Multi-Site Setup でサイト障害から復旧

これらのガイドには、Keycloak マルチサイトアーキテクチャのさまざまなコンポーネント (以下を含む) を立ち上げるためのステップバイステップの手順が含まれています。

Amazon Web Service 上のさまざまな構成で Keycloak をデプロイする方法に関する一連のガイド。

これらのガイドには、ユーザーがマルチサイト Keycloak インスタンスを効率的にセットアップおよび運用できるようにするための詳細な運用手順が含まれています。

これをテスト環境の Keycloak サーバーにインストールし、パフォーマンステストを実行するために必要な数のユーザー、クライアント、グループなどを作成します。Keycloak は内部キャッシュに多くの情報をキャッシュし、データベースも同様であるため、データベースに適切な量のデータがある場合にのみ、いくつかの問題を特定できます。

これには、認証フローおよび Keycloak の管理者 REST エンドポイント用のすぐに使用できるシナリオが含まれています。まだニーズに合わない場合は、ライブラリとして使用して、既存のステップとカスタムステップに基づいて独自の Gatling シナリオを作成してください。これらのテストは JAR およびシェルスクリプトラッパーとしてデプロイされるため、ロードランナーに Java をインストールするだけで準備完了です。

これらの Ansible プレイブックを使用して、Keycloak テストインストールに対して負荷をかける EC2 インスタンスのセットを起動し、結果を集計します。

Red Hat OpenShift Service on AWS (ROSA) に基づいて、監視、ロギング、および便利な Operator が事前構成されたインスタンスをプロビジョニングし、Keycloak をデプロイする準備をします。

Aurora をリージョナルまたはグローバルのさまざまなバリアントでセットアップし、ROSA 環境に接続します。

これにより、追加の監視およびデバッグツールとともに Keycloak がデプロイされ、必要に応じてメトリクス、ログ、トレースを確認できます。

アクティブ/パッシブセットアップ用に Route 53 をセットアップして、異なる OpenShift クラスター内の 2 つの Keycloak デプロイメントに負荷を分散します。

毎週平日、GitHub アクション、パフォーマンステストスイートを使用して、Multi-AZ セットアップをゼロから新規作成し、結果を記録します。これにより、機能およびパフォーマンスの回帰が発生した場合にそれを捕捉できます。

高負荷で Keycloak を実行している場合、リクエストが Keycloak インスタンスでキューに入れられる可能性があります。キューに入れられるリクエストが多いほど、リクエストへの応答に時間がかかります。以前のバージョンでは、liveness プローブ (/health/live) へのリクエストもキューに入れられ、プローブは最終的にタイムアウトし、Kubernetes が Pod を再起動しました。最新バージョンの Keycloak では、プローブは ノンブロッキングになるように再実装されているため、キューに入れられず、したがってタイムアウトせず、高負荷下でも Pod が再起動されることはありません。

上記のようにリクエストがキューに入れられると、呼び出し元は時間内に応答を取得できず、Pod は最終的にメモリやネットワーク接続などのリソースを使い果たす可能性があります。推奨されるレシピは、インスタンスが時間内にリクエストを処理できない場合に、リクエストを早期にドロップすることです。これはロードシェディングと呼ばれます。Keycloak 23 は、同時ブロッキングリクエストの数を制限できる 新しいオプション http-max-queued-requests をサポートするようになりました。数を超えると、Keycloak はすぐにレスポンス 503 Server not Available を返します。これには 2 つの利点があります。呼び出し元は即時応答を受信し、後で再試行でき、リソースはサーバー側ですぐに解放されます。

新しい Keycloak インスタンスが起動または再起動すると、そのキャッシュは空になります。高負荷時に同じレルムまたは同じクライアントに対する並列リクエストが Keycloak のノードに到着した場合、以前のバージョンの Keycloak は各並列リクエストでデータベースからデータをロードしていました。これにより、データベース接続の使用率が急増し、初期応答遅延が発生しました。キャッシュまたはキャッシュ内のレルムエントリが削除された場合も同様です (たとえば、変更されたため)。最新バージョンの Keycloak では、これが防止され、各 Keycloak インスタンスはデータベースからデータを 1 回フェッチし、他のすべての並列リクエストはデータベースに再度クエリすることなくこのデータを使用します ( #21521 および #22988, #24202 を参照してください)。

クラスター内で実行される Keycloak インスタンスが多いほど、および並行して処理されるリクエストが多いほど、JGroups スレッドプールへの負荷が高くなります。JGroups スレッドプールは、Keycloak の埋め込み Infinispan のスムーズな通信を保証し、容量を超えた場合、内部 Infinispan 通信でタイムアウトが発生する可能性があります。高可用性ドキュメントには、Quarkus スレッドプールを JGroup スレッドプールを超えないように設定する方法に関するドキュメントが含まれるようになりました。

埋め込み Infinispan は、クラスターを監視できる改善されたメトリクスを提供します。Keycloak のメトリクスエンドポイントによって公開されるメトリクスには、現在のノードの Infinispan メトリクスのみが含まれるようになったため、別の Pod が現在起動またはシャットダウンしている場合でもブロックされません ( ISPN-15042 および ISPN-15072)。これにより、これらの重要な瞬間にクラスターの可視性が向上します。メトリクスは、キャッシュ名をラベルとして公開できるようになりました。そのため、Infinispan XML 構成に <metrics names-as-tags="true" /> を追加することで、ダッシュボードでより簡単にプロットできます。サイト間のレイテンシに関する追加のメトリクスも利用できます。

Infinispan とその通信層 JGroups を徹底的にテストし、状態転送が停止した状況 ( ISPN-14982 ) や、初期状態転送が失敗した状況を修正することができました。マルチサイトセットアップで使用される Gossip ルーターは、ロードバランサーに複数の IP アドレスがある状況でも機能するようになりました ( JGRP-2722, JGRP-2721, infinispan-operator#1857, および infinispan-operator#1856 )。