前回の記事では、DNSの基礎について学びました。
本記事では、前回学んだDNSを使って、ユーザーをCDNにルーティングする方法について解説します。
まずは、第3回で解説したブラウザがWebサイトに接続するまでのプロセスを再確認し、DNSがどこで使われているか見ていきます。
ブラウザがWebサイトに接続するまでのプロセス(復習)
このうちDNSに関連するのは、下記の2箇所です。
- 1. ブラウザは、DNSで www.bloomblock.net を名前解決
- 5. エッジサーバーは、DNSでオリジンサーバーのドメイン名 origin.bloomblock.net を名前解決
「5. オリジンサーバーの名前解決」は通常のAレコードの名前解決ですので、前回学んだことと変わりません。
本記事の主題であるCNAMEレコードでのルーティングは「1. www.bloomblock.net の名前解決」で行われます。
これは、次の2ステップで行われます。
- www.bloomblock.net への問い合わせでCNAMEレコードを受け取る
- CNAMEレコードで示されている abc.cloudfront.net のAレコードを受け取る
CNAMEレコードについて
CNAMEレコードについては第3回で簡単に説明しましたが、ここで詳しく解説します。
DNSのCNAMEレコード（Canonical Name Record）は、あるドメイン名（エイリアス）を別のドメイン名（正規名）にマッピングするために使用されるタイプのリソースレコードです。これにより、複数のドメイン名が単一のドメイン名に関連付けられます。
CNAMEレコードを受けとったユーザーは、別のドメイン名（正規名）について、再度DNS問い合わせを行います。
これだと何が嬉しいのか分からないと思いますが、CDN導入時にはCNAMEレコードが役立ちます。
CNAMEレコードを利用することでCDN事業者が管理しているエッジサーバーのIPアドレスにマッピングすることができるからです。
エッジサーバーのIPアドレスは、CDN事業者が管理しているため、利用者であるWebサイト運営者は正確には分かりません。
そのため、CNAMEレコードを使って、CDNのドメイン名を名前解決するようにユーザーに促し、実際のIPアドレスはCDN事業者が管理するDNSサーバーから受け取ります。
これを図にすると下記のようになります。
CNAMEレコード以外の選択肢
CDNを導入する時、CNAMEレコードを利用することは最も一般的な方法です。
しかしながら、次の2つの欠点があります。
- DNSサーバーへの問い合わせが2回実行されるため遅延が大きくなる
- Zone Apex(“bloomblock.net”など)のドメイン名にはCNAMEレコードを作れない
これらの欠点を解決するための方法が、各CDN事業者から提供されています。
詳しくは別記事にまとめていますので、興味がある方はこちらをご覧ください。
最適なエッジサーバーの選択
ここまで、DNSに問い合わせを行い、ユーザーがエッジサーバーに接続する流れを見てきました。では、ユーザーがエッジサーバーに接続にする時、どのようにしてユーザーにとって最適なエッジサーバーが選ばれるのでしょうか？
CDNを導入する主なメリットの1つに「レスポンスの高速化」がありましたが、これはエッジサーバーがユーザーに近いことによるメリットです。ユーザーから遠いエッジサーバーが選ばれてしまうと、CDN導入はデメリットになってしまいます。
この答えは、最適なエッジサーバーのIPアドレスをCDN事業者のDNSが返却する です。
CDN事業者のDNSサーバーが、問い合わせ元のキャッシュDNSサーバーのIPアドレスを確認し、CDN事業者が持つ地理情報データベースなどから最適なエッジサーバーを選択し、そのIPアドレスを返します。
また、CDN事業者によっては追加の情報を使って最適なエッジサーバーを選択しています。
例えば、Amazon CloudFrontでは、地理情報に加えて、ユーザーとエッジサーバーとのTCPコネクション確立にかかった時間を計測したテーブル、エッジサーバーのパフォーマンスや負荷情報から総合的に判断しています。
関連記事: Using multiple content delivery networks for video streaming – part 1
CDNを導入する時の流れ
それでは、CNAMEでユーザーをルーティングする方法が分かったので、CDNを導入する時の流れを見ていきましょう。
前提は下記の通りです。
www.bloomblock.netにはAレコードが登録されており、オリジンサーバーのIPアドレス(1.2.3.4)に解決される- AレコードのTTLは1時間(3600)
- オリジンサーバーのIPアドレスは1.2.3.4
この状態を図示すると下記のようになります。
TTLは、前回記事で解説した通り、キャッシュDNSサーバーに名前解決の結果がキャッシュされる時間です。 3600が指定されている場合、1時間はwww.blooomblock.netに対する問い合わせは権威サーバーに問い合わせることなく、キャッシュDNSサーバーが応答します。
CDN導入時の作業の全体像は次の通りです。
- オリジンサーバーの設定を更新
- オリジンサーバー用のAレコードを追加
- CDNの設定を完了し、展開
- AレコードのTTLを短くする
- Aレコードを削除し、CNAMEレコードを追加
- CNAMEレコードのTTLを伸ばす
- (オプション) CDN経由以外のアクセスを拒否する設定をオリジンサーバーに追加
それでは、各ステップの作業の意味を見ていきましょう。
1. オリジンサーバーの設定を更新
オリジンサーバーの設定を更新し、CDNからのリクエストを受け取れるようにします。
というのは、これまでオリジンサーバーは、www.bloomblock.netというホスト名が対象のリクエストを受け取っていましたが、エッジサーバーを経由した時は、origin.bloomblock.netにホスト名が変化します。
そのため、この時点では、両方のホスト名に対するリクエストを受け取れるようにオリジンサーバーの設定をする必要があります。
この設定は、名前ベースのVirtualHostと呼ばれる機能で実現されており、ApacheやNginxの設定を変更することで設定可能です。名前ベースのVirtualHostが使われていなければ設定変更は不要です。
2. オリジンサーバー用のAレコードを追加する
エッジサーバーがオリジンサーバー用のAレコードを追加します。
Aレコードの内容は、ユーザーがアクセスしているものと同じでドメイン名のみ変更します。
この状態を図示すると下記のようになります。
3. CDNの設定を完了し、展開
ユーザーが接続してくる前にCDNの設定と展開を終わらせておきます。
この時点では、ユーザーはCDNに接続してこないので、安心してCDNの設定の検証をすることができます。
ユーザーはCDNにこの時点では接続しないと述べましたが、開発者はどうやってCDNの設定の検証をするのでしょうか？
答えは、「開発者のマシンだけCDNに接続するように hosts ファイルを書き換える」です。
hosts ファイルは、ローカルで名前解決をするために使われるファイルです。OSは、hostsファイルを最初に参照し、該当するドメイン名がなければDNSサーバーに問い合わせるという挙動をします。
そのため、開発者のマシンのhosts ファイルに下記のような設定を追加することで、DNSサーバーに問い合わせることなく、エッジサーバーに接続できます。下記は hosts ファイルのサンプルです。13.32.50.25はエッジサーバーのIPアドレスです。
# hostsファイルの設定
A.B.C.D www.bloomblock.nethosts ファイルは、Mac/Linuxは/etc/hosts、Windowsでは、C:\Windows\System32\drivers\etc\hostsに置かれています。
エッジサーバーのIPアドレスは、CDNのドメイン名abc.cloudfront.netを名前解決することで取得できます。
この状態を図にすると下記のようになります。
4. AレコードのTTLを短くする
www.bloomblock.netのAレコードのTTLを短くします。
これは、次のアクションでAレコードを削除し、CNAMEレコードを追加した際にすぐにユーザーがエッジサーバー経由でアクセスしてくるようにするためです。
あまりに短いとDNSサーバーへのリクエスト数が増え、負荷が増大することになるので、TTLは300(5分)に設定することを推奨します。負荷を気にしなくてよいクラウドのDNSサーバーであっても、リクエスト数に応じてコストが増大するのが一般的です。
この状態を図にすると下記のようになります。
5. Aレコードを削除し、CNAMEレコードを追加
この作業を実施後にユーザーはエッジサーバー経由で接続してくるようになります。
そのため、この作業の後はCDNやオリジンサーバーのログを監視し、多数のエラーレスポンスが発生していないかなど確認します。
また、CNAMEレコードのTTLも300と短くしておきます。これは、想定外のエラーが増大した場合にすぐに切り戻しをするためです。
切り戻しは、この作業を行う前の状態に戻すために、CNAMEレコードを削除し、Aレコードを追加します。最大5分待てば、全ユーザーがオリジンサーバーに直接繋ぐようになります。
切り戻した後に落ち着いてトラブルシューティングを行いましょう。
この状態を図にすると下記のようになります。
6. CNAMEレコードのTTLを伸ばす
CDN導入後に問題がないことを確認できたら、DNSサーバーの負荷とコストを削減するためにCNAMEレコードのTTLを長くしましょう。
7. (オプション) CDN経由以外のアクセスを拒否する設定をオリジンサーバーに追加
この作業はオプションですが、エッジサーバーからのリクエスト以外を拒否する設定をオリジンサーバー側で追加することでセキュリティの向上と負荷削減ができます。
というのは、CDN導入後もオリジンサーバーはインターネットからアクセス可能であるため、オリジンサーバーのIPアドレスを知っているユーザーは直接オリジンサーバーに接続できるからです。
直接オリジンサーバーにアクセスされるとキャッシュが使えないですし、WAFをCDNに導入していても意味がありません。一般的なユーザーはこのようなことはしないため、悪意を持っているユーザーの可能性が高いです。
そのため、まず第一に、オリジンサーバーのIPアドレスを知られないようにする、第二にオリジンサーバーに直接アクセスされても拒否するようにすることでセキュリティを向上させます。
オリジンサーバーに直接アクセスされても拒否する設定方法はいくつかあります。エッジサーバーのIPアドレス以外のアクセスを拒否する、エッジサーバーで特定のHTTPヘッダーを付与し、そのヘッダーがついていなかったり値が違ったらアクセスを拒否するといった複数パターンでの設定方法があります。
どの方法が良いかは、使用するCDNとオリジンサーバーの組み合わせで決まりますので、一度調査してみてください。
まとめ
本記事では、DNSを使ってユーザーをCDNにルーティングする方法を学びました。
前回から連続してDNSについて取り上げましたが、その奥深さに驚いた方もおられるのではないかと思います。最初は取っ付きにくい部分もあるかと思いますが、本記事を見ながら実際にdigコマンドで名前解決をしてみるなど、手を動かすことでより理解が進むのではないかと思います。
次回はCDNの要素技術であるHTTPについて解説します。
ここまでの記事で、ユーザーはエッジサーバーのIPアドレスを知り、接続できるようになりました。次からはエッジサーバーに接続した後の動作について解説していきます。
CDN入門記事の一覧ページはこちらです。
