Networkの略でウェブコンテンツの配信を高速化する技術です。当サイトもページ表示速度高速化のためCloudFrontを導入しようと検討してみたのですが、サイトの構成上難しい部分もあって一旦断念しました。まとめ|ネイキッドドメインでのCDN適応方法を探すページロード速度が速いサイトを目指す2016年5月に開設した当サイトは順調にアクセスが増えており、2016年10月のアクセス数には10,000PV程になりました。このままPVは順調に増えていくと思いますが、現在のWordpressはプラグインを多用しているためかページ表示速度が遅いという問題が発生しています。本サイトはゆとりずむさんのブログ分類によると「情報提供型」に最も近いので、本サイトの基本戦略はロングテールを主軸としたコンテンツ作りと、検索流入を対象としたSEO、関連するコンテンツへの回遊率を上げるとしています。(実際アクセスのほとんどは検索流入です)月間10,000PVのアクセス量なら503エラーになることはありませんが、ページの表示速度が遅くなってしまうと、それだけで直帰率の上昇等様々な悪影響があります。Insightsではサーバー応答速度が2秒以上、ページ全体の読み込み平均10秒と非常に遅いサイトになっています。ページ表示速度を高速化させる方法にはなにがある?ページ表示速度の高速化には様々な方法がありますが、ページ表示速度を上げる方法には「Webサイトを軽量化する」「サーバーを増強する」という2つの方法に分類できます。これまで当サイトでは、ページ高速化のため陰ながら様々な改善を実施していました。KUSANAGIに移行しましたCDNの導入(今回の本命)サーバーのコンテンツを別のサーバーにキャッシュし、そこから読み込ませることでサーバーの負荷を下げる技術。本サイトは静的なwebコンテンツがほとんどなので、効果は十分見込めそう。私はPHPやJavaSprictを殆ど触ったことない人間なので、現時点でコードの縮小やjQueryについて適切な対応をとることができません。なると現時点ではサーバーを増強するしか手段がないのですが、サーバーを借りるのもタダではありません。一応、アドセンスやアソシエイトは設置していますが、ノービスクラスの本サイトの広告収入額では現在のサーバー環境の維持で手いっぱいです。プレミアムやVPSへの移行は厳しめです。このような問題点に対して、最も簡素かつ期待できそうなのがCDNの導入です。CDNについて簡単に解説さて、CDNとは具体的にどのようなサービスなのでしょうか。Network)と言います。いった面で大きなメリットがあります。導入の効果の感じを聞くとブロードバンド時代(この単語も既に死語ですね)の先端技術な感じもしますが、CDNは90年代のダイヤルアップ時代に考案された実績のある技術です。肝心のCDNの仕組みは、ざっくりと言ってしまえば単にキャッシュしたファイルを配信するだけの技術です。CDNが通常のサーバーと異なるポイントは「最も近い場所にあるサーバーを自動で選択し配信する」という事です。単純に距離が近いという事は応答速度が速くなるという事とほぼイコールとも言えます。CDNを提供するサーバーは帯域も広く、コンテンツの高速配信と素早い応答速度が期待できます。本サイトは変化の少ない動的コンテンツで満たされているサイトですので、これを静的コンテンツ的な扱いにしてCDNで配信させてしまえば大幅なページ速度向上が見込まれます。一般的な構成(左)では、1つのサーバーに各ユーザーが直接アクセスするため負荷が高くなる。これをCDN経由に変更(右)すると負荷が分散され高速化が期待できる。コンテンツだけをCDNにキャッシュさせるCDNにも様々な運用方法があります。その中で最も簡単な方法はテキストデータとコンテンツを別々に配信する方法です。帯域の狭いサーバーでは画像や動画などの大きなファイルの転送に時間がかかります。それらの重いファイルだけでもCDNから読み込ませるようにすればページの表示速度を向上させることができます。サーバー側での操作が殆どなく、htmlファイルの画像リンクの書き換えや専用プラグインの導入などで対応できるため、導入が非常に簡単であるという利点があります。この方式はwebコンテンツそのものは本来のサーバーから読みに行く方法のため、今回のようにサーバー応答速度が遅い場合には効果がありません。画像や動画など、重いデータをS3バケットに保存し、配信をCloudFront経由で行うことでページ表示時間の改善が望める。この方法はリンクの書き換えやプラグインの導入で対応できる。サーバーを丸ごとCDN経由で配信するもう1つのCDN運用方法がサーバーの内容をCDNキャッシュさせて配信する方法です。配信を全てCDNから行うため、高速なCDNバックボーンの恩恵を受けられる上、サーバーがダウンしても一定期間はCDNからコンテンツが配信されるため対障害性も確保することができます。この方法ではCDN導入が多少複雑になり、DNSの設定を変更させてCDNサーバーを経由させる必要があります。欠点としてはWebページを丸ごとキャッシュしてしまうため、頻繁に内容が変わるwebコンテンツの場合更新内容がすぐに反映されないことがあります。今回は、この方法でCDNを導入します。全てのデータをCDNから配信方法。CloudFrontを導入CDNを提供しているサービスはいくつかあります。Service(AWS)のCloudFrontを使う事に決めました。参考:CDN国内パフォーマンス比較(2016年9月)この2点を理由に、まずはAWSの無料期間が終わるまでCloudFrontを試用してみることに決めました。サブドメインでテスト環境を構成してCloudFront導入テストCDN導入は初めての試みである事や、自身のネットワーク知識が乏しい所もあるため、いきなり本番環境でのCDN導入はトラブルが発生して取り返しのつかないことになってしまいそうです。そのため、まずはテスト環境を作って動作確認を行います。サブドメインでテスト用環境check.voltechno.comを構成して、本番環境に見立ててWordPressを導入します。このURLを変えることなくCDN経由でコンテンツを配信させることができれば、本番環境でもうまくいくはずです。どの段階でどの作業を行ったのか確認するため、この段階での構成図を下記に示します。(DNSサーバーの存在は省略)CDN導入前のテスト環境の状態。オリジンのドメインを変更それではCloudFrontを使ったCDNの構築に入ります。このままCloudFrontにcheck.voltechno.comへアクセスする設定を記述しても、Aレコードで割り当てられているオリジンサーバーへのアクセスが優先されてしまいます。そのため、オリジンサーバーのアドレスをcheck2.voltechno.comに変更します。CDNサーバーにcheck.voltechno.comでアクセスさせるために、オリジナルのサーバーはcheck2.voltechno.comに変更する。(WordPress内の設定に変更は加えない)CloudFrontの設定AWSのアカウントを作ってCloudFrontの設定画面を開きます。AWSはマネジメントコンソールの画面を通じて様々なサービスにアクセスできる。今回はストレージ&コンテンツ配信のリストからCloudFrontを選択する。Startedボタンを押す。Settingsオリジンサーバーの情報を設定します。Name:オリジナルコンテンツのサーバーアドレス、オリジンのアドレス(check2.voltechno.com)を入れる。Path:ディレクトリの設定。Headers:カスタムヘッダーの付与。Settingsキャッシュとその他情報を設定します。Caching:コンテンツのキャッシュ時間。Headersを選ぶとサーバー側の設定が適応される。Cookies:Cookieをオリジンサーバーに転送するか。Class:エッジロケーションごとの価格を指定。Names(CNAMEs):独自ドメインの指定。Object:空欄Logging:ログ機能。State:そのままBehaviors基本設定はこれで終わりましたが、このままではWordPressの管理画面などにログインできません。管理画面にアクセスできるよう設定を追記する必要があります。Settingsボタンを押す。Behaviorを押す。TTL時間を0にすることにより常にオリジンサーバーを読み込むようになります。Patternを*.phpに変えて同じものをもう1個登録します。これで管理画面(wp-admin)とphpにアクセスする時は常にオリジンサーバーに直接アクセスできるようになりました。設定完了StatusがInProgressとなり設定の反映が始まります。完了には大体20~30分ほどかかります。Name上に記載されているアドレスにアクセスできるようになります。Nameにアクセスするとサイトが表示されるようになります。キャッシュされたものかオリジンに読みに行っているものかはわかりませんが、とりあえず動いてはいるようです。Nameであるd1b4b01g7urm8z.cloudfront.netをCNAMEでcheck.voltechno.comに割り当てて全て完了です。(DNSの反映には最大2日ほどかかる場合もあります、気長に待ちましょう)下がテスト環境下でのCDN導入完了状態を図式化したものになります。CDNへの導入が完了した状態。check.voltechno.comにアクセスするとキャッシュがあればCDNから配信、CDNにキャッシュがなければcheck2.voltechno.comから配信される。どのような場合でもユーザーはcheck.voltechno.comから常にコンテンツが配信されているように見えるこれでユーザーから見たアドレスを変えることなくWordPressをCDN経由のアクセスに変更することが出来ました。同じ手順を踏めば本番環境でもCDNへの移行ができるはずです。CloudFrontのページ表示速度を確認するCDNでキャッシュ取得も出来ているようなのでGTmetrixでサイトの表示速度を比較してみます。オリジンサーバーのcheck2.voltechno.com。サブドメインの同一サーバーだとしても、余計なものが入ってない分WordPressの動作は早いです。それでもサーバーの応答速度は1秒近くありますが。次がCloudFront経由であるcheck.voltechno.comの測定結果。うおぉすごい早いぞコレ。Timeが1/5になってる!ここまで早いとは思わなかった!!Amazonのサーバーってスゲェ!!!そんなわけで予想以上の結果が得られました。本サイトにもCloudFrontを導入すればかなりのサイト表示速度の改善が期待できそうです。いうわけで本番環境導入へ進みます本番環境でのCloudFront設定、しかし...さて、本番環境でのCDN導入ですが、結論から言うと本サイト(voltechno.com)のCloudFront導入は一旦中止することとしました。原因は本サイトのURLをネイキッドドメインにしていたためです。CDNとネイキッドドメインは相性が悪い本サイトのURLはvoltechno.comにしています。このようなアドレスの先端に何もついていない形式のドメインはネイキッドドメインと呼ばれます。Domainとも呼ばれます)さて、このようなネイキッドドメインの扱いについて、RFC1912では下記のように記されています。サーバと悪い不具合に衝突するでしょう。→参考:CNAMEの間違った使い方つまり、ネイキッドドメインはCNAMEレコードで使っちゃいけないよ、だそうです。実際のところ設定してしまえば動くらしいですが(sendmailで不都合は起こるそうですが)、このドメイン利用を後々どこまで広げるかわからないので、変なことはしないでおきます。今回、なぜドメインの先端にwwwっていうサブドメインをつける必要があるのかよくわかりました。サブドメインをつけておけば色んな事が楽になるんですね。まとめ|ネイキッドドメインでのCDN適応方法を探す今回はドメインの制約に引っかかってしまいCDNの導入は一時見送りとしました。「一時見送り」なので再びCDN導入するつもりです。調べてみると、このネイキッドドメインにCDNを導入する問題については何個か解決方法があるようです。ネットで見つかった限りでは、「リクエスト全てをサブドメインに転送する設定をウェブサーバーに組み込む」とか、「CDNをCloudflareに変える」とか、「ネームサーバーを別のところに変える」とか、色々と方法はあるようです。次回挑戦して上手くいったら追記報告したいと思います。今回CDNについていろいろやってみましたが、私自身ネットワーク系の知識に疎いほうの人間です。この記事の内容にしても「CloudFrontの設定がよくない」とか「CDNの解釈が間違っている」とか「そもそもDNSの理解が乏しい」などがあるかもしれません。いうかありますもし何かに気付いたり間違い指摘、参考リンクの提示などがあれば、Contactからアドバイスいただけるとありがたいです。(解決しました)ちょっと話は変わって、今回のCloudFrontの導入にのために初めてAWSを使ってみたんですが、すごいですねAWS。現在、使用しているホスティングはgoogleやさくら・AWSと色々分散してしまっているのですが、ちょっと頑張れば全部AWSでまとめることが出来そうです。IoTも興味深いです。Webコンテンツのほぼ全てAWSで済んじゃうじゃないですか。役立つ情報を発信するサイトです。