株式会社MIXIで
今回は、みてねの
なお、この連載では以前1秒動画の生成・
自動作成フォトブックとは
みてねでは、ご家族の思い出を形あるものとして残し、また贈り物としてもご利用いただけるよう、紙のフォトブック注文機能を提供しています。
このフォトブックには、紙質や印刷品質に応じて
またフォトブック機能では、毎月1冊フォトブックを作成し、月ごとに思い出を形に残したり、祖父母やご親戚へ共有いただくことを想定しています。
自動作成フォトブックでは、この
この自動作成機能は、毎月5日以降に、みてねのアルバムに保存されている先月の写真から、フォトブックにおすすめの23枚
自動作成の流れ
フォトブックの自動作成処理は、下図の通り(1)対象ユーザ抽出、(2)素材選択、(3)配信、の3段階で実現しています。以下ではその詳細を説明します。
(1)対象ユーザ抽出
自動作成フォトブックにおける対象ユーザ抽出処理は、以前ご紹介した1秒動画と同様に、基本的にはバッチ処理として毎日実行しています。その最初の段階として、
この処理では、実際に
(2)素材選択
フォトブックを自動作成する対象ユーザを取り出した後は、実際にどの写真を選ぶか選択します。
この素材選択処理には、独自のルールベース素材選択AIを利用しており、たとえば以下のような点を加味して、なるべくよい写真の組み合わせを提案しています。
- お気に入り、コメント、公開範囲、解像度などのメタデータ:お気に入りやコメントがあり、公開範囲が
「家族みんなに公開」 で、高解像度の写真を優先したい。 - MLモデルによる写真の解析結果:お子さまやご家族がきれいに写った写真を優先したい。
(表紙のみ) :表紙では写真を正方形にクロップするため、被写体が見きれない写真を優先したい。写真のクロップ時、被写体が見きれないか - 撮影日時や場面のばらけ具合:特定の週・
日・ 時間に偏らず、1ヶ月間からまんべんなく選択したい。また特に、同じ場面の写真 (連写など) を複数選ぶことは避けたい。
このうち1~3は、素材となるそれぞれの写真単体に対して評価できますが、4については素材を組み合わせ、フォトブック全体としてのでき具合を評価する必要があります。
みてねでは、この写真単体の評価と、フォトブック全体としての評価を良い具合に組み合わせた素材選択AIを開発・
- フィルタリングによる候補写真の選出:はじめに該当ユーザがもつ写真のうち、フォトブックに含める候補写真をフィルタリングにより選択する。たとえば
「お気に入り>家族みんなに公開>MLモデルによる評価が高い」 などのように、上記1~3の観点に優先順位を設定し、それぞれのフィルタ処理を用意しておく。各ユーザに対する素材選択処理としては、もっとも厳しいフィルタ条件からはじめて、候補写真の枚数が十分揃うまでフィルタ条件を緩めていく。 - 候補写真のスコアリング:すべての候補写真に対し、より細かいスコアリングを行う。ここでも上記1.〜3.の観点を用い、各写真のスコアを点数化する。
- ランダムな自動作成フォトブック候補の生成:候補写真から23枚
(表紙1枚、本文22枚) を組み合わせて、ランダムに自動作成フォトブックの候補を複数パターン作る。ただしここでは完全なランダムではなく、スコアの高い写真を選ばれやすくしたり、撮影日時や場面のばらけ具合など上記4.の観点を盛り込んだりして、良さそうなフォトブック候補が生成されるよう工夫している。 - 最良の自動作成フォトブック候補を選択:3.で生成した自動作成フォトブック候補に対し、フォトブック全体に対するスコア
(上記4の観点) を計算し、最高スコアの候補を最終的な自動作成フォトブックとして採用する。
(3)配信
素材選択の終わったフォトブックは、iOS/
負荷対策
ここまでで自動作成フォトブックの大まかな仕様についてご説明しました。ここからはその負荷対策の手法についてご紹介します。
対象ユーザ選択処理:BigQueryへのオフローディング
上記で説明したフォトブック自動提案処理のうち、(1)対象ユーザ選択処理においてBigQueryを利用し、DB負荷対策と高速化を行っています。
BigQuery導入前の対象ユーザ選択処理は、アプリサーバ向けDBを参照しており、DBへ高負荷をかけていたほか、処理完了までに半日~1日程度の時間を要していました。このクエリの主要部分
BigQueryはこのような、通常のRDBでは処理に時間がかかる、またはインスタンス負荷を意識せねばならないクエリを、高速かつサーバレスに
また今後の課題として、対象ユーザ選択処理全体や、素材選択処理を含めたフォトブック自動提案システム全体の完全BigQuery化や、Amazon AuroraとAmazon Redshiftのzero-ETL integrationの活用により、さらなるDB負荷軽減や自動提案の高速化が可能なものと見込んでおり、アーキテクチャ的な改善も含め今後の課題として検討・
生成処理全体のバッチ仕様の改善
一方、生成処理全体のバッチ仕様にも課題がありました。現在みてねでは、毎月5日から数日間をフォトブック大量配信期間と位置付け、この期間に前月分のフォトブックを
この大量配信期間の生成処理は、従来は1日単位でのバッチ処理方式とし、
運用開始当初はこの仕様で問題なかったものの、ユーザ数が増加するにつれ、当日分の素材選択処理が配信時間に間に合わず、翌日に持ち越してしまうオーバーランが時折発生するようになりました。このオーバーランが発生すると、対象ユーザ抽出に日をまたいで重複が生じることで余計なシステム負荷がかかったり、ユーザにとっても配信日が順延されてしまったりなどの問題がありました。
またシステム運用上の観点からも、オーバーランの発生に対するアラートを設定しておらず、翌日以降にあとからシステムメトリクスを確認して気づく、といった課題がありました。
これに対する改善として、大量配信期間はその冒頭に一度だけ対象ユーザ抽出を行ったうえで、素材選択処理を24時間継続し、当日の配信時間に間に合った分を配信する、という仕様に改修しました。改修後の素材選択ジョブキューにおける大量配信期間のジョブ件数のグラフを以下に示します。大量配信期間の冒頭にジョブが全件積まれ、大量配信期間を通して一定ペースでジョブが消化される様子が確認できます。
この仕様変更に際しては、家族間・
さらにフォトブックの配信遅延を防止する仕組みとして、素材選択処理のジョブキューの残り件数とジョブ消化速度から、現在のペースにおける完了見込み時間を計算・
以上の改修により、素材選択処理のシステム負荷を24時間を通して平準化したうえで、大量配信期間を従来の5日間から3〜4日間へと大幅に短縮できました。また素材選択処理の処理ペースを監視し、必要であれば事前にインフラをスケールアウトできるよう運用体制も改善することができました。
まとめ
この記事では、みてねData Engineeringグループにおける取り組みのひとつとして、自動作成フォトブックの仕組みと、その負荷対策の事例についてご紹介しました。
みてねでは、前回の1秒動画の記事でもご紹介したように、BigQueryの活用やバッチ処理の改善、インフラ構成やパイプラインの最適化など、さまざまな観点からシステムの負荷対策に取り組んでいます。また今回ご紹介した自動提案フォトブックについては、負荷対策のほか自動作成内容の品質向上などにも課題があり、引き続き改善に取り組んでいきます。