Amazon Web Services ブログ
NTTドコモにおける Leminoの大規模ライブ配信を支えるアーキテクチャ（第一回）
本稿では株式会社NTTドコモ（以下、docomo）において、映像配信サービス『Lemino』の開始にあわせて配信基盤を再構築し、同時視聴ユーザが数百万規模のライブ配信を実現した取り組みについて、全4回に分けてご紹介します。この取り組みについて概要をご覧になりたい方は導入事例ページもご覧ください。
全４回の内容は以下からアクセスできますので、ご興味のある回をご覧いただければ幸いです。
第二回 アクセスの急増に対する対応策〜キャッシュ戦略とバックエンドの保護〜
第三回 クラウドを活用したテスト効率化 〜リリース前・リリース後に何をするべきか〜
第一回 適切なデータストアの選定とアーキテクチャの見直し
1.はじめに
docomoの『Lemino』は、2015 年から提供していた『dTV』をリニューアルする形で誕生した映像配信サービスです。
既存システムにとらわれず、新機能を素早く提供するとともに大規模なライブ配信を実現するために、データストアを改めて選定し、全てのアーキテクチャを見直しました。
dTV では目標需要を満たす設備が構成上の制約で準備できませんでしたが、Lemino では需要予測に応え、なおかつ低コストに配信可能になっています。
2.旧システムでのスケーリングの阻害要因
複数のアプリケーションでデータベースを共有すると、密結合が生じ、パフォーマンスの問題が発生する可能性があります。
以前の dTV のシステムでは、データベースはAmazon Aurora PostgreSQLをシャーディングせずに 1 クラスタで、すべてのアプリケーションで共有し、密結合の状態で使用していました。ただし、dTV のシステムは数百万規模の同時視聴のような大規模なライブ配信の要件が無かったため、Amazon Aurora PostgreSQL 1クラスタでも十分運用できていました。
Amazon Aurora 自体は Lemino でも活用していて、一般的な RDBMS を使いたいユースケースにマッチしています。データベース管理タスクをマネージドに提供してくれるため、データベースの管理作業が楽になります。
一方で、大規模なライブ配信の際にコンピュート（Amazon EC2）の台数を数千にまで増やすことを検討・検証した際、PostgreSQL へのコネクション数増加によるリソース逼迫とトランザクション管理が課題になり、スケーラビリティを阻害する要因になっていました。
Cache や Read Replica の利用、RDS Proxy の活用による接続プーリング等、Amazon Aurora PostgreSQL のままで改善可能なことは検討しましたが、ライブ配信は開演時に急激にアクセスが来るうえに、セッションやデバイスの管理のために書き込み処理が避けられなかったため、どうしても急激なトランザクション増加に耐えられるように Writer のインスタンスのサイズを事前に大きくしておかなければなりませんでした。Writer のインスタンスのサイズは無限に大きくできるわけではありませんし、Writer インスタンスを変更するためにサービスの瞬断を伴う運用作業が必要になり、ユーザー影響が少ない時間帯に作業する労力がかかりました。常に Amazon Aurora PostgreSQL のインスタンスを大きなサイズにしておくことは費用の観点から難しく、作業は停止が許容されるメンテナンス時間帯で終わらせなければなりません。Amazon Aurora PostgreSQL に接続するコンピュートの数が増えれば増えるほど、DBを大きいものに変更した後にフロント側のコンピュートをスケールアウトするための時間がかかるようになり、予定していた時間の中で、想定数のコンピュートを起動し終えることは現実的ではありませんでした。
また、機能面のスケーラビリティも課題でした。Lemino は視聴ユーザーに合わせて広告型無料配信 / 月額有料配信 / PPV 配信など、様々な形態で提供し、感情検索やスタンプ、コミュニケーション機能などの機能拡張も実施が決定していました。このようなサービス追加は密結合なシステムでは影響範囲が大きくなるため困難でした。アプリケーションの更新時や故障時の影響を小さくするために、サービス分割を見直すことは必要不可欠でした。
図1.dTVのアーキテクチャ概要
3.Leminoでの設計方針
性能面・機能面のスケーラビリティを向上するために、RDBMS 以外のデータベースも含め、機能ごとに最適なデータストアを選定しました。既存のアプリケーションから、映像配信に必要となる基本機能とその画面遷移を検討、配信時にアクセス数が増える導線を確認し、どの機能がどのような API でデータにアクセスするかを整理して、書き込み・読み込み負荷を推測し、どこでコントロールできるかを確認していきます。
その上でデータストアを選定していきますが、その際、以下のような Step で検討しています。
Step1 データ取得時の検索条件およびリレーションの要否
アプリケーションがデータを取得する際の検索条件およびリレーションの要否を整理します。どのようなクエリが必要なのか、Primary Key 検索だけでデータアクセス要件が満たせるのか、もしくは複数のカラムまたは複数テーブルを結合した検索が必要かを検討します。
Step2 アクセス機能と負荷
どの機能が使われるとどのデータにアクセスするか、書き込み・読み込みを分けてそれぞれの想定負荷を検討します。
Step3 アクセスレコードの分散
特定のレコードにアクセス集中する場合は、どの程度キャッシュが活用できるのかを検討します。
図2. Lemino のデータストア選定検討サンプル
この検討は Step1 から 3 までを実施して終了にはなりません。実際は、アプリケーションに対してユーザーがどのような導線でアクセスしてくるか、ユーザのdアカウントログイン有無や利用デバイスにより、API のアクセス数そのものが大きく変わります。ライブ配信などによるスパイクアクセス時の最大負荷を計算し、実際に負荷をかけて検証していくなかで、このデータストア選定、テーブル設計で問題ないか確認し、ボトルネックを洗い出しておくことが重要です。
4.Leminoで主に利用しているデータストア
Lemino のシステムは映像そのものを配信する部分や dアカウントログイン、月額サービス契約導線やクレジットカード決済など様々なサービスで構成されていますので、ここで紹介するデータストアはあくまで Web やモバイルのアプリケーションのバックエンドで利用している一例です。AWSのマネージドサービスを活用することで、データベースそのものの学習コストは少なく済み、複数種類のデータベースを併用しても問題なく運用できています。
あらゆる規模で一桁ミリ秒のパフォーマンスを実現する、サーバーレス NoSQL フルマネージドデータベース。秒間数十万の高い読書き性能が必要、かつ、PK でのクエリでほとんどの要件が満たせるデータを管理。
※ 各種セッション情報、および、ユーザーデータを管理
※ 特定レコードに負荷が集中する場合は DynamoDB Accelerator (DAX) を利用
リアルタイム検索のスケールアウトをマネージドに実現できるマネージドサービス。高い読込み性能が必要で、かつ、複数のキーで検索が必要なデータを管理。
※ コンテンツデータやエモートラインなど、検索用データを管理
PostgreSQL との完全な互換性を持ち、グローバル規模で活用されている高パフォーマンスと可用性を実現する RDBMS のマネージドサービス。
複数テーブルを結合したトランザクション管理が必要なデータを管理
※ ログイン済みの会員データ、月額契約・購入情報、集計用アーカイブを管理
図3. Lemino のアーキテクチャ概要
5.まとめ
第一回の事例では、パフォーマンスと機能面のスケーラビリティを確保するために Lemino の開発で実施した、適切なデータストアの選定とアーキテクチャの見直し方法をご紹介しました。
スパイクアクセスに耐え、アジリティ向上を目指してリアーキテクトを検討中の皆様の参考にしていただければ幸いです。
次回は以下をご紹介します。
第二回 アクセスの急増に対する対応策〜キャッシュ戦略とバックエンドの保護〜
著者について
株式会社NTTドコモ
第一プロダクトデザイン部 映像サービス担当 松原拓也
株式会社NTTドコモで提供している映像配信サービス『Lemino』のアーキテクト及び、バックエンドシステムのリードエンジニア、プロジェクトマネージャーを担当。
アマゾン ウェブ サービス ジャパン合同会社
技術統括本部 ストラテジックインダストリー技術本部 津和﨑美希
通信業界のお客様を担当するソリューション アーキテクト。普段は通信業界のお客様の AWS活用 を支援していますが、Observability については AWS 社内でコミュニティ活動をしています。ここ数年、動画配信等、Media Service のご支援にも手を広げるなど、幅広い AWS 活用をご支援しています。