インフラを『触って直す』ほど壊れる理由: IaC と DB 設定が教える一つの原則

Jun 14, 2026

1 min read

1 views

88%

変更とは、状態を増やすことではなく、真実を一つに保つこと

インフラを運用していると、ある瞬間にこんな感覚に襲われます。「動いているのに、なぜか安心できない」。画面上は正常、アプリも返答している、しかしどこかで差分が生まれている気がする。実はその不安こそ、システムが抱える最も厄介な問題の前触れです。

なぜなら、インフラで本当に壊れるのはサービスそのものではなく、何が正しい状態なのかという定義だからです。テンプレートに書かれた内容、実際に存在するリソース、そして運用者の頭の中にある理解。この三つが一致している間だけ、変更は制御可能です。どれか一つでもずれると、システムは「動いているが説明できない」状態になります。

ここで見える核心は意外とシンプルです。インフラ運用の難しさは、設定を増やすことではありません。正しい状態を一箇所に保てるかどうかにあります。

ドリフトはバグではなく、認識の分裂である

多くの人は、設定の食い違いを単なるミスとして扱います。だれかがコンソールで値を変えた。緊急対応で手作業の修正をした。試しに少しだけいじった。こうした行為は一見すると実務的ですが、その瞬間からシステムは二重化します。コード上の真実と現場の真実が別々に存在し始めるからです。

このズレは、いわゆるドリフトです。厄介なのは、ドリフトがすぐに事故を起こすとは限らないことです。むしろ多くの場合、しばらくは静かに潜みます。だから人は油断する。しかし次の更新、次の削除、次の再作成のタイミングで、以前の手作業の変更が消えたり、想定外の差分として表面化したりする。つまりドリフトは、後から来る変更に利息を付けて返してくる負債です。

ここで重要なのは、「手で直したから早い」ことと「正しい状態になった」ことは別問題だという点です。手作業は局所最適を与えますが、システム全体の真実を増やしません。むしろ真実の在りかを分散させます。

変更管理の本質は、機械を動かすことではない。真実の所在を一つに保つことだ。

たとえば、会議室の予約表を紙と共有スプレッドシートと個人メモの三箇所で管理しているとします。どれか一つにだけ書き忘れた瞬間、部屋は空いているのか埋まっているのか、誰にも確実には分からなくなる。インフラのドリフトは、まさにこの状態です。機械が複雑だから難しいのではありません。単一の正解を維持する制度がないから難しいのです。

デフォルト値は、無意識の標準装備である

ここで、DB パラメータグループの話が鋭く効いてきます。各 DB インスタンスには、DB エンジンとバージョンに応じたデフォルトの DB パラメータグループが使われます。これは一見、単なる仕様説明のように見えます。しかし実際には、運用の哲学を示しています。

デフォルトとは、何も設定しないときにシステムが選ぶ「標準の意味」です。問題は、デフォルトが便利であるほど、人はそれを意識しなくなることです。意識しないまま使われる設定は、気づかれないままルールになります。ルールになると、例外が増えたときに初めてその存在が露わになる。

つまりデフォルトは、ただの初期値ではありません。暗黙の統治機構です。多くの DB は、実は明示的に設計したから安定しているのではなく、デフォルトがうまく機能しているから安定しています。しかし、デフォルトに依存したまま個別対応を積み重ねると、ある時点でその安定は崩れます。標準に寄りかかりながら、標準を更新していないからです。

ここに、IaC の考え方と深くつながる点があります。テンプレートは、単にリソースを作るためのファイルではありません。何を標準とみなすかを明文化する装置です。テンプレート外で変更してはいけない理由は、厳格だからではない。標準の位置がずれると、デフォルトと例外の境界が曖昧になるからです。

たとえば、ある RDS インスタンスでパラメータを数個だけ変更したとします。初めは問題ないかもしれません。しかし時間が経つと、どの設定がエンジンのデフォルトで、どの設定がチーム独自の運用方針で、どの設定が一時しのぎの調整なのか、誰にも分からなくなる。こうしてシステムは、設定の集合体ではなく、由来不明の選択肢の堆積物になります。

本当に設計すべきなのは、設定値ではなく変更経路である

ここで視点を一段引き上げると、より大きな真理が見えます。優れた運用とは、最適な値を見つけることではありません。値がどう変化しても破綻しない経路を設計することです。

多くの現場は、何を設定するかに集中しすぎます。メモリの値はこれでよいか、タイムアウトは何秒か、DB パラメータはこの組み合わせでよいか。もちろん重要です。しかしそれ以上に重要なのは、その値を誰が、どの方法で、どの記録に基づいて変えるのかです。設定値は点ですが、変更経路は線です。システムを壊すのは点ではなく、線の途切れです。

この観点から見ると、CloudFormation の「スタック内のリソースは CloudFormation 以外で変更しない」という原則は、単なる操作ルールではありません。変更経路を一本化するための制約です。変更が一本化されていれば、差分は追跡できる。差分が追跡できれば、原因を説明できる。原因を説明できれば、再発を防げる。

逆に、コンソールからの即席修正や、手元の都合での個別変更が増えると、変更経路は迷路になります。迷路では、速く動くことよりも、今どこにいるか分からないことのほうが致命的です。運用の失敗は、しばしば性能不足ではなく、経路不明として起こります。

良い運用は、正しい答えを知っていることではない。正しい答えにたどり着く道を、毎回同じにできることだ。

この考え方は、DB パラメータにもそのまま当てはまります。デフォルトを使うのは悪ではありません。むしろ、デフォルトは変更経路を短くし、理解可能性を上げます。ただし、デフォルトを採用するなら、その選択を明示しなければいけません。何もしないことと、デフォルトを意図的に使うことは違うからです。

「触って直す」文化から「宣言して戻す」文化へ

ここで、実務で最も大きな転換点が訪れます。多くの組織では、問題が起きたときに「まず触る」文化があります。止めずに直す、急いで戻す、コンソールで調整する。気持ちは分かります。現場には時間がなく、障害は待ってくれないからです。

しかし、短期的な復旧を優先するほど、長期的な再現性は失われます。そこで必要なのは、触って直すから宣言して戻すへの移行です。つまり、今の状態をいじって正解に近づけるのではなく、望ましい状態を宣言し、その宣言に実状態を戻すことです。

このとき IaC と DB 設定は、別々の技術ではなく同じ思想の二つの表れになります。IaC は「リソースの構造」を宣言する。DB パラメータは「動作の前提」を宣言する。どちらも、暗黙の運用を明示に変えるための道具です。さらに言えば、どちらも例外を減らすための装置ではなく、例外を管理可能にするための装置です。

たとえば、あるアプリでデッドロック回避のために DB のタイムアウトを少し伸ばしたいとします。これを一度だけ手で変えると、後で再デプロイした際に元に戻るかもしれません。あるいは逆に、テンプレートに戻すと本番の挙動が崩れるかもしれません。問題は値そのものより、「その値がどこで定義されているのか」が曖昧なことです。宣言して戻す文化では、この曖昧さを消します。

宣言型の強みは、変更を遅くすることではありません。むしろ、変更を速く安全にすることです。毎回手で状況判断するのではなく、既知の意図に照らして反映するからです。

実践のためのフレームワーク: 三つの真実を揃える

ここまでを一つの実践フレームワークにまとめるなら、ポイントは三つの真実を一致させることです。

設計の真実: どうあるべきかをテンプレートや定義で表す。
実体の真実: 実際のリソースや DB がどうなっているかを把握する。
運用の真実: どう変えてよいか、誰がどこから変えるかを決める。

この三つが一致していれば、変更は予測可能です。一致していなければ、どれだけ丁寧に作業しても、その場しのぎになります。重要なのは、完璧な設定を一発で作ることではなく、三つの真実の距離を最小化することです。

具体例で考えましょう。ECS のタスク定義を一部だけ手で修正したとします。今は動いているので一見成功です。しかしテンプレートは修正されていないため、次回の更新で元に戻るかもしれない。さらに、DB 側ではパラメータグループがデフォルトのままなのか、個別調整済みなのかが曖昧だと、アプリの挙動と DB の前提が食い違います。こうしたとき、障害はコードの中ではなく、定義と実体の境界で起こります。

だから本当に必要なのは、個別の作業テクニックではありません。必要なのは、境界を曖昧にしない規律です。テンプレートが真実の出典であること。デフォルトがどこまで適用されているかを理解すること。そして、変更を例外処理ではなく通常経路に組み込むことです。

Key Takeaways

手作業の修正は、速度を買って一貫性を売る行為だと認識する。
テンプレート、実体、運用ルールの三つを一致させることで、ドリフトを防ぐ。
デフォルト値は無意識の標準なので、使うなら必ず意図を明示する。
設定値より変更経路を設計する。誰が、どこから、どう変えるかを固定する。
「宣言して戻す」運用を徹底し、場当たり的な修正を最終形にしない。

終わりに: 安定したシステムとは、変わらないシステムではない

インフラの成熟を、変更しないことだと誤解すると、運用はすぐに硬直します。実際には逆です。安定したシステムとは、変化が起きても真実がぶれないシステムです。テンプレートで宣言され、デフォルトの意味を理解し、実体と定義の差分がいつでも説明できる。そんな状態こそが、もっとも強い。

ドリフトが怖いのは、設定が変わるからではありません。変わったことに気づけなくなるからです。そしてデフォルトが重要なのは、単に便利だからではありません。何も決めていないときに、システムが何を選ぶかを示してくれるからです。つまり、インフラ運用の本質は、機械を制御することではなく、意味の一貫性を維持することにあります。

一度この視点を持つと、インフラを見る目が変わります。個別の設定値は、もはや単なる数値ではない。それは、組織が「何を正しい状態とみなすか」を表す契約です。契約を手で書き換え続ける組織は、いずれ自分の契約文を読めなくなる。逆に、契約を一箇所で宣言し、そこに戻れる組織は、変化の多い世界でも壊れません。

本当に強い運用とは、何でも自由にいじれることではない。何が真実かを一度決めたら、そこへ何度でも戻れることです。