- 625個のTerraformワークスペースと38個のAWSアカウントで、165,000個以上のクラウドリソースを管理
- エンジニア170人のうち40人がインフラ専門
- 毎日225回のインフラリリース（
terraform apply）と723回のプラン（terraform plan）を実行
- そのためにTerraform Cloudを導入し、インフラリリースプロセスを自動化することで、開発者の手作業とミスを削減
Terraform Cloud導入前の課題
- 高いAWSアクセス権限が必要：インフラチームが高レベルのAWSアクセス権限を持つ必要があった
- 時間のかかる作業：各ディレクトリで
terraform applyを実行し、レビューと承認を繰り返す必要があり、1回の変更が120個以上のワークスペースに影響することもあった
- インフラドリフトの発生：想定外の変更が蓄積し、適用時に追加のレビューや対応が必要になった
Terraform Cloud導入と効果
- ドリフトの解消 → インフラドリフトを解消し、リスクと開発者の負担を軽減
- 開発者時間の節約 → 年間約8,000時間の開発者時間を節約（開発者4人分の業務量に相当）
- 変更の追跡が可能 → 監査ログを通じて変更を追跡でき、デバッグも容易
- スペキュラティブプランをサポート → 変更を自動テストし、結果をGitHub CIで直接確認可能
現在のTerraform Cloud運用方式
- セルフホスト：Terraform Cloud for Businessを自前で導入し、AWSアカウント内のECSクラスターでTFCエージェントを運用
- エージェントプール構成：120台のエージェントを**開発環境（40台）と本番環境（80台）**に分けて運用し、高い同時実行性を維持
重点的に監視している要素
- エージェント枯渇と同時実行数の制限 → エージェント不足時はオンコール担当者に通知
- プラン時間 → 開発環境でプラン時間が4分を超えた場合はチームに通知
- インフラドリフト → 現在は測定していない（ドリフトがほとんど発生しないため）
品質向上のための最適化
- TFC CLIの開発：複数のワークスペースにまたがる変更をCLIで自動レビュー・承認できるようにした
- 通知システムの構築：Slack通知を通じてTerraformの適用漏れが起きないよう自動化
- ワークスペースの自動管理：Terraformを使って625個のワークスペースを管理し、タグを適用して所有チームを区別
- Terraform Cloud利用状況の分析：TFC APIを活用してステートバージョンデータを収集し、リソース使用量と成長傾向を把握
- Terraform Stateのバックアップ：障害発生時に復旧できるよう、ステートファイルをS3バケットに自動バックアップ
- ワークスペース依存関係の管理：モジュール依存関係ツリーを作成し、ワークスペースが監視すべきディレクトリを自動設定
- プロバイダーアップグレードの自動化：Dependabotを活用してプロバイダーを月次でアップグレードし、自動化によって管理負担を軽減
今後の改善点
- 段階的ロールアウト：
mainブランチベースのリリースから、**多段階デプロイ（開発 → ステージング → 本番）**方式へ移行
- 大規模ワークスペースの分割：現在の625個のワークスペースを1500個以上に細分化し、プランおよび適用時間を短縮しつつ変更の影響範囲を縮小する方針
- 通知機能の改善：Slack通知に再割り当て機能を追加し、
tfc reviewコマンドの自動生成機能を導入
- エージェントのオートスケーリング：EKSベースのオートスケーリングシステムを導入し、変動するワークロードを効率的に処理する計画
- 自社開発ツールのオープンソース化：社内で開発した各種ツールをオープンソースとして公開し、他チームでも活用できるようにする計画
まだコメントはありません。