[レポート] NET309: CloudFrontでのパフォーマンス最適化: すべてのミリ秒が大切！ #reinvent

AWS re:Invent 2019

#イベントレポート

#Amazon CloudFront

#AWS

清水俊也

2020.01.29

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

はじめに

清水です。AWS re:Invent2019のセッションNET309「Optimizing for performance in CloudFront: Every millisecond counts!」の聴講レポートとなります。本セッション、re:Invent2019現地で聴講するよう予約していたのですが、スケジュールを勘違いしておりセッション会場にたどり着けず現地では聴講できませんでした。代わりに公開されているセッション動画とスライドでの聴講となります。

セッションの概要は下記になります。

In content delivery, every millisecond counts for your customers because it translates to a better user experience. In this session, the Amazon CloudFront engineers provide a deep-dive into optimization and measurement techniques used to continually improve the delivery of your content. Learn about how we optimize for both dynamic and static content delivery. We also share insights from Tinder on how these optimizations benefited the performance of their applications.

スピーカーは下記のお三方です。

Tino Tran - Principal SA, Edge Svcs., Amazon Web Services
Karthik Uthaman - Senior Software Engineer, Amazon Web Services
Chris Obrien - Senior Engineering Manager, Tinder

セッションスライドはこちらのリンクで、またセッション動画は下記で公開されています。

レポート

まずはTino TranさんからCloudFrontの概要についての紹介です。

Amazon CloudFront
- 210のPoP(Points of Presence)
- 11のリージョナルエッジキャッシュ（オリジンとエッジロケーションの中間層）
- エッジロケーションとAWSリージョンをつなぐプライベートなグローバルネットワーク
- 前年比50%の成長率
- 34の国と77の都市
なぜパフォーマンスが重要なのか？
- WebページのLoading時間。訪問者は2秒以上は待ってくれない
- SEO的にも長いLoading時間は不利
- ビデオストリーミングでのバッファリングの防止
Amazon CloudFrontでのコンテンツ高速配信のユースケース
- サイト全体の高速配信
- APIの高速化
- ソフトウェアアップデートやゲームパッチといった大きなファイルのダウンロード
- Lambda@Edgeでのプログラミング可能なCDN
Amazon CloudFrontの顧客事例
- Amazon Prime VideoやHulu、SkyNewsなどメディア配信
- Intuitなど金融サービス
- Slackのようなメッセージングサービス

続いて、Tinder社のChris Obrienさんから、エンドユーザのレイテンシ改善等CloudFrontの活用事例の紹介です。

Tinderについて
- マッチングアプリ。チャットやデート機能。
- プロフィール作成
  - 自己紹介や住んでいる場所、マッチング相手の設定
  - 写真のアップロード
- マッチング候補の写真を確認、興味があれば右にスワイプ
Tinderのユースケース例: Login
- 複数のHTTPS API呼び出し
- それぞれのAPI呼び出しごとにTLSハンドシェイク
- 距離が遠いほど、API呼び出しのレイテンシが高くなる
エンドユーザのレイテンシの問題
- アーキテクチャ
  - たくさんのクライアント。iOS, Android, Web
  - インターネット経由でAWSのus-east-1でホストしているバックエンドインフラへアクセス
- HTTPSを使用しており、全てのAPIがTLSハンドシェイクの確立が必要
  - TLSハンドシェイクは多くの情報のやり取りが発生
- CloudFront使用前のTLSハンドシェイクレイテンシ
  - インドでは700ミリ秒を超える。ドイツで470ミリ秒。アメリカでも平均210ミリ秒。
どうすればTLSハンドシェイクレイテンシを減らすことができるか
- Amazon CloudFrontのグローバルネットワークの利用
- CDNであるCloudFrontが本当に問題解決に役立つか？
  - CloudFrontは静的コンテンツをCDNとして提供するためのだけのもの？
  - CloudFrontでどのようにTLSハンドシェイクのレイテンシ削減に役立つのか？
- CloudFrontでTLSハンドシェイクレイテンシ削減のためにできること
  - エンドユーザに地理的に近い場所(PoP)でTLSハンドシェイクをターミネート
  - PoPからオリジンの接続を再利用
  - 低速のインターネットを介して行われる通信の代わりに、最適化されたAWSグローバルネットワークを利用してPoPからオリジンに通信
CloudFrontの導入
- CloudFront導入前の構成
- CloudFront導入
  - システムとエンドユーザの間にCloudFrontを導入
- テストケース
  - 決定的な結果を得るのに十分な数のアクティブユーザを対象に
  - iOS, Android, Webそれぞれのユーザをバランス良く
  - us-east-1から可能な限り離れた場所で
- CloudFrontへのトラフィックルーティング
  - 一部のトラフィックだけを、CloudFrontにゆっくりルーティングしたい
  - CloudFrontに問題がある場合やレイテンシが増加してしまった場合のロールバック方法の確立も必要
  - Amazon Route53トラフィックポリシーの利用
- Amazon Route53トラフィックポリシー
  - ルーティングポリシー
    - 地理ベース、重み付けベース
  - フェイルオーバーポリシーも設定可能
- インドネシアでのテスト
  - インドネシアのトラフィックの25%をCloudFrontへ
  - Webクライアントのヘッダにいくつかエラーがあることに気がつく
  - Route53トラフィックポリシーで簡単にロールバック
  - わずか20日でデプロイ完了
- インドネシアでのTLSハンドシェイクレイテンシの削減結果
  - CloudFrontなしの場合は550ミリ秒。CloudFront導入により70ミリ秒。87%の削減
  - アプリのログインが45%高速に
  - プロフィールの読み込みが40%高速に
  - 画像とビデオのアップロードが30%高速に
  - 他のAPIについては、ペイロードサイズに応じて約40%から60%の改善がみられた
CloudFrontをグローバルに導入！
- CloudFront導入前のTLSハンドシェイクレイテンシ
- CloudFront導入後のTLSハンドシェイクレイテンシ
  - すべての地域でレイテンシを削減。ほとんどの地域で100ミリ秒以下に
TinderアプリへのCloudFront導入のインパクト
- 以前よりもユーザがアクティブに
- アプリがもっさりしていて離れてしまったユーザが戻ってきた
- プロフィールの読み込みが20%高速化
- 写真のアップロードが15%増加
- スワイプ数が3%増加
- アプリの全体的なブラウジング速度の改善
まとめ
- CloudFrontは静的コンテンツだけでなく動的ワークロードも最適化
- CloudFrontの実装はシンプルかつ高速
- TinderのAPIパフォーマンスが30-45%向上

続いてもう一度Tino Tranさんに戻ります。CloudFrontのグローバルネットワーク部分の詳細についての説明です。

AWSのバックボーンネットワークを活用する理由
- 可用性
- パフォーマンス
- 近さ（顧客に近いこと）
- セキュリティ
AWSはどのようにインターネットに接続するか
- AWSのリージョンごとのトランジットセンターを介して
- PoP: Points of Presenceを介して。これはCloudFrontやRoute53などのエッジサービスと同じポイント
PoPネットワークとの接続
- AWSネットワークの拡張
- ネットワークスケーリングの増加
- 最適な相互接続
- 100以上の設備と170のInternet Exchange
ネットワーク最適化についての深堀り
- インテリジェントルーティング
  - CloudFrontへのアクセス時、Route53と連携して最適なエッジロケーションへ
    - パフォーマンス、サーバやネットワークのキャパシティ、PoPの状態などを考慮
- TCP輻輳制御
  - TCP BBR
    - パケット損失ではなく、実際の輻輳に対応
    - RTTと帯域幅を測定
    - 帯域幅の変化の調査
    - ボトルネックの制限を飽和
  - TLS
    - 転送中の暗号化
    - 使用は増えているが、レイテンシの増加やTLSの新バージョン対応など
    - CloudFrontにオフロードが可能
      - セッション再開（session resumption)

ここでKarthik Uthamanさんに代わり、サーバ側（CloudFrontとオリジン間）の最適化についての説明です。

サーバサイド側の最適化についての深堀り
- 動的コンテンツ配信についての最適化
- メディアワークロードでの最適化
- オリジンの負荷低減
どのようにキャッシュスペースを有効に使うか？エッジロケーションのアーキテクチャ
- PoPそれぞれは物理サーバーのアレイ
- サーバごとに3つのレイヤ
  - L1 - ロードバランサと小さめのキャッシュレイヤ。ホット（ポピュラー）なオブジェクトだけ
  - L2 - より大量のキャッシュレイヤ
  - L3 - 永続的接続レイヤ。キャッシュスペースはないが、オリジンとのコネクションをプールする
- リクエストでL1になければL2に。L2は同じサーバではなく別サーバになることも。この選択はハッシュで決まる
- L3の決定についてもハッシュから
動的コンテンツの最適化
- エッジロケーションでのTLS終端による、全体的なレイテンシ改善
- L1ではTTLやヘッダの内容とかの確認。動的コンテンツなのかキャッシュ可能なのかの判定
- 動的コンテンツの場合は、キャッシュレイヤをスキップして直接L3レイヤに
- L3レイヤでオリジンと永続的な接続を使用
  - 接続を再利用することによるレイテンシの改善。2RTTが1RTTで
  - 永続的接続により輻輳の点でもメリット、スループット向上。
メディアワークロードの最適化
- CloudFrontは2019年の最も大きなメディアイベントのいくつかを配信
  - Super BowlやThursday Night Football
    - Thursday Night FootballはAmazon Prime Videoでの配信で、全世界18億人の視聴者
  - TVニュージーランドのコモンウェルスゲームズ、3億人の視聴者
メディア配信での課題
- Flash Crowdと呼ばれる状況が発生
  - あるタイミングで、みんなが一斉に同じライブストリームをみはじめる（同じファイル/オブジェクトに一斉にアクセスが発生）
- エッジ内の書くサーバのL1に一斉にリクエストが発生
- キャッシュヒット向上のため、通常では単一のサーバのL2レイヤにアクセス
  - 単一のL2で過負荷になりオーバーロードを招く
- 対策として、L2レイヤの負荷が高くなるようであれば、別のサーバのL2レイヤにもロードバランスするしくみ
- L2レイヤが複数のサーバにまたがっても、L3レイヤは1つのサーバが担当。オリジンへの負荷低減
- レスポンスについては、オブジェクトのポピュラリティにより、特別に参照が多いファイルであればL1レイヤでキャッシュする
オリジンの負荷低減
- 210のPOP
- オリジンの負荷が多くなり始める
- リージョナルエッジキャッシュで追加のキャッシュ幅を提供
- オリジンの負荷を低減し、顧客へのコストを削減
- 顧客へのキャッシュヒット率を増やし、それによりレイテンシを改善

最後にKarthik Uthamanさんにより本セッションが締めくくられました。

まとめ
- Amazon CloudFrontはグローバルネットワークであり、前年比で50％の成長
- Amazon CloudFrontはデプロイと管理が容易
- AWSマネージドバックボーンネットワークは信頼できるパフォーマンスを提供
- Amazon CloudFrontは常にインフラストラクチャとサービスを最適化している

感想

CloudFrontのエッジロケーションの内部の仕組みや構成も紹介され、非常に興味深いセッションでした。TLSハンドシェイクの面など含めて、動的コンテンツの場合でもCloudFront導入で高速化が期待できるのは大きいですね。アメリカ国内などオリジンと同じ地域でも効果は表れますが、特にグローバルな環境では効果絶大だと感じました。