株式会社 MIXI、FC東京の写真選定業務効率化システムを Amazon Aurora DSQL で実現

はじめに

株式会社 MIXI は、コミュニケーションを軸に、ソーシャルネットワーキングサービスからゲーム、スポーツ、ライフスタイルサービスへと事業を多角化してきた日本の企業です。「モンスターストライク」や「家族アルバム みてね」といったサービスに加え、FC東京をはじめとするプロスポーツチームの運営を通じて、人と人との豊かなコミュニケーションの場を提供しています。

本記事では、MIXI が FC東京向けに開発した「写真選定業務効率化システム」のバックエンドデータベースとして、Amazon Aurora DSQL 採用の経緯と技術的な工夫、得られた効果を、お客様の声を交えて紹介します。

※本画像は、FC東京様と MIXI 様の許諾を得て掲載しています

解決したかった課題

FC東京では、試合ごとに公式カメラマンが撮影した約 1 万枚の写真を、試合当日に Web 公開するマッチレポートといったマーケティング・広報用途に活用しています。これまでは担当者が写真を目視で 1 枚ずつ確認しながら選定する運用を行っており、選定に時間がかかることでタイムリーに写真素材を活用できないことが課題でした。そこで、画像認識モデルと生成 AI を組み合わせて自動的に写真を分析・選定し、Web UI から候補を素早くプレビューできるシステムを新規に構築することにしました。

ただし、その開発・運用を担うのは少人数のチームであり、データベースの管理に人手をかけられないという事情がありました。加えて、試合は基本的に週 1〜2 回、主に土日に開催され、そのたびに写真の取り込み・分析・選定が短時間に集中する一方、試合と試合の間には、データベースへのアクセスが発生しない時間帯が生じます。こうした稼働に波のあるワークロードでは、データベースにアクセスしない時間帯のコストを抑える最適化も必要でした。

なぜ Aurora DSQL を選んだのか

これらの前提を踏まえ、データベースに求めたのは、少人数で無理なく運用でき、稼働の波にも無駄なく対応できる運用特性でした。決め手は次の点です。

• メンテナンス・バージョン管理が不要：エンジンのバージョンアップやメンテナンスウィンドウを意識する必要がなく、専任 DBA を置かずに少人数のチームで運用できる
• 使った分だけの課金：「リクエストベースの、使用量主導型の価格モデル」を採用しており、データベースへのアクセスが発生しない時間帯は処理に対する課金が発生しないため、固定インスタンス（常時稼働）の構成と比べて利用に波のある本ワークロードでも無駄なコストを抑えられる
• 通常の RDB として利用できる：使い慣れた SQL でデータを扱え、PostgreSQL のドライバー・ORM・ツールも活かせる（後述のとおり一部の対応を実施）

アーキテクチャ概要

システム全体のアーキテクチャは以下の通りです。

技術的に工夫した点

本システムでは、JavaScript / TypeScript の ORM である Drizzle（https://orm.drizzle.team/）を採用しています。Aurora DSQL が PostgreSQL 互換であることを活かして Drizzle をベースに実装を進めました。ただし、一部の PostgreSQL 機能との非互換やトランザクションサイズなどの制限があり、次のような対応を行っています。なお、本記事で触れる Aurora DSQL の制約・仕様は執筆時点のものです。Aurora DSQL は継続的に機能追加・改善が行われているため、最新の情報は公式ドキュメントをご確認ください。

1. ORM の Drizzle が出力する DDL を Aurora DSQL 互換形式に変換するスクリプトを内製

Drizzle が生成するスキーマ変更 DDL は通常の PostgreSQL を想定しており、Aurora DSQL の制約・仕様に合わない箇所があります。AWS は Aurora DSQL 向けに、一部の ORM フレームワーク用のアダプター／ダイアレクトや、各種データベースドライバー用のコネクターを公開していますが、本システムで採用している Drizzle 向けのアダプターは執筆時点では提供されていませんでした。そこで、Drizzle が出力する DDL を Aurora DSQL の制約・仕様に合わせて変換するスクリプトを内製しました。主な処理は次の通りです。

• インデックス作成：Aurora DSQL では単体の CREATE INDEX 文に非同期指定（CREATE INDEX ASYNC）が必須のため、Drizzle が出力する CREATE INDEX を CREATE INDEX ASYNC に変換する処理
• 外部キー制約：Aurora DSQL は外部キー制約をサポートしていないため、Drizzle が生成する外部キー制約の ALTER TABLE（ADD FOREIGN KEY）を削除する処理
• トランザクションの分割：Aurora DSQL は 1 トランザクションにつき DDL を 1 つしか実行できないため、複数の DDL 変更を 1 つのトランザクションでまとめて適用しようとする Drizzle のマイグレーションを、1 つずつ個別のトランザクション（BEGIN … COMMIT）に分割する処理

これらの変換は、Drizzle のマイグレーションを実行するコマンド（npm script）に組み込んでいます。ローカルでも CI/CD パイプラインでも同じコマンドで実行されるため、開発者は通常の Drizzle のワークフローのままスキーマ変更を進められます。

2. トランザクションサイズ制限への対応：大きな更新を複数のトランザクションに分割

Aurora DSQL には、1 トランザクションあたりに変更できる行数に上限があります（3,000 行）。1 試合あたり約 1 万枚の写真それぞれに 5〜6 個のタグを付与します。レコード数はタグだけで約 5〜6 万件に達し、さらに写っている人物の関連付け（人数分のレコード）も登録します。これらをまとめて 1 つのトランザクションで反映すると上限（3,000 行）を超えてしまいます。本システムでは、一時的な不整合が許容できる処理を整理したうえで、分析結果の反映については複数の小さなトランザクションに分割して処理する方式にしました。これにより、1 トランザクションあたりの変更行数を上限内に抑えています。利用者には処理中かどうかの状態を画面に表示し、アップロード・分析の進捗を把握できるようにしています。

3. OCC（楽観的同時実行制御）への対応

Aurora DSQL は OCC を採用しており、コミット時に競合が検出された場合はトランザクションをリトライする必要があります。本システムでは、ドライバー層にリトライ処理を作り込み、競合時には数回リトライしたうえで、それでも成功しない場合はデッドレターキューへ退避させて後続のハンドリングを行っています。

開発・運用面で得られた効果

本システムの設計・実装は、「AWS Prototyping Program」の支援を受けて進めました。これは、AWS の Prototyping Engineer が課題に合わせてシステムのプロトタイプを開発するプログラムです。約 1 か月の開発期間を経て、プロジェクト開始から約 2 か月後には本番稼働まで到達できました。DSQL 採用後に開発チームが実感している効果は次の通りです。

メンテナンスウィンドウ・バージョン管理が不要

「DB の存在を意識せず開発・運用できる」ことが採用後最大のメリットでした。標準でマルチ AZ 構成になっており、実際、本番稼働後 DB 起因の障害は発生していません。従来型の（プロビジョンド構成の）RDB を採用していた場合は 0.5 人月程度を要すると想定していましたが、Aurora DSQL の採用後はこうした作業がほぼ不要となりました。

少人数チームでアプリ開発に集中できる

DBA を専任で置く必要がなく、インスタンスのサイジングやスケーリングといったキャパシティ設計そのものが不要なため、少人数のチームでもアプリケーション機能の実装に集中でき、開発スピードを保てました。本システムはデータベースを含むアプリケーション全体を実質 1 名で開発していますが、サーバーレス構成によりキャパシティを意識せずデータベースを扱えたことが、開発の高速化に直結しています。なお、開発メンバーは PostgreSQL の利用経験があり、DSQL 自体の学習コストはほとんど発生しませんでした。DSQL 固有の制約事項についても理解・把握は短時間で済み、それらへの具体的な対応は前述の「技術的に工夫した点」のとおり実装で吸収しています。

使った分だけの課金で無駄のないコスト構造

稼働に波がある本システムでは、使った分だけの課金というコストモデルが特によく合致しました。アクセスが発生しない時間帯は処理に対するコストがかからないため、こうしたワークロードでも無駄なコストを抑えられています。

性能要件を十分に満たせている

複雑な検索条件を設定してもサムネイル一覧の初期表示は 1 秒以内に収まり、写真分析のスループットも実用上十分な速度で完了しています。実運用において、データベースがボトルネックになったことはありません。もちろん DB 性能だけで実現したわけではありませんが、Aurora DSQL がこれらの要件を性能面の問題なく支えられていることが、システム全体としての設計余地を広げてくれています。

さいごに

株式会社 MIXI では、FC東京向けの写真選定業務効率化システムのバックエンドに Aurora DSQL を採用し、利用が特定の時間帯に偏るワークロードを、運用工数を最小限に抑えながら短期間で本番稼働まで到達させることができました。株式会社 MIXI の數藤氏は次のように振り返っています。

「DB の存在を意識せずに開発・運用できることが一番のメリットでした。メンテナンスやスケーリングの設計から解放され、少人数のチームでもアプリケーション開発に集中できています。こうした特性を持つワークロードでは、今後も積極的に Aurora DSQL を活用していきたいと考えています。」

Aurora DSQL の採用を検討しているチームにとって、本事例が一つの参考になれば幸いです。

株式会社 MIXI ライブエクスペリエンス事業本部 企画推進部 エンジニアリング支援グループ
數藤 智幸 氏