幕張メッセに日が暮れる頃、AWS Summitの参加者が続々とQVCジャパンのオフィスに集まってくる。放送業界の関係者を中心に開催されているMedia-JAWSの第2回勉強会は、今回もキー局、地方局、動画配信事業者などバラエティ豊かな登壇者。まずは前半のセッションをお伝えする。
デジアサが手がけた視聴者参加型コンテンツのAWS的舞台裏
今年発足したばかりにもかかわらず、すでに3回目となる勉強会となったMedia-JAWS。2019年6月12日に開催された「Media-JAWS 【第2回】re:Late～AWS Summit初日夜は、参加者同士で盛り上がろう！～」をテーマに据え、AWSとの関わりを語るセッションとLTが披露された。
トップバッターはデジアサ チーフエンジニアの小南 英司さん。デジアサは大阪の朝日放送（ABC）のグループ会社で、デジタルコンテンツを扱っている。もともと字幕制作からスタートし、Web／データ放送のコンテンツ制作、システム開発などを手がけており、昨年はAWSのSelect Consulting Partnerも取得している。小南さんはサーバーサイドからアプリの実装まで幅広く手がけており、「プリキュア応援アプリ」「高校野球速報アプリ」「ライブ動画配信システム on Mac」などを担当したという。
デジアサ チーフエンジニアの小南 英司さん
今回の話は放送と連動した視聴者参加型コンテンツだ。放送の世界は通信のように基本的に輻輳がない世界なので、視聴者参加型コンテンツでも一発勝負でミスはできず、高い安定性が求められる。また、TVの告知効果はやはり高く、サイトに一瞬でアクセスが集中し、バーストトラフィックが発生する。一方で、視聴者参加型コンテンツは付加価値的なサービスなので、予算や納期も限られている。高い安定性と限りあるリソースをABCではどのように両立しているかが今回のテーマになる。
AWSをベースにしたABCの視聴者参加型システムは、投票データの受付、集計処理、結果データの表示、静的サイトのホストなどを実現するために、Lambda、API Gateway、Kinesis、DynamoDB、S3、CloudFrontなどサーバーレス構成を採用する。サーバレスを採用することで運用保守のかかる人的コストが削減され、特番時に使った分だけで済むというコストメリットがある。一方で、最大負荷を考慮する緻密な設計とチューニングが必要で、サービス仕様を正しく理解する必要があるという。
インフラもコードもAWS SAMを用いた一括管理を行なっている。たとえば、権限に応じたIAM Roleや適切に設定されたCloudWatch Alarmなどの作成、Lambdaのソースコード管理などもAWS SAMで行なっており、すべてAWSリソースをテンプレートに記述している。こうした継続的なデプロイの結果、人為的なミスは大幅に軽減され、他リージョンへの展開や本番環境への反映もコマンド1つで実現する。なにより主要な機能をテンプレート化して共用することで、属人化の排除と品質の一定化が図れるという。
また、安定運用に重要な負荷対策だが、前述したように視聴者参加コンテンツは短時間に大量のアクセスが集中することになるため、トラフィックを徐々に下げながら受け止めることが重要だという。
たとえば、220万のユーザーが3秒に1回スマホアプリをタップすると、1秒間に60万タップされることになる。こうしたPOST処理をアプリでは10秒に1回送る仕様にし、API Gatewayでは2万／秒でリクエストを受け止め、ストリームをKinesis Data Streamで溜め込む。これをLambdaで1000レコード／秒ごとにDynamoDBに書き込み、新旧イメージを比較しながら集計データを更新している。同時に想定外のデータによる想定外の挙動を排除すべく、API GatewayやLambdaを用いて、パラメーターや送信データのバリデート、異常データの排除なども実施している。一方、GET処理においてはCloudFrontとAPI Gatewayのキャッシュを活用している。
バーストトラフィックをアプリやキャッシュで受け止める
普段あまり意識しない視聴者参加型コンテンツの裏側を知ることができたセッションだった。
毎年1.5PB増える動画をAmazon Glacier Deep Archiveでバックアップ
DMM.comで動画配信事業を手がける菊地弘晃さんは、「VODのディザスタリカバリをAWSで考えてみる」という。AWS Summitに参加できず、幕張に直行してきた菊地さんだが、参加できなかった人は会場にもちらほらいたので、ほっと一安心。ちなみにDMM.comとFANZAは別のサービスである。
DMM.com 動画配信事業部 菊地弘晃さん
今回のテーマはディザスタリカバリ（DR）なので、いわば災害対策。「首都圏に直下型地震が来るって言われてるじゃないですか。2012年には4年以内に70％の確率で来ると言われていましたが、すでに2019年です（笑）」と言いながら、大規模な地震はいつ起こってもおかしくないのは事実だ。基本、DRにおいてはRTOと呼ばれる目標復旧時間、RPOと呼ばれる目標復旧時点、RLOと呼ばれる目標復旧レベルの3つの指標がある。DMM動画に置き換えると、RTOが「配信再開までの時間」、RPOは「どれくらいのコンテンツ数を復旧するか」、RLOは「動画の品質をどこまで落とすか」になるという。
現状、DMM動画のバックアップは、「真心を込めて、HDDで、手動で」行なわれている。これには理由があり、歴史的な経緯で安定運用されているほか、とにかく非常に安価なのが理由だ。しかし、バックアップとしてHDDを活用するのはやはり困難で、今回エンコーダースタックの入れ替えとともにバックアップのリプレースも進めることにしたという。
おもにコストの安さでバックアップはHDDを採用
さて、Media JAWSに登壇しているので、なにを用いているかは自明だが、バックアップ先になにを使うかはもちろん検討した。Amazon S3のアーカイブサービスであるAmazon S3 Glacierがそこそこ安いAWS、Coldlineでもそこそこ高いGCP、コスト上限があるので安心という某光ディスクアーカイブサービスという3つの選択肢が検討された。結果として、「値段とDR時に暫定運用する際の容易さ」でAWSを選定した。
とはいえ、DMM動画は毎年1.5PB増えるため、Glacierでさえも5年間で1億円を超えてしまう。しかし、既存のGlacierの1/4という価格であるAmazon Glacier Deep ArchiveがいよいよGAとなった。「1TB保存して、1ヶ月1ドル。これしかねえと思った」（菊地さん）とのことで、Glacier Deep Archiveに決定。「これでも2500万円はかかるんですけど、1億円と言われたあとに2500万円と言われたので、めちゃ安いと感じてしまった（笑）」とは菊地さんのコメントだ。
爆安のAmazon Glacier Deep ArchiveがいよいよGAへ
Deep Archiveの登場でバックアップをとらないという選択肢はなくなった
構成としては、エンコーダースタックのデータをGlacierにアーカイブし、いざ災害が起こった際はDeepArchiveからS3にリストアし、これをトリガにLambdaをキック。Media Elemental Converterでエンコードし、Elemental MediaPackageでパッケージ化し、CloudFront経由で配信するという流れを想定した。
このシステム構成を前提に、菊地さんはDR時の試算を披露する。総ファイル時間は7.3万時間で、1年で1.5PB増える状態。DR時には1ヶ月間、低画質のみでの配信を行なうという条件で、1年間分のバックアップコンテンツを1ヶ月だけAWSから配信することになる。Glacierからのデータ取り出し、S3への保存、エンコードやパッケージング、CloudFront経由での配信など全部含めると月に9000万円（！）ぐらい。「高いとみるか、安いとみるかは難しく、うちだとたぶんゴーサインが出ると思います」と菊地さんは語る。
現在、菊地さんは前述したRTO、RPO、RLOなどの条件を踏まえて、コストの最適化を実施中。「RTO：時間がかかってもいいからオンプレから配信」「RPO：売れ筋コンテンツのみ配信する」「RLO：低画質1本ではなく、複数画質にする」などさまざまなオプションから選択する必要があるという。たとえば、コストの9割近くを占めるCloudFrontのようなCDNは使用せず、オンプレで構築した配信システムからストリーミング配信を行なうといったこともありえるという。
最後、菊地さんは「今日、僕はDeep Archiveの宣伝に来たんですけど（笑）、Deep Archiveの登場により、もはやバックアップをとらないという選択肢はなくなったと思います。動画のDRに関してはAWS一択なのではないかと」とまとめた。
