> ## Documentation Index
> Fetch the complete documentation index at: https://docs.abbyy.com/llms.txt
> Use this file to discover all available pages before exploring further.

# スケーリング

Orchestratorは、キューの状況に応じてワーカープールの規模を調整します。ユーザーが設定するのは、ワーカー数の上限・下限と、その応答速度です。

## プールのサイズの決定方法

```text theme={null}
workers = busy + ceil(queued units × average unit time / minimumThroughputSeconds)
```

の値が `scaling.minWorkers` から `scaling.maxWorkers` の範囲に収まるよう制限されます。作業単位あたりの平均処理時間は `scaling.defaultUnitSeconds` を初期値とし、作業単位の完了に応じて実測値に追従します。たとえば、1 作業単位あたり 30 秒かかる作業単位が 80 個キューに入っており、目標が 120 秒の場合は、ワーカーを 20 個追加するよう要求されます。

プールは、キューの要求に応じて直ちに拡大します。一方、縮小するのは、キューが要求するワーカー数の減少が `scaling.scaleDownCooldownMs` の間継続した場合に限られます。

| 値 | デフォルト | 効果 |
| - | - | - |
| `scaling.minWorkers` | `0` | キューが空のときも稼働させておくワーカー数。 |
| `scaling.maxWorkers` | `20` | プールで稼働するワーカーの最大数。 |
| `scaling.minimumThroughputSeconds` | `120` | キュー内の処理にどれだけ早くキャパシティを割り当てるか。値を小さくするほど、早い段階でより多くのワーカーが起動します。 |
| `scaling.defaultUnitSeconds` | `30` | 1 作業単位の処理時間の初期推定値。 |
| `scaling.tickMs` | `15000` | プールサイズを確認する間隔。 |
| `scaling.scaleDownCooldownMs` | `300000` | プールが縮小されるまでに、キューが要求するワーカー数の減少が継続している必要がある時間。 |

ワーカーの 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` を設定してください。新しいノードでバースト処理を高速化するには、[ワーカーイメージの事前プル](https://docs.abbyy.com/ja/fine-parser/enterprise/best-practices/scheduling.md#pre-pulling-the-worker-image)を参照してください。

## 作業単位のサイズとリース

ページ数が `ingest.pageSplitThreshold` (25) を超える PDF は、そのページ数ごとの区分に分割され、各区分が 1 つの作業単位になります。作業単位を小さくすると、大きなドキュメントをより多くのワーカーに分散して処理できます。

ワーカーは `orchestrator.workLeaseSeconds` (300 秒) 以内に作業単位の処理を完了する必要があります。完了しなかった場合、その作業単位は別のワーカーに割り当てられ、`orchestrator.workMaxAttempts` (3) 回試行しても完了しないと、ジョブは `timed-out` で失敗します。リース時間は、最も処理に時間がかかる作業単位の所要時間より長く設定するか、分割のしきい値を下げてください。

## Ingest と Orchestrator

Ingest は `ingest.replicas` 個の pod で実行されます。アップロードや PDF の分割処理で ingest の高負荷状態が続く場合は、この値を増やしてください。Orchestrator は常に 1 レプリカで実行されます。