CDN を導入する上で確認すべき注意点とは？

CDNベンダーは導入簡単！とマーケティングし営業さんも同じように手軽ですよ！と案内していることが多いです。これは間違いではありません。なぜなら導入自体はDNSレコードをかえるだけで完了するからです。しかし、気をつけなければいけない点は多数あります。導入が簡単であればよし！といかないのがキャッシュの世界。導入するサーバー（Webサイト等）に全く同じ構成がないように、導入するシステムや状況によって気をつけるポイントも多数存在します。これがCDNの面白いところでもありますが、全てのケースをご紹介することはできないので、今回はCDNを導入する上で注意・気をつけるべきスタンダードなポイントについて解説します。　　　　　　　　　　　　　　　　　　　　

CDNに切り替えできるドメイン（DNS）かどうか

凄く基本的なことですが、CDNを導入する予定のドメイン名によって（正確にはDNSサーバー）CDNに切り替えが出来ないケースがあります。

CDNに切り替える場合、DNSサーバーでCNAMEレコード設定を行いますが、redbox.ne.jpのようにサブドメインではないAPEXドメインをご利用中の場合は注意が必要です。簡単にいうとAPEXドメインはCNAMEレコード設定が出来ないので、DNSサーバーにてCNAMEと同じような機能を有していることがCDNを利用する上での前提条件になります。※APEXドメインでもCDNを適用したいホスト名と同じMXレコードなどが存在する場合も同じですがこれは回避策があります。

詳しく以下の記事で解説しているため合わせてご確認下さい。

まずはCDNの導入を予定しているドメイン名がAPEXドメインか否か確認しましょう。次に、MXレコードなどが利用するサブドメインに含まれているか確認してみましょう。

wwwなどが付与されているサブドメインであれば、どのようなDNSサーバーでもCNAMEレコードが対応していれば切り替え可能です。ただし、CNAME予定のサブドメインがDNSサーバー上で1つ以上ないことも確認すべきです。※もしMXレコードなどがある場合は、MXレコードをかぶらないように別名に変更が必要です。

サブドメインではないAPEXドメインを利用予定（中）の場合、利用しているDNSサーバーを調べて、DNSサーバーがALIAS、ZONE APEXのような機能を有しているか確認しましょう。DNSサーバーが対応していない場合、CDNを導入する前にまずはDNSサーバーの移転から行う必要があります。

主な対応DNSサーバー一覧

一昔前はZone Apex対応のDNSサーバーはごく僅かで、海外の英語UIで高価なDNSしかありませんでした。GehirnDNSはあるベンダーの間借りではありますが、APIと日本語UIにいち早く対応したベンダーでもあります。その他日本を代表するサーバー会社のほとんどのDNSは時代の流れと共にALIASレコード対応となっております。

従来までお客様がAPEXドメインをご利用で且つCDNをご検討頂いている際は、まずZONE　APEXというのは～から始まりDNSの移転が～というご案内を苦い思いでしていた弊社ですが、こうして対応DNSが増えることは大変喜ばしいことです。

SSL証明書一式は手元にあるか

遙か昔といっても最近ともいえますが、個人情報を取り扱うWebフォームやカート、会員ページのみSSLで利用するというケースが多かったとおもいます。しかし現在は常時SSL（フルSSLサイト）が当たり前になっています。

CDNを利用する場合CDN→ユーザー間でSSL通信を行うため、CDNにもSSL証明書を設定する必要があります。CDNベンダーによっては、CDNベンダーが発行したSSL証明書しか受け付けないケース（AKAMAIなど）以外は、既に利用しているSSL証明書をCDNでも利用することができます。既にHTTPSとなっているサイトの場合、なんとなく大丈夫でしょと思わずに今使ってるSSL証明書一式が手元にあるか今一度確認しましょう。

必要なのは証明書・中間証明書・秘密鍵（パスフレーズ無し）です。

また逆のパターンでSSL証明書一式は手元にあるけど、CDN用の証明書を銘柄が違う証明書で取り直したものを適用したいという場合もあるとおもいます。この場合、ユーザーとCDN間、CDNとWebサーバー（オリジン）と利用する証明書の種類が異なることになりますが、ユーザーからみるとCDNに適用した証明書のみ見えるため、銘柄が異なる証明書をつかっても特に問題ではありません。

無料SSLの罠

実は無料SSL証明書をつかっており、持ち出し出来ないというケースも多々見受けられます。※概ね無料SSL証明書というのは持ち出し不可です。手元に証明書一式がない場合は、新規でCDN用のSSL証明書を取得する必要があります。

SSL証明書取得手順については、最初に発行するドメインのCSRを作成し一緒に秘密鍵も作成します。その後、作成したCSRを使ってSSL証明書発行事業者にて申請を行います。証明書の種類によって最短数時間から1日程度で証明書の発行できるもはありますが、企業認証などの証明書は1週間～かかる場合もあるため事前にしっかり確認しましょう。

主なSSL証明書取得ベンダー

[the_ad id=”2875″]

CPIブランドのサーバーで有名な企業です。サーバー以外にもSSL証明書の代行取得も行っています。

[the_ad id=”2874″]

ネットオウル株式会社が運営しているサイトです。

SSLストア

ニジモが運営するSSL証明書代行サービスです。

IPアドレスで判断している事項（アクセス制限など）

管理画面へのアクセスや、PHPMYADMINなどの管理ツールへのアクセスは、IPアドレスでアクセス制限していることも多いと思います。CDNを導入した途端、閉め出されてしまわないようにIPベースでアクセス制限を実施しているかどうかは予め確認しておくべき事項の一つです。

CDNを導入するとWebサーバーからはクライアントIP＝CDN（キャッシュサーバー）のIPとなってしまいます。そのため、CDNが通知するクライアントIPをみてアクセス制限できるように修正する必要があります。

X-forwarded-forで正しくIPを識別

大抵のCDNは、HTTPリクエストヘッダーX-forwarded-forという中に、実クライアントIPをいれてWebサーバーに送信してくれますので、サーバーやシステムのIP制限において、クライアントIPではなく、X-forwarded-forの中身の値をみて判断できるようにしましょう。注意点としては、X-forwarded-forは経由する箇所が多い場合、カンマ区切りで複数IPがはいり実クライアントIPは一番左側に記載されます。

X-forwarded-for 例：クライアントIP,Proxyサーバー1,Proxyサーバー2

よってサーバーやプログラムで判断する時も一番左のIPアドレスで判断して下さい。

これらはCDNに限らず冗長化する上で利用するロードバランサー導入時も同じことが言えますが初めてCDNを導入する場合、シンプルにはまりがちなポイントです。

IP制限の他にも、IPアドレスによってリダイレクトしている場合も同様のことが言えます。

HTTPS利用時のリダイレクト判定

HTTPSサイトの場合、URL正規化のためHTTPでアクセスしてきたアクセスをHTTPSにリダイレクトするという設定をしている場合がほとんどだとおもいます。しかし、CDNを導入すると何故かこのリダイレクトが効かないということに遭遇します。

これもIP制限が上手く動作しないという問題と同じく、アクセスしてきたクライアントがHTTPかHTTPSかを判断する方法が変わってしまったことが原因です。

CDN未使用時はWebサーバーやプログラムが一般的な方法でHTTPかHTTPSかを判別できます。CDN導入時は、CDN→Webサーバー間はアクセスするクライアントがHTTP（S）に関わらず常にHTTPSで通信します。※CDNの仕様によって例外あり

そのため、サーバー側でリダイレクトの判別がうまくいかないのです。

CDNでリダイレクトが効かない場合、X-forwarded-Protoで解決

クライアントIPを判断できるようにするために、X-forwarded-forというヘッダーを使いましたが、クライアントプロトコルを判断する場合、X-forwarded-ProtoというHTTPヘッダーで識別させることによって解決できます。X-forwarded-Protoの中身には概ねクライアントのプロトコル（http/https）が格納されるので、こちらの文字列ベースでリダイレクトルールを記載しましょう。

リダイレクトが効かない、という問題はCDN導入後結構時間が経過してから気づくケースがおおいです。そのため、Webサーバーやプログラムの問題じゃないかと時間をつかってしまうことも散見されますがＣＤＮが影響している場合もあります。導入前にしっかりおさえておきましょう。

DDos保護やWAFが導入されている場合

CDNを導入するオリジン側に、DDos保護やWAF（Web Application Firewall）が導入されている場合注意が必要です。トラブルのケースとして多い例がやはりＩＰベースでのなにかしらの処理を行っている場合となります。例えばクライアントＩＰベースで10秒間200リクエストまで許可しその後持ち点を元に緩和していくというような所謂RateLimitが実装されていると、クライアントIPの判定を前述したHTTPヘッダーなどによって判別する方式に変更頂く必要があります。こちらを行わないとランダムでキャッシュMISSが多い時に何故かエラーになるといった不可解な現象が発生します。

DDosプロテクションが導入されている場合も、CDNからキャッシュ不可能なリクエストが大量に来た際、誤検知を起こしてしまう可能性があります。全てのケースでＷＡＦがある場合はＮＧというわけではありませんが、WAFの仕様をしっかり把握しておくことが重要です。

トラブルはゼロでもWAFの効果もゼロに？

CDNベンダーによって様々ですが、CDN側の仕様でオリジンへのリクエスト時、特定のHTTPヘッダーを透過しない（削除してしまう）ケースがあります。

削除してしまうだけであれば問題ないのでは？と感じられるかもしれません。しかし、WAFの中には特定のHTTPヘッダーをベースに不正アクセスかどうか判定・検知している場合があります。

たまたまWAFで必須のHTTPヘッダーがCDN側の仕様で削除されてしまっていると、前述の2つような見えるトラブルにはならず、WAFが正しく判定できていないという見えないトラブルが発生します。

このようなトラブルを未然に防ぐには、まず導入している・または導入予定のWAFベンダーにCDNとの連携実績があるか、ある場合はどのような点に気をつけたらいいかをヒアリングしましょう。逆にCDNベンダー側でも主なWAF事業者との連携実績をもっている場合があるので、事前に確認しておくのがベストです。

ロードバランサーの配下にあるサイト

さて、まだまだ気をつけることはあります。Webサーバーなどを負荷分散、冗長化する上でロードバランサーを利用することは良くある事だと思います。このロードバランサーでソースIPベースの振り分けを行っている場合、実クライアントIPベースでの判断ではないため偏りが生じてしまう可能性があります。TCP接続毎に独自に均等バランシングを行えるようなパッシブモードの場合はこの限りではありません。またCDNに限らずProxy経由のアクセスも同様となります。

これらの回避策はロードバランサーで判定方法を変えられるのであれば一番早いのですが、もっとシンプルに解決する方法があります。弊社のエッジキャッシュCDNもそうですが、CDN自体にオリジンサーバーを複数登録しておき、ヘルスチェックが通ったサーバーにだけ均等にリクエストする、またはアクティブスタンバイとするような設定を行います。このようにCDNにロードバランシングを任せてしまうと、結果的に誤判定を防ぎ既存のロードバランサーが不要となるため、管理・ランニングコストが削減できるというメリットがあります。

ただし、CDNで実装可能なバランシングは比較的シンプルなTYPEに限定されるため、複雑で高度なバランシングが必須となる環境では素直な置き換えとはいかない場合があります。

CDNで利用できる主なバランシング

CDNで利用できる主なオリジンバランシングは以下の通りです。

・Weight（重みづけ）

設定された重みベースでリクエストを振り分ける

・アクティブスタンバイ

アクティブ側がダウンした場合のみスタンバイにリクエストを振り分ける

・ランダム

ランダムにリクエストを振り分ける

・スティッキーセッション

クライアントIPをベースに同じオリジンサーバーに振り分ける、いわゆるStickyセッション

これら以外にも弊社のエッジキャッシュは少し特殊な振り分け方法が可能です。

・HASHベース

リクエストヘッダーやURLの一部などをつかってHASH化し、このHASHに基づいてバックエンドを固定化します。例えば、HTTPヘッダーやCookieに特定の値が付与されたユーザーはオリジンA、付与されていない場合はオリジンBに固定するといった細かい制御が可能です。

・Failover

先ほどのいくつかの振り分けをベースに、ヘルスチェック機能をプラスすることができます。例えばHASHベースにFailover条件を追加すると、HASHで振り分けを固定しているオリジンがダウンした場合のみ、そのクライアントはFailoverで指定したオリジンにアクセスできます。

このようにCDNで利用できるバランシングは色々ありますが、利用できる機能はシンプルなものから高度なものまで様々です。まずはロードバランサーの分散方法とTYPEを確認し同じ機能が利用予定のCDNにある場合は、CDNで実装してしまいましょう。

CDNで実装できない場合はCDNを経由した時も、ロードバランサー本来の機能が問題なく動作するか確認しましょう。

キャッシュコントロールヘッダーの罠

オリジンサーバー側で今どのようなキャッシュコントロールヘッダーが付与されていますか？と聞かれて、正確に答えられるようであれば、是非弊社で一緒に働きましょう！恐らく大半のシステムがキャッシュコントロールヘッダーを適切に把握し正確に付与しているケースは少ないです。逆にWebサーバーやCMSが勝手にやっている、アプリやインフラにお任せしているというほうが多いのではないでしょうか。CDNを利用する場合、そのようなことではトラブルとなり、効果を最大限発揮できません。

ここでまずすべきことは、キャッシュするコンテンツ・キャッシュしてはいけないコンテンツを把握し、これらに適切なヘッダーが付与されているか、付与されていない場合は付与できるか確認しましょう。オリジン側でのヘッダーの付与が出来ない、という場合はCDNベンダー側の設定で付与したりキャッシュするように設定したりすることも可能です。

キャッシュさせるためには概ねCache-Control Max-age=120などを付与するか、s-maxageを付与してCDNにキャッシュ時間を命令します。逆にキャッシュさせたくない場合は、no-storeなどを付与するというのが一般的です。またブラウザキャッシュと併用する場合はこのようなシンプルな付与では考慮が足りない場合があるため、事前にHTTPヘッダーのことを勉強しておきましょう。

このようにヘッダー1つでCDNの振る舞いはガラッとかるので、決してキャッシュコントロールヘッダーを軽視してCDNを利用してはいけません。キャッシュコントロールヘッダーは最大限効果を発揮させるポイントで、ヘッダーを制したものがCDNを制すといっても過言ではありません。

CDNベンダー独自の設定とルール

CDNベンダーによってどのような条件でキャッシュするのか、しないのかは統一されていません。よって黄色いCDNから赤いCDN（弊社ではなく）に移転したらトラブった、、というケースは大抵CDNベンダーのキャッシュ条件の違いによって引き起こされています。CDNベンダーの独自ルールもしっかり把握しておく必要があります。

初めてCDNを導入する上でのポイントおさらい

わたしたちは、大好きなキャッシュなので楽しい！といえますが、初めて導入を検討している方にとっては安全且つ迅速に効果を体験したいとおもいますし、最低限何を確認したらいいのかなかなか調べても正解がでてこないのではとおもいます。

CDNをトライアルしてはじめて問題に気づき慌てる前に、抑えておくべき事はしっかりおさえておきましょう。弊社CDNの場合、このような注意事項は事前に細かくヒアリングさせていただき、問題となりそうな点はしっかり対策方法をアドバイスするところまで月額定額料金に含まれています。

また、現在他社CDNをご利用中で運用やキャッシュチューニングなどに困っているという方でも、他社CDNのコンサルテーションも実施しております。※ご興味があるかたは公式お問い合わせフォームからご連絡ください。