イミュータブルインフラストラクチャ(Immutable Infrastructure)とは、「環境を変更する場合は、既存の設定を変更して、環境を更新するのではなく、設定が変更された新しい環境を用意し、古い設定の環境は捨てる」という考え方です。構築された環境は変更しないことをポリシーにします。これまでのインフラ管理の考え方からすると非常に大胆な考え方です。
イミュータブルインフラストラクチャには大きなメリットが2つあります。
既存の設定を無視し、新しい設定で環境を作り直せば「既存の設定が邪魔をして新しい設定を環境に適用できない」ということはまずあり得ません。第1回で「初期構築は何もない状態から作るので既存環境の影響を考える必要がなく、さほど問題なく作ることができる」と解説した通り、毎回新しく作り直せば既存環境がどうであるか気にする必要がないのです。
これは2つ目のメリットである設定手順の自動化にもつながります。従来のインフラ管理では、既存設定がどうなっているかを確認し、環境の更新時にミスが生まれないよう「Excel手順書」を利用するケースが多くありました。
Excel手順書は、サーバ機器の設定を事前に確認して一つずつ順番に記載したものです。この手順書を元に、作業員が運用業務を行ってきました。ミスを防ぐために複数名で実施し、実施時刻を記入して「作業実績エビデンス」として残す場合もあります。
これは「更新作業を自動化できない」という問題から利用されてきましたが、イミュータブルインフラストラクチャの「古いものは捨てて、その都度作成する」という考え方により、「自動化できない手順書での対応」というものをなくしているのです。
2つ目のコンセプトは、宣言的設定です。従来、サーバの管理にはExcelのパラメーターシートなどを用いて管理していました。さまざまなミドルウェアの設定を全てExcelのシートに書き出し、一つずつそれに沿ってサーバを構築します。しかし、これにも問題があります。
Excel手順書を用いた更新作業後、パラメーターシートが更新されないことが多々あるのです。その結果、パラメーターシートを確認してもサーバ側の設定が分からず、結局サーバでコマンドを操作して確認するという「2重管理」が起きます。
宣言的設定では、この2重管理を起こさないため、Kubernetesでのマニフェストファイルを基準にします。サーバ側の設定を変更する際は、このマニフェストファイルを先に修正し、Kubernetes環境に適用します。その結果、必ずKubernetesのマニフェストファイルの設定とKubernetes環境の設定が同一のものになります。もし同じ環境を再現する場合は、このマニフェストファイルを別の場所で適用すればいいのです。
Copyright © ITmedia, Inc. All Rights Reserved.