Ch2. CDNとDNS - Pyons Tech Blog

Content Delivery Network

AWS Cloud Frontでは世界中に存在するAWSのローケーションを利用してCDNを構築することが出来る。

コンテンツの格納にはバックエンドサーバ（オリジンサーバ）が必要になるが、そのオリジンサーバとして

が利用できる。そのため、コンテンツの格納はオンプレで行い、CDNだけCloud Frontに任せてホスティングの負荷を下げる、と言った運用が可能になる。

また、URLのパスに応じて異なるオリジンサーバを指定することも出来る。

CDNとして配信できるのはHTML/CSSや画像などを扱う【ダウンロードディストリビューション】と動画ストリーミングを実施する【ストリーミングディストリビューション】が存在する。

ファイルの拡張子やURLごとにキャッシュ期間を変更することが出来る。

またキャッシュ期間を0に設定して、常にオリジンサーバからコンテンツを取得するような設定も可能。

ドメイン管理と権威DNSの役割がセットになった「AWS Route53」というサービスが存在する。

ドメイン管理はシンプルに【pyons04.work】のようなドメインを発行・管理してくれるサービスで、AWSから発行してAWSアカウントの料金として維持費用の支払いが出来る(お名前.comとかと同じ)。

一部、他で発行したドメインをRoute53での移管に変更することも出来るようだが、少なくともトップレベルドメインが【.work】だとAWSでは管理できないようだった(.jpとかはOK)。

まずキャッシュDNSではないので、自分の担当のドメイン名以外に対するIPアドレスの返答は出来ない点に注意する。例えば【.work】のアドレス解決のリクエストが来てもRoute53でレスポンスを行うことは無い。

ドメイン名から権威DNSに対して名前解決を依頼するのが【キャッシュDNS】である(8.8.8.8などが有名)。 Google Public DNS - Wikipedia

【ホストゾーン】とはRoute53で応答させたいサイトの「ドメイン名」のことを指す。

「test.co.jpという名前解決リクエストに対して206.12.12.15というアドレスを返却する」という組み合わせのことを「レコード情報」と呼んでいる。

レコード情報には様々な種類があるが、どれもIPアドレスを直接指定する必要がない。

レコード種類	説明	例
A	IPv4アドレス、またはAWSのホストを指定できる	pyons04.work -> myLB-1234567890.us-east-1.elb.amazonaws.com (-> 140.23.21.34)
CNAME	別のドメイン名、またはAWSのホストを指定できる	pyons04.work -> (pyons05.work -> 140.23.21.34)
Alias	AやCNAMEで直接AWSのホストを指定した場合でもクエリの応答を一回で済ませる	pyons04.work -> myLB-1234567890.us-east-1.elb.amazonaws.com (ABCDEFGHI12345) (-> 140.23.21.34)

レコードにAWSのホストを指定した場合、AWSのホストを更に名前解決してIPアドレスを返却することになる。これはAWSホストの(Public)IPアドレスは動的に変化する恐れがあるため、致し方ない。

しかし、Aliasレコードに対してAWSホストのFQDNを指定することで、レコードとAWSホストのIPアドレスを1対1で紐付けることが出来る上、AWSホストのIPアドレスが変更されるたびにレコードが自動更新される。そのため、DNSリクエストの解決が一回で済む。

Zoned Apexとはサブドメイン(wwwとか)を含まないドメイン名のことで、Naked Domeinとも呼ばれる。

昔はomosan.shibuya@aoyama.jpのようにメールサーバに利用されることが多かったが、今ではWEBのURLでも利用される(amazon.comとか)。

Zoned ApexはRFCの仕様上、CNAMEの登録が出来ない(他のドメインに更にルーティングさせることが出来ない)。しかし、AWSのRoute53を権威DNAサーバとして利用した場合、先述したAliasを利用してそれが可能になる。

（どうやって実現しているのかイマイチ理解していなので後で調べてみる。）

ルーティングポリシーには以下のようなものが使える。 CCNAで学習したDNS ラウンドロビンの延長だが、更に細かいプリファレンスが行える。

ルーティングポリシー	説明
シンプル	1対1のルーティングポリシー
フェイルオーバー	アクティブ/スタンバイ構成で2つのレコードを登録しておく。スタンバイへの切り替えはヘルスチェックによって行われる
位置情報	アクセスのあった地域に応じて、異なるレスポンスを返却出来る。
地理的近接性	位置情報と近しいと思われる(※2021.05.23現在 AWS Consoleには該当のポリシーが存在しない)。
レイテンシー	遅延がもっとも少ないサーバーをレスポンスする。
複数値回答	ランダムにレスポンスする。但し、ヘルスチェックでNGになると対象から自動的に外される。
加重	指定した比率でリクエストを分散させる。新しい機能を実装したのでn%の人から反応を見たい、と言ったA/Bテストに利用できる。

ルーティングポリシーにもあった「フェイルオーバールーティングポリシー」はFault Tolerant Architectureの中核をなすものである。フェイルしたことを確認するヘルスチェックの仕方は3種類存在する。