第12章 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 つのサイトエントリーが残ります。