クロスリージョン・マルチクラスターフリートにおける在庫認識型の弾性スケジューリング - Container Service for Kubernetes

複数リージョンにまたがるアプリケーションデプロイメントでは、異なるリージョン間のリソース割り当ての管理が課題となることがあります。この課題に対処するため、ACK One は、マルチクラスターフリート向けのインテリジェントな在庫認識スケジューラを提供します。このトピックでは、在庫認識スケジューリングの仕組みと、フリートでこの機能を有効にする方法について説明します。

概要

GPU 推論ワークロードを提供する際、ユーザーは主に 2 つの課題に直面します。

動的な GPU 可用性： GPU リソースの供給はリージョン間で変動するため、リアルタイムでの可用性を保証することが困難です。
GPU の高コスト： 将来的な需要に対応するために GPU ノードを事前にプロビジョニングすると、多額の不要なコストが発生する可能性があります。

在庫認識スケジューリングの仕組みは、即時スケーリングと組み合わせることで、これらの 2 つの課題に効果的に対処します。フリートのメンバークラスター内の既存リソースが新しいアプリケーションをスケジュールするには不十分な場合、スケジューラは GPU 在庫が利用可能なリージョンにあるクラスターにワークロードをインテリジェントに配置します。その後、そのクラスターの即時スケーリング機能が必要なノードをオンデマンドでプロビジョニングします。

この機能により、GPU などの希少なリソースに依存するアプリケーションのスケジューリング成功率を最大化すると同時に、運用コストを大幅に削減できます。

重要

この機能は現在プレビュー段階です。ご利用になるには、チケットを送信してください。

仕組み

アプリケーションがフリートにデプロイされ、メンバークラスターのリソースが不足している場合、次のワークフローがトリガーされます。

フリートのコントロールプレーンで、アプリケーションとその伝播ポリシーが作成されます。
スケジューラは、ターゲットのメンバークラスターに必要なリソースが不足していることを検出します。
スケジューラは、メンバークラスターのスケーラー (ACK GOATScaler) にクエリを実行し、そのリージョンで利用可能な GPU 在庫を確認します。
在庫レポートに基づいて、スケジューラは配置決定を再評価し、在庫が利用可能なクラスターにアプリケーションをディスパッチします。
アプリケーションがターゲットクラスターにディスパッチされると、即時スケーリング機能が新しいノードをプロビジョニングし、アプリケーションの Pod がスケジュールされて実行を開始します。

前提条件

フリートインスタンスに複数のメンバークラスターを関連付けていること。
メンバークラスターでノードの即時スケーリングを有効化していること。
重要
メンバークラスターが現在自動スケーリングで構成されている場合は、ノードの即時スケーリングに切り替えてください。
AMC コマンドラインツールをインストールしていること。

GPU インスタンスの仕様と推定コスト

推論フェーズでは、GPU メモリはモデルパラメーターによって占有されます。使用量は次の数式で計算されます。

$GP U m e m ory = M o d e l p a r am e t er co u n t * P rec i s i o n d a t a b y t es$

デフォルトの FP16 精度を持つ 7B モデルを例にとると、モデルパラメーター数は 70 億、パラメーターあたりのバイトサイズは 2 バイト (デフォルトは 16 ビット浮動小数点数/バイトあたり 8 ビット) です。

$GP U m e m ory = 7 * 1 0^{9} * 2 b y t es \approx 13.04 G i B$

モデルのロードに使用されるメモリに加えて、Key-Value (KV) キャッシュのサイズと GPU 使用率も考慮する必要があります。通常、メモリの一部はバッファリング用に予約されます。したがって、ecs.gn7i-c8g1.2xlarge や ecs.gn7i-c16g1.4xlarge のように 24 GiB のメモリを提供するインスタンスタイプを使用することを推奨します。詳細については、「GPU コンピューティング最適化インスタンスファミリー」および「Elastic GPU Service の課金」をご参照ください。

ステップ 1：モデルデータの準備

このステップでは、Qwen-8B モデルファイルを準備し、各メンバークラスターに対応する Object Storage Service (OSS) の永続ボリューム (PV) を作成します。

モデルをダウンロードします。
説明
git-lfs プラグインがインストールされているかどうかを確認してください。インストールされていない場合は、yum install git-lfs または apt-get install git-lfs を実行してインストールします。詳細については、「git-lfs のインストール」をご参照ください。
```
git lfs install
GIT_LFS_SKIP_SMUDGE=1 git clone https://huggingface.co/Qwen/Qwen3-8B
cd Qwen3-8B
git lfs pull
```
OSS にフォルダを作成し、モデルをアップロードします。
説明
ossutil のインストールと使用方法の詳細な手順については、「ossutil のインストール」をご参照ください。
```
ossutil mkdir oss://<your-bucket-name>/models/Qwen3-8B
ossutil cp -r ./Qwen3-8B oss://<your-bucket-name>/models/Qwen3-8B
```

各メンバークラスターに PV と PersistentVolumeClaim (PVC) を作成し、OSS からモデルファイルをマウントします。詳細については、「ossfs 1.0 の静的プロビジョニングされたボリュームの使用」をご参照ください。

YAML テンプレート

apiVersion: v1
kind: Secret
metadata:
  name: oss-secret
stringData:
  akId: <your-oss-ak> # OSS へのアクセスに使用する AccessKey ID。
  akSecret: <your-oss-sk> # OSS へのアクセスに使用する AccessKey Secret。
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: qwen3-8b
  namespace: default
spec:
  accessModes:
    - ReadWriteMany
  resources:
    requests:
      storage: 20Gi
  selector:
    matchLabels:
      alicloud-pvname: qwen3-8b
  storageClassName: oss
  volumeMode: Filesystem
  volumeName: qwen3-8b
---
apiVersion: v1
kind: PersistentVolume
metadata:
  labels:
    alicloud-pvname: qwen3-8b
  name: qwen3-8b
spec:
  accessModes:
    - ReadWriteMany
  capacity:
    storage: 20Gi
  csi:
    driver: ossplugin.csi.alibabacloud.com
    nodePublishSecretRef:
      name: oss-secret
      namespace: default
    volumeAttributes:
      bucket: <your-bucket-name> # バケット名。
      otherOpts: '-o allow_other -o umask=000'
      path: <your-model-path> # この例では、パスは /models/Qwen3-8B/ です。
      url: <your-bucket-endpoint> # エンドポイント (例：oss-cn-hangzhou-internal.aliyuncs.com)。
    volumeHandle: qwen3-8b
  persistentVolumeReclaimPolicy: Retain
  storageClassName: oss
  volumeMode: Filesystem

ステップ 2：メンバークラスターのノードプールの設定

各メンバークラスターで、次の設定でノードプールを作成または編集します。

[インスタンスタイプ]： ecs.gn7i-c8g1.2xlarge (または他の適切な GPU インスタンスタイプ)
スケーリングモード：自動
想定ノード数： 0

その他の操作とパラメーター設定については、「ノードプールの作成と管理」をご参照ください。

ノードのスケーリング設定を調整する際、スケールインの遅延パラメーターを調整して、後続のステップの待機時間を短縮できます。

ステップ 3：フリートクラスターでのアプリケーションと伝播ポリシーの作成

推論サービスデプロイを定義するために、deploy.yaml という名前のファイルを作成します。

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: qwen3-8b
  name: qwen3-8b
  namespace: default
spec:
  replicas: 4
  selector:
    matchLabels:
      app: qwen3-8b
  template:
    metadata:
      labels:
        app: qwen3-8b
    spec:
      volumes:
        - name: qwen3-8b
          persistentVolumeClaim:
            claimName: qwen3-8b
        - name: dshm
          emptyDir:
            medium: Memory
            sizeLimit: 20Gi
      containers:
      - command:
        - sh
        - -c
        - vllm serve /models/qwen3-8b --port 8000 --trust-remote-code --served-model-name qwen3-8b --tensor-parallel=1 --max-model-len 8192 --gpu-memory-utilization 0.95 --enforce-eager
        image: kube-ai-registry.cn-shanghai.cr.aliyuncs.com/kube-ai/vllm-openai:v0.9.1
        name: vllm
        ports:
        - containerPort: 8000
        readinessProbe:
          tcpSocket:
            port: 8000
          initialDelaySeconds: 30
          periodSeconds: 30
        resources:
          limits:
            nvidia.com/gpu: "1"
        volumeMounts:
          - mountPath: /models/qwen3-8b
            name: qwen3-8b
          - mountPath: /dev/shm
            name: dshm

PropagationPolicy.yaml という名前のファイルを作成します。キーフィールド autoScaling.ecsProvision: true は、インベントリを考慮したスケジューリングを有効にします。

apiVersion: policy.one.alibabacloud.com/v1alpha1
kind: PropagationPolicy
metadata:
  name: demo-policy
spec:
  # このフィールドは、在庫認識型の弾性スケジューリングを有効にします。
  autoScaling:
    ecsProvision: true
  preserveResourcesOnDeletion: false
  conflictResolution: Overwrite
  resourceSelectors:
  - apiVersion: apps/v1
    kind: Deployment
    name: qwen3-8b
    namespace: default
  placement:
    replicaScheduling:
      replicaSchedulingType: Divided
      weightPreference:
        dynamicWeight: AvailableReplicas
    clusterAffinity:
      clusterNames:
      - ${cluster1-id} # ご利用のメンバークラスター ID に置き換えてください。
      - ${cluster2-id} # ご利用のメンバークラスター ID に置き換えてください。

フリートの kubeconfig ファイルを使用して、アプリケーションとその伝播ポリシーをデプロイします。
```
kubectl apply -f deploy.yaml
kubectl apply -f PropagationPolicy.yaml
```
しばらくすると、メンバークラスターの GPU ノードプールが自動的にスケールアップを開始します。

ステップ 4：弾性スケーリングの検証

フリート内のワークロードのスケジューリングステータスを確認します。
```
kubectl get resourcebinding
```
期待される出力：
```
NAME                  SCHEDULED   FULLYAPPLIED   OVERRIDDEN   ALLAVAILABLE   AGE
qwen3-8b-deployment   True        True           True         False          7m47s
```
出力は SCHEDULED が TRUE であることを示しており、ワークロードが正常にスケジュールされたことを意味します。
Pod が Running 状態になったら、メンバークラスター間での分散状況を確認します。
```
kubectl amc get deploy qwen3-8b -M
```
期待される出力：
```
NAME       CLUSTER           READY   UP-TO-DATE   AVAILABLE   AGE     ADOPTION
qwen3-8b   cxxxxxxxxxxxxxx   2/2     2            2           3m22s   Y
qwen3-8b   cxxxxxxxxxxxxxx   2/2     2            2           3m22s   Y
```
この出力は、メンバークラスターに当初利用可能な GPU ノードがなかったにもかかわらず、すべてのレプリカがスケジュールされ、実行されていることを示しています。
deploy.yaml ファイルを更新して qwen3-8b のレプリカ数を 2 にスケールダウンし、再適用します。
または、ワークロードを削除して、レプリカ数が 0 にスケールダウンされるシナリオをシミュレートすることもできます。
```
kubectl apply -f deploy.yaml
```
約 10 分後、メンバークラスターの GPU ノードプールは自動的にスケールダウンして未使用のノードを解放し、コストを削減します。
ワークロードを削除した場合、ノード数は 0 にスケールダウンされます。