インフラ

「mikuexpo.com」Amazon CloudFront 導入備忘録

LINEで送る
Pocket

【はじめに】
海外向け初音ミクイベント告知サイト「mikuexpo.com」において、
下記を目的に、Amazon CDNサービス「CloudFront」を導入した技術記事です。

  • 海外からのページ表示速度改善
  • サーバ&ネットワーク高負荷対策

【目次】
(1)要件定義
(2)要件を満たす導入施策
(3)利用にあたって
(4)導入手順
(5)キャッシュ生存期間の注意点
(6)さいごに


既にインドネシア公演が終わり、先日次回開催地決定のお知らせさせて頂きました。
次回開催国は米国、場所はロスとニューヨークです。

今後、他国でも開催する可能性があるのと、下記要件定義としての改善も早くから適用したい事もあって、
「CDNソリューション」(以下、CDN、キャッシュサーバ。)を導入する事と致しました。

(1)要件定義

  1. ページ表示速度の改善
  2. オリジナルサーバは日本に存在、告知したいユーザ層は地域的に距離が離れている

  3. サーバ&ネットワーク高負荷対策
  4. 同日同時刻にSNSやWEBやメールでお知らせを展開、海外ニュースサイトへ掲載される事によるアクセス過多への対策

  5. 運用保守の軽減
  6. 上記2点をクリアするにあたって費用対効果が現実的である事と、障害で起こされること無く私自身ゆっくり寝れるという事

(2)要件を満たす導入施策

    本ケースの場合、比較的に簡単な対応策としてCDNを利用することで改善されます。
    CDNを採用する事で、エッジサーバと呼ばれる分散サーバが定期的にオリジンサーバへコンテンツを参照し、キャッシュする。DNS設定により公開したいFQDNをエッジサーバ(キャッシュサーバ)に設定する事で、アクセスユーザは地域的に近くのエッジサーバへアクセスし、オリジンサーバへのアクセス負荷軽減が実現できるという仕組み。
    CDNといえば、Amazon CloudFront(以下、CF。)、akamaiCDN(以下、akamai。)、IIJGIOコンテンツアクセラレーションサービス(以下、IIJGIO-CA。)など既知ですが、コスト的には以外にIIJGIO-CAが安価でしたが現時点で海外にエッジサーバが無いという理由から、CFを利用する事に至りました。

    # 海外向けでなく日本向けの配信であれば、IIJGIO-CAが完全転送量課金で「\15/1GB」と安価でオススメです。akamaiは、契約には代理店経由での個別対応となりそうですがCDN性能としてはエッジサーバ数も豊富で帯域品質、レスポンス速度も良く、中大規模向けと認識しています。

(3)利用にあたって

    「mikuexpo.com」は、自社サーバ、独自ドメイン。コンテンツも静的コンテンツが占めていてS3に再配置しても良かったのですが、運用手間は掛けたくないので、極力サーバ設定やコンテンツは変更したくありませんでした。但し、CFを導入設定するにあたっては、オリジンサーバがサブドメインとして適用されているFQDNでなければなりませんので、適当にサブドメインを設定する必要がありました。

    しかし、今設定してしまうとアクセス出来なくなる可能性があるので、設定手順に注意が必要です。
    また、サイトのコンテンツ仕様としては、FQDN全てに対してキャッシュを有効にしても良いという事も確認し、後に仕様変更として動的なコンテンツが適用となったとしても、CFでPOSTスルーを有効するか、明示的に任意のPATHを除外し対応する事ができるという事も事前調査として問題なかったので採用する事に至りました。

(4)導入手順

  1. DNSに「mikuexpo.com」に対しサブドメインを追加設定
  2. 「例) Aレコード: origine.mikuexpo.com」

  3. アクセスログ出力の為、事前準備
  4. ログ出力用領域(Log Bucket)を S3 に作成

  5. CF「Create Distribution」にてキャッシュサーバを生成
  6. Alternate Domain Names (CNAMEs): mikuexpo.com
    Origines: origine.mikuexpo.com

  7. これでCFインスタンス作成されるが、「Status: InProgress」となり有効となるまで約15-30分掛かる。「Status: Deployed」になったら、下記「Domain Name」にアクセスして、オリジンサーバのコンテンツがキャッシュされている事を確認し、問題なく表示されていれば、正常にキャッシュされている事が確認できる。
  8. Domain Name: hogehoge.cloudfront.net

  9. 公開FQDNのAレコードを生成したCFのDomain Nameに設定
  10. 「例) Aレコード(エイリアス): hogehoge.cloudfront.net」
    DNS情報が伝播する事で、CDNが有効となる。予めTTL値は最短にしておく事。

(5)キャッシュ生存期間の注意点

    キャッシュサーバは、比較的導入しやすく、アクセス、負荷を軽減してくれる便利なサービスですが、WEBコンテンツの特性上、場合によってはページ表示で不整合を起こす事もあります。それは、キャッシュには生存期間があるという事。
    更新が多いサイトでは、明示的に「このコンテンツはキャッシュしてはいけませよー」という設定を行わないと、htmlは変わったけど、コンテンツ毎の時差によって、cssやimagesデータが新しい、若しくは古いという事となり、ページが新しいコンテンツと古いコンテンツが混じった状態にもなりかねません。
    まして、CFのデフォルトキャッシュ生存期間は24時間なので注意が必要です。
    ※CFのキャッシュ仕様についてはこちらに記載があります。(amazon docs)

そこで、CFにおける、キャッシュコントロールの有効案として。

  1. CFの「Distribution」設定のTTLを最小にする
  2. 最短で3600秒を設定する事が可能。

  3. CFの「Invalidations」機能を活用
  4. 上記設定で間に合わない時(早くキャッシュクリアしたい場合)に、明示的にキャッシュクリアのリクエストを行なう事ができます。但し、適用されるまでに約10-15分程掛かります。

  5. Rename Distributionパターン活用
  6. 更新ファイルを新しいファイル名で公開する。

  7. URL後ろに任意のクエリー文字列で対応
  8. クエリー文字列を付加することで、更新時にキャッシュからロードしないという方法

  9. オリジンサーバでキャッシュ生存時間を制御
  10. HTML meta情報、HTTPヘッダー情報に明示的に記載する事。
    気をつける点としては、text/* ,image/* 等があるのでHTMLの対応だけでなく、ブラウザプラグイン等でHTTPヘッダー情報について注意すると良いでしょう。

-> html meta

-> httpd config

-> nginx config

 
# js, png, ico, …などもありますので他のファイルについても注意下さい。

(6)さいごに

    今回CF導入については、オリジンサーバをまるごと&サブドメイン無しでFQDN名を変更せず採用した事についての内容でした。CDNの導入方法は多々あり、画像、音声ファイルのみ採用されているケースをよく確認する事があります。※事前に公開しているページや画像をブラウザのプラグイン等用いて読込速度を計測しながら導入計画すると効果測定できて良いのではないでしょうか。

    導入工数ですが、既にオリジンサーバが運用している場合、CFを導入するにあたっての実質作業時間としては約1時間程度で導入可能です。※但し、サイト、サービス仕様にもよります。DNSのTTL値も考慮の上、事前にダミー環境等で十分検証する事をオススメ致します。

    # 本ブログ記事、「mikuexpo.com」以外のFQDN名は設定例の為、架空のFQDN名にて説明しています。ご了承下さい。

mikuexpo