© 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

自己紹介 • 名前

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

• 所属

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

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

• 仕事

メディアおよびコンテンツ配信系のお客様を主に担当コンテンツ配信、アーカイブなどの案件に従事

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

80

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の法則

80 20

キャッシュの活用

• 画像ファイル • 動画ファイル • CSS • Java Script • 静的HTML

キャッシュTTLも可能な限り長く クライアント側にもキャッシュさせる

• 静的コンテンツは全てキャッシュさせることでCDNの効果を最大化

動的コンテンツ

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

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

動的コンテンツ

キャッシュの活用

• 動的コンテンツ(ページ共通) リクエストに応じて動的にページ生成は行われるが、生成されるページ自体は一定期間共通

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

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

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

例えば

Query Stringsを活用している

キャッシュの活用

• 動的コンテンツ(ページ共通) HTTPヘッダー判定によるページ切り替え

例えば User-Agentを見てクライアント端末に適したページを応答

キャッシュの活用

動的コンテンツでも 一定期間ページ更新が不必要なものは 積極的にキャッシュ

日単位 時間単位

分単位 秒単位

Cache-Control Header と Minimum TTLで調整

キャッシュの活用

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

クライアント オリジン 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

• TCPスロースタート

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が応答

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.

Webアクセスの高速化

DNS Lookup TCP Connection

Send Receive

オリジン クライアント

CloudFront

Route53 Route53

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

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

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

• DNSクエリ

CloudFrontでの実現方法

静的・動的コンテンツの混在 環境における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（署名付きURL）

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

検 索 Cloud Storage & DB Day