この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
こんにちは、AWS事業本部の島川です。
本記事ではラスベガスで開催されたAWSの一大イベント AWS re:Invent 2019で発表されたセッションをご紹介いたします。
今回紹介するセッション
Scaling Hotstar.com for 25 million concurrent viewers
スピーカー
Gaurav Kamboj Cloud Architect , Hotstar
概要
This session focuses on why traditional autoscaling doesn't work for Hotstar (Disney's OTT streaming service), who recently created a global record for live streaming to 25.3 million concurrent viewers. We talk about challenges in scaling infrastructure for millions and how to overcome them, how Hotstar runs gamedays before facing live games, how it uses a load-testing monster called Hulk to prepare its platform for 50M peak. We also learn how the company uses chaos engineering to overcome real-world problems and achieve this scale.
このセッションでは、25.3万人の同時視聴者へのライブストリーミングのグローバルレコードを最近作成したHotstar（DisneyのOTTストリーミングサービス）で従来の自動スケーリングが機能しない理由に焦点を当てます。数百万人のインフラストラクチャのスケーリングの課題と、それらを克服する方法、Hotstarがライブゲームに直面する前にゲームを実行する方法、Hulkと呼ばれる負荷テストモンスターを使用して50Mものピークのプラットフォームを準備する方法について説明します。また、企業がカオスエンジニアリングを使用して実際の問題を克服し、この規模を達成する方法についても学びます。
レポート
Hotstarとは
- ディズニー(The Walt Disney Company)がオーナーのインドのOTTプラットフォーム
- 3億5千万ダウンロード越え
- 1日で1億人以上ユニークユーザー
- 15の言語に対応している
- 色んなコンテンツがある
- ライブ/オンデマンド
- スポーツ/ニュース/テレビ/映画
- 地域カタログ
実際のページ
15の言語に対応とのことでしたが、今現在、日本語には対応していないようです。
同時接続されるパターン
- 今回の例はクリケットのスポーツストリーミング
- ニュージーランドの場合ピークは13.9M接続
- インドの場合はピークは25.3M接続
スケールについて
- 以上の情報を踏まえてスケールについて考えなければならない。
- 2019年のクリケットワールドカップを想定(ニュージーランドvsインドの試合)
- 25M+
- 同時接続数の数
- 1M+
- 1秒当たりのリクエスト数
- 10 Tbps+
- 帯域使用
- これはインドのインターネットの70~75%の帯域を占める。
- 10B+ (100億)
- クリックストリームメッセージの数
GameDay
- 実際のゲームを想定して負荷をかける
Project HULK
- 負荷を発生させる
- パフォーマンスとtsunamiテスト
- カオスエンジニアリング
- 機械学習を用いたトラフィックパターン
合計スペック
- 108,000CPU
- 216 TB RAM
- 200 Gbps Network out
- 8の地域
LoadGenerationの構造
- 複数リージョンに立てたEC2から負荷をかける
スケーリングは時間との競争だった
- 毎分1Mの成長率
- アプリケーションの起動時間が数分かかる
- 90秒の修正時間がある
- プッシュ通知
- 完全にバックアップされたAMI
AWSのAutoScalingを使用しない理由
- AWS上のスケーリングの方法として一番最初に考えられるのがAutoScaling
- これを採用しなかった理由
-
容量不足エラーが発生することがある
- AutoScalingGroupに複数のインスタンスタイプを指定できなかった(当時の話。今はアップデートされて指定できるようになっています。)
- AutoScalingのステップサイズ
- 再試行とexponential backoffの仕組みの存在
既に試されたスケーリング戦略
- あらかじめ必要な試合開始前のインフラ
- リクエスト数またはプラットフォームの同時実行性に基づいたスケールアップ
- 平衡性に基づいたプロアクティブな自動スケールアップ
- EC2スポットフリートの使用
- 様々なインスタンスタイプ
カオスエンジニアリングの実際の中身
- プッシュ通知
- Tsunami Trrafic
- 遅延スケールアップ
- 帯域幅の制限
- 待ち時間を増やす
- ネットワーク障害(CDN)
カオスエンジニアリングでどんな答えを探すのか
- 各システムの限界点
- どのぐらいの勢いで死ぬのか
- ボトルネックと弱点
- 未発見の問題と隠されているパターン
- ネットワークアプリケーション等の障害
緊急時モード
- 不要なサービスを停止する。
- P0サービスだけは常に稼働させておく
- ネットワークの大部分が動作不能になった場合でも限られた機能だけは維持する。
重要なポイント
- 常に失敗に備える
- ユーザーの行動を理解する
- ぶっ壊れても大丈夫なようにしておく
おしまい
さいごに
大規模なストリーミング配信のネットワーク負荷に耐えるためにどのようなことをしているのかのセッションでした。負荷の想定って難しく、またテストも多岐に渡るものでどんなことに気を付けておかなければならないのかを考えておく必要があるんだなと勉強になりました。
AWSのAutoScalingを採用しなかった理由なんかも聞けて楽しかったです。
18
