3.10. スレッドプールの設定の概念

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

デフォルトでは、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 が OpenShift によって強制終了されます。