Webサイトやアプリケーションを運用していると、「ドメイン名でアクセスできるようにしたい」「サーバーが落ちたら自動で別のサーバーに切り替えたい」「特定の地域のユーザーを近いサーバーに振り分けたい」といった要件が出てきます。こうした要件をまとめて解決するのが「Amazon Route 53」です。今回は、Route 53の基本的な仕組みから、DNSクエリの流れ、ルーティングポリシーの使い分け、フェイルオーバーの設定、オンプレミスとの連携まで、初心者にも分かりやすく解説します。
そもそもDNSとは何か
Route 53を理解する前に、まず「DNS」という仕組みを押さえておく必要があります。
DNSは「Domain Name System」の略で、ドメイン名(example.comなど)をIPアドレス(192.168.1.1など)に変換する仕組みです。コンピュータ同士の通信はIPアドレスで行われますが、人間がIPアドレスを覚えるのは大変です。そこでDNSが「名前とIPアドレスの対応表」として機能し、人間にとって分かりやすいドメイン名で通信できるようにしています。
身近な例で言うと、スマホの電話帳に近いイメージです。「山田さん」という名前で電話をかけると、電話帳が「山田さん=090-XXXX-XXXX」という対応を教えてくれて、実際にその番号に電話がかかります。DNSも同様に「example.com=203.0.113.1」という対応を教えてくれて、そのIPアドレスに通信が届きます。
DNSクエリの流れ
ブラウザでURLを入力してからWebサイトが表示されるまでの流れを、DNSの観点から整理してみます。
ユーザーがブラウザに「example.com」と入力
↓
①ブラウザがOSに「example.comのIPアドレスを教えて」と聞く
↓
②OSがキャッシュを確認(以前調べた結果が残っていれば即返答)
↓
③キャッシュがなければリゾルバ(プロバイダのDNSサーバー)に問い合わせ
↓
④リゾルバがルートDNSサーバーに「.comのDNSサーバーはどこ?」と聞く
↓
⑤ルートDNSが「.comはこのサーバーが担当」と教える
↓
⑥リゾルバが.comのDNSサーバーに「example.comはどこ?」と聞く
↓
⑦「example.comはRoute 53が担当」と教えられる
↓
⑧リゾルバがRoute 53に「example.comのIPアドレスは?」と聞く
↓
⑨Route 53が「203.0.113.1です」と返答
↓
⑩ブラウザが203.0.113.1にアクセスしてWebサイトが表示されるこの一連の流れが、ブラウザにURLを入力してから数ミリ秒以内に完了しています。Route 53はこの流れの⑧〜⑨の部分、つまり「ドメイン名に対してどのIPアドレスを返すか」を管理するサービスです。
TTL(Time To Live)とは
DNSの仕組みで重要な概念が「TTL」です。TTLは「この回答を何秒間キャッシュしていいか」という有効期限のことです。
たとえばTTLを300秒(5分)に設定すると、一度問い合わせた結果を5分間キャッシュし、5分間は再びDNSに問い合わせません。TTLを短くすると変更がすぐに反映されますがDNSへの問い合わせ回数が増え、TTLを長くするとキャッシュが効いてDNSへの負荷が減りますが変更の反映が遅くなります。
サーバーの切り替えなど変更が発生する予定がある場合は、事前にTTLを短く(60秒など)しておくと、切り替え後の反映を素早くできます。
Amazon Route 53とは
Amazon Route 53は、AWSが提供するDNSサービスです。「Route 53」という名前は、DNSが使用するポート番号「53」に由来しています。
Route 53が提供する機能は大きく3つです。
ドメイン登録として、example.comのようなドメイン名をRoute 53から直接購入・管理できます。
DNSルーティングとして、ドメイン名に対してどのIPアドレスやAWSリソースを返すかを設定できます。
ヘルスチェックとして、サーバーの死活監視を行い、異常を検知した場合に自動で別のサーバーに切り替えるフェイルオーバーを実現できます。
Route 53のレコードタイプ
Route 53では、様々な種類のDNSレコードを設定できます。代表的なものを整理します。
Aレコードはドメイン名をIPv4アドレスに対応付けるレコードです。最も基本的なレコードで、「example.com → 203.0.113.1」のような設定をします。
CNAMEレコードはドメイン名を別のドメイン名に対応付けるレコードです。「www.example.com → example.com」のように、エイリアス(別名)を設定する場合に使います。ただしCNAMEはルートドメイン(example.com)には使用できないという制限があります。
AliasレコードはRoute 53独自のレコードタイプで、AWSリソース(ALB・CloudFront・S3など)のDNS名に対応付けるために使います。CNAMEと似ていますが、ルートドメインにも使えます。ALBのDNS名はIPアドレスが変わる可能性があるため、Aレコードではなく基本的にAliasレコードを使います。
MXレコードはメールサーバーを指定するレコードです。「このドメイン宛のメールはこのサーバーに届けてください」という設定をします。
ルーティングポリシーの種類と使い分け
Route 53の強力な機能の一つが「ルーティングポリシー」です。同じドメイン名でも、条件によって異なるIPアドレスを返すことができます。
シンプルルーティング
最も基本的なルーティングです。1つのドメイン名に1つ(または複数)のIPアドレスを設定します。複数のIPアドレスを設定した場合はランダムに返します。ヘルスチェックとは組み合わせられないため、小規模なシステムや検証環境向けです。
加重ルーティング(Weighted)
複数のサーバーに対して「重み」を設定し、その比率でトラフィックを振り分けます。たとえば旧バージョンのサーバーに重み90・新バージョンのサーバーに重み10を設定すると、10%のトラフィックだけ新バージョンに流せます。新機能のカナリアリリース(段階的リリース)に非常に有効なポリシーです。
example.com へのアクセス
90% → 旧バージョンのサーバー(重み90)
10% → 新バージョンのサーバー(重み10)レイテンシーベースルーティング(Latency)
ユーザーから各サーバーへのレイテンシー(応答速度)を測定し、最も速く応答できるリージョンのサーバーに振り分けます。グローバルにサービスを展開していて「ユーザーに最も近いサーバーから配信したい」という場合に使います。
地理的ルーティング(Geolocation)
ユーザーの地理的な位置(国・大陸)に基づいてルーティング先を決めます。「日本からのアクセスは東京リージョンへ」「ヨーロッパからのアクセスはフランクフルトリージョンへ」のように、地域ごとに異なるサーバーに振り分けられます。コンテンツの言語対応や法的規制(データを特定の国内にのみ保管しなければならない要件)がある場合に有効です。
フェイルオーバールーティング(Failover)
プライマリ(主系)とセカンダリ(副系)のサーバーを設定し、プライマリが正常な間はプライマリに、障害が発生した場合は自動的にセカンダリに切り替えるポリシーです。ヘルスチェックと組み合わせて使います。
通常時:example.com → プライマリサーバー(東京)
障害時:example.com → セカンダリサーバー(大阪) ← 自動切替複数値回答ルーティング(Multivalue Answer)
複数のIPアドレスをランダムに返すポリシーで、ヘルスチェックと組み合わせることができます。シンプルルーティングとの違いは、ヘルスチェックで異常なサーバーを自動的に除外できる点です。ただし本格的なロードバランサーの代替にはならないため、簡易的な負荷分散として使います。
フェイルオーバーの仕組み
Route 53のフェイルオーバーは、ヘルスチェックと組み合わせることで実現します。ヘルスチェックとは、Route 53が定期的にサーバーにHTTPリクエストやTCP接続を試みて、サーバーが正常に応答しているかを確認する機能です。
フェイルオーバーの流れは以下の通りです。
Route 53がプライマリサーバーに定期的にヘルスチェック
↓
プライマリサーバーが応答しない(障害発生)
↓
Route 53がヘルスチェック失敗を検知
↓
DNSの返答をセカンダリサーバーのIPアドレスに自動切替
↓
ユーザーは意識せずセカンダリサーバーにアクセスヘルスチェックの間隔はデフォルトで30秒です。10秒間隔の「高速ヘルスチェック」も設定できますが、追加コストが発生します。フェイルオーバーの切り替え速度は「ヘルスチェックの失敗回数×間隔」で決まるため、より早い切り替えが必要な場合は高速ヘルスチェックを使います。
オンプレミスとの連携
Route 53はAWS上のリソースだけでなく、オンプレミス(自社データセンター)との連携にも使えます。これを実現するのが「Route 53 Resolver」です。
Route 53 Resolverは、VPCとオンプレミスの間でDNSクエリを相互に解決するための仕組みです。
インバウンドエンドポイントは、オンプレミスのサーバーがAWS VPC内のリソース(EC2やRDSなど)の名前解決をしたい場合に使います。オンプレミスのDNSサーバーからVPC内のエンドポイントに問い合わせることで、VPC内のプライベートDNS名を解決できます。
アウトバウンドエンドポイントは、VPC内のEC2インスタンスがオンプレミスのサーバーの名前解決をしたい場合に使います。VPCからオンプレミスのDNSサーバーに転送ルールを設定することで、オンプレミスのホスト名を解決できます。
オンプレミス環境 AWS環境(VPC)
社内サーバー → インバウンドエンドポイント → EC2/RDS
(オンプレ→AWSの名前解決)
EC2 → アウトバウンドエンドポイント → 社内DNSサーバー
(AWS→オンプレの名前解決)この仕組みはDirect ConnectやVPN経由でAWSとオンプレミスを接続している企業でよく使われます。「ハイブリッドクラウド環境でのDNS統合」というテーマでAWSの試験にもよく出てくる内容です。
プライベートホストゾーン
Route 53には「パブリックホストゾーン」と「プライベートホストゾーン」の2種類があります。
パブリックホストゾーンはインターネット上のドメイン名を管理するもので、世界中からアクセス可能です。
プライベートホストゾーンはVPC内だけで有効なDNS設定です。たとえば「db.internal」のような内部専用のドメイン名を設定して、VPC内のEC2インスタンスだけがそのドメイン名でRDSに接続できるようにするといった使い方をします。インターネットからはアクセスできないため、内部サービスのエンドポイントを管理するのに適しています。
まとめ
Amazon Route 53は、単なるDNSサービスにとどまらず、ルーティングポリシーによるトラフィック制御、ヘルスチェックによる自動フェイルオーバー、オンプレミスとのDNS統合まで、幅広い機能を持つサービスです。シンプルルーティングから始まり、加重ルーティングでカナリアリリース、フェイルオーバーで高可用性を実現、レイテンシーベースでグローバル配信の最適化と、システムの要件に合わせて使い分けられるのがRoute 53の強みです。DNSという普段意識しにくい仕組みを理解しておくことは、クラウドエンジニアとしてインフラ設計の幅を広げる上で非常に重要な知識になります。
コメント