Amazon Web Services ブログ
NTTドコモにおける Leminoの大規模ライブ配信を支えるアーキテクチャ（第二回）
本稿では株式会社NTTドコモにおいて、映像配信サービス『Lemino』の開始にあわせて配信基盤を再構築し、数百万規模の同時視聴ライブ配信を実現した取り組みについて、全4回に分けてご紹介します。この取り組みについて概要をご覧になりたい方は導入事例ページもご覧ください。
全４回の内容は以下からアクセスできますので、ご興味のある回をご覧いただければ幸いです。
第二回 アクセスの急増に対する対応策〜キャッシュ戦略とバックエンドの保護〜
第三回 クラウドを活用したテスト効率化 〜リリース前・リリース後に何をするべきか〜
第二回 アクセスの急増に対する対応策〜キャッシュ戦略とバックエンドの保護〜
1.需要予測の難しさとキャッシュ戦略・バックエンドの保護の必要性
システムを設計するにあたり、どの程度リソースを用意するべきか、正確に推測するのは容易なことではありません。ビジネス目標に対応したスケーラビリティを確保しようとするのは通常のことですが、例えば、ある Live 配信のビジネス目標とされる視聴ユーザー数が A人だった場合、それに対応したシステムを作るには何が必要でしょうか？
まず、ビジネスの観点での需要予測を、システムを設計するのに十分な粒度に落とし込む必要があります。システムを設計するのに必要な需要予測は機能別の API ごとの最大ピークアクセスが想定されるべきです。例えば、配信開始時間があらかじめ告知されている Live の場合は、配信開始時間の数分前に視聴開始が集中することが想像できます。そうした場合には視聴開始にまつわる API を視聴ユーザー数 A人が数分間、数秒間といった短い間に実行する可能性があり、そのピークに耐える必要があります。配信開始時間が正確にわからない場合、視聴ユーザーA人はまばらにアクセス開始するかもしれません。配信の特性を踏まえて、過去の同様の配信時の実績データなどを踏まえた知見から予測していくことになります。
また、視聴開始以外の API にスパイクアクセスは必ずしもこないことも考慮すべきです。アプリケーションを初回ダウンロードしてユーザー登録をするための API はライブを見たいユーザーのなかで初回にアプリにアクセスするユーザーだけが実行する処理となり、ライブ直前に行う必要がある処理ではありません。事前にアプリをダウンロードし登録を済ませてくれたユーザーが多ければ、その API についての秒単位の需要予測は必ずしも高くないかもしれません。配信を視聴するための契約をする API やアカウントを作成するAPIについても同様です。余剰のリソースを無駄に確保しないためにも本当に高いトランザクションを捌く必要があるAPIはどれか、認識しておくことが重要です。
例）視聴ユーザー数 A人でも視聴開始のアクセス数は分散する
どの API がどの程度のスパイクアクセスに耐えるべきか、需要予測を適切に行うには過去の配信時の実績ベースのデータが有用です。過去の配信時の実績データを活かす仕組みが必要になります。これまでに行ったことがない配信を実施する場合、正確に需要予測をする難易度は上がります。
需要予測を正確に行うことができれば、多くのユーザーに最適なシステムリソースでサービス提供が可能になります。しかし、需要予測は必ず当たるとはかぎりません。急にその Live 配信が話題になり、視聴数が一気に跳ね上がる可能性があります。できるだけスケーラブルに、コスト効率よくサービス提供するためにはキャッシュ戦略が必要となり、需要予測が想定を超えた場合にビジネス影響範囲を小さくするためにはバックエンドの保護が必要になります。
2.キャッシュ戦略
キャッシュを活用することはバックエンドに何度も問い合わせることをしないため、より低レイテンシーでコスト効率よく、スパイク時の影響を最小限にすることにつながります。
AWS のサービスを活用するとデータ特性に応じた複数箇所でのCacheを作成することが可能で、Lemino では以下のように使い分けしています。
エッジロケーションというグローバルのネットワークを経由してコンテンツを配信。 応答がユーザー情報に依存しない API はCDN（Contents Delivery Network）でキャッシュすることで負荷及び応答性能を大幅に改善
例）クライアント向けの作品情報の取得
Amazon DynamoDB Accelerator (DAX)
更新頻度が少なく、アプリケーションからの読み込みアクセスが多いレコード
例）アプリケーション内での映像情報の取得
DynamoDB に RDS と同一のデータを持たせ、キャッシュ用途のように、ユーザーの読み込みリクエストで活用することで、高い秒間の読込み性能が必要なデータをスケーラブルに、運用負荷少なく管理
例）購入情報等
※RDS の Reader や ElastiCache を活用することも RDS の Read 性能を上げたい場合は選択肢ですが、ライブ配信開始時のような急激なスパイク負荷を想定する場合、インスタンス追加に伴うスケールアウト完了までの時間を許容できませんでした。その点、DynamoDB のオンデマンドキャパシティモードでは、該当テーブルの以前のピーク時のトラフィックの最大 2 倍まで即座にスケールできます。RDS の Reader や ElastiCache のノードの追加が流量の増加に間に合わなかった場合のサービスへの影響と運用の手間などを考慮し、DynamoDB に一部のデータを常に同期することを選択しています。
このほかに、アプリケーション側でも、ユーザに依存せず再利用可能なデータをローカルでキャッシュすることでデータストアの負荷を抑制しています。様々な場所で可能な限りキャッシュを活用することはバックエンドの保護につながっています。
3.バックエンドの保護
需要予測の精緻化とキャッシュの活用をしても、バックエンドに対して予測を上回るリクエストがくる可能性は0にはなりません。一部の API 負荷の想定外の高まりで、バックエンドの使用率が増えることでサービス全体に影響を与えることや、配信以外の共通基盤への影響は避けなければなりません。バックエンドの許容量やボトルネックとなる API の閾値をベースに、想定を超えるリクエストについてはスロットリングするか、待機させることが必要です。現在接続しているユーザーの処理を優先し、新規接続については仮想待合室などでコントロールを行えるようにする、等の工夫によりサービス全体への影響は避け、想定外のアクセス急増にも対応できるようにしておきます。
例えば、1分間でX回処理する性能と、1秒間でX回処理する性能では、当たり前ですが、事前に用意しておくべきシステムリソースが異なります。数秒待たせるだけで、必要なシステムリソースを抑え、スパイクアクセスに耐えきれないことによるサービス障害を抑えることが可能になるケースもあります。
そのアクセスはどの程度ならユーザー体験を損ねずに待たせることが可能か、どの程度時間があればリソースを追加することができるのかも検討しつつ、スパイクアクセスがサービス全面停止に繋がらないようにする必要があります。
Lemino のサービスでは大規模なスパイクアクセスが発生する場合には契約などの一部の導線に仮想待合室を設置しています。
仮想待合室のアーキテクチャは Virtual Waiting Room を参考にスケーラビリティを改良しています。
Lemino のサービスは複数のシステムが連携して動くため、dアカウントの認証などは別の担当チームがあり、自分たちのチームだけではスケールをコントロールできないことがあります。
最後の手段として、他システムも含めたバックエンドを保護するためにスロットリングさせることも選択肢です。
4.まとめ
アクセスの急増に対する対応策として、まずは需要予測を精緻化し、事前に必要となるシステムリソースを認識することが大切です。それを上回るスパイクアクセスに備えて、キャッシュ戦略とバックエンドの保護が大切であることをお伝えしました。
アクセスの急増を想定し、想定外に備えるシステムを検討中の皆様の参考にしていただければ幸いです。
次回は以下をご紹介します。
第三回 クラウドを活用したテスト効率化 〜リリース前・リリース後に何をするべきか〜
著者について
株式会社NTTドコモ
第一プロダクトデザイン部 映像サービス担当 松原拓也
株式会社NTTドコモで提供している映像配信サービス『Lemino』のアーキテクト及び、バックエンドシステムのリードエンジニア、プロジェクトマネージャーを担当。
アマゾン ウェブ サービス ジャパン合同会社
技術統括本部 ストラテジックインダストリー技術本部 津和崎美希
通信業界のお客様を担当するソリューション アーキテクト。普段はお客様のAWS活用を支援していますが、ObservabilityについてはAWS社内でコミュニティ活動をしています。ここ数年、動画配信等、Media Serviceのご支援にも手を広げ、幅広いAWS活用をご支援しています。