Upload
others
View
2
Download
0
Embed Size (px)
Citation preview
© 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