Google Cloud Next’24 にて行われたセッション「Multi-project, multi-runtime, multi-region infrastructure as code」のレポートです。
Google Cloud Next’24 とは
2024 年 4 月 9 ～ 11 日にラスベガスのマンダレイベイで開催されている、Google Cloud が主催する最大級規模のイベントです。
https://cloud.withgoogle.com/next/
登壇者
HashiCorp Developer Advocate
Rosemary Wang 氏
セッション内容
IaC への取り組み
基本的な概念
- マルチプロジェクト
- チームメンバーとインフラストラクチャーを共有することが可能
- 進化のためのリファクタリングを考える必要がある
- プラットフォームのインフラストラクチャーが必要になる
- マルチスレッド
- オリジナルの形状や既存のシステムが存在し、それらをインフラストラクチャーコードで管理する必要がある
- ランタイムやアーキテクチャの追加が必要
- マルチリージョン
- インフラストラクチャーを複数のリージョンにデプロイする必要がある
- プラットフォームの機能が必要
- マルチクラウド
- クラウドは複雑であり、複数のクラウドプロバイダーを考慮する必要がある
- クラウド環境の設計に注意が必要
基本原則
- 依存性注入
- 上流のリソースから属性を取得する仕組み
- サーバーなどのリソースが必要な情報を取得する
- 以下の例では network のデータリソースを上に分けて取得させている
- アトミックな変更
- インフラストラクチャーの変更は原子的であるべき
- 大規模な変更ではなく、小さな変更を行う
- 環境の分離
- 開発、テスト、本番などの環境は分離する
- 異なる環境での変更が影響しないようにする
- サービスアカウントの導入
- 各層ごとにサービスアカウントを実装する
- 最小限の権限でリソースを作成する
プロジェクトのデプロイ
- 1.Bootstrap
- インフラストラクチャの初期化
- 共有リソースの構築
- 組織ポリシーやネットワーキングの設定
- 2.共有リソース
- ロギング、シークレット管理、ネットワーキングなどの共有リソースのデプロイ
- 3.環境リソースの挿入
- 開発、ステージング、本番環境などの環境リソースの挿入
- 4.ランディングゾーン
- プロジェクトのセットアップや基本インフラストラクチャの構築
- 開発者やデータサイエンティスト向けのセルフサービスモデル
- 5.ランタイム
- Dev と Prod のプロジェクトを区別し、必要なランタイムリソースをデプロイ
- 以下の例のように環境ごとにモジュールを分ける
- これらの手順により、インフラストラクチャーコードの進化を促進し、柔軟性と拡張性を実現する
マルチ環境の方針
- マルチプロジェクト
- Google Cloud に固有のものであり、課金が正確であり、ビジネスを孤立したサンドボックスで作業できるようにする
- ランタイムはインフラリソースをサービスの実行に割り当てるものであり、ビジネスドメインごとに分割する
- マルチリージョン
- リージョン間でのトラフィックのルーティングの適切な処理や冗長性を重視する
- マルチクラウド
- 複数のクラウドプロバイダー間のインターフェースの標準化を目指す
感想
マルチ環境における IaC の構造のベストプラクティスについて解説されていました。
環境ごとにリソースタグを分けたり、サービスアカウントを最小権限で構成することについては意識していたのですが、ランタイムごとのモジュール分離や共有リソースを元にした IaC 設計にも今後は着目したいと思います。
また、マルチプロジェクトやマルチクラウドといった状況はまだ経験していないため、どのような観点に気をつけて設計すれば良いか大変勉強になりました。
