第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 の Java）の垂直自動スケーリングは、Red Hat build of Keycloak には推奨されません。代わりに、CPU やメモリー制限を高くして、JVM が必要に応じてそれらの制限内に適応できるようにすることを検討できます。
