MongoDB on EC2 を長年運用してきたエンジニアにとって、「そろそろマネージドサービスに移行したい」という思いは共通のテーマではないでしょうか。パッチ適用、バックアップ管理、シャード構成のスケールアップ——これらの運用負荷は年々積み重なり、本来注力すべきアプリケーション改善の時間を奪っていきます。
今回は、音楽ストリーミングサービス「AWA」を提供するAWA株式会社が実施した、MongoDB on EC2 から Amazon DocumentDB への大規模移行事例（AWS公式ブログより）をもとに、実際の移行プロセスで直面した課題と、エンジニアが事前に把握すべきポイントを整理します。
移行の背景と規模感
AWA株式会社のデータベース環境は、移行前の時点で以下のような大規模な構成でした。
項目 | 内容 |
|---|---|
MongoDBバージョン | 4.4.29 |
構成 | 10シャード・レプリカセット |
インスタンス | r6a.2xlarge × 20台（データノード） |
ドキュメント数 | 約23億件 |
2022年から「マネージドサービスへの集約」という方針を掲げ、約4年の歳月を経て2025年12月に全マイクロサービスの移行を完了しました。移行後の構成は db.r8g.8xlarge（Writer + Reader）の1クラスター構成となり、データベースコストの約50%削減を実現しています。さらにDatabase Savings Plansの適用で追加20%削減も見込んでいます。
3フェーズで実施した移行プロセス
AWAの移行は、自社開発のデータ連携ツール「DB Sync」を中心に、3つのフェーズで進められました。AWS Database Migration Service（DMS）も検討されましたが、DB Syncの運用実績を活かすことで安定した移行を実現しています。
DB SyncはMongoDBのChange Streamsを利用したサブスクリプション形式のリアルタイム同期ツールです。今回の移行では、限定的なコレクションの同期から全コレクション対応に拡張して使用しました。
移行スケジュールは以下の通りです。
時期 | フェーズ | 主な内容 |
|---|---|---|
2025年4〜5月 | 計画策定 | 移行対象の洗い出し・移行方式の決定 |
2025年6〜7月 | 準備 | 負荷試験環境の構築、DB Syncの全コレクション対応 |
2025年8月 | 負荷試験 | 通常負荷とピーク負荷の2種類を約1ヶ月実施 |
2025年10月〜 | 並行運用・切り替え | マイクロサービスごとに依存関係の少ないものから順次切り替え |
2025年12月 | 完了 | 全マイクロサービスの切り替え完了 |
切り替えは各サービスのDB接続先をDNSレベルで変更する方式を採用し、ニアゼロダウンタイムでの移行を実現しています。
移行で直面した3つの課題
大規模な移行であったため、本番環境でも複数の課題に直面しました。それぞれの対応策とともに振り返ります。
課題1 Writerへの負荷集中と切り戻し
大規模なライブ配信イベント開催時に、以前は10シャードに分散していた書き込みが1クラスターのWriterに集中し、サービスに影響が出ました。事前に切り戻し手順を準備していたため即座に旧環境へ復旧でき、影響を最小限に抑えることができました。
その後、以下の対応を実施しています。
- AWAラウンジ高負荷を模した追加負荷試験の実施
- 高頻度のWriteクエリをアプリケーション側で最適化（インクリメント処理の見直しなど）
- ReaderエンドポイントとWriterエンドポイントへの接続を明確に分離
Amazon DocumentDBはコンピューティングとストレージが分離されたアーキテクチャのため、Readerインスタンスを柔軟に追加できます。Read中心のワークロードでは、この分離設計を前提にアプリケーションを設計することが重要です。
課題2 データ同期ツールの拡張時の問題
DB Syncを全コレクション対応に拡張した際、同期サーバーの過負荷と、一部コレクションでObjectID型が正しく同期されないという2つの問題が発生しました。後者は移行後に発覚したため、全コレクションのスキーマとデータ型を事前に網羅的に把握しておくことの重要性を改めて認識したとのことです。
課題3 TLS通信とID/パスワード認証への対応
移行で最も工数がかかったのがこの認証対応でした。Amazon DocumentDBではTLSがデフォルトで有効化されており、以前のMongoDB環境ではネットワーク隔離のみで認証を設定していなかったため、接続設定の変更が必要になりました。結果的にセキュリティ向上につながりましたが、移行前に影響範囲を確認しておくことが推奨されます。
移行後の効果と定量的な成果
移行完了後、AWA株式会社は以下の成果を達成しています。
評価項目 | 移行前（MongoDB on EC2） | 移行後（Amazon DocumentDB） |
|---|---|---|
月額コスト | 基準値 | 約50%削減（Savings Plans適用でさらに約20%削減見込み） |
インスタンス台数 | r6a.2xlarge × 20台 | db.r8g.8xlarge（Writer + Reader） |
レスポンスタイム | 基準値 | 大きな変化なし |
バックアップ | Cloud Manager 20世代管理 | 自動バックアップ + PITR |
スケール変更 | シャード削減に数ヶ月かかることも | Readerの追加・削除が容易 |
セキュリティ | ネットワーク隔離のみ | TLS通信 + ID/パスワード認証 |
20台のEC2インスタンス（10シャード構成）から1クラスターへ大幅に集約しながらも、レスポンスタイムは維持されています。これはAmazon DocumentDBのReaderインスタンスを活用したRead処理の分散が有効に機能した結果です。
運用面では、特定エンジニアに集中していたバージョンアップ対応やノード障害対応の負荷が軽減され、スロークエリの改善など本来注力すべき領域への集中が可能になりました。モニタリングはDatadogと連携した監視ダッシュボードを構築し、フェイルオーバー検知にはAWS ChatbotでSlack通知を整備しています。
移行を検討するエンジニアが事前に確認すべきポイント
AWAの事例から、MongoDB on EC2からAmazon DocumentDBへの移行を検討する際に重要な確認事項をまとめます。
Writeクエリのパターン把握
シャーディング構成から1クラスターへの集約では、Writerへの負荷集中が最大のリスクです。特にイベント時など負荷が変動するワークロードでは、ピーク時のWriteパターンを詳細に把握した上で負荷試験を設計してください。
Reader/Writer分離の設計
Amazon DocumentDBのアーキテクチャを活かすため、アプリケーション側でReaderとWriterを意識した設計への変更を事前に計画することをお勧めします。この設計なしではReaderのスケールメリットを活かせません。
TLS認証の影響範囲確認
Amazon DocumentDBではTLSと認証がデフォルトで有効化されています。既存のMongoDB環境で未設定の場合、接続設定の変更が必要になります。全接続箇所の事前確認が重要です。
スキーマとデータ型の網羅的な把握
データ同期ツールを使用する場合、全コレクションのスキーマとデータ型（特にString型とObjectID型の混在など）を事前に把握しておくことで、同期時の予期せぬ問題を防げます。
互換性の事前確認
Amazon DocumentDB Compatibility Toolを使用して、既存クエリの互換性を事前に確認しておくことをお勧めします。複雑なアグリゲーションパイプラインを使用していない場合は、多くのケースで問題なく移行できます。
まとめ
AWA株式会社の事例は、23億ドキュメントという大規模な環境でも、適切な計画と準備によってニアゼロダウンタイムでの移行が実現できることを示しています。
「相当凝ったクエリでもなければ、MongoDBのまま移行できると思います」というAWAエンジニアの言葉が示すように、Amazon DocumentDBはMongoDBとの互換性が高く、移行のハードルはそれほど高くありません。最大の工数はTLS認証対応とWriter負荷の最適化にあったことが、今回の事例から分かります。
MongoDB on EC2の運用に課題を感じているチームにとって、本事例が移行検討の具体的な参考となれば幸いです。Amazon DocumentDBの詳細については、公式ベストプラクティスドキュメントや移行ガイドも合わせてご参照ください。
