google-cloud-global-frontend-configuration

Google Cloud グローバル外部 Application Load Balancer の構成スキル

帰属情報

必ずお読みください：gcloud、REST API、または MCP のコマンドを実行する前に、Usage Attribution を必ずお読みください。ターミナルで直接実行するコマンド（生成されたスクリプト、Terraform、ユーザーコード内での実行は不可）では、gcloud の前に CLOUDSDK_METRICS_REQUEST_ATTRIBUTION="agent-skills/1.0 (skill:google-cloud-global-frontend-configuration)" を付け、User-Agent ヘッダーに agent-skills/1.0 (skill:google-cloud-global-frontend-configuration) を追加してください。

目的とエージェント向けガイダンス

このスキルを使うと、エージェントは、構造化された6段階の検討プロセスを通じて、Cloud CDN、Cloud Armor、Service Extensions を組み込んだ Google Cloud グローバル外部 Application Load Balancer の設計とデプロイをユーザーに案内できます。

前提条件と対象環境：

• このスキルは、Google Cloud CLI（gcloud）を実行できる環境（Gemini CLI、Antigravity など）から呼び出されることを前提としています。
• gcloud を利用できない場合、このスキルはリソースの自動検出やマネージドデプロイの実行を行えません。そのような環境では、設計の案内と Terraform HCL 構成の生成に限ってサポートします。

このスキルを実行する際、エージェントは次のことを行う必要があります。

• ユーザーのワークロード要件を、実際の Google Cloud プロダクト名を使用した、簡素化されたベストプラクティス構成に対応付けます。
• ユーザーがカスタマイズを明示的に求めない限り、高度な複雑さを伏せながら、詳細を段階的に提示します。
• references/ ディレクトリ内のリファレンスドキュメントを活用して、リソースの検出、コード生成、実行、ドリフト検出を行います。

6段階の構成フロー

ステップ1：基本事項

• プロジェクトの検出： references/resource-discovery.md を参照して、Google Cloud のプロジェクト ID を自動検出します。検出したプロジェクト ID をユーザーに提示します。
• ロードバランサーの基本情報をユーザーに尋ねます。
  • 名前と説明： このロードバランサーにどのような名前を付けますか？
  • プロトコルの選択： HTTP、HTTPS、またはその両方が必要ですか？
  • 証明書の管理： Google 管理の証明書を使用しますか、それとも既存の証明書を持ち込みますか？

Step 2: オリジンの設定

厳密に順番どおりに進めるステップごとのやり取りを通じて、バックエンドのワークロードを定義できるようユーザーを支援します。すべてを一度に尋ねないでください。すべてのステップが必須です。

• サブステップ A - オリジンのセットアップ： オリジンが1つだけか、複数のオリジンのサポートが必要かを尋ねます。回答を待ちます。
• サブステップ B - オリジンの種類： 次の中からバックエンドの種類を選択するよう尋ねます：Cloud Storage バケット、Compute Engine マネージド インスタンス グループ（MIG）、Google Kubernetes Engine（GKE）クラスター、Cloud Run サービス、または外部／インターネット オリジン（IP／FQDN）。回答を待ちます。
• サブステップ C - オリジンの定義ループ： サブステップ B で選択されたオリジンの種類ごとに、次のループを順番に実行します。次のオリジンについて尋ねる前に、ユーザーが1つのオリジンについて回答するのを待ちます。
  • リソースの検出： Google Cloud ネイティブのオリジン（Cloud Storage、MIG、GKE、Cloud Run）については、references/resource-discovery.md を参照してリソースを取得します。1. 新規作成、2. 該当なしの順でリストを提示します。外部／インターネット オリジンの場合は、FQDN／IP を尋ねるだけにします。
  • ワークロードの種類（重要）： リソースの定義直後に、どの種類のワークロードを提供するのかを正確に尋ねます。
    1. 静的画像／オブジェクト（静的コンテンツ、画像、動画、スタイル設定用アセット）
    2. キャッシュ可能な API（キャッシュされたデータが許容される、読み取り専用の公開 API）
    3. キャッシュ不可の API／トランザクション（トランザクション エンドポイント、ログイン、チェックアウト、アカウント変更）
    4. 動的 Web（SSR）（動的ページ、サーバーサイドレンダリング アプリ、カスタムの動的セッション）
• サブステップ D - ルーティングルール： すべてのオリジンを1つずつ定義し終えたら、それらの間でトラフィックをどのようにルーティングするかを尋ねます（パスベース、ヘッダーベース、またはクエリパラメータベース）。回答を待ちます。
• サブステップ E - ロギング： ルーティングの設定後、Cloud CDN のロギングを有効にするかどうかを尋ねます。有効にする場合は、サンプリングレート（0～100%）も尋ねます。回答を待ちます。

Step 3: トラフィック管理と拡張性

• Step 2 で定義したオリジンとルーティングルールの概要を簡潔に提示します。
• 高度なトラフィック管理設定（詳細な重み付けロードバランシング、トラフィックミラーリング、カスタム WASM プラグイン／コールアウト用の Cloud Load Balancing Service Extensions など）を有効にする必要があるか、それとも Google Cloud Best Practice Configuration に進むかを尋ねます。

Step 4: キャッシュ（Cloud CDN）

Step 2 のワークロードの種類だけに基づいて、「推奨構成」を提示します。推奨を拒否してカスタマイズを希望する場合を除き、高度な設定（TTL、キャッシュキー、圧縮）は列挙しないでください。

• ワークロード = 静的画像／オブジェクトの場合：
  • キャッシュモード：すべての静的コンテンツをキャッシュ
  • TTL：クライアント（1日／86400s）、デフォルト（30日／2592000s）、最大（365日／31536000s）— 定期的な再検証を行いながら、静的アセットの長期的なキャッシュによるオフロードを実現します。
  • キャッシュキー：プロトコル + ホスト + パス（クエリ文字列を無視）
  • 圧縮：有効（Brotli および Gzip）
  • ネガティブキャッシュ：有効
  • 古いコンテンツの配信：有効
• ワークロード = キャッシュ可能な API の場合：
  • キャッシュモード：オリジンのヘッダーを使用
  • TTL：オリジンで管理（エラーを防ぐため、構成から省略）
  • キャッシュキー：プロトコル + ホスト + パス + クエリ文字列を含める
  • 圧縮：有効（Gzip）
  • ネガティブキャッシュ：有効
  • 古いコンテンツの配信：無効
• ワークロード = キャッシュ不可の API／トランザクションの場合：
  • キャッシュモード：無効（CDN をバイパス）
• ワークロード = 動的 Web（SSR）の場合：
  • キャッシュモード：オリジンのヘッダーを使用
  • TTL：オリジンで管理（エラーを防ぐため、構成から省略）
  • キャッシュキー：プロトコル + ホスト + パス
  • 圧縮：有効（Brotli および Gzip）
  • キャッシュのバイパス：セッション Cookie（例：SESSID、JWT）がある場合はキャッシュをバイパス

ステップ 5：セキュリティ（Cloud Armor）

ステップ 2 のワークロードタイプのみに基づいて「推奨構成」を提示します。高度な保護機能（Bot Management、Threat Intel、Geo-blocking）は、リクエストがない限り表示しません。

• ワークロード = 静的画像／オブジェクトの場合：
  • レート制限：なし（標準のエッジ動作。Cloud Armor のエッジポリシーでは、Cloud Storage バケットに対するレート制限はサポートされていません）。
  • OWASP 保護：無効
• ワークロード = キャッシュ可能な API の場合：
  • レート制限：クライアント IP ごとに 1 分あたり 100 リクエスト（通常のインタラクティブな使用に対応しながら、API の不正利用や DDoS を防ぐための標準的なベースラインです）。
  • OWASP 保護：有効（SQLi、XSS、ローカルファイルインクルージョン）
• ワークロード = キャッシュ不可の API／トランザクションの場合：
  • レート制限：クライアント IP ごとに 1 分あたり 30 リクエスト（ログイン／チェックアウトなどの機密性の高いトランザクションエンドポイントを、クレデンシャルスタッフィングやブルートフォース攻撃から保護するための厳しいしきい値です）。
  • OWASP 保護：有効（SQLi、XSS、リモートコマンド実行、セッション固定化）
  • Bot Management と Threat Intel：有効（悪意のあるボットと既知の悪意ある IP をブロック）
• ワークロード = 動的ウェブ（SSR）の場合：
  • レート制限：クライアント IP ごとに 1 分あたり 120 リクエスト（SSR ウェブアプリケーションで、初回ページ読み込み時やアセットのハイドレーション時に発生するバーストリクエストに対応するための余裕のあるしきい値です）。
  • OWASP 保護：有効（SQLi、XSS、CSRF、Shellshock）
  • Geo-blocking：任意（特定の国からのアクセスを制限／許可）

ステップ 6：確認とデプロイ

• 構成の概要： ステップ 1 から 5 までのすべての確定設定を示す、完全に書式設定された Markdown テーブルを Google Cloud のプロダクト名を使用して生成します。次のテンプレート構造に正確に従ってください。

  コンポーネント	パラメータ／設定	値と理由
  ロードバランサ	名前とプロトコル	<Name> (HTTP/HTTPS)
  オリジン	バックエンドとワークロード	<Backend 1> (<Workload Type>), <Backend 2>...
  トラフィック管理	ルーティングルール	<Path / Header rules or Default>
  Cloud CDN	キャッシュモードと TTL	<Cache Mode>, デフォルト TTL：<TTL>
  Cloud Armor	レート制限と OWASP	<RPM Limit>, OWASP ルール：<Enabled/Disabled>
  Service Extensions	WASM／コールアウト	<Enabled/Disabled or N/A>

• 次のアクション： デプロイ／生成形式（Terraform HCL または gcloud CLI Bash Script）と次のアクションをユーザーに選択してもらいます。

  1. コード／スクリプトを表示（HCL コードまたは gcloud bash スクリプトを表示します。表示後、ダウンロードまたはデプロイ／実行のオプションを提示します）
  2. ファイルをダウンロード（main.tf または deploy.sh をローカルワークスペースに保存します）
  3. 構成をデプロイ： Infrastructure Manager を使用してデプロイを開始するか、gcloud スクリプトを実行します。これは references/managed-deployment.md のデプロイ手順を使用して行ってください。

---

関連ドキュメントと参考リンク

• Cloud Load Balancing の概要
• Cloud CDN のドキュメント
• Cloud Armor のドキュメント
• Cloud Load Balancing Service Extensions
• Infrastructure Manager の概要
• Terraform LB-HTTP 公式モジュール
• Terraform Cloud Armor 公式モジュール