スレッドプールの設定に関する概念

Keycloak ノード間の通信にシングルサイトセットアップで使用される JGroups 通信は、少なくとも 2 つのコアが Keycloak で利用可能な場合に OpenJDK 21 で利用可能なバーチャルスレッドの使用から恩恵を受けます。これにより、メモリ使用量が削減され、スレッドプールサイズを設定する必要がなくなります。したがって、OpenJDK 21 の使用を推奨します。

Keycloak リクエストとブロッキングプローブは、エグゼキュータプールによって処理されます。利用可能な CPU コア数に応じて、最大サイズは 50 スレッド以上です。スレッドは必要に応じて作成され、不要になると終了するため、システムは自動的にスケールアップおよびスケールダウンします。Keycloak では、http-pool-max-threads 設定オプションで最大スレッドプールサイズを設定できます。例については、Keycloak Operator を使用した HA 用 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 でそれぞれ設定します。数値が低いと、負荷スパイク時にリクエストが一時的に失敗した場合でも、すべてのクライアントに対して迅速な応答時間が保証されます。

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

http-max-queued-requests を設定して、このキューサイズを超えた場合に効果的なロードシェディングを可能にする最大キュー長を指定します。Keycloak Pod が 1 秒あたり約 200 リクエストを処理すると仮定すると、1000 のキューは最大待機時間が約 5 秒になることを意味します。

この設定がアクティブな場合、キューに格納されたリクエストの数を超えるリクエストは、HTTP 503 エラーで応答を返します。Keycloak は、エラーメッセージをログに記録します。

Keycloak の活性プローブは、高負荷時の Pod の再起動を避けるために非ブロッキングです。

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

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