メインコンテンツへスキップ
KEDA は、Vantage 3.0 セルフホスト型で使用できる、推奨のオプションのオートスケーリングエンジンです。これを有効にすると、Vantage コンポーネントのチャートによって、サポート対象のワークロード用の ScaledObject リソースが作成されます。KEDA はそれらのトリガーを評価し、ワークロードをスケールアップおよびスケールダウンする Kubernetes HorizontalPodAutoscaler (HPA) リソースを管理します。
Vantage のワークロードチャートには KEDA 2.17.x が必要です。KEDA 2.17.3 を使用してください。KEDA 2.18 以降では、現在の Vantage チャートによって生成される一部の ScaledObject フィールドを処理できません。

​
オートスケーリングの仕組み

KEDA はワークロードのレプリカ数を変更します。Kubernetes ノードの追加、クォータの増加、またはワークロードを実行できないノードを実行可能にすることはありません。KEDA は、ノードオートスケーラーやその他の容量管理プロセスと連携させてください。

​
スケーリング戦略

生成されたScaledObjectリソースでは、ワークロードの特性に応じて異なるトリガータイプが使用されます。 生成されるしきい値、レプリカ数の境界、クエリ、およびHPAの動作は、ワークロードとVantageチャートのバージョンによって異なります。インストール環境で生成されたScaledObjectリソースを正としてください。

​
CPU 使用率トリガー

CPU トリガーでは、ワークロードの平均 CPU 使用率を設定されたターゲット値と比較します。CPU 使用率はワークロードの CPU リクエストに対する相対値として計算されるため、Kubernetes の resource metrics API が正常に動作しており、ワークロードに有効な CPU リクエストが設定されている必要があります。 resource metrics が利用可能であることを確認します。

​
Prometheus トリガー

非同期ワーカー の ScaledObject リソースでは、Prometheus の Vantage アプリケーション メトリクスを使用します。主なシグナルは次のとおりです。
  • 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 になります。 続行する前に、次の確認を行ってください。
Prometheus で、これらのクエリを実行し、インストール先の名前空間の時系列データが返されることを確認します。
Prometheus のインストールおよびサービスメッシュの要件については、Prometheus による監視を参照してください。

​
オートスケーリングを有効にする

Vantage の設定で KEDA を有効にし、別個のトップレベル observability セクションで、チャートによって作成された ServiceMonitor を有効にします。
observability セクションは、vantage や Vantage カスタムリソースの一部ではありません。これは、vantage-selfhosted チャートによって直接生成される監視用リソースを制御します。 値は既存の vantage-selfhosted Helm リリースを通じて適用してください。ArgoCD は、各コンポーネントのアプリケーションとその ScaledObject リソースを非同期に作成します。

​
オートスケーリングを確認する

生成されたリソースを一覧表示します:
ScaledObject リソースの準備が整うまで待ちます:
各リソースとその HPA を確認します:
ステータスは注意して確認してください。
  • Ready=True は、KEDA がトリガー構成を受け入れたことを示します。
  • Active=True は、少なくとも 1 つのトリガーが現在スケーリングを要求していることを示します。
  • トラフィックやキュー内の処理がない場合、Active=False は正常なことがあります。
  • HPA のメトリック値が <unknown> の場合、Kubernetes はそのメトリックの現在値を取得できないことを示します。
条件を管理したワークロード テスト中は、ワークロード、HPA、ノード容量をあわせて監視してください。
要求されたレプリカが 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 と相談する際は、これらの測定結果を活用してください。

​
トラブルシューティング

詳細な対処手順については、Troubleshooting KEDA and Prometheus を参照してください。

​
次のステップ

Prometheus による監視

スクレイピングを設定し、KEDA で使用されるメトリクスを確認します。

前提条件

KEDA、Prometheus、およびクラスターの容量要件を確認します。

トラブルシューティング

異常な ScaledObjects や利用できないメトリクスの問題を診断します。

互換性

KEDA または Vantage をアップグレードする前に、サポート対象のバージョンを確認します。