第21章 応答しないサイトを無効にするための AWS Lambda のデプロイ

マルチクラスターデプロイメントのサイト間でネットワーク通信障害が発生すると、2 つのサイト間でデータのレプリケーションを継続できなくなります。Data Grid には FAIL 障害ポリシーが設定されており、可用性よりも整合性が優先されます。したがって、ネットワーク接続を復元するかクロスサイトレプリケーションを無効にすることで障害が解決されるまで、すべてのユーザーリクエストにエラーメッセージが表示されます。

このような状況では、オンラインまたはオフラインとしてマークするサイトを判断するために、クォーラムが一般的に使用されます。しかし、マルチクラスターデプロイメントは 2 つのサイトのみで構成されるため、これは不可能です。代わりに、“フェンシング” を活用して、一方のサイトが他方のサイトに接続できない場合に、ロードバランサー設定に残るサイトが 1 つだけになるようにして、このサイトだけが後続のユーザーリクエストを処理できるようにします。

フェンシングの手順では、ロードバランサーの設定に加え、2 つの Data Grid クラスター間のレプリケーションを無効にして、ロードバランサー設定に残っているサイトからのユーザーリクエストに対応できるようにします。その結果、レプリケーションが無効になるとサイトは同期されなくなります。

非同期状態から回復するには、サイトの同期 で説明されているとおり手動で再同期する必要があります。このような理由から、フェンシングによって削除されたサイトは、ネットワーク通信障害が解決されても自動的に再追加されません。削除されたサイトは、サイトをオンラインにする の手順に従って、必ず 2 つのサイトを同期してから再度追加してください。

この章では、Prometheus アラート と AWS Lambda 関数を組み合わせてフェンシングを実装する方法を説明します。Data Grid サーバーのメトリクスによってスプリットブレインが検出されると、Prometheus アラートがトリガーされ、Prometheus AlertManager が AWS Lambda ベースの Webhook を呼び出します。トリガーされた Lambda 関数は、現在の Global Accelerator 設定を検査し、オフラインであると報告されたサイトを削除します。

両方のサイトがまだ稼働しているがネットワーク通信がダウンしている真のスプリットブレインシナリオでは、両方のサイトが同時に Webhook をトリガーする可能性があります。これを防止するために、一度に 1 つの Lambda インスタンスのみを実行できるようにします。AWS Lambda のロジックにより、ロードバランサー設定には必ず 1 つのサイトエントリーが残ります。