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

今回は、みてねの「自動作成フォトブック」について、その概要や処理の流れを説明したのち、これまでに実施してきた負荷対策についてご紹介します。

なお、この連載では以前1秒動画の生成・配信についてもご紹介しており、本記事では1秒動画と比較したフォトブック自動作成処理の特徴や違いについても触れます。

自動作成フォトブックとは

みてねでは、ご家族の思い出を形あるものとして残し、また贈り物としてもご利用いただけるよう、紙のフォトブック注文機能を提供しています。

このフォトブックには、紙質や印刷品質に応じて「スタンダード」「⁠ハードカバー」「⁠ライト」の3種類がありますが、いずれもA5サイズ、24ページ（うち写真22ページ）の仕様です。

またフォトブック機能では、毎月1冊フォトブックを作成し、月ごとに思い出を形に残したり、祖父母やご親戚へ共有いただくことを想定しています。

自動作成フォトブックでは、この「1ヵ月ぶんの写真から1冊のフォトブックを作る」ことの負担を減らすため、フォトブックの表紙・本文にどの写真を選択するかをAIが作成しています。

この自動作成機能は、毎月5日以降に、みてねのアルバムに保存されている先月の写真から、フォトブックにおすすめの23枚（表紙1枚・本文22枚）を選んで自動作成し各ユーザに提案しています。自動作成されたフォトブックの提案データを受けとったユーザは、内容を確認したうえで、そのままフォトブックとして注文することも、部分的に編集（写真の入れ替えやコメントの追加・削除）してから注文することもできます。

自動作成の流れ

フォトブックの自動作成処理は、下図の通り(1)対象ユーザ抽出、(2)素材選択、(3)配信、の3段階で実現しています。以下ではその詳細を説明します。

(1)対象ユーザ抽出

自動作成フォトブックにおける対象ユーザ抽出処理は、以前ご紹介した1秒動画と同様に、基本的にはバッチ処理として毎日実行しています。その最初の段階として、「⁠その日、どのユーザにフォトブックを自動作成するか」を取り出す処理が対象ユーザ抽出です。

この処理では、実際に「対象ユーザがもつ閲覧可能な写真の数」などの条件を確認し、自動作成が可能なユーザのみを抽出しています。その処理には部分的にBigQueryを用いており、DBの負荷軽減や処理の高速化を図っています。これについて詳しくは後述します。

(2)素材選択

フォトブックを自動作成する対象ユーザを取り出した後は、実際にどの写真を選ぶか選択します。

この素材選択処理には、独自のルールベース素材選択AIを利用しており、たとえば以下のような点を加味して、なるべくよい写真の組み合わせを提案しています。

1. お気に入り、コメント、公開範囲、解像度などのメタデータ：お気に入りやコメントがあり、公開範囲が「家族みんなに公開」で、高解像度の写真を優先したい。
2. MLモデルによる写真の解析結果：お子さまやご家族がきれいに写った写真を優先したい。
3. （表紙のみ）写真のクロップ時、被写体が見きれないか：表紙では写真を正方形にクロップするため、被写体が見きれない写真を優先したい。
4. 撮影日時や場面のばらけ具合：特定の週・日・時間に偏らず、1ヶ月間からまんべんなく選択したい。また特に、同じ場面の写真（連写など）を複数選ぶことは避けたい。

このうち1～3は、素材となるそれぞれの写真単体に対して評価できますが、4については素材を組み合わせ、フォトブック全体としてのでき具合を評価する必要があります。

みてねでは、この写真単体の評価と、フォトブック全体としての評価を良い具合に組み合わせた素材選択AIを開発・運用しています。この素材選択AIは、以下のようにフィルタリング、スコアリングおよびランダム性の要素を組み合わせて実現しています。

1. フィルタリングによる候補写真の選出：はじめに該当ユーザがもつ写真のうち、フォトブックに含める候補写真をフィルタリングにより選択する。たとえば「お気に入り＞家族みんなに公開＞MLモデルによる評価が高い」などのように、上記1～3の観点に優先順位を設定し、それぞれのフィルタ処理を用意しておく。各ユーザに対する素材選択処理としては、もっとも厳しいフィルタ条件からはじめて、候補写真の枚数が十分揃うまでフィルタ条件を緩めていく。
2. 候補写真のスコアリング：すべての候補写真に対し、より細かいスコアリングを行う。ここでも上記1.〜3.の観点を用い、各写真のスコアを点数化する。
3. ランダムな自動作成フォトブック候補の生成：候補写真から23枚（表紙1枚、本文22枚）を組み合わせて、ランダムに自動作成フォトブックの候補を複数パターン作る。ただしここでは完全なランダムではなく、スコアの高い写真を選ばれやすくしたり、撮影日時や場面のばらけ具合など上記4.の観点を盛り込んだりして、良さそうなフォトブック候補が生成されるよう工夫している。
4. 最良の自動作成フォトブック候補を選択：3.で生成した自動作成フォトブック候補に対し、フォトブック全体に対するスコア（上記4の観点）を計算し、最高スコアの候補を最終的な自動作成フォトブックとして採用する。

(3)配信

素材選択の終わったフォトブックは、iOS/Androidアプリへとプッシュ通知を送り、ユーザへお届けします。

負荷対策

ここまでで自動作成フォトブックの大まかな仕様についてご説明しました。ここからはその負荷対策の手法についてご紹介します。

対象ユーザ選択処理⁠：BigQueryへのオフローディング

上記で説明したフォトブック自動提案処理のうち、(1)対象ユーザ選択処理においてBigQueryを利用し、DB負荷対策と高速化を行っています。

BigQuery導入前の対象ユーザ選択処理は、アプリサーバ向けDBを参照しており、DBへ高負荷をかけていたほか、処理完了までに半日～1日程度の時間を要していました。このクエリの主要部分（家族ごとの1ヵ月間における写真件数のカウント処理）をBigQueryにオフロードすることで、アプリサーバ側のDB負荷を大きく軽減したうえで、処理時間を2時間程度にまで短縮できました。

BigQueryはこのような、通常のRDBでは処理に時間がかかる、またはインスタンス負荷を意識せねばならないクエリを、高速かつサーバレスに（インスタンス負荷をあまり意識せずに）実行できる利点があります。みてねでは、BigQueryをBI（Business Intelligence）や分析用途のほか、1秒動画や今回ご紹介した自動提案フォトブックなどのアプリケーション開発でも積極的に活用しています。

また今後の課題として、対象ユーザ選択処理全体や、素材選択処理を含めたフォトブック自動提案システム全体の完全BigQuery化や、Amazon AuroraとAmazon Redshiftのzero-ETL integrationの活用により、さらなるDB負荷軽減や自動提案の高速化が可能なものと見込んでおり、アーキテクチャ的な改善も含め今後の課題として検討・議論しています。

生成処理全体のバッチ仕様の改善

一方、生成処理全体のバッチ仕様にも課題がありました。現在みてねでは、毎月5日から数日間をフォトブック大量配信期間と位置付け、この期間に前月分のフォトブックを（その時点までに写真数などの条件を満たす）全ユーザに自動作成する仕様としています。

この大量配信期間の生成処理は、従来は1日単位でのバッチ処理方式とし、「⁠毎日0:00に対象ユーザ選択処理を開始し、当日夕方の配信までに素材選択を完了する」仕様としていました。この仕様による大量配信期間の、素材選択ジョブキューにおけるジョブ件数のグラフを以下に示します。毎日0:00ごろにジョブが積まれ始め、夕方ごろにかけてジョブが消化される様子が確認できます。

運用開始当初はこの仕様で問題なかったものの、ユーザ数が増加するにつれ、当日分の素材選択処理が配信時間に間に合わず、翌日に持ち越してしまうオーバーランが時折発生するようになりました。このオーバーランが発生すると、対象ユーザ抽出に日をまたいで重複が生じることで余計なシステム負荷がかかったり、ユーザにとっても配信日が順延されてしまったりなどの問題がありました。

またシステム運用上の観点からも、オーバーランの発生に対するアラートを設定しておらず、翌日以降にあとからシステムメトリクスを確認して気づく、といった課題がありました。

これに対する改善として、大量配信期間はその冒頭に一度だけ対象ユーザ抽出を行ったうえで、素材選択処理を24時間継続し、当日の配信時間に間に合った分を配信する、という仕様に改修しました。改修後の素材選択ジョブキューにおける大量配信期間のジョブ件数のグラフを以下に示します。大量配信期間の冒頭にジョブが全件積まれ、大量配信期間を通して一定ペースでジョブが消化される様子が確認できます。

この仕様変更に際しては、家族間・ユーザ間の配信順序や配信日に影響が出るため、プロダクトオーナーやプロダクトマネージャ、CSチームなどのステークホルダーと事前に議論のうえ、合意を得て改修を行いました。これを機に、「⁠日ごとのバッチ処理のオーバーラン」の概念はもはやなくなり、エンジニアとしては「大量配信期間中に、すべての自動作成フォトブックを配信し終えること」だけ考えればよい状態となりました。

さらにフォトブックの配信遅延を防止する仕組みとして、素材選択処理のジョブキューの残り件数とジョブ消化速度から、現在のペースにおける完了見込み時間を計算・通知したうえで、大量配信期間内に終わらない見込みの場合にはアラートを発報する監視機構を導入しました。

以上の改修により、素材選択処理のシステム負荷を24時間を通して平準化したうえで、大量配信期間を従来の5日間から3〜4日間へと大幅に短縮できました。また素材選択処理の処理ペースを監視し、必要であれば事前にインフラをスケールアウトできるよう運用体制も改善することができました。

まとめ

この記事では、みてねData Engineeringグループにおける取り組みのひとつとして、自動作成フォトブックの仕組みと、その負荷対策の事例についてご紹介しました。

みてねでは、前回の1秒動画の記事でもご紹介したように、BigQueryの活用やバッチ処理の改善、インフラ構成やパイプラインの最適化など、さまざまな観点からシステムの負荷対策に取り組んでいます。また今回ご紹介した自動提案フォトブックについては、負荷対策のほか自動作成内容の品質向上などにも課題があり、引き続き改善に取り組んでいきます。