Infrastructure as Code（）は環境再現性の要。本記事では主要 4 ツールを比較し、データ基盤での使い分けを提示します。
1. なぜ IaC が必要か
- 再現性: 同じ環境を何度でも作れる (dev / staging / prod)
- 変更履歴: Git で誰が何を変えたか追える
- レビュー: PR でインフラ変更をレビューできる
- ロールバック: 問題があれば前バージョンに戻せる
- ドキュメント代わり: コード自体が現状を表す
2. 4 ツール比較
| ツール | 言語 | 強み | 向くケース |
|---|---|---|---|
| Terraform | HCL | 業界デファクト、エコシステム | マルチクラウド |
| OpenTofu | HCL | Terraform fork、Apache 2.0 | ライセンス重視 |
| Pulumi | TS/Python/Go/C# | プログラミング言語の力 | ロジカル分岐多い |
| CDK | TS/Python | AWS 統合最強 | AWS 専業 |
| SST | TypeScript | Next.js 連携、サーバーレス | Next.js + AWS |
3. データ基盤での使い分け
- （ / ）：Terraform が定石
- Storage（ / GCS）：Terraform、Pulumi も可
- IAM / 権限：Terraform、変更履歴の追いやすさ重視
- Lambda / Cloud Functions：CDK / SST が楽
- ：Helm + Terraform が定石
4. tfstate 管理のベストプラクティス
S3 + DynamoDB ロック (定番)
Code
terraform { backend "s3" { bucket = "my-terraform-state" key = "prod/terraform.tfstate" region = "ap-northeast-1" dynamodb_table = "terraform-locks" encrypt = true }}5. CI/CD への組込み
- PR 時: `terraform plan` を自動実行、差分を PR コメントに
- main マージ時: `terraform apply` を自動実行 (本番は手動承認推奨)
- Atlantis: PR コメントで `atlantis plan` のような対話運用
- Spacelift / env0 / Terraform Cloud: マネージド runner、ロック管理込み
6. よくある落とし穴
- 手動変更との差分: 誰かがコンソールで変更すると、次の plan で破壊的変更が出る
- state ファイルの破損: バックアップ必須 (S3 のバージョニング有効化)
- tfstate の競合: 複数人同時 apply はロック必須
- 機密情報: tfstate に DB パスワード等が平文で入る → 暗号化 + アクセス制限
- module の循環参照: 設計時に依存関係を明確に
ふくふくの進め方
IaC 化されていないインフラの棚卸しから、段階的 Terraform 化を 1〜2 ヶ月で。既存リソースの import → 新規変更を tf 経由に → 全体 IaC 化、の流れ。
次回予告
EP.07 はローカル開発環境を綺麗に保つ道具：mise / direnv / 。
この記事の感想を教えてください
あなたの 1 クリックで、本当にこの記事は更新されます。「もっと詳しく」「続編希望」が一定数集まった記事は、 ふくふくが 実際に内容を拡充したり続編記事を公開 します。 送信したリアクションはお使いのブラウザに記録され、再カウントされません。