脱・ローカルステート：Terraformにおける「安全」と「高速」の境界線
「TerraformのローカルステートをGit管理している」。もしあなたのチームがまだそんな前時代的な運用をしているなら、今日で終わりにするべきだ。
Terraformのステートファイル（`terraform.tfstate`）は、単なる設定ファイルではない。クラウド上の実環境とあなたのコードを繋ぐ「真実のソース（Single Source of Truth）」だ。これをローカルに置くことは、時限爆弾を抱えて運用するに等しい。
今日は、SREの現場で「当たり前」とされているS3バックエンド＋DynamoDBロックの構成を、ただ実装するだけでなく、チームの生産性を極限まで高めるための「プロの作法」として伝授する。
—
1. なぜ「ローカルステート」がエンジニアを殺すのか
ローカルステートには以下の3つの致命的な欠陥がある。
1. 競合の温床: メンバーAとBが同時に`terraform apply`を実行すれば、容易にステートが破損し、整合性が失われる。
2. 機密情報の漏洩: ステートファイルには、データベースのパスワードやシークレットキーが「平文」で含まれる可能性がある。Gitにプッシュした瞬間、それは世界中に公開されたことになる。
3. 属人化: 「誰のローカルPCにある環境が最新か？」を追いかける不毛な時間は、開発スピードを劇的に低下させる。
—
2. 実践：S3 + DynamoDBによる堅牢なバックエンド構成
以下のコードは、バックエンドを抽象化し、チーム全体で安全に共有するための標準的なテンプレートだ。
backend.tf
terraform {
backend “s3” {
# バケット名は環境やプロジェクトごとに一意にする
bucket = “my-app-terraform-state-prod”
key = “network/terraform.tfstate”
region = “ap-northeast-1”
# 【重要】排他制御用のDynamoDBテーブル
# これにより、同時実行によるステート破壊を物理的に防ぐ
dynamodb_table = “terraform-lock”
# 通信の暗号化
encrypt = true
}
}
プロのヒント：バックエンドの動的設定
`backend`ブロック内で変数は使えない。環境ごとにバケットを切り替える場合、無理にコードを分けるのではなく、実行時に`-backend-config`オプションを使うのが「大人の作法」だ。
実行例：環境依存の設定を分離する
terraform init -backend-config=”bucket=my-app-terraform-state-dev”
—
3. 開発スピードを加速させる「神プラグイン」と設定
Terraformのコードを書く際、IDEは最強の武器になる。VS Codeを使っているなら、以下の構成は「必須」だ。
おすすめプラグイン
- HashiCorp Terraform (公式): 言うまでもない。LSP（Language Server Protocol）が神レベルの補完を提供してくれる。
- TFLint: Terraformの「静的解析」ツール。AWSの推奨インスタンスタイプや、リソースの依存関係のミスを`plan`する前に検知する。CIに組み込むのが鉄則。
- Terraform DocGen: 自動で`README.md`に変数表を生成する。ドキュメントを書く時間を0にせよ。
隠れたキーボードショートカット (VS Code)
- `Shift + Alt + F`: Terraformコードのフォーマット。チーム内で `terraform fmt` を強制し、コードスタイルを統一する。
- `Ctrl + Space`: リソースの補完。プロはキーを叩く回数を極限まで減らす。
—
4. チームで守るべき「3つの鉄則」
ツールを導入しても、運用がズボラなら意味がない。以下のルールをチームの憲法に加えろ。
1. `plan`の結果を必ずCIで共有する:
手元で`apply`するな。GitHub Actions等のCI上で`terraform plan`を実行し、その結果をPRのコメントとして投稿させる仕組みを構築せよ。
2. ステートには触らない:
「ステートがずれたから直接編集する」という禁じ手は、最終手段だ。可能な限り `terraform import` や `terraform state rm` を使い、常にコードとリソースを同期させ続けろ。
3. モジュール化による責務の分離:
1つの巨大な`main.tf`は悪だ。ネットワーク、DB、アプリ層でディレクトリを分け、ステートを分割せよ。これにより、万が一ステートが破損しても被害を最小限に抑えられる。
—
最後に：IaCは「手段」であり「目的」ではない
あなたが目指すべきは、「Terraformのコードを完璧に書くこと」ではない。「何度でも、安全に、自動でインフラを再現できる環境を作ること」だ。
今回紹介したS3 + DynamoDBの構成は、そのための「土台」に過ぎない。この土台の上に、CI/CDによる自動デプロイ、Policy as Code（SentinelやOPA）によるガバナンス、そして疎結合なモジュール設計を積み重ねることで、初めて「真のSRE」の領域が見えてくる。
さあ、今すぐローカルの`terraform.tfstate`を削除し、クラウドへ移行せよ。それが、あなたのチームが「伝説的なインフラ」を構築する第一歩だ。