Amazon Route 53とDNSのシナリオ判断

名前解決の設定を変える事例から、要件に合う公開範囲とルーティング方針を選びます。名前が解決できること、接続できること、業務が成功することを段階に分けて考えます。

この単元で学ぶこと

  • 要件に合うDNSレコードと公開範囲を選ぶ
  • 切替えや割合の条件を正しく解釈する
  • 名前解決と他の障害を切り分ける

本文解説

1. 新しい公開サイトの準備 example.comを取得しただけでは、Webサーバーへのレコードや配備は完成していません。登録、権威DNSの委任先、ゾーン内の回答、Webの受信設定を順に確認します。名前の登録を完了した報告と、利用者がWebを閲覧できる検証結果を分けます。

2. 内部名を使う場合 社内アプリからdb.example.comで内部DBを参照するなら、関連VPCのプライベートホストゾーンを検討します。別VPCから同じ名前を使うには関連付けやDNS設定を確認します。名前の解決成功はVPC間のルートやDBの認可を付与するものではありません。

3. 頂点の宛先を指定する example.comというゾーン頂点をALBへ向ける場合、対応Aliasを利用する選択肢があります。www.example.comのCNAMEを作れた経験から頂点も同じと判断しないことが重要です。DNSが返すアドレスとWeb側のホスト名・証明書の整合も別に確認します。

4. 新版へ段階的に誘導 同じ名前の応答先を旧版80、新版20の重みで構成すれば、重み合計100に対し新版の選択割合は20%です。ただしこれは各HTTP要求を厳密に五つのうち一つへ振る保証ではありません。リゾルバーのキャッシュや利用者数により実測のHTTP件数比率は異なり得ます。

5. 遅延と所在地を分ける 複数リージョンの応答時間を改善したいならLatency routingを比較します。利用者の国や地域により提供する内容を切り替えるならGeolocationを検討します。地理的に近いことと測定・推定される低遅延は同じ意味ではなく、要件の言葉を読み分けます。

6. 稼働系が使えないとき Failoverで待機系を返すには、対象のヘルス状態をどう評価するかを設計します。DNSが待機系を返せても、その側のアプリ、データ、容量が不足すれば業務は復旧しません。DNSの切替え機能とシステム全体の復旧目標を同一視しないようにします。

7. TTLの残りを考える 古い応答を300秒のTTLで受け取って120秒経過した直後にレコードを変えたとします。そのキャッシュをTTLどおり保持する単純な前提なら残り180秒です。新しいTTLへ変更したからといって、すでに配られた古いキャッシュの残り時間が直ちに書き換わるわけではありません。

8. 原因の層を特定する 名前が解決しなければ、利用するゾーン、レコード、委任やResolverの条件を調べます。IPは取得できるのに通信できなければ経路やファイアウォール、Webが認可エラーならアプリの権限を調べます。DNS設定を何度も変える前に、どの段階まで成功したかを記録します。

図解

サイト変更で別々に確かめる条件
レコードの保存成功だけで全利用者の切替え完了とは判断しません。

重要ポイント

  • 比率はDNSの応答選択でありHTTP件数の厳密保証ではない。
  • 新TTLは既存キャッシュの残りを即時に書き換えない。
  • 名前解決・接続・認可を分けて調査する。

間違えやすい点

  • 内部名が解決できればDBへ接続・更新できると判断する。
  • 切替先のデータや容量をDNS任せにする。

用語解説

委任
対象ドメインの名前解決を担当するネームサーバーを示す仕組み。
重み
複数の応答先を選ぶ相対的な割合を指定する値。
待機系
障害時等に処理を引き継ぐため準備するシステム。

関連教材

参考資料

教材データに登録された参考リンクです。リンク先の内容や更新日は提供元でご確認ください。

確認問題の出題・採点や学習履歴の保存にはログインが必要です。