Cloud DNS で可用性向上！ヘルスチェックで健全なサーバに繋げよう！
はじめに
Google Cloud Partner Top Engineer で
本記事では 2025/02/21 に GA になったばかりの新機能「Cloud DNS のパブリック IP によるヘルスチェック機能」についてのご紹介と、DNS ヘルスチェックによる可用性をいかにして高めるかを解説します。
SS：リリースノート
セカンダリー サーバへ切り替える苦労
BCP のジレンマ
SS：DNS 切り替えと BCP
WEB サーバのように、パブリック IP アドレスを購入したドメインに DNS で名前解決をしてサービスを公開していたとしましょう。
万が一プライマリー サーバがダウンした場合、セカンダリー サーバへ切り替えるといった BCP 対応を求められることがあると思います。
DNS レコードをプライマリー サーバからセカンダリー サーバのものへ切り替えたはいいものの、TTL が長く設定されていていわゆる「DNS の浸透待ち」といった事象に遭遇したことはないでしょうか？
切り替えが完了するまでにはタイムラグが生まれ、その間ユーザの画面にはエラーが表示され続けます。
BCP どころか機会損失にも繋がり、サービスの信頼性も低下し、ビジネスインパクトは拡大する可能性があります。
信頼性とタイムラグ
サーバがダウンしたとき、迅速かつ安全にセカンダリーを昇格させるオペレーションはサービスの信頼性を向上させるうえで重要です。
しかし、上述のようなストーリーではどうしても様々なタイムラグが発生します。
復旧までのタイムラグが伸びれば伸びるほどサービスの信頼性は低下してしまいます。
- システムダウンに気がつくまでの時間
- セカンダリーへ移行する作業時間
- DNS キャッシュがフラッシュされユーザに反映されるまでの時間
- プライマリーに復旧対応し反映されるまでの時間
ヘルスチェック ベース の オート ルーティング
Cloud DNS におけるヘルスチェック機能とルーティング ポリシー機能を組み合わせれば、プライマリー ↔ セカンダリー の切り替えと 復旧オペレーションを自動化 することができます。
各機能をご紹介します。
ヘルスチェック
指定したヘルスチェック間隔に従って、ヘルスチェック プローブを宛先 IP アドレスへ定期的に送信し健康状態を監視する機能です。
この宛先 IP アドレスは Cloud DNS で名前解決する対象サーバの IP アドレスです。
ヘルスチェック間隔が 30 秒の場合、Cloud DNS は 30 秒ごとに 1 つのヘルスチェック プローブを送信します。
万が一ヘルスチェックが失敗したとしても、しきい値を超えない限りは正常と判断されます。
また、一度成功すると異常しきい値はリセットされます。
例として、ヘルスチェック間隔としきい値を以下のように設定した場合の結果をまとめます。
表：ヘルスチェックのシナリオと結果の対応表
| 間隔 | しきい値 | シナリオ | 状態判断 |
|---|---|---|---|
| 30秒 | 5回 | 30秒間隔でポーリングし、1回目で成功した | 正常 |
| 30秒 | 5回 | 30秒間隔でポーリングし、5回目で成功した | 正常 |
| 30秒 | 5回 | 30秒間隔でポーリングし、5回すべて失敗した | 異常 |
| 30秒 | 5回 | 30秒間隔でポーリングし、5回目で成功したが6回目は失敗した | 正常 |
ルーティング ポリシー
特定のルーティング ポリシー 値に基づいてレコード セットを構成し、DNS クエリのトラフィックをルーティングする機能です。
現在サポートされているルーティング ポリシーは以下の3つです。
- 重み付きラウンドロビン（WRR）ルーティング ポリシー
- 位置情報に基づくルーティング ポリシー
- フェイルオーバー ルーティング ポリシー
表：ルーティングポリシーと概要説明
| ポリシー名 | 概要説明 |
|---|---|
| 重み付きラウンドロビン（WRR） | 重み付けを設定してラウンドロビン方式でトラフィックを分散する |
| 位置情報 | 送信元の位置情報を取得し、最も地理的に近い場所にあるサーバへ転送する |
| フェイルオーバー | アクティブ/スタンバイ構成をとり、動作しているプライマリーまたはアクティブなサーバへ転送する |
復旧までの流れ
ヘルスチェック機能とルーティング ポリシー機能を組み合わせたとき、プライマリー ↔ セカンダリー の切り替えと復旧には以下のように作用します。
異常検知 / 切り替え / 復旧までの一連のオペレーションを自動化することで、ダウンタイムを最小限に抑えユーザ離れを防ぐことができます。
表：状態遷移と対応機能
| # | 状態 | シナリオ | 対応する機能 | ルーティング先 |
|---|---|---|---|---|
| 1 | 🟩 | プライマリーの健康状態を監視 | ヘルスチェック | プライマリー |
| 2 | 🟨 | プライマリーの異常を検知 | ヘルスチェック | プライマリー |
| 3 | 🟥 | DNS レコードのルーティングを動的に変更 | ルーティング ポリシー | セカンダリー |
| 4 | 🟨 | プライマリーの復旧を検知 | ヘルスチェック | セカンダリー |
| 5 | 🟨 | DNS レコードのルーティングを動的に変更 | ルーティング ポリシー | プライマリー |
| 6 | 🟩 | プライマリー完全復旧 | ヘルスチェック | プライマリー |
🟩：正常 🟨：異常検知 🟥：異常
新機能：パブリック IP アドレス によるヘルスチェック
公式ドキュメントより引用
ヘルスチェック機能自体はすでに Cloud DNS で提供されていましたが、限定公開ゾーンの DNS ルーティング ポリシーのみ一般提供（GA）されていました。
そのため、Google Cloud 内部に閉じた通信を行うプロダクトに用途が限定されることがあり、パブリック インターネットに公開するサービスへの展開を望む声は多かったと思います。
- 内部パススルー ネットワーク ロードバランサ（GA）
- 内部アプリケーション ロードバランサ（GA）
- クロスリージョン内部アプリケーション ロードバランサ（GA）
- 内部プロキシ ネットワーク ロードバランサ（Preview）
今回のアップデートにより、一般公開ゾーンの DNS ルーティング ポリシーでも GA となり、パブリック インターネット越しのヘルスチェックが構成できるようになりました。
Cloud DNS で障害復旧までやってみた
実際に Cloud DNS と WEB サーバ（Nginx）を構成し、動作を検証してみましょう。
使用する Google Cloud リソースは以下のとおりです。
VPC ネットワーク と GCE の構築手順は割愛します。
- Cloud DNS 一般公開 ゾーン
- プライマリー用 GCE インスタンス
- セカンダリー用 GCE インスタンス
- GCE インスタンス 用 VPC ネットワークとサブネット
Step1 WEB サーバを用意する
SS：Nginx をインストールした GCE インスタンス
Step2 ヘルスチェックを作成する
ゾーンの作成手順は割愛しますが、今回は一般公開ゾーンを利用します。
レコードセットを作成する前に、事前にヘルスチェックを作成するか Cloud Console のウィザードに従って同時作成をしてください。
$ gcloud beta compute health-checks create tcp ${HEALTH_CHECK_NAME} \
--check-interval=30 --timeout=5 \
--unhealthy-threshold=2 --healthy-threshold=2 \
--port=80 --proxy-header=NONE --no-enable-logging \
--source-regions=asia-northeast1,asia-northeast2,asia-northeast3 \
--project=${PROJECT_ID}
Step3 Cloud DNS ゾーン と レコード セットを作成する
WEB サーバの IP アドレスをドメインに名前解決するためのレコードセットでは、通常の A レコードではなく「ルーティング ポリシー 付きのレコードセット」を作成することに注意してください。
$ gcloud beta dns record-sets create ${RECORD_SETS_NAME}. \
--type="A" --ttl="60" \
--routing-policy-type="FAILOVER" \
--routing-policy-primary-data="${PRIMARY_IP}" \
--backup-data-trickle-ratio="0.0" \
--routing-policy-backup-data-type="GEO" \
--routing-policy-backup-data="${SECONDARY_REGION=SECONDARY_IP}" \
--health-check="${HEALTH_CHECK_NAME}" \
--zone="${DNS_ZONE_NAME}" \
--project=${PROJECT_ID}
Step2 と Step3 が完了すると、以下のように Cloud DNS の一般公開ゾーンとレコードセットが作成されていることが確認できます。
 |
 |
|---|---|
|
SS：一般公開ゾーン |
SS：ルーティング ポリシー 付きのレコードセット |
Step4 プライマリー サーバをダウンさせてみる
プライマリー サーバとなる GCE インスタンスをシャットダウンさせ、どのように名前解決の結果が変化するかを nslookup コマンドで確認します。
正常性確認
まずは正常時の場合、以下のようにプライマリー サーバのパブリック IP アドレスが正常に返ることが確認できます。
$ nslookup ${HOST_NAME}
Server: # 実行端末のローカル IP
Address: # 実行環境のローカル ゲートウェイ IP
Non-authoritative answer:
Name: ${HOST_NAME}
Address: xx.xx.xx.xx # プライマリー サーバの IP アドレス
疑似障害発生
正常性確認ができたところで、プライマリー サーバをシャットダウンし、擬似的なシステム障害を発生させます。
フェイルオーバー 確認
その直後、再度 nslookup コマンドでドメインに紐づいた IP アドレスを確認します。
この時点でフェイルオーバーは完了し、セカンダリー サーバの IP アドレスとなっていることが確認できました。
$ nslookup ${HOST_NAME}
Server: # 実行端末のローカル IP
Address: # 実行環境のローカル ゲートウェイ IP
Non-authoritative answer:
Name: ${HOST_NAME}
Address: xx.xx.xx.xx # セカンダリー サーバの IP アドレス
自動復旧確認
最後に、プライマリー サーバを起動させ、擬似的な障害復旧を再現します。
GCE インスタンスが起動したことを確認し、再度 nslookup コマンドでドメインに紐づいた IP アドレスを確認します。
正常時と同様に、プライマリー サーバのパブリック IP アドレスへ自動的に切り替わっていれば成功です。
$ nslookup ${HOST_NAME}
Server: # 実行端末のローカル IP
Address: # 実行環境のローカル ゲートウェイ IP
Non-authoritative answer:
Name: ${HOST_NAME}
Address: xx.xx.xx.xx # プライマリー サーバの IP アドレス
まとめ
Cloud DNS のヘルスチェック機能とルーティング ポリシー機能を組み合わせれば、アクティブ / スタンバイ構成のサーバに対する DNS レコードの切り替えや復旧を迅速かつ安全に実施することができます。
また、これを応用すれば複数の環境にまたがったマルチクラウド構成やハイブリッド構成にも展開することができ、幅広い展開が期待できます。
可用性と信頼性の向上のお供にぜひ試してみてください。
Discussion