デベロッパー

TPU、GKE マネージド DRANET、マルチクラスタ推論ゲートウェイを使用したテスト

2026年6月10日

https://storage.googleapis.com/gweb-cloudblog-publish/images/0-hero-dra.max-2500x2500.png

Ammett Williams

Developer Relations Engineer

※この投稿は米国時間 2026 年 6 月 2 日に、Google Cloud blog に投稿されたものの抄訳です。

あるリージョンでワークロードに障害が発生しても、サービスを使用しなければならない場合、どうすればよいでしょう？これは、可用性や稼働時間に関してよく見られるケースです。Kubernetes エコシステムと動的リソース割り当て（DRA）や推論ゲートウェイなどの機能が最近強化されたことを受け、AI 推論ワークロードを使用した簡単なテストで、Google Cloud のこれらの機能を試してみることにしました。

このブログ投稿では、この設定について詳しくご説明します。また、こちらの Codelab（TPU、Cloud Storage FUSE、マネージド DRANET を使用してマルチクラスタ GKE Inference Gateway を構築する）で、詳細な構成をすぐに確認することもできます。

構成要素

このテストを構築するには、以下のプロダクト、機能、ツールを使用します。

Google Kubernetes Engine（GKE）マネージド DRANET: これは、Pod 間でリソースのリクエストや共有ができるマネージド機能です。GPU と TPU をサポートしています。このテストでは、2 つの異なるリージョンで TPU を使用し、マネージド DRANET を使用してネットワークを割り当てました。
マルチクラスタ GKE Inference Gateway: AI / ML 推論ワークロードを複数の GKE クラスタ間で負荷分散します。これはフェイルオーバーの状況で効果的です。今回のテストではこれを試します。このテストをサポートするタイプは、マルチクラスタクロスリージョン内部アプリケーションロードバランサ（gke-l7-cross-regional-internal-managed-mc）です。
Cloud Storage FUSE: データ、モデル、チェックポイント、ログを Cloud Storage に直接保存できるようにします。デプロイを高速化するために、オープンソースの Gemma モデルをこのストレージにダウンロードし、そこから取得するようにしました。
Virtual Private Cloud（VPC）: 分離された安全な通信を内部ロードバランサとコンピューティングノードに提供する、基盤となるグローバルネットワークです。
GKE フリート: フリートは、個別のリージョンクラスタを、統合された管理コントロールプレーン下にグループ化します。
TPU v6e: モデルのサービングに必要なハイパフォーマンスコンピューティングを提供する、Google のカスタム AI アクセラレータです。使われていた VM ファミリータイプは、2x2 スライスの ct6e-standard-4t でした。

設計パターンの例

目的は、異なるリージョンにある 2 つの GKE クラスタに LLM モデル（Gemma 3）をデプロイすることです。各クラスタは 4 つの TPU v6e チップを使用します。モデルは Cloud Storage に保存する必要があります。ワークロードは、マルチクラスタ対応の GKE Inference Gateway を使用して提供します。ユーザーに最も近いリージョンにトラフィックをルーティングする必要があります。また、いずれかのリージョンで障害が発生した場合は、もう一方のリージョンにフェイルオーバーする必要があります。

https://storage.googleapis.com/gweb-cloudblog-publish/images/1-build.max-2200x2200.png

設定手順

2 つのリージョンでプロジェクトの TPU にアクセスするには、それらのリージョンで必要な割り当てを確保しておく必要があります。

最初の手順: 環境を設定する。

予約と同じゾーンに標準 VPC を作成し、ファイアウォールルールとサブネットを設定します。
プロキシ専用サブネットを作成します。これは、GKE Inference Gateway にアタッチした内部リージョンアプリケーションロードバランサで使用されます。
トラフィックとヘルスチェックを許可するファイアウォールルールを設定します。
ゲートウェイ用に両方のリージョンで静的内部 IP アドレスを予約します。
Cloud Storage FUSE バケットをプロビジョニングし、専用の IAM サービスアカウントを構成します。これを Kubernetes Workload Identity にバインドし、Pod がバケットを安全にマウントしてモデルの重みを直接読み取れるようにします。

次の手順: 標準の GKE クラスタとノードプールを作成する。

選択したリージョンに、構成済みの 2 つの独立した GKE クラスタをデプロイします。
クラスタの作成時に、Gateway API（--gateway-api=standard）と Cloud Storage FUSE CSI ドライバ（--addons GcsFuseCsiDriver）を有効にします。
両方のクラスタに、専用の TPU v6e ノードプール（ct6e-standard-4t）を作成します。
---accelerator-network-profile=auto フラグと --node-labels=cloud.google.com/gke-networking-dra-driver=true フラグを設定し、これらの TPU ノードプールでマネージド DRANET を有効にします。

次の手順: フリート登録を介してグローバルメッシュを確立する。

フリートの作成と登録の設定の手順に沿って、統合された GKE フリートに両方の GKE クラスタを登録します。
フリートでのマルチクラスタサービスディスカバリとマルチクラスタ Ingress を有効にします。
プライマリリージョンを構成ハブとして指定し、両リージョンにわたるルーティングルールのコントロールプレーンとして機能させます。

次の手順: AI ワークロードをデプロイする。

Kubernetes の一時ジョブを使用して、Gemma 3（gemma-3-27b-it）モデルの重みを Cloud Storage バケットに直接ダウンロードします。
割り当てモードが「All」に設定されたマネージド DRANET デバイスクラス（deviceClassName: netdev.google.com）を明示的にリクエストする、ResourceClaimTemplate を定義します。

読み込んでいます...

両リージョンの TPU ノードに推論サーバー（vLLM など）をデプロイします。Pod 仕様で 2x2 TPU トポロジのノードセレクタを使用し、4 つの TPU を正確にリクエストして、netdev クレームをマウントするようにします。これにより、Pod は標準のイーサネットとともに専用のアクセラレータネットワークを確実に利用できるようになります。

次の手順: マルチクラスタ推論ゲートウェイを構成します。

必要なカスタムリソース定義（CRD）をインストールし、Kubernetes が InferenceObjective などの特殊なルーティングオブジェクトを処理できるようにします。
KV キャッシュ使用量など、ハードウェアの使用状況を追跡する、AutoscalingMetric をデプロイします。
Helm を使用して、両方のリージョンから独立した AI デプロイを、単一の論理 InferencePool にグループ化します。
クロスリージョンゲートウェイとそれに関連付けられた HTTPRoute をデプロイし、受信するグローバルトラフィックを管理します。
ヘルスチェックとバックエンドポリシーをプールに適用し、ロードバランシングでカスタムハードウェア指標を使うようにします。

InferenceObjective を構成して、過負荷状態の TPU を回避し、可用性が最も高いリージョンにプロンプトをルーティングするよう、ゲートウェイに指示します。

読み込んでいます...

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: cross-region-gateway
  namespace: default
spec:
  gatewayClassName: gke-l7-cross-regional-internal-managed-mc
  addresses:
  - type: networking.gke.io/named-address-with-region
    value: "regions/europe-west4/addresses/gemma-gateway-ip-europe-west4"
  - type: networking.gke.io/named-address-with-region
    value: "regions/us-east5/addresses/gemma-gateway-ip-us-east5"
  listeners:
  - name: http
    protocol: HTTP
    port: 80
---
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: gemma-route
  namespace: default
spec:
  parentRefs:
  - name: cross-region-gateway
    kind: Gateway
  rules:
  - backendRefs:
    - group: networking.gke.io
      kind: GCPInferencePoolImport
      name: gemma-pool
      port: 8000
---
apiVersion: networking.gke.io/v1
kind: HealthCheckPolicy
metadata:
  name: gemma-health-check
  namespace: default
spec:
  targetRef:
    group: networking.gke.io
    kind: GCPInferencePoolImport
    name: gemma-pool
  default:
    config:
      type: HTTP
      httpHealthCheck:
        requestPath: /health
        port: 8000
---
apiVersion: networking.gke.io/v1
kind: GCPBackendPolicy
metadata:
  name: gemma-backend-policy
  namespace: default
spec:
  targetRef:
    group: networking.gke.io
    kind: GCPInferencePoolImport
    name: gemma-pool
  default:
    timeoutSec: 100
    balancingMode: CUSTOM_METRICS
    trafficDuration: LONG
    customMetrics:
      - name: gke.named_metrics.tpu-cache
        dryRun: false
        maxUtilizationPercent: 60
---
apiVersion: autoscaling.gke.io/v1beta1
kind: AutoscalingMetric
metadata:
  name: tpu-cache
  namespace: default
spec:
  selector:
    matchLabels:
      app: gemma-server
  endpoints:
  - port: 8000
    path: /metrics
    metrics:
    - name: vllm:kv_cache_usage_perc
      exportName: tpu-cache
---
apiVersion: inference.networking.x-k8s.io/v1alpha2
kind: InferenceObjective
metadata:
  name: gemma-objective
  namespace: default
spec:
  priority: 10
  poolRef:
    name: gemma-pool
    group: "inference.networking.k8s.io"

フェイルオーバーのテスト

プライマリリージョンの障害をシミュレートして、高可用性アーキテクチャを検証します。プライマリのデプロイがオフラインになると、ゲートウェイは障害を自動的に検出し、その後のすべてのユーザーリクエストをアクティブなセカンダリクラスタへシームレスに再ルーティングします。これにより、トラフィックをドロップすることなく継続的な可用性が確保されます。