プールのサイズの決定方法
scaling.minWorkers から scaling.maxWorkers の範囲に収まるよう制限されます。作業単位あたりの平均処理時間は scaling.defaultUnitSeconds を初期値とし、作業単位の完了に応じて実測値に追従します。たとえば、1 作業単位あたり 30 秒かかる作業単位が 80 個キューに入っており、目標が 120 秒の場合は、ワーカーを 20 個追加するよう要求されます。
プールは、キューの要求に応じて直ちに拡大します。一方、縮小するのは、キューが要求するワーカー数の減少が scaling.scaleDownCooldownMs の間継続した場合に限られます。
ワーカーの Deployment を手動でスケーリングしたり、HorizontalPodAutoscaler をアタッチしたりしないでください。Orchestratorが次回の確認時にレプリカ数をリセットします。
キャパシティ
各ワーカーはworker.resources.requests (デフォルトでは 1 vCPU と 1 GB) をリクエストし、一度に 1 作業単位ずつ処理します。スループットを向上させるには、ワーカーに割り当てる CPU を増やすのではなく、maxWorkers の値を引き上げてください。
Orchestratorは pod を作成するだけなので、pod 用のノードを追加するには、クラスターにノードオートスケーラーが必要です。maxWorkers を数百規模に引き上げる前に、クラスターの制限だけでなく、クラウドの CPU クォータも確認してください。
このチャートではリクエストは設定されていますが、リミットは設定されていません。大きなページや高解像度のページの処理中にメモリ不足でワーカーが退避 (evict) される場合は、worker.resources.requests.memory の値を引き上げてください。
コールドスタート
minWorkers: 0 の場合、アイドル期間後の最初のジョブは、ワーカーがスケジュールされてイメージをプルし、起動するまで待機します。ワーカーを常に準備完了の状態に保つには、minWorkers を設定してください。新しいノードでバースト処理を高速化するには、ワーカーイメージの事前プルを参照してください。
作業単位のサイズとリース
ページ数がingest.pageSplitThreshold (25) を超える PDF は、そのページ数ごとの区分に分割され、各区分が 1 つの作業単位になります。作業単位を小さくすると、大きなドキュメントをより多くのワーカーに分散して処理できます。
ワーカーは orchestrator.workLeaseSeconds (300 秒) 以内に作業単位の処理を完了する必要があります。完了しなかった場合、その作業単位は別のワーカーに割り当てられ、orchestrator.workMaxAttempts (3) 回試行しても完了しないと、ジョブは timed-out で失敗します。リース時間は、最も処理に時間がかかる作業単位の所要時間より長く設定するか、分割のしきい値を下げてください。
Ingest と Orchestrator
Ingest はingest.replicas 個の pod で実行されます。アップロードや PDF の分割処理で ingest の高負荷状態が続く場合は、この値を増やしてください。Orchestrator は常に 1 レプリカで実行されます。