アプリ単位のアーキテクチャなしにイミュータブルインフラストラクチャは実現できない

F5

2013年に、イミュータブルサーバーという概念が紹介されました。イミュータブルサーバーは、「イミュータブル（不変）」という言葉が示すとおり、静的なサーバーです。構成は固定されており、変更できません（少なくとも変更すべきではありません）。変更が必要な場合は、新しい構成のサーバーで稼働中のサーバーを置き換えます。これが望ましい理由は、特にクラウド環境や高度に自動化されたオンプレミス環境において、構成が簡素化され、デプロイを実行する自動化システムの信頼性が向上するためです。

この概念は、ネットワークサービスやアプリケーションサービスであっても、クラウド環境やコンテナ化された環境ではうまく機能しますが、従来型の共有インフラストラクチャアーキテクチャにはあまり適していません。

これは、共有インフラストラクチャが複数のサービスを実行することを前提としているためです。F5 iHealth のデータによると、その数は個別の構成（仮想サーバー）で平均123に上る場合があります。1台の仮想サーバーに1つの変更を加えるために、残り122台の仮想サーバーを停止して再デプロイすることは、現実的ではなく、推奨もされません。

しかし、だからといって、この概念が非現実的または望ましくないものになるわけではありません。自動化およびInfrastructure as Code（IaC）システムとともにイミュータブルインフラストラクチャを導入する鍵は、アプリケーション単位のアーキテクチャへ移行することです。

イミュータブルインフラストラクチャを採用する理由

なぜ企業ネットワークのアーキテクチャをこれほど大きく転換する必要があるのでしょうか。今でもこれ以上うまく言い換える方法が思いつかないため、以前の自分の言葉を引用します。

なぜなら、エントロピーです。

ソフトウェアエントロピーの法則については、Ivar Jacobsonらによる『オブジェクト指向ソフトウェア工学：ユースケース駆動アプローチ』で次のように説明されています：

原則として、熱力学第二法則では、閉鎖系の無秩序さは減少せず、変わらないか増大するだけであるとされています。この無秩序さを表す尺度がエントロピーです。この法則はソフトウェアシステムにも当てはまると考えられます。システムに変更を加えると、その無秩序さ、すなわちエントロピーは常に増大します。これはソフトウェアエントロピーとして知られています。

この法則は、ファームウェアやシステムレベルのアップデートを適用しなければならないシステムにも当てはまります。ホットフィックスやパッチが適用されるシステムも同様です。また、本来であれば厳格な変更管理プロセスに従ってのみ変更すべき構成に、緊急の調整が加えられるシステムにも当てはまります。イミュータブル（使い捨て型）インフラストラクチャが解決しようとしているのは、システムに変更を加えるほど、不要なものが蓄積し、不安定さが増していくように見えるという問題です。無秩序。混沌。エントロピー。

アプリケーションを提供するための構成変更や、最近発見された脆弱性に対する緊急の仮想パッチの適用だけが理由ではありません。これらはアプリケーションサービスの構成を変更する妥当な理由ですが、それだけではありません。ホットフィックス、パッチ、バージョンの依存関係も、共有インフラストラクチャ上で稼働する123個の構成のいずれかを変更する必要が生じる妥当な理由です。

アプリ単位のアーキテクチャに移行することで、共有インフラストラクチャ上で稼働するインスタンスのうち、1つ、2つ、あるいは10個で障害が発生しても、残りの100個に影響が及ぶ可能性を排除できます。各アプリに専用のデータパスを割り当てることで、イミュータブルインフラストラクチャのアプローチを採用するための基盤が整い、Infrastructure as Codeに基づく自動化されたデプロイ手法への移行をより効果的に支援できます。

これは、完全にソフトウェアベースのアプリケーションサービスパイプラインを意味します。そこでは、コンテナ内にマイクロサービスをデプロイするのと同様に、アプリケーションサービスが「マイクロアプリケーションサービス」と呼べるアーキテクチャでデプロイされます。

Julian Dunn氏（Chef）は、ブログで次のように的確に述べています。イミュータブルインフラストラクチャ：実用的か否か？

イミュータブルインフラストラクチャは一般に、仮想マシンイメージ、コンテナイメージ、その他の形式を問わず、一度構築した後、そのインスタンスを1つまたは複数実行し、以後は一切変更しないスタックと定義されます。このデプロイモデルでは、インスタンスまたはコンテナを終了し、最初の手順からやり直します。つまり、新しいイメージを構築し、古いインスタンスを破棄します。

これを、特定のアプリケーションと最も密接に結合（アフィニティ）しているアプリケーションサービスに適用すると、2層のネットワークアーキテクチャになります。これは、ネットワークDDoS対策や従来のポートベースのファイアウォールによるアクセス制御など、コアとなる共通の共有サービスと、そこから接続されるアプリケーションごとの「スタック」で構成されます。このスタックはイミュータブルなものとして扱われ、Infrastructure as Codeの概念に基づいてデプロイおよび管理されます。

しかし、アプリケーション単位のインフラストラクチャがなければ、イミュータブル化は実現できません。関連するアプリケーションサービスを共有プラットフォームから切り離すことが、まず必要だからです。同じプラットフォームをソフトウェア形態で利用できれば、このプロセスはさらに容易になります。アプリケーション単位のイミュータブルモデルへ本格的に移行するために必要な知識やツールセットの多くが、すでに整っているためです。

真のイミュータブルインフラストラクチャを検討していない場合でも、新しいインフラストラクチャバージョン、ホットフィックス、パッチなど、最も適した場面で活用できれば、インフラストラクチャの担当者と、そのインフラストラクチャが支えるアプリのDevOps担当者の双方にとって、運用が容易になります。

著者について

F5

F5のその他のブログ記事