第15章 Automation Controller のパフォーマンスチューニング
Automation Controller をチューニングしてパフォーマンスとスケーラビリティを最適化します。ワークロードを計画するときは、パフォーマンスとスケーリングのニーズを特定し、制限に合わせて調整し、デプロイメントを監視してください。
Automation Controller は、次のような複数の調整可能なコンポーネントを備えた分散システムです。
- ジョブのスケジューリングを担当するタスクシステム
- ジョブの制御と出力の処理を担当するコントロールプレーン
- ジョブが実行される実行プレーン
- API の提供を担当する Web サーバー
- websocket 接続とデータを提供およびブロードキャストする Websocket システム
- 複数のコンポーネントで使用されるデータベース
15.1. Automation Controller をデプロイするための容量のプランニング
Automation Controller の容量のプランニングでは、計画されたワークロードを実行する容量を確保できるように、デプロイメントのスケールと特性について計画します。容量のプランニングには次のフェーズが含まれます。
- ワークロードの特徴付け
- さまざまなノードタイプの機能の確認
- ワークロードの要件に基づくデプロイメントのプランニング
15.1.1. ワークロードの特徴
デプロイメントを計画する前に、サポートするワークロードを確立します。Automation Controller ワークロードを特徴付けるために、次の要素を考慮してください。
- 管理対象ホスト
- ホストごとの 1 時間あたりのタスク数
- サポートする同時実行ジョブの最大数
- ジョブに設定するフォークの最大数。フォークによって、ジョブがいくつのホストで同時に動作するかが決まります。
- 1 秒あたりの API 要求の最大数
- デプロイするノードのサイズ (CPU/メモリー/ディスク)
15.1.2. Automation Controller のノードのタイプ
Automation Controller デプロイメントでは、4 種類のノードを設定できます。
- コントロールノード
- ハイブリッドノード
- 実行ノード
- ホップノード
15.1.2.1. コントロールノードをスケーリングする利点
コントロールノードとハイブリッドノードは、制御容量を提供します。これらのノードは、ジョブを開始し、データベースへの出力を処理する機能を提供します。すべてのジョブにはコントロールノードが割り当てられます。デフォルト設定では、各ジョブを制御するには 1 の容量単位が必要です。たとえば、100 の容量単位を持つコントロールノードは、最大 100 個のジョブを制御できます。
より多くのリソースを備えた大規模な仮想マシンをデプロイして、コントロールノードを垂直スケーリングすると、コントロールプレーンの次の機能が向上します。
- コントロールノードが制御タスクを実行できるジョブの数。この数を増やすには、より多くの CPU とメモリーが必要です。
- コントロールノードが同時に処理できるジョブイベントの数。
CPU とメモリーを同じ比率でスケーリングすることを推奨します (例: 1 CPU: 4 GB RAM)。メモリー消費量が多い場合でも、インスタンスの CPU を増やすことで負荷が軽減されることがよくあります。コントロールノードが消費するメモリーの大部分は、メモリーベースのキューに格納されている未処理のイベントによるものです。
コントロールノードを垂直スケーリングしても、Web 要求を処理するワーカーの数は自動的に増加しません。
垂直スケーリングの代わりに、より多くのコントロールノードをデプロイして水平スケーリングを行うこともできます。これにより、ロードバランサーをプロビジョニングしてノード間で要求を分散する場合、制御タスクをより多くのノードに分散できるほか、Web トラフィックもより多くのノードに分散できます。より多くのコントロールノードをデプロイする水平スケーリングは、コントロールノードがダウンした場合や通常よりも高い負荷が発生した場合に、冗長性とワークロードの分離を強化するため、多くの点で望ましい場合があります。
15.1.2.2. 実行ノードをスケーリングする利点
実行ノードとハイブリッドノードは実行容量を提供します。ジョブが消費する容量は、ジョブテンプレートに設定されているフォークの数とインベントリー内のホストの数のいずれか少ない方に、メインの Ansible プロセスを考慮した 1 容量単位を加えたものと等しくなります。たとえば、デフォルトのフォーク値が 5 のジョブテンプレートが 50 台のホストを持つインベントリーで動作している場合、このジョブテンプレートは、割り当てられている実行ノードから 6 容量単位を消費します。
より多くのリソースを備えたより大規模な仮想マシンをデプロイすることで実行ノードを垂直スケーリングすると、ジョブ実行のためのフォークが増加します。これにより、インスタンスで実行できる同時実行ジョブの数が増加します。
一般に、CPU とメモリーを同じ比率でスケーリングすることを推奨します。コントロールノードやハイブリッドノードと同様に、各実行ノードには容量調整があります。容量調整を使用して、Automation Controller が作成する容量消費の推定値に合わせて実際の使用量を調整できます。デフォルトでは、すべてのノードがその範囲の上限に設定されます。実際の監視データによりノードが過剰に使用されていると判明した場合、容量調整を減らすことで、実際の使用量と一致させることができます。
実行ノードを垂直スケーリングする代わりに、より多くの仮想マシンを実行ノードとしてデプロイして、実行プレーンを水平スケーリングすることもできます。水平スケーリングによりワークロードをさらに分離できるため、異なるインスタンスを異なるインスタンスグループに割り当てることができます。これらのインスタンスグループは、組織、インベントリー、またはジョブテンプレートに割り当てることができます。たとえば、特定のインベントリーに対してジョブを実行する場合にのみ使用できるインスタンスグループを設定できます。この場合、実行プレーンを水平スケーリングすることで、優先度の低いジョブが優先度の高いジョブをブロックしないようにすることができます。
15.1.2.3. ホップノードをスケーリングする利点
ホップノードが使用するメモリーと CPU は非常に少ないため、これらのノードを垂直スケーリングしても容量には影響しません。多くの実行ノードとコントロールプレーンの間の唯一の接続として機能するホップノードについては、ネットワーク帯域幅を監視してください。帯域幅の使用量が飽和している場合は、ネットワークの変更を検討してください。
ホップノードを追加して水平スケーリングすると、1 つのホップノードがダウンしても冗長性が提供され、コントロールプレーンと実行ノードの間でトラフィックを流し続けることができます。
15.1.2.4. 制御容量と実行容量の比率
デフォルト設定を前提とすると、従来の仮想マシンのデプロイメントでは、制御容量と実行容量の最大推奨比率は 1:5 です。この比率により、利用可能なすべての実行容量でジョブを実行して出力を処理するための、十分な制御容量が確保されます。実行容量に対して制御容量が少ないと、実行容量を使用する十分な数のジョブを起動できなくなります。
この比率を 1:1 に近づけることが推奨される場合があります。たとえば、ジョブが高レベルのジョブイベントを生成する場合、制御容量に対して実行容量を減らすと、出力を処理するためにコントロールノードに掛かる負荷が軽減されます。
