導入
「同じドメイン名でアクセスされたときに、どのサーバーへ振り分けるか」を制御するのがDNSの役割です。AWSのDNSサービス Route 53 は、単なる名前解決を超えた可用性設計の道具として使われます。
説明
Amazon Route 53 は、フルマネージドのDNSサービスです。SAAで重要なのは、多彩な ルーティングポリシー です。
| ポリシー | 動作 |
|---|---|
| シンプル | 1つのドメインに1つ（または複数をランダム）のリソースを返す |
| フェイルオーバー | プライマリにヘルスチェックを行い、異常時にセカンダリへ自動切り替え |
| レイテンシーベース | ユーザーから見て最も低遅延なリージョンへ振り分け |
| 加重（Weighted） | 設定した比率でトラフィックを振り分ける（例：新バージョンに10%だけ流すカナリアリリース） |
| 位置情報（Geolocation） | ユーザーの地理的位置に応じて振り分け（国別コンテンツの出し分けなど） |
| 複数値回答 | ヘルスチェック付きで複数のIPをランダムに返す（簡易的な負荷分散） |
これらの多くは ヘルスチェック と組み合わせて使います。Route 53が定期的にエンドポイントの状態を確認し、異常があれば正常なリソースだけを返すことで、DNSレベルでの高可用性を実現します。
flowchart TD
User["ユーザー"] --> R53["Route 53"]
R53 -->|"ヘルスチェックOK"| Primary["プライマリ (東京)"]
R53 -.->|"プライマリ異常時のみ"| Secondary["セカンダリ (大阪)"]
具体例
グローバルなSaaSの運用チームが、Route 53のポリシーを目的別に使い分けます。
- 新バージョンを安全に出したい → 加重ルーティング。新環境へ10%、現行へ90%と比率で振り分け、問題なければ徐々に新環境の比率を上げる（カナリアリリース）。事故っても影響は10%に留まる。
- 東京リージョンが落ちても止めたくない → フェイルオーバールーティング＋ヘルスチェック。普段は東京へ案内し、ヘルスチェックが東京の異常を検知したら自動で大阪へ切り替え。ユーザーは同じドメインのまま。
- 世界中のユーザーに速く届けたい → レイテンシーベース。日本のユーザーは東京、欧州のユーザーはフランクフルトへと、その人にとって最速のリージョンへ。
いずれも背後でヘルスチェックが効き、異常なエンドポイントは返さないのでDNSレベルの高可用性になります。「新バージョンに少しずつ＝加重、障害時に自動切替＝フェイルオーバー、最も近いリージョン＝レイテンシーベース」。設問の“目的の言葉”とポリシー名を対応させれば即答できます。
読んでみよう
「カナリアリリースで新バージョンに少しずつトラフィックを流したい」→ 加重ルーティング。「メインリージョン障害時に別リージョンへ自動切り替えたい」→ フェイルオーバールーティング＋ヘルスチェック。「世界中のユーザーに最も近いリージョンへ振り分けたい」→ レイテンシーベース。設問中の「目的の言葉」とポリシー名を対応させて覚えましょう。