CDNの移行においては、以下のような(一般的な)CDNトラブルが発生する可能性があります。
- キャッシュされない
- CDN切替によりオリジンサーバの負荷が上がり、サービスダウン
- キャッシュされる
- CDN切替により情報漏えいが発生する
- アクセスが遅くなる
- CDNが外れる
キャッシュに関するトラブルは致命的なものとなりやすいため、ここではキャッシュ関連のCDNによる違いをまとめます。
レンジリクエストへの対応
レンジリクエスト(巨大ファイルに対するファイルの部分取得)については、CDNより対応が大きく異なります。詳細については「レンジリクエスト」を参照ください。
Cookie、クエリ文字列の扱い
最近のCDNでは、動的ファイルに対するキャッシュとして、Cookie、クエリ文字列、ユーザエージェント等をキーとしたキャッシュが可能になっています。ただし、CDNにより対応レベルは異なり、以下に分類されます
- Cookie等をキーとして認識できる
- ホワイトリスト(オブジェクト認識に使用するキー)の指定が可能
- ブラックリスト(オブジェクト認識に使用しないキー)の指定が可能
オリジンサーバのHTTPヘッダ
オリジンサーバが発行するcache-controlなどのHTTPヘッダ(キャッシュ指示)は、CDNにより扱いが異なります。
設定の優先度
どちらを優先するかにより、キャッシュの振る舞いが変わります。それぞれにユースケースが存在しますが、CDNによっては片方の優先度しか取れません：
- オリジンサーバのcache-control > CDNへのTTL設定
- ユースケース
- CDNで全体的なTTLを設定し、特定のページのみno-cache等でキャッシュさせない
- ユースケース
- CDNへのTTL設定 > オリジンサーバのcache-control
- ユースケース
- WordPressのようなすべてのphpページに対しno-cacheを発行するCMSにおいて、no-cacheを無視する(phpをキャッシュさせる)
- ユースケース
対応
オリジンサーバのcache-controlをCDNで解釈する際にも、RFCに完全に準拠していない場合があります。
障害例
Mercari社(2017)
- 概要
- CDN切替において、ユーザ別ページがCDNによりキャッシュされ、情報の漏洩が発生した
- 詳細
- 切替後のCDNは、積極的にコンテンツをキャッシュする仕様になっていた
- 新CDNの特徴
- “Cache-Control: no-cache”を無視してキャッシュする
- Expiresヘッダが過去のものであっても、有効なCache-Controlがあればキャッシュする(上記：no-cacheの場合もキャッシュ)
- 新CDNの特徴
- 切替後のCDNは、積極的にコンテンツをキャッシュする仕様になっていた
- 鍋島補足
- CDNキャッシュによる情報漏えいは、「アクセスしたユーザの情報が他のユーザから見ることができる」というものであり、データベースの情報漏えい(全ユーザの情報リストが外部に流出)よりも軽微なものです
- AkamaiからFastlyへの切替であると思われます
- Fastlyの場合、国内配信サーバの数は多くない（多分、数十台程度）ため、実際の漏洩数は多くはないと思われます
- 現状、CDNにキャッシュさせたくないオブジェクトに対しては”Cache-Control:Private”を付けるのが無難です
- ユーザページに対する外部監視を行い、CDNでキャッシュされているかどうか判定することは有効です
- リンク