第14章 AWS Lambda をデプロイしてレスポンスのないサイトを無効にする
この章では、マルチサイトデプロイメントの 2 つのサイト間におけるスプリットブレインシナリオを解決する方法を説明します。1 つのサイトに障害が発生するとレプリケーションが無効になるため、他のサイトは引き続きリクエストを処理できます。
このデプロイメントは、マルチサイトデプロイメントの概念 の章で説明されているセットアップで使用することを想定しています。このデプロイメントは、マルチサイトデプロイメントのビルディングブロック の章で説明されている他のビルディングブロックとともに使用してください。
以下のブループリントは、機能的に完全な最小限の例を示すためのものであり、通常のインストールに適したベースラインのパフォーマンスを実現します。ただし、お使いの環境、組織の標準、セキュリティーのベストプラクティスに合わせて変更する必要があります。
14.1. アーキテクチャー
マルチサイトデプロイメントのサイト間でネットワーク通信障害が発生すると、2 つのサイト間でデータのレプリケーションを継続できなくなります。Data Grid には FAIL 障害ポリシーが設定されており、可用性よりも整合性が優先されます。したがって、ネットワーク接続を復元するかクロスサイトレプリケーションを無効にすることで障害が解決されるまで、すべてのユーザーリクエストにエラーメッセージが表示されます。
このようなシナリオでは、オンラインまたはオフラインとしてマークするサイトを判断するためにクォーラムが一般的に使用されます。ただし、マルチサイトデプロイメントは 2 サイトのみで構成されるため、これは不可能です。代わりに “フェンシング” を使用して、サイトの 1 つが他のサイトに接続できない場合はロードバランサー設定に 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 つのサイトエントリーが残ります。
