Keycloak は、Infinispan キャッシュを使用して相互に接続する複数の Keycloak インスタンスで構成されるデプロイメントをサポートしています。ロードバランサーは、これらのインスタンス間で負荷を均等に分散できます。これらのセットアップは、単一サイト上の透過的なネットワークを対象としています。
Keycloak 高可用性ガイドは、さらに一歩進んで、複数サイトにわたるセットアップについて説明しています。このセットアップは複雑さを増しますが、一部の環境では、その追加の高可用性が必要になる場合があります。
Keycloak の複数サイト構成機能は、以下のユースケースを対象としています。
単一の AWS リージョンまたは同等の低遅延構成に制約される。
メンテナンスのための計画停止を許可する。
定義されたユーザー数とリクエスト数に収まる。
定期的な停止の影響を受け入れることができる。
当社では、以下の構成で Keycloak を定期的にテストしています。
同じ AWS リージョン内の 2 つの Openshift シングル AZ クラスター
ROSA HCP を使用して、Red Hat OpenShift Service on AWS (ROSA) でプロビジョニング。
各 Openshift クラスターには、単一のアベイラビリティーゾーンにすべてのワーカーがあります。
OpenShift バージョン 4.17。
Amazon Aurora PostgreSQL データベース
プライマリ DB インスタンスが 1 つのアベイラビリティーゾーンにあり、同期的にレプリケートされたリーダーが 2 番目のアベイラビリティーゾーンにある高可用性
バージョン 16.1
AWS Global Accelerator、両方の ROSA クラスターにトラフィックを送信
ROSA の Prometheus および Alert Manager によってトリガーされる AWS Lambda によるフェイルオーバーの自動化
同等のセットアップでも動作するはずですが、環境のパフォーマンスと障害動作を確認する必要があります。機能テスト、障害テスト、および負荷テストは、Keycloak Benchmark Project で提供しています。
各項目の詳細については、Building blocks multi-site deployments ガイドを参照してください。
当社では、以下の負荷で Keycloak を定期的にテストしています。
100,000 ユーザー
1 秒あたり 300 リクエスト
これらの値を使用したテストではハードリミットは見られませんでしたが、水平方向および垂直方向にスケールされた Keycloak 名インスタンスとデータベースで、より高いボリュームをテストすることを推奨します。
詳細については、CPU およびメモリリソースのサイジングに関する概念 ガイドを参照してください。
2 つのサイトの追加の冗長性があっても、ダウンタイムは依然として発生する可能性があります。
Keycloak または Infinispan のアップグレード中、両方のサイトをアップグレード期間中オフラインにする必要があります。
特定の障害シナリオでは、最大 5 分間のダウンタイムが発生する可能性があります。
特定の障害シナリオの後、障害が発生したサイトをオンラインに戻すことによって冗長性を復元するために、手動による介入が必要になる場合があります。
特定のスイッチオーバーシナリオでは、最大 5 分間のダウンタイムが発生する可能性があります。
制限事項の詳細については、複数サイト構成に関する概念 ガイドを参照してください。
さまざまなガイドでは、必要な概念と構成要素を紹介しています。各構成要素について、完全に機能する例を設定する方法をブループリントで示しています。本番環境のセットアップを準備する際には、追加のパフォーマンスチューニングとセキュリティ強化が依然として推奨されます。