第5章 スレッドプールの設定の概念

Red Hat build of Keycloak ノード間の通信でシングルサイト設定で使用される JGroups 通信は、Red Hat build of Keycloak に少なくとも 4 つのコアが利用可能な場合に OpenJDK 21 で利用可能な仮想スレッドを使用する利点が得られます。これにより、メモリー使用量が削減され、スレッドプールのサイズを設定する必要がなくなります。したがって、OpenJDK 21 の使用が推奨されます。

Red Hat build of Keycloak のリクエストとブロッキングプローブは、エグゼキュータープールによって処理されます。利用可能な CPU コア数に応じて、プールのサイズは最大 50 スレッド以上になります。スレッドは必要に応じて作成され、不要になると終了するため、システムは自動的にスケールアップおよびスケールダウンします。Red Hat build of Keycloak では、http-pool-max-threads 設定オプションによって最大スレッドプールサイズを設定できます。例については、Operator を使用した HA 用 Red Hat ビルドの Keycloak のデプロイ を 参照してください。

Kubernetes で実行する場合は、Pod に許可された CPU 制限を超える負荷が発生しないようにワーカースレッドの数を調整して、輻輳を引き起こすスロットリングを回避します。物理マシンで実行する場合は、ノードが処理できる以上の負荷が発生しないようにワーカースレッドの数を調整して、輻輳を回避します。輻輳が発生すると、応答時間が長くなり、メモリー使用量が増加し、最終的にはシステムが不安定になります。

可能であれば、下限のスレッド数から始めて、目標のスループットと応答時間に応じて数を調整してください。負荷とスレッド数が増加すると、データベース接続もボトルネックになる可能性があります。リクエストが 5 秒以内にデータベース接続を取得できないと、そのリクエストは失敗し、Unable to acquire JDBC Connection のようなメッセージがログに記録されます。呼び出し元は、サーバー側のエラーを示す 5xx HTTP ステータスコードを含む応答を受け取ります。

データベース接続数とスレッド数を増やしすぎると、高負荷時にリクエストがキューに蓄積されてシステムが輻輳し、パフォーマンスが低下します。データベース接続の数は、それぞれ Database 設定の db-pool-initial-size、db-pool-min-size、および db-pool-max-size によって設定されます。数値が低いと、負荷が急増したときにリクエストが失敗することがありますが、すべてのクライアントの応答時間が速くなります。

デフォルトでは、Red Hat build of Keycloak は、リクエストの処理が停止した場合でも、すべての受信リクエストを無限にキューに入れます。これにより、Pod でさらにメモリーが使用され、ロードバランサーのリソースが枯渇する可能性があります。最終的には、リクエストが処理されたかどうかをクライアントが認識することなく、リクエストがクライアント側でタイムアウトになります。Red Hat build of Keycloak でキューに入れられるリクエストの数を制限するには、追加の Quarkus 設定オプションを設定します。

http-max-queued-requests を設定して最大キュー長を指定し、このキューサイズを超えた場合に効果的な負荷制限を適用できるようにします。Red Hat build of Keycloak Pod が 1 秒あたり約 200 のリクエストを処理すると仮定すると、キューが 1000 の場合、最大待機時間は約 5 秒になります。

この設定がアクティブな場合、キューに入れられたリクエストの数を超えるリクエストに対して、HTTP 503 エラーが返されます。Red Hat build of Keycloak は、エラーメッセージをログに記録します。

Red Hat build of Keycloak の liveness プローブは、高負荷時の Pod の再起動を回避するために、ノンブロッキングです。

全体的なヘルスプローブと readiness プローブは、場合によってはデータベースへの接続を確認するためにブロックすることがあるため、高負荷時に失敗する可能性があります。このため、高負荷時には Pod が準備完了状態にならない可能性があります。

Linux 上で Java を実行する場合、Java がスレッドを作成するには、使用可能なファイルハンドルが必要です。したがって、オープンファイルの数 (Linux で ulimit -n で取得される数) に余裕を確保し、Red Hat build of Keycloak が必要なスレッドの数を増やせるようにする必要があります。各スレッドはメモリーも消費するため、コンテナーのメモリー制限を、これを許容する値に設定する必要があります。そうしないと、Pod が Kubernetes によって強制終了されます。