クラウド・ネイティブという考え方――これからのIT基礎知識 Vol.2

記事をシェアする:

クラウド・ネイティブ基礎知識解説の連載2回目。イミュータブル・インフラストラクチャーを取り上げる。コンテナ移行に加えてイミュータブル・インフラストラクチャーの概念を取り入れた開発と運用サイクルを回すことで、真にクラウド・ネイティブのメリットを受けることができる。

執筆者：高良 真穂 ID:maho.takara

日本IBM クラウド＆コグニティブ・ソフトウェア事業本部、「15Stepで習得 Dockerから入るKubernetes」の著者

OpenShift／Kubernetesの導入で成果をあげる道

クラウド・ネイティブ基礎知識解説

1. CNCFとは（Vol.1）
2. クラウド・ネイティブの定義（Vol.1）
3. クラウド・ネイティブの特徴的アプローチ（Vol.1）
3-1. コンテナ（Vol.1）
3-2. イミュータブル・インフラストラクチャー
3-3. マイクロサービス（Vol.3）
3-4. サービスメッシュ（Vol.3）
3-5. 分散トレーシング（Vol.3）
3-6. 宣言型API：declarative APIs（Vol.3）
3-7. コンテナ・オーケストレーター Kubernetes（Vol.4）
3-8. モニタリングとロギング（Vol.4）
4. クラウド・ネイティブ推進の課題と解決の取り組み（Vol.4）
5. まとめ（Vol.4）

3.2. イミュータブル・インフラストラクチャー

しかし、アプリケーションをコンテナへ移行だけではデメリットしかない。コンテナ移行に加えてイミュータブル・インフラストラクチャーの概念を取り入れた開発と運用サイクルを回すことで、真にクラウド・ネイティブのメリットを受けることができる。これは重要なポイントである。

この手法の概要と名前の由来

イミュータブル(不変の)・インフラストラクチャー(Immutable infrastructure)は、ITサービス運用における アプリケーションのデプロイ、および、サービス管理の手法である。これは、アプリケーションの構成要素(components)に変更が発生した場合、本番環境の中で変更するのではなく、変更済みのアプリケーションのコードと依存するソフトウェア一式を再デプロイして置き換える手法である。

アプリケーションのコードと依存するソフトウェア一式とは、アプリケーションの実行コード、プログラミング言語ランライム環境、OSライブラリ、ミドルウェアのクライアントライブラリ、設定ファイルなど、アプリケーションを実行に必要なソフトウェアのセットである。

従来のITサービス運用では、アプリケーションのコードなど構成要素に変更の必要がある場合、本番サービスを中断して、または、サービス継続中に、ソフトウェアの構成要素の変更が実施されてきた。

しかし、イミュータブル・インフラストラクチャーでは、稼働中であっても、前述の一式を丸ごと置き換える。例えば、ソフトウェアのセットの中で一つの要素に変更に必要があった場合でも、そのセットの中で部分的変更を行うのではなく、ソフトウェア一式を再アセンブルして置き換える。ここで、アセンブルと呼ぶ理由は、アプリケーションのソースコードからのコンパイル、コンテナのビルド、ライブラリのインストール、設定ファイルの配置、起動シェルスクリプトのセットなど、必要となるパーツ（ファイル）を集めて組み立てるように、一式を作成するからである。 ここでソフトウェアの一式としている実態は、コンテナとなっているケースと、ディレクトリとファイルのセットのケースがある。
 

従来型とイミュータブル・インフラストラクチャーの違い

イミュータブル・インフラストラクチャーと呼ばれる理由は、ソフトウェアの一式としてアセンブルされた状態から変更できないためである。具体的には、プログラム言語のライブラリの一つに変更がある場合でも、一部を変更するのではなく、一式を作りなおす。そして、新たに作りなおした一式を、本番環境にデプロイする前に、アプリケーションの正常稼働を確認する。

つまり、イミュータブル・インフラストラクチャーは、アプリケーションが依存する基盤となるソフトウェアが、随時変更されない、不変であることを意味している。

解決する課題

アプリケーションのコードと、その基盤となるソフトウェアに変更がある場合に、一部を変更して使い続けるのではなく、一式を作りなおす手法は、様々なメリットをもたらす。

• 実行環境の一部を変更するのではなく、変更時は一式を作り直して再デプロイするため、構成のドリフト（揺らぎ）を軽減
• 脆弱性が発見されたソフトウェアを変更と品質の担保が容易となることから、脆弱性による攻撃の脅威を軽減
• 複数の固有設定や複数バージョンのファイルから、リストアするのではなく、一式を置き換えるため、予定外の停止時間を軽減
• 繰り返し一式をデプロイする結果として、十分にテストされ検証済みの共通イメージを構築
• イミュータブル・インフラストラクチャーは、アプリケーションのコードと依存するソフトウェア一式の運用に必要な自動化を促進
• イミュータブル・インフラストラクチャーは、ITの複雑さと軽減して、障害発生を減少させる
• アプリケーションが更新されるたびに、テスト済みの最新のインスタンスが開始されるため、サーバーのパッチ適用や構成の変更が不要となり、変更を追跡して管理する必要が無い
• アプリケーションの更新後に問題が発生した場合、以前の既知の正常なインスタンスにロールバックが簡単
• 個々のサーバー内のコンポーネントを変更しないため、予測できない動作やコード変更の意図しない結果が生じる可能性を削減

イミュータブル・インフラストラクチャーの効果は、アプリケーションのコードと依存するソフトウェア一式を形成し、デプロイのサイクルを繰り返すことから得られる。

アプリケーションをコンテナへ移行するだけでは、クラウド・ネイティブのメリットを受けることはない。むしろ、それまでのサーバー運用と同じことを実施していては、デメリットが大きい。つまり、コンテナへ移行と合わせて、イミュータブル・インフラストラクチャーの概念を取り入れた開発と運用サイクルを回すことで、クラウド・ネイティブのメリットを受けることができるようになる。

The Twelve-Factor App

PaaS (Platform As a Service)は、利用者自身がコンテナをビルドすることは無いが、アプリケーションが依存するOSやライブラリ等の基盤を変更できない点で、イミュータブル・インフラストラクチャーの実装形態の一つである。そのため、クラウド・ネイティブのドキュメントなどからも、参考にするべき手法であるとして、The Twelve-Factor Appの参照が推奨されている。

The Twelve-Factor Appは、もともとHerokuプラットフォーム上での仕事の経験を元に書かれたアプリケーションの設計原則である。Herokuは、アプリケーションのコードとマニフェストを共に登録することで、そのサービスの内部で、ビルドしてコンテナ化して実行する。そして、データベースなどのアプリケーションに必要なサービスは、メニューから選択して対応づけることで、アプリケーションのコードからアクセスできる。つまり、Herokuは、PaaSである。この様なPaaSの仲間には、Cloud Foundryや Red Hat OpenShiftの S2I機能がある。
 
以下のサマリーの詳細は、Webサイトにあるので参考にしていただきたい。

参考資料

• Red Hat OpenShift on IBM Cloud
• IBM Cloud Paks：エンタープライズグレードのフル・スタック・クラウド・ソリューション
• 特定のクラウドに依存しないシステム・アプリ開発とは