はじめに
この記事はDevOps on AWS大全の一部です。
DevOps on AWS大全の一覧はこちら。
この記事ではAmazon Route53を耐障害性の観点から超詳細解説しています。
具体的には以下流れで説明します。
- Amazon Route53とは
- 耐障害性を考慮したルーティング
AWSの区分でいう「Level 200：トピックの入門知識を持っていることを前提に、ベストプラクティス、サービス機能を解説するレベル」の内容です。
この記事を読んでほしい人
- Amazon Route53を採用するときのベストプラクティスを説明できるようになりたい人
- Amazon Route53の耐障害性に不安を感じている人
- AWS Certified DevOps Engineer Professionalを目指している人
Amazon Route53とは
Amazon Route53とは高可用、スケーラブル、そして完全マネージド型の権威DNSサーバです。
また、Route53は権威DNSサーバであると同時にドメインレジスターでもあります。
Route53を理解するためには、Record、Hosted Zone、Routing Policyの3つを理解する必要があります。
Record
Route 53の基本的な構成要素はRecordです。
これは、ドメインに関連付けられた各リソースのエントリーで、主にドメイン名をIPアドレスに対応付けます。
Recordの中にはDomain/subdomain Name、Record Type、Value、Routing Policy、TTLという5つの設定項目があります。
Domain/subdomain Nameはドメイン名、ValueはIPアドレス、TTLはDNSリゾルバでのキャッシュ期間です。
Routing Policyは耐障害性を考慮したルーティングのところで詳しく説明します。
Record Typeの主なものには以下があります。
| レコード名 | 説明 |
|---|---|
| A | ドメイン名をIPv4アドレスに解決 |
| AAAA | ドメイン名をIPv6アドレスに解決 |
| CNAME | 別のドメイン名にエイリアスを設定 |
ほかにもMXやTXTなどのレコードがありますがDNSの項目になるのでここでの説明は割愛します。
Hosted Zone
Route 53では、ドメインを管理する単位としてHosted Zoneがあります。
これは特定のドメインに関連するDNSレコードの集合体で、各Hosted Zoneには一意の名前が付与されます。
Hosted Zone内でレコードセットを設定することで、ドメインの挙動や解決ルールを定義できます。
例えば、www.example.com をどのIPアドレスに解決するかなどがホステッドゾーンで設定されます。
Hosted ZoneにはPublicとPrivateが存在し、インターネットからつなぐ場合にはPublicをVPC内部での通信に閉じる場合にはPrivateを利用します。
なお、PublicとPrivateで同じドメインを登録するとインターネットからのアクセスにはPublic Hosted Zoneが応答し、VPCからのアクセスにはPrivate Hosted Zoneが応答します。
あまりないとは思いますが、どうしても内部で通信をひねりたいがクロスドメインにしたくないというときには活用できる仕組みです。
耐障害性を考慮したルーティング
Route53はAWSのサービス内で唯一SLAが100%のサービスです。
そのため、Route53自体の耐障害性を考える必要はありません。
Route53の耐障害性で考える必要があるのはルーティング先のサービスまで含めて可能な限りダウンタイムを短くする、というパターンです。
そのために使うRoute53の機能がRouting Policyです。
代表的なRouting Policyごとの説明を以下にまとめます。
Simple Routing Policy
単一のリソースにトラフィックを転送します。主に単一のエンドポイントを持つシンプルな用途に適しています。
Weighted Routing Policy
複数のリソースに対して異なる重みを設定し、トラフィックを分散させることができます。例えば、新しいバージョンのアプリケーションに一部のトラフィックを導入する場合に有用です。
Latency-Based Routing Policy
クライアントの地理的位置に応じてトラフィックを最も低いレイテンシを持つエンドポイントに導くことができます。グローバルに展開されたアプリケーションで効果的です。
Failover Routing Policy
プライマリとセカンダリの2つのリソースを設定し、プライマリが利用できない場合にセカンダリにトラフィックを自動的にフェイルオーバーさせます。
トラフィックフロー
耐障害性という観点でRouting Policyを見るとFailover Routing Policyが最も優れています。
ただ、実際の運用を考えるとFailover Routing Policyだけで運用するというのはあまり現実的ではありません。
例えば、リリース作業を考えるとトラフィック分割のためにWeighted Routing Policyも使いたいという場面は多いでしょう。
そのため、トラフィックフローを用いたRouting Policyの組み合わせがRouting Policyのベストプラクティスです。
トラフィックフローとは複雑なルーティングのサポートをしてくれるサービスです。
具体的には複数のRouting Policyを組み合わせて使用する場合に発生するレコード設定の複雑な階層構造管理をできるようにしてくれます。
このサービスを利用するとWeighted Routing Policyでトラフィック分割しながらリリースできる仕組みを作りつつ、バックエンドがダウンした時に備えたFailover Routing PolicyでSorry画面に自動で向くようにする、といったことが可能になります。
まとめ
この記事ではAmazon Route53を耐障害性の観点から超詳細解説しました。
- Amazon Route53とは
- 耐障害性を考慮したルーティング
次回はRDSの耐障害性を考えます。