サイトまるごとCloudFrontのチェックポイント集です。

1. 荒木靖宏
アマゾンウェブサービスジャパン
技術統括本部 シニアマネージャ
今だから！Amazon CloudFront徹底活用

2. 自己紹介
• 名前
– 荒木 靖宏
• 所属
– アマゾン ウェブ サービス ジャパン株式会社
– 技術統括本部 シニアマネージャ プリンシパルソリューションアー
キテクト
– ネットワーク技術担当
– 大規模ユーザ担当

3. Agenda
• Amazon CloudFront
• サイトまるごとCloudFront化
• ベストプラクティスステップガイド
• まとめ

4. Amazon CloudFront
• 特徴 (http://aws.amazon.com/jp/cloudfront/)
– 簡単にサイトの高速化が実現できると共に、サー
バの負荷も軽減
– 様々な規模のアクセスを処理することが可能
– 世界73箇所のエッジロケーション
• 価格体系 (http://aws.amazon.com/jp/cloudfront/pricing/)
– データ転送量(OUT)
– HTTP/HTTPSリクエスト数
– (利用する場合)SSL独自証明書 など
マネージドCDN(Contents Delivery Network)サービス
クライアント
レスポンス向上 負荷軽減
Amazon
CloudFront
キャッシュ
配信 オフロード
Webサーバ

5. ユーザ視点に立ったSLA
5
他CDNサービスのSLAの定義例
SLAを容易に達成できるルールを設定
- 顧客の認識と差が生じやすい
オリジンにテスト用のオブジェクトを置き、ベンダーのエージェントより1時間に数回テ
ストしてサーバー側計測で2回連続失敗した場合にFailureと認定。
カスタマーが能動的に上記の設定を行わないとSLAは適用されない。
上記2点を満たした場合のみ100%のSLAを提供。
• CloudFrontのSLA
• クライアントサイドでのSLA定義
- 顧客と同じ認識に立ちやすい
• CloudFront内部サーバエラー数を約5分の割合で計算する。99.9%を下回った場合はクレジット
をご提供いたします。
• ・SLA詳細 https://aws.amazon.com/jp/cloudfront/sla/

6. エッジロケーションの配置
Amazon CloudFrontは、大容量キャパシティのエッジロケーションをインターネットユーザの分布に合わ
せて戦略的に配置する集中分散型アプローチをとっています。
メリット
 キャッシュとユーザの過度な分散によるキャッシュミスが起きにくくなります
 設定の展開、アクセスログの収集にかかる時間を短縮できます
 特定の地域のユーザが最適でないエッジに割当てられるリスクを低減します
ISP
ISP
ISP
ISP
ISP
ISP
ISP
集中分散型
ISP
ISP
ISP
ISP
ISP
ISP
ISP
広域分散型

7. CloudFrontのRegional Edge Cacheを発表
• エッジロケーションからオリジン間に配置す
る中間キャッシュサーバを追加コストなしで
自動的に利用可能に
• 物理的に様々な場所からアクセスが行われる
場合に、オリジンに対するコンテンツ取得を
削減することができる
• Regional Edge Cacheは東京、北バージニ
ア、オレゴン、サンパウロ、フランクフルト、
シンガポール、ソウル、ムンバイ、シドニー
の9カ所に設置 中間キャッシュ
から送出

8. 他CDNからCloudFrontに移行後
オリジントラフィックが約7分の1に減少したお客様事例
1. 他CDN使用時 10/9 ~ 10/15
2. CFへMigration後 12/4 ~ 12/10
3. Regional Edge Cache機能のリリース後 1/6 ~ 1/12
50Mbps
50Mbps
50Mbps

9. Agenda
• Amazon CloudFront
• サイトまるごとCloudFront化
• ベストプラクティスステップガイド
• まとめ

10. Dynamic
Static
Video
User
Input
SSL
サイトまるごとCloudFront

11. CloudFront導入はバックエンドそのままで可能
ALB / ELB
Dynamic Content
Amazon EC2
Static Content
Amazon S3 Custom Origin
OR
OR
Custom Origin
Amazon CloudFront
example.com *.jpg
*.php

12. 典型的Webアプリの構成要素
• Static Assets
• Dynamic Content
• Streaming Media

13. Agenda
• Amazon CloudFront
• サイトまるごとCloudFront化
• ベストプラクティスステップガイド
• まとめ

14. Static Assets

15. Static Assetsとは?
• 変化しないコンテンツ: Images, JS, CSS, Fonts,
Software
• ユーザ個別ではなく、同じものを多くの人が利用
• 一定時間状態が変わらないオブジェクト（期間様々：秒
分時）

16. ステップ#1. Static AssetsをAmazon S3へ
• S3からCloudFrontへのデータ転送は無償
• Webサーバの負荷が低減する
• S3はスケーラブルかつ高可用を提供する

17. ステップ#2. S3上のコンテンツの権限設定
• Origin Access Identity (OAI)の利用
– 特別なCloudFrontユーザがOAIを使う
– S3側はOAIなしには読み取り許可をしない
• Why use OAI?
– コンテンツ漏洩防止
– S3のURLを直接使わせない

18. ステップ#3. （プライベートコンテンツ向け）CloudFront上のコ
ンテンツの権限設定
• 方法は２つ：Signed URLs or Signed Cookies
• Signed URLsはMarketing email
• Signed CookiesはStreaming, サイト認証
Region
Access Denied
Access Denied

19. ステップ#4. ブラウザキャッシュの利用
• max-ageをヘッダに指定
(e.g. Cache-Control: max-age=3600)
• HTML5であれば application cache
• キャッシュサイズに制限がある点は注意する
(e.g. IE is 8-50M, Chrome is < 80M, Firefox is 50MB, etc.)

20. ステップ#5. Edge Cachingの利用
• 中間キャッシュ用のs-maxageを長くする
(e.g. Cache-Control: max-age=3600, s-maxage=86400)
• ヘッダ、クエリ文字列、クッキーの転送をしない
– CORSをしない限り必要ない
• CloudFront のdefault設定を使用する

21. ステップ#6. オブジェクトにバージョン付与
• 更新とロールバックを容易にするため
• ファイル名を変更する（or クエリ文字列の利用）
• 更新頻度が低いオブジェクトには長いTTLを設定
• ブラウザキャッシュではユニークとして扱われる

22. Dynamic Content

23. Dynamic Contentとは?
• 全てのリクエスト毎に違う内容
(例: /index.php)
• 頻繁(数秒, 数分)に変更されるが、必ずしも毎回違う内
容ではないもの
(例: 天気情報, API, etc.)
• リクエスト（クエリ文字列, cookies, ヘッダ）で変化する内
容
(例: mobile vs. desktop users, 検索 etc.)

24. ステップ#7. 可能な限りキャッシュする
• 数秒であっても、殆どのコンテンツはキャッシュ可能
• CloudFrontはTTLを0秒にも対応
• 極小TTLでも設定すべき
– CloudFront は“If-Modified-Since” および “If-None-Match” をサポートしている
– CloudFront はOriginが止まっていてもキャッシュされているオブジェクトを返す
– 積み重ねがオリジン負荷を下げる

25. Popular Objects Reportの利用
CloudFront Popular Objects Reportが上位50URLを示す
その中から、すこしでもキャッシュ可能なコンテンツを探して設定

26. ステップ#8. 複数のキャッシュ制御条件を使う
• 必要なヘッダだけを転送
– 例：/imagesにはクッキーは転送不要
• User-Agentヘッダは使わない
– Is-Mobile-Viewer, Is-Tablet-Viewer, Is-Desktop-Viewer, Is-SmartTV-
Viewer
• 全クッキーの転送は止める
– 必要とするクッキーだけを転送する

27. Availability Best Practices

28. ステップ#9. モニタ、アラーム、通知の利用
• CloudFrontはほぼリアルタイムのモニタとアラーム
がCloudWatch経由で提供
– 6種提供中：Requests, Bytes Downloaded, Bytes Uploaded, 4xx
Error Rate, 5xx Error Rate, Total Error Rate
– 無償
– アラームと通知設定可能

29. ステップ#10. エラーページをカスタマイズ
• ユーザ体験向上につながる
• エラーページはS3を使う
• エラーページのキャッシュTTL
は短くする（例：15秒）

30. ステップ#11. Design for Failure
• CloudFrontからのオリジンフェッチが失敗する場合
を考える
Region
CloudFront

31. Design for Failure …Cont’d
• Amazon Route 53のヘルスチェック機能の利用
Region
Route53
Health
Check
Health
Check

32. Design for Failure …Cont’d
Region
Route53
Health
Check
Health
Check
CloudFront

33. Design for Failure …Cont’d
Region
Route53
Health
Check
Health
Check
CloudFront

34. Agenda
• Amazon CloudFront
• サイトまるごとCloudFront化
• ベストプラクティスステップガイド
• まとめ

35. Amazon
Route 53
AWS WAF
Amazon
CloudFront
Elastic Load Balancing EC2
AP-NORTHEAST-1
Amazon S3
Corporate Datacentre
Elastic Load Balancing EC2
US-WEST-2
Amazon
Route 53
CloudFrontを中心とした大量アクセス全体像
AWS Lambda

36. CloudFrontはWebサービス提供のベストプラクティス
• CloudFrontは大量のアクセスを処理する数々の手
法をフルマネージドで提供