様々なサービスと組み合わせてのCDN活用、構成のケーススタディ解説

CDN（content delivery network）が利用される理由は様々ですが、別のソリューションと併用されるなど、利用される環境にも様々なパターンが存在します。本記事では単純な利用構成以外のパターンについて、ケーススタディとして5つ解説します。

CDNの基本について知りたい場合は、下記の記事をお読みください。

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

単純なCDN利用の構成と諸注意

CDNはオリジンサーバーよりもクライアントに近い方へ位置し、リバースプロキシのように動作することで、オリジンサーバーにかかるアクセス負荷を軽減したり、配信の高速化に貢献したりするソリューションです。クライアント⇒CDN⇒オリジンサーバーという流れでリクエストされ、CDNがオリジンサーバーから取得したコンテンツをキャッシュした後は、そのキャッシュが最新版であると設定された時間内は、CDNがオリジンサーバーへのリクエスト無しに、クライアントに対するレスポンスを行います。

SSL化のためのCDN利用

これが最も標準的で、多くのCDNユーザーで見られる利用例です。この時、クライアントとCDN間の通信においては、CDNサーバー側にSSL証明書のインストールがされていれば、オリジンサーバー側にはされていなかったとしても、クライアントに対してHTTPS通信を行うことが可能です。クライアントブラウザも、対象のWebサイトをSSL化されているWebサイトとして表示します。

CDNはDNSによってリクエストをオリジンサーバーではなくCDNに向けるよう指定するのみで利用できるサービスですので、より簡易にWebサイトのSSL化を実現したい場合に用いられることがあります。またSSL通信にはコンテンツのやり取りに先んじて、クライアントとサーバーの間で暗号化通信を確立させる処理が発生するため、これによるサーバーの負荷対策を行いたい場合などにも利用を検討出来ます。

オリジンサーバーにSSL証明書がインストールされていない場合、CDNとオリジンサーバーとの間の通信はHTTP通信になる点を考慮しておく必要があります。この配信方法を採用する場合は、CDNとオリジンサーバーの間の通信が第三者に傍受、改ざんなどをされない環境になっているという前提が必要です。

直接オリジンサーバーをリクエストされないようにする工夫

もしクライアントからオリジンサーバーのドメインやIPアドレスに直接リクエストされてしまった場合は、CDNを介さずにオリジンサーバーが直接レスポンスすることになってしまいます。この時オリジンサーバー側にSSL証明書が設定されていなければ、クライアントに対してHTTP応答しなければならず、またクライアントブラウザによってはHTTPサイトの閲覧に警告を出す機能が備わっていますので、サイトの表示が出来ない場合もあります。また、直接リクエストされてしまった場合はCDNを利用している恩恵をオリジンサーバーが受けることが出来ません。

Ｊストリームが提供するCDNサービス「J-Stream CDNext」ではCDNからオリジンサーバーへアクセスする際に「Via: JSTCDN」というヘッダ情報が付与されますので、オリジンサーバー側でこのヘッダの存在するリクエストのみの通信を許可するよう設定しておくことを推奨しています。

アクセスログに関する注意

前述のようにCDNはクライアントからのリクエストを最初に受ける位置に配置されることが多いサービスです。これ以後もそのような例をご紹介していきますが、その際の注意として、オリジンサーバーへのリクエストがCDNに一本化されるため、オリジンサーバーが受け取るアクセスログが、全てCDNのキャッシュサーバーの情報になるという点を考慮してください。「J-Stream CDNext」ではエンドクライアントからのアクセスログ情報を無償提供する機能を備えていますので、必要な際にはこれを利用することが出来ます。

【ケーススタディ1】 サイトダウンのケアを行う構成での利用

CDNの大きな導入理由としてオリジンサーバーの負荷対策が挙げられますが、万一オリジンサーバーがダウンしてしまった場合に備えたインフラ構成としているWebサイトに対して、更なる可用性を期待して導入される場合があります。

構成例

クライアントからのリクエストをまずロードバランサーが受け取ります。オリジンサーバーは冗長構成となっていて、正系のサーバーに異常が無ければ正系に、正系が応答出来ない状態であれば副系としてスタンバイしているサーバーにロードバランサーがリクエストを振り分けるなどの構成が取られている場合があります。時にはオリジンサーバーが応答出来ない状態である時、現在Webサイトが表示できない状態である旨をクライアントに断るためのSorryコンテンツを配信するためのサーバーに接続するよう設定されていることもあります。

この時CDNを利用する場合は、クライアントとロードバランサーの間にCDNを配置します。CDNはクライアントからのリクエストを受け取ると、ロードバランサーに対してコンテンツのリクエストを行います。その後ロードバランサーはCDNが無い場合と同じように振る舞い、CDNはレスポンスされたコンテンツをキャッシュし配信します。次回の同じコンテンツへのリクエストに対してはCDNがキャッシュしたコンテンツを配信しますので、ロードバランサーより後ろのインフラの稼働はありません。
CDNがあることによって、ロードバランサーがリクエストをオリジンサーバーへ振り分けるという動き自体の頻度を減らすことが出来るので、アクセス負荷によるオリジンサーバーのダウン対策として、更なる効果が期待できます。

【ケーススタディ2】 リバースプロキシの前段での利用

セキュリティ対策上の理由などにおいて、オリジンサーバーの前段でクライアントからのリクエストを受け止め、リバースプロキシとして動作するサーバーを用意している例があります。地方自治体が構築する自治体情報セキュリティクラウドなどがその例の一つです。この環境においてCDNを利用することも、アクセス負荷対策などの理由において有効です。

構成例

クライアントとリバースプロキシの間にCDNを配置させる構成が一般的です。オリジンサーバーのアクセス負荷に効果的であることはもちろん、オリジンサーバーの応答頻度を減らすことによるセキュリティ対策上の要請にも貢献することが出来ます。この場合も、リバースプロキシはCDNからのアクセスしか受け付けない設定を施しておくと尚のこと効果的です。またセキュリティ上のケアが強く求められるWebサイトの場合は、Webサイト上で望ましくない振る舞いをしたクライアントを特定するなどの理由によってアクセスログの解析が必要になることがあります。
前述の通り「J-Stream CDNext」にはアクセスログの無償提供機能がありますので、これを有効に利用することが出来ます。また「J-Stream CDNext」の機能によって、特定のIPアドレスからのアクセスをブロックすることが可能です。（反対に特定のIPアドレスからのアクセスのみ許可することも可能）特定のクライアントからの防御が必要な場合は、リバースプロキシの前段での当機能の利用が有効です。

キャッシュの生存期間に関する注意

この構成の際、オリジンサーバーでCache-Controlヘッダのmax-ageが設定されている場合は、リバースプロキシはmax-ageの設定時間分はオリジンサーバーからレスポンスされたコンテンツをそのままCDNにもレスポンスします。その時CDNもそのコンテンツをキャッシュしますが、CDN側にもキャッシュの生存期間（TTL）が設定されていた場合、オリジンサーバーのmax-ageとCDNのTTLが重なって、意図した以上にキャッシュの生存期間が延びてしまう可能性があります。更新頻度が高いWebサイトや、更新を直ちに反映させたい場合などでは注意が必要です。このような懸念がある際にはmax-ageやCDNのTTLの設定値をチューニングして対処します。

関連記事

• キャッシュHIT率を向上させ効果的にCDNを利用する

構成に関する補足

セキュリティ対策上の理由においてリバースプロキシを利用している場合は、リバースプロキシの後ろに保護すべき内部ネットワークが存在することが多いでしょう。リバースプロキシと内部ネットワークの間にCDNを配置してしまうと、リバースプロキシからのリクエストが一度インターネットに出てCDNへ向かい、CDNからインターネットを通じて内部ネットワークへ接続するという流れになってしまうので、この構成はほとんど採用されません。

【ケーススタディ3】 WAFとの併用

WAF（Web Application Firewall）が利用されているWebサイトにCDNが併用される場合があります。WAFは専用機器を購入して用いるアプライアンス型の他に、月額費用を支払ってサービスとして利用するクラウド型が存在し、導入や運用の手軽さから近年後者の利用が拡大しています。

クラウド型WAFとの構成例

クラウド型WAFはCDNと同じようにDNSによってオリジンサーバーの前面でリクエストを受け、悪意のあるものを遮断してオリジンサーバーを防御します。この時CDNは、大抵の場合クライアントとクラウド型WAFの間に位置します。これは、単純に可用性を高める意味もありますが、クラウド型WAFの運用コスト削減のために用いられる場合があります。

クラウド型WAFはピークトラフィックに基づいた帯域課金であることが多く、大量トラフィックを受けてしまうとその分運用費に跳ね返ってしまいます。「J-Stream CDNext」はCDNからクライアントに対して配信されたデータ転送量が課金根拠になります。クラウド型WAFの前面にCDNが位置してコンテンツの配信を行うことで、クラウド型WAF側の配信帯域を抑えることが出来るため、クラウド型WAFと比較してCDNの配信単価が安価である場合、合計の運用コストから勘案してこの構成が採用される場合があります。
Ｊストリームでは「Imperva App Protect」というクラウド型WAFを提供しており、「J-Stream CDNext」との併用構成の提案実績も多数あります。また「Imperva App Protect」に加え、安価で気軽に導入できる「BLUE Sphere」も取り扱っています。お客様の要望や検討の状況に合わせ、最適なサービスをご提案します。

この構成を採用する際、CDNとクラウド型WAFの間の通信は、それぞれからサービスの機能として払い出されたFQDNを利用して行われることが多いですが、多くのサービスでこのFQDNはデフォルトでSSL化されています。従ってクライアントとCDNの間、及びクラウド型WAFとオリジンサーバーの間の通信の暗号化のみ、サービスの利用者は考慮すれば良いことになります。

【ケーススタディ4】 リクエストヘッダ変換

クライアントとオリジンサーバーの間に位置して動作するサービスにはCDNやWAFの他にも様々な種類が存在します。それらの仕様によっては、オリジンサーバーがうまくリクエストを受け取れない場合があります。この時、そのサービスとオリジンサーバーの間にCDNを配置させることによって、リクエストの疎通を手助けできることがあります。

画像変換サービスとの併用例

例を挙げてご紹介します。
メディアサイトなど画像を多く掲載しているWebサイトにおいて、同じ画像をサイズ別に用意して複数のWebページで表示させる運用をしている場合があります。この時、クラウド上で自動的に1枚の画像を様々なサイズに変換したり、ウォーターマークを重ねるなどの加工をしたりすることが出来るサービスの利用が検討できます。
このサービスはクライアントとオリジンサーバーの間で動作し、変換の設定がされている画像コンテンツへのリクエストがあった際には、設定通りに画像コンテンツを変換してクライアントにレスポンスします。Webサイトの運用者は静的に同じ画像を複数のサイズなどで用意する必要が無くなるため、運用負荷やストレージ容量の削減に効果的です。この時、画像を変換するサービスの仕様により、オリジンサーバーへリクエストを行う際のヘッダ情報が意図しない値になってしまい、オリジンサーバーがリクエストを正常に受け取れないケースがありました。

そこで画像を変換するサービスとオリジンサーバーの間にCDNを配置させます。「J-Stream CDNext」にはオリジンサーバーへリクエストする際のヘッダ情報を追加もしくは除去する機能が搭載されています。これを利用して、疎通を妨げているヘッダ情報を修正することにより、オリジンサーバーは当サービスからのリクエストを正常に受け取ることが出来るようになりました。
更に画像を変換するサービスとクライアントの間にCDNを配置することも、配信効率の向上に貢献します。変換された画像をCDNがキャッシュすることにより、リクエストの度に画像を変換する必要がなくなるため、配信の高速化に効果が期待できます。
この例の構成をまとめると、クライアント⇒CDN⇒画像変換サービス⇒CDN⇒オリジンサーバーということになります。

Ｊストリームではこのような画像変換サービスの提案も可能です。現在のWebサイトやインフラ構成などに適したチューニングを施した上でサービスを提供します。

【ケーススタディ5】 CDNからCDNへのリクエスト

CDNは一般に、地理的に分散された複数のキャッシュサーバーで構成され、それぞれのキャッシュサーバーがコンテンツのキャッシュを保持し、リクエストされた地域からその時最も合理的な拠点に位置するキャッシュサーバーが応答する仕組みになっています。キャッシュサーバーの台数が多ければ、CDNサービスとしての配信性能に直接ポジティブに影響します。

キャッシュサーバーによるオリジンサーバーへの負荷

しかしあまりにもキャッシュサーバーの台数が多い場合に、それぞれのキャッシュサーバーがオリジンサーバーへコンテンツのリクエストを行うと、キャッシュサーバーからのリクエストによってオリジンサーバーに負担をかけてしまう恐れがあります。CDNの配信キャパシティとオリジンサーバーに与える負荷についてはトレードオフの関係である場合があります。

「J-Stream CDNext」のキャッシュサーバーはある程度の台数でグループを組む構成となっており、各グループ内の代表のキャッシュサーバーのみがオリジンサーバーへコンテンツのリクエストを行い、レスポンスされたコンテンツをグループ内で共有する仕組みになっています。これによりキャッシュサーバーからオリジンサーバーへ与えるアクセス負荷を軽減しながら、正常にキャッシュを各キャッシュサーバーへ行き渡らせることが出来ます。

例えば、既にあるCDNサービスを利用しており、詳細な配信設定を施しているなどの理由から、安易に他のCDNサービスへ乗り換えられないが、既存CDNからオリジンサーバーへのアクセス負荷を軽減させたいという場合に、既存CDNから「J-Stream CDNext」へリクエストさせるよう設定することで問題を解消することが出来ます。
その場合の構成は、クライアント⇒既存CDN⇒J-Stream CDNext⇒オリジンサーバーとなります。
多数のキャッシュサーバーからのアクセス負荷に耐えることができるようオリジンサーバーを増強するコストに対して「J-Stream CDNext」を導入するコストの方が安価である場合、この構成を検討出来ます。

以上、シンプルな構成以外で利用されるCDNのケーススタディを5つ解説しました。
CDNを用いることで得られるメリットは、ごく単純なオリジンサーバーへのアクセス負荷分散だけではありません。Ｊストリームでは経験豊富なエンジニアと詳細な設定が可能なCDNサービスによって、Webサイトの仕様やインフラ構成、併用されるサービスの挙動などに応じた適切なサービス利用方法をご提案します。お気軽にご相談ください。

サービス詳細

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