Tweet
Tweet

Slide 1

Slide 1 text

©MIXI 年間版1秒動画2023 大量配信の裏側 Vantageスタジオ みてね事業部 Data Engineeringグループ 浜田 恭平

Slide 2

Slide 2 text

©MIXI 自己紹介 ● 浜田 恭平 ( Kyohei Hamada ) ● Twitter: @haman29, GitHub: @haman29 ● 三児の父（9y / 5y / 1y）、育児休業1年 ● 2017年 株式会社ミクシィ (現 株式会社MIXI) 入社 ○ 2017年〜 モンスターストライクSRE ○ 2018年〜 ライブエクスペリエンス事業本部サーバエンジニア ○ 2019年〜 みてね事業部 Data Engineering グループ（現在） ● 普段は Ruby を書いています 2

Slide 3

Slide 3 text

©MIXI 3 子どもの写真・動画をご家族で共有するアプリ 家族アルバム みてね ※ (株) MIXI 調べ。iOS・Android™ アプリ登録者数、ブラウザ版登録者数の合計 


Slide 4

Slide 4 text

©MIXI Data Engineering グループ 機械学習技術を用いた自動提案・自動編集機能の開発・運用 ● MLチーム　３名（兼任２名） ○ 機械学習モデルに関わる研究開発（モデルの実装・訓練・評価・改善） ○ 機械学習モデルを動かすコンテナの作成や運用 ● バックエンドチーム　４名 ← ここに所属しています！ ○ 写真・動画を解析するメディア解析パイプラインの開発・運用 ○ 各種レコメンドロジックの実装 ○ Ruby, Rails, ActiveRecord, BigQuery, FFmpeg, ImageMagick 4

Slide 5

Slide 5 text

©MIXI 関わっている機能 5 1秒動画 人物ごとのアルバム

Slide 6

Slide 6 text

©MIXI 関わっている商品 6 フォトブック 写真プリント アニバーサリーブック TV版DVD カレンダー みてね年賀状

Slide 7

Slide 7 text

©MIXI お品書き ● 年間版1秒動画のお話 ● 配信件数が年々増加する課題 ● 2023年の取り組み ○ 施策1. 1月1日の0時から生成し続ける ○ 施策2. 本番環境での負荷テスト ● 1月1日 本番当日 ● まとめ 7

Slide 8

Slide 8 text

©MIXI 1秒動画 お子さまの成長・思い出がギュッと詰まったダイジェスト動画 ● 四季版 ● 月版（プレミアム） ● 年間版（プレミアム）→ 本日はこちらのお話 8

Slide 9

Slide 9 text

©MIXI 年間版1秒動画：本体の仕様 ● 最長 3分超え ○ イントロ + ((月タイトル + 5 シーン) * 12ヶ月) + アウトロ ● シーン：3.1秒 ○ 動画：1件を切り出し ○ 写真：4件をタイル表示など ● 全 60 シーン ○ 1ヶ月あたり最大 5 シーンずつ * 12ヶ月 ○ 各シーンを 0.5 秒ずつクロスフェード ● オリジナルBGM 9

Slide 10

Slide 10 text

©MIXI 年間版1秒動画：生成フロー 10 １．写真・動画の解析（メディア解析） ○ 写真・動画がアップロードされるとバックグラウンドで解析処理が走る ○ メディア解析パイプライン（Ruby, Amazon SQS, Sidekiq） ○ 機械学習モデル（Python） i. 顔検出、人物検出 → 「1秒動画」で利用 ii. 顔の姿勢推定、年齢・性別判定、特徴量抽出 →「人物ごとのアルバム」で利用 ○ レコメンドに利用するため、スコアを事前計算しておく ２．生成対象家族の抽出 ○ プレミアム加入家族を定期的に抽出しておく

Slide 11

Slide 11 text

©MIXI 年間版1秒動画：生成フロー 11 ３．素材選択 ○ 機械学習技術を用いたルールベースのレコメンドロジック ○ スコア付け i. 顔検出 ii. 人物検出（動画のみ） iii. 家族みんなに公開 iv. お気に入り v. コメント数 ○ 撮影日時を均等にする。日ごと、週ごと、月ごとのグルーピング。 みてねのMeetup #4 『1秒動画の作り方 〜深層学習とデータ分析で最高のダイジェスト動画を作る〜』を開催しました

Slide 12

Slide 12 text

©MIXI 年間版1秒動画：生成フロー 12 ４．1秒動画の生成 ( Transcoder ) ○ Transcoder と呼ばれるコンポーネント（Ruby） ○ Sidekiq Batch（Sidekiq Pro 限定の機能）によるパイプライン処理 ○ FFmpeg コマンドを利用 i. 各素材の回転・切り出し・加工 ii. 全ての素材を結合、BGMをつける iii. Amazon S3 に格納する ５．配信

Slide 13

Slide 13 text

©MIXI 年間版1秒動画：歴史 13 機能 インフラ 2020年 リリース AWS OpsWorks 2021年 誕生月アニメーション タイトルの多言語化（英語、ドイツ語、フランス 語） AWS OpsWorks, Amazon EKS 2022年 スペイン語追加 Amazon EKS 2023年 BGM のローカリゼーション （欧米圏、アジア圏） Amazon EKS

Slide 14

Slide 14 text

©MIXI 配信件数が年々増加する課題 14

Slide 15

Slide 15 text

©MIXI 配信件数が年々増加する課題 15

Slide 16

Slide 16 text

©MIXI 年間版1秒動画：要件 ● 1月1日〜12月31までに撮影した1年間の写真・動画が対象 ● 【重要】1月3日までに全てのご家族に配信する ● すなわち、およそ2日間で1秒動画を生成する必要がある 16

Slide 17

Slide 17 text

©MIXI 高負荷が予想されるポイント ● ３．素材選択 ○ 四季版や月版と比べてレコード数が多い ■ 1家族あたり最大で数十万件の写真・動画が対象 ○ レコメンドに必要な関連レコードも合わせて取得する ○ クエリの流量がどうしても多くなる、DBに高負荷が掛かる ■ Amazon Aurora の Reader Endpoint を利用 ● ４．1秒動画の生成（Transcoder） ■ 年間版1秒動画を1本生成する ● 掛かる時間は平均約45分 ● 100を超える Sidekiq Worker プロセス数 17 1本の年間版1秒動画を作るだけでそれなりの難易度がある

Slide 18

Slide 18 text

©MIXI 昨年までのふりかえり ● 毎年トラブルが多発し、都度対応が必要な状況 ○ 素材選択Workerのクエリが刺さる ○ Spot インスタンス枯渇 ○ DBのコネクション数が上限に達する ● 昨年は1月2日に配信遅延、1月3日に帳尻を合わせた ○ ギリギリ間に合った 18 過去の経験を踏まえた上で、今年はもっと上手くやりたい

Slide 19

Slide 19 text

©MIXI 施策1. 1月1日0時から生成し続ける 19

Slide 20

Slide 20 text

©MIXI 施策1. 1月1日0時から生成し続ける ● 昨年まで：デイリーバッチ ○ 生成対象の家族を２グループ（A, B）に分割 ○ 1月1日10時に Aグループを生成開始、1月2日13時に配信 ○ 1月2日10時に Bグループを生成開始、1月3日13時に配信 ● 背景・課題 ○ 四季版・月版のロジックをそのまま流用する実装 ○ 四季版・月版では、長い時間を掛けてゆっくり生成することが暗黙的に許容さ れていたので、サーバ負荷が高くなりすぎない程度に生成数を調整すること ができた ○ 年間版の場合、2日間で全て生成しきる必要がある ○ 現状のつくりではサーバ負荷のピークが瞬発的にくる 20

Slide 21

Slide 21 text

©MIXI 施策1. 1月1日0時から生成し続ける ● 今年：デーモンプロセス ○ 1月1日0時に生成開始、生成できた分を1月2日13時に配信 ○ 繰越分を1月3日13時に配信 ● 効果 ○ 瞬発的なサーバ負荷を軽減することができた ○ ゆっくり絶えず生成し続けることでスループットも改善した 21

Slide 22

Slide 22 text

©MIXI 施策2. 本番環境での負荷テスト 22

Slide 23

Slide 23 text

©MIXI 施策2. 本番環境での負荷テスト ● 処理件数は昨年の倍になる予想 ● 1月3日の配信に間に合わせるために必要なスループットを試算 ● = スループット目標値 ● 目的 a. スループット目標値を出せるコードとインフラを用意すること b. 効率よくマシンリソースを使うこと c. 不具合やエラーを検知すること 23

Slide 24

Slide 24 text

©MIXI 手順 ● BigQuery で対象家族の抽出（数千件） ○ プレミアム家族からサンプリング ○ 写真・動画数の多い上位5位の家族を含める ● 1秒動画生成ジョブを一気に積む ○ Sidekiq の push_bulk ● メトリクスの確認 ○ New Relic ■ レスポンスタイム、スループット ○ Grafana ■ Amazon EKS の Node や Pod の CPU / Memory を確認 ■ 1秒動画の生成数を Amazon CloudWatch Metrics に記録 24

Slide 25

Slide 25 text

©MIXI 各種パラメータ ● 素材選択Worker 25 ひとまず昨年の設定ではじめる

Slide 26

Slide 26 text

©MIXI 各種パラメータ ● Transcoder 26 ひとまず昨年の設定ではじめる

Slide 27

Slide 27 text

©MIXI 負荷テスト1回目 27

Slide 28

Slide 28 text

©MIXI 素材選択Worker ● 極端に実行時間の長いジョブを観測 ● 写真・動画を数十万件持つ家族がタイムアウト 28

Slide 29

Slide 29 text

©MIXI Transcoder (Memory) ● Node の Memory にゆとりがある 29

Slide 30

Slide 30 text

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

Slide 31

Slide 31 text

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

Slide 32

Slide 32 text

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

Slide 33

Slide 33 text

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

Slide 34

Slide 34 text

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

Slide 35

Slide 35 text

©MIXI Transcoder (スループット) ● スループット目標値の 69% ほど ○ 1秒動画パイプライン全体を管理する Sidekiq Worker 35 ● pod 数 目標値は このあたり

Slide 36

Slide 36 text

©MIXI 負荷テスト1回目：結果 ● スループットが目標値に到達する前に、用意していた件数を全て捌ききってし まった。 ● 翌日、もう一度負荷テストをすることになった。 36

Slide 37

Slide 37 text

©MIXI 変更点 ● 素材選択Worker ○ 数十万件の写真・動画と関連 レコードを取得するクエリが刺 さっていたので、クエリ自体の チューニング ● Transcoder ○ パラメータチューニング ○ CPU 100% に近づけたい ○ FFmpeg `-threads` を 2 に してみる ○ maxReplicaCount も増やす 37

Slide 38

Slide 38 text

©MIXI 負荷テスト2回目 38

Slide 39

Slide 39 text

©MIXI 素材選択ワーカー 39 実行時間の長いジョブを削減

Slide 40

Slide 40 text

©MIXI Transcoder (CPU / Memory) 40 （12:00~13:40）CPU を効率的に使えている

Slide 41

Slide 41 text

©MIXI Transcoder (スループット) 41 スループット目標値の105%達成 （最終的に maxReplicaCount: 3000 から 4000 に上げた） 目標値は このあたり

Slide 42

Slide 42 text

©MIXI 1月1日本番当日 42

Slide 43

Slide 43 text

©MIXI 1月1日本番当日 43 ● 1月2日10時に全て生成が完了！ ● 1月2日13時に全てのご家族に配信！ ● 1月3日までに配信する要件を大幅に達 成！ ● スループット目標値の112%！ ● エラー 0 件！ ● 1月3日のシフトを削減！最高！ 目標値は このあたり

Slide 44

Slide 44 text

©MIXI まとめ 44

Slide 45

Slide 45 text

©MIXI まとめ ● 年間版1秒動画2023 大量配信の裏側 ● 配信件数が年々増加する課題 ● 2023年の取り組み ○ 施策1. 1月1日0時から生成し続ける ○ 施策2. 本番環境での負荷テスト ● 結果、1月1日の本番当日はアクシデントがなかった ● お正月三が日に全てのご家族に年間版1秒動画をお届けすることがで きた 45