gihyo.jpサイトのロゴ

みてね×gihyo.jpスペシャル

みてねのコンテンツ自動作成⁠⁠・自動分類を支える写真⁠⁠・動画解析パイプライン

2024-12-16

株式会社MIXIで「家族アルバム みてね」（⁠⁠以下みてね）のData Engineeringグループ所属の松石と申します。

今回は、これまで本連載でご紹介してきたみてねの1秒動画や自動作成フォトブック、人物ごとのアルバムといった、みてねのコンテンツ自動作成・自動分類機能の裏側で用いられている写真・動画解析パイプラインについてご紹介します。

写真⁠・動画解析パイプラインのビジネス的な意義と要件

意義

前述のような各種コンテンツ自動作成・自動分類機能は、いずれもみてねのビジョンである「⁠『⁠世界一愛されるサービス』と『圧倒的収益』を達成」の実現のために提供しています。

たとえば1秒動画には、全家族に3ヵ月ごとにお届けする「四季版」と、プレミアム家族限定で毎月・毎年お届けする「月版」「⁠年間版」があります。これらの1秒動画は、日々のみてねの利用を通して蓄積された写真・動画からダイジェスト動画である1秒動画を自動作成することで、驚きの振り返りを提供しています。また「月版」および「年間版」は、みてねの重要な収益源の1つであるプレミアムの目玉コンテンツのひとつとして、みてねの収益性にも貢献しています。

このようなコンテンツ自動作成・自動分類を実現する第一歩として、みてねにアップロードされた写真・動画に何が写っているのかについて、AIにより解析し理解するためのシステムが、今回ご紹介する写真・動画解析パイプラインです。その用途として、たとえば写真・動画に対する顔検出を解析パイプラインで行い、1秒動画にどの写真・動画を含めるかの素材選択に活用する、といった例が挙げられます。

要件

この写真・動画解析パイプラインに対するビジネス的な要件としては以下が挙げられます。

  1. みてねにアップロードされる写真・動画すべて（1日あたり1000万件のオーダー）に対し、AI/MLモデルを含む一連の解析処理を実行すること（スケーラビリティ）
  2. 解析結果を保存し、前述のような各種コンテンツ自動作成・自動分類機能に幅広く安定的に活用できること（汎用性と可用性）
  3. 解析にかかるインフラコスト・インフラ負荷・解析処理のレイテンシをできるだけ抑えつつ、解析精度をできるだけ高めること（コスト効率・パフォーマンス効率の高さ）

以下では上記3つの観点、とくにスケーラビリティ面に重点をおき、解析パイプラインについてご紹介します。

写真⁠・動画解析パイプラインの概要

はじめに写真・動画解析パイプライン全体の概要図を以下に示します。各コンポーネントの詳細については次章でご紹介します。

写真・動画解析パイプライン全体の概要図
写真・動画解析パイプライン全体の概要図

設計方針

写真・動画解析パイプラインは、前述の要件を念頭に、運用・保守性や拡張性も考慮し、以下の設計方針をとっています。

  • 非同期処理：SidekiqおよびAmazon SQSを採用し、パイプライン全体を非同期処理で構成する。
  • 用途に適した言語・フレームワークの採用：パイプラインのうち通常のバックエンド処理部分は、みてねの他のバックエンドシステムに合わせてRuby on RailsおよびSidekiqを採用する。一方AI/ML処理においては、一般に広く用いられているTensorFlowなどのPython向けフレームワークを採用する独立したサブシステムまたはリポジトリとして切り出し、SQSで連携する。
  • オーケストレータの自前実装：解析パイプライン全体を管理するワークフローエンジン、またはオーケストレータ的な役割を自前実装する。

解析項目

ひとくちに「写真・動画の解析」といっても、さまざまな切り口の処理があります。みてねにおける写真・動画の主要な解析処理としては、大別して以下3種類があります。

  1. 写真・動画データ本体に関する解析（人物や場面といった被写体の認識など）
  2. 写真・動画ファイルのメタデータに関する解析（EXIF/XMLメタデータの取得や分析など）
  3. 他の写真・動画との比較（同一場面におけるベストショットの判定など）

以下ではとくに1.および2.の観点による解析についてご紹介します。

写真⁠・動画解析パイプラインの構成と実装

写真・動画解析パイプラインの大まかな構成としては、みてねのバックエンドサーバ本体であるmitene、AI/ML解析パイプライン自体を定義・実装するmedium-analyzer、およびAI/MLモデルの処理を担当するAI/MLモデル推論器があります。以下ではそれぞれについてご紹介します。

みてねのバックエンドサーバ mitene

miteneは、みてねのバックエンドサーバ本体であり、Railsで実装され、iOS/AndroidアプリやWebフロントエンド向けにAPIを提供しています。

写真・動画解析パイプラインにおけるmiteneの責務は以下のとおりです。

  • 写真・動画の管理：クライアントからアップロードされた写真・動画を保存し管理する
  • 解析ジョブの開始：アップロードされた全ての写真・動画に対し、後述のAI/ML解析パイプラインmedium-analyzerに解析ジョブを投げる
  • 解析ジョブの状態管理とリトライ：写真・動画解析ジョブの状態を管理し、失敗した、または行方不明になったまま放置されているジョブをリトライする
  • 一部の解析処理の直接実行：解析項目のうち、写真・動画ファイルのメタデータに関する解析と、他の写真・動画との比較とを内部で実行する
  • 解析結果の保存と活用：解析結果をDBに保存し、また1秒動画などのコンテンツ自動作成・自動分類機能で活用する

AI/ML解析パイプライン medium-analyzer

medium-analyzerは、AI/MLモデル推論器を束ねた解析パイプライン本体を定義・実行するサブシステムであり、miteneと同様にRailsで実装されています。その責務は以下のとおりです。

  • AI/MLモデルに関する解析パイプラインの定義と実行：miteneから受け取った解析ジョブに対し、必要なAI/MLモデルの実行ジョブを投げ、結果をmiteneに返す
  • 複数モデルバージョンやパイプラインバージョンへの対応：AI/MLモデルの評価・更新時など、必要に応じて特定のモデルのバージョンや、パイプライン自体のバージョンを出し分ける

AI/MLモデル推論器

AI/MLモデル推論器は、medium-analyzerから解析ジョブを受け取り、実際に顔検出などのAI/MLモデルを写真・動画に対して適用するシステムであり、TensorFlowなどのAI/MLフレームワーク利用のためPythonで実装されています。その責務は以下のとおりです。

  • AI/MLモデルを用いた推論の実行：実際にAI/MLモデルを用いて、写真・動画データに対する推論処理を行い、結果をmedium-analyzerへと返す

なお、AI/MLモデルを用いた推論処理を本番環境で大規模に適用する設計として、一般的にはオンライン推論とバッチ推論があります。

  • オンライン推論：モデルを同期APIの形でデプロイし、個別の入力データをWeb APIなどから渡して推論する設計。たとえばAmazon SageMakerのエンドポイントを用いたリアルタイム推論や、Google CloudのVertex AIによるオンライン予測など。
  • バッチ推論：モデルを非同期APIの形でデプロイし、複数の入力データをバッチ化して、Amazon S3やGoogle Cloud Storageなどのストレージを経由して渡す設計。たとえばAmazon SageMakerのバッチ変換や、Vertex AIのバッチ予測など。

一方みてねの写真・動画解析パイプラインにおいては、AI/MLモデルをSQSを介した非同期APIとしてデプロイしており、入力データもバッチ化せず、個別の写真・動画単位で渡す設計をとっています。個別のAI/ML推論器は、ジョブをSQSのキューから取り出して（dequeueして）推論し、結果を別のキューに書き戻す（enqueueする）もので、オンライン推論とバッチ推論の中間的な設計と言えるかもしれません。この設計には以下の利点があります。

  • オンライン推論と比較したスケーリングの容易さとリソース・コスト効率の高さ：オンライン推論を採用した場合、同期APIを受けつけるインフラ（たとえばEC2インスタンスなど）のスケーリングを、CPU使用率やリクエスト数に応じて、「⁠リクエストが詰まらないよう、かつコスト効率が良くなるよう」調整することに難易度があります。一方で本方式では、推論器側が自身のタイミングでジョブを受け付けることができ、またスケーリング条件やリソースサイズの設定（CPUコア数やメモリ量など）を任意に変更することで、リソースの使用効率、つまりコスト効率を高めることができます。
  • バッチ推論と比較したパイプライン設計の単純さ：推論ジョブ（みてねでは写真・動画）をあらかじめ利用者がバッチ化することには、一定の複雑さが伴います。一方で本方式では、解析パイプラインとしてはあくまで写真・動画を個別のジョブとして扱います。またリソース使用効率を高めるために必要に応じて、各AI/MLモデル推論器の内部で推論ジョブのバッチ化を行うものとしています。これにより、解析パイプライン全体としては単純な設計で、扱いやすい粒度のジョブを基本単位としつつ、必要に応じたリソース・コスト効率の改善を可能としています。

Redisによる解析ジョブの状態管理

medium-analyzerでは、前述のとおり、解析パイプラインのワークフローエンジンを自前で実装しています。その概要をご紹介します。

解析ジョブの実行状態は、Redisを用いたステートマシンとして管理しており、そのスキーマのイメージを以下に示します。

# key
"#{写真・動画のUUID}:#{解析ジョブのバージョン}"

# value
{
    "job_uuid": miteneの発行したジョブのUUID,
    "next_step": 次に処理する解析項目
}

# keyの例
0E5072A8-863C-4B60-A7C5-AE1378F3EE84:1

# valueの例
{
    "job_uuid": "C9F9E066-65E9-4178-8DF5-F56B6FFFC953",
    "next_step": "face_detection"
}

実際の解析パイプラインにおいては、たとえば「顔検出」や「姿勢推定」といった個別のAI/MLモデルの推論処理をそれぞれステートマシンの状態として定義しています。そして楽観的ロックを用い、Redisの更新に成功した場合に限り推論処理を行い、後続のジョブをenqueueします。

この設計により、SidekiqやSQSなどに起因するジョブの重複を検出・削除しています。これは、一部の解析ジョブにおいて、解析結果やログデータを外部のDBなどに直接永続化するケースがあり、そのデータ整合性の確保のために行っているものです。

また、keyに含まれる解析ジョブのバージョンを参照し、ステートマシン自体を切り替えることで、解析ジョブごとに、特定の推論処理のみ異なるモデルバージョンを適用したり、新たなモデルを処理するステップを追加したり、といったカスタマイズを実現しています。

なお、ここではmedium-analyzerのジョブ管理についてご紹介しましたが、解析ジョブのリトライに活用するため、実際にはmiteneにも類似のジョブ管理の仕組みを導入しています。

運用と監視

以前ご紹介したとおり、2024年12月現在、みてねのバックエンドサービスはほぼすべてがAmazon EKS上にデプロイされており、解析パイプラインの各コンポーネントもEKS上で運用しています。一部にはGPUを用いるAI/ML推論器もあり、専用のノードを用意して対応しています。

また監視について、個別のSQS/Sidekiqキューの長さやレイテンシ、ジョブを処理するワーカーのエラーレートやスループットを監視するほか、とくに以下の点を重点的に監視しています。

  • パイプライン全体でのメトリクス：パイプライン全体で多数のキューが存在し、個別のキューのレイテンシや長さを確認するだけでは不足するため、パイプライン全体（解析ジョブの開始から完了まで）のレイテンシやエラーレートを監視しています。
  • 解析結果の精度に関する統計データ：AI/MLモデルの追加・更新時や、徐々にデータの傾向が変化するなどしてモデルの精度が低下するドリフトの検知・対応のため、解析結果全体の統計データを監視しています。
  • 単一障害点のメトリクス：ジョブ管理に用いるRedisや、解析結果を保存するDBは、それぞれ単一障害点であり、そのシステム負荷を監視しています。
  • 解析パイプライン全体のコスト：写真・動画の解析にかかるインフラコストを明らかにするため、「⁠写真・動画100万件あたり、または1ヵ月あたりのパイプライン全体にかかるインフラコストがいくら」という切り口で定期的に確認しています。

まとめと今後に向けて

本記事では、みてねのコンテンツ自動作成・自動分類を支える写真・動画解析パイプライン、とくにその構成やジョブ管理、運用・監視についてご紹介しました。

このパイプラインでは、AI/ML要素を含むワークフローエンジンを自前実装していますが、これは本パイプラインを設計・実装した2018年当時、AI/ML要素を含むワークフローエンジンとしてデファクト的に用いられるフレームワークがなかったため採用したものです。

以前の1秒動画の記事でもご紹介したように、当時よりみてねではSidekiq/SQSを用いたワークフローの設計・実装・運用実績があったため、これにならってSidekiq/SQSを採用し、オーケストレータを自前で実装したものです。

このパイプラインの設計は、前述のとおりにAI/MLモデル運用時のコスト効率が高く、また運用・監視体制を整備してきています。これらにより、2018年の設計・運用開始当初と比べ桁違いにサービスの利用者数が増加した2024年12月現在でも、大きなトラブルなく、みてねにアップロードされた全ての写真・動画に対する解析処理を続けることができています。

一方、本記事を執筆している2024年12月現在では、KubeflowやGoogle CloudのVertex AI Pipelines、Amazon SageMaker Pipelines、Apache AirflowといったAI/MLやデータエンジニアリングのためのワークフローエンジンが登場しています。今後新規に同様のパイプラインやワークフローを構築する際は、こういった既存フレームワークの採用を第一に検討するとよいでしょう。

みてねでもすでに、研究開発ワークロードにおいてはこうしたフレームワークを採用しており、本番ワークロードについても必要に応じて導入を検討していきたいと考えています。

おすすめ記事

記事・ニュース一覧