MIXIがFC東京の「1万枚の写真」選定を自動化 無駄な運用費をどう削った？：週末に集中する処理をいかにさばくか

週末の試合のたびに1万枚の写真の選定に追われ、担当者には多大な運用負担がのしかかる。FC東京の過酷な業務を、MIXIはいかにして救ったのか。「Amazon Aurora DSQL」を用いたシステム構築の全貌に迫る。

[TechTargetジャパン]

　企業における慢性的なITエンジニア不足が課題になる中、限られた人員でいかに迅速かつ効率的にシステムを運用するかが問われている。SNS（ソーシャルネットワーキングサービス）やゲームなどを手掛けるMIXIは、プロスポーツチームのFC東京の運営を支援している。FC東京は、試合の熱気をファンにいち早く届けるため、試合当日に公式カメラマンが撮影する約1万枚の写真を、マッチレポートなどのマーケティング用途でWebに公開している。

　従来は、広報担当者が1万枚の写真を1枚ずつ目視で確認して選定していたため、多大な時間がかかり、タイムリーな写真素材の活用が困難だった。そこでMIXIは、画像認識モデルと生成AIを組み合わせ、写真の分析と選定を自動化し、Webブラウザから候補を素早くプレビューできるシステムを開発した。

　このシステムのバックエンドデータベースとして選ばれたのが、Amazon Web Services（AWS）が提供する「Amazon Aurora DSQL」だ。試合は主に週末に週1、2回開催されるため、写真の取り込みや分析処理が特定の曜日の短時間に集中する。一方で、試合がない平日の時間帯にはデータベースへのアクセスが全く発生しないという、稼働の波が極めて激しい。システムの開発・運用を担うチームは少人数であり、データベース管理に人手をかけられないという事情もあった。Amazon Aurora DSQLの採用によって、MIXIは使った分だけの課金による費用最適化と、運用負担の大幅な軽減を達成した。

　稼働の波に合わせた費用最適化と運用負荷の削減を両立させたAmazon Aurora DSQLだが、新しいシステムへの移行には技術的なハードルも存在した。MIXIは開発においてどのような壁に直面し、独自の工夫でそれをどう乗り越えたのか。

MIXIがデータベースに求めた3つの要件

併せて読みたいお薦め記事

AWSの活用事例

• セブン＆アイが「AWS」にグループ各社のシステムを集約する“挑戦的な理由”
• 任天堂はなぜ「Nintendo Switch Online」のインフラに「AWS」を選んだのか

　MIXIが新システムのデータベースに求めたのは、少人数でも無理なく運用でき、かつアクセスが集中する波に無駄なく処理できるという条件だった。採用の決め手になったのは、以下の3点だ。

• 専任のデータベース管理者が不要
  • データベースエンジンのバージョンアップやメンテナンスウィンドウ（保守作業のための計画停止時間）を意識する必要がなく、少人数のチームで運用が可能となる。
• 使った分だけの課金モデル
  • リクエストごとの使用量に応じた価格モデルを採用しており、アクセスが発生しない時間帯は処理の課金が発生しないため、常時稼働の構成と比べて無駄な費用を抑えられる。
• 使い慣れたツールやクエリの利用
  • オープンソースのリレーショナルデータベース「PostgreSQL」と互換性があり、既存のツールや知識を活用できる。

非互換性やデータ制限の壁をどう乗り越えたか

　システムの実装において、MIXIは「JavaScript」および「TypeScript」向けのORM（データベースのデータをプログラムのオブジェクトとして扱うためのツール）「Drizzle」を採用した。PostgreSQL互換であることを生かして開発を進めたが、一部の機能においては非互換性や独自の制限が存在したため、それらを回避する仕組みを自社で構築した。

　技術的な工夫として、主に3つの工夫を施している。

　1つ目は、Drizzleが出力するDDL（データ定義言語：データベースの構造を定義する命令）を互換形式に変換する内製スクリプトの開発だ。開発時点で、Drizzle用の公式アダプターは提供されていなかった。そのため、MIXIは通常のPostgreSQLを想定した設定を、制約に合わせて変換する以下の処理を組み込んだ。

• インデックス作成において、非同期指定（ASYNC）を自動で付与する処理を追加した。
• 外部キー制約機能が提供されていないため、生成される外部キー制約の追加記述を削除する処理を加えた。
• 1回の処理につき実行できる変更が1つという制約に対し、複数の変更を1つずつ個別のトランザクションに分割するよう実装した。

　これらの変換スクリプトを開発の基本コマンドに組み込むことで、開発者は通常のワークフローを変えることなくデータベースの変更作業を進めることが可能になった。

　2つ目は、一度に変更できるデータ容量の制限への対策だ。Amazon Aurora DSQLには、1トランザクション当たりに変更できる行数に上限が存在する。本システムでは、1試合約1万枚の写真それぞれに複数のタグや人物の関連付け情報を登録するため、レコード数は数万件に達する。これを一度に反映しようとすると上限を超えてしまうため、一時的なデータの不整合を許容した上で、分析結果の反映処理を複数の小さな単位に分割する方式を採用した。

　3つ目は、OCC（楽観的同時実行制御：データ更新時の競合を前提とせず、確定時に確認する方式）への適応だ。Amazon Aurora DSQLはOCCを採用しており、書き込み時に競合が検出された場合は処理をやり直す必要がある。そのため、プログラム層に自動で再試行する処理を作り、数回リトライしても成功しない場合は、デッドレターキュー（処理に失敗したデータを一時的に退避させる仕組み）に退避させ、後続の処理で適切に扱う設計とした。

運用負担から解放され、アプリケーション開発に集中

　システムの開発プロジェクトは、AWSのエンジニアがプロトタイプ開発を支援するプログラム「AWS Prototyping Program」を活用して進行し、開発開始から約2カ月で本番稼働を実現した。運用開始後、2026年6月まででデータベースに起因する障害は発生していない。従来型の構成を採用していれば発生していたであろう0.5人月分の構築・管理作業が不要になり、開発チームはアプリケーション機能の実装に集中できるようになった。複雑な検索条件を用いた画面の表示も1秒以内に完了するなど、実運用において性能面での課題も見られていない。

　MIXIのエンジニアリング支援グループに所属する數藤智幸氏は、「データベースの存在を意識せずに開発・運用できることが一番のメリットだった。メンテナンスやスケーリングの設計から解放され、少人数のチームでもアプリケーション開発に集中できている」と評価する。利用が特定の時間帯に偏るワークロードにおいて、MIXIは今後も積極的に同サービスの活用を進めていく方針だ。