Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

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

AWS Summit Tokyo 2018

Yuta Iwama

May 29, 2018
Tweet

More Decks by Yuta Iwama

Other Decks in Technology

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/