Hybrid CloudでAIワークロードを最適配置

**統計では企業の約9割がマルチクラウドを利用し、そのうち過半がハイブリッド構成を採用しています（Flexera 2024）。**¹ ² 一方で、AIプロジェクトはPoCから本番運用への移行でつまずきがちです。³ 公開データを突き合わせると、失敗の根は「配置」の問題に行き着きます。データ重力（データが存在する場所に計算を引き寄せる力）、レイテンシ（遅延）、GPUコスト、そして規制。⁴ これらが絡み合うため、単一クラウドやオンプレ（自社設備）単独では局所最適に陥りやすいのです。

設計で効くのは華やかなモデル選定よりも、どこで訓練し、どこで推論するかという地味な判断です。とくに大型言語モデルの微調整と低遅延推論を同時に満たすには、ハイブリッドが現実解になりやすい。オンプレの近接性とクラウドの弾力性を組み合わせると、p95（95パーセンタイル）レイテンシの短縮や、総所有コストの圧縮につながるケースが一般に報告されています。⁵ 以下では、その設計原則と実装、運用の要所を具体的に解説します。

なぜハイブリッドなのか：AI実装の物理法則

AIワークロードがハイブリッドに向かう理由は、データの偏在と計算資源の希少性にあります。オンプレに滞留する数百TB級の履歴データを毎回クラウドへ移送すると、1GBあたり数セント〜数十セントのエグレス（外向き転送料）料金が積み上がり、100TBで数千〜数万ドル規模になります。⁷ さらに法規制や契約によるデータ所在地の制約が加わると、学習データは「動かさない」前提で設計するのが合理的です。対して推論はユーザー近接と可用性がカギで、需要の波に応じたスケールアウトを考えると、複数リージョンのクラウドに載せておくのが安全です。⁶

訓練と推論の分離が生む経済合理性

学習はGPU時間単価が支配的です。スポットや割引枠を活用できるクラウドでの短期集中的な学習、あるいは高稼働を維持できるオンプレGPUでの償却効率（amortization）を最大化する運用のいずれかが有力な選択肢になります。⁸ 例えばA100クラスで1時間あたりの実効単価を比較したとき、オンプレは高稼働時に安価ですが、稼働率が落ちると一気に割高になります。⁵ これに対しクラウドは高需要時でも入手性が相対的に高く、スポット時は単価が大きく下がります。⁸ 結論として、学習は「大量データの所在に近い場所」かつ「その時点で最安のGPU時間」を選び、推論は「ユーザーとデータパスに近いエッジまたはマルチリージョン」に置くのが王道です。⁶

データ重力とレイテンシのしきい値

レイテンシのしきい値はユースケースで異なります。チャットUIのような対話的操作では、サブ秒の応答が体感品質に直結します。⁹ 一方、リアルタイム音声やロボティクスではより厳しいしきい値が求められます。モデルの前処理・後処理や機能ストアの参照を含むエンドツーエンドの遅延を見積もり、ネットワーク往復を許容できるかを判断します。軽量エンベッディングやキャッシュはクラウドに置いても、最終意思決定のAPIはオンプレ近接で提供する、といった分割が効果的です。⁴

最適配置の設計原則：SLOから逆算する

配置の議論は技術選定からではなくSLO（Service Level Objective：サービス目標）から始めます。目標p95レイテンシ、目標可用性、コスト上限、データ所在地という4軸を定義し、それぞれに制約を与えます。これを満たす配置候補を2〜3案に絞り、シンセティック負荷と実データでA/Bテストするのが実務的です。よく見られるパターンは、学習のデータ前処理と検証をオンプレで実施し、チェックポイントのみをクラウドへ同期して大規模微調整を走らせ、生成した重みをセキュアに戻して近接推論に展開する、という流れです。

コスト指標：1,000リクエストあたりの総所有コスト

コストはGPU・CPU・メモリだけでなく、ストレージI/O、ネットワークエグレス、オーケストレーションのオーバーヘッドを合算して「1,000リクエスト当たりの総所有コスト」で可視化します。この指標で比較すると、オンプレ近接推論はエグレスがゼロに近く、キャッシュヒット率が高いほど優位になります。逆にクラウド広域推論はスパイク吸収に強く、可用性目標を満たしやすいのが長所です。SLOを守りながらこの指標が最小になる組み合わせが、あなたの組織にとっての最適配置です。

データ経路：コピーではなく同期の設計

コピー主体の運用は破綻しがちです。チェックポイントや特徴量は差分同期とオブジェクトストレージのバージョニングを前提にし、片方向レプリケーションでデータ主権を守ります。メタデータは単一の真実の源泉を定め、モデルレジストリはハッシュと署名で改ざんを検知します。こうして「学習の成果物だけを動かす」設計が、ガバナンスと速度の両立に効きます。

実装リファレンス：KubernetesでハイブリッドAI

ここからは実装のスナップショットを紹介します。基盤はKubernetesを前提とし、フェデレーションや複数クラスタ運用でオンプレとクラウドを接続します。GPUスケジューリング、推論基盤、分散実行、ネットワーク、IaC、そしてスマートルーティングまで、重要点をコードで示します。

GPUノードへのスケジューリングと帯域の意識

GPUワークロードをオンプレに優先配置し、帯域を確保したいときは、ノードラベルとトレランス（許容）を併用します。以下は学習ジョブをオンプレGPUへ寄せ、クラウド側はフォールバックにする例です。

apiVersion: batch/v1
kind: Job
metadata:
  name: train-onprem-preferred
spec:
  template:
    spec:
      tolerations:
        - key: "gpu"
          operator: "Exists"
          effect: "NoSchedule"
      nodeSelector:
        site: onprem
        accelerator: nvidia
      containers:
        - name: trainer
          image: ghcr.io/org/trainer:latest
          resources:
            limits:
              nvidia.com/gpu: 2
              cpu: "8"
              memory: 32Gi
          env:
            - name: CHECKPOINT_DIR
              value: "/mnt/ckpt"
      restartPolicy: Never

併せてTopology Aware Hints（トラフィックの局所性を高めるKubernetesのヒント機構）やNetworkPolicyでデータ経路のローカリティを高め、学習とストレージの往復を局所化すると、I/O待ちによるGPU遊休を抑えられます。

推論はKServe、分散処理はRayで

推論はKServe（Kubernetes上のモデルサービング基盤）で宣言的に運用します。¹⁰ ABテストやローリングを前提にした設定です。

apiVersion: serving.kserve.io/v1beta1
kind: InferenceService
metadata:
  name: sentiment
spec:
  predictor:
    scaleTarget: 2
    minReplicas: 2
    maxReplicas: 10
    model:
      modelFormat:
        name: pytorch
      storageUri: s3://models/sentiment/v3/
      resources:
        limits:
          cpu: "4"
          memory: 8Gi
          nvidia.com/gpu: 1

分散の前処理やバッチ推論はRay（分散実行フレームワーク）が有効です。¹¹ オンプレとクラウドでノードタイプを分け、優先度を付けて実行します。

# ray-cluster values excerpt
cluster:
  name: ray-hybrid
  head:
    resources:
      limits:
        cpu: "4"
        memory: 8Gi
  workers:
    - name: onprem-gpu
      minReplicas: 2
      maxReplicas: 6
      nodeSelector:
        site: onprem
      resources:
        limits:
          nvidia.com/gpu: 1
          cpu: "8"
          memory: 32Gi
    - name: cloud-gpu
      minReplicas: 0
      maxReplicas: 10
      nodeSelector:
        site: cloud
      resources:
        limits:
          nvidia.com/gpu: 1
          cpu: "8"
          memory: 32Gi

ネットワークとIaCで安全に結ぶ

ハイブリッドの信頼性はネットワークで決まります。以下はTransit Gateway¹² とSite-to-Site VPN¹³をTerraformで定義する抜粋です。実運用ではBGPやHAの設計も加えます。

provider "aws" {
  region = "ap-northeast-1"
}
resource "aws_ec2_transit_gateway" "core" {
  description = "core-tgw"
}
resource "aws_vpn_gateway" "onprem" {
  vpc_id = aws_vpc.main.id
}
resource "aws_customer_gateway" "dc" {
  bgp_asn    = 65000
  ip_address = var.onprem_public_ip
  type       = "ipsec.1"
}
resource "aws_vpn_connection" "dc" {
  customer_gateway_id = aws_customer_gateway.dc.id
  transit_gateway_id  = aws_ec2_transit_gateway.core.id
  type                = "ipsec.1"
}

ネットワーク越しの推論先を動的に切り替えるクライアントも用意しておくと、障害時の復旧が速くなります。以下はp95レイテンシ（直近の分布に基づく95パーセンタイル）を見ながらオンプレとクラウドを切り替える最小実装です。

import time
import requests
from statistics import median

ENDPOINTS = [
    {"name": "onprem", "url": "https://onprem.example/api/infer"},
    {"name": "cloud",  "url": "https://cloud.example/api/infer"},
]
latency = {e["name"]: [1000.0] * 5 for e in ENDPOINTS}

def p95(xs):
    xs = sorted(xs)
    k = int(0.95 * (len(xs) - 1))
    return xs[k]

def choose():
    ranked = sorted(ENDPOINTS, key=lambda e: p95(latency[e["name"]]))
    return ranked[0]

def infer(payload):
    ep = choose()
    t0 = time.perf_counter()
    r = requests.post(ep["url"], json=payload, timeout=5)
    dt = (time.perf_counter() - t0) * 1000
    arr = latency[ep["name"]]
    arr.pop(0); arr.append(dt)
    r.raise_for_status()
    return r.json()

学習のパイプラインはクラウド側でスパイク時のみ起動し、成果物だけを戻すのが安全です。Argo Workflowsの例を示します。

apiVersion: argoproj.io/v1alpha1
kind: Workflow
metadata:
  generateName: finetune-
spec:
  entrypoint: main
  templates:
    - name: main
      dag:
        tasks:
          - name: preprocess
            template: prep
          - name: train
            template: train
            dependencies: [preprocess]
          - name: publish
            template: publish
            dependencies: [train]
    - name: prep
      container:
        image: ghcr.io/org/preprocess:latest
    - name: train
      container:
        image: ghcr.io/org/finetune:cuda
        resources:
          limits:
            nvidia.com/gpu: 4
    - name: publish
      container:
        image: ghcr.io/org/publish:latest
        env:
          - name: DEST
            value: s3://models/my-model/

この構成により、学習はクラウドの弾力性を、推論はオンプレの近接性を活かせます。ネットワークとレジストリを信頼の基盤に据えるのがポイントです。

運用：SLA、コスト、セキュリティを回す

ハイブリッド運用は、監視とテストの仕組みづくりが9割です。GPUの学習稼働率は60〜85%を目安に、I/O待ちやフェッチでのアイドルを可視化します。推論ではp95やp99のテール（遅延分布の上位側）がSLOを壊しやすいため、CPUスロットリングやメモリ圧迫、同時接続の上限に敏感になります。モデルごとのスロット設計とレプリカのウォームアップを仕込むと、コールドスタートを抑えられます。

観測と負荷試験：p95を落とさない

負荷試験は継続運用の一部です。シンセティックなトラフィックでキャッシュとレプリカを温め、本番前にp95を確認します。単純な例ですが、以下はvegeta（HTTP負荷試験ツール）を使った計測です。¹⁴ 結果をS3に残して回帰を検知します。

echo "POST https://onprem.example/api/infer" | vegeta attack -duration=60s -rate=200 | tee results.bin | vegeta report
vegeta plot results.bin > p95.html

観測面では、PrometheusでGPU使用率、処理時間、エラー率、キュー長を集約し、GrafanaでSLOダッシュボードを維持します。KServeやIstioのメトリクスと合わせて、ネットワーク遅延とアプリ遅延を分離すると、ボトルネックの特定が速くなります。

コストの自動ブレーキとガバナンス

予算超過は自動で止めます。クラウド側は予算アラートと一時停止フック、オンプレ側はキュー深度に応じたジョブ受付のスロットルを組み込みます。Kubernetesではポリシーエンジンでガードレールを定義できます。以下はKyverno（Kubernetesのポリシーエンジン）で高額GPUの無制限使用を防ぐ簡易ポリシーです。

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: limit-gpu
spec:
  rules:
    - name: require-gpu-limits
      match:
        resources:
          kinds:
            - Pod
      validate:
        message: "GPU Podはlimitsを設定してください"
        pattern:
          spec:
            containers:
              - resources:
                  limits:
                    nvidia.com/gpu: "?*"
    - name: cap-gpu-count
      match:
        resources:
          kinds:
            - Pod
      validate:
        message: "GPUは最大2枚まで"
        deny:
          conditions:
            any:
              - key: "{{ request.object.spec.containers[0].resources.limits['nvidia.com/gpu'] }}"
                operator: GreaterThan
                value: 2

セキュリティはゼロトラストを基本に、ワークロードIDで相互TLS、機密はKMSと短期トークンで配布します。モデルやデータの出自をSBOM（ソフトウェア部品表）・SLSA（ソフトウェア供給網保証）レベルで管理し、署名検証をAdmissionで必須化すると、サプライチェーンの攻撃面を狭められます。¹⁵ ¹⁶ ¹⁷ 詳細はAI実装の関連記事も参照してください。

まとめ：配置は戦略、実装は地道に

AIにおけるハイブリッドクラウドは、万能薬ではなく現実解です。データは動かさず、学習は弾力的に、推論は近接で低遅延という原則に従うだけで、初期の躓きの多くは回避できます。SLOを先に決め、1,000リクエスト当たりの総所有コストで比較し、A/Bで測る。この繰り返しが最適配置を磨き上げます。

**次のスプリントでは、推論のp95と可用性、そして月次のGPU予算をダッシュボードに載せ、クラウドとオンプレの配賦比率を1回だけ見直してください。**もし数値が動かなければ、データ経路かキャッシュ設計が詰まりです。今日示したスニペットを叩き台に、チームの実情へ合わせて手を動かしてみませんか。配置は戦略ですが、結果は計測からしか生まれません。