すべてのコードではなく変更内容のみを実行: Cloud Build による IaC デプロイの最適化
Google Cloud Japan Team
※この投稿は米国時間 2022 年 2 月 5 日に、Google Cloud blog に投稿されたものの抄訳です。
多くの場合、Infrastructure as Code（IaC）はクラウド リソースの大規模なデプロイに使用され、ソース コントロール リポジトリに保存されます。マルチフォルダのリポジトリを使用すると、同様の IaC を単一のリポジトリに結合できます。メリットは次のとおりです。
複数の CI / CD パイプラインを管理するオーバーヘッドの削減
コードの可視性の向上
類似コードの複数の ACL を管理するオーバーヘッドの削減
また、CI / CD パイプラインを使用して、上記のリポジトリ内に IaC をデプロイすることも少なくありません。この投稿では、パイプラインの前回の実行から変更された内容のみをデプロイして IaC パイプラインを最適化する方法について説明します。この方法でパフォーマンスが向上し、コストが削減されます。
マルチフォルダ IaC リポジトリの例:
ビジネスへの影響
この投稿で説明するアプローチでは、次のメリットが想定されます。
ビルドの高速化: 変更された内容のみを実行するため。
デベロッパーの生産性向上: IaC パイプラインのフィードバック サイクルを高速化できるため、デベロッパーのアジリティを向上させることが可能です。
コストの最適化: ビルド時間を短縮することで、IaC パイプラインのコストを削減できます。
開始方法
Terraform といった IaC のマルチフォルダを含むクラウドソース リポジトリ（またはその他のソース コントロール リポジトリ）が必要になります。
また、ブランチへの push イベントベースのトリガーを使用した Cloud Build パイプラインも必要になります。
現在使用されている一般的なアプローチ
マルチフォルダ IaC リポジトリでは、すべてのフォルダを反復処理して IaC をデプロイする必要があります。上記リポジトリの例では、Cloud Build パイプラインの手順の 1 つは次のようになります。
このアプローチでは、前回の commit 変更による影響を受けるのが 1 つのフォルダだけの場合も、リポジトリのすべてのフォルダでコードを実行する必要があります。このアプローチには、次のようなデメリットがあります。
コードデプロイ ステータスのフィードバックが遅くなることで、デベロッパーのアジリティに悪影響が出る
ビルド時間が長くなるため、IaC パイプラインを実行する運用コストが高くなる
選択的デプロイ
このアプローチでは、前回 IaC パイプラインのデプロイが成功した後に変更された IaC のみを実行します。
ソリューション設計
次の手順は選択的デプロイの高度なソリューション設計です。
前回成功したビルド: 前回成功した Cloud Build の実行を見つける必要があります。
差分コンピューティング: 前回パイプラインのデプロイに成功した後に影響を受けているフォルダを見つける必要があります。
実行: 最後に、差分コンピューティングの手順で取得したフォルダに IaC コードをデプロイできます。
実装手順
手順 1: 前回成功したビルドに関連付けられている commit を見つける
この手順では、前回成功したビルドを見つけるために gcloud コマンドの「gcloud builds list」を使用します。以下のサンプルコードのフィルタでは、1 つの Cloud Build トリガーに対して成功した commit のみをフェッチしていることに注目してください。
イベントベースの Cloud Build トリガーを使用し、イベントでコードをリポジトリに push する場合、このビルドは 1 つの commit と関連付けられます。したがって、「gcloud builds describe」コマンドを使用して、特定の Cloud Build の実行に関連付けられた commit を取得できます。
手順 2: 前回 commit に成功した後に変更されたフォルダを見つける
「git diff」コマンドを使用して、前回成功したビルドに関連付けられた commit（手順 1）と現在のビルド実行に関連付けられた commit の違いを見つけることができます。
差分出力をログファイルに保存し、次の手順で使用できます。監査のため、ビルドの完了後にこのログファイルを Cloud Storage バケットに保存することもできます。
手順 3: 変更されたフォルダを反復処理する
これで、手順 2 の git diff 出力からフォルダを反復処理し、コードを実行できるようになりました。
注意事項 / エッジケース
ビルドにリポジトリの履歴を含める
Git リポジトリでソースをビルドするために、Cloud Build はリポジトリのシャロー クローンを実行します。つまり、ビルドを開始した単一の commit だけが、ビルドするワークスペースにチェックアウトされます。これにより、変更されたフォルダを見つけるために必要な「git diff」操作が実行できなくなります。こちらで説明されている手順を行って、リポジトリのビルド履歴を含める必要があります。
前回成功したビルドが存在しない
ビルド履歴で少なくとも 1 つのビルドが成功している必要があります。選択的デプロイを使用せずにパイプラインを実行して、最初に成功したビルドを取得します。
入力としての手動 commit
「git diff」を計算するには、特定の commit を手動で渡すことが必要になる場合があります。この機能は、エラーから回復するために最近のビルドをいくつか再実行する場合に役立ちます。
一元化モジュールが変更されたら、フォルダまたはフォルダのサブセットをすべて実行する
Terraform モジュールのような一元化されたフォルダがリポジトリにある場合があります。一元化されたフォルダのレベルで変更が行われた場合、すべてのフォルダを実行する必要があります。
標準的な例
- 戦略的クラウド エンジニア Maitreya Mulchandani
- 戦略的クラウド エンジニア Venkata Ponnam
