前回説明した通り、クラウドネイティブとは、クラウドの利用を前提としたシステムであり、クラウドの利点を最大限に活用することに力点が置かれています。
Herokuの「The Twelve-Factor App」が出てくるなど、これまで暗黙的に実行されてきたベストプラクティスが「クラウドネイティブな開発スタイル」として形式知化されてきています。
マイクロサービスは、クラウドネイティブなアーキテクチャと言われます。複数のサービスの組み合わせで構成されるため、それぞれのサービス基盤構築の頻度が増します。
今回はクラウドネイティブなアーキテクチャを実現するために重要な要素としての「Infrastructure as Code」、およびDockerなどの仮想化について説明します。
フェーズ別技術マップ(第4回の再掲) |
Infrastructure as Code
洗濯機をスマホのアプリで起動して洗濯をしたり、コネクテッドカーに代表されるような車の通信端末化が進んで渋滞予測・自動運転ができるようになったりと、これまでハード・インフラ寄りだった領域にソフトウェアが割って入ってきています。
もっとも、皆さんの中には、これらは組込み系の領域が中心で、コンピュータシステムの領域にはまだ遠い話だろう、という意識が強い方もいらっしゃるのではないでしょうか?
コンピュータシステムにおいて、これまでの自動化といえば、実装やテストの領域が主でした。
実装に関しては、小さな範囲の自動化では、Eclipseを使ったBeanの自動生成やコード補完があります。一方、大きな範囲の自動化ですと、設計書からのソース自動生成や、データベースモデル等から一括でCRUDの画面やロジック、SQL等を生成するScaffolding(土台作り)などが挙げられます。
また、テストに関しては、JUnitのテストコードを書いて単体テストを自動実行したり、キャプチャ&リプレイと呼ばれるブラウザでの作業を記録して結合テストを自動実行したりするものがあります。
それぞれの領域の詳細な説明は省きますが、旧来から取り組みが進むものの、依然として毎年のように新たな技術が出てくる活発な分野です。
近年、前回説明したCI(Continuous Integration)/CD(Continuous Delivery)の領域がより活発になってきており、さらに、Infrastructure as Codeと呼ばれる「基盤をコーディング」する、いわば第四の自動化領域が出てきています。
表:4つの自動化領域とInfrastructure as Code
領域名 | 対象フェーズ | 利用技術例 | |
---|---|---|---|
1 | ソースコード自動生成 | 開発(設計・実装) | Eclipse、TERASOLUNA ViSC |
2 | テスト自動化 | 開発(テスト) | JUnit、JsTestDriver、Selenium、Selenide |
3 | ビルド・デプロイ自動化(DevOps、CI/CD) | ビルド・デプロイメント | Jenkins、Gradle、Maven |
4 | 基盤自動化(Infrastructure as Code) | 環境構築・環境変更 | 構築:SDN、Chef、Puppet テスト:ServerSpec 概念:Immutable Infrastructure 仮想化:Docker |
これまでの基盤自動化と言えば、ハードウェア・ミドルウェアの設定作業をインストーラやシェルなどを用いて行ってきました。近年では、SDN(Software Designed Network)やChefなど、インフラ要素がソフトウェアにより定義・構築されたり、ServerSpecをはじめとする、ソフトウェアにおけるJUnitのようなテストコードを用いて基盤のテストを行ったりする風潮も生まれてきました。
この技術を後述する仮想化と併せて活用し、クラウドで言う所のIaaSやPaaSレイヤの構築を高速化します。仮想化を用いて個別システム・業務に依存しない不変部分を雛形化し、仮想イメージをコピーするのみである程度の構築作業を完了させます。その後、Infrastructure as CodeにおけるChefやPuppetといった基盤構築技術を用いて可変部分を自動化します。
定型的な繰り返しの作業が多ければ多いほど、自動化の効果がスケールします。このため、マイクロサービスのように複数のサービスの組み合わせで構成されるアーキテクチャは、それぞれのサービスの基盤構築の頻度が多くなり、Infrastructure as Codeによる効果が高まるのです。
仮想化、CI/CDとの住み分け |
仮想化が実現するクラウドの柔軟性
これまで、業務アプリケーション開発者が利用する開発環境を準備するのに数週間かかるのは当たり前でした。この部分が進捗上のボトルネックになったり、我慢した結果、試験環境の面数が足りずに作業の並列性を上げられなかったりするケースは珍しくなく、困った経験をした方もいらっしゃるでしょう。
こういったインフラ面の課題解決のアプローチとして、必要な時に必要なだけ払い出す、いわゆるイネーブラ技術や、払い出したインフラには変更を加えずに使い終わったら捨てるImmutable Infrastructureが注目されてきており、その中核をDockerに代表される仮想化技術が担っています。
Dockerとはオープンソースのコンテナ管理ソフトウェアの1つです。従来のVM(Gest OS)と比べ、OSのブート時間を削減できるうえ、ハードウェアリソースを有効に使えることなどから注目を集めています。また、Dockerfileを用いてコンテナイメージをコード化しており、前述のInfrastructure as Codeを実現しています。
これにより、仮想化を使わずにハード・OS単位で分割されているマシンと比べ、新規にインフラを払い出すのが容易になります。インフラの払い出しの応用で「Auto Scaling」も実現できます。
マイクロサービスは小さな単位にサービスを分割するため、インフラの払い出しに対する要求頻度が高まり、仮想化との親和性が高いと言えます。
* * *
今回は、前回に引き続き、マイクロサービスと並び注目されてきている「クラウドネイティブ」について説明しました。クラウドネイティブなアーキテクチャを実現するために第四の自動化領域であるInfrastructure as Codeを用いて基盤構築を高速化することが重要になってきます。
次回は、「Spring Boot」と呼ばれるフレームワークを用いて実際にHello Worldレベルのマイクロサービスを作ってみることで、開発フェーズにおけるマイクロサービスの理解を深めます。
著者紹介
正野 勇嗣 (SHONO Yuji ) - NTTデータ シニア・エキスパート
2011年頃まで開発自動化技術のR&Dに従事。その後、開発プロジェクト支援やトラブルシューティング等に主戦場を移す。「ソースコード自動生成」に加えて、JenkinsやMaven等の「ビルド自動化」、JsTestDriverやSelenium等の「テスト自動化」を扱うようになり、多様化する開発自動化技術動向に興味。
最近は第四の自動化であるInfrastructure as Code等の「基盤自動化」の魅力に惹かれている。開発自動化技術に関する雑誌・記事執筆も行う。2児のパパ。