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は今後も積極的に同サービスの活用を進めていく方針だ。