【ITニュース解説】Configuration Drift Is a Production Incident With a Long Fuse

ITシステムを運用する現場では、予測不能なトラブルがしばしば発生する。その中でも特に原因究明が困難で厄介なのが、「設定のズレ（Configuration Drift）」と呼ばれる現象だ。これは、稼働中のシステムの実際の設定が、本来あるべきとされる設定や記録された設定と異なっている状態を指す。このズレは、まるで時間差で爆発する爆弾のように、ある日突然、大きな問題を引き起こす可能性がある。

想像してみてほしい。ある日突然、あなたのWebサイトの決済機能が使えなくなった。利用者が支払い手続きをすると「502エラー」が表示される。これはサーバーが正しく応答できないことを示すエラーだ。しかし、困ったことに、前週に問題なくデプロイしたのと同じバージョンのプログラムを使っている。システムを動かしているサーバー（ポッド）も正常に動いていると報告しているし、CPUの負荷もいつも通り低い。決済機能が連携している外部の支払いプロバイダーも、システムからの健全性チェックにはきちんと応答している。ポッドを再起動したり、前のバージョンに戻したり、プロバイダーのステータスを確認したりと、あらゆる手を尽くしても問題は解決しない。原因はどこにも見当たらないように思える。

このトラブルの真の原因は、非常に単純なものだった。それは、システムの動作を制御する「環境変数」という設定の一つが、新しく入れ替わったサーバーには存在しなかったことだ。問題が発覚する数ヶ月前、決済プロバイダーの処理が一時的に遅くなったことがあった。これにより、決済の要求が一定時間内に処理されずタイムアウトし、502エラーが頻発していたのだ。本来であれば、正式な開発プロセス（レビュー、ビルド、段階的なデプロイなど）を経て設定を変更すべきだったが、緊急事態だったため、システム運用担当者が直接稼働中のサーバーにアクセスし、タイムアウト時間を延ばす環境変数を手動で設定した。この変更によってエラーは減り、システムは正常に戻った。しかし、この手動での変更はどこにも記録されず、リポジトリにも反映されないままだった。

このようにして、設定のズレは少しずつ蓄積していく。これは一度の劇的な変更で起こることは稀で、ほとんどの場合、小さな変更が積み重なることによって発生する。例えば、kubectl set envというコマンドで一時的に環境変数を設定したり、管理コンソールのスライダーを動かしたり、特定の開発環境だけで必要な環境変数を追加したり、リポジトリの設定に誤りがあったために直接サーバーの設定ファイルを修正したりといったケースだ。それぞれの変更は、その瞬間には正当な理由があり、問題を解決する有効な手段に見える。しかし、これらの変更が適切な手順で記録・共有されなければ、その存在は変更を行った本人以外には「見えない」ものとなる。そして、そのツケは後になって、全く別の場所で、予想もしない形で支払われることになるのだ。

設定のズレによる障害が特に厄介なのは、普段信頼しているはずの全ての情報源が沈黙している点にある。プログラムのコードは何も変わっていないため、デプロイ履歴はクリーンに見える。使用しているプログラムのイメージバージョンも同じなので、リポジトリを見ても何も異常は検出されない。設定ファイルのリポジトリも誰も触っていないため、差分（以前の状態との変更点）は全く表示されない。つまり、何も変わっていないように見えるのに、システムは正しく動かないのだ。

本当に変わったのは、プログラムが動く「土台」の部分である。サーバーの入れ替え、システム規模の拡張、仮想マシンの更新、災害時の別拠点への切り替えなど、何らかの理由で新しいインスタンス（サーバーや実行環境）が構築される際、これらはリポジトリに記録されている「真実」に基づいて作成される。しかし、以前から稼働していたインスタンスには、手動で適用された「一時的な修正」が残っている場合がある。結果として、一時的にシステム内に「古い修正を持ったインスタンス」と「新しい（修正なしの）インスタンス」が混在する「混合環境」が生まれる。これが最悪のシナリオだ。同じサービスを動かす二つのサーバーが、同じ要求に対して異なる応答をする可能性があるため、問題がさらに複雑化する。もし「古いサーバーでは問題なく動くのに、新しいサーバーでは動かない」という現象に遭遇したら、それは設定のズレが発生している可能性が非常に高い。

設定のズレを見つける唯一の方法は、現在稼働中のシステムの設定状態と、リポジトリにコミットされている（公式に記録されている）設定状態を比較することだ。文書化された設定は、それが書かれた時点の意図を表しているが、その情報を書いた人が既に会社を辞めている可能性もある。結局のところ、リポジトリに存在する情報が最も信頼できる「真実の源」なのだ。

そこで、稼働中の環境自身に「私はどんな設定で動いているのか」を報告させ、その情報をリポジトリの情報と比べる方法が有効となる。例えば、以下のようなコマンドを実行する。

kubectl exec deploy/payments -- env | sort > /tmp/live.env （稼働中の支払いシステムの環境変数を取得し、一時ファイルに保存する） grep -E '^[A-Z_]+=' config/payments.env | sort > /tmp/repo.env （リポジトリにある支払いシステムの設定ファイルから環境変数を取得し、一時ファイルに保存する） diff -u /tmp/repo.env /tmp/live.env （二つのファイルの内容を比較し、差分を表示する）

この比較作業を、システムが正常に稼働している間に定期的に実行することが重要だ。緊急事態が発生してから慌てて行うべきではない。live.envに存在するがrepo.envに存在しない設定、または値が異なる設定は、全て設定のズレとして特定される。この方法は、データベースのパラメータや、新機能の有効・無効を切り替える設定、インフラストラクチャの管理コンソールで設定される項目など、あらゆる設定に適用できる。

このケースでは、リポジトリにある設定ファイルにはpayment.clientTimeoutMsが「8000」ミリ秒と書かれていたにもかかわらず、手動のコンソール操作でその値が「20000」ミリ秒に変更されていたことが判明した。リポジトリから作成された新しいサーバーは「8000」ミリ秒の設定を受け取り、その結果、プロバイダーが遅い時に再びタイムアウト問題が発生してしまったのだ。

このような設定のズレを防ぐための最も重要なルールは「リポジトリにないものは存在しない」という原則を徹底することだ。稼働中のプロセス内部にのみ存在する設定は、もはや「設定」とは呼べない。それは期限付きの、文書化されていない変更であり、その期限は次回の再起動の時である。

もちろん、緊急事態は起こりうる。真夜中に手動で値を変更することが、その時点での最適な解決策である場合もあるだろう。しかし、その「緊急脱出」には代償が伴う。手動で行われた全ての変更は、必ず同じシフトのうちにリポジトリに対してコミット（変更の登録）を行い、そのコミットをインシデント（障害）対応チャンネルで共有し、変更理由をメッセージに含めることを義務付ける。そして、そのコミットがリポジトリにマージされるまで、インシデントはクローズしない、というルールを設けるのだ。コミットがなければ、修正も存在しない、と考える。

このルールを徹底することで、設定のズレは関係者が必ず確認する「リポジトリ」という一箇所で可視化される。変更をレビューする人々はその内容を理解し、次に運用を担当する人は、単に値だけでなく、その変更が行われた理由も継承できる。そして、次にサーバーが入れ替わる時、新しい環境は、既に問題なく稼働している環境と完全に一致するようになる。なぜなら、その稼働中の設定はもはや「秘密」ではなく、リポジトリに正式に記録された「真実」となっているからだ。安定したシステム運用のためには、このような厳格なルールとプロセスが不可欠である。