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

年間版1秒動画2023 大量配信の裏側 - MIXI TECH CONFERENCE 2023 DAY1

年間版1秒動画2023 大量配信の裏側 - MIXI TECH CONFERENCE 2023 DAY1

More Decks by 浜田 恭平 (Kyohei Hamada)

Other Decks in Programming

Transcript

  1. ©MIXI 自己紹介 • 浜田 恭平 ( Kyohei Hamada ) •

    Twitter: @haman29, GitHub: @haman29 • 三児の父(9y / 5y / 1y)、育児休業1年 • 2017年 株式会社ミクシィ (現 株式会社MIXI) 入社 ◦ 2017年〜 モンスターストライクSRE ◦ 2018年〜 ライブエクスペリエンス事業本部サーバエンジニア ◦ 2019年〜 みてね事業部 Data Engineering グループ(現在) • 普段は Ruby を書いています 2
  2. ©MIXI Data Engineering グループ 機械学習技術を用いた自動提案・自動編集機能の開発・運用 • MLチーム 3名(兼任2名) ◦ 機械学習モデルに関わる研究開発(モデルの実装・訓練・評価・改善) ◦

    機械学習モデルを動かすコンテナの作成や運用 • バックエンドチーム 4名 ← ここに所属しています! ◦ 写真・動画を解析するメディア解析パイプラインの開発・運用 ◦ 各種レコメンドロジックの実装 ◦ Ruby, Rails, ActiveRecord, BigQuery, FFmpeg, ImageMagick 4
  3. ©MIXI お品書き • 年間版1秒動画のお話 • 配信件数が年々増加する課題 • 2023年の取り組み ◦ 施策1.

    1月1日の0時から生成し続ける ◦ 施策2. 本番環境での負荷テスト • 1月1日 本番当日 • まとめ 7
  4. ©MIXI 年間版1秒動画:本体の仕様 • 最長 3分超え ◦ イントロ + ((月タイトル +

    5 シーン) * 12ヶ月) + アウトロ • シーン:3.1秒 ◦ 動画:1件を切り出し ◦ 写真:4件をタイル表示など • 全 60 シーン ◦ 1ヶ月あたり最大 5 シーンずつ * 12ヶ月 ◦ 各シーンを 0.5 秒ずつクロスフェード • オリジナルBGM 9
  5. ©MIXI 年間版1秒動画:生成フロー 10 1.写真・動画の解析(メディア解析) ◦ 写真・動画がアップロードされるとバックグラウンドで解析処理が走る ◦ メディア解析パイプライン(Ruby, Amazon SQS,

    Sidekiq) ◦ 機械学習モデル(Python) i. 顔検出、人物検出 → 「1秒動画」で利用 ii. 顔の姿勢推定、年齢・性別判定、特徴量抽出 →「人物ごとのアルバム」で利用 ◦ レコメンドに利用するため、スコアを事前計算しておく 2.生成対象家族の抽出 ◦ プレミアム加入家族を定期的に抽出しておく
  6. ©MIXI 年間版1秒動画:生成フロー 11 3.素材選択 ◦ 機械学習技術を用いたルールベースのレコメンドロジック ◦ スコア付け i. 顔検出

    ii. 人物検出(動画のみ) iii. 家族みんなに公開 iv. お気に入り v. コメント数 ◦ 撮影日時を均等にする。日ごと、週ごと、月ごとのグルーピング。 みてねのMeetup #4 『1秒動画の作り方 〜深層学習とデータ分析で最高のダイジェスト動画を作る〜』を開催しました
  7. ©MIXI 年間版1秒動画:生成フロー 12 4.1秒動画の生成 ( Transcoder ) ◦ Transcoder と呼ばれるコンポーネント(Ruby)

    ◦ Sidekiq Batch(Sidekiq Pro 限定の機能)によるパイプライン処理 ◦ FFmpeg コマンドを利用 i. 各素材の回転・切り出し・加工 ii. 全ての素材を結合、BGMをつける iii. Amazon S3 に格納する 5.配信
  8. ©MIXI 年間版1秒動画:歴史 13 機能 インフラ 2020年 リリース AWS OpsWorks 2021年

    誕生月アニメーション タイトルの多言語化(英語、ドイツ語、フランス 語) AWS OpsWorks, Amazon EKS 2022年 スペイン語追加 Amazon EKS 2023年 BGM のローカリゼーション (欧米圏、アジア圏) Amazon EKS
  9. ©MIXI 高負荷が予想されるポイント • 3.素材選択 ◦ 四季版や月版と比べてレコード数が多い ▪ 1家族あたり最大で数十万件の写真・動画が対象 ◦ レコメンドに必要な関連レコードも合わせて取得する

    ◦ クエリの流量がどうしても多くなる、DBに高負荷が掛かる ▪ Amazon Aurora の Reader Endpoint を利用 • 4.1秒動画の生成(Transcoder) ▪ 年間版1秒動画を1本生成する • 掛かる時間は平均約45分 • 100を超える Sidekiq Worker プロセス数 17 1本の年間版1秒動画を作るだけでそれなりの難易度がある
  10. ©MIXI 昨年までのふりかえり • 毎年トラブルが多発し、都度対応が必要な状況 ◦ 素材選択Workerのクエリが刺さる ◦ Spot インスタンス枯渇 ◦

    DBのコネクション数が上限に達する • 昨年は1月2日に配信遅延、1月3日に帳尻を合わせた ◦ ギリギリ間に合った 18 過去の経験を踏まえた上で、今年はもっと上手くやりたい
  11. ©MIXI 施策1. 1月1日0時から生成し続ける • 昨年まで:デイリーバッチ ◦ 生成対象の家族を2グループ(A, B)に分割 ◦ 1月1日10時に

    Aグループを生成開始、1月2日13時に配信 ◦ 1月2日10時に Bグループを生成開始、1月3日13時に配信 • 背景・課題 ◦ 四季版・月版のロジックをそのまま流用する実装 ◦ 四季版・月版では、長い時間を掛けてゆっくり生成することが暗黙的に許容さ れていたので、サーバ負荷が高くなりすぎない程度に生成数を調整すること ができた ◦ 年間版の場合、2日間で全て生成しきる必要がある ◦ 現状のつくりではサーバ負荷のピークが瞬発的にくる 20
  12. ©MIXI 施策1. 1月1日0時から生成し続ける • 今年:デーモンプロセス ◦ 1月1日0時に生成開始、生成できた分を1月2日13時に配信 ◦ 繰越分を1月3日13時に配信 •

    効果 ◦ 瞬発的なサーバ負荷を軽減することができた ◦ ゆっくり絶えず生成し続けることでスループットも改善した 21
  13. ©MIXI 施策2. 本番環境での負荷テスト • 処理件数は昨年の倍になる予想 • 1月3日の配信に間に合わせるために必要なスループットを試算 • = スループット目標値

    • 目的 a. スループット目標値を出せるコードとインフラを用意すること b. 効率よくマシンリソースを使うこと c. 不具合やエラーを検知すること 23
  14. ©MIXI 手順 • BigQuery で対象家族の抽出(数千件) ◦ プレミアム家族からサンプリング ◦ 写真・動画数の多い上位5位の家族を含める •

    1秒動画生成ジョブを一気に積む ◦ Sidekiq の push_bulk • メトリクスの確認 ◦ New Relic ▪ レスポンスタイム、スループット ◦ Grafana ▪ Amazon EKS の Node や Pod の CPU / Memory を確認 ▪ 1秒動画の生成数を Amazon CloudWatch Metrics に記録 24
  15. ©MIXI Transcoder (CPU) 30 • Node の CPU が100% 張り付き

    • 明らかに Pod の CPU 使いすぎ
  16. ©MIXI 31 Transcoder (CPU) • Node の CPU が100% 張り付き

    • 明らかに Pod の CPU 使いすぎ 修正(1) ・原因が FFmpeg コマンドで一部 `-threads` オ プションの指定漏れであることが発覚。 ・FFmpeg `-threads` オプションのデフォルト値 が CPU論理コア数。 ・つまり無指定の場合、 1 node で複数コンテ ナが動作する前提の K8s において node の vCPU数が指定された状態にあった(例 : c5.4xlarge であれば 16)。 ・修正した結果、 CPU の 100%張り付きが解 消。
  17. ©MIXI 32 Transcoder (CPU) • Node の CPU が100% 張り付き

    • 明らかに Pod の CPU 使いすぎ 修正(2) ・concurrency を 3 から 4 に増やす ・maxReplicaCount を 1000 から 1200 に増やす 修正(1) ・原因が FFmpeg コマンドで一部 `-threads` オ プションの指定漏れであることが発覚。 ・FFmpeg `-threads` オプションのデフォルト値 が CPU論理コア数。 ・つまり無指定の場合、 1 node で複数コンテ ナが動作する前提の K8s において node の vCPU数が指定された状態にあった(例 : c5.4xlarge であれば 16)。 ・修正した結果、 CPU の 100%張り付きが解 消。
  18. ©MIXI 33 Transcoder (CPU / スループット) • Node の CPU

    が100% 張り付き • 明らかに Pod の CPU 使いすぎ 修正(2) ・concurrency を 3 から 4 に増やす ・maxReplicaCount を 1000 から 1200 に増やす 修正(1) ・原因が FFmpeg コマンドで一部 `-threads` オ プションの指定漏れであることが発覚。 ・FFmpeg `-threads` オプションのデフォルト値 が CPU論理コア数。 ・つまり無指定の場合、 1 node で複数コンテ ナが動作する前提の K8s において node の vCPU数が指定された状態にあった(例 : c5.4xlarge であれば 16)。 ・修正した結果、 CPU の 100%張り付きが解 消。
  19. ©MIXI 34 Transcoder (CPU / スループット) 修正(2) ・concurrency を 3

    から 4 に増やす ・maxReplicaCount を 1000 から 1200 に増やす あれ、CPU 100%張り付い てた時よりもスループットが 下がっている...? • Node の CPU が100% 張り付き • 明らかに Pod の CPU 使いすぎ 修正(1) ・原因が FFmpeg コマンドで一部 `-threads` オ プションの指定漏れであることが発覚。 ・FFmpeg `-threads` オプションのデフォルト値 が CPU論理コア数。 ・つまり無指定の場合、 1 node で複数コンテ ナが動作する前提の K8s において node の vCPU数が指定された状態にあった(例 : c5.4xlarge であれば 16)。 ・修正した結果、 CPU の 100%張り付きが解 消。
  20. ©MIXI 変更点 • 素材選択Worker ◦ 数十万件の写真・動画と関連 レコードを取得するクエリが刺 さっていたので、クエリ自体の チューニング •

    Transcoder ◦ パラメータチューニング ◦ CPU 100% に近づけたい ◦ FFmpeg `-threads` を 2 に してみる ◦ maxReplicaCount も増やす 37
  21. ©MIXI 1月1日本番当日 43 • 1月2日10時に全て生成が完了! • 1月2日13時に全てのご家族に配信! • 1月3日までに配信する要件を大幅に達 成!

    • スループット目標値の112%! • エラー 0 件! • 1月3日のシフトを削減!最高! 目標値は このあたり
  22. ©MIXI まとめ • 年間版1秒動画2023 大量配信の裏側 • 配信件数が年々増加する課題 • 2023年の取り組み ◦

    施策1. 1月1日0時から生成し続ける ◦ 施策2. 本番環境での負荷テスト • 結果、1月1日の本番当日はアクシデントがなかった • お正月三が日に全てのご家族に年間版1秒動画をお届けすることがで きた 45