イミュータブルインフラストラクチャ とは？

サーバーに何度もパッチを当てたり設定を変えたりしていると「今この状態はどうなっているのか」が誰にもわからなくなるんだ。これを「設定のドリフト」と呼ぶ。3年間パッチを当て続けたサーバーと、新しく同じ手順で構築したサーバーは、実は微妙に違う状態になっていることがある。イミュータブルなら毎回新品だから、そういう問題が起きないんだよ。

例えばアプリを更新するときに、新しいバージョンを含んだAMI（マシンイメージ）やDockerイメージを作って、そこから新しいサーバーを起動する。ロードバランサーの向きを新しいサーバーに切り替えて、古いサーバーを破棄する。サーバーに直接SSHしてファイルを編集する、ということはしないんだ。

そう、コンテナはこの考え方ととても相性がいい。Dockerイメージは一度ビルドしたら変更されないし、新しいバージョンは新しいイメージとしてビルドする。Kubernetesが古いPodを消して新しいPodを起動するのも、まさにイミュータブルの考え方だよ。

これがイミュータブルインフラストラクチャの運用上の悩みどころでね。理想的にはサーバーにSSHしないから、問題調査はログやメトリクスを外部の監視基盤（CloudWatch、Datadog等）に集約しておく前提なんだけど、現実にはログだけでは再現できない問題がある。メモリリークやファイルディスクリプタの枯渇みたいな状態依存の問題は、そのサーバーの中を見ないとわからない。でも見るためにSSHすると「変更しない」原則が崩れる。だから「デバッグ用のサイドカーコンテナ」や「エフェメラルコンテナ」のような「見るけど変えない」仕組みが重要になってくるんだよ。