3.6. Automation Controller のチューニング

イベントは、ジョブにサブスクライブされた UI クライアントが存在するノードすべてに送信されます。このタスクはコストが高く、クラスターが生成するイベントの数が増加し、コントロールノードの数が増加するにつれて、さらにコストが高くなります。これは、特定のジョブにサブスクライブされたクライアントの数に関係なく、すべてのイベントがすべてのノードにブロードキャストされるためです。

UI にライブイベントを表示するオーバーヘッドを削減するために、管理者は次のいずれかを選択できます。

イベントのライブストリーミングを無効にすると、イベントは、ジョブの出力詳細ページのハードリフレッシュ時にのみロードされます。1 秒あたりに表示されるイベントの数を減らすと、ライブイベントを表示するオーバーヘッドは限定されますが、ハードリフレッシュを行わなくても UI でライブ更新が提供されます。

コールバックレシーバーはジョブのすべての出力を処理し、この出力をジョブイベントとして Automation Controller データベースに書き込みます。コールバックレシーバーには、イベントをバッチで処理するワーカーのプールがあります。ワーカーの数は、インスタンスで使用可能な CPU の数に応じて自動的に増加します。

管理者は、JOB_EVENT_WORKERS 設定を使用してコールバックレシーバーワーカーの数をオーバーライドできます。CPU ごとに複数のワーカーを設定することはできません。また、少なくとも 1 つのワーカーが必要です。値が大きいほど、Automation Controller にイベントがストリーミングされる際に、Redis キューをクリアするのに利用できるワーカーが増えますが、Web サーバーなどの他のプロセスと CPU 秒数で競合する可能性があります。また、より多くのデータベース接続 (ワーカーあたり 1 つ) を使用するほか、各ワーカーがコミットするイベントのバッチサイズが小さくなる可能性があります。

各ワーカーにより、バッチで書き込むイベントのバッファーが増大します。バッチを書き込む前に待機するデフォルトの時間は 1 秒です。これは、JOB_EVENT_BUFFER_SECONDS 設定によって制御されます。ワーカーがバッチ間で待機する時間を増やすと、バッチサイズが大きくなる可能性があります。

次の設定は、クラスターの容量計算に影響します。次のファイルベースの設定を使用して、すべてのコントロールノードでこれらを同じ値に設定します。

インスタンスグループで使用できる max_concurrent_jobs および max_forks 設定を使用して、インスタンスグループまたはコンテナーグループ全体で消費できるジョブとフォークの数を制限します。

((number of worker nodes in kubernetes cluster) * (CPU available on each worker)) / (CPU request on pod_spec) = maximum number of concurrent jobs

((number of worker nodes in kubernetes cluster) * (memory available on each worker)) / (memory request on pod_spec) = maximum number of forks

タスクマネージャーは、スケジュールする必要があるタスクを定期的に収集して、どのインスタンスに容量があり、タスクを実行可能かを判断します。タスクマネージャーのワークフローは、以下の通りです。

スケジューリングタスクが TASK_MANAGER_TIMEOUT 秒 (デフォルトは 300 秒) 以内に完了しない場合、タスクは早期に終了します。タイムアウトの問題は通常、保留中のジョブが多数存在する場合に発生します。

タスクマネージャーが 1 回の実行で処理できる作業量を制限する方法の 1 つに、START_TASK_LIMIT 設定があります。これにより、1 回の実行で開始できるジョブの数が制限されます。デフォルトは 100 ジョブです。さらに保留中のジョブがある場合は、新しいスケジューラータスクが直後に実行されるようにスケジュールされます。全体的なスループット向上のために、ジョブの起動から開始までのレイテンシーが潜在的に増大しても構わない場合は、START_TASK_LIMIT を引き上げることを検討できます。タスクマネージャーの個々の実行にかかる時間を確認するには、/api/v2/metrics で入手可能な Prometheus メトリクス task_manager__schedule_seconds を使用します。

タスクマネージャーによって実行の開始が選択されたジョブは、タスクマネージャープロセスが終了して変更がコミットされるまで実行されません。TASK_MANAGER_TIMEOUT 設定は、タスクマネージャーが変更をコミットするまでの 1 回の実行時間を決定します。タスクマネージャーは、タイムアウトに達すると進捗状況をコミットしようとします。タスクは、猶予期間 (TASK_MANAGER_TIMEOUT_GRACE_PERIOD により決定) が経過するまでは強制終了されません。

Automation Controller クラスターホストは、クラスター内のネットワークを介して通信します。従来の仮想マシンインストーラーのインベントリーファイルでは、クラスターノードへのルートを複数指定でき、それらはさまざまな方法で使用されます。

例:

[automationcontroller]
controller1 ansible_user=ec2-user ansible_host=10.10.12.11 node_type=hybrid routable_hostname=somehost.somecompany.org

コントロールノードとハイブリッドノードはそれぞれ、Automation Controller の UI と API を提供します。WSGI トラフィックは、ローカルソケット上の uwsgi Web サーバーによって処理されます。ASGI トラフィックは、Daphne によって処理されます。NGINX はポート 443 でリッスンし、必要に応じてトラフィックをプロキシー処理します。

Automation Controller の Web サービスをスケーリングするには、次のベストプラクティスに従ってください。

クライアント側で Automation Controller の Web サービスを最適化するには、次のガイドラインに従ってください。