第2章 スケーリング
Red Hat build of Keycloak を開始した後、次のスケーリングおよびチューニングのガイドラインを使用して、インスタンスを必要なロードに適応させることを検討してください。
- リソースの利用を最小限に抑える
- 目標応答時間を達成する
- データベースプールの競合を最小限に抑える
- メモリー不足エラーや過剰なガベージコレクションのオーバーヘッドを解決する
- 水平スケーリングによる高い可用性を実現する
2.1. 垂直スケーリング
Red Hat build of Keycloak ワークロードを監視するときは、CPU またはメモリーの使用率が低すぎたり高すぎたりしていないかを確認します。Java 仮想マシン (JVM) で使用可能なリソースをより適切に調整するには、CPU およびメモリーリソースのサイズ設定の概念 を参照してください。
JVM で使用可能なメモリーの量を増やす前に、特にメモリー不足エラーが発生した場合は、ヒープダンプを使用してフットプリントの増加原因を特定することが最善策となります。応答時間が長すぎる場合は、HTTP 作業キューが大きすぎることを示している可能性があり、単にメモリーを増やすよりもロード制限を調整した方が効果的です。以下のセクションを参照してください。
2.1.1. 一般的なチューニングオプション
Red Hat build of Keycloak は、使用可能なコアの数に基づいて、使用されるスレッドの数を自動的に調整します。スレッド数を手動で変更すると、全体的なスループットが向上する可能性があります。詳細は、スレッドプールの設定の概念 を参照してください。ただし、スレッド数の変更は、データベース接続などの他の JVM リソースと組み合わせて行う必要があります。そうしないと、ボトルネックが別の場所に移動する可能性があります。詳細は、データベース接続プールの概念 を参照してください。
キューに入れられた作業のメモリー使用率を制限し、ロード制限を提供するには、スレッドプールの設定の概念 を参照してください。
データベース接続の取得時にタイムアウトが発生する場合は、利用可能な接続数を増やすことを検討する必要があります。詳細は、データベース接続プールの概念 を参照してください。
2.1.2. 垂直自動スケーリング
Kubernetes などの一部のプラットフォームでは、垂直方向に自動スケーリングするメカニズムが提供されています。垂直自動スケーリングは、サーバーインスタンスの再起動が必要な場合 (現時点で Java on Kubernetes の場合に該当)、Red Hat build of Keycloak では推奨されません。代わりに、CPU やメモリーの制限を高くして、必要に応じて JVM がそれらの制限内で適応できるようにすることを検討できます。
