クッキングライブアプリの高速開発

AWS Summit Tokyo 2018

Transcript

1. クッキングライブアプリの 高速開発 クックパッドが仕掛ける新規事業 渡辺 慎也 岩間 雄太
2. 自己紹介 • 渡辺 慎也 ◦ twitter.com/wata_dev • クックパッド株式会社 ◦ メディアプロダクト開発部部長 • CookpadTV 株式会社 ◦ 取締役 CTO
3. レシピ動画事業注力の為、子会社を設立 new!
4. 目指す 3 つの No.1
5. 目指す 3 つの No.1 レシピ動画数 No.1 レシピ動画広告 No.1 レシピ動画ユーザー課金 No.1 クッキング LIVEで 新しい料理体験 スマホなしで 2 時間で、誰もが驚く レシピが決まる 1 分動画を。 cookpad studio storeTV cookpadTV
6. Image Area cookpad studio 2 時間で、誰もが驚く 1 分動画を。
7. Image Area storeTV スマホなしで レシピが決まる
8. Image Area cookpadTV クッキングライブで 新しい料理体験
9. 全体アーキテクチャ cookpad-tv-admin cookpad-tv-message cookpad-tv-api cookpad-tv-kinu ライブ動画配信基盤 fluentd-proxy streaming load Amazon Redshift bricolage HAproxy cookpad auth RTMP HLS 番組情報 コメント 認証 画像
10. AWS Elemental MediaLive • MediaLive がすぐに配信出来る状態にはならない ◦ 配信直前ではなく番組配信日時が決まったらすぐにリソース作成 ◦ 配信予定番組数分リソースが必要に ▪ →制限緩和依頼
11. AWS Elemental MediaLive • リリース当初は SecurityGroup が編集不可 ◦ 番組登録時は IP アドレスが未確定 EIP + HAproxy を前段において EC2 インスタンスの SecurityGroup を動的 変更することで対応
12. API サーバの Auto Scaling • ライブ配信は配信開始時に一気にアクセスが発生 ◦ 通常の Auto Scaling では間に合わない ◦ 事前に Auto Scaling しておく仕組みが必要 独自のデータ活用基盤で過去の 来場者数等を集計しアプリケー ションの MySQL に保存
13. API サーバーの Auto Scaling • 過去の来場者数をベースに事前 Auto Scaling ◦ desired count ではなく min capacity を上げる ◦ 放送開始時に min capacity を戻す（後は自然 scale-in に任せる） 詳細は Techlife「cookpadTV ライブ配信サービスの”突貫”Auto Scaling 環境構築」 http://techlife.cookpad.com/entry/2018/04/26/214500
14. コメント、ハート配信 • ライブの盛り上がり、コミュニケーションの要 ◦ 気軽にコメント、ハートを連打させたい ◦ コメントサーバは golang で別途実装 詳細は Techlife「クッキングLIVEアプリcookpadTVのコメント配信技術」 http://techlife.cookpad.com/entry/2018/04/12/180000
15. ライブ動画 配信基盤
16. 自己紹介 • 岩間雄太 ◦ twitter.com/ganmacs • クックパッド株式会社 ◦ 2017新卒 ◦ 技術部開発基盤グループ
17. ライブ動画配信基盤の責任とは • ライブ動画 ◦ 開始/終了時間 をもとにライブ動画配 信 • アーカイブ動画 ◦ ライブ終了後の見逃し配信
18. 設計方針 • 配信部分は S3 / MediaStore のような マネージドサービスに任せる • 避けたかったこと ◦ 人気番組があるからサーバ増強 ◦ 想定外のアクセスがあって落ちる よくスケールして運用が楽であること
19. AWS Elemental MediaLive 採用理由 • Wowza Streaming Engine と比較 ◦ 想定した設計を素直に構築できる ▪ S3 / MediaStore との連携 ◦ AWS の他のサービスとの連携 ◦ マネージドサービスに任せられる 詳細 : AWS Elemental MediaLive を使用したライブ動画配信アプリの基盤開発 http://techlife.cookpad.com/entry/2018/05/10/090000
20. アーキテクチャ • APIサーバがリクエストをもとに MediaLive に channel / input を作成 • ライブ動画は MediaStore を output • アーカイブ動画は S3 を output • S3 / MediaStore がオリジンサーバ ◦ エンコーダから直接配信しない • CDN 経由で配信
21. ライブ配信 1. 番組情報を受け取る 2. 1. をもとに MediaLive に channel / input を 作成 3. 開始時間の一定時間前 3.1. MediaLive のchannel を idle から running へ 3.2. AWS CloudWatch のアラーム設定 4. 配信されてきた動画をMediaStore へ ユーザは CDN を経由して視聴
22. アーカイブ配信 • MediaLive の Archive Output Group • 出力先を S3 へ • ライブ配信が終了したら S3 から動画を 集めて変換
23. 工夫した点 • MediaLive の状態遷移 ◦ 稀に running 状態にならないことがあった • 動画の配信検知 ◦ CloudWatch のアラーム設定 • Archive Output Group
24. MediaLive の状態遷移 • MediaLive で配信するためには running にする必 要がある • idle から running にならないことがあった • 一定時間 running にならなければ channel を再作 成するようにして対応している
25. 動画の配信検知 • 配信検知用のデーモンを実装 • 開始検知 ◦ アーカイブの S3 Event を使用 ◦ 1つ目の動画作成されると SQS に通知 • 終了検知 ◦ MediaLive の Network out を使用 ◦ 当初は両方 Network out
26. Archive Output Group の動画フォーマット • 数秒ごとに ts ファイルを作られる • S3 Multipart Upload で細切れの ts ファイル を結合 • 1つの ts ファイルを社内動画変換サービスへ ◦ 動画変換サービスのバックエンドは ElasticTranscoder S3 Multipart Upload: https://docs.aws.amazon.com/AmazonS3/latest/dev/mpuoverview.html
27. 今後の開発 • 演者との更なる双方向コミュニケーション機能の実装 ◦ アンケート、スタンプ、特別なコメント ◦ AWS AppSync を利用 • 有料機能の実装 ◦ 都度課金、継続課金 • トライアルとしてグローバル展開
28. We are hiring! https://cookpad.jobs/