この記事の内容について
CDNを利用していないサイトに初めてCDNを適用する場合、または配信に利用しているCDNを別のCDNのサービスに乗り換える場合に確認すべき内容や注意すべき点をまとめてみたいと思います。
なお、新規に導入する CDN は Fastly を前提とした内容ですが、必要な確認内容等はどのCDNでも同様になります。
事前に検証すべき内容について
それでは実際に導入前に検証すべき内容について説明していきます。検証すべき内容はサイトのサービス内容等によって若干の差はあるかと思いますが、大きく分けると以下の4つのポイントに分けられます。
- サイト上の機能が問題なく動作するか
- キャッシュしてはいけないものがキャッシュされていないか
- キャッシュすべきものが意図した TTL でキャッシュされているか
- 必要なアクセス分析情報が取得できているか
これらのポイントは hostsファイルを利用したCDNの導入前テスト を行うことで一般ユーザーに CDN を適用する前に確認することが出来ます。
上記のポイントの挙動をブラウザ、スマートフォンのアプリケーションなど実際のクライアント端末の挙動からと、Fastly-Debug レスポンスヘッダーなどのデバッグ情報の両方から確認しましょう。
それではそれぞれのポイントについてもう少し詳しく説明します。
サイト上の機能が問題なく動作するか
今まで直接配信していたものを CDN 経由での配信に切り替える場合、ページのレイアウトが崩れていないか、表示されていない画像は無いかなどサイトが正しく表示されているか。また、サイトで提供している機能が今までと同じく動作することを確認する必要があります。
例えば ショッピングサイトであればログイン、ログアウト、カートに商品を入れる、購入処理を行うなど、ユーザーがサイトで取りうる一通りの処理を検証すべきです。
画像サーバーのみに CDN を導入する場合、仕組み上サービスの動線に影響があることは少ないですが、それでも念の為一通りの機能が正しく動作することは確認しておくに越したことは無いでしょう。
キャッシュしてはいけないものがキャッシュされていないか
CDN 導入時に一番避けたいのが誤って個人情報をキャッシュしてしまい別のユーザーに配信してしまうということです。特に CDN の乗り換えの際にはCDNベンダーによってキャッシュルールの決め方は異なりますので十分な事前の検証を行いましょう。
動作を確認する際にはレスポンスに含まれる Fastly-Debug ヘッダー情報などを確認し、個人情報を含むレスポンスがキャッシュされていないことを確認します。
また、一つのユーザーアカウントではなく複数のアカウントでログインしてファイルがキャッシュされていないことなどを確認しましょう。
キャッシュすべきものが意図した TTL でキャッシュされているか
オブジェクトがキャッシュされていたとしても TTL が短く設定されていると CDNによる負荷軽減やパフォーマンス改善の効果が弱くなってしまいます。
キャッシュ対象のオブジェクトに十分な TTL が設定されていることを確認しましょう。
更新頻度の少ない画像やjs, css などの静的オブジェクトであれば通常1日や30日。更新を想定していないのであれば365日程度のTTLが設定されていれば十分でしょう。
ある程度更新頻度の高いオブジェクトは更新時にキャッシュの削除（パージ）を行う仕組みを実装できるのであれば静的オブジェクトと同様に長いTTL。
パージの実装が難しいのであれば、オリジン側での変更がエンドクライアントに反映されるまでに許容できる最大の時間をTTLを指定しましょう。
必要なアクセス分析情報が取得できているか
今まで取得できていたアクセス分析情報と同じ情報が CDN 経由でも取得できることを確認しましょう。
リアル・ユーザ・モニタリング(Real User Monitoring, RUM)と呼ばれるクライアント側で分析情報を取得している場合は特に何もしなくてもそのまま情報が取得出来ることが多いですが、念の為 CDN 経由で配信した場合も問題なく必要な情報が取得できているかは確認しておきましょう。
ログからアクセスを分析している場合は、現在のログのフォーマットに沿った形でのログの出力を行うことで対応できます。
問題はサーバー側で情報を収集している場合、例えば以下のような問題が発生します。
- オリジン側で認識するクライアントのIPがFastlyサーバーのIPとなる
クライアントのIPは Fastly からオリジンへのリクエストに含まれる Fastly-Client-IP ヘッダーに含まれています。
オリジン側でクライアントのIPが必要な場合は Fastly-Client-IPヘッダーの値を利用できます。
- キャッシュされたオブジェクトに対するリクエストはオリジンに到達しない
Fastlyがキャッシュしたオブジェクトからリクエストを処理した場合、リクエストはオリジンには到達しません。分析が必要なページはキャッシュしないケースが多いですが、キャッシュ対象のリクエストも分析する必要がある場合はログなどから分析を行うなどの対応が必要です。
オリジン側の分析は分析している内容によって必要な対処は異なるので、必要な情報に応じた対応が必要となります。
事前に確認しておくべき手順
続いては CDN 経由での配信を始める前に、万が一の問題が発生した場合にどのように対処を行うかを確認しておきます。
キャッシュの削除手順
キャッシュしたくないオブジェクトをキャッシュしてしまった場合、CDN のネットワーク上から該当のオブジェクトを削除(パージ)する必要があります。
Fastly では個別の URL、Surrogate-Key と呼ばれるタグを設定したグループ、該当のサービス全体と3つの種類でパージを行うことが出来ます。
事前にどのような手順でパージを行うかを確認しておきましょう。手順については以下のページをご参照下さい。
Fastly でコンテンツをパージ（キャッシュを削除）する
切り替え、切り戻し手順
CDN 経由での配信に切り替えた後に何らかの問題が発生し、問題の修正に時間がかかりそうな場合には一旦 CDN を経由しない構成に切り戻すことが考えられます。
通常 CDN は対象のドメインの DNS レコードを CNAME することで導入します。切り戻す際は逆の作業となります。
万が一にそなえて CDN を導入する際は事前に DNS のTTL を短めに設定するなどの対策をとっておきましょう。
切り替えの手順の詳細等は以下のページをご参照下さい。
問題発生時のトラブルシュート手順
CDN 経由の配信で何らかの問題が発生した場合、ログを取得しているとトラブルシュートが容易になるケースが多いです。
可能な限りサービス導入前に障害に備えてログの配信設定を行いましょう。
まとめ
CDN を初めて導入する際には色々と不安になることもあると思いますが、事前に十分な検証を行うことで問題は避けることが出来ます。
また、問題が発生した場合の対処方法を予め確認しておくことで万が一の問題が発生しても安心してスムーズに対処することが出来ます。
十分に検証を行い、安全に CDN を導入しましょう。
なお、Fastly はキャッシュの削除やログ配信、設定変更もほぼリアルタイムで行なえるので万が一問題が発生しても迅速に対処が可能な CDN となっています。