SAP-C02-077 · セクション 09 / タスク 2.4

Route 53 Routing Policyによる可用性設計

シンプルルーティング / 加重ルーティング / レイテンシールーティング / フェイルオーバールーティング / 位置情報ルーティング / 地理的近接性ルーティング / IPベースルーティング / 複数値回答ルーティング / ヘルスチェック

ゴール

Amazon Route 53のルーティングポリシーを、

名前だけ暗記
↓
シナリオで迷う

状態にしません。

最初に、

DNSで
何を基準に
応答先を選びたいか？

を確認します。

単一リソース
↓
シンプル

割合
↓
加重

最小レイテンシー
↓
レイテンシー

アクティブ / パッシブ
↓
フェイルオーバー

利用者の国・地域
↓
位置情報

利用者とリソースの地理的距離
+
境界を調整
↓
地理的近接性

既知の送信元IP範囲
↓
IPベース

複数の正常なIPを返す
↓
複数値回答

という判断軸を作ります。

1. ルーティングポリシーは「DNS回答の選び方」

Amazon Route 53のルーティングポリシーは、

パケットごとに
トラフィックを振り分ける

ロードバランサーではありません。

ルーティングポリシーは、DNSクエリに対して、どのレコード値を回答候補にするかを決めます。

したがって、

DNS応答
↓
リゾルバー / クライアントがキャッシュ
↓
実際の接続

という性質を持ちます。

特に加重ルーティングで、

90 : 10

と設定しても、個々のHTTPリクエストが厳密に90% / 10%へ分配されるわけではありません。

DNSキャッシュの影響を受けるため、DNS回答ベースのおおよその分配として考えます。

2. 最初に「選択目的」を決める

8種類のルーティングポリシーを比較するときは、次の質問から始めます。

何を制御したいか？
│
├─ 1つの通常回答
├─ トラフィック割合
├─ レイテンシー
├─ アクティブ / パッシブ
├─ 利用者の国・地域
├─ 利用者とリソースの距離
├─ 既知のIP範囲
└─ 複数の正常な回答

ヘルスチェックは、この目的そのものではありません。

例えば、

レイテンシーを最小化したい
+
異常リージョンは除外したい

なら、

レイテンシールーティング
+
ヘルスチェック

です。

ルーティングポリシーが選択基準を決め、正常性は候補から除外する条件になると考えます。

3. シンプルルーティング：単一リソースへの標準的なDNS回答

シンプルルーティングは、

この名前
↓
このリソース

という単純なDNS回答に向いています。

例えば、

app.example.com
↓
1台のウェブサーバー

です。

シンプルルーティングでは1つのレコードに複数の値を含めることもできます。

app.example.com
↓
192.0.2.10
192.0.2.20
192.0.2.30

この場合、複数の値を回答できます。

ただし、各値を個別に正常性評価して、

異常な192.0.2.20だけ
回答候補から除外

するための方式ではありません。

その要件では、複数値回答ルーティングなどを評価します。

4. 加重ルーティング：指定割合でDNS回答を分ける

加重ルーティングでは、同じ名前・タイプを持つ複数レコードへ重みを設定します。

例えば、

旧環境
重み 90

新環境
重み 10

なら、おおよそ、

旧環境
90 / (90 + 10)

新環境
10 / (90 + 10)

の割合で選択されます。

典型的な用途は、

カナリアリリース
段階的移行
新旧環境のトラフィック分割
複数リソースへの比率制御

です。

例えば、

旧環境 99
新環境 1

から開始し、

のように段階的に移行できます。

重要なのは、重みは相対値ということです。

1 と 1

なら50%ずつ、

10 と 10

でも50%ずつです。

5. 重み0には特殊な動作がある

通常、

現行環境
重み 100

待機環境
重み 0

とすると、Route 53はまず重みが0より大きいレコードを対象にします。

ただし、すべての加重レコードへ正常性評価を設定していて、

重みが0より大きいレコード
↓
すべて異常

になった場合、Route 53は重み0のレコードも評価対象にします。

したがって、

重み0
=
どんな状態でも
絶対に回答候補にならない

とは判断しません。

また、

全レコード
重み0

とすると、Route 53はそれらのリソースへ等しい確率でルーティングします。

6. レイテンシールーティング：最も低いレイテンシーを期待できるリージョン

レイテンシールーティングは、

利用者
↓
地理的に最も近い場所

を単純に選ぶポリシーではありません。

Route 53が保持するAWSリージョンとのレイテンシーデータから、利用者へ最も低いレイテンシーを提供すると判断したAWSリージョンのレコードを選択します。

例えば、

東京リージョン
シンガポールリージョン
シドニーリージョン

に同じアプリケーションがある場合、

利用者
↓
Route 53が
最適なレイテンシーの
リージョンを判断
↓
対応するレコードを回答

します。

地理的に最も近いリージョンが、必ず最低レイテンシーになるとは限りません。

7. レイテンシーと正常性は別の判断軸

レイテンシーレコードへ正常性評価を組み合わせた場合、

最も低レイテンシーの候補
↓
異常

なら、Route 53は別の正常なレイテンシーレコードを評価できます。

つまり、

レイテンシールーティング
↓
性能上の選択基準

正常性評価
↓
利用可能な候補か

です。

正常性評価を追加しても、

レイテンシールーティング
=
フェイルオーバールーティング

になるわけではありません。

8. フェイルオーバールーティング：明確なアクティブ / パッシブ

フェイルオーバールーティングは、

プライマリ
↓
異常時のみ
↓
セカンダリ

というアクティブ / パッシブ要件に使用します。

例えば、

東京
プライマリ

大阪
セカンダリ

です。

ここでの決定条件は、割合、レイテンシー、利用者地域ではなく、優先順位を固定した待機系切り替えです。

9. 位置情報ルーティング：利用者の国・地域を明示的に分ける

位置情報ルーティングでは、DNSクエリの送信元として推定された利用者の地理的位置に基づいて回答を変えます。

指定できる主な単位は、

大陸
国
米国の州

です。

例えば、

日本
↓
日本向けサイト

ドイツ
↓
EU向けサイト

という制御です。

典型例は、

言語・コンテンツのローカライズ
配信権による地域制御
地域単位で明示的に接続先を固定

です。

10. 位置情報では「より具体的な地域」が優先される

例えば、

北米
↓
エンドポイントA

カナダ
↓
エンドポイントB

の両方を作成した場合、カナダからのクエリには、

カナダ

というより具体的なレコードが優先されます。

また、位置を特定できないIPや、対応する地域レコードが存在しないクエリがあります。

そのため、

デフォルト
↓
エンドポイントC

を用意できます。

デフォルトレコードがなければ、該当する位置情報レコードがないクエリへ回答できない場合があります。

11. 地理的近接性ルーティング：利用者とリソースの距離 + バイアス

地理的近接性ルーティングは、位置情報ルーティングとは目的が異なります。

判断するのは、

利用者は
どの国に属するか

ではなく、

利用者と
各リソースの地理的距離

です。

AWSリソースではAWSリージョンやローカルゾーングループを指定し、AWS外のリソースでは緯度・経度を指定できます。

12. バイアスで地理的な境界を動かす

地理的近接性ルーティングでは、バイアスを使って担当する地理的範囲を調整できます。

正のバイアス
↓
そのリソースが担当する地域を拡大

負のバイアス
↓
そのリソースが担当する地域を縮小

有効範囲は、

-99 ～ 99

です。

例えば、

東京
バイアス +30

シンガポール
バイアス 0

なら、東京側へルーティングされる地理的範囲を広げる方向に働きます。

したがって、

日本からは必ず東京

のような行政区分ベースの制御ではなく、リソース周辺の担当境界を距離ベースで調整したい場合に使います。

13. IPベースルーティング：自社が知っているIP範囲を使う

IPベースルーティングは、

Route 53が推定する
国・距離

ではなく、自社が把握している送信元IP範囲をルーティング判断へ使いたい場合に選択します。

例えば、

ISP AのCIDR
↓
エンドポイントA

ISP BのCIDR
↓
エンドポイントB

です。

主な用途は、

特定ISPごとの経路最適化
ネットワークコスト最適化
自社が把握する利用者IP範囲への個別制御

です。

CIDRブロックをCIDRロケーションへまとめ、それらをCIDRコレクションとして管理します。

IPベースルーティングはプライベートホストゾーンではサポートされません。

14. 位置情報とIPベースを混同しない

両方とも利用者側の情報を使いますが、判断材料が違います。

要件	候補
日本・ドイツ・米国など地理的位置で分けたい	位置情報ルーティング
ISP AのCIDRだけ特定エンドポイントへ送りたい	IPベースルーティング
自社で保有する利用者IP範囲の知識を反映したい	IPベースルーティング

つまり、

利用者の地理的位置
↓
位置情報

利用者の既知IP範囲
↓
IPベース

です。

15. 複数値回答ルーティング：複数の値を正常性と組み合わせて返す

複数値回答ルーティングでは、1つのDNSクエリに対して複数のレコード値を返せます。

レコードごとにヘルスチェックを関連付け、

サーバーA
正常

サーバーB
異常

サーバーC
正常

なら、正常な候補が存在する場合は、

サーバーA
サーバーC

のように正常なレコードを回答できます。

Route 53はDNSクエリへ最大8つの正常レコードを返します。

正常レコードが8件以下なら、すべての正常レコードを返します。

ただし、重要な例外があります。

すべての複数値回答レコード
↓
異常

の場合、Route 53は無回答にするのではなく、最大8つの異常レコードを回答します。

したがって、

複数値回答
=
異常レコードは
どんな状況でも絶対に返らない

とは一般化しません。

16. 複数値回答はロードバランサーの代替ではない

複数値回答ルーティングは、

DNS
↓
複数のレコード値を返す

仕組みです。

Application Load Balancerのように、

各HTTPリクエスト
↓
ターゲット正常性
↓
リクエスト単位で分散

するものではありません。

したがって、

複数のIPを
正常性と組み合わせて
DNS回答したい

なら複数値回答、

アプリケーションへの
本格的な負荷分散が必要

ならElastic Load Balancingなどを評価します。

17. シンプルの複数値と複数値回答を区別する

シンプルルーティングでも、1つのレコードに複数のIPアドレスを設定できます。

ただし、

シンプル
↓
複数値を回答できる
↓
値ごとに
正常性評価する方式ではない

のに対して、

複数値回答
↓
レコード単位の正常性評価
↓
正常候補が存在すれば
正常な値を最大8件回答

という違いがあります。

なお、複数値回答でも全レコードが異常な場合は最大8件の異常レコードを回答します。

したがって、複数の値を返したいだけなのか、レコードごとの正常性をルーティング判断へ組み込みたいのかを分けます。

18. ヘルスチェックはルーティング目的を置き換えない

正常性評価を組み合わせると、正常な候補が存在する場合は異常候補を避けて回答できます。

例えば、

レイテンシールーティング
+
正常性評価

なら、

正常な候補の中で
低レイテンシー

を選びます。

加重ルーティング
+
正常性評価

なら、

利用可能な候補を考慮し
重みに基づいて選択

します。

ただし、各ルーティングポリシーには全候補異常時などの個別動作があります。

そのため、

ヘルスチェックあり
↓
異常レコードは
必ず何があっても回答されない

とは一般化しません。

重要なのは、選択基準と正常性条件を別々に考えたうえで、そのポリシー固有の例外動作も確認することです。

19. 8種類を同じ判断軸で比較する

要件	ルーティングポリシー	決定打
単一リソースへ通常のDNS回答	シンプル	特別な振り分け不要
指定割合で分ける	加重	相対的な重み
最も低いレイテンシーを期待するAWSリージョン	レイテンシー	Route 53のレイテンシーデータ
プライマリ障害時のみセカンダリ	フェイルオーバー	アクティブ / パッシブ
国・大陸・米国州で明示的に分ける	位置情報	利用者の地理的位置
利用者とリソースの距離で選び境界も調整	地理的近接性	距離 + バイアス
既知のCIDR / ISP単位で分ける	IPベース	CIDRコレクション
複数レコードを正常性と組み合わせて回答	複数値回答	正常候補があれば最大8件の正常レコード

20. シナリオ1：新バージョンへ5%だけ流す

要件：

旧環境
現在の本番

新環境
新バージョン

まず5%だけ
新環境へ流したい

この場合、

旧環境
重み 95

新環境
重み 5

の加重ルーティングを評価します。

決定打は、明示的な割合制御です。

21. シナリオ2：利用者に最も低いレイテンシーを提供する

要件：

東京
フランクフルト
バージニア

同じアプリケーションを配置

利用者ごとに
最も低いレイテンシーを期待できる
AWSリージョンへ接続

なら、レイテンシールーティングを評価します。

ここでは、

国ごとに固定

する位置情報ルーティングではありません。

22. シナリオ3：配信権によって国単位で分ける

要件：

日本
日本向けコンテンツ

米国
米国向けコンテンツ

その他
共通サイト

なら、

日本
米国
デフォルト

の位置情報レコードを評価します。

決定打は、行政的な地理区分ごとに接続先を明示したいことです。

23. シナリオ4：特定ISPだけ専用経路へ送る

要件：

ISP Aの利用者
↓
専用エンドポイント

その他
↓
標準エンドポイント

で、ISP AのCIDR範囲を把握しているなら、IPベースルーティングを評価します。

これは、

ISP Aの利用者が
どの国にいるか

ではなく、既知の送信元IP範囲が決定条件です。

24. 混同ポイント

混同	正しい判断
地理的に近い = レイテンシールーティング	レイテンシーはRoute 53のレイテンシーデータで判断
国ごとに分ける = 地理的近接性	国・大陸など明示的地域なら位置情報
地理的近接性 = 位置情報	地理的近接性は利用者とリソースの距離 + バイアス
ISP別に分けたい = 位置情報	既知CIDRならIPベース
加重90 / 10 = HTTPリクエストを厳密に90 / 10	DNS回答ベースなのでキャッシュの影響を受ける
重み0 = どんな条件でも絶対に選ばれない	非ゼロ重みがすべて異常なら評価対象になる場合がある
全加重レコードを重み0にすると無回答	すべて等しい確率でルーティングされる
シンプルで複数IPを返せば異常IPも自動除外	シンプルの複数値は値ごとの正常性評価を目的としない
複数値回答なら異常レコードは絶対に返らない	全レコード異常なら最大8件の異常レコードを返す
複数値回答 = ALB	DNS回答方式でありロードバランサーの代替ではない
ヘルスチェックを付ければ全部フェイルオーバールーティング	正常性は候補条件であり、選択目的は元のポリシーに残る

25. SAP-C02判断フロー

DNSで何を決めたい？
│
├─ 特別な振り分け不要
│      ↓
│   シンプル
│
├─ 割合
│      ↓
│   加重
│
├─ 最小レイテンシー
│      ↓
│   レイテンシー
│
├─ プライマリ / セカンダリ
│      ↓
│   フェイルオーバー
│
├─ 国 / 大陸 / 米国州
│      ↓
│   位置情報
│
├─ 利用者とリソースの距離
│  + 地理的境界を調整
│      ↓
│   地理的近接性
│
├─ 既知CIDR / ISP
│      ↓
│   IPベース
│
└─ 複数レコードを
   正常性と組み合わせて回答
       ↓
    複数値回答

その後
↓
異常候補を避ける必要があるか
↓
必要に応じて正常性評価を組み合わせる
↓
全候補異常時など
ポリシー固有動作も確認

まとめ

Route 53のルーティングポリシーは、

どれが一番高可用か

で選ぶものではありません。

先に、

DNS回答を
何に基づいて選びたいか

を決めます。

単一
割合
レイテンシー
アクティブ / パッシブ
地理的位置
地理的距離
既知IP
複数レコード

という選択目的を明確にした後、

正常性評価

を必要に応じて組み合わせます。

最も重要なのは、ルーティング目的と正常性条件を別々に考え、固有の例外動作も確認することです。

主要AWS公式資料

AWS Certified Solutions Architect - Professional 試験ガイド（SAP-C02）
Amazon Route 53 — ルーティングポリシーの選択
Amazon Route 53 — シンプルルーティング
Amazon Route 53 — 加重ルーティング
Amazon Route 53 — レイテンシールーティング
Amazon Route 53 — フェイルオーバールーティング
Amazon Route 53 — 位置情報ルーティング
Amazon Route 53 — 地理的近接性ルーティング
Amazon Route 53 — IPベースルーティング
Amazon Route 53 — 複数値回答ルーティング
Amazon Route 53 — ヘルスチェック設定時のレコード選択

理解確認

このページの内容を10問で確認します。

理解確認10問へ →