"}
```
* `application_worker_priority_queue_length` は、ワーカーの種類ごとに待機中の作業量を示します。
* `application_worker_active_threads` は、アクティブな処理スレッド数を示します。一部の自動生成されたワーカー設定では、キューの深さに加えて、これを 2 つ目の Prometheus トリガーとして使用します。これにより、空きの処理スレッドがなくなった時点でワーカーを先回りしてスケールアップし、新たに到着したタスクを、キューの滞留がたまるまで待たせることなく、すぐに処理できるようにします。
チャートで生成されたクエリには、ワークロード固有のサービスおよびワーカーのセレクターが追加されており、一定期間のローリングウィンドウを使用する場合もあります。これらを上記の 2 つの大まかな確認用クエリに置き換えないでください。
一部の `ScaledObject` リソースには、複数のトリガーが含まれています。どのトリガーでもスケールアウトを要求でき、HPA は最も大きいレプリカ推奨値を採用します。ワークロードが予期せずスケールした場合は、最初のトリガーだけでなく、すべてのトリガーを確認してください。
### Skill 構成に応じてワーカータイプをスケールさせる
TechCore の処理は、OCR、Extraction、Classification などのワーカータイプに分かれており、各ワーカータイプはそれぞれ専用のキュー上で個別にスケールします。デプロイした Skill によって、どのワーカータイプに最も負荷がかかるかが決まります。OCR の比重が高い Skill 構成では OCR ワーカーの需要が高まり、抽出の比重が高い構成では Extraction ワーカーの需要が高まります。
ドキュメントはこれらのワーカータイプを段階的に通過するため、ステージ間の処理能力の不均衡は、エラーではなく待機として現れます。あるステージのリソースが、その前段のステージに対して不足している場合 (たとえば、OCR の処理能力は十分でも Extraction ワーカーが少なすぎる場合) 、ドキュメントは最初のステージをすばやく通過したあと、下流のキューが解消され、そのワーカーがスケールアウトするまで数分間待機します。本番用 Skill 構成で代表的な負荷テストを実施し、ワーカータイプごとのキューの深さを監視したうえで、レプリカ数の相対的な境界値の調整について ABBYY account team と相談してください。
## 前提条件
KEDA を有効にする前に、次の点を確認してください。
1. KEDA 2.17.3 がインストールされており、その operator と metrics API server が正常に稼働していること。
2. Kubernetes の resource metrics API が CPU データを返すこと。
3. Prometheus に `http://prometheus-operated.observability.svc.cluster.local:9090` でアクセスできること。
4. Vantage の `ServiceMonitor` が存在し、Prometheus が Vantage の `/metrics-text` ターゲットを `UP` と報告していること。
5. Prometheus が Vantage ワーカー メトリクスの現在の値を返すこと。
6. cluster に、TechCore ワーカー 用のラベルが付いた nodes を含め、追加レプリカをスケジュールできる十分な空き容量があること。
項目 3 の Prometheus service 名、名前空間、ポートは、生成される `ScaledObject` resource の固定 endpoint になります。
続行する前に、次の確認を行ってください。
```bash theme={null}
kubectl get deployment --all-namespaces | grep keda-operator
kubectl -n observability get service prometheus-operated
kubectl -n $install_namespace get servicemonitor
```
Prometheus で、これらのクエリを実行し、インストール先の名前空間の時系列データが返されることを確認します。
```promql theme={null}
application_worker_priority_queue_length{namespace=""}
application_worker_active_threads{namespace=""}
```
Prometheus のインストールおよびサービスメッシュの要件については、[Prometheus による監視](/ja/vantage/self-hosted/v3.0/monitoring/prometheus)を参照してください。
## オートスケーリングを有効にする
Vantage の設定で KEDA を有効にし、別個のトップレベル `observability` セクションで、チャートによって作成された `ServiceMonitor` を有効にします。
```yaml theme={null}
vantage:
keda:
enabled: true
observability:
prometheus:
namespace: observability
serviceMonitor:
create: true
```
`observability` セクションは、`vantage` や `Vantage` カスタムリソースの一部ではありません。これは、`vantage-selfhosted` チャートによって直接生成される監視用リソースを制御します。
値は既存の `vantage-selfhosted` Helm リリースを通じて適用してください。ArgoCD は、各コンポーネントのアプリケーションとその `ScaledObject` リソースを非同期に作成します。
## オートスケーリングを確認する
生成されたリソースを一覧表示します:
```bash theme={null}
kubectl -n $install_namespace get scaledobjects.keda.sh
kubectl -n $install_namespace get hpa
```
`ScaledObject` リソースの準備が整うまで待ちます:
```bash theme={null}
kubectl -n $install_namespace wait \
--for=condition=Ready scaledobjects.keda.sh \
--all \
--timeout=5m
```
各リソースとその HPA を確認します:
```bash theme={null}
kubectl -n $install_namespace describe scaledobject
kubectl -n $install_namespace get scaledobject -o yaml
kubectl -n $install_namespace describe hpa
```
ステータスは注意して確認してください。
* `Ready=True` は、KEDA がトリガー構成を受け入れたことを示します。
* `Active=True` は、少なくとも 1 つのトリガーが現在スケーリングを要求していることを示します。
* トラフィックやキュー内の処理がない場合、`Active=False` は正常なことがあります。
* HPA のメトリック値が `` の場合、Kubernetes はそのメトリックの現在値を取得できないことを示します。
条件を管理したワークロード テスト中は、ワークロード、HPA、ノード容量をあわせて監視してください。
```bash theme={null}
kubectl -n $install_namespace get deployment,hpa,pod --watch
```
要求されたレプリカが `Running` になることを確認してください。HPA の desired count が増加しているにもかかわらず pod が `Pending` のままの場合は、KEDA のトリガーではなく、容量不足またはスケジューリングの問題です。
## 生成された動作を理解する
Vantage のワークロード用チャートは、次のワークロード固有の設定を提供します。
* トリガーしきい値と Prometheus クエリ。
* レプリカ数の最小値と最大値。
* スケールアップ速度と安定化動作。
* スケールダウン速度と安定化動作。
この構成は、バックログが発生したときにすばやくスケールアップし、その後は安定化ウィンドウを通じて慎重にスケールダウンするよう設計されています。これは、キューが一定時間静かな状態を保つまでレプリカを稼働させ続けるクールダウン期間です。モデル ワーカーと学習ワーカーでは、軽量な API サービスよりも長いクールダウンが使用されます。これは、それらのレプリカを削除するとキャッシュされたモデルが破棄され、モデルを再ロードすると次のタスクの処理が目に見えて遅くなるためです。生成されたリソース内のウィンドウ期間は、そのチャート バージョンにおける参考値として扱い、調整対象とは見なさないでください。
正確な値は製品構成の一部であり、汎用的な容量推奨値ではありません。ワークロード特性や検証データの変化に応じて、Vantage チャートのバージョンごとに変わる可能性があります。
別の環境から `ScaledObject` マニフェストやしきい値をコピーしたり、生成されたリソースを直接編集したりしないでください。ArgoCD は、調整時またはアップグレード時の再調整で、チャートからレンダリングされた構成を復元することがあります。サポート対象の Vantage チャート値のみを使用し、追加のオートスケーリング オーバーライドを適用する前に、ABBYY の担当チームに連絡してください。
## クラスター容量を計画する
オートスケーリングでは、規模不足のクラスターや制約のあるクラスターを補うことはできません。次の点を考慮して計画してください。
* ドキュメントの最大到着率と、許容可能なキュー待機時間。
* 代表的なドキュメントとSkillに対する、平均処理時間と上位パーセンタイルの処理時間。
* pod の起動時間とModelのウォームアップ時間。
* 同時にスケーリングする各ワークロードの CPU とメモリのリクエスト値。
* ノードオートスケーラーのプロビジョニング時間と、ノードプールの最大サイズ。
* 名前空間のクォータ、クラスターの上限、レジストリのプルのスループット。
* TechCore ノードのラベル、taint、アクセラレーター、学習ワーカーの分離。
* ノードまたはアベイラビリティゾーンが利用できない場合の障害許容性。
代表的な負荷テスト中に、キューの深さ、処理レイテンシー、pod の起動時間、HPA の目標レプリカ数、Pending 状態の pod を測定してください。環境固有のチューニングについて ABBYY と相談する際は、これらの測定結果を活用してください。
## トラブルシューティング
| 症状 | 確認すべき主な箇所 |
| ---------------------------------------------- | ------------------------------------------------------------------------------------------- |
| `ScaledObject` リソースが表示されない | `vantage.keda.enabled: true` を確認し、生成された ArgoCD アプリケーションを調べます。 |
| `Ready=False` または `ScaledObjectCheckFailed` | KEDA 2.17.3 であることを確認し、未対応のトリガーフィールドがないか `ScaledObject` のイベントを調べます。 |
| HPA メトリクスに `` が表示される | Prometheus service、`ServiceMonitor`、スクレイプターゲット、mesh ポリシー、クエリ結果を確認します。 |
| HPA がより多くのレプリカを要求しているのに、pod が `Pending` のままである | node の capacity、クォータ、resource request、TechCore ラベル、taint、persistent-volume のスケジューリングを確認します。 |
| workload の queue が落ち着いているように見えるのにスケーリングする | すべてのトリガーを調べます。別の Prometheus トリガーまたは CPU トリガーが有効になっている可能性があります。 |
| upgrade 後に scaling の動作が変わる | 生成された `ScaledObject` をバージョン管理されたチャート構成と比較し、両方の Vantage チャートで同じバージョンを使用していることを確認します。 |
詳細な対処手順については、[Troubleshooting KEDA and Prometheus](/ja/vantage/self-hosted/v3.0/troubleshooting#keda-and-prometheus) を参照してください。
## 次のステップ
スクレイピングを設定し、KEDA で使用されるメトリクスを確認します。
KEDA、Prometheus、およびクラスターの容量要件を確認します。
異常な ScaledObjects や利用できないメトリクスの問題を診断します。
KEDA または Vantage をアップグレードする前に、サポート対象のバージョンを確認します。