Route 53ルーティング

このレッスンでできるようになること。可用性やトラフィック配分の要件文から、Route 53 のルーティングポリシーを1つ選び、ヘルスチェックと組み合わせて設計できるようになります。

要件の文から入る

ある会社が、東京リージョンで本番の Web システムを運用し、別リージョンに待機環境を用意しました。要件は「本番が応答しなくなったら、利用者を自動的に待機環境へ向けること。平常時のトラフィックはすべて本番へ流すこと」です。DNS 側で何を設定しますか。

拾う語は「応答しなくなったら」「自動的に」「平常時はすべて本番へ」です。平常時に配分しないのだから加重は違います。地理や距離で分けるわけでもありません。フェイルオーバールーティングにプライマリとセカンダリのレコードを登録し、プライマリにヘルスチェックを紐付けるのが答えです。

ここで大事なのは、ヘルスチェックを付けなければフェイルオーバーは起きないという点です。プライマリのレコードにヘルスチェックが関連付けられて初めて、Route 53 は異常を検知してセカンダリを返すようになります。選択肢の中に「フェイルオーバーレコードを作成する」とだけ書かれたものと「ヘルスチェックを関連付けたフェイルオーバーレコードを作成する」の両方が並ぶことがあり、後者が正解です。

ルーティングポリシーの対応表

要件語との対応で覚えます。ここが得点源です。

特に混同されるのがレイテンシーと位置情報です。レイテンシーは速さ、位置情報は所在地で決まります。「フランスからの利用者にはフランス語サイトを見せる」は速さの話ではないので位置情報、「利用者に最も速く応答するリージョンへ」は所在地の話ではないのでレイテンシーです。要件文が速度を語っているか、国や地域そのものを語っているかで切り分けます。

ヘルスチェックの使い分け

ヘルスチェックは3種類あり、これも問われます。

フェイルオーバー以外のポリシーにもヘルスチェックは付けられます。加重やレイテンシーのレコードに付けておくと、異常な宛先が候補から外れます。「片方のリージョンが落ちたときに、そちらへは振らないでほしい」という要件はこれで満たします。

よくある引っ掛け

1つめは、可用性の要件に加重ルーティングで答えてしまうものです。加重は比率で配る仕組みなので、ヘルスチェックを付けない限り異常な宛先にも配り続けます。障害時の切り替えが主目的ならフェイルオーバーです。

2つめは、DNS の切り替えだけで復旧時間をゼロにできると読んでしまうものです。DNS の応答にはレコードの TTL に応じたキャッシュが効くため、切り替えが利用者に行き渡るまでに時間差が生じます。「切り替え時間を短くしたい」という要件が付いたら TTL を小さくしておく設計が絡みます。TCP や UDP のレベルで即座に経路を切り替えたい要件なら、DNS ではなく次のレッスンで扱う Global Accelerator が候補になります。

3つめは、位置情報ルーティングを「利用者に近いリージョンへ送って速くする」ための答えにしてしまうものです。近さと速さは一致しないことがあるため、速度の要件にはレイテンシーを当てます。

まとめ

• 障害時の切り替えはフェイルオーバー。プライマリにヘルスチェックを付けて初めて機能します
• 比率で配るのは加重。段階移行やカナリアの要件語で出ます
• 速さの要件はレイテンシー、所在地の要件は位置情報です
• ヘルスチェックはエンドポイント、CloudWatch アラーム、計算型の3種類を使い分けます
• DNS の切り替えは TTL のキャッシュ分だけ遅れます。即時性が要件なら DNS 以外も検討します