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チーム 3名(兼任2名) ○ 機械学習モデルに関わる研究開発(モデルの実装・訓練・評価・改善) ○ 機械学習モデルを動かすコンテナの作成や運用 ● バックエンドチーム 4名 ← ここに所属しています! ○ 写真・動画を解析するメディア解析パイプラインの開発・運用 ○ 各種レコメンドロジックの実装 ○ 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 1.写真・動画の解析(メディア解析) ○ 写真・動画がアップロードされるとバックグラウンドで解析処理が走る ○ メディア解析パイプライン(Ruby, Amazon SQS, Sidekiq) ○ 機械学習モデル(Python) i. 顔検出、人物検出 → 「1秒動画」で利用 ii. 顔の姿勢推定、年齢・性別判定、特徴量抽出 →「人物ごとのアルバム」で利用 ○ レコメンドに利用するため、スコアを事前計算しておく 2.生成対象家族の抽出 ○ プレミアム加入家族を定期的に抽出しておく

Slide 11

Slide 11 text

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

Slide 12

Slide 12 text

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

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 高負荷が予想されるポイント ● 3.素材選択 ○ 四季版や月版と比べてレコード数が多い ■ 1家族あたり最大で数十万件の写真・動画が対象 ○ レコメンドに必要な関連レコードも合わせて取得する ○ クエリの流量がどうしても多くなる、DBに高負荷が掛かる ■ Amazon Aurora の Reader Endpoint を利用 ● 4.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時から生成し続ける ● 昨年まで:デイリーバッチ ○ 生成対象の家族を2グループ(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 使いすぎ 修正(1) ・原因が 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 に増やす 修正(1) ・原因が 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 に増やす 修正(1) ・原因が 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 使いすぎ 修正(1) ・原因が 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