Aws summits2014 amazon_cloudfrontを利用したサイト高速化とセキュア配信
- 1. © 2014 Amazon.com, Inc. and its affiliates. All rights reserved. May not be copied, modified, or distributed in whole or in part without the express consent of Amazon.com, Inc. Amazon CloudFrontを利用した サイト高速化とセキュア配信 Kiyonori Kitasako Solutions Architect, Amazon Data Service Japan 2014.07.18 Session #TA-06
- 2. 自己紹介 •名前 北迫 清訓 (きたさこ きよのり) •所属 アマゾンデータサービスジャパン ソリューションアーキテクト •仕事 メディアおよびコンテンツ配信系のお客様を主に担当 コンテンツ配信、アーカイブなどの案件に従事
- 3. Agenda 1. Amazon CloudFront CloudFrontによるサイト高速化 CloudFrontによるセキュア配信 まとめ 2. 3. 4.
- 5. Contents Delivery Network •世界中にあるエッジのキャパシティを活用して高速かつ効 率的にコンテンツを配信可能なサービス –ユーザからのアクセスを最も近いエッジサーバに誘導 することでユーザへの配信を高速化 –エッジサーバでは、コンテンツのキャッシングを行い、 オリジンサーバに負荷をかけずエッジから直接配信
- 6. Contents Delivery Network オリジン Amazon CloudFront レスポンス向上 負荷軽減 リクエスト 配信 リクエスト キャッシュから配信 キャッシュ コンテンツ取得 CDNサービス クライアント オリジンサーバ 台数の削減 ユーザ体験の 向上
- 7. Contents Delivery Network • 最適なエッジへの誘導 Amazon CloudFront クライアント Internet 位置情報DB ①ドメイン名問い合わせ CloudFront DNS Edge Location ②IPアドレス問い合わせ (xxx.cloudfront.net) ③最適なEdgeアドレス応答 ④最適なEdgeへアクセス ⑤キャッシュがなければ オリジンから取得 DNSリゾル バ オリジン
- 8. Global Edge Locations Europe Amsterdam, Netherlands(2) Dublin, Ireland Frankfurt, Germany (3) London, England (3) Madrid, Spain Marseille, France Milan, Italia Paris, France (2) Stockholm, Sweden Warsaw, Poland Asia Chennai, India Hong Kong, China(2) Manila, Philippines Melbourne, Australia Mumbai, India Osaka, Japan Seoul, Korea Singapore (2) Sydney, Australia Taipei, Taiwan Tokyo, Japan(2) South America Sao Paulo, Brazil Rio de Janeiro, Brazil North America Atlanta, GA Ashburn, VA (3) Dallas, TX (2) Hayward, CA Jacksonville, FL Los Angeles, CA(2) Miami, FL New York, NY (3) Newark, NJ Palo Alto, CA San Jose, CA Seattle, WA South Bend, IN St. Louis, MO 2014年07月時点 52 Edge Locations
- 10. Webアクセスの高速化 クライアント 215 request DNS Lookup TCP Connection Send Receive index.jsp style.css hoge.js itme1.png item2.png HTTPリクエストにおける 80：20の法則 20 8 0
- 11. Webアクセスの高速化 DNS Lookup TCP Connection Send Receive クライアント クライアント CloudFront 物理的な NWスピード 通信の最適化 レスポンス キャパシティ オリジン オリジン
- 12. ISP ISP IX ISP CDN Edge Locationの活用 クライアント DC AWS region AWS edge AWS edge IX/Teir1 • 物理的なネットワークスピード（距離） キャッシュ オリジン
- 13. CDN Edge Locationの活用 クライアント DC AW S edg e VS Edge Capacity • レスポンスキャパシティ サーバキャパシティ ネットワークキャパシティ オリジン
- 14. CDN Edge Locationの活用 クライアント 分散型 CDN 集中型 CDN ISP ISP IX ISP ISP クライアント Edge Edge Edge Edge クライアントに 近いエッジ キャッシュヒット 率が高い VS ISP IX AWS edge キャッシュ共有 ISP ISP ISP AWS edge
- 15. CDN Edge Locationの活用 CloudFrontのEdgeに 可能な限りキャッシュ させることが重要
- 16. CDN Edge Locationの活用 •可能な限りキャッシュからコンテンツを配信 静的コンテンツ 動的コンテンツ HTTPリクエストにおける80：20の法則 80 20
- 17. キャッシュの活用 • 画像ファイル • 動画ファイル • CSS • Java Script • 静的HTML キャッシュTTLも可能な限り長く クライアント側にもキャッシュさせる • 静的コンテンツは全てキャッシュさせることで CDNの効果を最大化
- 18. 動的コンテンツ 動的コンテンツ(ページ共通) 動的コンテンツ(パーソナライズ) 動的コンテンツ
- 19. キャッシュの活用 • 動的コンテンツ(ページ共通) リクエストに応じて動的にページ生成は行われる が、生成されるページ自体は一定期間共通 /item/ContentsDetail?item_id=012345 (商品詳細) /api/ListCategory?category=cloud (カテゴリ一覧) /api/ListContents?top=10 (人気商品一覧) 例えば Query Stringsを活用している
- 20. キャッシュの活用 • 動的コンテンツ(ページ共通) HTTPヘッダー判定によるページ切り替え 例えば User-Agentを見てクライアント端末に適したページを応答
- 21. キャッシュの活用 動的コンテンツでも 一定期間ページ更新が不必要なものは 積極的にキャッシュ 日単位 時間単位 分単位 秒単位 Cache-Control Header と Minimum TTLで調整
- 22. キャッシュの活用 • 短期間でのキャッシュの更新 クライアント CDN Edge オリジン Last-Modified キャッシュ(短期) /ETagヘッダー キャッシュ(期間切れ) If-Modified-Since 更新なし キャッシュの再利用 304 (Not Modified) 最適化された通信 更新あり
- 23. キャッシュヒット率の向上 •ヒット率向上のための要素 –キャッシュ時間 –URLの共通化 –Etag / Last-Modifiedヘッダーの活用 –(オプション)Query Stringsパラメータ値の固定化 –(オプション)転送対象Header値の固定化 CloudFrontは完全一致でキャッシュを共有
- 24. キャッシュヒット状況の確認 > curl --head http://dxxxx.cloudfront.net/index.php HTTP/1.1 200 OK Content-Type: text/html; charset=UTF-8 Date: Wed, 16 Jul 2014 07:34:38 GMT Server: Apache/2.2.26 (Amazon) X-Powered-By: PHP/5.3.28 Cache-Control: no-store X-Cache: Miss from cloudfront X-Amz-Cf-Id: fhHLqZdhWY1Y8ea8feo-MRFCP2g1mdO8MzIrzi3Fgu2X3GtMNxyYhA== > curl --head http://dxxxx.cloudfront.net/index.php HTTP/1.1 200 OK ： X-Cache: Hit from cloudfront X-Amz-Cf-Id: -ZS2M7j2qsW5fOEPCrMlyx2jo5pRvi7altuyN1hwFQxUZOeog6Axng== •HTTPクライアントでレスポンスヘッダーを確認 > curl --head http://dxxxx.cloudfront.net/index.php HTTP/1.1 200 OK ： X-Cache: RefreshHit from cloudfront X-Amz-Cf-Id: HbXR9PvZ_JjOa3xFuzZ41DqImkqDkDU84Gxn5of0zUobVjY0956hXg== オリジン キャッシュ キャッシュ再利用
- 25. CDN Edge Locationの活用 キャッシュができない 動的ページはEdgeを プロキシとして利用
- 26. 動的コンテンツでの活用 •Dynamic Contents Acceleration CloudFrontによる最適化されたOriginとの通信 •POST/PUT, Header, Cookie対応 •Keep-Alive Connection •TCPスロースタート
- 27. POST/PUT, Header, Cookieの対応 キャッシュできない動的コンテンツ •POST/PUTリクエストはPROXYとして動作 •OriginへのHeaderやCookie情報の転送 Cloud FrontのEdgeを経由させても 多くの動的ページが扱えるように その上でEdgeとOrigin間通信の最適化
- 28. Keep-Alive Connection クライアント SYN SYN- ACK ACK オリジン GET /index.jsp SYN- ACK ACK GET /index.jsp SYN USER 1 USER 2 • 従来のTCP Connection Webサーバ オリジンへの負荷が増加 30ms 120ms 120ms TCP 3 Way Handshake DNS Lookup TCP Connection Send Receive
- 29. Keep-Alive Connection CDN Edge クライアント SYN SYN- ACK ACK GET /index.html SYN- ACK ACK GET /index.html SYN USER 1 USER 2 10ms 120ms 60ms SYN SYN- ACK ACK GET /index.jsp 20ms GET /index.jsp Keep-Alive HTTPS通信の場合 もっと顕著な差が CloudFrontで SSL Termination • CloudFrontによるKeep-Alive Optimization オリジン
- 30. TCPスロースタート クライアント Packet 1 ACK Packet 1 オリジン User TCP Slow Start Packet 2 Packet 3 Packet 3 ACK Packet 4 Packet 5 Packet 6 Packet 7 • ネットワークの輻輳を回避 するために少しづつパケッ トを増やしながら通信する 仕組み ユーザの新規TCPコネクション毎に発生 DNS Lookup TCP Connection Send Receive
- 31. TCPスロースタート • CloudFrontによるTCP Slow Start Optimization USER 1 オリジン TCP Slow Start Packet 1 ACK Packet 1 Packet 2 Packet 3 Packet 3 ACK Packet 4 Packet 5 Packet 6 Packet 7 CDN Edge USER 2 オリジン Packet 1 Packet 2 Packet 3 Packet 4 CDN Edge Packet 4 ACK Packet 5 Packet 6 Packet 7 Packet 8 既存のコネクションを流用するため スロースタートシーケンスをバイパス
- 32. DNS Lookupの高速化 •ホストの名前解決にRoute53を活用 CloudFrontはAlternative Domain Name Originの名前解決にも DNS Lookup TCP Connection Send Receive Amazon Route53 •世界52箇所にDNSサーバを配備 •Anycastを利用してレイテンシー が低いDNSが応答
- 33. DNS Lookupの高速化 > Nslookup cdn.awssummit.co.jp Server: 192.168.2.1 Address: 192.168.2.1#53 Non-authoritative answer: Name: cdn.awssumit.co.jp Address: 54.230.234.XXX Name: cdn.awssumit.co.jp Address: 54.230.234.XXX Name: cdn.awssumit.co.jp Address: 54.230.235.XXX : •CloudFrontのAlternative Domain NameをRoute53を利 用して名前解決する際は、レコードセットのTypeを CNAMEではなくAレコードのAliasを利用することで クエリ回数の削減が可能 > nslookup cdn.awssummit.co.jp Server: 192.168.2.1 Address: 192.168.2.1#53 Non-authoritative answer: cdn.awssumit.co.jp canonical name = dxxxx.cloudfront.net. Name: dXxxx.cloudfront.net Address: 54.230.234.XXX Name: dXXXX.cloudfront.net Address: 54.230.234.XXX : CNAME A Recode + Alias cdn .awssummit.co.jp.
- 34. Webアクセスの高速化 DNS Lookup TCP Connection Send Receive クライアント オリジン CloudFront Route53 Route53 • 物理的なネットワーク速度 • エッジキャッシュおよびキャパシティの活用 • オリジンとの通信の最適化 • DNSクエリ
- 36. CloudFront Behaviorの活用 img/* api/cache* * Behavior Cache TTL http://www.aws.com/ (正規表現) オリジン Cache-control: no-cache, no-store クライアント img/item01.jpg api/cache-itme?id=10 index.jsp AWS MC • URL毎に異なるキャッシュポリシーを適用 動的ページは Custom TTL 30 Days Custom TTL 10 min Use Origin
- 38. CloudFrontのセキュア機能 •HTTPSサポート •GEO Restriction •Signed URL（署名付きURL）
- 39. Signed URLとは • CloudFront経由で配信するコンテンツに対して 期間指定URLを生成することで、配信コンテン ツを保護する機能 クライアント CloudFront Signed URL有効 署名確認 Webサーバ Amazon S3 オリジン Origin Access Identity(OAI) 接続元IP制限 オリジンへのダイレクトアクセス 認証サーバ CloudFront 署名付きURL発行 秘密鍵
- 40. Signed URLの仕組み •指定可能ポリシー カスタムポリシ(Custom Policy) •アクセス有効開始・終了時刻 •アクセス元IPアドレス制限 •許可コンテンツパスワイルドカード指定 既定ポリシ(Canned Policy) •アクセス有効終了時刻 •許可コンテンツフルパス
- 41. Signed URLの作成方法 1.ポリシー定義をJSONフォーマットの文字列で準備 2.AWSアカウントのCloudFront用秘密鍵で文字列を暗号化 3.コンテンツURLのQuery Stringsにパラメータとしてセット https://dxxx.cloudfront.net/secure/media01.mp4? Signature=Yana7RByw30iPHZQzFKIyqoAsLHMPPeZ~w- 7RPuHeVTY06VDgnW7MbNjQSbGkHn9kWPdlFAWCX7g1q9Mk5kORLXMcJwCOCm165~P6ss9Bj8rMmYNoIj96u7Nm3xzwbFHfCf5WyafA6aX1PoQ2Vgod98TZVhHGuTdA-IuiMz6Ly8_ &Policy=eyJTdGF0ZW1lbnQiOlt7IlJlc291cmNlIjoiaHR0cHM6Ly9kMWJ3amwwb3JteW9veC5jbG91ZGZyb250Lm5ldC9obHMvKiIsIkNvbmRpdGlvbiI6eyJEYXRlTGVzc1RoYW4iOnsiQVdTOkVwb2NoVGltZSI6MTM5NDI0NjMwM319fV19 &Key-Pair-Id=APKAIZ4RI4PUMO3SNKLQ CloudFront用秘密鍵があればどこでも URLの生成が可能
- 42. Signed URLの利用領域 •プレミアムコンテンツ配信 –ダウンロード配信 (ゲーム, 映像, 音声, データ) –ストリーミング配信 (映像, 音声) 既存認証システムと連携し コンテンツに対して複雑な保護処理を 施さなくても簡単かつセキュアに配信 CloudFrontの設定と既存認証システム でのURL生成機能の実装のみ
- 43. Signed URL Tips •アクセス –HTTPSと場合によってはGeo Restrictionとの組み合わせ •CloudFrontの設定 –Behavior毎にSigned URLの有無が指 定可能 –アクセスURLの正規表現を利用し Distributionを分けなくても特定のコ ンテンツのみ保護可能 •キャッシュの有効活用 –キャッシュされたコンテンツにも Signed URLは有効 –クライアントにキャッシュさせたくな いコンテンツは、Cache-Controlヘッ ダーのno-cache, no-storeと CloudFrontのCustom TTLで調整 •有効時間の設定 –ダウンロード時は有効時刻を短く設定 –ストリーミングは映像・音声の再生時 間+αを設定
- 44. まとめ
- 45. CloudFrontの活用 •インフラアプローチによるサイト高速化の実現 •動的コンテンツに関してもCloudFrontを上手 く活用 •セキュアなコンテンツ配信も容易かつ高速化が 可能 チリも積もれば速くなる
- 46. http://csd.awseventsjapan.com/ 2014.09.09 SAVE THE DATE 検 索 Cloud Storage & DB Day