AHPA 予測 Autoscaling による GPU 枯渇防止と Kubernetes ワークロード最適化 - ACK

周期的なトラフィックや Pod の初期化に時間がかかる GPU 推論ワークロードは、スケーリングの問題を引き起こします。標準の HPA は、使用率のしきい値を超えてから初めて反応するため、リソースの枯渇やレイテンシーの急増を回避するには手遅れになる可能性があります。Advanced Horizontal Pod Autoscaler (AHPA) は、Prometheus からのリアルタイム GPU メトリック、既存の負荷傾向、および予測アルゴリズムを組み合わせることで、需要が発生する前に Pod をプロアクティブにスケーリングし、この問題を解決します。

ワークロードに次の特性のいずれかまたは複数が含まれる場合は、このガイドを使用してください。

周期的または時間帯によるトラフィックパターン (例: 営業時間中の高い GPU 使用率、夜間のアイドル状態)
初期化にかなりの時間を要する Pod。リアクティブなスケールアウト中にレイテンシーの急増を引き起こします。
GPU がアイドル状態のときに正確なスケールインを必要とするコスト感度

前提条件

開始する前に、以下を確保してください。

GPU アクセラレーションノードを備えた Container Service for Kubernetes (ACK) マネージドクラスター。詳細については、「GPU アクセラレーションノードを使用した ACK クラスターの作成」をご参照ください。
AHPA がインストールされ、データソースが設定されていること。詳細については、「AHPA の概要」をご参照ください。
Managed Service for Prometheus が有効になっており、GPU リソース使用量の詳細を含む少なくとも 7 日間のアプリケーション統計が収集されていること。

重要

AHPA の予測品質は、既存データに直接依存します。7 日間のデータ収集期間をスキップしたり短縮したりしないでください。履歴が不十分だと不正確な予測が生成され、AHPA がレプリカをプロビジョニング不足またはプロビジョニング過多にする可能性があります。

仕組み

Managed Service for Prometheus は、ご利用のワークロードからリアルタイム GPU 使用率とメモリ使用量を収集します。Prometheus Adapter はこれらのメトリックを Kubernetes が認識する形式に変換し、AHPA に公開します。AHPA は、現在のメトリックと既存の負荷傾向および予測アルゴリズムを組み合わせることで、GPU の将来の需要を予測し、使用率が急増する前ではなく、急増する前に Pod をスケーリングします。

しきい値を超えてからスケーリングする標準の HPA とは異なり、AHPA はリソースが枯渇する前にスケールアウトを完了し、GPU がアイドル状態のときに自動的にスケールインします。

ステップ 1: メトリックアダプターのデプロイ

クラスターの Prometheus インスタンスの内部 HTTP API エンドポイントを取得します。
1. ARMS コンソールにログインします。
2. 左側のナビゲーションウィンドウで、[Managed Service For Prometheus] > [Instances] を選択します。
3. 「インスタンス」ページの上部で、ACK クラスターが配置されているリージョンを選択します。
4. Managed Service for Prometheus インスタンスの名前をクリックします。インスタンス詳細ページの左側のナビゲーションウィンドウで、[設定項目] をクリックし、[HTTP API URL] セクションに表示されているエンドポイントを控えておきます。
ack-alibaba-cloud-metrics-adapter をデプロイします。
1. ACKコンソールにログインします。左側のナビゲーションウィンドウで、[マーケットプレイス] > [マーケットプレイス] を選択します。
2. [マーケットプレイス] ページで、[アプリカタログ] タブをクリックし、ack-alibaba-cloud-metrics-adapter を見つけてクリックします。
3. 「ack-alibaba-cloud-metrics-adapter」ページの右上隅で、[デプロイ] をクリックします。
4. [基本情報] ページで、[クラスタ] および [名前空間] を指定し、[次へ] をクリックします。
5. [パラメーター] ページで、[チャートバージョン] を設定し、前のステップで記録した内部HTTP APIエンドポイントをprometheus.urlパラメーターの値として入力します。[OK] をクリックします。

ステップ 2: GPU ベースの予測スケーリングのための AHPA の設定

この例では、BERT 意図検出推論サービスをデプロイし、GPU 使用率が 20% を超えたときに Pod をスケーリングするように AHPA を設定します。

推論サービスのデプロイ

推論サービスをデプロイします。

cat <<EOF | kubectl create -f -
apiVersion: apps/v1
kind: Deployment
metadata:
  name: bert-intent-detection
spec:
  replicas: 1
  selector:
    matchLabels:
      app: bert-intent-detection
  template:
    metadata:
      labels:
        app: bert-intent-detection
    spec:
      containers:
      - name: bert-container
        image: registry.cn-hangzhou.aliyuncs.com/ai-samples/bert-intent-detection:1.0.1
        ports:
        - containerPort: 80
        resources:
          limits:
            cpu: "1"
            memory: 2G
            nvidia.com/gpu: "1"
          requests:
            cpu: 200m
            memory: 500M
            nvidia.com/gpu: "1"
---
apiVersion: v1
kind: Service
metadata:
  name: bert-intent-detection-svc
  labels:
    app: bert-intent-detection
spec:
  selector:
    app: bert-intent-detection
  ports:
  - protocol: TCP
    name: http
    port: 80
    targetPort: 80
  type: LoadBalancer
EOF

Pod が実行中であることを確認します。

kubectl get pods -o wide

予想される出力:

NAME                                    READY   STATUS    RESTARTS   AGE     IP           NODE                        NOMINATED NODE   READINESS GATES
bert-intent-detection-7b486f6bf-f****   1/1     Running   0          3m24s   10.15.1.17   cn-beijing.192.168.94.107   <none>           <none>

推論サービスをテストします。まず外部 IP アドレスを取得します。

kubectl get svc bert-intent-detection-svc

47.95.XX.XX を返された IP アドレスに置き換えてから、テストリクエストを送信します。

curl -v "http://47.95.XX.XX/predict?query=Music"

予想される出力:

*   Trying 47.95.XX.XX...
* TCP_NODELAY set
* Connected to 47.95.XX.XX (47.95.XX.XX) port 80 (#0)
> GET /predict?query=Music HTTP/1.1
> Host: 47.95.XX.XX
> User-Agent: curl/7.64.1
> Accept: */*
>
* HTTP 1.0, assume close after body
< HTTP/1.0 200 OK
< Content-Type: text/html; charset=utf-8
< Content-Length: 9
< Server: Werkzeug/1.0.1 Python/3.6.9
< Date: Wed, 16 Feb 2022 03:52:11 GMT
<
* Closing connection 0
PlayMusic

HTTP 200 とクエリ結果は、推論サービスが実行中であることを確認します。

AHPA のデータソースの設定

次の内容で application-intelligence.yaml という名前のファイルを作成します。prometheusUrl をステップ 1 で記録した内部エンドポイントに設定します。

apiVersion: v1
kind: ConfigMap
metadata:
  name: application-intelligence
  namespace: kube-system
data:
  prometheusUrl: "http://cn-shanghai-intranet.arms.aliyuncs.com:9090/api/v1/prometheus/da9d7dece901db4c9fc7f5b*******/1581204543170*****/c54417d182c6d430fb062ec364e****/cn-shanghai"

ConfigMap を適用します。

kubectl apply -f application-intelligence.yaml

AHPA のデプロイ

次の内容で fib-gpu.yaml という名前のファイルを作成します。この例では、AHPA が予測データを収集するだけで、それに基づいてアクションを実行しない observer モードを使用します。自動スケーリングを有効にする前に予測を検証するには、observer モードを使用します。完全なパラメーターリファレンスについては、「パラメーター」をご参照ください。

apiVersion: autoscaling.alibabacloud.com/v1beta1
kind: AdvancedHorizontalPodAutoscaler
metadata:
  name: fib-gpu
  namespace: default
spec:
  metrics:
  - resource:
      name: gpu
      target:
        averageUtilization: 20   # Scale when average GPU utilization across pods exceeds 20%
        type: Utilization
    type: Resource
  minReplicas: 0
  maxReplicas: 100
  prediction:
    quantile: 95                 # Use the 95th percentile of historical values (conservative estimate)
    scaleUpForward: 180          # Start scaling 180 seconds before predicted demand peaks
  scaleStrategy: observer        # observer: collect predictions without scaling; change to auto to enable scaling
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: bert-intent-detection
  instanceBounds:                # Time-based replica bounds that override minReplicas/maxReplicas during each window
  - startTime: "2021-12-16 00:00:00"
    endTime: "2022-12-16 00:00:00"
    bounds:
    - cron: "* 0-8 ? * MON-FRI"    # Off-peak hours: allow scale-in to 4 replicas
      maxReplicas: 50
      minReplicas: 4
    - cron: "* 9-15 ? * MON-FRI"   # Business hours: keep at least 10 replicas
      maxReplicas: 50
      minReplicas: 10
    - cron: "* 16-23 ? * MON-FRI"  # Evening peak: keep at least 12 replicas
      maxReplicas: 50
      minReplicas: 12

主要なパラメーター:

パラメーター	説明
`averageUtilization`	AHPA の対象となる全 Pod のスケーリングをトリガーする GPU 使用率のしきい値 (%)
`quantile`	予測を生成するために使用される既存データのパーセンタイル。値が高いほど控えめな見積もりとなり、プロビジョニング不足のリスクを軽減します。
`scaleUpForward`	AHPA が予測される需要のピークの何秒前にスケーリングを開始するか
`scaleStrategy`	`observer`: 予測とレポートのみ。`auto`: 予測と実行。
`instanceBounds`	特定の時間枠における Cron ベースのレプリカの下限と上限のオーバーライド

AHPA をデプロイします。
```
kubectl apply -f fib-gpu.yaml
```

AHPA ステータスを確認します。

kubectl get ahpa

予想される出力:

NAME             STRATEGY   REFERENCE               METRIC   TARGET(%)   CURRENT(%)   DESIREDPODS   REPLICAS   MINPODS   MAXPODS   AGE
fib-gpu          observer   bert-intent-detection   gpu      20          0            0             1          10        50        6d19h

CURRENT(%) は 0 であり、TARGET(%) の 20 を超えるとスケーリングがトリガーされることを示しています。

ステップ 3: オートスケーリングのテストと予測の評価

負荷の生成

fib-loader をデプロイして、推論サービスに継続的なリクエストを送信します。

kubectl apply -f - <<EOF
apiVersion: apps/v1
kind: Deployment
metadata:
  name: fib-loader
  namespace: default
spec:
  progressDeadlineSeconds: 600
  replicas: 1
  revisionHistoryLimit: 10
  selector:
    matchLabels:
      app: fib-loader
  strategy:
    rollingUpdate:
      maxSurge: 25%
      maxUnavailable: 25%
    type: RollingUpdate
  template:
    metadata:
      creationTimestamp: null
      labels:
        app: fib-loader
    spec:
      containers:
      - args:
        - -c
        - |
          /ko-app/fib-loader --service-url="http://bert-intent-detection-svc.${NAMESPACE}/predict?query=Music" --save-path=/tmp/fib-loader-chart.html
        command:
        - sh
        env:
        - name: NAMESPACE
          valueFrom:
            fieldRef:
              apiVersion: v1
              fieldPath: metadata.namespace
        image: registry.cn-huhehaote.aliyuncs.com/kubeway/knative-sample-fib-loader:20201126-110434
        imagePullPolicy: IfNotPresent
        name: loader
        ports:
        - containerPort: 8090
          name: chart
          protocol: TCP
        resources:
          limits:
            cpu: "8"
            memory: 16000Mi
          requests:
            cpu: "2"
            memory: 4000Mi
EOF

スケーリング動作の確認

負荷がかかった状態での AHPA ステータスを確認します。

kubectl get ahpa

予想される出力:

NAME             STRATEGY   REFERENCE               METRIC   TARGET(%)   CURRENT(%)   DESIREDPODS   REPLICAS   MINPODS   MAXPODS   AGE
fib-gpu          observer   bert-intent-detection   gpu      20          189          10            4          10        50        6d19h

CURRENT(%) は 189 であり、TARGET(%) の 20 を超えています。AHPA は 10 個の Pod (DESIREDPODS) へのスケーリングを推奨しています。scaleStrategy が observer であるため、実際のスケーリングはまだ発生しません。

予測結果の確認

予測された GPU 使用率と実際の GPU 使用率を比較するために、予測チャートを取得します。

kubectl get --raw '/apis/metrics.alibabacloud.com/v1beta1/namespaces/default/predictionsobserver/fib-gpu'|jq -r '.content' |base64 -d > observer.html

observer.html を開いて、過去 7 日間の GPU データに基づく予測結果を確認します。

チャートには 2 つのビューが含まれています。

Predict GPU Resource Observer: 青い線は実際の GPU 使用率を示し、緑の線は AHPA の予測を示します。適切に調整された予測は、十分な容量が確保されていることを確認するために、実際の使用率よりわずかに上で実行されます。
Predict POD Observer: 青い線はスケーリングイベントからの実際のレプリカ数を示し、緑の線は AHPA の予測レプリカ数を示します。予測された Pod 数が実際の数よりも少ない場合、auto モードに切り替えることで、AHPA はより効率的に事前スケーリングし、プロビジョニング過多を削減できます。

自動スケーリングへの切り替え

auto モードに切り替える前に、予測チャートを確認します。予測は、次の両方の条件が真の場合に準備ができています。

予測された GPU 使用率 (緑の線) が、プロビジョニング過多を示す大きなギャップなしに、実際の使用率 (青の線) を一貫して上回り、かつそれに近い状態であること。
予測された Pod 数 (緑の線) が、いくつかのビジネスサイクルにわたって実際のスケーリングイベント (青の線) に近似していること。

予測が安定したら、fib-gpu.yaml の scaleStrategy を更新します。

scaleStrategy: auto

変更を適用します。

kubectl apply -f fib-gpu.yaml

auto モードがアクティブになると、AHPA は GPU 使用率のしきい値が超えられるのを待つのではなく、予測に基づいて Pod をスケーリングします。

次のステップ

Knative を使用したサーバーレス GPU 推論: AHPA はサーバーレス Kubernetes (ASK) クラスターで動作します。周期的なトラフィックパターンを持つワークロードの場合、AHPA はリソース変更を予測し、容量をプリフェッチしてコールドスタートの影響を軽減します。詳細については、「AHPA を使用して Knative で予測スケーリングを有効にする」をご参照ください。
カスタムメトリックベースのスケーリング: HTTP QPS、メッセージキューの長さ、またはその他のアプリケーションメトリックに基づいてスケーリングするには、alibaba-cloud-metrics-adapter とともに外部メトリックメカニズムを使用します。詳細については、「AHPA を使用してアプリケーションスケーリングのカスタムメトリックを構成する」をご参照ください。