【レポート】リアルタイムにインターネットを計測する – CloudFrontチームのAWSサービス活用事例 #reinvent #CTD406

2017.11.29

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

re:Invent 2017のセッション「CTD406 - Measuring the Internet in Real Time」を聴講したレポートです。

スピーカーはJorge Vasquez(Sr. Software Development Engineer, Amazon Web Services)です。

本セッションは、Amazon CloudFrontの開発チームが日々のトラフィックをAWSサービスを駆使して解析する事例を紹介します。

CFチームによるトラフィックの計測と管理

  • なぜ計測が必要か
    • ファイバーの光のスピード
    • 帯域
  • CloudFrontのユースケース
    • パフォーマンス
    • 静的コンテンツ、動的コンテンツのキャッシュ
    • ニュースサイトとか
    • 短いTTLによるキャッシュ
    • エッジとのTCPハンドシェイクとキープアライブ
    • AmazonのショッピングカートやSlackなどWeb APIのキャッシュとしても有効
    • 可用性
    • 多くのPOP、経路による分散構成
    • DDoS耐性
    • コンテンツの保持性。オリジンがダウンしてもキャッシュを保持してクライアントに返せる
    • セキュリティ
    • WAF(XSS、SQLiなど)
    • Field Level EncryptionNEW!!
    • コンプライアンス準拠
  • リクエストのライフサイクル
    • DNSの名前解決。CloudFrontのドメインからIPアドレスを引いてPOPにHTTPアクセスをリクエストする
    • 状況は刻一刻と変わる。リゾルバに対してどのPOPのIPアドレスを返すのか選択する基準はいろいろある。
  • フィードバックループ
    • ホテルのシャワーの例水圧と温度は様子を見ながら調節しなければならない。
    • CloudFrontもフィードバックループで計測と調節を繰り返し回している
  • RTTの計測
    • Kinesisの活用
    • RTTデータはPOPから続々と届く
    • Kinesisストリーム(シャード)の対応が必要
    • パーティションキーとリシャード
    • リゾルバのRTTも取っている

リアルタイムフィードバックなシステムのデザインパターン

以下のデザインパターンを基本として採用した。

  1. たくさんのエンドポイントからの情報をKinesis Streamで一箇所に集約
  2. StreamのコンシューマとしてEC2でKCL(Kinesis Client Library)を実行
  3. 集計結果はS3に保存

これを様々な用途に当てはめていく

  • POPのヘルス状態の計測に適用こちらはCloudWatchメトリクスからアラームを設定してダッシュボードと状態監視
  • POPのキャパシティ計算こちらはCloudWatch APIに投入したメトリクスを別のEC2から取得、集計結果をS3に格納するパターン
  • デザインパターンとして他のデータにも適用している
    • リンク数
    • 負荷
  • アーキテクチャ図
  • デザインパターンとしては複数のフィードバックループを入れ子で回すこと、整形済みのデータを複数AWSリージョンに保存すること
  • ルーターの輻輳制御
    • Outputにキューを仕掛ける
    • キューの滞留状況から特定POPのレイテンシーを検出
    • で、POPの負荷状況をフィードバックする
  • デザインパターンのまとめ

所感

CloudFrontの内部でAWSサービスを駆使している、貴重なDog Foodingの事例が聞けました。リアルタイムなストリーム処理向けの標準的なAWSアーキテクチャに沿いつつCloudFrontの実際の運用に活かされている様子がよくわかりました。