ネットワーキング

Cloud DNS ルーティングポリシーを使って世界各地の社員にアプリケーションを公開する方法

2022年1月28日

https://storage.googleapis.com/gweb-cloudblog-publish/images/GCP-networking-01.max-2600x2600.jpg

Google Cloud Japan Team

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

ビジネスにとって特に重要なアプリケーションを構築するときに、切っても切り離せないのが高可用性の問題です。Google Cloud では、戦略的アプリケーションの構築にはマルチリージョンのアーキテクチャを採用することを推奨しています。この記事では、Cloud DNS ルーティングポリシーを使って、マルチリージョンの設計を簡略化する方法を紹介します。

例として Google の社内ウェブアプリケーションを取り上げます。その中で知識の共有を目的とした Wiki アプリケーションを見てみましょう。このアプリケーションでは、従来の 2 層アーキテクチャ（エンジニアからのウェブリクエストを処理するフロントエンドサーバーと、アプリケーションのデータを格納するバックエンドサーバー）を使用しています。

このアプリケーションは米国（サンフランシスコ）、ヨーロッパ（パリ）、アジア（東京）のエンジニアに利用されているので、この 3 か所の Google Cloud リージョンでサーバーをデプロイすることにしました。それにより、レイテンシやパフォーマンスの問題を回避するとともに、費用を抑えることが狙いです。

https://storage.googleapis.com/gweb-cloudblog-publish/images/1_high_leel_design.max-1000x1000.jpg

設計の概要図

この Wiki アプリケーションは各リージョンで内部ロードバランサ（ILB）経由で公開されます。エンジニアは ILB に Interconnect または Cloud VPN 経由で接続します。

ここで課題となってくるのは、ユーザーから最も近い使用可能なフロントエンドサーバーを判断し、そこにユーザーを送信する仕組みです。

もちろん、<region>.wiki.example.com（<region> は US、EU、ASIA）という形式でリージョンごとのホスト名を使用することも可能ですが、この方法だと、エンジニアが自分でリージョンを選択しなければならず、ユーザー側に余計な負担をかけることになります。それだけでなく、いずれかのリージョンで Wiki アプリケーションがダウンした場合、ユーザーは手動で別のリージョンのホスト名に変えなければならず、あまり使い勝手が良いとはいえません。

では、どのような設計にすればよいのでしょうか。

Cloud DNS Policy Manager を使えば、グローバルなホスト名（wiki.example.comなど）を 1 つ用いて、位置情報ポリシーに基づき、このホスト名をエンドユーザーに最も近いエンドポイントに解決することが可能です。具体的には、Interconnect または VPN 接続の到達先の GCP リージョンをトラフィックの送信元とみなし、そこから最も近くにある使用可能なエンドポイントが探されるという仕組みになっています。

たとえば、以下の図に示すように、米国のユーザーに対するホスト名を米国内部のロードバランサの IP アドレスに解決します。

https://storage.googleapis.com/gweb-cloudblog-publish/images/2_DNS_resolution.max-1000x1000.jpg

ユーザーの場所に基づく DNS 解決

この方法により、クライアント側をシンプルな構成にして、ユーザーエクスペリエンスを向上させることができます。

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

読み込んでいます...

Cloud DNS ルーティングポリシーの構成方法について詳しくは、公式ドキュメントのページをご覧ください。

この構成は、Wiki アプリケーションの信頼性を向上させるためにも効果的です。たとえば、いずれかのリージョンでなんらかのインシデントが発生し、アプリケーションを使用できなくなった場合は、位置情報ポリシーを更新して、そのリージョンを構成から削除することができます。そうすると、それ以降に接続したユーザーに対しては、次に近いリージョンが解決に使用されるようになり、クライアント側やアプリケーションチームの側で特に操作しなくても済みます。

ここまでで、この位置情報機能はユーザーを最も近くのリソースへ送信するのに便利であるということを見てきました。さらに、この機能はマシン間のトラフィックの処理にも使用できます。

前述のウェブアプリケーションの例を拡張して、世界中のフロントエンドサーバーを同じように構成し、フロントエンドサーバーと同じリージョンにあるバックエンドサーバーを確実に使用するようにしてみましょう。

そのために、フロントエンドサーバーが backend.wiki.example.com というグローバルホスト名に接続するように構成します。このホスト名の解決には、Cloud DNS の位置情報ポリシーに従ってフロントエンドサーバーの GCP リージョン情報が参照されたうえで、バックエンド層の内部ロードバランサのうち最も近くにあるものが使用されます。