CDNのメリット・デメリットとは？ トラブル回避して上手に使う方法

CDN（Content Delivery Network）は多くのWebサイトで利用される利便性の高い技術ですが、使い方によってはトラブルの元になってしまうデメリットも存在します。メリットと合わせて、予想されるデメリットに対して事前にケアをしておくことで、安心してCDNを利用できるようにしましょう。

CDNの基本を確認したい方はこちらの記事もご覧ください。

• 【関連記事】CDNとは？　～ノンエンジニア向けにわかりやすく解説～

1. CDNの一般的なメリット

CDNを利用する理由にはいくつかの種類がありますが、その内の最も大きなものは配信パフォーマンスの向上でしょう。CDNを利用することで、オリジンサーバーにかかる配信の負荷を軽減でき、エンドユーザーに対してもネットワーク上最適な経路でコンテンツを配信できるようになります。表示速度の向上に貢献するので、ユーザー体験の最適化や、SEOにも効果が期待できます。

• 【関連記事】Webサイトの表示速度改善に貢献するCDNの機能とは？

また負荷によるオリジンサーバーのダウンのリスクを軽減するので、可用性の向上にも繋がります。CDN自体も高度に冗長化されているソリューションであるため、一部の拠点の障害がサービス全体へ影響を与えにくいという点も特徴です。CDNの高い配信能力に、DDoS攻撃などの高負荷を仕掛けられる攻撃への耐性を期待する場合もあるでしょう。

CDNはオリジンサーバーの負荷を軽減するので、CDNを導入することによってオリジンサーバーのスペックは下げても良くなることもあります。これはオリジンサーバーにかかるコストの圧縮に繋がります。Webインフラ全体の構成として、CDNを利用することを前提とした最適なスペックを検討していきましょう。

このようにCDNには様々なメリットがあります。サーバーに対して大きな負荷がかかる人気コンテンツばかりでなく、SNSの投稿やニュースサイトの記事、テレビの特集など、ふとしたきっかけでWebサイトへのアクセスが不意に高まり、サーバーに負荷をかけてしまうことで、Webサイトがダウンしてしまう事例はしばしば報道されます。CDNは思わぬ事故を未然に防ぎ、インターネット上における安定したコンテンツの配信をサポートします。

ただし使い方を間違えたり、ケアすべき点を見逃したりしてしまうと、思わぬトラブルが発生してしまう恐れがあるので注意が必要です。

2. CDNのデメリット①：キャッシュしてはいけないコンテンツをキャッシュしてしまう

CDNを利用する際には、CDN利用の対象となるドメインで配信されるコンテンツに、キャッシュしてはいけないものが含まれていないか確認する必要があります。
CDNは基本的に、オリジンサーバーから配信されたコンテンツをそのままキャッシュし、そのままエンドユーザーへ配信します。アクセスしてきたエンドユーザー全員に同じコンテンツを配信する場合であれば問題ありません。
しかし、例えば誰がアクセスしたかによって内容が変わるようなWebサイトを配信する場合は、Aさん向けのコンテンツをBさんCさんにも配信してしまう恐れがあります。

通販サイトなどでこのような事象が発生しまうと、個人情報の漏洩に繋がる重大な事故となってしまいます。実際に事故として大きなニュースになった例もあります。

参考記事

• 「メルカリ」の個人情報漏えい、原因はCDNキャッシュの仕様、技術的な詳細情報を公表／Impress Watch

CDNには特定のルールでキャッシュを制御する機能が備わっている場合が多いので、キャッシュしてはいけないコンテンツがある場合には事前に注意して設定を行う必要があります。
Jストリームが提供するCDNサービス「J-Stream CDNext」には、ディレクトリや拡張子、ファイル名単位でキャッシュ制御を行う機能を搭載しています。CDNがキャッシュすることで事故が起きてしまう可能性のあるファイルは、事前にチェックを行って適切にキャッシュルールを設定することが重要です。

3. CDNのデメリット②：古いコンテンツを配信してしまう

CDNがコンテンツをキャッシュしている時間のことを「キャッシュTTL」等と呼びます。
J-Stream CDNextの場合、エンドユーザーからのアクセスを受けると、それをきっかけにしてオリジンサーバーへコンテンツを要求し、応答されたコンテンツをキャッシュします。CDNはコンテンツをキャッシュした時から、TTLとして設定された期間の内は、オリジンサーバーへの問い合わせ無しに、エンドユーザーからのリクエストに応答してコンテンツを配信します。TTLが切れると、CDNはオリジンサーバー側でコンテンツの更新が行われていないか確認を行い、もし更新されていた場合は、改めてコンテンツをキャッシュし直して、またTTLの期間分配信を行います。
CDN利用下における基本的なコンテンツ更新の流れはこのようにして行われます。

TTLが長い場合

CDNサービスによって仕様は様々ですが、TTLは任意の値に調整することが可能です。
J-Stream CDNextの場合は5分を初期値としていますが、例えばこれを1時間や24時間などの長時間に設定することも可能です。TTLを長時間に設定した場合、それだけオリジンサーバーへの問い合わせ頻度を減らすことが出来るので、更にオリジンサーバーの負荷軽減の効果が期待できます。

ただし、TTLを長時間に設定している時には、オリジンサーバー側でのコンテンツの更新に注意が必要です。例えばTTLを24時間に設定している場合、オリジンサーバー側でコンテンツの更新を行っても、TTLが残っている間は、更新前のキャッシュがCDNから配信され続けてしまいます。この場合は最長24時間の間、古いコンテンツが配信され続けてしまうことになります。

TTLを短く設定する

古いコンテンツが配信され続けてしまうことを回避するためには、適切なTTL設定を行う必要があります。そもそもある程度更新頻度が高いコンテンツであれば、TTLは数分程度にしておくことが推奨されます。例えばTTLが5分であれば、最長でも5分待てばコンテンツの更新がエンドユーザーへの配信内容へ反映されることになります。更にリアルタイムな更新反映が必要であればTTLを数十秒程度にする場合もありますし、そのコンテンツのみキャッシュをしないという選択肢を取ることもあるでしょう。その場合エンドユーザーは、該当のコンテンツのみ必ずオリジンサーバーへ問い合わせを行うことになるので、必ず最新のコンテンツを受け取ることが出来ます。

TTLを長期間に設定する場合は、そのコンテンツの更新頻度が低いことを条件とすべきでしょう。長期間変更する予定の無い画像ファイルなどであれば、TTLを長く設定した方がCDNのメリットを強く享受することが出来ます。

TTLを短く設定した場合に考えられるデメリット

上記のような理由によってTTLをあえて短く設定する場合もあります。その場合は配信するコンテンツの更新のリアルタイム性はある程度強化されますが、CDNからオリジンサーバーへ問い合わせを行う頻度が増えるため、オリジンサーバーへかかる負荷は比較的大きくなります。同じWebサイト内のコンテンツであっても、TTLを長くすべきか、短くすべきか、よく見極めて適切な設定を行うことが重要です。
J-Stream CDNextではTTLを数秒の単位から1週間まで柔軟に設定することが可能です。TTLについてもディレクトリごと、拡張子ごと、ファイル名ごとに設定が出来ます。

4. CDNのデメリット③：アクセスログがオリジンサーバーに蓄積されない

GoogleAnalyticsをはじめとしたタグ埋め込み型（Webビーコン型）のアクセス解析は、CDN（Web負荷分散サービス）を導入しても影響ありませんが、それ以外の方式（サーバーログ取得型、パケットキャプチャリング型）のアクセス解析を利用している場合は注意が必要です。

CDNを利用する場合、エンドユーザーからのアクセスがオリジンサーバーへ到達しているか否かを問わず、アクセスは必ずCDNを経由することになります。アクセスがオリジンサーバーへ到達する場合も、実際にオリジンサーバーへ問い合わせを行うのは、エンドユーザーではなくCDNということになります。つまりCDNを利用することによって、オリジンサーバーはCDN以外から直接アクセスを受けることが無くなるということになります。
従ってアクセスログを確認した時、オリジンサーバー側のログにはCDNのサーバーからアクセスされたという記録しか残っていないことになります。エンドユーザーに関するアクセスログを取得したい場合にはCDN側に蓄積されているログ情報を参照する必要があります。

CDN事業者からのアクセスログの提供については、よく仕様を確認する必要があります。提供を行っていない、有償で行っている、無償で行っている、CDN管理者の裁量で取得できる/CDN事業者に問い合わせる必要があるなど、対応は様々です。J-Stream CDNextは無償でアクセスログの提供を行っており、サービスの管理画面からアクセスログファイルを管理者自身で取得する設定を行うことが可能です。

• 【関連記事】［CDN］アクセスログ無償提供。管理画面から簡単出力設定！ストレージの用意が不要！　：CDNextの特徴

GoogleAnalytics を利用している場合の注意点

当社が提供しているCDNサービス「J-Stream CDNext」のサポートサイトでは、下記のようにご案内しています。

GoogleAnalytics を利用する際はCookieキャッシュの設定にご注意ください。
Cookieキャッシュの設定で「全て利用」を選択すると GoogleAnalytics で利用される Cookie 毎にキャッシュが生成され、キャッシュヒット率が低下します。
Cookie 毎のキャッシュが必要な場合は、「指定Cookieのみ利用」もしくは「指定Cookieを除外」を選択し、対象の Cookie を絞るように設定してください。

J-Stream CDNext サポートサイト：https://tech.jstream.jp/blog/cdn/cdn_trouble_accesslog/

GoogleAnalyticsを始め、それぞれ利用しているアクセスログでの注意点は、導入予定のCDNサービスで確認しておきましょう。

5. CDNのデメリット④：フィーチャーフォンからのアクセスにケアが必要

フィーチャーフォンからアクセスすることを想定したWebサイトにCDNを導入する時には、特別な設定を必要とする場合があります。

CDNを利用して配信するWebサイトにSSLを適用する時、大抵の場合SNI（Server Name Indication）という仕様が用いられます。従来SSLは一つのサーバー（一つのグローバルIPアドレス）に対して一枚のSSL証明書という組み合わせが原則でした。CDN事業者がサービスとして提供しているCDNは、共通の配信基盤を用いて複数の顧客に提供を行っているので、顧客ごとに異なるSSL証明書を利用出来るようにすることは原則できないということになります。そのような時にSNI方式を採用すると、この原則が緩和され、ドメイン単位で異なるSSL証明書を利用することが出来るようになります。多くのCDNサービスで、SSL配信を行う際にはSNI方式が標準とされています。

しかしSNI方式によるSSL配信は一般的にフィーチャーフォンに対応していないため、フィーチャーフォンからはアクセスをすることが出来ません。フィーチャーフォン向けにもSSL配信を行う場合には、CDNサービス側に対象サイトの配信に用いる専用のグローバルIPアドレスを用意して、SNIではない仕様によって配信を行わなければいけません。この対応は一般にCDNサービスのオプションとしては高価であることが多いので、注意が必要です。

• 【関連記事】SNIとは？　CDNでSSL配信を行うための基礎知識

J-Stream CDNextでもフィーチャーフォン配信のために専用のグローバルIPアドレスを用意するオプションを提供していますが、費用対効果の観点などから、フィーチャーフォン向けにはFQDNを分けた別サイトを用意し、そちらはCDNを利用しない、あるいは非SSLのまま配信するという対応を取るケースも少なくありません。

6. CDNのデメリット⑤：キャッシュしないコンテンツの配信にも料金がかかる

前述の通り、あるドメインにCDNを適用する時には、エンドユーザーからのアクセスがオリジンサーバーへ到達しているか否かを問わず、対象のドメインへのアクセスは必ずCDNを経由することになります。つまりキャッシュをしてはいけないコンテンツであっても、CDNを経由して配信されるということです。

CDNにはいくつかの課金根拠がありますが、CDNからエンドユーザーに対して配信されたコンテンツの総転送量が最も基本的なものになります。これはCDNがキャッシュしているコンテンツであるかどうかを問わず、CDNから配信されたという点が根拠になるため、あえてキャッシュをしないという設定をしたコンテンツの配信にかかる転送量も課金対象となります。

キャッシュをさせたいコンテンツと、キャッシュをさせたくないコンテンツが明確に分かれている場合、サブドメインなどでFQDNを分けてしまうことでこれを回避できます。例えば画像コンテンツだけはキャッシュをさせたいという場合、「img.hoge.co.jp」を画像用FQDN、それ以外のコンテンツを「www.hoge.co.jp」などとそれぞれ設定し、前者のみにCDNを適用することで、前者だけをCDNの課金対象とすることが出来ます。

7. CDNのデメリット⑥：CNAMEレコード利用上の制約がある

CDNを適用するには、対象のドメインについて、DNSのCNAMEレコードによってCDNとの関連付けを行うことが一般的です。CNAMEレコードには他のDNSレコードと異なる特徴的な制約事項があります。CNAMEレコードに設定されるドメインは、CNAME以外のレコードへ一緒に登録することが出来ません。

これはRFCと呼ばれるインターネット上の技術に関する仕様をまとめた文書でも規定されており、CDNを利用するためにCNAMEレコードを設定する場合には注意が必要です。もし対象のドメインについてMXレコードやNSレコードなど他のDNSレコードの設定も行いたい場合、対応について検討しなければいけません。

またCNAMEレコードはサブドメインの付かないドメインに対して設定することが出来ないという制約もあるので、その場合CDNを適用することも基本的には出来ません。単純に、対象のドメインにサブドメインを設定するか、ALIASレコードと呼ばれるDNSレコードを利用することが出来るDNSサービスによって、CDNの利用を実現することが出来ます。

• 【関連記事】［CDN］「www」が付かないネイキッドドメイン（Zone APEX）でのCDN利用　：CDNextの特徴

以上、CDNのデメリットとその解消方法についてお伝えしました。
お伝えした通り、デメリットが発生する可能性をしっかりと把握していれば対処は難しくありません。CDNは正しく利用すれば高い効果を発揮する技術です。Ｊストリームでは経験豊富なエンジニアと営業担当、また国内で自社開発するJ-Stream CDNextに搭載された小回りの利く設定項目によって、お客様のサイトを安全に配信します。ぜひお気軽にお問合せ下さい。

サービス詳細

• J-Stream CDNext（シーディーネクスト）

お役立ち資料