2.2. 水平スケーリング
単一の Red Hat build of Keycloak インスタンスは可用性の問題の影響を受けやすくなります。インスタンスがダウンすると、別のインスタンスが起動するまで完全な停止が発生します。異なるマシン上で 2 つ以上のクラスターメンバーを実行すると、Red Hat build of Keycloak の可用性が大幅に向上します。
単一の JVM では、同時に処理できるリクエストの数に制限があります。追加のサーバーインスタンスは、データベースや分散キャッシュなどの関連リソースによってスケーリングが制限されるまで、スループットをほぼリニアスケーリングできます。
一般的には、水平スケーリングの問題を処理するために、Red Hat build of Keycloak Operator を許可することを検討してください。Operator を使用する場合は、水平方向にスケーリングするために、必要に応じて Keycloak カスタムリソースの spec.instances を設定します。詳細は、Red Hat build of Keycloak Operator を使用して HA 用に Red Hat build of Keycloak をデプロイする を参照してください。
Operator を使用していない場合は、以下を確認してください。
- インスタンスが別々のマシン上にある場合、より高い可用性が可能になります。Kubernetes では、Pod のアンチアフィニティーを使用してこれを強制します。
分散キャッシュを使用します。マルチサイトクラスターの場合は、クラスターメンバーが同じ状態を共有できるように外部キャッシュを使用します。関連する設定の詳細は、分散キャッシュの設定 を参照してください。組み込み Infinispan キャッシュには、次のような水平スケーリングの考慮事項があります。
- インスタンスには互いを検出する方法が必要です。詳細は、分散キャッシュの設定 の検出を参照してください。
- このキャッシュは、ストレッチクラスターとも呼ばれる、複数のアベイラビリティーゾーンにまたがるクラスターには最適ではありません。組み込み Infinispan キャッシュの場合は、すべてのインスタンスを 1 つのアベイラビリティーゾーンに配置するようにします。目標は、通信における不要なラウンドトリップを回避し、応答時間の増大を防ぐことです。Kubernetes では、Pod アフィニティーを使用してこの Pod のグループ化を強制します。
- このキャッシュは、複数のメンバーが同時に参加または離脱することを適切に処理しません。特に、メンバーが同時に退会すると、データが失われる可能性があります。Kubernetes では、デフォルトのシリアル処理を備えた StatefulSet を使用して、Pod が順番に開始および停止されるようにできます。
サイト全体が利用できなくなった場合にサービスの可用性が失われないようにするには、高可用性ガイドを参照して、マルチサイトデプロイメントの詳細を確認してください。マルチサイトデプロイメント を参照してください。
2.2.1. 水平自動スケーリング
水平自動スケーリングにより、オンデマンドで Red Hat build of Keycloak インスタンスを追加または削除できます。起動時間は瞬時には発生しないため、起動時間を最小限に抑えるには最適化されたイメージを使用する必要があることに注意してください。
組み込み Infinispan キャッシュクラスターを使用する場合、クラスターメンバーを動的に追加または削除するには、Infinispan が Infinispan キャッシュの再バランスを実行する必要がありますが、それらのキャッシュに多くのエントリーが存在する場合は、コストが高くなる可能性があります。この時間を最小限に抑えるために、セッション関連のキャッシュ内のエントリー数をデフォルトで 10000 に制限します。注記: この最適化は、persistent-user-sessions 機能が設定で明示的に無効にされていない場合にのみ可能です。
Kubernetes では、Keycloak カスタムリソースはスケーラブルであるため、組み込みの自動スケーラー の対象にすることができます。
