このページの一部またはすべての情報は、S3NS の Cloud de Confiance に適用されない場合があります。詳細については、Google Cloud との違いをご確認ください。

Google は AI 技術を使用して、コンテンツをご希望の言語に翻訳しています。AI 翻訳には誤りが含まれる場合があります。

弾力性のあるクロスリージョン高可用性を構成する

Autopilot Standard

このドキュメントでは、Google Kubernetes Engine（GKE）Multi-Cluster Inference Gateway と GKE 自動スケーリング機能を使用して、AI 推論ワークロードのリージョンをまたぐ伸縮自在な高可用性を構成する方法について説明します。この設定により、異なるリージョンの複数の GKE クラスタ間でワークロードの負荷をインテリジェントに分散できます。

GKE Multi-Cluster Inference Gateway の詳細については、 GKE Multi-Cluster Inference Gateway についてをご覧ください。

始める前に

Google Kubernetes Engine API を有効にします。

Google Kubernetes Engine API の有効化
このタスクに Google Cloud CLI を使用する場合は、インストールして初期化します。

注: 既存の gcloud CLI インストールがある場合は、ロケーション関連のエラーを回避するために、またはgcloud config set compute/region を使用してデフォルトのリージョンまたはゾーンが構成されていることを確認してください。gcloud config set compute/zoneデフォルトと異なる場合は、コマンドでロケーションを指定する必要がある場合があります。詳細については、gcloud CLI のプロパティをご覧ください。
H100 GPU 用にプロジェクトに十分な割り当てがあることを確認します。詳細については、GPU の割り当てとリソース割り当てをご覧ください。
GKE バージョン 1.34.1-gke.1127000 以降を使用します。
gcloud CLI バージョン 480.0.0 以降を使用します。
ノードで使用されるサービスアカウントに roles/monitoring.metricWriter 権限と roles/stackdriver.resourceMetadata.writer 権限があることを確認します。
プロジェクトに roles/container.admin と roles/iam.serviceAccountAdmin の Identity and Access Management（IAM）ロールがあることを確認します。
Hugging Face の次の前提条件を満たしていることを確認します。
1. Hugging Face アカウントを作成します。
2. Hugging Face で Llama 3.1 モデルへのアクセスをリクエストして承認を得ます。
3. Hugging Face のモデルのページでライセンス同意契約に署名します。
4. 少なくとも読み取り権限を持つ Hugging Face アクセストークンを生成します。

クラスタとノードプールを作成する

異なるリージョンに 2 つの GKE クラスタを作成し、ノードプールを構成する手順は次のとおりです。

最初のクラスタを作成します。
```
gcloud container clusters create gke-west --zone \
    CLUSTER_1_ZONE \
    --project=PROJECT_ID \
    --gateway-api=standard \
    --cluster-version=GKE_VERSION \
    --machine-type="MACHINE_TYPE" \
    --disk-type="DISK_TYPE" \
    --enable-managed-prometheus --monitoring=SYSTEM,DCGM \
    --hpa-profile=performance \
    --workload-pool=PROJECT_ID.s3ns.svc.id.goog \
    --async
```
次のように置き換えます。
- PROJECT_ID: プロジェクト ID
- CLUSTER_1_ZONE: 最初のクラスタのゾーン（europe-west3-c など）
- GKE_VERSION: 使用する GKE バージョン（1.34.1-gke.1127000 など）
- MACHINE_TYPE: クラスタノードのマシンタイプ（c2-standard-16 など）
- DISK_TYPE: クラスタノードのディスクタイプ（pd-standard など）
注: --async フラグを使用すると、コマンドがすぐに返され、バックグラウンドでクラスタが作成されます。get-credentials コマンドは、クラスタが完全にプロビジョニングされるまで待機します。
注: この例ではゾーンクラスタを使用していますが、リージョンクラスタを使用することもできます。
最初のクラスタに H100 ノードプールを作成します。
```
gcloud container node-pools create h100 \
    --accelerator "type=nvidia-h100-80gb,count=2,gpu-driver-version=latest" \
    --project=PROJECT_ID \
    --location=CLUSTER_1_ZONE \
    --node-locations=CLUSTER_1_ZONE \
    --cluster=CLUSTER_1_NAME \
    --machine-type=NODE_POOL_MACHINE_TYPE \
    --num-nodes=NUM_NODES \
    --spot \
    --min-nodes=MIN_NUM_NODES \
    --max-nodes=MAX_NUM_NODES \
    --enable-autoscaling \
    --async
```
次のように置き換えます。
- PROJECT_ID: プロジェクト ID
- CLUSTER_1_ZONE: 最初のクラスタのゾーン（europe-west3-c など）
- CLUSTER_1_NAME: 最初のクラスタの名前（gke-west など）
- NODE_POOL_MACHINE_TYPE: ノードプールのマシンタイプ（a3-highgpu-2g など）
- NUM_NODES: ノードプール内のノード数（3 など）
- MIN_NUM_NODES: ノードプール内の自動スケーリングの最小ノード数（1 など）
- MAX_NUM_NODES: ノードプール内の自動スケーリングの最大ノード数（10 など）
注: --spot フラグは、Spot VM を使用するようにノードプールを構成します。 Spot VM は費用対効果が高いですが、プリエンプトされる可能性があります。これは、AI/ML 推論ワークロードでは許容されることがよくあります。
認証情報を取得し、最初のクラスタに Hugging Face トークンシークレットを作成します。
```
gcloud container clusters get-credentials CLUSTER_1_NAME \
    --location CLUSTER_1_ZONE \
    --project=PROJECT_ID

kubectl create secret generic hf-token \
    --from-literal=token=HF_TOKEN
```
次のように置き換えます。
- PROJECT_ID: プロジェクト ID
- CLUSTER_1_NAME: 最初のクラスタの名前（gke-west など）
- CLUSTER_1_ZONE: 最初のクラスタのゾーン（europe-west3-c など）
- HF_TOKEN: Hugging Face アクセストークン

最初のクラスタとは異なるリージョンに 2 つ目のクラスタを作成します。

gcloud container clusters create gke-east --zone CLUSTER_2_ZONE \
    --project=PROJECT_ID \
    --gateway-api=standard \
    --cluster-version=GKE_VERSION \
    --machine-type="MACHINE_TYPE" \
    --disk-type="DISK_TYPE" \
    --enable-managed-prometheus \
    --monitoring=SYSTEM,DCGM \
    --hpa-profile=performance \
    --workload-pool=PROJECT_ID.s3ns.svc.id.goog \
    --async

CLUSTER_2_ZONE は、2 つ目のクラスタのゾーン（us-east4-a など）に置き換えます。

2 つ目のクラスタに H100 ノードプールを作成します。
```
gcloud container node-pools create h100 \
    --accelerator "type=nvidia-h100-80gb,count=2,gpu-driver-version=latest" \
    --project=PROJECT_ID \
    --location=CLUSTER_2_ZONE \
    --node-locations=CLUSTER_2_ZONE \
    --cluster=CLUSTER_2_NAME \
    --machine-type=NODE_POOL_MACHINE_TYPE \
    --num-nodes=NUM_NODES \
    --spot \
    --min-nodes=MIN_NUM_NODES \
    --max-nodes=MAX_NUM_NODES \
    --enable-autoscaling \
    --async
```
次のように置き換えます。
- PROJECT_ID: プロジェクト ID
- CLUSTER_2_ZONE: 2 つ目のクラスタのゾーン（us-east4-a など）
- CLUSTER_2_NAME: 2 つ目のクラスタの名前（gke-east など）
- NODE_POOL_MACHINE_TYPE: ノードプールのマシンタイプ（a3-highgpu-2g など）
- NUM_NODES: ノードプール内のノード数（3 など）
- MIN_NUM_NODES: ノードプール内の自動スケーリングの最小ノード数（1 など）
- MAX_NUM_NODES: ノードプール内の自動スケーリングの最大ノード数（10 など）
認証情報を取得し、2 つ目のクラスタに Hugging Face トークンのシークレットを作成します。
```
gcloud container clusters get-credentials CLUSTER_2_NAME \
    --location CLUSTER_2_ZONE \
    --project=PROJECT_ID
kubectl create secret generic hf-token --from-literal=token=HF_TOKEN
```
次のように置き換えます。他の変数の定義については、前の手順をご覧ください。
- HF_TOKEN: Hugging Face アクセストークン

クラスタをフリートに登録する

次のようにして、クラスタをプロジェクトのフリートに登録します。

gcloud container fleet memberships register CLUSTER_1_NAME \
    --gke-cluster CLUSTER_1_ZONE/CLUSTER_1_NAME \
    --location=global \
    --project=PROJECT_ID

gcloud container fleet memberships register CLUSTER_2_NAME \
    --gke-cluster CLUSTER_2_ZONE/CLUSTER_2_NAME \
    --location=global \
    --project=PROJECT_ID

次のように置き換えます。他の変数の定義については、前の手順をご覧ください。

CLUSTER_1_NAME: 最初のクラスタの名前（gke-west など）
CLUSTER_2_NAME: 2 つ目のクラスタの名前（gke-east など）

Multi-Cluster Ingress 機能を有効にして、構成クラスタを指定します。
```
gcloud container fleet ingress enable \
    --config-membership=projects/PROJECT_ID/locations/global/memberships/CLUSTER_1_NAME
```
次のように置き換えます。他の変数の定義については、前の手順をご覧ください。
- PROJECT_ID: プロジェクト ID
- CLUSTER_1_NAME: 最初のクラスタの名前（gke-west など）

プロキシ専用サブネットを作成する

警告: Cloud de Confiance by S3NS では、VPC ネットワークごとにリージョンごとに 1 つのプロキシ専用サブネットのみを使用できます。ターゲットリージョンに purpose=REGIONAL_MANAGED_PROXY 設定のプロキシ専用サブネットがすでに含まれている場合、GLOBAL_MANAGED_PROXY サブネットの作成は失敗します。最初に既存のリージョンプロキシ専用サブネットを削除する必要があります。リージョンプロキシ専用サブネットを削除すると、それを使用するリージョン内のリージョン Envoy ベースのロードバランサに影響するため、変更を適切に計画してください。

最初のクラスタのリージョンにサブネットを作成します。
```
gcloud compute networks subnets create CLUSTER_1_REGION-subnet \
    --purpose=GLOBAL_MANAGED_PROXY \
    --role=ACTIVE \
    --region=CLUSTER_1_REGION \
    --network=default \
    --range=SUBNET_RANGE_1 \
    --project=PROJECT_ID
```
次のように置き換えます。
- PROJECT_ID: プロジェクト ID
- CLUSTER_1_REGION: 最初のクラスタのリージョン（europe-west3 など）
- SUBNET_RANGE_1: 最初のクラスタのリージョンにあるプロキシ専用サブネットのサブネット IP 範囲（10.0.0.0/23 など）
2 つ目のクラスタのリージョンにサブネットを作成します。
```
gcloud compute networks subnets create CLUSTER_2_REGION-subnet \
    --purpose=GLOBAL_MANAGED_PROXY \
    --role=ACTIVE \
    --region=CLUSTER_2_REGION \
    --network=default \
    --range=SUBNET_RANGE_2 \
    --project=PROJECT_ID
```
次のように置き換えます。
- PROJECT_ID: プロジェクト ID
- CLUSTER_2_REGION: 2 つ目のクラスタのリージョン（us-east4 など）
- SUBNET_RANGE_2: 2 つ目のクラスタのリージョンにあるプロキシ専用サブネットのサブネット IP 範囲（10.5.0.0/23 など）

必要なカスタムリソースをインストールする

クラスタのコンテキスト変数を定義します。
```
CLUSTER1_CONTEXT="gke_PROJECT_ID_CLUSTER_1_ZONE_CLUSTER_1_NAME"
CLUSTER2_CONTEXT="gke_PROJECT_ID_CLUSTER_2_ZONE_CLUSTER_2_NAME"
```
次のように置き換えます。
- PROJECT_ID: プロジェクト ID
- CLUSTER_1_ZONE: 最初のクラスタのゾーン（europe-west3-c など）
- CLUSTER_1_NAME: 最初のクラスタの名前（gke-west など）
- CLUSTER_2_ZONE: 2 つ目のクラスタのゾーン（us-east4-a など）
- CLUSTER_2_NAME: 2 つ目のクラスタの名前（gke-east など）

両方のクラスタに InferencePool カスタムリソースと InferenceObjective カスタムリソースをインストールします。

kubectl apply -f https://github.com/kubernetes-sigs/gateway-api-inference-extension/releases/download/v1.0.1/manifests.yaml --context=$CLUSTER1_CONTEXT

kubectl apply -f https://github.com/kubernetes-sigs/gateway-api-inference-extension/releases/download/v1.0.1/manifests.yaml --context=$CLUSTER2_CONTEXT

リソースをターゲットクラスタにデプロイする

両方のクラスタにモデルサーバーをデプロイします。

kubectl apply -f \
https://raw.githubusercontent.com/kubernetes-sigs/gateway-api-inference-extension/release-1.0/config/manifests/vllm/gpu-deployment.yaml \
--context=$CLUSTER1_CONTEXT

kubectl apply -f \
https://raw.githubusercontent.com/kubernetes-sigs/gateway-api-inference-extension/release-1.0/config/manifests/vllm/gpu-deployment.yaml \
--context=$CLUSTER2_CONTEXT

次のマニフェストを inference-objective.yaml という名前のファイルに保存します。

apiVersion: inference.networking.x-k8s.io/v1alpha2
kind: InferenceObjective
metadata:
  name: food-review
spec:
  priority: 10
  poolRef:
    name: llama3-8b-instruct
    group: "inference.networking.k8s.io"

マニフェストを両方のクラスタに適用します。

kubectl apply -f inference-objective.yaml --context=$CLUSTER1_CONTEXT
kubectl apply -f inference-objective.yaml --context=$CLUSTER2_CONTEXT

Helm を使用して、InferencePool リソースを両方のクラスタにデプロイします。

helm install vllm-llama3-8b-instruct \
  --kube-context $CLUSTER1_CONTEXT \
  --set inferencePool.modelServers.matchLabels.app=vllm-llama3-8b-instruct \
  --set provider.name=gke \
  --set inferenceExtension.monitoring.gke.enabled=true \
  --version v1.0.1 \
  oci://registry.k8s.io/gateway-api-inference-extension/charts/inferencepool

helm install vllm-llama3-8b-instruct \
  --kube-context $CLUSTER2_CONTEXT \
  --set inferencePool.modelServers.matchLabels.app=vllm-llama3-8b-instruct \
  --set provider.name=gke \
  --set inferenceExtension.monitoring.gke.enabled=true \
  --version v1.0.1 \
  oci://registry.k8s.io/gateway-api-inference-extension/charts/inferencepool

両方のクラスタで、InferencePool リソースをエクスポート済みとしてマークします。

kubectl annotate inferencepool vllm-llama3-8b-instruct networking.gke.io/export="True" \
    --context=$CLUSTER1_CONTEXT

kubectl annotate inferencepool vllm-llama3-8b-instruct networking.gke.io/export="True" \
    --context=$CLUSTER2_CONTEXT

リージョンをまたぐ Inference Gateway をデプロイする

次のマニフェストを mygateway.yaml として保存します。

---
kind: Gateway
apiVersion: gateway.networking.k8s.io/v1beta1
metadata:
  name: cross-region-gateway
  namespace: default
spec:
  gatewayClassName: gke-l7-cross-regional-internal-managed-mc
  addresses:
  -   type: networking.gke.io/ephemeral-ipv4-address/europe-west3
    value: "europe-west3"
  -   type: networking.gke.io/ephemeral-ipv4-address/us-east4
    value: "us-east4"
  listeners:
  -   name: http
    protocol: HTTP
    port: 80
    allowedRoutes:
      kinds:
      -   kind: HTTPRoute
      namespaces:
        from: All
---
apiVersion: gateway.networking.k8s.io/v1beta1
kind: HTTPRoute
metadata:
  name: vllm-llama3-8b-instruct-default
spec:
  parentRefs:
  -   name: cross-region-gateway
    kind: Gateway
  rules:
  -   backendRefs:
    -   group: networking.gke.io
      kind: GCPInferencePoolImport
      name: vllm-llama3-8b-instruct
---
kind: HealthCheckPolicy
apiVersion: networking.gke.io/v1
metadata:
  name: health-check-policy
  namespace: default
spec:
  targetRef:
    group: "networking.gke.io"
    kind: GCPInferencePoolImport
    name: vllm-llama3-8b-instruct
  default:
    config:
      type: HTTP
      httpHealthCheck:
          requestPath: /health
          port: 8000

マニフェストを構成クラスタに適用します。
```
kubectl apply -f mygateway.yaml --context=CLUSTER1_CONTEXT
```
次のように置き換えます。
- CLUSTER1_CONTEXT: 最初のクラスタのコンテキスト（gke_my-project_europe-west3-c_gke-west など）

カスタム指標レポートを有効にする

次の内容で metrics.yaml という名前のファイルを作成します。

apiVersion: autoscaling.gke.io/v1beta1
kind: AutoscalingMetric
metadata:
  name: gpu-cache
  namespace: default
spec:
  selector:
    matchLabels:
      app: vllm-llama3-8b-instruct
  endpoints:
  -   port: 8000
    path: /metrics
    metrics:
    -   name: vllm:kv_cache_usage_perc
      exportName: kv-cache
    -   name: vllm:gpu_cache_usage_perc
      exportName: kv-cache-old

クラスタごとに、指標構成を適用します。
```
kubectl apply -f metrics.yaml --context=CLUSTER1_CONTEXT
kubectl apply -f metrics.yaml --context=CLUSTER2_CONTEXT
```
CLUSTER1_CONTEXT と CLUSTER2_CONTEXT の定義については、必要なカスタムリソースをインストールするをご覧ください。

ロードバランシングポリシーを構成する

このセクションでは、ロードバランシングポリシーを構成する方法について説明します。このポリシーは、カスタム指標と地域別の設定に基づいて、トラフィックを推論プールに分散する方法を定義します。次の構成では、優先リージョンとして us-east4 を設定します。us-east4 リージョンの gke.named_metrics.kv-cache カスタム指標が使用率 80% に達した場合にのみ、トラフィックが他のリージョンにオーバーフローします。

vLLM バージョン v0.10.2 以降の場合は、gke.named_metrics.kv-cache 指標を使用します。
それよりも前のバージョンでは、gke.named_metrics.kv-cache-old 指標を使用します。

次の内容で backend-policy.yaml という名前のファイルを作成します。

kind: GCPBackendPolicy
apiVersion: networking.gke.io/v1
metadata:
  name: my-backend-policy
spec:
  targetRef:
    group: "networking.gke.io"
    kind: GCPInferencePoolImport
    name: vllm-llama3-8b-instruct
  default:
    timeoutSec: 600
    balancingMode: CUSTOM_METRICS
    trafficDuration: LONG
    customMetrics:
    -   name: gke.named_metrics.kv-cache
      maxUtilizationPercent: 80
      dryRun: false
    scopes:
    -   selector:
        gke.io/region: "us-east4"
      backendPreference: PREFERRED

新しいポリシーを適用します。
```
kubectl apply -f backend-policy.yaml --context=CLUSTER1_CONTEXT
```
CLUSTER1_CONTEXT は、最初のクラスタのコンテキスト（gke_my-project_europe-west3-c_gke-west など）に置き換えます。

自動スケーリングを構成する

トラフィックが他のリージョンにオーバーフローする前に各クラスタが増加する負荷を処理できるようにするには、モデルサーバーデプロイの Horizontal-Pod-Autoscaler（HPA）を構成する必要があります。

構成の主な原則

同じカスタム指標を使用する: HPA は、GCPBackendPolicy の Multi-Cluster Inference Gateway で使用するのと同じカスタム指標（vllm:kv_cache_usage_perc など）に基づいてスケーリングするように構成する必要があります。この方法により、ロードバランシングとスケーリングの両方の決定が、推論サーバーからの同じシグナルによって行われるようになります。選択する指標の値は、使用率を表す 0 ～ 1 の範囲にする必要があります。指標の値が 1 より大きい場合、ロードバランサは 100% の使用率と解釈するため、予期しないルーティング動作が発生する可能性があります。
HPA ターゲットを低く設定する: HPA 構成の指標のターゲット値は、maxUtilizationPercent 設定よりも低く設定する必要があります。GCPBackendPolicyHPA のターゲット使用率を低く設定すると（たとえば、HPA は平均使用率 50% でスケーリング）、ロードバランサのしきい値（使用率 80% など）に達する前にクラスタがレプリカを追加できます。この方法により、優先リージョン内の容量を最大化できます。使用率のターゲットを低くすると、現在のリージョンが実際に上限に近づいたときに、リージョンをまたぐ伸縮自在な高可用性を確保することで、トラフィックの早期オーバーフローを防ぐこともできます。

必要な認可ロールを作成する権限をユーザーに付与します。

kubectl create clusterrolebinding cluster-admin-binding \
    --clusterrole cluster-admin --user "$(gcloud config get-value account)" --context=CLUSTER1_CONTEXT

kubectl create clusterrolebinding cluster-admin-binding \
    --clusterrole cluster-admin --user "$(gcloud config get-value account)" --context=CLUSTER2_CONTEXT

CLUSTER1_CONTEXT 変数と CLUSTER2_CONTEXT 変数は、必要なカスタムリソースをインストールするセクションで定義されています。

クラスタごとにマニフェストを適用します。

kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/k8s-stackdriver/master/custom-metrics-stackdriver-adapter/deploy/production/adapter_new_resource_model.yaml --context=CLUSTER1_CONTEXT

kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/k8s-stackdriver/master/custom-metrics-stackdriver-adapter/deploy/production/adapter_new_resource_model.yaml --context=CLUSTER2_CONTEXT

custom-metrics-stackdriver-adapter サービスアカウントで Cloud Monitoring の指標を読み取れるようにします。

PROJECT_NUMBER=$(gcloud projects describe PROJECT_ID --format="value(projectNumber)")

gcloud projects add-iam-policy-binding projects/PROJECT_ID \
  --role roles/monitoring.viewer \
  --member=principal://iam.googleapis.com/projects/$PROJECT_NUMBER/locations/global/workloadIdentityPools/PROJECT_ID.s3ns.svc.id.goog/subject/ns/custom-metrics/sa/custom-metrics-stackdriver-adapter

PROJECT_ID は、プロジェクト ID で置き換えます。

次のマニフェストを pod-monitoring.yaml という名前のファイルに保存します。

apiVersion: monitoring.googleapis.com/v1
kind: PodMonitoring
metadata:
  name: inference-server-podmon
spec:
  selector:
    matchLabels:
      app: vllm-llama3-8b-instruct
  endpoints:
  -   port: 8000
    path: /metrics
    interval: 5s

マニフェストを両方のクラスタに適用します。

kubectl apply -f pod-monitoring.yaml --context=CLUSTER1_CONTEXT
kubectl apply -f pod-monitoring.yaml --context=CLUSTER2_CONTEXT

次のマニフェストを hpa.yaml という名前のファイルに保存します。

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: inference-server-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: vllm-llama3-8b-instruct
  minReplicas: 1
  maxReplicas: 10
  metrics:
  -   type: Pods
    pods:
      metric:
        name: prometheus.googleapis.com|vllm:gpu_cache_usage_perc|gauge
      target:
        type: AverageValue
        averageValue: "0.5"

マニフェストを両方のクラスタに適用します。

kubectl apply -f hpa.yaml --context=CLUSTER1_CONTEXT
kubectl apply -f hpa.yaml --context=CLUSTER2_CONTEXT

デプロイを確認する

Gateway の IP アドレスを取得します。
```
export GW_IP=$(kubectl get gateway/cross-region-gateway -n default --context=CLUSTER1_CONTEXT -o jsonpath='{.status.addresses[0].value}')

echo ${GW_IP}
```
CLUSTER1_CONTEXT 変数は、必要なカスタムリソースをインストールするセクションで定義されています。
一時的な Pod でインタラクティブな sh セッションを開始します。
```
kubectl run -it --rm --image=curlimages/curl curly --context=CLUSTER1_CONTEXT -- /bin/sh
```
CLUSTER1_CONTEXT 変数は、必要なカスタムリソースをインストールするセクションで定義されています。

curly Pod 内からテストリクエストを送信します。

curl -i -X POST <var>GW_IP</var>:80/v1/completions \
-H 'Content-Type: application/json' \
-d '{
  "model": "food-review-1",
  "prompt": "What is the best pizza in the world?",
  "max_tokens": 100,
  "temperature": 0
}'

GW_IP は、前の手順で取得したゲートウェイ IP アドレスに置き換えます。

ゲートウェイの負荷テストを行う

同じ VPC ネットワーク内のロードジェネレータを使用して、Gateway IP アドレスに持続的な負荷を適用します。
優先リージョン（us-east4）で処理できると想定される適度な負荷から開始します。
負荷テストのリクエスト率または同時実行数を徐々に増やします。
負荷テストの実行中に、 Cloud de Confiance コンソールまたは kubectlを使用してシステムをモニタリングします。
- Pod のスケーリング（HPA）: 両方のクラスタの vllm-llama3-8b-instruct デプロイの Pod 数を確認します。
- ノードのスケーリング（クラスタオートスケーラー）: 両方のクラスタの h100 ノードプール内のノード数をモニタリングします。
- カスタム指標: 両方のクラスタのモデルサーバーデプロイの Monitoring で、vllm:kv_cache_usage_perc 指標（vllm バージョン v0.10.2 以降）または vllm:gpu_cache_usage_perc 指標（vllm バージョン v.0.10.2 未満）を監視します。
- ロードバランサの指標: Monitoring で cross-region-gateway に関連付けられたロードバランサの指標を確認します。

負荷を増やすと、us-east4 の使用率が増加します。gke-east クラスタの HPA がスケールアウトし、平均使用率が GCPBackendPolicy で定義されている maxUtilization 値（80%）に近づくと、ロードバランサは europe-west3 の gke-west クラスタにリクエストをルーティングし始めます。

次のステップ

GKE Gateway API の詳細を確認する。
GKE Multi-Cluster Inference Gateway の詳細を確認する。
マルチクラスタ Ingress の詳細を確認する。

弾力性のあるクロスリージョン高可用性を構成する

始める前に

クラスタとノードプールを作成する

クラスタをフリートに登録する

プロキシ専用サブネットを作成する

必要なカスタム リソースをインストールする

リソースをターゲット クラスタにデプロイする

リージョンをまたぐ Inference Gateway をデプロイする

カスタム指標レポートを有効にする

ロード バランシング ポリシーを構成する

自動スケーリングを構成する

構成の主な原則

デプロイを確認する

ゲートウェイの負荷テストを行う

次のステップ

必要なカスタムリソースをインストールする

リソースをターゲットクラスタにデプロイする

ロードバランシングポリシーを構成する