Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
荒木靖宏
アマゾンウェブサービスジャパン
技術統括本部 シニアマネージャ
今だから!Amazon CloudFront徹底活用
自己紹介
• 名前
– 荒木 靖宏
• 所属
– アマゾン ウェブ サービス ジャパン株式会社
– 技術統括本部 シニアマネージャ プリンシパルソリューションアー
キテクト
– ネットワーク技術担当
– 大規模ユーザ担当
Agenda
• Amazon CloudFront
• サイトまるごとCloudFront化
• ベストプラクティスステップガイド
• まとめ
Amazon CloudFront
• 特徴 (http://aws.amazon.com/jp/cloudfront/)
– 簡単にサイトの高速化が実現できると共に、サー
バの負荷も軽減
– 様々な規模のアクセスを処理することが可能
– 世界...
ユーザ視点に立ったSLA
5
他CDNサービスのSLAの定義例
SLAを容易に達成できるルールを設定
- 顧客の認識と差が生じやすい
オリジンにテスト用のオブジェクトを置き、ベンダーのエージェントより1時間に数回テ
ストしてサーバー側計測で2回...
エッジロケーションの配置
Amazon CloudFrontは、大容量キャパシティのエッジロケーションをインターネットユーザの分布に合わ
せて戦略的に配置する集中分散型アプローチをとっています。
メリット
 キャッシュとユーザの過度な分散によ...
CloudFrontのRegional Edge Cacheを発表
• エッジロケーションからオリジン間に配置す
る中間キャッシュサーバを追加コストなしで
自動的に利用可能に
• 物理的に様々な場所からアクセスが行われる
場合に、オリジンに対す...
他CDNからCloudFrontに移行後
オリジントラフィックが約7分の1に減少したお客様事例
1. 他CDN使用時 10/9 ~ 10/15
2. CFへMigration後 12/4 ~ 12/10
3. Regional Edge Cac...
Agenda
• Amazon CloudFront
• サイトまるごとCloudFront化
• ベストプラクティスステップガイド
• まとめ
Dynamic
Static
Video
User
Input
SSL
サイトまるごとCloudFront
CloudFront導入はバックエンドそのままで可能
ALB / ELB
Dynamic Content
Amazon EC2
Static Content
Amazon S3 Custom Origin
OR
OR
Custom Origin...
典型的Webアプリの構成要素
• Static Assets
• Dynamic Content
• Streaming Media
Agenda
• Amazon CloudFront
• サイトまるごとCloudFront化
• ベストプラクティスステップガイド
• まとめ
Static Assets
Static Assetsとは?
• 変化しないコンテンツ: Images, JS, CSS, Fonts,
Software
• ユーザ個別ではなく、同じものを多くの人が利用
• 一定時間状態が変わらないオブジェクト(期間様々:秒
分時)
ステップ#1. Static AssetsをAmazon S3へ
• S3からCloudFrontへのデータ転送は無償
• Webサーバの負荷が低減する
• S3はスケーラブルかつ高可用を提供する
ステップ#2. S3上のコンテンツの権限設定
• Origin Access Identity (OAI)の利用
– 特別なCloudFrontユーザがOAIを使う
– S3側はOAIなしには読み取り許可をしない
• Why use OAI?
...
ステップ#3. (プライベートコンテンツ向け)CloudFront上のコ
ンテンツの権限設定
• 方法は2つ:Signed URLs or Signed Cookies
• Signed URLsはMarketing email
• Signe...
ステップ#4. ブラウザキャッシュの利用
• max-ageをヘッダに指定
(e.g. Cache-Control: max-age=3600)
• HTML5であれば application cache
• キャッシュサイズに制限がある点は注...
ステップ#5. Edge Cachingの利用
• 中間キャッシュ用のs-maxageを長くする
(e.g. Cache-Control: max-age=3600, s-maxage=86400)
• ヘッダ、クエリ文字列、クッキーの転送をし...
ステップ#6. オブジェクトにバージョン付与
• 更新とロールバックを容易にするため
• ファイル名を変更する(or クエリ文字列の利用)
• 更新頻度が低いオブジェクトには長いTTLを設定
• ブラウザキャッシュではユニークとして扱われる
Dynamic Content
Dynamic Contentとは?
• 全てのリクエスト毎に違う内容
(例: /index.php)
• 頻繁(数秒, 数分)に変更されるが、必ずしも毎回違う内
容ではないもの
(例: 天気情報, API, etc.)
• リクエスト(クエリ...
ステップ#7. 可能な限りキャッシュする
• 数秒であっても、殆どのコンテンツはキャッシュ可能
• CloudFrontはTTLを0秒にも対応
• 極小TTLでも設定すべき
– CloudFront は“If-Modified-Since” お...
Popular Objects Reportの利用
CloudFront Popular Objects Reportが上位50URLを示す
その中から、すこしでもキャッシュ可能なコンテンツを探して設定
ステップ#8. 複数のキャッシュ制御条件を使う
• 必要なヘッダだけを転送
– 例:/imagesにはクッキーは転送不要
• User-Agentヘッダは使わない
– Is-Mobile-Viewer, Is-Tablet-Viewer, Is...
Availability Best Practices
ステップ#9. モニタ、アラーム、通知の利用
• CloudFrontはほぼリアルタイムのモニタとアラーム
がCloudWatch経由で提供
– 6種提供中:Requests, Bytes Downloaded, Bytes Uploaded,...
ステップ#10. エラーページをカスタマイズ
• ユーザ体験向上につながる
• エラーページはS3を使う
• エラーページのキャッシュTTL
は短くする(例:15秒)
ステップ#11. Design for Failure
• CloudFrontからのオリジンフェッチが失敗する場合
を考える
Region
CloudFront
Design for Failure …Cont’d
• Amazon Route 53のヘルスチェック機能の利用
Region
Route53
Health
Check
Health
Check
Design for Failure …Cont’d
Region
Route53
Health
Check
Health
Check
CloudFront
Design for Failure …Cont’d
Region
Route53
Health
Check
Health
Check
CloudFront
Agenda
• Amazon CloudFront
• サイトまるごとCloudFront化
• ベストプラクティスステップガイド
• まとめ
Amazon
Route 53
AWS WAF
Amazon
CloudFront
Elastic Load Balancing EC2
AP-NORTHEAST-1
Amazon S3
Corporate Datacentre
Elastic...
CloudFrontはWebサービス提供のベストプラクティス
• CloudFrontは大量のアクセスを処理する数々の手
法をフルマネージドで提供
Upcoming SlideShare
Loading in …5
×

今だから!Amazon CloudFront 徹底活用

4,846 views

Published on

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

Published in: Technology
  • Hello! Get Your Professional Job-Winning Resume Here - Check our website! https://vk.cc/818RFv
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here

今だから!Amazon CloudFront 徹底活用

  1. 1. 荒木靖宏 アマゾンウェブサービスジャパン 技術統括本部 シニアマネージャ 今だから!Amazon CloudFront徹底活用
  2. 2. 自己紹介 • 名前 – 荒木 靖宏 • 所属 – アマゾン ウェブ サービス ジャパン株式会社 – 技術統括本部 シニアマネージャ プリンシパルソリューションアー キテクト – ネットワーク技術担当 – 大規模ユーザ担当
  3. 3. Agenda • Amazon CloudFront • サイトまるごとCloudFront化 • ベストプラクティスステップガイド • まとめ
  4. 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. 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. 6. エッジロケーションの配置 Amazon CloudFrontは、大容量キャパシティのエッジロケーションをインターネットユーザの分布に合わ せて戦略的に配置する集中分散型アプローチをとっています。 メリット  キャッシュとユーザの過度な分散によるキャッシュミスが起きにくくなります  設定の展開、アクセスログの収集にかかる時間を短縮できます  特定の地域のユーザが最適でないエッジに割当てられるリスクを低減します ISP ISP ISP ISP ISP ISP ISP 集中分散型 ISP ISP ISP ISP ISP ISP ISP 広域分散型
  7. 7. CloudFrontのRegional Edge Cacheを発表 • エッジロケーションからオリジン間に配置す る中間キャッシュサーバを追加コストなしで 自動的に利用可能に • 物理的に様々な場所からアクセスが行われる 場合に、オリジンに対するコンテンツ取得を 削減することができる • Regional Edge Cacheは東京、北バージニ ア、オレゴン、サンパウロ、フランクフルト、 シンガポール、ソウル、ムンバイ、シドニー の9カ所に設置 中間キャッシュ から送出
  8. 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. 9. Agenda • Amazon CloudFront • サイトまるごとCloudFront化 • ベストプラクティスステップガイド • まとめ
  10. 10. Dynamic Static Video User Input SSL サイトまるごとCloudFront
  11. 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. 12. 典型的Webアプリの構成要素 • Static Assets • Dynamic Content • Streaming Media
  13. 13. Agenda • Amazon CloudFront • サイトまるごとCloudFront化 • ベストプラクティスステップガイド • まとめ
  14. 14. Static Assets
  15. 15. Static Assetsとは? • 変化しないコンテンツ: Images, JS, CSS, Fonts, Software • ユーザ個別ではなく、同じものを多くの人が利用 • 一定時間状態が変わらないオブジェクト(期間様々:秒 分時)
  16. 16. ステップ#1. Static AssetsをAmazon S3へ • S3からCloudFrontへのデータ転送は無償 • Webサーバの負荷が低減する • S3はスケーラブルかつ高可用を提供する
  17. 17. ステップ#2. S3上のコンテンツの権限設定 • Origin Access Identity (OAI)の利用 – 特別なCloudFrontユーザがOAIを使う – S3側はOAIなしには読み取り許可をしない • Why use OAI? – コンテンツ漏洩防止 – S3のURLを直接使わせない
  18. 18. ステップ#3. (プライベートコンテンツ向け)CloudFront上のコ ンテンツの権限設定 • 方法は2つ:Signed URLs or Signed Cookies • Signed URLsはMarketing email • Signed CookiesはStreaming, サイト認証 Region Access Denied Access Denied
  19. 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. 20. ステップ#5. Edge Cachingの利用 • 中間キャッシュ用のs-maxageを長くする (e.g. Cache-Control: max-age=3600, s-maxage=86400) • ヘッダ、クエリ文字列、クッキーの転送をしない – CORSをしない限り必要ない • CloudFront のdefault設定を使用する
  21. 21. ステップ#6. オブジェクトにバージョン付与 • 更新とロールバックを容易にするため • ファイル名を変更する(or クエリ文字列の利用) • 更新頻度が低いオブジェクトには長いTTLを設定 • ブラウザキャッシュではユニークとして扱われる
  22. 22. Dynamic Content
  23. 23. Dynamic Contentとは? • 全てのリクエスト毎に違う内容 (例: /index.php) • 頻繁(数秒, 数分)に変更されるが、必ずしも毎回違う内 容ではないもの (例: 天気情報, API, etc.) • リクエスト(クエリ文字列, cookies, ヘッダ)で変化する内 容 (例: mobile vs. desktop users, 検索 etc.)
  24. 24. ステップ#7. 可能な限りキャッシュする • 数秒であっても、殆どのコンテンツはキャッシュ可能 • CloudFrontはTTLを0秒にも対応 • 極小TTLでも設定すべき – CloudFront は“If-Modified-Since” および “If-None-Match” をサポートしている – CloudFront はOriginが止まっていてもキャッシュされているオブジェクトを返す – 積み重ねがオリジン負荷を下げる
  25. 25. Popular Objects Reportの利用 CloudFront Popular Objects Reportが上位50URLを示す その中から、すこしでもキャッシュ可能なコンテンツを探して設定
  26. 26. ステップ#8. 複数のキャッシュ制御条件を使う • 必要なヘッダだけを転送 – 例:/imagesにはクッキーは転送不要 • User-Agentヘッダは使わない – Is-Mobile-Viewer, Is-Tablet-Viewer, Is-Desktop-Viewer, Is-SmartTV- Viewer • 全クッキーの転送は止める – 必要とするクッキーだけを転送する
  27. 27. Availability Best Practices
  28. 28. ステップ#9. モニタ、アラーム、通知の利用 • CloudFrontはほぼリアルタイムのモニタとアラーム がCloudWatch経由で提供 – 6種提供中:Requests, Bytes Downloaded, Bytes Uploaded, 4xx Error Rate, 5xx Error Rate, Total Error Rate – 無償 – アラームと通知設定可能
  29. 29. ステップ#10. エラーページをカスタマイズ • ユーザ体験向上につながる • エラーページはS3を使う • エラーページのキャッシュTTL は短くする(例:15秒)
  30. 30. ステップ#11. Design for Failure • CloudFrontからのオリジンフェッチが失敗する場合 を考える Region CloudFront
  31. 31. Design for Failure …Cont’d • Amazon Route 53のヘルスチェック機能の利用 Region Route53 Health Check Health Check
  32. 32. Design for Failure …Cont’d Region Route53 Health Check Health Check CloudFront
  33. 33. Design for Failure …Cont’d Region Route53 Health Check Health Check CloudFront
  34. 34. Agenda • Amazon CloudFront • サイトまるごとCloudFront化 • ベストプラクティスステップガイド • まとめ
  35. 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. 36. CloudFrontはWebサービス提供のベストプラクティス • CloudFrontは大量のアクセスを処理する数々の手 法をフルマネージドで提供

×