今だから!Amazon CloudFront 徹底活用

648 views

Published on

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

Published in: Technology
0 Comments
3 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
648
On SlideShare
0
From Embeds
0
Number of Embeds
4
Actions
Shares
0
Downloads
0
Comments
0
Likes
3
Embeds 0
No embeds

No notes for slide
  • 参考
    SST50
    Secure Content Delivery Using Amazon CloudFront and AWS WAF (Nate DyeのreInvent)

    https://www.slideshare.net/AmazonWebServices/secured-api-acceleration-with-engineers-from-amazon-cloudfront-and-slack
  • Mar 16, 2017
  • With the caching and acceleration technology that CloudFront has, we can deliver all of you content from static images to user inputted content.
    Static: images, js, html, etc
    Video: rtmp and http streaming support
    Dynamic: customizations and non-cachable content
    User Input: http verb support including Put/Post, etc
    SSL: Serve the content securely with SSL (https)

  • http://docs.aws.amazon.com/ja_jp/AmazonCloudFront/latest/DeveloperGuide/private-content-restricting-access-to-s3.html
  • http://docs.aws.amazon.com/ja_jp/AmazonCloudFront/latest/DeveloperGuide/PrivateContent.html
  • Helps eliminate network latency
  • #2 – integrate it into your build software; this is how the cloudfront console does it which we deliver via cloudfront.
  • For INM, make sure you include etags in your content, which S3 does for you automatically

     If-Modified-Since、If-None-Match がクライアントから送られてきたら、変更ありなしを判断して 304レスポンスを返せば通信量が減らせます
  • 今だから!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は大量のアクセスを処理する数々の手 法をフルマネージドで提供

    ×