PowerPoint Presentation

© 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

自己紹介

• 名前

北迫 清訓 (きたさこ きよのり)

• 所属

アマゾンデータサービスジャパン

ソリューションアーキテクト

• 仕事

メディアおよびコンテンツ配信系のお客様を主に担当

コンテンツ配信、アーカイブなどの案件に従事

Agenda

1.

Amazon CloudFront

CloudFrontによるサイト高速化

CloudFrontによるセキュア配信

まとめ

2.

3.

4.

Amazon

CloudFront

Contents Delivery Network

• 世界中にあるエッジのキャパシティを活用して高速かつ効

率的にコンテンツを配信可能なサービス

– ユーザからのアクセスを最も近いエッジサーバに誘導

することで

ユーザへの配信を高速化

– エッジサーバでは、コンテンツのキャッシングを行い、

オリジンサーバに負荷をかけずエッジから直接配信

Contents Delivery Network

オリジン

Amazon

CloudFront

レスポンス向上

負荷軽減

リクエスト 配信 リクエスト キャッシュから配信 キャッシュ コンテンツ取得

CDNサービス

クライアント オリジンサーバ 台数の削減 ユーザ体験の 向上

Contents Delivery Network

• 最適なエッジへの誘導

Amazon CloudFront

クライアント Internet 位置情報DB ①ドメイン名問い合わせ

CloudFront DNS

Edge Location

②IPアドレス問い合わせ (xxx.cloudfront.net) ③最適なEdgeアドレス応答 ④最適なEdgeへアクセス ⑤キャッシュがなければ オリジンから取得 DNSリゾル バ オリジン

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

CloudFrontによる

サイト高速化

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

Webアクセスの高速化

DNS Lookup TCP Connection Send Receive クライアント クライアント

CloudFront

物理的な NWスピード 通信の最適化 レスポンス キャパシティ オリジン オリジン

IX ISP ISP ISP

CDN Edge Locationの活用

クライアント DC

AWS

region

AWS edge AWS edge IX/Teir1

• 物理的なネットワークスピード（距離）

キャッシュ オリジン

CDN Edge Locationの活用

クライアント DC AW S edg e

VS

Edge Capacity

• レスポンスキャパシティ

サーバキャパシティ

ネットワークキャパシティ

オリジン

CDN Edge Locationの活用

クライアント

分散型

CDN

集中型

CDN

IX ISP ISP ISP ISP クライアント Edge Edge Edge Edge

クライアントに

近いエッジ

キャッシュヒット

率が高い

VS

ISP IX AWS edge

キャッシュ共有

ISP ISP ISP AWS edge

CDN Edge Locationの活用

CloudFrontのEdgeに

可能な限りキャッシュ

させることが重要

CDN Edge Locationの活用

• 可能な限りキャッシュからコンテンツを配信

静的コンテンツ

動的コンテンツ

HTTPリクエストにおける80：20の法則

キャッシュの活用

• 画像ファイル

• 動画ファイル

• CSS

• Java Script

• 静的HTML

キャッシュTTLも可能な限り長く

クライアント側にもキャッシュさせる

• 静的コンテンツ

は全てキャッシュさせることで

CDNの効果を最大化

動的コンテンツ

動的コンテンツ(ページ共通)

動的コンテンツ(パーソナライズ)

動的コンテンツ

キャッシュの活用

• 動的コンテンツ(ページ共通)

リクエストに応じて動的にページ生成は行われる

が、生成されるページ自体は一定期間共通

/item/ContentsDetail?item_id=012345 (商品詳細)

/api/ListCategory?category=cloud (カテゴリ一覧)

/api/ListContents?top=10 (人気商品一覧)

例えば

Query Stringsを活用している

キャッシュの活用

• 動的コンテンツ(ページ共通)

HTTPヘッダー判定によるページ切り替え

例えば

キャッシュの活用

動的コンテンツ

でも

一定期間ページ更新が不必要なものは

積極的にキャッシュ

日単位

時間単位

分単位

秒単位

キャッシュの活用

• 短期間でのキャッシュの更新

クライアント _{CDN Edge} オリジン Last-Modified /ETagヘッダー キャッシュ(短期) キャッシュ(期間切れ) If-Modified-Since 更新なし 304 (Not Modified) キャッシュの再利用 更新あり 最適化された通信

キャッシュヒット率の向上

• ヒット率向上のための要素

– キャッシュ時間

– URLの共通化

– Etag / Last-Modifiedヘッダーの活用

– (オプション)Query Stringsパラメータ値の固定化

– (オプション)転送対象Header値の固定化

CloudFrontは完全一致でキャッシュを共有

キャッシュヒット状況の確認

> 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==

オリジン

キャッシュ

CDN Edge Locationの活用

キャッシュができない

動的ページはEdgeを

プロキシとして利用

動的コンテンツでの活用

• Dynamic Contents Acceleration

CloudFrontによる最適化されたOriginとの通信

• POST/PUT, Header, Cookie対応

• Keep-Alive Connection

POST/PUT, Header, Cookieの対応

キャッシュできない動的コンテンツ

• POST/PUTリクエストはPROXYとして動作

• OriginへのHeaderやCookie情報の転送

Cloud FrontのEdgeを経由させても

多くの動的ページが扱えるように

その上でEdgeとOrigin間通信の最適化

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

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

オリジン

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

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

既存のコネクションを流用するため

スロースタートシーケンスをバイパス

DNS Lookupの高速化

• ホストの名前解決にRoute53を活用

CloudFrontはAlternative Domain Name

Originの名前解決にも

DNS Lookup

TCP Connection

Send Receive

Amazon Route53

• 世界52箇所にDNSサーバを配備

• Anycastを利用してレイテンシー

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 :

CNAM

E

A Recode + Alias

cdn .awssummit.co.jp.

Webアクセスの高速化

DNS Lookup TCP Connection Send Receive オリジン クライアント

CloudFront

Route53 Route53

• 物理的なネットワーク速度

• エッジキャッシュおよびキャパシティの活用

• オリジンとの通信の最適化

• DNSクエリ

CloudFrontでの実現方法

静的・動的コンテンツの混在

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

CloudFrontによる

セキュア配信

CloudFrontのセキュア機能

• HTTPSサポート

• GEO Restriction

Signed URLとは

• CloudFront経由で配信するコンテンツに対して

期間指定URL

を生成することで、配信コンテン

ツを保護する機能

クライアント

CloudFront

Signed URL有効

署名確認

Webサーバ Amazon S3 オリジン Origin Access Identity(OAI) 接続元IP制限 オリジンへのダイレクトアクセス 認証サーバ CloudFront 秘密鍵 署名付きURL発行

Signed URLの仕組み

• 指定可能ポリシー

カスタムポリシ(Custom Policy)

• アクセス有効開始・終了時刻

• アクセス元IPアドレス制限

• 許可コンテンツパスワイルドカード指定

既定ポリシ(Canned Policy)

• アクセス有効終了時刻

• 許可コンテンツフルパス

Signed URLの作成方法

1. ポリシー定義をJSONフォーマットの文字列で準備

2. AWSアカウントのCloudFront用秘密鍵で文字列を暗号化

3. コンテンツURLのQuery Stringsにパラメータとしてセット

https://dxxx.cloudfront.net/secure/media01.mp4? Signature= Yana7RByw30iPHZQzFKIyqoAsLHMPPeZ~w-7RPuHeVTY06VDgnW7MbNjQSbGkHn9kWPdlFAWCX7g1q9Mk5kORLXMcJwCOCm165~P6ss9Bj8rMmY NoIj96u7Nm3xzwbFHfCf5WyafA6aX1PoQ2Vgod98TZVhHGuTdA-IuiMz6Ly8_ &Policy=eyJTdGF0ZW1lbnQiOlt7IlJlc291cmNlIjoiaHR0cHM6Ly9kMWJ3amwwb3JteW9veC5jbG91ZGZyb2 50Lm5ldC9obHMvKiIsIkNvbmRpdGlvbiI6eyJEYXRlTGVzc1RoYW4iOnsiQVdTOkVwb2NoVGltZSI6MTM5N DI0NjMwM319fV19 &Key-Pair-Id=APKAIZ4RI4PUMO3SNKLQ

CloudFront用秘密鍵があればどこでも

URLの生成が可能

Signed URLの利用領域

• プレミアムコンテンツ配信

– ダウンロード配信 (ゲーム, 映像, 音声, データ)

– ストリーミング配信 (映像, 音声)

既存認証システムと連携し

コンテンツに対して複雑な保護処理を

施さなくても簡単かつセキュアに配信

CloudFrontの設定と既存認証システム

でのURL生成機能の実装のみ

Signed URL Tips

• アクセス

– HTTPSと場合によってはGeo

Restrictionとの組み合わせ

• CloudFrontの設定

– Behavior毎にSigned URLの有無が指

定可能

– アクセスURLの正規表現を利用し

Distributionを分けなくても特定のコ

ンテンツのみ保護可能

• キャッシュの有効活用

– キャッシュされたコンテンツにも

Signed URLは有効

– クライアントにキャッシュさせたくな

いコンテンツは、Cache-Controlヘッ

ダーのno-cache, no-storeと

CloudFrontのCustom TTLで調整

• 有効時間の設定

– ダウンロード時は有効時刻を短く設定

– ストリーミングは映像・音声の再生時

間+αを設定

CloudFrontの活用

• インフラアプローチ

によるサイト高速化の実現

• 動的コンテンツ

に関してもCloudFrontを上手

く活用

• セキュアなコンテンツ配信

も容易かつ高速化が

可能

チリも積もれば速くなる

http://csd.awseventsjapan.com/

2014.09.09 SAVE THE DATE

検 索