この記事は AWS Summit 2014 Tokyo 2日目、”Amazon CloudFrontを利用したサイト高速化とセキュア配信”セッションのレポートです。
Cloud Front
北迫清則（アマゾンデータサービスジャパンソリューションアーキテクト）様
メディア・コンテンツ配信系のお客様を担当しています。このセッションの内容はサイトの高速化とセキュア配信のテーマでお話させて頂きます。
Cloud Front とは、コンテンツデリバリーネットワーク、CDNの部類に入るサービスです。世界各国のキャッシュサーバー（エッジサーバー）を効率的に活用してサイトアクセスを高速化するサービスです。
クライアントからEdgeを介してオリジナルサーバー（Origin）にアクセスし、二度目以降はキャッシュからコンテンツを配信する仕組み。クライアント側はレスポンスの向上、サーバー側は負荷の軽減によって、ユーザー体験は向上し、サーバーの台数を減らせる。
クライアントがサイトにアクセスするときにDNSリゾルバからCloudFrontDNSに転送、アマゾンのDNSが位置情報を使い適切なEdgeを返す。世界５２箇所にEdgeがある。日本は東京都大阪に一箇所ずつ。
サイトの高速化
サイトアクセスで裏で起きているのは、HTTPリクエストでDNSルックアップしてTCPコネクションを貼ってGETリクエストをしてレスポンスをもらう…などといった流れになる。そしてCSSやJSや画像を連続して取りに行くことになると思う。
PHPなど動的なサイトが多いと思うので、高速化というとみなさんプログラムの高速化に取り組まれると思う。
しかし20:80の法則というのが有り、動的コンテンツの処理が20で、実は静的コンテンツの取得に残り８０の時間がかかっている。Amazonのサイトの例ですが、このページのコンテンツの取得では２１５リクエストが発生しています。
そこでクライアントからOriginの間にCDNの仕組みを介在させることで高速化が図れる。物理的なネットワークスピードと、レスポンスキャパシティの向上、またEdgeとOriginの通信でも最適化によって高速化が図られる。
通常のアクセスではいくつかのISPを経由することになる。Cloud FrontのEdgeサーバーはその中央のIX（インターネットエクスチェンジ）につながっており、ISPの経由数を減らすことが出来る。
日本やアメリカではあまりCDNを使うメリットがないと言われることがあるが、我々は十分高速化することが出来ると考えている。アクセスが増えてくるとどうしても遅延が発生してくるが、我々は大量にキャッシュサーバーを抱えているのでアクセスが増えても非常に遅延が発生しにくい。
CDNのサービス形態
CDNのサービス形態は、分散型CDNと集中型CDNと言われるものがある。分散型CDNは、ユーザーに最も近い末端のISPの近くに小規模なCDNを大量に置くというCDN。レスポンスタイムが非常に早くなる。しかしそれぞれのCDNの規模が小さいのでキャッシュのヒット率が下がる。
それに対して、中央のIXに大きなCDNを置く集中型にすることで、キャッシュのヒット率は高くなる。過去、分散型が注目されたこともあるが、昨今の回線の安定化などで集中型も注目される状況になってきた。集中型で、ISP間の中央に位置するIXにどれだけ太い回線を出すかが、CDNの性能になってくるかと思う。
可能な限りキャッシュからコンテンツを配信する
静的コンテンツ
静的コンテンツは全てキャッシュさせることで効果を最大化するのはわかり易い例。キャッシュTTLを可能な限り長くし、クライアント側にもキャッシュさせてEdgeにすらアクセスっせないのがわかりやすいパターン。
動的コンテンツ
ページ共通で使われる動的ページや、パーソナライズされた動的コンテンツの２種類あるかと思う。
キャッシュを活用すべき動的コンテンツ
ページ共通の動的コンテンツは、リクエストに応じて動的にページは生成されるが、生成されるページ自体は一定期間共通というもの。例えば商品ページやカテゴリ一覧、人気商品一覧など。
HTTPヘッダー判定によるページの切り替え、例えばUser-Agentによるページの切り替えなど。
こういったものは積極的にキャッシュを活用すべき。動的コンテンツでも一定期間ページ更新が不必要なものは積極的にキャッシュする。日単位、時間、秒単位など。
短いキャッシュスパンで意味があるのかと思われるかもしれないが、更新がなければ（３０４Not Modified）、コンテンツの再取得はしないので効率化出来る。
キャッシュヒット率の向上
- キャッシュ時間TTLを伸ばす。
- URLの共通化（URLごとにキャッシュするから）
- Etag / Last-Modified ヘッダの活用
- （オプション）Query Stringsパラメータ値の固定化（パラメータが完全一致しないと同一キャッシュとしない）
- （オプション）転送対象header値の固定化（Headerも完全一致で確認可能）
取得したデータがどのようにEdgeサーバーから提供されたか、HTTPクライアントでレスポンスヘッダーを確認できる。
- X-Cache:Miss from cloudfront //オリジンから取得
- X-Cache:Hit from cloudfront //キャッシュ有り
- X-Cache:Refresh from cloudfront //オリジン更新なし304
ダイナミックコンテンツアクセラレーション
エッジとオリジン間の通信最適化が可能。
POST、Put、Header、Cookie対応
動的ページを扱う上で前段にCDNがあることでポスト出来ないやHeadを入れられないということでCDNを挟めないなどがあったが、POST、Put、Header,Cookieなどの対応アップデートをしてきた。
クラウドフロントを利用できる動的ページの範囲が広がってきている。そのうえでEdgeとオリジン間の通信最適化が有効になって切る。
Keep Alive
TCPコネクションは３Wayハンドシェイクをしている。これがユーザーごとに同じことが発生する。これをやるとユーザーもサーバー側もリソースを使って負荷がかかる。
これに対してCloudFrontを挟むとどうなるかというと、Edgeとオリジンでコネクションを張り続けるので、2人目以降はEdgeとオリジンのハンドシェイクを省ける。
SSLを使っている場合もっと顕著にスピードの違いが出る。CloudFrontはSSLターミネーション機能もある。
TCPスロースタート
ネットワークの輻輳を回避するために少しずつパケットを増やしながら通信する仕組み。これもユーザーごとにこのプロセスを行う。これが、間にCloudFrontを挟むと、CDNとオリジン間では最初から高速に通信出来る。ｎ
DNS Lookup
CloudFrontはRoute53を使っていて、Route53は世界52カ国に拠点がある。リゾルバに一番近いDNSが応答するのでRout53を使うだけで高速化する。
レコードセットのTypeをCNAMEではなくAレコードのAliasを利用することでリクエスト回数の削減が可能。
CNAMEを使うとCNAMEで帰ったドメインをもう一度問い合わせることになる。AレコードのAliasを使うと直接クラウドフロントになる。
アクセス高速化まとめ
物理ネットワーク速度、Edgeキャパシティ、オリジンとの通信の最適化、DNSクエリによって、動的ページの生成速度の他に、サイトを早くする施策を打つことが出来る。
静的・動的コンテンツの混在環境に於ける活用
URLごとに異なるポリシーを適用可能。正規表現で分けてTTLを設定したりできる。ある程度コンテンツごとにキャッシュ時間のコントロールが可能。
セキュア配信
- HTTPSサポート
- GEOリストリクションRestriction特定地域からのアクセスのみ許可
- Signed URL（署名付きURL）
Signed URLがわかりにくいと思いますのでこちらをご説明します。
Signed URL（署名付きURL）
有効期限を設定したワンタイムのURL生成。アクセスコントロールサーバーがCloudFrontに期間指定URLを生成して配信コンテンツを保護する。
Originへの直接アクセスは、例えばS3であれば、オリジンアクセスIdentityを使うと、特定のCroudFrontからしかアクセス出来ないように出来る。
またクラウドフロントのIPは公開されているのでそのIPのみ許可することでOriginのコンテンツを保護できる。
2種類のポリシーがある。
既定ポリシー
アクセス有効終了時刻、許可コンテンツフルパス
カスタムポリシ
- コンテンツ有効開始時刻・終了時刻
- アクセス元IPアドレス制限
- 許可コンテンツパスワイルドカード指定（特定ディレクトリ配下やパターンに署名を使いまわせる。）
ポリシー定義をJSONフォーマとの文字列で準備
AWSアカウントごとのCloudFront用秘密鍵で文字列を暗号化
こんてんつURLのQueryStringsにパラメータとしてセット
利用シーン
プレミアムコンテンツ配信（ダウンロード配信、ストリーミング配信）など。コンテンツに対して複雑な保護処理を施さなくても簡単かつセキュアに配信可能になる。
Tips
有効時間の設定目安：ダウンロードコンテンツに関しては、ダウンロードのコネクションを張っている最中は切れないので、コネクションを張るまでの時間だけで良い。
ストリーミング：継続的にアクセスが発生するので、映像・音声の再生時間＋αで設定。
アクセスURLの正規表現を利用して特定のコンテンツのみ Signed URL で保護することが出来る。
アクセス
HTTPSと場合によってはRestrictionとの組み合わせ
キャッシュの有効活用
キャッシュコンテンツにもSignedURLは有効。
Cloud Frontの活用
- インフラアプローチによるサイト高速化の実現
- 動的コンテンツに関してもCloud Frontをうまく活用
- セキュアなコンテンツ配信も容易かつ高速化が可能
ちりも積もればサイトは早くなる。