Service Extensions

解決する課題

ロードバランサが処理するリクエスト／レスポンスに、自前のロジックを挟み込みたい、というのが核心です。従来はバックエンドのアプリやサイドカープロキシを改修して実現していた処理を、ロードバランサの処理経路そのものに差し込めるようにします。

• ヘッダの追加・削除・書き換えを、バックエンドに手を入れずロードバランサ側で完結させたい
• 認証・認可の判定を外部サービスへ委譲し、アプリ本体から認可ロジックを分離したい
• カスタムなエラーページへのリダイレクトや、リクエスト内容に応じた動的なルーティングを実装したい
• 特定の通信内容をカスタムログとして記録し、監査やデバッグに使いたい
• これらを Envoy の設定を直接いじったり、独自プロキシを運用したりせずに済ませたい

要するに「ロードバランサのデータ処理経路に拡張ポイントを公式に開放する」のが Service Extensions です。

主要概念と用語

• プラグイン（Plugins）: WebAssembly（Wasm）でロジックを書き、Google マネージドのサンドボックス上で実行する形態。リクエスト／レスポンス経路に近い場所で動き、起動が速く軽量。Proxy-Wasm の ABI に従う。外部サーバを用意せずに済むサーバーレス的な拡張
• コールアウト（Callouts）: ロードバランサから外部の gRPC サーバを呼び出す形態。サーバはユーザー管理のコンピュート（VM、GKE、ハイブリッド接続経由のオンプレミスなど）上で動かす。任意のコードと状態を持てる柔軟な拡張
• トラフィック拡張（Traffic Extension）: 主要な拡張ポイント。リクエスト／レスポンスのヘッダとボディを処理できる
• ルート拡張（Route Extension）: ルーティング決定の前段で働く拡張。ヘッダのみを扱い、振り分け先の選択などに使う
• 認可拡張（Authorization Extension）: アクセス可否の判定を外部に委譲する拡張。ヘッダを見て許可／拒否を返し、ボディは転送しない
• ext_proc / ext_authz: コールアウトが用いる Envoy のプロトコル。ext_proc（External Processing）が既定で、ボディも扱える。ext_authz は認可拡張専用
• 処理フェーズ（イベント）: リクエストヘッダ、リクエストボディ、レスポンスヘッダ、レスポンスボディなど、経路上のどの段階で拡張を呼ぶかを指定する

仕様・制限・クォータ

• 対応ロードバランサ: 主に Application Load Balancer（L7） が対象。グローバル外部・リージョン外部・リージョン内部など複数のタイプで利用できるが、対応する拡張の種類はロードバランサのタイプによって異なる。Media CDN など一部プロダクトでも利用が広がっている
• プラグインの実行制約: Wasm サンドボックスで動くため、できることは限定される。重い計算や任意の外部接続には向かず、ヘッダ操作など軽量な処理が前提。実行時間やメモリに厳しい制約がある
• コールアウトの責任分界: 呼び出される gRPC サーバはユーザー側で運用・スケール・冗長化する必要がある。ロードバランサはあくまで呼び出す側
• 拡張ごとの扱える範囲: トラフィック拡張はヘッダ＋ボディ、ルート拡張と認可拡張はヘッダ中心、という違いがある
• ロードバランサあたりの拡張数や、コールアウトのタイムアウト・ボディサイズなどに上限がある。規模の大きい構成では事前にクォータと制限を確認する

具体的な上限値はリージョンやロードバランサの種類により変わるため、最新値は公式ドキュメントで確認してください。

内部の仕組み

Service Extensions は、Google のロードバランサ基盤（Envoy ベースのデータプレーン）に拡張の呼び出し点を設けることで実現されています。リクエストやレスポンスが処理経路を流れる途中で、指定したフェーズで拡張へ制御が渡ります。

• プラグインは Wasm モジュールとしてデータプレーンの近くで実行される。Proxy-Wasm の ABI 経由でヘッダなどにアクセスし、書き換え結果を経路に反映する。Google マネージドのサンドボックスで隔離され、起動が速い
• コールアウトは、データプレーンが ext_proc（または認可向けの ext_authz）の gRPC を、ユーザー管理のバックエンドへ発行する。バックエンドはヘッダ／ボディを受け取り、変更指示や許可／拒否を gRPC で返す
• どちらの形態でも、ロードバランサ本体や背後のアプリを改修せずに、処理経路に処理を挿入できるのが本質。Envoy の拡張機構（external processing / external authorization）を、マネージドな形で安全に開放したものと捉えると分かりやすい

設計パターン / ベストプラクティス

• ヘッダ追加・正規化・カスタムエラーページへのリダイレクトなど軽量処理はプラグインで実装し、外部サーバの運用を避ける
• 外部 ID プロバイダや独自ポリシーに基づく**認可は認可拡張（コールアウト）**へ寄せ、アプリ本体から認可ロジックを切り離す
• コールアウトのバックエンドは複数インスタンス＋ヘルスチェックで冗長化し、拡張がロードバランサ全体のボトルネックや単一障害点にならないようにする
• 拡張はリクエスト経路上の同期処理になり得るため、各拡張の遅延予算を意識し、タイムアウトを適切に設定する
• 1 つの巨大な拡張に詰め込まず、フェーズ（リクエストヘッダ／レスポンスヘッダ等）ごとに役割を分けて見通しを保つ
• 失敗時の挙動（拡張がエラー・タイムアウトしたら通すか／落とすか）を明示的に設計し、可用性とセキュリティのどちらを優先するか決めておく

運用・監視

• Cloud Monitoring で拡張呼び出しの遅延・エラー率・リクエスト数を監視し、拡張がレイテンシに与える影響を把握する
• コールアウトのバックエンドは通常のサービスと同様にヘルスチェックとオートスケールを設定し、拡張側の過負荷を防ぐ
• Cloud Logging と組み合わせ、プラグインからカスタムログを出して監査やデバッグに活用する
• 不具合切り分けでは、ロードバランサ側の拡張設定、コールアウト先の到達性（NEG・ファイアウォール）、gRPC のエラーコード、タイムアウト超過の有無を順に確認する
• 拡張のロールアウトは段階的に行い、まず一部のトラフィックや非本番環境で挙動とレイテンシを検証する

コスト

課金の中心は、拡張の処理量と、コールアウトを動かす自前バックエンドのリソース費です。

具体的な単価は変動するため、料金は公式の料金ページで最新値を確認してください。

セキュリティ

• 認可拡張でアクセス制御を外部委譲でき、アプリ本体に認可ロジックを散在させずに一元管理できる
• プラグインは Google マネージドのサンドボックスで隔離実行されるため、拡張コードがデータプレーン全体を侵食しにくい
• コールアウトのバックエンドは**内部接続（内部 IP・PSC・ハイブリッド NEG など）**で呼び出す構成にし、拡張サーバをインターネットに晒さない
• IAM で拡張リソースの作成・変更権限を最小化し、誰が処理経路に手を入れられるかを統制する
• 拡張で機微なヘッダやボディを扱う場合、ログ出力時のマスキングやアクセス制御を徹底し、情報漏えいを防ぐ

関連サービス・比較

最も近いのは、エッジ／配信経路でコードを実行する各クラウドの仕組みです。GCP では Service Extensions がロードバランサの処理経路へ拡張を差し込むのに対し、AWS は CloudFront 上の Lambda@Edge ／ CloudFront Functions で同様の経路処理を提供します。

ロードバランサ本体の機能は Cloud Load Balancing、WAF やレート制限など防御面は Cloud Armor、ID ベースのアクセス制御は IAP が担います。Service Extensions はそれらの標準機能では足りない独自ロジックを経路に足したいときの選択肢です。

ハンズオン / CLI例

# 1. コールアウト先（gRPC サーバ）をバックエンドサービスとして用意済みとする
#    （ここでは callout-backend という内部バックエンドサービスを参照する想定）

# 2. トラフィック拡張の定義ファイル（YAML）を作成
cat > traffic-extension.yaml <<'EOF'
name: my-traffic-extension
loadBalancingScheme: EXTERNAL_MANAGED
forwardingRules:
  - projects/PROJECT_ID/regions/asia-northeast1/forwardingRules/web-fr
extensionChains:
  - name: chain-1
    matchCondition:
      celExpression: "true"
    extensions:
      - name: add-header
        service: projects/PROJECT_ID/regions/asia-northeast1/backendServices/callout-backend
        supportedEvents:
          - REQUEST_HEADERS
          - RESPONSE_HEADERS
        timeout: 0.2s
EOF

# 3. トラフィック拡張（コールアウト）をインポートして作成
gcloud service-extensions lb-traffic-extensions import my-traffic-extension \
  --source=traffic-extension.yaml \
  --location=asia-northeast1

# 4. 作成した拡張を確認
gcloud service-extensions lb-traffic-extensions describe my-traffic-extension \
  --location=asia-northeast1