マルチサイトデプロイメントの概念

同期レプリケーションによるマルチサイトデプロイメントの理解

このトピックでは、高可用性マルチサイトセットアップと期待される動作について説明します。高可用性アーキテクチャの要件を概説し、利点とトレードオフについて説明します。

このセットアップを使用する場合

サイト障害を許容でき、ダウンタイムの可能性を減らすことができるKeycloakデプロイメントを提供するには、このセットアップを使用します。

デプロイメント、データストレージ、およびキャッシュ

異なるサイトで実行されている2つの独立したKeycloakデプロイメントは、低遅延ネットワーク接続で接続されています。ユーザー、レルム、クライアント、セッション、およびその他のエンティティは、2つのサイト間で同期的にレプリケートされるデータベースに保存されます。データは、ローカルキャッシュとしてKeycloak Infinispanキャッシュにもキャッシュされます。データが1つのKeycloakインスタンスで変更されると、そのデータはデータベースで更新され、無効化メッセージがworkキャッシュを使用して他のサイトに送信されます。

次の段落と図では、Infinispanのデプロイに関する言及は、外部Infinispanに適用されます。

active active sync.dio

データおよびサービス損失の原因

このセットアップは高可用性を目指していますが、次の状況ではサービスまたはデータ損失が発生する可能性があります。

  • Keycloakサイトの障害により、障害とロードバランサーの検出の間の期間にリクエストが失敗する可能性があります。リクエストがまだ障害が発生したサイトにルーティングされる可能性があるためです。

  • サイト間の通信で障害が発生すると、劣化したセットアップを再同期するために手動の手順が必要になります。

  • 劣化したセットアップは、追加のコンポーネントが故障した場合、サービスまたはデータ損失につながる可能性があります。劣化したセットアップを検出するには、監視が必要です。

このセットアップが耐えられる障害

障害 復旧 RPO1 RTO2

データベースノード

ライターインスタンスが故障した場合、データベースは同じサイトまたは他のサイトのリーダーインスタンスを新しいライターに昇格させることができます。

データ損失なし

数秒から数分（データベースによる）

Keycloakノード

各サイトで複数のKeycloakインスタンスが実行されます。1つのインスタンスが故障した場合、一部の受信リクエストはエラーメッセージを受信するか、数秒間遅延する可能性があります。

データ損失なし

30秒未満

Infinispanノード

各サイトで複数のInfinispanインスタンスが実行されます。1つのインスタンスが故障した場合、他のノードが変更に気付くまでに数秒かかります。エンティティは少なくとも2つのInfinispanノードに保存されるため、単一のノード障害はデータ損失につながりません。

データ損失なし

30秒未満

Infinispanクラスタの障害

いずれかのサイトでInfinispanクラスタが故障した場合、Keycloakはそのサイトの外部Infinispanと通信できなくなり、Keycloakサービスは利用できなくなります。ロードバランサーは、/lb-checkがエラーを返すため、状況を検出し、すべてのトラフィックを他のサイトに転送します。

セットアップは、Infinispanクラスタが復元され、データが再同期されるまで劣化します。

データ損失なし3

数秒から数分（ロードバランサーの設定による）

接続性 Infinispan

2つのサイト間の接続が失われた場合、データを他のサイトに送信できません。受信リクエストはエラーメッセージを受信するか、数秒間遅延する可能性があります。Infinispanは他のサイトをオフラインとしてマークし、データの送信を停止します。接続が復元され、2つのサイト間でデータが再同期されるまで、ロードバランサーでサイトの1つをオフラインにする必要があります。ブループリントでは、これを自動化する方法を示します。

データ損失なし3

数秒から数分（ロードバランサーの設定による）

接続性 データベース

2つのサイト間の接続が失われた場合、同期レプリケーションは失敗します。一部のリクエストはエラーメッセージを受信するか、数秒間遅延する可能性があります。データベースによっては、手動操作が必要になる場合があります。

データ損失なし3

数秒から数分（データベースによる）

サイト障害

Keycloakノードがいずれも利用できない場合、ロードバランサーは停止を検出し、トラフィックを他のサイトにリダイレクトします。ロードバランサーが障害を検出するまで、一部のリクエストはエラーメッセージを受信する可能性があります。

データ損失なし3

2分未満
表の脚注

1 リカバリポイント目標。セットアップのすべての部分がこの発生時に正常であったと仮定します。
2 リカバリ時間目標。
3 劣化したセットアップを復元するために必要な手動操作。

「データ損失なし」という記述は、以前の障害からセットアップが劣化していないことに依存します。これには、サイト間の状態を再同期するための保留中の手動操作を完了することが含まれます。

既知の制限事項

サイト障害

フェイルオーバーを成功させるには、以前の障害から劣化していないセットアップが必要です。データ損失を防ぐためには、以前の障害後の再同期などのすべての手動操作が完了している必要があります。劣化がタイムリーに検出および処理されるように、監視を使用してください。

非同期サイト

同期Infinispanリクエストが失敗すると、サイトが非同期になる可能性があります。この状況は現在監視が困難であり、復旧するにはInfinispanの完全な手動再同期が必要になります。両方のサイトのキャッシュエントリ数とKeycloakログファイルを監視すると、再同期が必要になる時期を示すことができます。

手動操作

サイト間でInfinispan状態を再同期する手動操作は、システムにストレスを与えるフルステート転送を発行します。

2サイト制限

このセットアップは、2つのサイトでのみテストおよびサポートされています。追加のサイトごとに、データが各サイトに同期的に書き込まれる必要があるため、全体的なレイテンシが増加します。さらに、ネットワーク障害、したがってダウンタイムの確率も増加します。したがって、安定性とパフォーマンスが劣るデプロイメントにつながると考えられるため、3つ以上のサイトはサポートしていません。

質問と回答

なぜ同期データベースレプリケーションなのですか？

同期的にレプリケートされたデータベースは、1つのサイトに書き込まれたデータがサイト障害後も常に他のサイトで利用可能であり、データが失われないことを保証します。また、次のリクエストがどのサイトで処理されても、古いデータを返さないことを保証します。

なぜ同期Infinispanレプリケーションなのですか？

同期的にレプリケートされたInfinispanは、1つのサイトのキャッシュされたデータがサイト障害後も常に他のサイトで利用可能であり、データが失われないことを保証します。また、次のリクエストがどのサイトで処理されても、古いデータを返さないことを保証します。

サイト間に低遅延ネットワークが必要なのはなぜですか？

同期レプリケーションは、データが他のサイトで受信されるまで、呼び出し元への応答を遅延させます。同期データベースレプリケーションと同期Infinispanレプリケーションの場合、各リクエストはデータが更新されるときにサイト間で潜在的に複数のインタラクションを持つ可能性があるため、低遅延が必要です。これにより、レイテンシが増幅されます。

同期クラスタは非同期クラスタよりも不安定ですか？

非同期セットアップはサイト間のネットワーク障害を優雅に処理しますが、同期セットアップはリクエストを遅延させ、呼び出し元にエラーをスローします。非同期セットアップは、他のサイトのInfinispanまたはデータベースへの書き込みを遅延させます。ただし、2つのサイトが完全に最新の状態になることはないため、このセットアップは障害時にデータ損失につながる可能性があります。これには以下が含まれます。

  • 非同期データベースを使用する場合、データベースの変更が障害発生時に他のサイトにレプリケートされないため、古いパスワードでユーザーがログインできるようになる、変更の損失。

  • 非同期Infinispanレプリケーションを使用する場合、無効化キャッシュが障害発生時に他のサイトに伝播されないため、古いパスワードでユーザーがログインできるようになる、無効なキャッシュ。

したがって、高可用性と整合性の間にトレードオフが存在します。このトピックの焦点は、Keycloakで可用性よりも整合性を優先することです。

次のステップ

ビルディングブロックマルチサイトデプロイメントガイドを読み続けて、さまざまなビルディングブロックのブループリントを見つけてください。

このページの内容
このガイドを編集