実際にCDNを使ってみよう！DNS設定からキャッシュ配信まで一連の設定をご紹介〜Web制作/運営の幅が広がるCDNを知ろう第5回〜
CDN(Content Delivery Network)のメリットや活用のポイントをお届けしている本連載、連載第5回の今回は、今までご紹介してきたCDNを実際に利用する手順をご紹介していきます。今回は、さくらのCDNウェブアクセラレータを例にご紹介していきますが、一般的なCDNでも似たような流れとなります。ウェブアクセラレータは設定項目がシンプルになっており初心者の方でも比較的利用しやすいCDNです。
なお、設定方法の詳細はウェブアクセラレータ独自ドメイン利用設定マニュアルに記載されております。この記事ではざっくりした流れと注意ポイントをご紹介していきますので、詳しい設定方法はマニュアルをご覧ください。
非常に大切な事前準備
第1回でCDNの設定にはDNSの設定変更が不可欠とご紹介しました。今回、既存のサイト www.example.com をCDN配信に変更するという想定で設定方法をご紹介するにあたり、まずは事前準備から説明していきたいと思います。
CDN側のセットアップ
CDN利用時にはもちろん、CDN側での設定が必要になります。オリジンサーバのアドレスを指定するのは必須ですが、その他にもオリジン間通信のhttp/httpsを選んだり、利用するHTTPメソッドを選んだりできるCDNもあります。さくらのCDNウェブアクセラレータはシンプルな設定項目のみ利用できますので、オリジンサーバのアドレスとhttp/httpsの選択、httpsを利用する場合は証明書と秘密鍵のアップロードぐらいで設定が完了します。なお、設定を有効化する際にドメイン所有確認のためTXTレコードの編集が必要になります。
さくらのクラウドDNSでのリソースレコード編集画面
DNS設定変更
よくDNS（権威DNSサーバ）の設定変更をした後、「浸透待ち」という言葉が使用されますがこれは誤りです。世間一般に権威DNSサーバの設定変更は終わった後の浸透に数日〜1週間もかかると誤った認識がされていますが、実際のDNSサーバの挙動はリソースレコード毎にTTL（Time To Live）というキャッシュ時間が設定されており、キャッシュDNSサーバはこのTTL時間分リソースレコード設定値をキャッシュし、TTLが切れたら権威DNSサーバへ再度設定値を取得しに行きます。つまりTTLを短くした状態で設定値を書き換えることでキャッシュがクリアされるまでにかかる時間（誤って浸透と呼ばれる事象にかかる期間）を最小限にできることになります。つまり「浸透をあてもなく待つ」という行為ではなく、「キャッシュが切れて設定が反映されるまで待つ」という言い方が正しいわけです。これを頭に入れておいた上で設定変更を進めていきましょう。
普通に運用されているサイトであれば、DNSサーバにはAレコードが設定されIPアドレスが記載されていると思います。digコマンドを利用すると一発で出てきますね。
$ dig www.example.com a ＜前略＞ ;; ANSWER SECTION: www.example.com. 3600 IN A （IPアドレス） ＜後略＞
これは、 www.example.com のTTLは3600秒で、このドメインへのリクエストは指定されたIPアドレスのサーバへ飛ばしてくださいねという意味です。3600秒は1時間なので、キャッシュが1時間有効、要するに www.example.com のリソースレコード値を変更すると反映まで最大1時間程度かかるよ、ということになります。
このTTLですが、それぞれのDNSサーバの仕様によるものの30秒程度まで短縮することができます。今回は仮に60秒に設定することにします。「だったら最初っから常時60秒に設定しとけばいいじゃないか！」と思われるかもしれませんが、これを常時60秒にしてしまった場合、キャッシュ時間が切れる頻度が上昇し、頻繁に権威DNSサーバまで名前解決しに行くことになりDNSルックアップに時間がかかるため、サイト表示の速度が落ちます。TTLが大きければ、それだけ長時間遠くの権威DNSサーバではなく近所のキャッシュDNSサーバで名前解決ができるのでページの表示速度もそれだけ早くなります。キャッシュ時間を恒常的に短くすることはサイト表示時間の低下を招くのでなにもない時は長めにしておきましょう。
というわけで設定値を変更しましょう。DNSサーバの管理画面などでTTLを60にします。
元のTTLが3600であれば1時間後ぐらいに再びdigコマンドを使ってみると反映されていると思います。
$ dig www.example.com a ＜前略＞ ;; ANSWER SECTION: www.example.com. 60 IN A （IPアドレス） ＜後略＞
DNSの設定値を調べるのに非常に便利なサイトがあります。 whatsmydns.net に調べたいドメインとリソースレコードを入れると世界中のDNSサーバでの設定値を見ることができます。これにより設定値がどれだけ書き換わっているかを確認することができます。
事前準備は以上で終了です。前述の通りTTLを短縮すると名前解決に時間がかかるようになりますので86400秒などに設定されている場合は、設定24時間以上前に3600秒まで短縮しておき、さらに設定1時間以上前に60秒にするといった感じで段階的に短くするのがおすすめです。デフォルト値はDNSによってそれぞれですので、設定変更が必要になった場合は事前にTTLを確認しましょう。72時間などに設定されている場合は設定変更の反映まで3日以上かかるため、1週間以上前にTTL値だけは確認して必要なら設定変更しておくと良いでしょう。
もちろんTTLはただのキャッシュ時間なので、面倒くさいから86400のまま設定変更！という乱暴な対応も可能ですが、上で説明している通り反映に最大1日かかることになります。正常に設定ができればそれでもいい（本当は良くはないが時間が経てば設定完了することはする）のですが、もし間違った値を設定したり設定自体を切り戻したりしたくなった場合、切り戻しに1日以上かかることになり非常にリスクが高くなります。DNSサーバのリソースレコードを編集する時はTTLを短縮→作業→様子見→TTLを短縮前に戻す、というフローが安全です。DNSサーバについては初心者向けの本などが多数販売されていますのでぜひ一読をおすすめします。CDNの利用時以外にも、レンタルサーバの引っ越しの時などに非常に役に立ちます。
ウェブサーバ側の設定
CDN事業者の仕様によりますが、キャッシュするかしないかの設定をオリジンサーバ側で設定しなければいけないことがあります。さくらのCDNウェブアクセラレータでは、CDN側にキャッシュするかしないかの設定を制御する機能が無いので、オリジンサーバ側で「Cache-control: s-maxage=600」といったHTTPレスポンスヘッダを追加する必要があります。Amazon CloudFrontではサーバを通過するトラフィックを全部キャッシュする機能がありますが、意図しないファイルのキャッシュをしてしまう可能性があるのでできれば明示的にキャッシュ対象ファイルを選ぶ方がいいでしょう。Amazon CloudFrontでは全ファイルキャッシュするか、レスポンスヘッダで制御するかをディストリビューションの設定で変更することができます。
レスポンスヘッダの追加は、.htaccessを編集できるなら簡単に追加することができます。ウェブアクセラレータマニュアルページで詳しい設定方法をご紹介しています。よくあるミスで、「Cache-Control: max-age」と秒数指定を忘れたり、レスポンスヘッダ自体を付け忘れたりしてキャッシュヒット率が0％になったままCDNを利用している（お金だけ掛かって負荷分散はされない状態）方がたまにいらっしゃいますので、レスポンスヘッダの正しい設定とDNS設定後の動作確認はしっかり行いましょう。
事前表示確認
CDNの設定は本番一発な部分が多いですが、事前に確認できることは確認しておきましょう。特に初心者の方は本番環境に影響のない適当なサブドメインのサイトを作って何度もなれるまで練習することをおすすめします。一通りの設定が終わったらまずはCNAME設定先での表示確認です。CDNにオリジンIPアドレスやオリジンホスト名を設定した後、このドメインにCNAMEしてくださいね、というアドレスが発行されます。さくらのCDNウェブアクセラレータでは、 （ランダム英数字）.user.webaccel.jp というURLが発行されます。
このアドレスにアクセスしてみて実際にサイトが表示されているかを確認します。WordPressのサイトの場合はサイトURLが異なると遷移ができなくなりますが、トップページだけは確認できるはずです。表示されない場合、オリジンサーバの設定に問題があるか、CDN側の設定に問題があります。
次に、Chromeデベロッパーツールなどで意図したファイルがキャッシュされ、レスポンスヘッダ X-Cache: HIT になっているかを確認します。これがMISSになっているとキャッシュされていません。数回リロードしてもMISSのままのようなら設定ミスが疑われます。マニュアルを見て設定を見直しましょう。
切り替え作業
さて、実際にウェブサイトのCDN配信を設定していきましょう。
事前作業でTTLは60秒になっていると思います。ここで一つ大事なことを書いておきますが、CNAMEを設定しようとすると、同じサブドメイン（今回の例では www.example.com ）にAレコードやTXTレコードは設定できません。つまり、Aレコードがある状態でCNAMEレコードを追加することはできないので、Aレコードを削除してからCNAMEレコードを設定することになります。ウェブアクセラレータの場合はドメイン所有確認のためTXTレコードを設定していると思いますので、これをまず削除します（動作には影響ありません）。
DNSサーバの仕様によりますが、一度削除してから追加しなければいけないものと、一度の操作で削除と追加ができるものがあります。前者の場合、ネガティブキャッシュが発生する可能性が高まりますのでこの作業は迅速に行うことが重要です。また、サイトが見られなくなったりする可能性がありますので深夜など見ている人の少ない時間帯で作業するのも良いアイディアです。
ネガティブキャッシュって何？
DNSのネガティブキャッシュについて、聞き慣れない言葉だと思いますのでちょっと触れておきましょう。これまで権威DNSサーバに設定されたリソースレコードはTTLの時間分キャッシュDNSサーバで名前解決される、TTLを過ぎると権威DNSサーバへ再度問い合わせに行くことをご説明してきました。これはリソースレコード値がある場合の話です。
もしリソースレコード値が無い場合、SOAレコードというAレコードの親分みたいなもの（すみませんだいぶざっくりです）のTTL分「リソースレコード値が無い」ことがキャッシュされます。これがDNSにおけるネガティブキャッシュです。ネガティブキャッシュが保持されている状態で権威DNSサーバに新しい設定値を投入しても「リソースレコード値が無い」ことがキャッシュDNSサーバにキャッシュされているため新しい設定値での名前解決はできません。つまり、Aレコードを消したことがキャッシュされるとサイトは閲覧できないことになります。新しい設定値はSOAレコードのTTLが切れると再度権威DNSサーバへ問い合わせが行き、反映されます。
ネガティブキャッシュの時間はSOAレコードのTTLか、SOAレコードのMINIMUM値のどちらか小さい方とRFC2308で規定されています。さくらインターネットで運用しているDNSサーバである ns1.dns.ne.jp で見てみると、TTLは900でMINIMUMは3600ですので、900秒が適用されることになります。
$ dig example.com soa ＜前略＞ ;; AUTHORITY SECTION: example.com. 900 IN SOA master.dns.ne.jp. tech.sakura.ad.jp. 2018111400 3600 900 3600000 3600 ＜後略＞
利用しているDNSサーバによってネガティブキャッシュの時間は異なりますので、作業前に確認しておくとトラブル発生時にも落ち着いて対応できます。DNSは非常にややこしいシステムですが、ウェブサイトを運営する上で非常に重要な知識ですので是非ともこの機会にCDNの利用方法とセットで覚えておきましょう。
切り替え作業に戻りましょう！
サイトが見られなくなると書くと「怖い作業！」と身構えてしまう方もいらっしゃるかもしれませんが、TTLの説明を思い出して安心してください。設定値を間違ったとしても最大キャッシュ時間であるTTLを短くしていれば被害を最小限にすることができます。ネガティブキャッシュ発生の可能性はありますが、作業を手早く行えばそれだけ可能性を減らせます。
というわけで切り替えです。CDN事業者から発行されたCNAME先を既存のドメインに設定します。通常はDNSサーバの設定変更画面で作業します。Aレコードを削除するか編集し、CNAMEレコードにして値をCDNから発行されたドメインにします。TTLは60秒のままにしておきましょう。
設定したらdigコマンドで確認します。TTLは動作確認が完了するまでは60秒にしておきましょう。
$ dig www.example.com cname ＜前略＞ www.example.com. 60 IN CNAME （ランダム英数字）.user.webaccel.jp. （ランダム英数字）.user.webaccel.jp. 60 IN A （IPアドレス） ＜後略＞
しばらくしないと（理論的にはこの場合は60秒以内）反映されないので気をつけてください。この際、先程ご紹介したwhatsmydns.netを利用すると便利です。設定値を見るとこれまでのAレコードにIPアドレスが設定されたシンプルな状態から、サイトドメインにCNAMEレコードが設定され、CDNへリダイレクトされるような感じで、さらにそのCDNのサーバIPアドレスにAレコードが向いている形になりキャッシュサーバ（この場合はDNSではなくCDNの方ですよ）へアクセスが迂回されるように設定変更されました。
DNSではサイトドメインの向き先をオリジンからCDNへ向けるだけですので、CDN側でオリジンのIPアドレスやFQDNを設定する必要があることがわかります。
動作確認
設定してウェブサイトが正常に見えているなら動作確認をしていきましょう。一通りサイトの表示を確認します。投稿機能などがある場合やWordPressを利用している場合などは実際の投稿なども確認してみましょう。
連載第3回でも触れておりますが、WordPressの管理画面（/wp-admin/配下）などはキャッシュをオフにした方がオペレーション上都合が良いので、そのあたりも設定していれば動作確認した方が良いでしょう。特に、Amazon CloudFrontを利用する場合、WordPressサイトはキャッシュ除外設定、Cookie転送設定などを入れないと管理画面が正常に動きません。さくらのCDNウェブアクセラレータでは設定内容がシンプルな代わりにこのあたりの煩雑な設定が必要ありません。一通り確認を終えたらTTLを元の長いものに戻しておきましょう。キャッシュされているかいないかの確認方法も、マニュアルサイトに記載されています。Chromeデベロッパーツールで、下の画像のように期待したファイルのX-Cache: HITになっていることを確認できたらOKです。
実際、CDN設定時のお問い合わせの非常に多くの割合を占めるのはファイルがキャッシュできないというものです。さくらのCDNウェブアクセラレータでは Cache-Control: s-maxage=60 のようにレスポンスヘッダを設定した場合でも、他の箇所で no-cacheを付けていたり、その他のキャッシュ無効ヘッダがあったりする場合はキャッシュしない設定になっています。特にWordPressをご利用の場合、ログイン状態でサイトを閲覧した場合やダッシュボードはすべてno-cacheヘッダが自動付与されますので気をつけてください。
切り戻し
設定の不備などがあって、サイトが表示されなかったり、期待した動作にならなかったりして、切り戻す場合の手順をご紹介しておきます。基本的には再度DNSの設定を変更することになります。このためにCNAMEを設定する際にも万が一の時にすぐに戻せるようTTLを60秒にしているわけです。DNSの設定変更画面へアクセスし、CNAMEになっているところをAに戻し、CDNのドメインを消して元のオリジンのIPアドレスにします。TTLはこの時も念のため60秒にしておきましょう。
設定変更が反映されるとウェブサイトの配信がCDN経由からオリジンサーバからの直接配信に戻ります。切り戻しに成功したら必要に応じてTTLを元に戻しましょう。これで切り戻しは完了です。
まとめ
CDNとは？から実際の設定まで駆け足でご説明してきましたがいかがでしょうか？今回の設定編で気づかれた方も多いと思いますが、CDNの設定で一番難しいのはDNSの仕組みの理解とキャッシュ設定によるところがほとんどです。逆にこれ以外の部分は非常にシンプルで、設定方法を一度覚えてしまえば乗り換えやON/OFFの切り替えなどが自由に行えるようになります。
CDNは転送量による従量制課金のサービスが多く、ちょっと使ってみてまた戻すという使い方も簡単にできます。気軽にお試しができるCDN、まずは500GiB無料枠がついているさくらのCDNウェブアクセラレータから始めてみてはいかがでしょうか？
さて、さて、次回(第6回)は、レンタルサーバにおけるキャッシュの活用方法をご紹介します。最近のレンタルサーバで多い「ブラウザキャッシュ」の機能やキャッシュサーバを利用したキャッシュ機能、WordPressのプラグインを利用したキャッシュ機能、CDNを利用したキャッシュ機能など、一言でキャッシュと言っても実に多くのパターンがあります。ある程度の規模のサイトを運営する場合キャッシュ機能を知っておくことは安価にサーバを運営していく上で非常に役立つ知識です。