GSLB（グローバルサーバー負荷分散）は、利用者を地域や遅延に応じて複数の拠点へ振り分ける仕組みで、その多くはヘルスチェック型DNSの上に成り立っています。「どこへ振り分けるか」の方針と「その拠点は正常か」の判定を組み合わせることで、拠点の障害時に利用者を自動で別の拠点へ逃がせます。この記事では、2拠点のアクティブ／スタンバイ、アクティブ／アクティブ、最後の逃がし先まで含めたツリー構成の3例と、DNSの外で用意しておく必要があるもの、確認方法を説明します。
GSLBとヘルスチェック型DNSの関係
言葉の整理から始めます。
- ヘルスチェック型DNS：権威DNSが接続先を定期的に監視し、正常な接続先のアドレスだけを返すDNSです。単体ではフェイルオーバーや、正常なアドレスだけを返すラウンドロビンとして使われます。
- GSLB：ヘルスチェックの結果に、「利用者に近い拠点」「遅延が小さい拠点」「重み」「優先度」といった振り分けの方針を重ねたものです。
つまり、GSLBはヘルスチェック型DNSを土台にした応用です。実現手段としては、Amazon Route 53 のルーティングポリシー、Azure Traffic Manager、Cloudflare の Load Balancing、NS1 のようなマネージドサービスのほか、F5 BIG-IP DNS のように自社設備で動かす製品もあります（2026年10月現在）。機能名や対応する振り分け方法は製品ごとに異なり、変更もあるため、ここでは考え方を中心に、Route 53 を具体例として説明します。
構成例1：2拠点のアクティブ／スタンバイ
東京をメイン、大阪やシンガポールなど別リージョンを予備にして、普段はメインだけに振り分ける構成です。Route 53 ならフェイルオーバールーティング、Traffic Manager なら優先度（Priority）のルーティングが該当します。
この構成は振り分けの方針が単純で、データの書き込みもメイン側に集められるため、WordPressのように書き込みを1か所に集めたいアプリと相性が良い構成です。予備側は普段アクセスを受けないので、障害時に初めて動かして不具合が見つかる、ということが起きやすくなります。定期的に切り替え試験を行うか、予備側にも監視のアクセスを流して動作を確かめておきます。
構成例2：2拠点のアクティブ／アクティブ
両方の拠点で常に利用者を受け付け、利用者ごとに遅延の小さい拠点へ振り分ける構成です。Route 53 ではレイテンシーベースのルーティングを使い、拠点ごとのレコードにヘルスチェックの判定を連動させます。どちらかの拠点が異常と判定されると、その拠点へ向かっていた利用者は、次に遅延の小さい正常な拠点へ回されます。
各リージョンにロードバランサー（ALB）がある場合、エイリアスレコードの「ターゲットのヘルスを評価」を有効にすると、ロードバランサーの背後に正常なサーバーがあるかどうかが判定に使われます。1リージョン分の定義は、たとえば次のような形です（ホストゾーンIDやDNS名は環境のものに置き換えます）。
{
"Action": "UPSERT",
"ResourceRecordSet": {
"Name": "app.example.com",
"Type": "A",
"SetIdentifier": "tokyo",
"Region": "ap-northeast-1",
"AliasTarget": {
"HostedZoneId": "your-alb-hosted-zone-id",
"DNSName": "your-alb-name.ap-northeast-1.elb.amazonaws.com",
"EvaluateTargetHealth": true
}
}
}もう一方のリージョンも SetIdentifier と Region、ロードバランサーを変えて同じように登録します。ロードバランサーのヘルスチェック対象は、トップページではなく、アプリとデータベースまで動いているかを返す軽いURLにしておくと、判定の精度が上がります。
構成例3：最後の逃がし先まで含めたツリー構成
構成例2では、両方の拠点が同時に異常になると逃がし先がありません。そこで、レイテンシーで振り分ける部分をひとまとまりとして扱い、その上にフェイルオーバーを重ねて、最後にメンテナンス画面を返すようにします。
www.example.com（フェイルオーバー）
├ プライマリ：app.example.com へのエイリアス（ターゲットのヘルスを評価）
│ └ app.example.com（レイテンシー）
│ ├ 東京リージョンのALB（ターゲットのヘルスを評価）
│ └ 別リージョンのALB（ターゲットのヘルスを評価）
└ セカンダリ：静的なメンテナンス画面（オブジェクトストレージ＋CDNなど）Route 53 では、同じホストゾーンの別のレコードを指すエイリアスを作れるため、このようにレコードを段に重ねられます。レイテンシーの段にある全拠点が異常になると、プライマリ全体が異常とみなされ、セカンダリのメンテナンス画面が返ります。真っ白な画面やタイムアウトではなく、状況を伝えるページを出せるのが利点です。
段を重ねるほど設定の見通しは悪くなります。レコードの定義はコンソールで手作業するより、Terraform などの設定ファイルで管理し、変更の前後で差分を確認できるようにしておくと安全です。作業前には現在のレコードを書き出してバックアップしてください。
DNSの外で用意しておくもの
GSLBが切り替えるのは「利用者がどの拠点に接続するか」だけです。拠点を移った先でサイトが正しく動くかは、DNSの外の準備で決まります。
データの置き場所WordPressを2拠点で動かす場合、データベースの書き込みは1か所に集めるのが基本です。予備側にはレプリカを置き、メインの拠点が失われたときにレプリカを昇格させる手順を用意します。DNSが切り替わってもデータベースは自動では切り替わらないため、この手順は別に決めて訓練しておく必要があります。アップロードファイルは、両拠点から参照できるオブジェクトストレージに置くと扱いやすくなります。
1拠点で全体を受け止める余力アクティブ／アクティブで両拠点が半分ずつ受けている場合、片方が止まるともう片方に全量が来ます。オートスケーリングの上限やデータベースの性能が、全量を受け止められるかを確かめておきます。
監視元の許可と判定の意味ヘルスチェックの監視元をファイアウォールで止めていると、正常な拠点が異常と判定されます。逆に、ヘルスチェックのURLがキャッシュされていると、壊れた拠点を正常と判定します。また、すべての拠点が異常と判定されたときにどの応答を返すかはサービスごとの仕様で決まっているので、ドキュメントで確認しておきます。
振り分けを確認する方法
レイテンシーや地域による振り分けは、どこから問い合わせるかで結果が変わるため、手元の dig だけでは確かめられません。Route 53 では、利用者のアドレスを指定して応答を試算できます。
# 指定したクライアントのサブネットから問い合わせた場合の応答を試す
aws route53 test-dns-answer \
--hosted-zone-id your-hosted-zone-id \
--record-name www.example.com \
--record-type A \
--edns0-client-subnet-ip 203.0.113.1
# 権威サーバーに、EDNS Client Subnet 付きで直接問い合わせる例
dig +short www.example.com A +subnet=203.0.113.0/24 @ns-xxx.awsdns-xx.com切り替えの試験では、片方の拠点のヘルスチェック対象だけを意図的に異常にし、その拠点へ向かっていた利用者の応答が別の拠点に変わるまでの時間を測ります。続けて両方を異常にし、メンテナンス画面に切り替わるかも確かめます。異なる地域からの見え方は、海外リージョンに置いた一時的なサーバーや、外部の計測サービスを使って確認すると全体像がつかめます。
まとめ
- GSLBは、ヘルスチェック型DNSに地域・遅延・優先度などの振り分け方針を重ねた仕組みです。
- 書き込みを1か所に集めたいならアクティブ／スタンバイ、遅延を下げたいならアクティブ／アクティブを選びます。
- 全拠点が異常になったときのために、最後の逃がし先としてメンテナンス画面を重ねたツリー構成にできます。
- データベースの切り替え、1拠点で全量を受ける余力、監視元の許可は、DNSの外で用意します。
- 振り分けの確認には
test-dns-answerやdig +subnetを使い、切り替え時間を実測しておきます。