アプリごとのアーキテクチャがなければ不変のインフラストラクチャは実現できない

2013 年に、不変サーバーの概念が導入されました。 不変サーバーは、不変という用語が示すように、静的です。 構成は固定されており、変更することはできません (少なくとも変更すべきではありません)。 変更が必要な場合は、新しい構成の新しいサーバーが実行中のサーバーに置き換えられます。 これが望ましい理由は、特にクラウドや高度に自動化されたオンプレミス環境では、構成が簡素化され、展開を推進する自動化システムの信頼性が向上するためです。

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

これは、共有インフラストラクチャの定義には複数の実行中のサービスが含まれるためです。 F5 iHealthデータに基づくと、複数とは平均 123 個の個別の構成 (仮想サーバー) を意味します。 1 つの仮想サーバーに 1 つの変更を加えるために、122 の仮想サーバーを停止して再デプロイすることは現実的ではなく、推奨もされません。

しかし、だからといってこの概念が非現実的であったり望ましくないというわけではない。 自動化およびインフラストラクチャ・アズ・コード (IaC) システムとともに不変のインフラストラクチャを採用するための鍵は、アプリごとのアーキテクチャに移行することです。

なぜ不変インフラストラクチャなのか?

企業のネットワーク アーキテクチャにこれほど大きな変化を起こすのはなぜでしょうか? 今日はもっと良い言い方が思いつかないので、私自身の言葉を引用させてください。

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

ソフトウェアエントロピーの法則は、 Ivar Jacobsonらによって「オブジェクト指向ソフトウェアエンジニアリング」で説明されています。 ユースケース主導のアプローチ":

熱力学の第二法則は、原則として、閉鎖系の無秩序性は減少することはできず、変化しないか増加するだけであると述べています。 この無秩序さの尺度がエントロピーです。 この法則はソフトウェア システムにも当てはまるようです。システムが変更されると、その無秩序性、つまりエントロピーは常に増加します。 これはソフトウェア エントロピーとして知られています。

この法律は、ファームウェアまたはシステムレベルの更新を適用する必要のあるシステムにも適用されます。 ホットフィックスとパッチが展開される対象。 理想的な世界では、厳密に従った変更管理プロセスを通じてのみ変更されるべきである構成の緊急調整。 不変（使い捨て）インフラストラクチャが解決しようとしている問題は、システムに導入する変更が増えるほど、システムがより不格好で不安定になるように見えることです。 障害。 混沌。 エントロピ。

これは、アプリのサービス構成を変更したり、最近発見された脆弱性に対する緊急仮想パッチを展開したりするだけではありません。 これらはアプリケーション サービス構成を変更する十分な理由ですが、唯一の理由ではありません。 ホット フィックス、パッチ、およびバージョンの依存関係も、共有インフラストラクチャ上で実行されている 123 の構成の 1 つを変更する必要がある理由として考えられます。

アプリごとのアーキテクチャに移行することで、共有インフラストラクチャで実行されている他の 100 個のインスタンスに対して、1 個、2 個、あるいは 10 個のインスタンスが中断される可能性がなくなります。 各アプリに独自のデータ パスを与えることで、本質的に、コード ベースのデプロイメント プラクティスとしての自動化されたインフラストラクチャへの移行をより適切にサポートする不変のインフラストラクチャ アプローチをサポートするための基盤が整います。

これは、完全にソフトウェア ベースのアプリケーション サービス パイプラインを意味します。アプリケーション サービスは、コンテナ内でマイクロサービスが展開される方法に非常に似た「マイクロ アプリケーション サービス」アーキテクチャで展開されます。 

Chef のJulian Dunn氏は、自身のブログ「 Immutable Infrastructure」で次のように説明しています。 実用的か否か?

不変のインフラストラクチャは、一般的に、一度構築し (仮想マシン イメージ、コンテナ イメージなど)、1 つまたは複数のインスタンスを実行し、その後は変更されないスタックとして定義されます。 デプロイメント モデルでは、インスタンス/コンテナを終了し、ステップ 1 からやり直して、新しいイメージを構築し、古いインスタンスを破棄します。

したがって、これを特定のアプリケーションに最も密接に結合されている (アフィン) アプリケーション サービスに適用すると、不変として扱われ、インフラストラクチャをコードの概念として展開/管理するアプリケーションごとの「スタック」に供給される、コアの共通共有サービス (ネットワーク DDoS や従来のポートベースのファイアウォール経由のアクセスなど) で構成される 2 層ネットワーク アーキテクチャが作成されます。

しかし、まず関連するアプリケーション サービスを共有プラットフォームから切り離す必要があるため、アプリごとのインフラストラクチャがなければ不変を実現することはできません。 同じプラットフォームをソフトウェア フォーム ファクターで使用できる場合は、アプリごとの不変モデルに向けて全力で取り組むために必要な知識とツールセットがすでに豊富にあるため、このプロセスはさらに簡単になります。

真の不変インフラストラクチャを検討していない場合でも、最も適切なタイミングでそれを活用できる機能 (新しいインフラストラクチャ バージョン、ホット フィックス、パッチなど) があれば、インフラストラクチャがサポートしているアプリの DevOps 所有者とユーザーの両方の作業が楽になります。