Anthos Service Mesh と Traffic Director は Cloud Service Mesh になりました。詳細については、Cloud Service Mesh の概要をご覧ください。

プロキシレス gRPC サービスを使用した高度なトラフィック管理を構成する

この構成は、プレビュー版のお客様はサポートされていますが、新しい Cloud Service Mesh ユーザーにはおすすめしません。詳細については、Cloud Service Mesh サービスルーティングの概要をご覧ください。

このドキュメントでは、次のトラフィック管理機能を使用して Cloud Service Mesh を構成する方法について説明します。

ルートマッチング
トラフィック分割
回路遮断
フォールトインジェクション
最大ストリーミング期間
再試行
セッションアフィニティ
外れ値検出
地域によるロードバランシング

このドキュメントでは、Compute Engine でのプロキシレス gRPC を使用した高度なトラフィック管理の設定を中心に説明しますが、Google Kubernetes Engine（GKE）でプロキシレス gRPC を使用する場合は、高度なトラフィック管理もサポートされています。

始める前に

高度なトラフィック管理を構成する前に、プロキシレス gRPC サービスを使用した Cloud Service Mesh の設定の準備の要件をご確認ください。すべての要件が満たされていなければ、高度なトラフィック管理を構成することはできません。

これらの機能のコンセプトに関する情報については、高度なトラフィック管理をご覧ください。

gRPC Wallet の例について

gRPC Wallet のサンプルのデプロイを例に、この機能を説明します。この例では、3 つの gRPC サービス、grpc.examples.wallet.Wallet、grpc.examples.wallet.stats.Stats、grpc.examples.wallet.account.Account があり、3 つの個別のアプリケーションとしてデプロイされています。

次の図に示すように、Wallet を呼び出して口座の残高を取得し、Stats サービスを使用してコインの価格を取得する gRPC クライアントを作成します。Wallet サービスは、Stats と Account サービスを呼び出して残高を計算します。また、Stats サービスは Account サービスを呼び出してユーザー情報を取得します。

gRPC Wallet のトラフィックルーティング構成の例。 — gRPC Wallet のトラフィックルーティング構成の例（クリックして拡大）

この例では、構成したルールに基づいたリクエストのルーティングを説明するため、Wallet と Stats の実装の 2 つのバージョンをデプロイします。異なるバージョンのサービスのビルドとデプロイをシミュレートするには、サーバーフラグを使用して、1 回のみビルドするバイナリの動作を変更します。

--port フラグには、VM インスタンス上のサービスがリッスンするポートを指定します。
--hostname_suffix フラグには、リクエストに応答する VM インスタンスのホスト名に追加される値を指定します。生成される値は、レスポンスの hostname メタデータとして追加されます。これは、クライアントリクエストに応答したインスタンスグループ内のインスタンスの識別に役立ちます。
--premium_only フラグに値 true を指定すると、サービスが stats サービスのプレミアムバージョンになります。
--v1_behavior フラグに値 true を指定すると、ウォレットのバイナリが v1 バージョンとして動作します。

次の表に、gRPC サービスのいずれかを実行している各 VM インスタンス用のこれらのフラグの値、インスタンスグループ内のインスタンス数、これらのインスタンスグループが属するバックエンドサービスを示します。

バックエンドサービス	インスタンスグループ	インスタンス	サーバーフラグ
`account`	`account`	2	`--port=50053` `--hostname_suffix="account"`
`stats`	`stats`	2	`--port=50052` `--hostname_suffix="stats"` `--account_server="xds:///account.grpcwallet.io"`
`stats-premium`	`stats-premium`	2	`--port=50052` `--hostname_suffix="stats_premium"` `--account_server="xds:///account.grpcwallet.io"` `--premium_only=true`
`wallet-v1` `wallet-v1-affinity`	`wallet-v1`	2	`--port=50051` `--hostname_suffix="wallet_v1"` `--v1_behavior=true` `--account_server="xds:///account.grpcwallet.io"` `--stats_server="xds:///stats.grpcwallet.io"`
`wallet-v2`	`wallet-v2`	1	`--port=50051` `--hostname_suffix "wallet_v2"` `--account_server="xds:///account.grpcwallet.io"` `--stats_server="xds:///stats.grpcwallet.io"`

これらのサービスをデプロイした後、次の表のルーティングルールに基づいて、テストクライアントから上に示したバックエンドサービスにリクエストをルーティングするように Cloud Service Mesh を構成します。クライアントは、ホスト列に示されているサービスの仮想ホスト名に接続します。

ホスト	一致ルール	ルートアクション
`wallet.grpcwallet.io`	パス接頭辞: `"/"` ヘッダー: `"session_id"`	`wallet-v1-affinity` にルーティングする
	パス接頭辞: `"/"` ヘッダー: `{"route": "timeout"}`	5 秒のタイムアウトを設定し `wallet-v2` にルーティングする
	パス接頭辞: `"/"` ヘッダー: `{"route": "fault"}`	50% のリクエストが失敗し残りを `wallet-v2` にルーティングする
	パス接頭辞: `"/"` ヘッダー: `{"membership": "premium"}`	`wallet-v1` にルーティングし失敗時に最大 3 回再試行する
	フルパス: `/grpc.examples.wallet.Wallet/FetchBalance`	ルーティング先: `wallet-v1`: 70% `wallet-v2`: 30%
	デフォルト	`wallet-v1` にルーティングする
`stats.grpcwallet.io`	パス接頭辞: `"/"` ヘッダー: `{"membership": "premium"}`	`stats-premium` にルーティングする
	デフォルト	`stats` にルーティングする
`account.grpcwallet.io`	パス接頭辞: `"/"` ヘッダー: `{"route": "account-fault"}`	30% のリクエストが失敗し残りを `account` にルーティングする
	デフォルト	`account`

この例では、2 つの既存のサービス間で 70/30 のトラフィック分割を使用します。URL マップでまだ参照されていない新しいサービスにトラフィックを分割する場合は、まず新しいサービスを weightedBackendServices に追加し、それに 0 の重みを設定します。次に、そのサービスに割り当てられた重みを徐々に増やしていきます。

テストクライアントには、トラフィック管理機能を実証するために適切なリクエストを生成できるようにする次のオプションがあります。

オプション	説明
`--watch=true`	ストリーミングメソッドを呼び出して、残高または価格を確認する
`--unary_watch=true`	単項メソッドを繰り返し呼び出して、残高または価格を確認する
`--user=Alice`	ヘッダー `{"membership": "premium"}` を挿入する
`--user=Bob`	ヘッダー `{"membership": "normal"}` を挿入する
`--route=value`	ヘッダー `{"route": "value"}` を挿入する
`--affinity=true`	ヘッダー `{"session_id": "value"}` を挿入する

ローカルの環境を準備する

これらの例でローカル環境を設定するには、次のコマンドを実行します。

gcloud バイナリを更新して、最新バージョンであることを確認します。
```
gcloud components update
```
サンプルリポジトリをダウンロードします。
```
sudo apt-get install git -y
```

サンプルに適切なリポジトリのクローンを作成します。

export EXAMPLES_VERSION=v1.1.x
git clone -b $EXAMPLES_VERSION --single-branch --depth=1 \
  https://github.com/GoogleCloudPlatform/traffic-director-grpc-examples.git

Cloud Router インスタンスを作成して構成する

このセクションでは、各リージョンに Cloud Router インスタンスを作成し、Cloud NAT 用に構成します。この例で作成される VM には外部 IP アドレスはありませんが、インターネットにアクセスする必要があります。Cloud NAT を使用して Cloud Router を構成すると、必要なアクセス権が提供されます。

gcloud

Cloud Router インスタンスを作成します。

gcloud compute routers create nat-router-us-central1 \
    --network=default \
    --region=us-central1

Cloud NAT のルーターを構成します。

gcloud compute routers nats create nat-config \
    --router-region=us-central1 \
    --router=nat-router-us-central1 \
    --nat-all-subnet-ip-ranges \
    --auto-allocate-nat-external-ips

gRPC ヘルスチェックとファイアウォールルールを作成する

このセクションでは、gRPC ヘルスチェックリクエストがネットワークへアクセスすることを許可する gRPC ヘルスチェックとファイアウォールルールを作成します。その後、gRPC ヘルスチェックはバックエンドサービスに関連付けられ、これらのバックエンドサービスのバックエンドインスタンスの健全性を確認できます。

gcloud

ヘルスチェックを作成します。

gcloud compute health-checks create grpc grpcwallet-health-check \
    --use-serving-port

ヘルスチェック用のファイアウォールルールを作成します。

gcloud compute firewall-rules create grpcwallet-allow-health-checks \
    --network default --action allow --direction INGRESS \
    --source-ranges 35.191.0.0/16,130.211.0.0/22 \
    --target-tags allow-health-checks \
    --rules tcp:50051-50053

インスタンステンプレートを作成する

このセクションでは、ポート 50053 で公開されている account gRPC サービスをデプロイするインスタンステンプレートを作成します。

gcloud

インスタンステンプレートを作成します。

gcloud compute instance-templates create grpcwallet-account-template \
   --scopes=https://www.googleapis.com/auth/cloud-platform \
   --tags=allow-health-checks \
   --network-interface=no-address \
   --image-family=debian-10 \
   --image-project=debian-cloud \
   --metadata-from-file=startup-script=<(echo "#! /bin/bash
set -ex
cd /root
export HOME=/root
sudo apt-get update -y
pushd \$(mktemp -d)
sudo apt-get install -y wget git
wget https://dl.google.com/go/go1.16.5.linux-amd64.tar.gz
sudo tar -C /usr/local -xvf go1.16.5.linux-amd64.tar.gz
sudo cp /usr/local/go/bin/go /usr/bin/go
popd
git clone -b $EXAMPLES_VERSION --single-branch --depth=1 https://github.com/GoogleCloudPlatform/traffic-director-grpc-examples.git
cd traffic-director-grpc-examples/go/account_server/
go build .
sudo systemd-run ./account_server --port 50053 --hostname_suffix account")

マネージドインスタンスグループを作成します。

マネージドインスタンスグループ（MIG）は、自動スケーリングを使用して、必要に応じて新しい VM インスタンスを作成します。このセクションでは、前のセクションで作成したインスタンステンプレートを使用して MIG を作成します。

gcloud

インスタンスグループを作成します。

gcloud compute instance-groups managed create grpcwallet-account-mig-us-central1 \
   --zone=us-central1-a \
   --size=2 \
   --template=grpcwallet-account-template

名前付きポートを構成する

このセクションでは、gRPC サービスの名前付きポートを構成します。名前付きポートとは、gRPC サービスがリクエストをリッスンするポートです。この例では、名前付きポートはポート 50053 です。

gcloud

名前付きポートを作成します。

gcloud compute instance-groups set-named-ports grpcwallet-account-mig-us-central1 \
   --named-ports=grpcwallet-account-port:50053 \
   --zone=us-central1-a

バックエンドサービスを作成する

このセクションでは、INTERNAL_SELF_MANAGED とプロトコル GRPC の負荷分散方式でグローバルバックエンドサービスを作成します。次に、バックエンドサービスにヘルスチェックとインスタンスグループを関連付けます。この例では、マネージドインスタンスグループの作成で作成した MIG を使用します。この MIG は account gRPC サービスを実行します。--port-name フラグのポートは、名前付きポートの構成で作成した名前付きポートです。

gcloud

バックエンドサービスを作成し、新しいバックエンドサービスにヘルスチェックを関連付けます。

gcloud compute backend-services create grpcwallet-account-service \
    --global \
    --load-balancing-scheme=INTERNAL_SELF_MANAGED \
    --protocol=GRPC \
    --port-name=grpcwallet-account-port \
    --health-checks=grpcwallet-health-check

マネージドインスタンスグループをバックエンドとして追加します。

gcloud compute backend-services add-backend grpcwallet-account-service \
    --instance-group=grpcwallet-account-mig-us-central1 \
    --instance-group-zone=us-central1-a \
    --global

gRPC Wallet の例で使用されている残りのバックエンドサービスを作成する手順は、前述の手順と同様です。シェルスクリプトを実行して残りのサービスを作成します。このスクリプトは、次のバックエンドサービスをデプロイします。

stats
stats-premium
wallet-v1
wallet-v1-affinity
wallet-v2

追加のバックエンドサービスを作成するシェルスクリプトを実行します。

traffic-director-grpc-examples/scripts/create_service.sh go stats 50052 stats '--account_server="xds:///account.grpcwallet.io"'

traffic-director-grpc-examples/scripts/create_service.sh go stats 50052 stats-premium '--account_server="xds:///account.grpcwallet.io" --premium_only=true'

# This command creates wallet-v1 and wallet-v1-affinity backend services.
traffic-director-grpc-examples/scripts/create_service.sh java wallet 50051 wallet-v1 '--account_server="xds:///account.grpcwallet.io" --stats_server="xds:///stats.grpcwallet.io" --v1_behavior=true'

traffic-director-grpc-examples/scripts/create_service.sh java wallet 50051 wallet-v2 '--account_server="xds:///account.grpcwallet.io" --stats_server="xds:///stats.grpcwallet.io"'

ルーティングルールを作成する

このセクションでは、さまざまなトラフィック管理機能を実証するために使用される URL マップを作成します。URL マップでは、この例のサービスの仮想ホスト名と、関連するルーティングルールを指定します。詳細については、ルーティングルールマップをご覧ください。

URL マップでは、この例のサービスのホスト名を hostRules で指定します。これらのホスト名は、特定のサービスに接続するためにクライアントがチャンネル URI で使用する名前です。たとえば、account サービスにリクエストを送信する場合は、クライアントがチャンネル URI で xds:///account.grpcwallet.io を使用します。hostRules で、account.grpcwallet.io という値を持つ hosts エントリを構成します。

hosts エントリに関連付けられた pathMatcher は、その仮想ホストのすべてのルーティングルールを含む pathMatcher の名前を指定します。pathMatcher 構成は、gRPC Wallet の例についてで説明されているように、マッチングルールと対応するアクションルールで構成されます。

gcloud

URL マップを作成します。

export PROJECT_ID=$(gcloud config list --format 'value(core.project)')
export BS_PREFIX=projects/$PROJECT_ID/global/backendServices/grpcwallet

gcloud compute url-maps import grpcwallet-url-map << EOF
name: grpcwallet-url-map
defaultService: $BS_PREFIX-account-service

hostRules:
- hosts:
  - account.grpcwallet.io
  pathMatcher: grpcwallet-account-path-matcher
- hosts:
  - stats.grpcwallet.io
  pathMatcher: grpcwallet-stats-path-matcher
- hosts:
  - wallet.grpcwallet.io
  pathMatcher: grpcwallet-wallet-path-matcher

pathMatchers:
- name: grpcwallet-account-path-matcher
  defaultService: $BS_PREFIX-account-service
  routeRules:
  - matchRules:
    - prefixMatch: /
      headerMatches:
      - headerName: route
        exactMatch: account-fault
    priority: 0
    routeAction:
      weightedBackendServices:
      - backendService: $BS_PREFIX-account-service
        weight: 100
      faultInjectionPolicy:
        abort:
          httpStatus: 503
          percentage: 30

- name: grpcwallet-stats-path-matcher
  defaultService: $BS_PREFIX-stats-service
  routeRules:
  - matchRules:
    - prefixMatch: /
      headerMatches:
      - headerName: membership
        exactMatch: premium
    priority: 0
    service: $BS_PREFIX-stats-premium-service

- name: grpcwallet-wallet-path-matcher
  defaultService: $BS_PREFIX-wallet-v1-service
  routeRules:
  - matchRules:
    - prefixMatch: /
      headerMatches:
      - headerName: session_id
        presentMatch: true
    priority: 0
    routeAction:
      weightedBackendServices:
      - backendService: $BS_PREFIX-wallet-v1-affinity-service
        weight: 100

  - matchRules:
    - prefixMatch: /
      headerMatches:
      - headerName: route
        exactMatch: timeout
    priority: 1
    routeAction:
      weightedBackendServices:
      - backendService: $BS_PREFIX-wallet-v2-service
        weight: 100
      maxStreamDuration:
        seconds: 5

  - matchRules:
    - prefixMatch: /
      headerMatches:
      - headerName: route
        exactMatch: fault
    priority: 2
    routeAction:
      weightedBackendServices:
      - backendService: $BS_PREFIX-wallet-v2-service
        weight: 100
      faultInjectionPolicy:
        abort:
          httpStatus: 503
          percentage: 50

  - matchRules:
    - prefixMatch: /
      headerMatches:
      - headerName: membership
        exactMatch: premium
    priority: 3
    routeAction:
      weightedBackendServices:
      - backendService: $BS_PREFIX-wallet-v1-service
        weight: 100
      retryPolicy:
        retryConditions:
          - unavailable
        numRetries: 3

  - matchRules:
    - fullPathMatch: /grpc.examples.wallet.Wallet/FetchBalance
    priority: 4
    routeAction:
      weightedBackendServices:
      - backendService: $BS_PREFIX-wallet-v1-service
        weight: 70
      - backendService: $BS_PREFIX-wallet-v2-service
        weight: 30

  - matchRules:
    - prefixMatch: /grpc.examples.wallet.Wallet/
    priority: 5
    routeAction:
      weightedBackendServices:
      - backendService: $BS_PREFIX-wallet-v2-service
        weight: 100
EOF

ターゲットプロキシと転送ルールを作成する

このセクションでは、ターゲット gRPC プロキシと転送ルールを作成します。

ターゲット gRPC プロキシは、前のステップで作成した URL マップを参照します。--validate-for-proxyless フラグを指定すると、構成チェックが有効になり、プロキシレス gRPC デプロイと互換性のない機能を誤って有効にすることを回避できます。

gcloud

ターゲット gRPC プロキシを作成します。

gcloud compute target-grpc-proxies create grpcwallet-proxy \
   --url-map=grpcwallet-url-map \
   --validate-for-proxyless

作成したターゲット gRPC プロキシが転送ルールによって参照されます。負荷分散スキームが INTERNAL_SELF_MANAGED に設定され、この転送ルールが Cloud Service Mesh によって使用されていることを示します。これはグローバル転送ルールである必要があります。プロキシレス gRPC クライアントは、DNS ルックアップを実行する代わりに LDS リクエストを Cloud Service Mesh に送信することで、ターゲット URI で hostname:port を解決するため、IP アドレスは 0.0.0.0 に設定されます。詳細については、名前解決スキームをご覧ください。

ターゲット URI にポートが指定されていない場合、デフォルト値は 80 です。たとえば、ターゲット URI xds:///foo.myservice:8080 は、ポート 8080 を使用して構成された転送ルールと一致します。この例では、転送ルールはポート 80 を使用して構成されています。

gcloud

転送ルールを作成します。

gcloud compute forwarding-rules create grpcwallet-forwarding-rule \
   --global \
   --load-balancing-scheme=INTERNAL_SELF_MANAGED \
   --address=0.0.0.0 \
   --address-region=us-central1 \
   --target-grpc-proxy=grpcwallet-proxy \
   --ports=80 \
   --network=default

構成を確認する

構成プロセスが完了したら、Google Cloud コンソールの [Cloud Service Mesh] ページで、構成したバックエンドサービスが使用可能であることを確認します。バックエンドサービスと関連するバックエンドが正常であると報告されていることを確認します。この処理には数分かかることがあります。

ルーティング構成を確認する

このセクションでは、ルーティング構成が正しく機能していることを確認します。grpcurl ツールを使用して構成をテストします。

gcloud

クライアントを実行するクライアント VM を作成し、サービスをテストします。必要に応じて --network-interface=no-address フラグを指定できます。

gcloud compute instances create grpc-wallet-client \
    --zone=us-central1-a \
    --scopes=https://www.googleapis.com/auth/cloud-platform \
    --image-family=debian-10 \
    --image-project=debian-cloud \
    --metadata-from-file=startup-script=<(echo '#! /bin/bash
set -e
export GRPC_XDS_BOOTSTRAP=/run/td-grpc-bootstrap.json
# Expose bootstrap variable to SSH connections
echo export GRPC_XDS_BOOTSTRAP=$GRPC_XDS_BOOTSTRAP | sudo tee /etc/profile.d/grpc-xds-bootstrap.sh
# Create the bootstrap file
curl -L https://storage.googleapis.com/traffic-director/td-grpc-bootstrap-0.16.0.tar.gz | tar -xz
./td-grpc-bootstrap-0.16.0/td-grpc-bootstrap | sudo tee $GRPC_XDS_BOOTSTRAP')

SSH を使用して VM にアクセスし、次のコマンドを実行して VM を準備します。
```
export EXAMPLES_VERSION=v1.1.x
sudo apt-get update
sudo apt-get install git -y
```

次のコマンドを実行します。

git clone -b $EXAMPLES_VERSION --single-branch --depth=1 \
   https://github.com/GoogleCloudPlatform/traffic-director-grpc-examples.git
curl -L https://github.com/fullstorydev/grpcurl/releases/download/v1.6.1/grpcurl_1.6.1_linux_x86_64.tar.gz | tar -xz
chmod +x grpcurl

サイドカープロキシなしでサービスにアクセスするには、gRPC クライアントが xds 名前解決スキームを使用する必要があります。このスキームは、クライアントで使用される gRPC ライブラリに、xDS サーバーを使用してホスト名を解決するように指示します。これを実行するには、ブートストラップの構成が必要です。

前のセクションの起動スクリプトで GRPC_XDS_BOOTSTRAP 環境変数を設定し、ヘルパースクリプトを使用してブートストラップファイルを生成します。生成されたブートストラップファイル内の TRAFFICDIRECTOR_GCP_PROJECT_NUMBER、TRAFFICDIRECTOR_NETWORK_NAME、ゾーンの値は、Compute Engine VM インスタンスの詳細を把握しているメタデータサーバーから取得されます。これらの値は、-gcp-project-number オプションと -vpc-network-name オプションを使用してヘルパースクリプトに手動で指定できます。

`grpcurl` ツールを使用して構成を確認する

SSH シェルで次のコマンドを実行して、wallet-service、stats-service、account-service サービスが実行されていることを確認します。

./grpcurl -plaintext xds:///account.grpcwallet.io list
./grpcurl -plaintext -d '{"token": "2bd806c9"}' xds:///account.grpcwallet.io grpc.examples.wallet.account.Account/GetUserInfo
./grpcurl -plaintext -H 'authorization:2bd806c9' -H 'membership:premium' xds:///stats.grpcwallet.io grpc.examples.wallet.stats.Stats/FetchPrice
./grpcurl -plaintext -H 'authorization:2bd806c9' -H 'membership:premium' -d '{"include_balance_per_address": true}' xds:///wallet.grpcwallet.io grpc.examples.wallet.Wallet/FetchBalance

次の結果が表示されます。

grpc.examples.wallet.account.Account
grpc.health.v1.Health
grpc.reflection.v1alpha.ServerReflection

{
  "name": "Alice",
  "membership": "PREMIUM"
}

{
  "price": "10295"
}

{
  "balance": "5089953"
}

`grpc-wallet` クライアントでの確認

次の言語別の手順で構成を確認します。一連のコマンドで複数の RPC（追加のメタデータを含む）が送信され、URL マップのマッチングルールに基づいてバックエンドサービスにリクエストがルーティングされます。各レスポンスの VM インスタンスのホスト名も出力されます。これは、リクエストがルーティングされた VM インスタンスを示します。

Java

gRPC Java クライアントでサービスを確認するには、次のコマンドを実行します。
```
sudo apt-get install -y openjdk-11-jdk-headless
```

次のコマンドを実行します。

cd ~/traffic-director-grpc-examples/java
./gradlew installDist

# This command calls 'FetchBalance' from 'wallet-service' in a loop,
# to demonstrate that 'FetchBalance' gets responses from 'wallet-v1' (70%)
# and 'wallet-v2' (30%).
./build/install/wallet/bin/client balance --wallet_server="xds:///wallet.grpcwallet.io" --unary_watch=true --user=Bob

# This command calls the streaming RPC 'WatchBalance' from 'wallet-service'.
# The RPC path matches the service prefix, so all requests are
# sent to 'wallet-v2'.
./build/install/wallet/bin/client balance --wallet_server="xds:///wallet.grpcwallet.io" --watch=true --user=Bob

# This command calls 'WatchPrice' from 'stats-service'. It sends the
# user's membership (premium or not) in metadata. Premium requests are
# all sent to 'stats-premium' and get faster responses. Alice's requests
# always go to premium and Bob's go to regular.
./build/install/wallet/bin/client price --stats_server="xds:///stats.grpcwallet.io" --watch=true --user=Bob
./build/install/wallet/bin/client price --stats_server="xds:///stats.grpcwallet.io" --watch=true --user=Alice

Go

gRPC Go クライアントでサービスを確認するには、golang をインストールするか、公式の手順に従います。

sudo apt-get install -y wget
wget https://dl.google.com/go/go1.16.5.linux-amd64.tar.gz
sudo tar -C /usr/local -xvf go1.16.5.linux-amd64.tar.gz
sudo ln -s /usr/local/go/bin/go /usr/bin/go

次のコマンドを実行します。

cd ~/traffic-director-grpc-examples/go/wallet_client
go build

# This command calls 'FetchBalance' from 'wallet-service' in a loop,
# to demonstrate that 'FetchBalance' gets responses from 'wallet-v1' (70%)
# and 'wallet-v2' (30%).
./wallet_client balance --wallet_server="xds:///wallet.grpcwallet.io" --unary_watch --user=Bob

# This command calls the streaming RPC 'WatchBalance' from 'wallet-service'.
# The RPC path matches the service prefix, so all requests
# are sent to 'wallet-v2'.
./wallet_client balance --wallet_server="xds:///wallet.grpcwallet.io" --watch --user=Bob

# This command calls 'WatchPrice' from 'stats-service'. It sends the
# user's membership (premium or not) in metadata. Premium requests are
# all sent to 'stats-premium' and get faster responses. Alice's requests
# always go to premium and Bob's go to regular.
./wallet_client price --stats_server="xds:///stats.grpcwallet.io" --watch --user=Bob
./wallet_client price --stats_server="xds:///stats.grpcwallet.io" --watch --user=Alice

C++

gRPC C++ クライアントでサービスを確認するには、次のコマンドを実行します。
```
sudo apt-get install -y build-essential
```

次のコマンドを実行します。

cd ~/traffic-director-grpc-examples/cpp
../tools/bazel build :client

# This command calls 'FetchBalance' from 'wallet-service' in a loop,
# to demonstrate that 'FetchBalance' gets responses from 'wallet-v1' (70%)
# and 'wallet-v2' (30%).
../bazel-bin/cpp/client balance --wallet_server="xds:///wallet.grpcwallet.io" --unary_watch=true --user=Bob

# This command calls the streaming RPC 'WatchBalance'  from 'wallet-service'.
# The RPC path matches the service prefix, so all requests are sent to 'wallet-v2'.
../bazel-bin/cpp/client balance --wallet_server="xds:///wallet.grpcwallet.io" --watch=true --user=Bob

# This command calls 'WatchPrice' from 'stats-service'. It sends the
# user's membership (premium or not) in metadata. Premium requests are
# all sent to 'stats-premium' and get faster responses. Alice's requests
# always go to premium, and Bob's go to regular.
../bazel-bin/cpp/client price --stats_server="xds:///stats.grpcwallet.io" --watch=true --user=Bob
../bazel-bin/cpp/client price --stats_server="xds:///stats.grpcwallet.io" --watch=true --user=Alice

より高度なオプションを構成する

以降のセクションの手順を使用すると、追加の高度なトラフィックルーティングオプションを構成できます。

回路遮断

クライアントリクエストでバックエンドサービスが過負荷にならないように、回路遮断で障害しきい値を設定できます。未処理のリクエスト数が設定した上限に達すると、クライアントは追加のリクエストの送信を停止し、バックエンドサービスの復旧のための時間を確保します。

バックエンドサービスで過負荷を発生させずにエラーをクライアントに返すことで、カスケード障害を回避できます。これにより、自動スケーリングによって容量を増やしてトラフィックの急増に対応するなど、過負荷状態を管理する時間を確保しつつ、一部のトラフィックを処理できます。

stats-service のバックエンドサービスを作成する場合、create_service.sh スクリプトの構成には次の行が含まれます。

circuitBreakers:
  maxRequests: 1

この設定では、クライアントが一度に stats-service に保留できるリクエストは 1 つに制限されます。wallet-v2 サービスは 1 つのみ存在するため、2 つのウォレットクライアントで WatchBalance オペレーションを同時実行すると、2 番目のインスタンスで障害が発生します。

Java

次のコマンドを実行します。

cd ~/traffic-director-grpc-examples/java
./build/install/wallet/bin/client balance --wallet_server="xds:///wallet.grpcwallet.io" --watch=true --user=Bob  2>/dev/null 1>/dev/null &

sleep 10 # Wait a few seconds to allow the watch to begin.

./build/install/wallet/bin/client balance --wallet_server="xds:///wallet.grpcwallet.io" --watch=true --user=Bob

出力は次のようになります。

io.grpc.examples.wallet.Client run
INFO: Will try to run balance
io.grpc.examples.wallet.Client run
WARNING: RPC failed: Status{code=INTERNAL, description=RPC to stats server failed: UNAVAILABLE: Cluster max concurrent requests limit exceeded, cause=null}

kill コマンドを発行します。
```
kill %%
```

Go

次のコマンドを実行します。

cd ~/traffic-director-grpc-examples/go/wallet_client
./wallet_client balance --wallet_server="xds:///wallet.grpcwallet.io" --watch --user=Bob 2> /dev/null 1> /dev/null &

sleep 10 # Wait a few seconds to allow the watch to begin.

./wallet_client balance --wallet_server="xds:///wallet.grpcwallet.io" --watch --user=Bob

出力は次のようになります。

server host: error: no hostname
failed to fetch balance: rpc error: code = Internal desc = RPC to stats server failed:
UNAVAILABLE: Cluster max concurrent requests limit exceeded

kill コマンドを発行します。
```
kill %%
```

C++

次のコマンドを実行します。

cd ~/traffic-director-grpc-examples/cpp
../bazel-bin/cpp/client balance --wallet_server="xds:///wallet.grpcwallet.io" --watch=true --user=Bob 2>/dev/null 1>/dev/null &

sleep 10 # Wait a few seconds to allow the watch to begin.

../bazel-bin/cpp/client balance --wallet_server="xds:///wallet.grpcwallet.io" --watch=true --user=Bob

出力は次のようになります。

Client arguments: command: balance, wallet_server: xds:///wallet.grpcwallet.io, stats_server:
localhost:18882, user: Bob, watch: 1 ,unary_watch: 0, observability_project: , route:
13: RPC to stats server failed: UNAVAILABLE: Cluster max concurrent requests limit exceeded

kill コマンドを発行します。
```
kill %%
```

フォールトインジェクション

フォールトインジェクションは、高レイテンシ、サービス過負荷、サービス障害、ネットワークパーティショニングなどの障害をシミュレートするリクエストを処理する際にエラーを発生させます。この機能は、サービスの復元力を疑似的にテストするために利用できます。

以前に URL マップを作成したときに、route=fault ヘッダーを使用して wallet.grpcwallet.io に送信される RPC の 50% が失敗するフォールトインジェクションポリシーを設定しました。

フォールトインジェクションを実証するには、次の言語でコードを使用します。

Java

次のコマンドを実行します。

cd ~/traffic-director-grpc-examples/java
./build/install/wallet/bin/client balance --wallet_server="xds:///wallet.grpcwallet.io" --unary_watch=true --user=Bob --route=fault

出力は次のようになります。

server host: grpcwallet-wallet-v2-mig-us-central1-zznc
total balance: 10340491
- address: 148de9c5, balance: 2549839
- address: 2e7d2c03, balance: 7790652
io.grpc.examples.wallet.Client run
WARNING: RPC failed: Status{code=UNAVAILABLE, description=RPC terminated due to fault injection: HTTP status code 503, cause=null}

Go

次のコマンドを実行します。

cd ~/traffic-director-grpc-examples/go/wallet_client
./wallet_client balance --wallet_server="xds:///wallet.grpcwallet.io" --unary_watch --user=Bob --route=fault

出力は次のようになります。

 server host: grpcwallet-wallet-v1-mig-us-central1-bm1t_wallet-v1
 user: Bob, total grpc-coin balance: 10452589.
  - address: 2e7d2c03, balance: 7875108.
  - address: 148de9c5, balance: 2577481.
 failed to fetch balance: rpc error: code = Unavailable desc = RPC terminated due to fault injection

C++

次のコマンドを実行します。

cd ~/traffic-director-grpc-examples/cpp
../bazel-bin/cpp/client balance --wallet_server="xds:///wallet.grpcwallet.io" --unary_watch=true --user=Bob --route=fault

出力は次のようになります。

Client arguments: command: balance, wallet_server: xds:///wallet.grpcwallet.io,
stats_server: localhost:18882, user: Bob, watch: 0 ,unary_watch: 1, observability_project: ,
route: fault server host: grpcwallet-wallet-v2-mig-us-central1-1lm6
user: Bob total grpc-coin balance: 10211908
 - address: 148de9c5, balance: 2518132
 - address: 2e7d2c03, balance: 7693776
14: Fault injected

最大ストリーミング期間

最大ストリーミング期間により、すべての RPC に最大タイムアウトを適用できます。これにより、クライアントが期限の設定を忘れたり、長すぎる期限を設定したりすることによって、サーバーリソースを無駄にすることがなくなります。

上の URL マップを作成した際に、route=timeout ヘッダーを使用して、wallet.grpcwallet.io に送信される RPC の最大ストリーミング期間を 5 秒に設定しました。

タイムアウトを確認するには、まず wallet-v2 サービスを停止します。

gcloud

gcloud compute instance-groups managed resize \
    --size=0 grpcwallet-wallet-v2-mig-us-central1 \
    --zone=us-central1-a

処理するバックエンドサービスが存在せず、アプリケーションが期限を設定しないため、次のコマンドは恒久的に停止します。

Java

次のコマンドを実行します。

cd ~/traffic-director-grpc-examples/java
./build/install/wallet/bin/client balance --wallet_server="xds:///wallet.grpcwallet.io" --watch=true --user=Bob

コマンドがレスポンスを停止します。コマンドを中断するには、^C キーを押してください。

Go

次のコマンドを実行します。

cd ~/traffic-director-grpc-examples/go/wallet_client
./wallet_client balance --wallet_server="xds:///wallet.grpcwallet.io" --watch --user=Bob

コマンドがレスポンスを停止します。コマンドを中断するには、^C キーを押してください。

C++

次のコマンドを実行します。

cd ~/traffic-director-grpc-examples/cpp
../bazel-bin/cpp/client balance --wallet_server="xds:///wallet.grpcwallet.io" --watch=true --user=Bob

コマンドがレスポンスを停止します。コマンドを中断するには、^C キーを押してください。

ただし、timeout ルートを使用した次のコマンドは、maxStreamDuration 設定により 5 秒後に失敗します。

Java

次のコマンドを実行します。

cd ~/traffic-director-grpc-examples/java
./build/install/wallet/bin/client balance --wallet_server="xds:///wallet.grpcwallet.io" --watch=true --user=Bob --route=timeout

出力は次のようになります。

io.grpc.examples.wallet.Client run
WARNING: RPC failed: Status{code=DEADLINE_EXCEEDED, description=deadline exceeded after 4.999594070s.         [wait_for_ready, buffered_nanos=5000553401, waiting_for_connection], cause=null}

Go

次のコマンドを実行します。

cd ~/traffic-director-grpc-examples/go/wallet_client
./wallet_client balance --wallet_server="xds:///wallet.grpcwallet.io" --watch --user=Bob --route=timeout

出力は次のようになります。

failed to create stream: rpc error: code = DeadlineExceeded desc = context deadline exceeded.

C++

次のコマンドを実行します。

cd ~/traffic-director-grpc-examples/cpp
../bazel-bin/cpp/client balance --wallet_server="xds:///wallet.grpcwallet.io" --watch=true --user=Bob --route=timeout

出力は次のようになります。

Client arguments: command: balance, wallet_server: xds:///wallet.grpcwallet.io, stats_server:
localhost:18882, user: Bob, watch: 1 ,unary_watch: 0, observability_project: , route: timeout
4: Deadline Exceeded

wallet-v2 サービスを再起動します。

gcloud

gcloud compute instance-groups managed resize \
    --size=1 grpcwallet-wallet-v2-mig-us-central1 \
    --zone=us-central1-a

再試行

再試行は、gRPC アプリケーションが再試行ポリシーに従って送信リクエストを再試行できるようにすることで、サービスの可用性の向上に役立ちます。再試行ポリシーでは、失敗したリクエストを再試行する条件と、再試行回数の上限を構成できます（たとえば、リクエストが特定のレスポンスコードで失敗する場合など）。

以前に URL マップを作成したときに、membership=premium ヘッダーを使用して RPC の再試行ポリシーを FetchBalance メソッドに設定しました。このポリシーは、ステータスコード unavailable で失敗する RPC を最大で 3 回再試行します。また、Wallet サービスから Account サービスへの RPC の 30% を失敗させる route=account-fault ヘッダーを使用して、RPC のフォールトインジェクションポリシーを account.grpcwallet.io に設定しました。その結果、membership=normal ヘッダーを使用するテストクライアントからの RPC の 30% は失敗しますが、membership=premium ヘッダーを使用する RPC の失敗率は 1% 未満になります。

再試行を実証するには、次の言語でコードを使用します。

Java

次のコマンドを実行します。

cd ~/traffic-director-grpc-examples/java
# 30% of the requests fail because Bob is a normal user.
./build/install/wallet/bin/client balance --wallet_server="xds:///wallet.grpcwallet.io" --unary_watch=true --user=Bob --route=account-fault
# Less than 1% of the requests fail because Alice is a premium user.
./build/install/wallet/bin/client balance --wallet_server="xds:///wallet.grpcwallet.io" --unary_watch=true --user=Alice --route=account-fault

Go

次のコマンドを実行します。

cd ~/traffic-director-grpc-examples/go/wallet_client
# 30% of the requests fail because Bob is a normal user.
./wallet_client balance --wallet_server="xds:///wallet.grpcwallet.io" --unary_watch=true --user=Bob --route=account-fault
# Less than 1% of the requests fail because Alice is a premium user.
./wallet_client balance --wallet_server="xds:///wallet.grpcwallet.io" --unary_watch=true --user=Alice --route=account-fault

C++

次のコマンドを実行します。

cd ~/traffic-director-grpc-examples/cpp
# 30% of the requests fail because Bob is a normal user.
../bazel-bin/cpp/client balance --wallet_server="xds:///wallet.grpcwallet.io" --unary_watch=true --user=Bob --route=account-fault
# Less than 1% of the requests fail because Alice is a premium user.
../bazel-bin/cpp/client balance --wallet_server="xds:///wallet.grpcwallet.io" --unary_watch=true --user=Alice --route=account-fault

セッションアフィニティ

セッションアフィニティでは、インスタンスが良好な状態で処理能力があれば、特定の特性（HTTP ヘッダー）を持つリクエストを同じインスタンスに送信するための、ベストエフォート型の試行を行います。これは、特定のクライアントからのリクエストが異なるインスタンスにラウンドロビン分散されるのではなく、同じインスタンスに送信される場合に、パフォーマンスと効率性が向上するステートフルアプリケーションサーバーにとって有用です。

バックエンドサービス grpcwallet-wallet-v1-affinity-service を作成したときに、create_service.sh スクリプトで localityLbPolicy が ROUND_ROBIN に設定されていました。この例では、次の構成を適用して localityLbPolicy を RING_HASH に変更します。

sessionAffinity: HEADER_FIELD
localityLbPolicy: RING_HASH
consistentHash:
  httpHeaderName: "session_id"

gcloud

バックエンドサービス grpcwallet-wallet-v1-affinity-service の構成を保存します。

gcloud compute backend-services export grpcwallet-wallet-v1-affinity-service \
 --destination=bs_config.yaml \
 --global

バックエンドサービス grpcwallet-wallet-v1-affinity-service を更新します。

project_id="$(gcloud config list --format 'value(core.project)')"
backend_config="
backends:
- balancingMode: UTILIZATION
  capacityScaler: 1.0
  group: projects/${project_id}/zones/us-central1-a/instanceGroups/grpcwallet-wallet-v1-mig-us-central1
connectionDraining:
  drainingTimeoutSec: 0
healthChecks:
- projects/${project_id}/global/healthChecks/grpcwallet-health-check
loadBalancingScheme: INTERNAL_SELF_MANAGED
name: grpcwallet-wallet-v1-affinity-service
portName: grpcwallet-wallet-port
protocol: GRPC
sessionAffinity: HEADER_FIELD
localityLbPolicy: RING_HASH
consistentHash:
  httpHeaderName: session_id"
gcloud compute backend-services import grpcwallet-wallet-v1-affinity-service --global <<< "${backend_config}"

セッションアフィニティを確認するには、次の言語のコードを使用します。--affinity=true フラグを指定すると、クライアントはユーザーごとに一意の値を持つヘッダー session-id を挿入します。この値のハッシュは、バックエンドサービス grpcwallet-wallet-v1-affinity-service のインスタンスグループ内の特定のインスタンスにリクエストを送信するために使用されます。

Java

次のコマンドを実行します。

cd ~/traffic-director-grpc-examples/java
# Without affinity, requests are sent to both instances.
./build/install/wallet/bin/client balance --wallet_server="xds:///wallet.grpcwallet.io" --unary_watch=true --user=Alice
# With affinity, requests are sent to only one instance.
./build/install/wallet/bin/client balance --wallet_server="xds:///wallet.grpcwallet.io" --unary_watch=true --user=Alice --affinity=true

Go

次のコマンドを実行します。

cd ~/traffic-director-grpc-examples/go/wallet_client
# Without affinity, requests are sent to both instances.
./wallet_client balance --wallet_server="xds:///wallet.grpcwallet.io" --unary_watch=true --user=Alice
# With affinity, requests are sent to only one instance.
./wallet_client balance --wallet_server="xds:///wallet.grpcwallet.io" --unary_watch=true --user=Alice --affinity=true

C++

次のコマンドを実行します。

cd ~/traffic-director-grpc-examples/cpp
# Without affinity, requests are sent to both instances.
../bazel-bin/cpp/client balance --wallet_server="xds:///wallet.grpcwallet.io" --unary_watch=true --user=Alice
# With affinity, requests are sent to only one instance.
../bazel-bin/cpp/client balance --wallet_server="xds:///wallet.grpcwallet.io" --unary_watch=true --user=Alice --affinity=true

バックエンドサービス grpcwallet-wallet-v1-affinity-service の構成を復元します。

gcloud

gcloud compute backend-services import grpcwallet-wallet-v1-affinity-service \
  --source=bs_config.yaml \
  --global

外れ値検出

サービスの可用性を向上させるには、外れ値検出を構成します。この機能を使用すると、ロードバランシングプールから異常なホストを特定して、一時的に削除できます。こうした異常なホストは「外れ値」と呼ばれます。

gRPC は、成功率（ホストがリクエストを正常に処理する頻度）に基づいてホストを評価します。このレートは、gRPC エラー、HTTP エラー、タイムアウトなどの問題の影響を受けます。

Cloud Service Mesh を使用して外れ値検出を構成すると、gRPC がホストを評価する方法と外れ値の処理方法を微調整できます。たとえば、次のような判断基準を指定できます。

gRPC が外れ値の可能性を分析する前に、ホストが受信するリクエストの数。
ホストが外れ値と見なされる前に、平均成功率から外れる程度。
ロードバランシングプールから一度に外すことができるホストの最大割合。
外れ値がロードバランシングプールから除外される時間。

使用可能なパラメータの詳細については、REST Resource: backendServices リファレンスをご覧ください。ただし、次のセクションで説明するように、gRPC にはいくつかの制限事項があります。

制限事項

gRPC クライアントでは、次のフィールドはサポートされていません。

outlierDetection.consecutiveErrors
outlierDetection.enforcingConsecutiveErrors
outlierDetection.consecutiveGatewayFailure
outlierDetection.enforcingConsecutiveGatewayFailure

外れ値検出を設定する

次の手順では、1 つのインスタンスグループをバックエンドとして使用するサービスの外れ値検出を構成する方法について説明します。この手順では、次の構成を確立します。

外れ値検出分析は 1 秒ごとに実行されます。この動作は、interval フィールドを使用して構成します。
外れ値は、次のように 30 秒間ロードバランシングプールから外されます。
- ホストが一度も外されていない場合は、30 秒間だけ外されます。
- 以前にホストが外されている場合、時間は外されるたびに 30 秒増加します。たとえば、ホストが 3 回外されると、90 秒間外されます。この動作は、baseEjectionTime フィールドを使用して構成します。
選択された期間（この場合は 1 秒）の平均で 1 標準偏差を下回った場合、ホストは異常とみなされます。最大標準偏差を構成するには、successRateStdevFactor フィールドを使用します。

このように外れ値検出を構成するには、次の手順を行います。

gcloud

gcloud compute backend-services export コマンドを使用して、grpcwallet-wallet-v2-service バックエンドサービス構成ファイルをエクスポートします。
```
gcloud compute backend-services export grpcwallet-wallet-v2-service \
 --destination=bs_config.yaml \
 --global
```

bs_config.yaml ファイルで、grpcwallet-wallet-v2-service 構成を更新して外れ値検出フィールドを含めます。

outlierDetection:
 interval:
   seconds: 1
   nanos: 0
 baseEjectionTime:
   seconds: 30
   nanos: 0
 successRateStdevFactor: 1000

gcloud compute backend-services import コマンドを使用して、更新したファイルをインポートします。
```
gcloud compute backend-services import grpcwallet-wallet-v2-service \
 --source=bs_config.yaml \
 --global
```

地域によるロードバランシング

リソースを最大限効率的に使用するには、地域によるロードバランシングを構成します。この機能により、バックエンドにクライアントリクエストを均等に分散することで、リソースを節約できます。

地域によるロードバランシングを構成する場合は、次の表に示すオプションを使用できます。いずれのオプションについても、backendServices リソースを構成する必要があります。

オプション	対象	関連する構成フィールド
組み込みポリシーを使用する	すべての gRPC クライアント	`localityLbPolicy`
カスタムポリシーを使用する	gRPC クライアント 1.47 以降を使用する Java クライアント（gRPC クライアントのみを含むメッシュ内）	`localityLbPolicies`
優先ポリシーのリストを定義する	gRPC クライアント 1.47 以降を使用する Java クライアント（gRPC クライアントのみを含むメッシュ内）	`localityLbPolicies`

これらのオプションは自由に組み合わせて使用できます。ただし、localityLbPolicy と localityLbPolicies の両方を構成すると、gRPC はまず localityLbPolicies 構成の使用を試みます。

地域によるロードバランシングを構成しない場合、Cloud Service Mesh は ROUND_ROBIN ポリシーを使用します。

ROUND_ROBIN や他の組み込みポリシーについては、backendServices ページの localityLbPolicy の説明をご覧ください。

組み込みポリシーを使用する

すべてのクライアントに同じ組み込みポリシーを使用する場合は、localityLbPolicy フィールドを構成して選択します。

このフィールドを構成するときに、次のポリシーから選択できます。

LEAST_REQUEST（Java クライアントのみ）
RING_HASH
ROUND_ROBIN

すべてのクライアントが同じポリシーを使用できない場合は、優先ポリシーのリストを定義するをご覧ください。

gcloud

gcloud compute backend-services export コマンドを使用して、grpcwallet-wallet-v2-service バックエンドサービス構成ファイルをエクスポートします。
```
gcloud compute backend-services export grpcwallet-wallet-v2-service \
--destination=bs_config.yaml \
--global
```
エクスポートされた bs_config.yaml ファイルを更新して、次の行を追加します。
```
localityLbPolicy:
 -- policy
    name: RING_HASH
```
gcloud compute backend-services import コマンドを使用して、更新したファイルをインポートします。
```
gcloud compute backend-services import grpcwallet-wallet-v2-service --source=bs_config.yaml --global
```

カスタムポリシーを使用する

必要に応じて、gRPC で作成およびデプロイしたカスタムロードバランシングポリシーを使用できます。この機能は、gRPC バージョン 1.47 以降を使用する Java クライアントで使用できます。すべての gRPC クライアントを含むメッシュでのみ使用してください。

カスタムポリシーを作成する場合は、次のドキュメントをご活用いただける可能性があります。

カスタムポリシーをさらに高度な設定内容にするには、Open Request Cost Aggregation（ORCA）API を使用します。これらの API を使用すると、クエリの費用とサーバー使用率に関する指標をキャプチャできます。これらの API を使用するには、gRPC バージョン 1.48.1 以降が必要です。詳細については、gRPC ORCA の例をご覧ください。
xDS によってカスタムロードバランシング構成が gRPC に提供される仕組みについては、gRPC xDS カスタムロードバランサの構成をご覧ください。

カスタムポリシーを使用するように Cloud Service Mesh を構成するには、localityLbPolicies フィールドを使用してポリシーを識別します。

このプロセスは次の手順で行います。この手順では、接続しているクライアントが example.ExampleLoadBalancer というカスタムポリシーを使用するように、grpcwallet-wallet-v2-service バックエンドサービスの構成を更新します。

gcloud

gcloud compute backend-services export コマンドを使用して、grpcwallet-wallet-v2-service バックエンドサービス構成ファイルをエクスポートします。
```
gcloud compute backend-services export grpcwallet-wallet-v2-service \
--destination=bs_config.yaml \
--global
```
エクスポートされた bs_config.yaml ファイルを更新して、example.ExampleLoadBalancer ポリシーを参照します。次の行を含めます。
```
localityLbPolicies:
  - customPolicy:
      name: example.ExampleLoadBalancer
      data: '{ "message": "Hello load-balancing world!" }'
```
gcloud compute backend-services import コマンドを使用して、更新したファイルをインポートします。
```
gcloud compute backend-services import grpcwallet-wallet-v2-service --source=bs_config.yaml --global
```
省略可: ロードバランシングの構成をテストします。
Java
```
cd ~/traffic-director-grpc-examples/java
./build/install/wallet/bin/client balance --wallet_server="xds:///wallet.grpcwallet.io" --watch=true --user=Bob
```
カスタムロードバランシングポリシーを正しく構成すると、構成に配置したメッセージ（「Hello load-balancing world!」）が表示されます。

優先ポリシーのリストを定義する

1 つのロードバランシングポリシーをサポートしていないクライアントが複数ある場合は、クライアントが使用できるポリシーのリストを作成します。このオプションを使用すると、最初に選択したポリシーが特定のクライアントで使用できない場合、gRPC はリストの次にあるポリシーにフォールバックします。

優先ポリシーのリストを作成する場合、有効なオプションにはカスタムポリシー、ROUND_ROBIN、また Java クライアントの場合は LEAST_REQUEST などがあります。最大 10 個のポリシーを一覧表示できます。

この機能は、gRPC バージョン 1.47 以降を使用する Java クライアントでのみ使用できます。すべての gRPC クライアントを含むメッシュでのみ使用してください。

gcloud

gcloud compute backend-services export コマンドを使用して、grpcwallet-wallet-v2-service バックエンドサービス構成ファイルをエクスポートします。

gcloud compute backend-services export grpcwallet-wallet-v2-service \
  --destination=bs_config.yaml \
  --global

エクスポートされた bs_config.yaml ファイルを更新して、localityLbPolicies フィールドを含めます。次のポリシーを表すエントリを入力します。
- 無効なカスタムポリシー（example.InvalidLoadBalancer）
- 有効なカスタムポリシー（example.ExampleLoadBalancer）
- サポートされている組み込みポリシー（LEAST_REQUEST）
```
localityLbPolicies:
  - customPolicy:
      name: example.InvalidLoadBalancer
      data: '{ "message": "This load-balancing policy doesn't work!" }'
  - customPolicy:
      name: example.ExampleLoadBalancer
      data: '{ "message": "Hello load-balancing world!" }'
  - policy:
      name: LEAST_REQUEST
```
gcloud compute backend-services import コマンドを使用して、更新したファイルをインポートします。
```
gcloud compute backend-services import grpcwallet-wallet-v2-service --source=bs_config.yaml --global
```
省略可: ロードバランシングの構成をテストします。
Java
```
cd ~/traffic-director-grpc-examples/java
./build/install/wallet/bin/client balance --wallet_server="xds:///wallet.grpcwallet.io" --watch=true --user=Bob
```
gRPC はレスポンスで example.InvalidLoadBalancer を見つけようとしますが、失敗します。その後、example.ExampleLoadBalancer の使用にフォールバックし、構成に配置したメッセージ（「Hello load-balancing world!」）が表示されます。クライアントの gRPC ロギングには、example.InvalidLoadBalancer が見つからなかったことを示すメッセージが含まれます。

リソースをクリーンアップする

リソースをクリーンアップするには、ローカルシステムから次のコマンドを実行します。

traffic-director-grpc-examples/scripts/cleanup.sh

サービス間のトラフィックをブロックする

GKE 上でデプロイされているサービス A とサービス B 間のトラフィックをブロックする場合、サービスセキュリティを設定し、認可ポリシーを使用してサービス間のトラフィックをブロックします。詳しい手順については、Cloud Service Mesh サービスセキュリティと、Envoy とプロキシレス gRPC を使用した設定手順をご覧ください。

次のステップ

Cloud Service Mesh の構成に関する問題を解決するには、プロキシレス gRPC を使用したデプロイのトラブルシューティングをご覧ください。

プロキシレス gRPC サービスを使用した高度なトラフィック管理を構成する

始める前に

gRPC Wallet の例について

ローカルの環境を準備する

Cloud Router インスタンスを作成して構成する

gcloud

gRPC ヘルスチェックとファイアウォール ルールを作成する

gcloud

インスタンス テンプレートを作成する

gcloud

マネージド インスタンス グループを作成します。

gcloud

名前付きポートを構成する

gcloud

バックエンド サービスを作成する

gcloud

ルーティング ルールを作成する

gcloud

ターゲット プロキシと転送ルールを作成する

gcloud

gcloud

構成を確認する

ルーティング構成を確認する

gcloud

grpcurl ツールを使用して構成を確認する

grpc-wallet クライアントでの確認

Java

Go

C++

より高度なオプションを構成する

回路遮断

Java

Go

C++

フォールト インジェクション

Java

Go

C++

最大ストリーミング期間

gcloud

Java

Go

C++

Java

Go

C++

gcloud

再試行

Java

Go

C++

セッション アフィニティ

gcloud

Java

Go

C++

gcloud

外れ値検出

制限事項

外れ値検出を設定する

gcloud

地域によるロード バランシング

組み込みポリシーを使用する

gcloud

カスタム ポリシーを使用する

gcloud

Java

優先ポリシーのリストを定義する

gcloud

Java

リソースをクリーンアップする

サービス間のトラフィックをブロックする

次のステップ

gRPC ヘルスチェックとファイアウォールルールを作成する

インスタンステンプレートを作成する

マネージドインスタンスグループを作成します。

バックエンドサービスを作成する

ルーティングルールを作成する

ターゲットプロキシと転送ルールを作成する

`grpcurl` ツールを使用して構成を確認する

`grpc-wallet` クライアントでの確認

フォールトインジェクション

セッションアフィニティ

地域によるロードバランシング

カスタムポリシーを使用する