IaC

概要

IaC（Infrastructure as Code）は、サーバ・ネットワーク・データベースといったインフラの構成を、管理画面での手作業ではなくコードとして記述し、ツールに適用させる実践です。「Webサーバを2台、この設定のロードバランサの背後に置く」といった構成をテキストファイルで宣言すると、ツールがクラウドのAPIを呼んでそのとおりの環境を作り上げます。

代表的なツールはTerraform（クラウド横断で使えるデファクト）、AWS CloudFormation、Pulumi（汎用プログラミング言語で書ける）など。構成がただのテキストファイルになるため、Gitでの履歴管理、プルリクエストでのレビュー、同一環境の複製といった、アプリケーション開発で培われた規律をそのままインフラに持ち込めます。

なぜ生まれたか

手作業のインフラ管理には宿命的な問題がありました。管理画面でポチポチ設定したサーバは、時間とともに「誰が・いつ・なぜその設定にしたのか」が失われ、触るのが怖い「秘伝のタレ」と化します。本番とステージングの微妙な差異が原因の「本番でだけ起きるバグ」、担当者の退職とともに消える構築ノウハウ、障害でサーバを失ったときに元通りに再構築できない恐怖 — いずれも「構成が人間の記憶と手順書にしかない」ことに根があります。

クラウドコンピューティングの普及がこの問題を深刻化させると同時に、解決の道も開きました。インフラがAPIで操作できるようになったことで、「構成をコードに書き、機械に適用させる」ことが原理的に可能になったのです。構成の唯一の真実をコードに置き、人間はコードだけを編集する — これがIaCの中心思想です。

詳細

宣言的アプローチと冪等性

IaCツールの多くは「宣言的」に書きます。「サーバを作れ」という手順ではなく「サーバが2台ある状態」という結果を記述し、現状との差分を埋めるのはツールの仕事です。この方式の利点は冪等性（べきとうせい）、つまり何度適用しても同じ結果になる性質です。手順型のスクリプトは2回実行するとサーバが4台になりかねませんが、宣言型なら「2台ある」状態に収束します。すでに望む状態なら何もしない — 安心して繰り返し実行できることが、自動化の土台になります。

plan → apply のワークフロー

Terraformに代表されるワークフローの核心は、適用前に変更内容を確認できることです。コードを編集したら、まず plan で「何が作られ、何が変更され、何が削除されるか」の実行計画を確認します。意図しないリソースの削除がここで見つかれば、適用前に止められます。計画に問題がなければ apply で実際にクラウドへ反映する — この二段構えが、インフラ変更に「実行前のレビュー」という安全装置を与えます。

ツールは適用結果を「state（状態ファイル）」に記録し、コードと現実の対応関係を管理します。stateはチームで共有ストレージに置くのが必須で、その破損や競合はIaC運用の古典的なトラブル源です。

コードになると何が変わるか

構成がコードになると、Gitのプルリクエストでインフラ変更をレビューできます。「なぜこの変更をしたか」がコミット履歴に残り、問題があれば以前のバージョンに戻せます。さらに強力なのが環境の複製で、同じコードに変数だけ変えて適用すれば、本番とほぼ同一のステージング環境が数分で立ち上がります。災害復旧の観点でも、「コードさえあれば環境全体を作り直せる」状態は手作業運用とは比較にならない安心感があります。CI/CDパイプラインに組み込めば、「インフラの変更もpushとレビューで進む」開発フローが完成します。マージされたコードを自動でplan・applyするこの運用はGitOpsとも呼ばれ、Kubernetesの宣言的な思想とも深く響き合っています。

落とし穴 — ドリフトと設計の粒度

最大の敵は「ドリフト」、つまりコードの外で加えられた手作業の変更です。障害対応で管理画面から直接設定を変えると、コードと現実がズレ、次のapplyでその変更が黙って巻き戻される事故につながります。「緊急時も含め、変更は必ずコードを通す」という規律をチームで守れるかが、IaCの成否を分けます。

また、すべてを1つの巨大な構成にまとめると、planに時間がかかり、変更の影響範囲も読みにくくなります。ネットワーク・データベース・アプリ基盤といった変更頻度の異なる単位に分割するのが定石です。シークレットや認証情報をコードに直書きしない（stateファイルにも平文で残り得ます）、といったセキュリティ上の注意も欠かせません。導入コストは決して小さくありませんが、「そのインフラを2年後も安心して変更できるか」という問いへの、現時点で最良の答えがIaCです。