8.2 コードとしてのインフラストラクチャと構成

概要と動機

インフラストラクチャ・アズ・コード(IaC)とは、手作業のコンソールのクリックやその場しのぎのスクリプトではなく、機械可読の定義ファイルを通じて、インフラストラクチャ(ネットワーク、サーバー、データベース、ロードバランサー、権限)を定義しプロビジョニングすることです。構成管理は、同じ考えを、システムが存在した後の設定と状態に拡張します。合わせて、それらはインフラストラクチャを、手作りで脆い成果物から、アプリケーションのコードに使うのと同じエンジニアリングの規律による、バージョン管理され、レビュー可能で、再現可能な産物へと変えます。

大きなチームにとって、IaCは便利さではなく必要性です。数百人のエンジニアが環境を必要とし、数千のリソースがリージョンとアカウントにわたって一貫して保たれなければならないとき、手作業のプロビジョニングは追いつけず、正しさも保てません。人間が設定したインフラストラクチャは、遅かれ早かれ、誰も完全には理解せず、障害の後で確実には再構築できない独特の「雪片」サーバーへとずれます。インフラストラクチャを体系化することは、それを一貫し、監査可能で、使い捨てにします。どの環境もその定義から再作成でき、どの変更もレビュー可能な差分です。

企業と政府の組織は、もう一つの決定的な利点を得ます。徹底可能なガバナンスです。保存時の暗号化、ネットワークのセグメンテーション、承認されたリージョン、コスト配分のためのタグ付けのようなセキュリティとコンプライアンスの要件を、コードに直接埋め込み、何かがプロビジョニングされる前に自動的にチェックできます。事後にインフラストラクチャを監査して違反を追いかける代わりに、不適合なインフラストラクチャが存在するのを防ぎます。検知から予防へのこの転換が、IaCが現代のプラットフォームの実践の基礎になった中核の理由です。

主要原則

手順を記述する命令的なスクリプトより、望ましい状態を記述する宣言的な定義を好みます。
すべてのインフラストラクチャの定義をバージョン管理に保存し、他のコードと同様にレビューします。
インフラストラクチャを不変として扱います。その場で変更するのではなく、置き換えます。
プロビジョニングを冪等にし、同じ定義を繰り返し適用しても同じ結果になるようにします。
ドリフト、つまり稼働中の環境が宣言された定義から乖離することを継続的に検知し調整します。真実の源は、稼働中のシステムではなく、コードです。
コピー&ペーストではなく、再利用可能でバージョン管理されたモジュールからインフラストラクチャを構成します。
方針をコード、つまり機械的にチェック可能なコードで表現された組織のルールとして符号化し、ガードレールが助言的ではなく自動になるようにします。
シークレットを定義の外に保ちます。専用のシークレットマネージャーから参照します。

推奨事項

宣言的なツールを選び、モジュールを軸に構造化する

Terraform、Pulumi、あるいはCloudFormationのようなクラウドネイティブの選択肢といった、宣言的なIaCツールを採用し、断片化したツールの状況を避けるために組織全体でそれに標準化します。鍵となるアーキテクチャの実践はモジュール性です。一般的なパターン(準拠したネットワーク、強化されたデータベース、標準のサービス)を捉える、小さく、よく文書化され、バージョン管理されたモジュールを築きます。チームは、生のリソースを書くのではなく、これらのモジュールから環境を構成します。これにより、良い既定とセキュリティ設定が自動的に広がり、重複が劇的に減ります。

状態を意図して管理する

宣言的なツールは、コードと本物のリソースの対応づけを状態ファイルで追跡します。状態を、共有で、暗号化され、アクセス制御されたバックエンドにリモートで保存し、同時の変更が破損させないようロックを使います。状態をノートパソコンに決して保たず、最後の手段の回復行動を除いて手で編集してはいけません。状態はリソースのメタデータとシークレットを含みうるので機微であり、それに応じて保護してください。

ゴールデンイメージで不変のインフラストラクチャを築く

稼働中のサーバーにパッチを当てるのではなく、バージョン管理された「ゴールデンイメージ」(事前に設定され強化されたマシンあるいはコンテナのイメージ)を焼き込み、そこから新しいインスタンスをデプロイします。変更やパッチが必要なときは、新しいイメージを構築して展開し、古いインスタンスを退役させます。これは構成のドリフトを排除し、ロールバックを自明にし、すべてのインスタンスを同一で、既知の良いビルドまでたどれるものに保ちます。自動化されたイメージのパイプラインにセキュリティの強化とスキャンを含めることで、コンプライアンスがイメージの水準で組み込まれます。

構成のドリフトを検知し調整する

ドリフトは、稼働中の環境が定義から乖離したときに起こり、通常は誰かが緊急の手作業の変更をしたためです。実際の状態を宣言された状態と比較し、差異に旗を立てる定期的なドリフト検知を実行します。ドリフトを欠陥として扱います。手作業の変更をそのままにするのではなく、コードを更新して再適用することで調整します。継続的な構成の徹底を必要とするシステムには、ホストを宣言された状態に継続的に収束させる構成管理ツールを使います。

GitOpsとプル型のデプロイを採用する

GitOpsのモデルでは、Gitリポジトリがシステムの宣言された望ましい状態を保持し、対象の環境の内側で動く自動化されたエージェントが、その状態を継続的にプルして、稼働中のシステムをそれに合わせて調整します。これは従来のプッシュのモデルをひっくり返します。環境が自らの設定をプルするので、環境を変えるために外部のシステムが常設の資格情報を必要としません。GitOpsは、完全な監査証跡(すべての変更がコミット)、容易なロールバック(コミットを元に戻す)、強いドリフトの訂正(エージェントが望ましい状態を継続的に再主張)を与えます。Kubernetesと、単一でレビュー可能な真実の源を望む組織で、特に強力です。

ポリシー・アズ・コードでガードレールを徹底する

許可されるリージョン、必須の暗号化、必要なタグ、禁止された公開の露出のような組織のルールを、Open Policy Agent(OPA)のようなツールや、Sentinelのようなプラットフォーム固有のポリシーエンジンを使って、機械的にチェック可能なポリシーとして表現します。プロビジョニングの前にパイプラインでこれらのチェックを実行し、違反が自動的にブロックされるようにします。ポリシー・アズ・コードは、セキュリティチームの意図を、実行可能で一様に適用される統制に変え、手作業のレビューにはできなかった形で、数千の変更にスケールします。

トレードオフ: 長所と短所

選択	長所	短所	最適な場合
宣言的なIaC(Terraform/Pulumi)	再現可能、レビュー可能、ドリフトを検知可能	学習曲線。状態管理の複雑さ	規模のほぼすべてのチーム
命令的なスクリプト	なじみがある。一回限りには柔軟	冪等でない。監査と繰り返しが難しい	狭い、過渡的なケース
不変 + ゴールデンイメージ	ドリフトなし。自明なロールバック	イメージのビルドパイプラインのオーバーヘッド	一貫性を要するフリート
可変な構成管理	きめ細かい継続的な制御	ドリフトのリスク。収束が遅い	レガシーあるいは長寿命のホスト
GitOps(プル型)	強い監査証跡。自己修復	クラスター内のエージェントとGitの規律が必要	Kubernetesとクラウドネイティブ
ポリシー・アズ・コード	自動で一様なガードレール	事前のポリシー作成の労力	規制対象の環境

主な緊張は、柔軟性対制御です。手作業と命令的なアプローチは、単一の変更には速く感じられますが、規模では致命的になる隠れた不整合を蓄積します。宣言的で、不変で、ポリシーに統治されたインフラストラクチャは、より多くの前もっての投資と本物の文化的な転換を求めます。エンジニアが手早いコンソールの変更をやめなければならないからですが、信頼性、監査可能性、何でもオンデマンドで再構築できる能力で、その投資を何倍にも返します。

チームで議論すべき問い

共有のモジュールライブラリを誰が所有し、モジュールの改善はそれを使うすべてのチームにどう届きますか。 モジュールは、修正と強化された既定が伝播する場合にだけ元を取り、それには、全員がコピーするフォルダではなく、明確な所有と本物のバージョニングが必要です。準拠したネットワークと強化されたデータベースのモジュールを誰が保守するか、どうバージョン管理するか(変更履歴を伴うセマンティックバージョニング)、チームが大慌てなしにどうアップグレードをプルするかを決めてください。規模では、これが、誤設定を一度直すことと、手で編集された千のリソースにわたってそれを追いかけることの違いです。証拠を持ち込んでください。今日同じパターンの別々のコピーがいくつ存在するか、セキュリティの修正がすべての環境に届くのにどれだけかかるか、チームがモジュールのバージョンを固定しているか浮かせているか。重大なパッチが資産群全体に数日で届かないなら、モジュール性は見かけだけです。
ドリフト検知の周期は何で、ドリフトが見つかったとき実際に何が起こりますか。 ドリフトは、稼働中の環境が宣言された状態から静かに乖離することで、通常は緊急のコンソールの変更から起こり、それを容認することは、コードを作り話に変えます。実際の状態を宣言された状態と比較する頻度(夜間が妥当な既定)を決め、さらに重要なこととして、対応を決めてください。手作業の変更をそのままにするのではなく、コードを更新して再適用することで調整する。規制対象の設定では、これは統制の要件です。監査人は、宣言された状態が継続的に現実と一致することを必要とするからです。現在の数字を持ち込んでください。毎週いくつのリソースがドリフトし、どれだけ長くドリフトしたままで、それらを閉じる責任を誰かが負っているか。すべてのドリフトを所有者のいる欠陥として扱わなければ、誰もコードを信頼しなくなるまで、真実の源の保証が侵食されます。
GitOpsとプル型の調整に移りましたか。それとも、外部のシステムがまだ本番を変える常設の資格情報を持っていますか。 プルのモデルでは、対象の環境の内側のエージェントが稼働中のシステムをGitに継続的に調整し、それが、どの外部のシステムも書き込みアクセスを持つ必要をなくし、望ましい状態を再主張するのでドリフトが自己修正されます。すべての変更がコミットで、どのオペレーターも本番の常設の資格情報を必要としないので、これは強いセキュリティと監査の姿勢です。コストは本物です。動かすクラスター内のエージェントと厳格なGitの規律なので、現在のプッシュ型の自動化と量ってください。現在本番を直接変更できる人とものの一覧と、それらの変更が残す監査証跡を持ち込んでください。Kubernetesと高保証の飛び地では、この転換は通常価値がありますが、少数の静的なリソースには過剰かもしれません。
インフラストラクチャの状態はどう保存、ロック、アクセス制御され、それが破損あるいは失われた日には何が起こりますか。 状態はコードと本物のリソースの対応づけなので、失われたり損なわれたりした状態ファイルは、ツールを自分が作ったリソースに盲目にし、誰かを破壊的な再適用へと誘惑しえます。大きなチームでは、リスクが倍増します。共有の状態に対して適用する多くのエンジニアは、同時の実行が互いを上書きしないよう、リモートで暗号化されロックされたバックエンドを必要とするからです。一つの大きな状態の利便性を、それが生む影響範囲と量り、単一の間違いがすべてを落とさないよう、環境ごとあるいはドメインごとに状態を分けることを検討してください。事実を持ち込んでください。状態が今日どこに住み、ロックが徹底されているか、誰がそれを読めるか(シークレットを含みうる)、回復をリハーサルしたことがあるか。企業と政府の設定では、状態のバックエンドを、独自のバックアップ、監査ログ、回復のランブックを備えた、機微でアクセス制御される資産として扱ってください。それを失うことは、何が存在するかの記録を失うことだからです。
本物の緊急事態が手作業の変更を求めるとき、認められた緊急用の経路は何で、その変更はどうコードに折り込まれますか。 成熟したIaCの実践はいずれ、パイプラインを待つことが許されない午前3時のインシデントに出会い、誠実な問いは、手作業の変更が起こるかどうかではなく、どう封じ込めるかです。誰がパイプラインを迂回してよいか、何に触れてよいか、その行動がどう記録されるか、変更がコードに調整される、あるいは元に戻されなければならない期限を、事前に決めてください。その合意がなければ、緊急の例外は静かに日常の習慣になり、ClickOpsが裏口から戻ってきます。証拠を持ち込んでください。先四半期に帯域外の変更がいくつ起こり、それぞれがどれだけ調整されないままで、ドリフト検知が実際にそれらを捉えたか。規制対象と公的機関では、自動記録を伴う文書化された緊急用の手順はしばしば統制の要件です。監査人は、緊急事態が可能であることと、それぞれが証跡を残してシステムを宣言された状態に戻すことの両方を期待するからです。
セキュリティとコンプライアンスの基準線のどれだけが、悪い変更を自動的にブロックするポリシーとして表現され、どれだけが、誰かが覚えていることに頼る文書の中のルールですか。 wikiの散文として書かれたガードレールは日常的に違反されます。期限の圧力のもとで、すべてのエンジニアがそれを読んで適用することに依存するからで、同じルールがポリシー・アズ・コードとして表現されれば、不適合な変更はプロビジョニングされる前に拒否されます。大きな組織にとって、これは、セキュリティチームの意図が、レビューのボトルネックにならずに数千の変更にスケールする唯一の方法です。ポリシーを書いて保守する前もってのコストを、手作業のレビューと事後の是正の繰り返すコストと量り、どの統制(暗号化、承認されたリージョン、必須のタグ、公開の露出なし)が、固いゲートとして徹底するほど譲れないかを決めてください。現在の基準線のルールの一覧を持ち込み、どれが自動化され、どれが助言的かに印を付け、それぞれが実際にどれだけ頻繁に違反されるかを加えてください。企業と政府の文脈では、自動化されたポリシーは、監査を、数週間の手作業の証拠収集から、徹底された統制へのクエリに変え、コンプライアンスを検知から予防に変えます。

セクター別の視点

スタートアップ。 速度が勝つので、スタック全体を一つの宣言的なリポジトリに置き(Terraformが一般的な既定)、状態をマネージドで暗号化されたバックエンドに保ち、3人のチームでもすべての変更をプルリクエストに通してください。重いプラットフォームの仕組みは飛ばします。中央のモジュールチームも、まだポリシーエンジンもなく、バージョン管理と、コンソールで決してクリックしない規律だけ。それだけで、お金を節約するために取り壊し、次のデモのために再構築できる、再現可能な環境が得られます。

小規模事業者。 専任のプラットフォームの専門家がいないので、保守できないオーダーメイドのツールを立ち上げるのではなく、クラウドプロバイダーやベンダーがすでにサポートするマネージドなサービスとIaCに頼ってください。実行する人のいないゴールデンイメージのパイプラインを築くより、妥当な既定(暗号化、バックアップ、パッチ適用)が代わりに扱われるホスト型のプラットフォームを買うことを好みます。目標を狭く枠づけてください。障害や去っていく請負業者の後で再構築できるよう、少数の重要なリソースをコードに入れる。

大企業。 中核の問題は、多くのチーム、アカウント、リージョンにわたる一貫性なので、バージョン管理された共有のモジュールライブラリ、リモートでロックされた状態、パイプラインで徹底されるポリシー・アズ・コードに投資してください。中央のプラットフォームチームが強化されたモジュールとガードレールを公開し、プロダクトチームはその内側でセルフサービスし、ドリフト検知が継続的に走るので、数千のリソースが既知の状態に保たれます。モジュールとポリシーを保守する継続的なコストに予算を付けてください。その価値は、修正や強化された既定がどこにでも一度に伝播することから来るからです。

政府。 調達規則、認定、公的な説明責任が、不変のインフラストラクチャ、署名されたコミット、認定された飛び地の内側のGitOpsの調整へと向かわせるので、どのオペレーターも本番を変える常設の資格情報を持ちません。必要なセキュリティの基準線を、ゴールデンイメージとポリシー・アズ・コードに符号化し、コミット履歴に、改ざんが明らかで継続的に利用可能な監査の証拠を務めさせてください。あなたを閉じ込める独自の形式より、オープンで可搬なツールを好み、緊急事態の変更も構成管理の要件を満たすよう、緊急用の手順とその記録を明示します。

事例

スタートアップ。 5人のスタートアップは、AWSの構成全体、VPC、データベース、コンテナサービスを、暗号化されたS3のバックエンドに保たれた状態とDynamoDBによるロックを備えた、単一のTerraformのリポジトリに定義します。すべての変更がプルリクエストを通るので、一人のオンコールのエンジニアでも、applyを実行する前に何が変わるかを正確に見られます。大きなデモのために新しいステージングの環境が必要なとき、小さなモジュールをコピーして数分で立ち上げ、クラウドの請求書を低く保つために同じくらい速く取り壊します。

大企業。 多国籍の小売業者は、複数のクラウドアカウントとリージョンにわたってインフラストラクチャを管理します。中央のプラットフォームチームが、準拠したネットワーク、データベース、サービスの足場のためのバージョン管理されたTerraformのモジュールを公開し、暗号化あるいはコスト配分のタグを欠くリソースを拒否するOPAのポリシーを徹底します。プロダクトチームは自分の環境をセルフサービスでプロビジョニングしますが、すべての変更はポリシーが自動的にチェックされるパイプラインを流れます。ドリフト検知が夜間に走り、手作業の変更にチケットを起票し、数千のリソースを継続的に既知で準拠した状態に保ちます。

政府。 高保証の環境で運用する防衛機関は、必要なセキュリティの基準線を埋め込んだ強化されたゴールデンイメージを築き、それらのイメージから不変のインスタンスだけをデプロイします。すべてのインフラストラクチャはGitで宣言され、認定された飛び地の内側のGitOpsのエージェントによって調整されるので、どのオペレーターも本番を直接変更する常設の資格情報を持ちません。すべての変更は署名されたコミットです。これにより、監査人に完全で改ざんが明らかな履歴を与え、手作業の証拠収集なしに、継続的な監視と構成管理の要件を満たします。

ビジネスケース: 動機、ROI、TCO

IaCのROIは、速度、信頼性、リスクの低減から来ます。かつてチケット駆動の手作業のプロビジョニングで数週間かかった環境が数分で作成でき、それがエンジニアを解放しプロジェクトを加速します。再現性は、どの環境もコードから再構築できるので、障害後の回復時間を削ります。自動化されたポリシーの徹底は、セキュリティインシデントと監査の指摘の頻度とコストを減らし、規制対象の組織にとっては相当なものになりえます。

TCOの帳簿では、採用のコストには、ツール、訓練、モジュールとポリシーのライブラリの構築、手作業の変更をやめる規律が含まれます。採用しないコストはより急で、時間とともに複合します。誰も再構築できない雪片のインフラストラクチャ、遅く間違いやすいプロビジョニング、侵害につながるセキュリティの誤設定、数週間の手作業を消費する監査。リーダーシップには、IaCを、インフラストラクチャを管理されない負債から、統治され再現可能な資産に変えるものとして、そしてセキュリティとコンプライアンスを願望ではなく自動にする仕組みとして枠づけてください。

アンチパターンと落とし穴

本番でのClickOps。 コンソールで手作業で変更することは、ドリフトを保証し、再現性を破壊すること。
コード内のシークレット。 定義ファイルに資格情報をハードコードすると、バージョン履歴と状態に漏れること。
モノリシックでモジュール化されていない定義。 誰も変える勇気のない一つの巨大な設定は、置き換えた手作業のセットアップと同じくらい脆くなること。
管理されない状態。 ローカルあるいはロックされていない状態ファイルは、破損と失われたインフラストラクチャにつながること。
容認されたドリフト。 手作業の変更をそのままにすることは、コードが作り話になるまで真実の源の保証を侵食すること。
文書としてのポリシー。 wikiに住み、自動化されたチェックでないルールは、日常的に違反されること。
コピー&ペーストの増殖。 チーム間で設定を複製することは、修正と改善が決して広がらないことを意味すること。

成熟度モデル

レベル1: 開始。 インフラストラクチャは、コンソールとその場しのぎのスクリプトで手作業でプロビジョニングされます。環境は一貫せず、文書化されず、確実には再現できず、障害からの回復は遅く不確かです。

レベル2: 発展。 一部のインフラストラクチャは体系化されていますが、実践はチームごとに異なります。状態管理は一貫せず、ドリフトは普通で、シークレットが定義に漏れることがあり、ポリシーは、あるとしても手作業のレビューで徹底されます。

レベル3: 標準化。 宣言的なIaCが組織全体の文書化された標準で、管理されたリモートでロックされた状態を伴う、共有のバージョン管理されたモジュールから築かれます。ポリシー・アズ・コードがパイプラインでガードレールを徹底し、シークレットは専用のマネージャーから参照され、ドリフト検知が定期的な周期で走ります。

レベル4: 管理。 実践がベースラインに対して測定されます。ドリフト率と調整までの平均時間、チーム間のモジュールのバージョンの採用、ブロックされた対すり抜けたポリシー違反、プロビジョニングのリードタイム、実際にコードの下にあるリソースの割合を追跡します。これらの指標が変更をゲートし、投資の方向を導くので、決定は逸話ではなく証拠に基づきます。

レベル5: オーケストレーション。 インフラストラクチャは不変でGitOps駆動で、ドリフトに対して自己修復し、コンプライアンスの証拠は自動的に生成されます。モジュールとポリシーのライブラリは本物の使用とインシデントから継続的に改善し、インフラストラクチャの実践はセキュリティ、コスト、デリバリーの計画と統合されているので、要件が移るにつれて資産群全体が適応します。

議論のためのアイデア

中央で統治されるモジュールと、カスタムのインフラストラクチャを定義するチームの自律の間の線は、どこにあるべきですか。
ClickOpsを普通にせずに、パイプラインを迂回しなければならない本物の緊急の変更をどう扱いますか。
多くのアカウントとチームにわたって状態を管理し保護する正しい戦略は何ですか。
可変な構成管理が依然として正当化されるのはいつで、完全に不変なインフラストラクチャが勝つのはいつですか。
ポリシー・アズ・コードのライブラリを、進化するセキュリティと規制の要件とどう揃え続けますか。
IaCより前のレガシーのインフラストラクチャに、現実的な移行の経路はどのようなものですか。

要点

インフラストラクチャを宣言的に定義し、バージョン管理し、レビュー可能で再現可能なコードとして扱います。
良い既定を広げ重複を排除するために、小さなバージョン管理されたモジュールから築きます。
ドリフトを廃止しロールバックを単純にするために、不変のインフラストラクチャとゴールデンイメージを好みます。
状態を意図して管理し、シークレットを定義の外に保ちます。
強い監査証跡と自己修復の調整のために、GitOpsを採用します。
ポリシー・アズ・コードでガードレールを徹底し、コンプライアンスが事後に監査されるのではなく、存在へと予防されるようにします。

参考文献とさらなる読み物

Kief Morris, Infrastructure as Code: Dynamic Systems for the Cloud Age.
Yevgeniy Brikman, Terraform: Up & Running.
Betsy Beyer, Chris Jones, Jennifer Petoff, and Niall Richard Murphy (eds.), Site Reliability Engineering.
Gene Kim, Jez Humble, Patrick Debois, and John Willis, The DevOps Handbook.
Weaveworks, “GitOps” foundational writings (Alexis Richardson et al.).
Open Policy Agent documentation and the Rego policy language.
NIST Special Publication 800-53, security and privacy controls (configuration management family).