インフラがプロダクトである場合：IaCガバナンスとドリフト検出
あなたが数百から数千のサーバーを、複数のクラウドプロバイダーとリージョンにまたがって管理していると想像してください。あなたの会社は、クラウドサービスプロバイダー、大規模なEコマースプラットフォーム、あるいはシンガポール、フランクフルト、バージニアに同時にインフラを展開しているテクノロジー企業かもしれません。
このような環境では、インフラは単にアプリケーションが動作する場所ではありません。インフラこそがプロダクトです。ファイアウォールルールの追加、データベースインスタンスのサイズ変更、ロードバランサーパラメータの微調整など、すべての設定変更が一度に数十のサービスに影響を与える可能性があります。1つの誤った設定が1つのアプリケーションを壊すだけではありません。その共有インフラに依存する何百ものサービスを壊してしまいます。
これは、単一のWebアプリケーションをデプロイする世界とは異なります。リスクはより高く、影響範囲はより広く、エラーの許容範囲はほぼゼロです。
IaCにつながる一貫性の問題
SSHセッションやクラウドダッシュボードを通じて手動でインフラを管理していると、不整合が急速に忍び寄ります。ステージング環境は本番環境とはわずかに異なるファイアウォールルールを持っています。アジアの本番環境はヨーロッパのものとは異なります。現在実際にどの設定が実行されているのか、誰も確信を持って言えません。
これこそが、チームがInfrastructure as Code（IaC）に手を伸ばす瞬間です。すべてのインフラ設定をコードとして記述し、Gitに保存し、パイプラインを通じて自動的に適用します。Terraform、Pulumi、AWS CDK、CloudFormationが主要なツールになります。すべてのサーバー、ネットワークルール、ストレージバケットがバージョン管理で定義されます。
しかし、設定をコードとして記述することは最初のステップに過ぎません。インフラがコードに存在するようになると、新たな疑問が生じます：「すべての変更が本番環境に到達する前に、確実にポリシーに従うようにするにはどうすればよいか？」
IaCガバナンス：官僚主義ではなく自動化されたポリシー
ガバナンスという言葉は、物事を遅くするように聞こえます。実際には、IaCガバナンスはその逆です。すべての変更行を人間が読む必要なく、本番環境に到達する前にすべての変更をチェックする自動化されたガードレールです。
実際の仕組みは次のとおりです。セキュリティチームは、すべてのストレージバケットが暗号化されている必要があると決定します。コンプライアンスチームは、すべてのデータベースインスタンスが特定のインスタンスタイプを使用することを義務付けます。ネットワーキングチームは、ポート22や3306をパブリックインターネットに開放するファイアウォールルールがないことを要求します。
次の図は、コードコミットからデプロイ、ドリフト検出に至る自動化ガバナンスパイプラインを示しています。
これらのルールは、CI/CDパイプライン内で実行される自動化ポリシーとして記述されます。誰かがインフラコードを変更するプルリクエストを送信すると、パイプラインは単に変更を適用するだけではありません。最初にすべてのリソースをポリシーに対してチェックします。変更がポリシーに違反している場合、パイプラインは失敗します。変更は本番環境に到達しません。
例えば、以下はタグ付け標準を強制するシンプルなOpen Policy Agent（OPA）ルールで、すべてのリソースにcost-centerタグが必要であることを要求します。
package terraform
# 'cost-center'タグがないリソースを拒否する
violation[msg] {
resource := input.resource_changes[_]
resource.type in ["aws_s3_bucket", "aws_instance", "aws_db_instance"]
not resource.change.after.tags.cost-center
msg := sprintf("%v %v に必須タグ 'cost-center' がありません", [resource.type, resource.address])
}
このポリシーがCI/CDパイプラインで実行されると、必要なタグがないリソース変更はパイプラインを失敗させ、設定ミスのあるインフラが本番環境に到達するのを防ぎます。
これは、コントロールのために承認ゲートを追加することではありません。問題がインシデントになる前に捉えることです。公開読み取り可能な設定ミスのあるストレージバケットがデータ漏洩になることはありません。小さすぎるデータベースインスタンスがパフォーマンス障害を引き起こすことはありません。ポリシーがパイプラインでそれを捉え、チームはそれが実行される前に修正します。
ドリフト：現実がコードから乖離するとき
IaCはインフラの単一の信頼できる情報源を提供します。しかし、その真実は、実際に実行されているものがコードと一致している場合にのみ保持されます。実際には、この一致は常に崩れます。
ドリフトは、実際のインフラ設定がIaCコードで定義されたものと異なる場合に発生します。誰かがインシデント中にクラウドダッシュボードにログインし、セキュリティグループルールを手動で変更します。チームメンバーが緊急に必要だったため、コンソールを介して直接ロードバランサーリスナーを追加します。別のチームの自動化プロセスが、パイプラインを通さずにリソースを変更します。
ドリフトは、IaCを信頼できないものにするため危険です。コードがサーバーに設定Aがあると言っているのに、現実が設定Bである場合、復旧、スケーリング、または新しい環境の作成は予期しない結果を生み出します。コードが現実と一致しない場合、コードからインフラを再構築することはできません。
ドリフト検出は、実際のインフラ状態をコードと定期的に比較することでこれを解決します。パイプラインは、インフラを適用するために使用するのと同じコマンドを実行しますが、「計画」または「プレビュー」モードで実行します。何も変更しません。単に比較するだけです。差異を見つけた場合、それを報告します。
さらに進めるチームもあります。ドリフトが検出されると、パイプラインは自動的にインフラをコード定義の状態に調整できます。他のチームは、責任者に通知し、コードを更新するか、ドリフトを意図的なものとして受け入れるかを決定させることを好みます。
高リスク変更の処理
一部のインフラ変更は、他のものよりもリスクが高くなります。本番データベース設定の変更、プライマリトラフィックに影響を与えるファイアウォールルールの変更、数百万のリクエストを処理するロードバランサーの変更など、これらには特別な注意が必要です。
これらの変更には、自動化されたポリシー以上のものが必要です。パイプラインの内部で発生し、外部ではない統合承認プロセスが必要です。ワークフローは次のようになります。
- 開発者がインフラ変更を含むプルリクエストを作成します。
- 自動化ポリシーが実行され、違反がないかチェックします。
- ポリシーに合格した場合、パイプラインは関連するレビュー担当者に通知します。データベース変更の場合はDBA、ファイアウォール変更の場合はネットワークエンジニアなどです。
- レビュー担当者は、プルリクエストで直接承認するか、変更を要求します。
- すべての承認が満たされた後にのみ、変更が適用されます。
重要な洞察は、承認が遅くなることを意味しないということです。適切な人が適切なタイミングで、パイプラインで利用可能なすべてのコンテキストを持って適切な変更をレビューすることを意味します。チャットで人を追いかける必要はありません。リリースウィンドウが閉じる前の土壇場での承認はありません。
IaCガバナンスの実践的チェックリスト
- インフラに適用されるすべてのセキュリティおよびコンプライアンスルールに対して自動化ポリシーを記述する
- インフラ変更が適用される前に、パイプラインでポリシーチェックを実行する
- ドリフト検出をスケジュール（リスク許容度に応じて毎日または毎週）で実行するように設定する
- ドリフトを自動修復するか、チームに通知するかを決定する
- 追加の承認が必要な変更と、承認者が誰であるかを定義する
- 承認をパイプラインの一部にし、外部の別プロセスにしない
まとめ
インフラがプロダクトである場合、一貫性と制御はオプションではありません。IaCは基盤を提供しますが、ガバナンスとドリフト検出がその基盤を信頼できるものに変えます。自動化ポリシーは、問題が本番環境に到達する前に捉えます。ドリフト検出は、現実がコードから乖離したときを教えてくれます。そして統合承認により、高リスクの変更がボトルネックになることなく適切な注意を確実に受けられます。
目標はインフラ変更を遅くすることではありません。恐れずに迅速に行動できるほど安全にすることです。