Container Compute Service:AHPA を使用したリソース需要の予測と適用

前提条件

開始する前に、以下の条件を満たしていることを確認してください。

• ACS クラスター。詳細については、「ACS クラスターの作成」をご参照ください。

• クラスターに対して Managed Service for Prometheus が有効化されていること。詳細については、「Managed Service for Prometheus を使用した ACS クラスターのモニタリング」をご参照ください。

仕組み

AHPA は、Managed Service for Prometheus を通じて履歴メトリックデータを収集し、機械学習アルゴリズムを適用して、今後 24 時間における必要なポッド数を予測します。この予測には、相互に補完し合う 2 種類のモードが提供されます。

• 能動的予測（Proactive prediction） — 予測される需要ピーク到来前にポッドをスケールアウトし、コールドスタート遅延を吸収するためにリソースをプリフェッチします。

• リアクティブ予測 — 標準 HPA と同様に、リアルタイムのメトリック信号に応答します。

任意の時点において、AHPA は能動的予測、受動的予測、および現在のタイムウィンドウ内で instanceBounds に定義された最大・最小ポッド数に基づき、推奨されるポッド数を提示します。この推奨値は、自動スケーリングを有効化する前に AHPA ダッシュボードで確認できます。

ステップ 1：AHPA コントローラーのインストール

1. ACS コンソールにログインします。左側ナビゲーションウィンドウで、[クラスター] をクリックします。

2. [クラスター] ページで、管理するクラスターの ID をクリックします。クラスターの詳細ページの左側のナビゲーションウィンドウで、[操作] ＞ [アドオン] を選択します。

3. [アドオン] ページで、[その他] タブをクリックします。[AHPA コントローラー] を見つけ、[インストール] をクリックします。画面上の指示に従って、インストールを完了します。

ステップ 2：Prometheus を AHPA のデータソースとして追加

AHPA は、Managed Service for Prometheus インスタンスの内部エンドポイントを用いて履歴メトリックデータを取得します。本ステップでは、このエンドポイントを記録し、クラスター内に ConfigMap を作成してエンドポイントを登録したうえで、Prometheus に AHPA を監視対象コンポーネントとして登録します。

ステップ 3：テストサービスのデプロイ

AHPA の予測結果と標準 HPA のスケーリング動作を比較可能なテスト環境を構築します。この環境には以下の要素が含まれます。

• fib-deployment — スケーリング対象のワークロード

• fib-svc — fib-deployment を公開するサービス

• fib-loader — トラフィック変動をシミュレートするロードジェネレーター

• fib-hpa — CPU 使用率 50% のときに fib-deployment をスケールする標準的な HPA。ベースラインとして使用されます。

1. 以下の内容で demo.yaml というファイルを作成します。

   apiVersion: apps/v1
   kind: Deployment
   metadata:
     name: fib-deployment
     namespace: default
   spec:
     replicas: 1
     selector:
       matchLabels:
         app: fib-deployment
     strategy:
       rollingUpdate:
         maxSurge: 25%
         maxUnavailable: 25%
       type: RollingUpdate
     template:
       metadata:
         creationTimestamp: null
         labels:
           app: fib-deployment
       spec:
         containers:
         - image: registry.cn-huhehaote.aliyuncs.com/kubeway/knative-sample-fib-server:20200820-171837
           imagePullPolicy: IfNotPresent
           name: user-container
           ports:
           - containerPort: 8080
             name: user-port
             protocol: TCP
           resources:
             limits:
               cpu: "1"
               memory: 2000Mi
             requests:
               cpu: "1"
               memory: 2000Mi
   ---
   apiVersion: v1
   kind: Service
   metadata:
     name: fib-svc
     namespace: default
   spec:
     ports:
     - name: http
       port: 80
       protocol: TCP
       targetPort: 8080
     selector:
       app: fib-deployment
     sessionAffinity: None
     type: ClusterIP
   ---
   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://fib-svc.${NAMESPACE}?size=35&interval=0" --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
   ---
   apiVersion: autoscaling/v1
   kind: HorizontalPodAutoscaler
   metadata:
     name: fib-hpa
     namespace: default
   spec:
     maxReplicas: 50
     minReplicas: 1
     scaleTargetRef:
       apiVersion: apps/v1
       kind: Deployment
       name: fib-deployment
     targetCPUUtilizationPercentage: 50

2. テストサービスをデプロイします。

   kubectl apply -f demo.yaml

   続行する前に、すべてのポッドが実行中であることを確認します。

   kubectl get pods

   期待される出力（すべてのポッドが Running 状態であること）：

   NAME                              READY   STATUS    RESTARTS   AGE
   fib-deployment-xxx                1/1     Running   0          1m
   fib-loader-xxx                    1/1     Running   0          1m

ステップ 4：AHPA ポリシーの作成

AHPA ポリシーは、AdvancedHorizontalPodAutoscaler という種類のカスタムリソースです。以下に示す例では、observer モードで開始します。このモードでは、AHPA が予測を生成しますが、実際にスケーリングは実行しません。自動スケーリングを有効化する前に、予測の妥当性を検証する際にこのモードを使用します。

1. 以下の内容で ahpa-demo.yaml というファイルを作成します。

   apiVersion: autoscaling.alibabacloud.com/v1beta1
   kind: AdvancedHorizontalPodAutoscaler
   metadata:
     name: ahpa-demo
   spec:
     scaleTargetRef:                  # 必須。管理対象の Deployment。
       apiVersion: apps/v1
       kind: Deployment
       name: fib-deployment
     metrics:                         # 必須。スケーリング判断の根拠となるメトリック。
     - type: Resource
       resource:
         name: cpu
         target:
           type: Utilization
           averageUtilization: 40     # 必須。平均 CPU 使用率が 40 % を超えるとスケーリングを実行。
     maxReplicas: 100                 # 必須。ポッド数の上限（ハード制限）。
     minReplicas: 2                   # 必須。ポッド数の下限（ハード制限）。
     scaleStrategy: observer          # 任意。デフォルト：observer。
                                      # auto：AHPA が自動的にスケーリングを実行。
                                      # observer：スケーリングを実行せず、予測のみを観測。
                                      # scalingUpOnly：スケールアウトのみ実行し、スケールインは実行しない。
                                      # proactive：能動的予測のみ実行。
                                      # reactive：受動的予測のみ実行。
     stabilizationWindowSeconds: 300  # 任意。デフォルト：300 秒。スケールインのクールダウン期間。
     prediction:
       quantile: 95                   # 必須。デフォルト：0.99。範囲：0–1（小数点以下 2 桁）。
                                      # 値が大きいほど保守的（誤ったスケールアウトが少なくなる）。
                                      # 推奨範囲：0.90–0.99。
       scaleUpForward: 180            # 必須。ポッドのコールドスタート所要時間（秒）。
                                      # （ポッド作成から Ready 状態になるまでの時間）。
     instanceBounds:                  # 任意。スケジュール済みのレプリカ制限。
     - startTime: "2021-12-16 00:00:00"
       endTime: "2031-12-16 00:00:00"
       bounds:
       - cron: "* 0-8 ?  * MON-FRI"  # 月～金、00:00–08:59
         maxReplicas: 15
         minReplicas: 4
       - cron: "* 9-15 ?  * MON-FRI" # 月～金、09:00–15:59
         maxReplicas: 15
         minReplicas: 10
       - cron: "* 16-23 ?  * MON-FRI" # 月～金、16:00–23:59
         maxReplicas: 20
         minReplicas: 15

   以下の表に、主なパラメーターを示します。

   パラメーター	必須	デフォルト	説明
   scaleTargetRef	はい	—	管理対象の Deployment
   metrics	はい	—	スケーリングを駆動するメトリック。サポート対象：CPU、GPU、メモリ、クエリ/秒（QPS）、応答時間（RT）
   averageUtilization	はい	—	スケーリングしきい値。averageUtilization: 40 は、平均 CPU 使用率が 40 % を超えると AHPA がスケーリングを実行することを意味します。
   maxReplicas	はい	—	最大ポッド数
   minReplicas	はい	—	最小ポッド数
   scaleStrategy	いいえ	observer	スケーリングモード
   stabilizationWindowSeconds	いいえ	300	スケールインのクールダウン期間（秒）
   prediction.quantile	はい	0.99	予測されたメトリックがスケーリングしきい値を超えない確率のしきい値。範囲：0–1。推奨値：0.90–0.99
   prediction.scaleUpForward	はい	—	ポッドのコールドスタート所要時間：ポッド作成から Ready 状態になるまでの時間（秒）
   instanceBounds	いいえ	—	スケジュール済みの maxReplicas および minReplicas のオーバーライドを指定するタイムウィンドウ
   instanceBounds.bounds.cron	いいえ	—	レプリカ制限ウィンドウの Cron スケジュール

   instanceBounds.bounds.cron 内の Cron 式は、スペースで区切られた 5 フィールド形式（Quartz 互換）を使用します。各フィールドは以下のとおりです。

   フィールド	必須	有効値	特殊文字
   分	はい	0–59	* / , -
   時	はい	0–23	* / , -
   日	はい	1–31	* / , - ?
   月	はい	1–12 または JAN–DEC	* / , -
   曜日	いいえ	0–6 または SUN–SAT（デフォルト：*）	* / , - ?

   特殊文字の意味：

   • * — 任意の値

   • / — 増分（例：*/5 は「5 単位ごと」を意味）

   • , — リストの区切り文字

   • - — 範囲

   • ? — プレースホルダー（「日（月）」または「曜日」のいずれか一方が指定されている場合に、他方のフィールドで使用）

   「月」および「曜日」フィールドは大文字小文字を区別しません。たとえば、SUN、Sun、sun はすべて有効です。

   詳細については、「Cron 式」をご参照ください。

2. AHPA ポリシーを適用します。

   kubectl apply -f ahpa-demo.yaml

ステップ 5：予測結果の確認

AHPA は過去 7 日間の履歴データに基づいて予測を構築します。予測精度を評価するには、ポリシー適用後少なくとも 7 日間待つ必要があります。既存のアプリケーションの場合は、AHPA ダッシュボードで該当する Deployment を選択してください。

サンプル結果の解釈

本サンプルでは、scaleStrategy が observer に設定されているため、AHPA は予測を生成しますが、実際にスケーリングは実行しません。以下の図は、AHPA の予測と HPA ベースラインを比較したものです。

図から得られる主な知見は以下のとおりです。

• [実際の CPU 使用量と予測 CPU 使用量]： 予測 CPU 使用量（黄色）は実際の使用量（緑色）よりも一貫して高く、AHPA が保守的なキャパシティ設計を行っていることが確認できます。また、黄色の線が緑色の線より先に上昇しており、需要到来前にリソースが準備されていることも確認できます。

• [ポッド数の傾向]： 予測ポッド数（黄色）は HPA が提供するポッド数（緑色）より低く、かつ黄色の曲線は滑らかです。これは、AHPA の推奨により急激なスケーリングイベントが減少し、ワークロードの安定性が向上することを意味します。

自動スケーリングの有効化

予測結果が期待通りであることを確認した後、scaleStrategy を auto に設定し、ahpa-demo.yaml を再適用します。

kubectl apply -f ahpa-demo.yaml

AHPA はその後、自身の予測に基づいて fib-deployment を自動的にスケーリングします。

次のステップ

• AHPA の概要 — 予測アルゴリズムおよびポリシー設計について学びます。

• Cron 式 — instanceBounds.bounds.cron の構文に関するリファレンス