Shoeisha Technology Media

CodeZine(コードジン)

特集ページ一覧

1カ月で7000万件の画像・動画を処理する「家族アルバム みてね」の課題――メディア解析基盤リプレースまでの道のり【Developers Boost】

【A-9】「簡単でつかいやすい」を追求する開発の裏側 〜メディア解析基盤の話〜

  • ブックマーク
  • LINEで送る
  • このエントリーをはてなブックマークに追加
2019/01/17 11:00

 12月15日、翔泳社主催の若手エンジニア向けカンファレンス「Developers Boost(デブスト)~U30エンジニアの登竜門~」が開催された。企業の中核を担う30歳以下(U30)の若手エンジニアたちが登壇。その知識やノウハウを惜しみなく公開した。ここでは、株式会社ミクシィ 松石浩輔氏によるセッション「『簡単でつかいやすい』を追求する開発の裏側 〜メディア解析基盤の話〜」の模様をレポートする。ミクシィ社の家族向け写真・動画共有アプリ「家族アルバム みてね(以下、みてね)」は、ユーザーのアップロードした子どもの画像や動画をもとに、コンテンツを自動生成・自動提案する機能を提供している。同社は現在、これらの機能を支えるメディア解析基盤のリプレースを実施中だ。エンジニアの松石氏より、リプレースに至った背景や工夫した点などについて発表がなされた。

株式会社ミクシィ みてね事業部 開発G エンジニア 松石 浩輔氏
株式会社ミクシィ みてね事業部 開発G エンジニア 松石 浩輔氏

解析基盤が抱えていた課題を解決するため、環境を刷新

 「みてね」では、「いい感じ」のダイジェスト動画を自動生成する「1秒動画」や、1カ月分の画像から「いい感じ」のフォトブックをつくる「自動提案フォトブック」などの機能を提供している。

 これらの機能では、ユーザーが画像・動画ファイルをアップロードすると即座に顔検出や人物検出、BGM検出などの解析処理がなされる。「みてね」に保存されるすべてのメディアは、解析基盤を通過しているのだ。その数、なんと1カ月あたり7000万件以上。膨大な数のメディアは、かつて下図のような解析基盤によって処理されていた。

旧メディア解析基盤。アップロードされるメディア数が増加するにつれ、徐々にこのアーキテクチャの課題が見えてきたという。
旧メディア解析基盤。アップロードされるメディア数が増加するにつれ、
徐々にこのアーキテクチャの課題が見えてきた

 「旧メディア解析基盤にはいくつか課題がありました。まず、一部の解析項目をアプリサーバー側で処理していたため、メディア数が増えるとデータベースやredisへの負荷がかなり高くなってしまうこと。解析処理が原因で障害が起きることも少なくありませんでした。

 また、解析基盤をやや保守的なインフラ構成にしていたため、運用コストも高かったです。そこで、解析基盤の新しいアーキテクチャを考えることにしました」(松石氏)

 新しい解析基盤を検討するにあたり、いくつかの設計方針が立てられた。高負荷による障害を起こさないように、アプリサーバーから解析処理を切り離すこと。オペレーションコストを削減するため、コンテナ化してマネージドサービスを利用すること。そして、現在の基盤から漸進的に移行していくことだ。これらの方針のもと、リプレースプロジェクトが推進された。

Amazon SageMakerを活用し、推論処理を最適化

新メディア解析基盤。旧アーキテクチャの抱えていた課題を解決するため、いくつもの設計上の工夫がなされた。
新メディア解析基盤。旧アーキテクチャの抱えていた課題を解決するため、いくつもの設計上の工夫がなされた

 新しいメディア解析基盤は、上図のアーキテクチャとなった。アプリサーバーから独立した、メディア解析専用のサーバーを用意し、そこで解析処理を行う方針だ。機械学習的な推論処理は、Amazonの提供している機械学習用のマネージドサービスAmazon SageMaker(以下、SageMaker)を活用した推論APIにより実施されることとなった。

 「SageMakerを採用したのにはいくつか理由があります。まず、『みてね』の関連ファイルやサーバーはすべてAWS上にあるため、連携がしやすいこと。特に、画像・動画データがAmazon S3に配置されているため、それらとの連携が容易だったことは大きいです。また、SageMakerはマネージドサービスなので運用も楽になります」

 SageMakerによる推論APIは、コンテナ上で稼働するつくりになっている。コンテナ内でREST APIの形でHTTPサーバーを立て、その裏側で推論処理のロジックが動くしくみだ。では、推論処理はどのように実装されているのだろうか。

 「『みてね』で活用している顔検出の解析処理は、研究者の多い領域です。そのため、彼らが公開しているソースコードを流用できます。ただし、それらの実装では処理速度が遅いという欠点があったので、私たちは既存の検出器を高速化して利用しました」

 高速化の手法はいくつかある。「みてね」では、HTTPサーバーが受け取ったジョブをもとに「1.画像ダウンロード」「2.前処理」「3.推論処理」「4.後処理」という順序で解析処理が行われている。前処理の部分でデータ処理用パイプラインのNVIDIA DALIを利用することで、一部の処理をGPUにオフロードしているという。

 推論処理についても、同じくNVIDIA TensorRTを利用し、NVIDIA Tesla V100 + FP16演算に最適化した処理を行っている。これらの施策により、もともとの検出器の速度と比べて10倍以上の高速化を実現したそうだ。

 コンテナイメージのビルドやテスト、デプロイはAWS CodeBuildにより自動化されている。「みてね」のSageMakerインスタンスのスケーリングは、少し変わったルール設定だ。SageMaker推論APIを叩いているジョブキュー側のジョブ数を監視し、その数値をもとにスケールさせるつくりになっている。

 「SageMakerのAWS公式ドキュメントには、APIの実行回数を監視することでスケールさせるのがベストプラクティスであると書かれています。ですが、今回はAPI実行回数を制御できる用途のため、あえて公式ドキュメントの内容を無視したルール設定にしました。これにより、性能をギリギリまで向上させられるようにチューニングしています」

 新しい解析基盤への移行は、2つのフェーズに分けて行われた。第1フェーズでは、旧基盤と新基盤を並行稼働させ、後者の処理結果は破棄する運用方針となった。このフェーズのなかで、新基盤の正常稼働確認やパフォーマンスチューニングなどが実施されたという。安定運用の見通しが立った後、次のフェーズで新基盤への段階的な移行が行われた。

 「移行したことで、アプリサーバーの負荷はかなり軽減されました。解析処理に起因する障害も発生していません。また、運用コストも格段に下がり、オペレーションの手間も大きく軽減されました」

 エンジニアが運用作業から解放されるメリットは大きい。アプリサーバー負荷と運用コストが特に大きかった顔検出の解析基盤については、移行が完了しており、その他人物検出などの解析基盤も順次移行していく予定だ。

お問い合わせ

 株式会社ミクシィ

  • ブックマーク
  • LINEで送る
  • このエントリーをはてなブックマークに追加

著者プロフィール

All contents copyright © 2005-2019 Shoeisha Co., Ltd. All rights reserved. ver.1.5