3.4. Automation Controller API サービスのスケーリングに関する考慮事項

Automation Controller API サービスの主要なパフォーマンス指標は次のとおりです。

Automation Controller API サービスは、operator ベースのインストールでは Web Pod に、仮想マシンベースのインストールまたはコンテナーベースのインストールではコントロールノードまたはハイブリッドノードに配置されます。

Automation Controller API サービスを拡張するには、次のストラテジーを検討してください。

OpenShift Container Platform では、各 Web レプリカは、WSGI Web サービスワーカーと、タスク通信および WebSocket を容易にするさまざまなバックグラウンドサービス用のデータベース接続を消費します。仮想マシンベースのインストールおよびコンテナーベースのインストールで WSGI Web サーバーによって使用されるデータベース接続の数は、マシンの CPU 数に応じて変化します。さらに、制御ノードとハイブリッドノードは、Dispatcher (タスクシステム) と Callback Receiver (ジョブイベント処理ワーカープール) を管理します。これらのワーカープールは CPU の可用性に応じて拡張され、データベース接続が必要になります。

追加のコントロールノードをプロビジョニングするには、OpenShift Container Platform 上の Web デプロイメントを単純にスケールアウトするよりも多くのデータベース接続が必要になります。これが必要な理由は、コンテナー化および RPM コントロールノードのスケーリングによって、OpenShift Container Platform 上の別個のデプロイメントとして動作するタスクシステムも拡張されるためです。OpenShift Container Platform デプロイメントでサービスを分離する点が重要な違いで、管理者がデプロイメントをより細かく調整し、データベース接続など、限りのあるリソースを節約できるようにします。

100 件を超えるリクエストがバックログされると、これらのリクエストは uWSGI によってドロップされるため、OpenShift Container Platform でサービスが水平に必要な分、スケーリングされることが特に重要です。その結果、クライアントではドロップされたリクエストに対してタイムアウトが発生します。次のログテキストには、このイベントに対応するエラーが示されています。

*** uWSGI listen queue of socket ":8000" (fd: 3) full !!! (101/100) ***

*** uWSGI listen queue of socket ":8000" (fd: 3) full !!! (101/100) ***

このエラーは、uWSGI のバックログの長さがカーネルパラメーター somaxconn に紐づき、制約されていることが原因で発生します。OpenShift Container Platform でこのカーネルパラメーターを上げることは可能ですが、そのためには “unsafe sysctls” を許可する必要があります。