AWA 株式会社、MongoDB on EC2 から Amazon DocumentDB への移行でデータベースコストを約 50% 削減（Part 1/2）

PART1：ドキュメント指向データベースの活用と Amazon DocumentDB の選択 -検討編-

AWA 株式会社は、1 億 8,000 万曲以上の楽曲を提供する音楽ストリーミングサービス「AWA」を運営しています。
独自のライブ配信機能「AWA ラウンジ」やフラワーチャット / フラワースタンプ（投げ銭）機能を備え、幅広いデバイスに対応しています。

2015 年のサービス開始当初から AWS 上でシステムを構築してきた同社は、2025 年にサービス基盤のデータベースを MongoDB on Amazon EC2 から Amazon DocumentDB（MongoDB 互換）へ移行しました。
本ブログシリーズでは、ドキュメント指向データベースの活用方法と Amazon DocumentDB への移行プロセス、そして移行後の効果について、全 2 回に分けてお客様の声を紹介いたします。

PART1（本記事）: ドキュメント指向データベースの活用と Amazon DocumentDB の選択
PART2: 23 億ドキュメントの移行プロセスとコスト約 50% 削減の効果

移行検討の背景と課題

AWA では、マイクロサービスの実行基盤に Amazon ECS on AWS Fargate、キャッシュに Amazon ElastiCache for Redis、検索基盤に Amazon OpenSearch Service を採用するなど、「マネージドサービスへの集約」と「技術スタックの統一」を方針として掲げ、段階的にマネージドサービスへの移行を進めてきました。
その中で最後に残っていた大物が、Amazon EC2 上で MongoDB Cloud Manager を使用してセルフホストしていたデータベースでした。

この環境には、いくつかの運用上の課題がありました。

コストの高騰: セルフホスト環境の運用コストに加え、Cloud Manager の仕様変更によりバックアップコストがさらに増大した。
スケールダウンの困難さ: ピーク時に合わせて拡張した 10 シャード構成を縮小できなかった。
バージョンアップの負荷: 複数環境のクラスターを個別にアップグレードする必要があり、その作業中に予期しないエラーでの中断が発生、サポートケースへの問い合わせが頻発した。
事業継続リスク: MongoDB クラスターの運用には専門的な知識が求められ、対応できるエンジニアが限られていた。担当者が不在の際の障害対応や、引き継ぎの難しさが事業継続上のリスクとなっていた。

当初は、MongoDB のシャード数を削減してスペックを調整し、コストを最適化する案も検討されていました。
しかし、シャードを減らすためのデータ退避が何ヶ月経っても完了せず、最終的に MongoDB 側の問題であることが判明しました。
この経験から、セルフホスト環境でのコスト最適化に限界を感じ、マネージドサービスへの移行に舵を切ることになりました。

2022 年にマネージド化の計画書が作成されましたが、本格的にプロジェクト化したのは 2025 年 4～5 月でした。
Cloud Manager のバックアップコスト高騰が最終的な決め手となり、約 4 年越しの移行プロジェクトが始動しました。

移行前のシステム構成

移行対象データベースの概要

項目	内容
DB エンジン	MongoDB 4.4.29（Cloud Manager 管理）
構成	10 シャード、各シャードがレプリカセット
インスタンス	r6a.2xlarge × 20 台（データノード）
ドキュメント数	約 23 億 ( TB 規模 )
主な格納データ	アーティスト情報、プレイリスト、ログイン情報、再生回数、AWA ラウンジ機能
アプリケーション言語	Go
クエリパターン	find、update、insert が中心（アグリゲーションパイプライン不使用）
Read/Write 比率	約 30:1 以上（コンテンツ配信の特性上、Read ヘビー）

AWA におけるドキュメント指向データベースの活用

AWA はサービス開始当初からドキュメント指向データベースを採用しており、そのデータモデルはサービスの特性と深く結びついています。
移行先の選定にあたっては、ドキュメント指向 DB であることが重要な要件でした。

スキーマレス設計：サービス無停止でのスキーマ変更

「スキーマレスのところが最高です。
AWA のポリシーとして、メンテナンスによるサービス停止をゼロに近づけたい。
ALTER TABLE のためにサービスを止めるようなことはできれば避けたいですからね。」

AWA では、新しいコレクション（RDB におけるテーブルに相当）の追加が 2～3 ヶ月に 1 回程度、既存コレクションのフィールド変更 ( RDB における列追加などに相当 ) が月 1～2 回程度の頻度で発生します。
ドキュメント指向データベースでは、これらの変更をサービスを停止することなく実施できます。
新しいフィールドを追加する際は後方互換を保つようにフォールバック処理をコードに組み込み、新しいフィールドがないドキュメントに対してもアプリケーション側で対応する運用を採用しています。

スキーマレスの柔軟性を活かしつつ統制を保つため、Go 言語の Struct 定義をスキーマの正として管理しています。
Go のフィールド定義がそのまま DB スキーマに反映される仕組みで、直接 DB を変更することはせず、必ず Go コードを通じてアクセスする運用です。
アプリケーションのクラス定義と DB のデータ構造が一致するため、RDB で必要になるようなオブジェクトとテーブル間のデータ変換が不要です。
開発者は DB の構造を意識せずにアプリケーションのコードに集中でき、変換処理に起因するバグも防げます。

RDB : アプリのオブジェクト → O/R マッピング → テーブル（変換が必要）
ドキュメント指向DB : Go Struct → そのまま JSON ドキュメント

配列・ネスト構造：JOIN 不要のシンプルなクエリ

AWA では、ドキュメント指向データベースの柔軟なデータモデリングを活用しています。以下に、2 つの活用例を紹介します。

配列の活用例：外部サービス連携の管理

ユーザーが連携を許可した外部サービスの ID を配列として保持し、「特定のサービスと連携しているユーザーを検索する」といったクエリを、外部キーや JOIN を使わずにシンプルに実現しています。

RDB では、ユーザーテーブルと連携サービステーブルを外部キーで関連付け、JOIN で結合する必要がある処理を、1 回のクエリで完結できます。

ネスト構造の活用例：認証情報の管理

ユーザードキュメント内に外部認証サービスのログイン情報をネストしたオブジェクトとして格納し、auth_provider.id のようなドット記法のクエリで、特定の外部認証サービスの ID でログインしているユーザーを直接検索できます。
RDB であれば外部キーと JOIN が必要になる処理を、1 回のクエリで完結できます。

非正規化設計：Read ヘビーなサービスに最適化

AWA のサービスはコンテンツ配信という特性上、Read に大きく寄っています。
この特性を活かし、あえて正規化せず 1 ドキュメントに関連する ID を配列で保持する設計を採用しています。
1 つのドキュメントを取得すれば関連するエンティティの ID が全て分かり、それらの実体を主キーで取得するという 2 段階のクエリで、必要なデータを効率的に取得できます。

クエリの運用性を高めるため、複雑なクエリやアグリゲーションパイプラインは使用しない方針を取っています。
MongoDB のバージョンアップで仕様が変わることがあったため、アグリゲーションが必要にならないようデータ構造自体を設計し、集計が必要な値は書き込み時にカウントアップする方式を採用しています。
これにより、読み込み時に集計処理を実行する必要がなくなり、Read の負荷軽減にもつながっています。

インデックス戦略：Read 最適化の設計

AWA では、アプリケーションから発行される全ての Read クエリに対して専用のインデックスを設定しています。
論理削除フラグには専用のインデックスを設け、日付範囲検索にもクエリごとのインデックスを用意するなど、Read 性能を最優先としたインデックス戦略です。
多数のコレクション・インデックスを運用していますが、クエリごとに専用インデックスを設計しているため、意図しない実行計画が選択されることはほとんどありません。
MongoDB ではクエリがパイプライン形式で実行されるため、RDB のように複数テーブルの JOIN で実行計画が複雑化しにくいという特性も寄与していると考えられます。

Amazon DocumentDB を選択した理由

AWA がこれらのドキュメント指向 DB の設計を維持しつつ、移行先として Amazon DocumentDB を選択した理由は大きく 3 つあります。

1. MongoDB 互換による低リスクな移行

「MongoDB にこだわりはなく、ドキュメント指向 DB であることが大事。
MongoDB との高い互換性がある Amazon DocumentDB が最も移行しやすかった。」

Amazon DocumentDB は MongoDB との互換性を備えており、AWA で使用していた find、update、insert といった基本的なクエリはそのまま動作しました。

2. 本番実績に基づく性能への信頼

AWA では移行前から別のワークロードで Amazon DocumentDB を利用しており、1 クラスター・1 ノードの xlarge～2xlarge 程度のインスタンスで高い書き込み性能を確認していました。
MongoDB で 10 シャードに分散していた処理を、Amazon DocumentDB の 1 クラスターで処理できるという仮説が、既に本番環境で裏付けられていました。

3. AWS への集約によるコストと運用の最適化

「AWS に集中していたほうがやりやすい。
セキュリティ的にも Amazon VPC 内で完結させたかった。」

MongoDB Atlas も検討しましたが、AWS 上で全てを管理したいという方針から Amazon DocumentDB を選択しました。
Amazon VPC 内で通信を完結させることでセキュリティ要件を満たしつつ、ネットワーク構成を簡素化できる点も決め手の一つでした。

また、Amazon DocumentDB はコンピューティングとストレージが分離されたアーキテクチャを採用しており、Read ヘビーな AWA のワークロードに対して Reader インスタンスを柔軟にスケーリングできます。
マネージドサービスとしての自動バックアップや PITR も、運用負荷の軽減に寄与すると判断しました。

なお、Amazon DocumentDB Serverless も検討しましたが、11 月の Amazon EC2 Savings Plans 満了に合わせた移行スケジュールの中で検証時間を確保できなかったため、まずはインスタンスベースで移行し、今後の検証課題としています。

次回予告

PART1 で紹介したスキーマレス設計、配列・ネスト構造、非正規化設計、インデックス戦略といったドキュメント指向 DB の設計は、Amazon DocumentDB でどのように機能したのか。
PART2 では、23 億ドキュメントのニアゼロダウンタイム移行の具体的なプロセスと直面した課題、そしてコスト約 50% 削減を含む移行後の効果についてご紹介します。

[Part 2 に続く]

信田悟至氏

山下剛史氏

小林健太郎氏

AWA 株式会社

信田悟至氏
山下剛史氏

株式会社サイバーエージェントメディア統括本部 SRE