Cloud DNS ルーティング ポリシーとヘルスチェックを使用した、プライベート ワークロード向け自動フェイルオーバーのご紹介

※この投稿は米国時間 2022 年 10 月 25 日に、Google Cloud blog に投稿されたものの抄訳です。

高可用性は多くのお客様にとって重要な考慮事項です。これを受けて、Google Cloud は、Cloud DNS にプライベート ワークロードのヘルスチェック機能を導入することといたしました。これにより、ビジネス継続性および障害復旧（BC / DR）アーキテクチャを構築できるようになります。一般的な BC / DR アーキテクチャは、Google Cloud でマルチリージョン デプロイを使用して構築されます。過去のブログ投稿では、Cloud DNS ルーティング ポリシーを利用して、高可用性グローバル アプリケーションを公開する方法を紹介しました。グローバルに分散された、ポリシーベースの DNS 構成では信頼性を確保できますが、障害の発生時には、位置情報ポリシー構成を更新するために手動の操作が必要でした。このブログでは、内部ロードバランサ向けの Cloud DNS ヘルスチェック サポートを利用して、正常なインスタンスに自動フェイルオーバーが行われるようにする方法を紹介します。

ここでは、以前のブログで使用したものと同じ設定を使用して、例として社内知識共有ウェブ アプリケーションを使います。このアプリケーションは、従来の 2 層アーキテクチャ（エンジニアからのウェブ リクエストを処理するフロントエンド サーバーと、アプリケーションのデータを格納するバックエンド サーバー）を使用しています。

サンフランシスコ、パリ、東京のエンジニアがこのアプリケーションを使用することになるため、レイテンシ短縮、パフォーマンス向上、コスト削減を目指して、サーバーを 3 か所の Google Cloud リージョンにデプロイすることにしました。

この Wiki アプリケーションには、各リージョンから内部ロードバランサ（ILB）経由でアクセスできます。エンジニアは、ドメイン名 wiki.example.com を使用して、Interconnect または VPN 経由でフロントエンド ウェブアプリに接続します。この位置情報ポリシーは、Interconnect または VPN 接続の到達先の Google Cloud リージョンをトラフィックの送信元とみなし、そこから最も近くにある使用可能なエンドポイントを探します。

前述の設定では、いずれかのリージョン内のアプリケーションがダウンした場合、位置情報ポリシーを手動で更新して、影響を受けたリージョンを構成から削除する必要があります。担当者が障害を検出して、ポリシーを更新するまで、そのリージョンの近くのエンドユーザーはアプリケーションにアクセスできません。これでは、すぐれたユーザー エクスペリエンスとは言えません。この設計をどのように改善できるでしょうか。

Google Cloud は、内部ロードバランサ向けに Cloud DNS ヘルスチェックのサポートを導入します。内部 TCP / UDP ロードバランサの場合、バックエンド サービスに既存のヘルスチェックを使用でき、Cloud DNS は個々のバックエンド インスタンスから直接ヘルスシグナルを受け取るようになります。これにより、エンドポイントがヘルスチェックに失敗した場合に自動フェイルオーバーが可能になります。

たとえば、米国のフロントエンド サービスに異常がある場合、Cloud DNS はレイテンシに応じて、最も近いリージョンのロードバランサの IP（この例では東京の IP）をサンフランシスコのクライアントに返します。

wiki.example.com のレコードのヘルスチェックを有効にすることで、障害発生時の自動フェイルオーバーが実現され、Cloud DNS からは常にクライアント クエリのレスポンスとして正常なエンドポイントのみが返されるようになります。これによって、手動操作が不要になり、フェイルオーバー時間が大幅に短縮されます。

Cloud DNS ルーティング ポリシーの構成は、以下のようになります。

Cloud DNS マネージド ゾーンの作成:

Cloud DNS レコードセットの作成:

ヘルスチェックが正常に動作するように、ILB の参照には ILB の転送ルール名を使用する必要があります。代わりに ILB の IP を使用した場合、Cloud DNS はエンドポイントのヘルスチェックを行わなくなります。

注: Cloud DNS は、ロードバランサ自体に構成されているヘルスチェックを使用します。ユーザーは Cloud DNS 向けに追加のヘルスチェックを構成する必要はありません。GCP ロードバランサにヘルスチェックを作成する方法について詳しくは、公式ドキュメントのページをご覧ください。

この構成によって、インシデントの発生で 1 つのリージョンのアプリケーションにアクセスできなくなった場合に、ILB 上のヘルスチェックが失敗し、Cloud DNS が新たなユーザークエリを次に近い正常なエンドポイントに自動的に解決するようになります。

この構成を拡張して、フロントエンド サーバーから、最も近いリージョンの正常なバックエンド サーバーのみにトラフィックが送信されるように設定できます。

これで、エンドユーザーに最も近い正常なエンドポイントに自動フェイルオーバーする DNS ポリシーを使用して、マルチリージョン対応の多層アプリケーションを設定できました。