レイテンシーベースルーティング
ユーザーからのDNSクエリに対して、最もレイテンシが低いAWSリージョンのリソースを返すルーティングポリシー
“If your application is hosted in multiple AWS Regions, you can improve performance for your users by serving their requests from the AWS Region that provides the lowest latency.”
仕組み
“When Route 53 receives a DNS query for your domain or subdomain, it determines which AWS Regions you’ve created latency records for, determines which Region gives the user the lowest latency, and then selects a latency record for that Region.”
ユーザー（東京）→ DNS問い合わせ → Route 53
│
レイテンシ測定データを参照
│
┌─────────────────────┼─────────────────────┐
▼ ▼ ▼
東京リージョン バージニア フランクフルト
(レイテンシ: 低) (レイテンシ: 高) (レイテンシ: 中)
│
▼
東京のIPアドレスを返す
設定例
“To use latency-based routing, you create latency records for your resources in multiple AWS Regions.”
ルーティング先のリージョンごとに同じ名前のレコードを作成する必要がある
東京とバージニアにALBがある場合、2つのレコードを作成:
レコード1:
名前: api.example.com
タイプ: A (エイリアス)
ルーティングポリシー: レイテンシー
リージョン: ap-northeast-1 (東京)
値: 東京のALB
SetIdentifier: "tokyo"
レコード2:
名前: api.example.com
タイプ: A (エイリアス)
ルーティングポリシー: レイテンシー
リージョン: us-east-1 (バージニア)
値: バージニアのALB
SetIdentifier: "virginia"
SetIdentifierとは
通常、DNSレコードは「名前 + タイプ」で一意だが、レイテンシーベースルーティングでは同じ名前・同じタイプのレコードを複数作る。Route 53内部でこれらを区別するための識別子がSetIdentifier
出典: Values specific for latency records
“Set ID: Enter a value that uniquely identifies this record in the group of latency records.”
SetIdentifierは管理用のラベルで、ユーザーには見えない
注意点
“Latency between hosts on the internet can change over time as a result of changes in network connectivity and routing. Latency-based routing is based on latency measurements taken over a period of time, and the measurements reflect these changes.”
- レイテンシ測定はAWSの過去データに基づく（リアルタイム測定ではない）
- ネットワーク状況により結果が変わる可能性がある
ユースケース
- グローバルWebアプリで最寄りリージョンへ誘導
- マルチリージョンAPIのレスポンス時間最小化
加重 (Weighted) ルーティング
同じドメイン名に対して複数のリソースにトラフィックを分散させるルーティングポリシー。各レコードに「重み」を設定し、その比率でトラフィックを振り分ける
出典: Weighted routing - Amazon Route 53
“Weighted routing is a feature of Amazon Route 53 that enables distributing traffic to multiple resources using the same domain or subdomain name, with each resource assigned a relative weight. The traffic distribution is based on the weight assigned to each record as a proportion of the total weight for all records in the group.”
例
| レコード | 重み | トラフィック比率 |
|---|---|---|
| サーバーA | 70 | 70% |
| サーバーB | 30 | 30% |
ユースケース
出典: Weighted routing - Amazon Route 53
“This can be useful for load balancing and testing new software versions.”
- ロードバランシング
- 新バージョンのカナリアリリース（少量のトラフィックで新版をテスト）
- Blue/Greenデプロイメント
TTL (Time To Live)
DNSの一般的な概念
Route 53でDNSレコードを作成する際、各レコードにTTLを設定することになる
レコード作成時の設定項目:
- レコード名: api.example.com
- レコードタイプ: A
- 値: 192.0.2.1
- TTL: 300 ← ここで設定
- ルーティングポリシー: Simple
出典: Values that are common for all routing policies - Amazon Route 53
“TTL (seconds): Specify the amount of time, in seconds, that you want DNS recursive resolvers to cache information about this record.”
TTLとは
DNSリゾルバがレコード情報をキャッシュする時間（秒単位）
出典: Values specific for weighted records - Amazon Route 53
“TTL is the time, in seconds, that DNS recursive resolvers cache information about the record, with longer values reducing the number of calls to Route 53 but increasing the time for changes to take effect.”
トレードオフ
| TTL | メリット | デメリット |
|---|---|---|
| 長い（例: 86400秒=1日） | Route 53への問い合わせ減少、コスト削減 | 変更反映に時間がかかる |
| 短い（例: 60秒） | 変更が素早く反映 | 問い合わせ増加、コスト増 |
使い分け
- 通常運用: 長めのTTL（数時間〜1日）
- 移行・切り替え前: 短いTTLに変更して待機
- 障害時のフェイルオーバー: 短いTTLが有利
関連用語
DNSリゾルバ (DNS Resolver)
ユーザーのDNSクエリを受け取り、権威DNSサーバーに問い合わせて結果を返すサーバー。ISPやGoogle (8.8.8.8) などが提供している。TTLの間はキャッシュを保持する
ルーティングポリシー一覧
“When you create a record, you choose a routing policy, which determines how Amazon Route 53 responds to queries.”
| ポリシー | 説明 |
|---|---|
| Simple | 単一リソースへのルーティング |
| Failover | アクティブ-パッシブフェイルオーバー |
| Geolocation | ユーザーの地理的位置に基づく |
| Geoproximity | リソースの位置とトラフィックシフト |
| Latency | 最低レイテンシのリージョンへ |
| IP-based | ユーザーのIPアドレスに基づく |
| Multivalue answer | 最大8つの正常なレコードをランダムに返す |
| Weighted | 指定比率で複数リソースに分散 |