Amazon Web Services ブログ
AWA 株式会社、MongoDB on EC2 から Amazon DocumentDB への移行でデータベースコストを約 50% 削減（Part 2/2）
PART2：23 億ドキュメントの移行プロセスとコスト約 50% 削減の効果 -移行・効果編-
PART1 では、AWA がドキュメント指向データベースの特性をどのように活用しているか、そして Amazon DocumentDB の採用に至った経緯を解説しました。
PART2 では、23 億ドキュメントの大規模環境をニアゼロダウンタイムで Amazon DocumentDB へ移行した具体的なプロセスと、直面した課題、そして移行後の効果についてご紹介します。
移行前後のシステム構成
移行先の構成
移行前の環境は MongoDB 4.4.29、10 シャード・レプリカセット構成、r6a.2xlarge × 20 台（データノード）、23 億ドキュメントという大規模な環境でした（詳細は PART1 の移行対象データベースの概要を参照）。
移行先の Amazon DocumentDB の構成は以下の通りです。
| 項目 | 内容 |
|---|---|
| インスタンス | db.r6g.8xlarge（移行後に db.r8g.8xlarge に変更） |
| ストレージ | I/O-Optimized |
| 構成 | 1 クラスター（Writer + Reader） |
I/O-Optimized ストレージを選択した理由は、コスト予測のしやすさです。
db.r8g への変更は、コスト最適化および Database Savings Plans への対応を目的としています。
移行スケジュール
本プロジェクトは、AWA の少人数の開発チームが自社で実施しました。
本格的なプロジェクトは 2025 年 4 月に始動し、以下のスケジュールで進められました。
| 時期 | フェーズ | 内容 |
|---|---|---|
| 2025 年 4～5 月 | 計画策定 | 移行対象の洗い出し、移行方式の決定 |
| 2025 年 6～7 月 | 準備 | 負荷試験環境の構築、データ連携ツール DB Sync の全コレクション対応 |
| 2025 年 8 月 | 負荷試験 | 通常営業負荷と AWA ラウンジ 高負荷の 2 種類を約 1 ヶ月実施 |
| 2025 年 10 月～ | 並行運用・切り替え | マイクロサービスごとに段階的に切り替え |
| 2025 年 12 月中旬 | 完了 | 全マイクロサービスの切り替え完了 |
11 月に Amazon EC2 の Savings Plans が満了するタイミングに合わせてスケジュールを組みましたが、バッチ処理の切り替えに想定以上の時間がかかり、最終的に 12 月中旬の完了となりました。
データ移行の流れ
データ移行は、自社開発のデータ連携ツール DB Sync を中心に、3 つのフェーズで実施しました。
AWS Database Migration Service (AWS DMS) の利用も検討しましたが、DB Sync で既にデータ連携運用の実績があり、それを流用するほうが安定した移行につながると判断しました。
DB Sync は MongoDB の Change Streams を利用したサブスクリプション形式のデータ同期ツールで、以前から一部コレクションの同期に利用していた実績がありました。
フェーズ 1：初期データロード
mongodump/mongorestore を使用して、MongoDB 上の 23 億ドキュメントのデータを Amazon DocumentDB へ一括投入しました。
フェーズ 2：継続的データ同期
初期ロード完了後、DB Sync で MongoDB と Amazon DocumentDB 間のリアルタイム同期を開始しました。
DB Sync は MongoDB の Change Streams をサブスクライブし、変更イベントを Amazon DocumentDB へ書き込む仕組みです。
今回の移行では、以前の限定的なコレクション同期から全コレクション対応に拡張しました。
フェーズ 3：マイクロサービスごとの段階的切り替え
約 10 のマイクロサービスを、依存関係の少ないものから順に Amazon DocumentDB へ切り替えました。
切り替えは各サービスの DB 接続先を DNS レベルで変更する方式で、サービス停止はほぼ発生していません。
移行途中では、マイクロサービスによって参照先の DB が新旧で異なる状態が発生します。
そのため、サービス間の依存関係を考慮し、他のマイクロサービスへの影響が少ないものから順に切り替えを進めました。
切り戻しも考慮しており、実際に本番で一度切り戻しを実施しています（詳細は後述）。
移行時の課題と対応
Writer への負荷集中と切り戻し
本番環境で大規模な AWA ラウンジ（AWA 独自のライブ配信機能）イベントを実施した際、以前は 10 シャードに分散していた書き込みが 1 クラスターの Writer に集中し、サービスに影響が出ました。
再生ごとにカウントされるクエリがユーザー数分発生し、Writer がボトルネックとなりました。
事前に切り戻しの手順と判断基準を準備していたため、問題発生時に即座に旧環境への復旧を決断できました。切り戻しまでの間に発生した一部の書き込みデータは失われましたが、サービス全体への影響を最小限に抑えることを優先したビジネス判断でした。
その後、以下の対応を実施しました。
- 負荷試験の追加実施: AWA ラウンジ高負荷を模した追加の負荷試験を実施しました。
- 書き込み頻度の調整: インクリメント処理など、高頻度の Write クエリをアプリケーション側で最適化しました。
- Reader/Writer の分離: MongoDB 時代は全てのクエリを Writer（Primary）に送信していた設計を見直し、Amazon DocumentDB の Reader エンドポイントと Writer エンドポイントへの接続を明確に分離。それぞれ専用のドライバー設定を用意しました。
Amazon DocumentDB はコンピューティングとストレージが分離されたアーキテクチャを採用しており、Writer インスタンスとは独立して Reader インスタンスを柔軟に追加できます。
Read ヘビーな AWA のワークロードでは、この Reader/Writer 分離が特に重要でした。
「Reader と Writer を意識してアプリケーションを組むようになりました。
やらないと Writer に負荷が集中してしまい、Reader のスケールメリットを活かせません。
Amazon DocumentDB のベストプラクティスを学んで、頭を切り替えていきました。」
データ同期の課題
DB Sync を全コレクション対応に拡張した際、2 つの問題が発生しました。
1. 同期サーバーの過負荷
以前は限定的なコレクションのみ同期していたため、全コレクション対応で同期サーバーが過負荷になりました。
2. ObjectID 型のハンドリング
主キーの大半は String 型でしたが、一部コレクションで ObjectID 型が使われており、正しく同期されないケースが発生しました。
この問題は移行後に発覚し、迅速に対応を行いました。
データ同期ツールを使用する場合、データ同期ツール自体に精通しておくことだけでなく、全コレクションのスキーマとデータ型を事前に網羅的に把握しておくことが重要です。
TLS 通信と認証への対応
移行で最も工数がかかったのは、Amazon DocumentDB の TLS 通信と ID/パスワード認証への対応でした。
Amazon DocumentDB では TLS がデフォルトで有効化されており、以前の MongoDB 環境ではネットワーク隔離のみで認証を設定していなかったため、接続設定の変更が必要になりました。
「一番大変だったのは、ID/パスワード認証の対応でした。
以前の MongoDB では設定していなかったのですが、Amazon DocumentDB では必要となるため、これを機に認証と通信の暗号化を導入しました。」
結果的にセキュリティの向上につながりましたが、移行を検討される際は事前に認証設定の影響範囲を確認しておくことをお勧めします。
MongoDB 互換性
AWA では複雑なアグリゲーションパイプラインを使用しない方針を取っていたため、クエリの互換性問題はほとんど発生しませんでした。
find、update、insert を中心としたシンプルなクエリパターンにより、Web アプリケーションのクエリに関してはAmazon DocumentDB Compatibility Toolでの事前確認でも問題は検出されませんでした。
一部、古いバッチ処理と Go 言語のドライバーで対応が必要な箇所がありましたが、影響は限定的でした。
PART1 で紹介したスキーマレス設計、配列・ネスト構造を活用したデータモデル、Read 最適化のインデックス戦略、Go Struct によるスキーマ管理といったドキュメント指向 DB の設計は、Amazon DocumentDB 上でも問題なく動作しています。
Amazon DocumentDB への移行の効果
移行前後の比較
| 項目 | 移行前（MongoDB on Amazon EC2） | 移行後（Amazon DocumentDB） |
|---|---|---|
| 構成 | 10 シャード、レプリカセット | 1 クラスター（Writer + Reader） |
| インスタンス | r6a.2xlarge × 20 台 | db.r8g.8xlarge（Writer + Reader） |
| 月額コスト | – | 約 50% 削減 |
| バージョンアップ | 10 クラスター個別対応 | マネージドサービスで一括管理 |
| バックアップ | Cloud Manager 20 世代管理 | 自動バックアップ + PITR |
| スケール変更 | シャード削減が困難（数ヶ月かかることも） | Reader の追加・削除が容易 |
| 認証・暗号化 | 未設定（ネットワーク隔離のみ） | TLS 通信 + ID/パスワード認証 |
| ネットワーク | MongoDB 専用サブネットで複雑な隔離構成 | Amazon VPC 内でシンプルな構成 |
※ 移行前コストには Amazon EC2、Cloud Manager、バックアップ、通信費を含みます。
コスト削減
データベース関連コストは約 50% 削減されました。
コスト試算は、ベストプラクティスドキュメントを参考に既存クラスターの CPU・メモリ使用率から必要スペックを机上計算し、負荷試験で実証した上で本番稼働させています。
さらに、Database Savings Plans の適用により追加で約 20% の削減を見込んでいます。
性能
20 台の Amazon EC2 インスタンス（10 シャード構成）から 1 クラスターへの集約にもかかわらず、レスポンスタイムに大きな変化はありませんでした。
コンテンツ配信という特性上 Read ヘビーなワークロードであり、Amazon DocumentDB の Reader インスタンスを活用して Read 処理を分散させることで、台数を大幅に削減しつつ性能を維持できています。
MongoDB のシャーディング構成ではスケールダウンに数ヶ月を要することもありましたが、Amazon DocumentDB では Reader の追加・削除が容易です。
運用
マネージドサービスの活用により、特定のエンジニアに集中していたバージョンアップやノード障害対応の負荷が軽減され、スロークエリの改善などアプリケーション本来の改善に注力できるようになっています。
モニタリングについては、Datadog と連携した Amazon DocumentDB 用監視ダッシュボードを構築し、フェイルオーバー検知には AWS Chatbot を使用して Slack に通知する体制を整えています。
今後は、Amazon DocumentDB のクローン機能を活用し、本番データを用いた負荷試験環境の迅速な構築にも役立てていく予定です。
補足：Amazon DocumentDB のクローン機能とは
本番クラスターのデータを短時間かつ追加ストレージコストを抑えてコピーできる機能です。コピー元とコピー先でストレージを共有する Copy-on-Write 方式のため、クローン作成時点ではデータの物理コピーが発生せず、大規模なクラスターでも高速にクローンを作成できます。
セキュリティ
移行前は MongoDB 用に専用サブネットを作成し、複雑なネットワーク構成で隔離していました。
Amazon DocumentDB への移行により、TLS 通信と ID/パスワード認証が導入され、ネットワーク構成も簡素化されました。
10 年以上前に構築された初期のネットワーク構成を、移行のタイミングで整理できたことも副次的な効果です。
移行を検討されている方へ
本プロジェクトを通じた気づきとして、以下の点に留意されることをおすすめします。
「反省として、流れてくる Write クエリの頻度とタイミングを事前に詳細に把握しておくべきでした。」
- Write クエリの頻度とパターンを事前に詳細に把握する: シャーディング構成から 1 クラスターへの集約では、Writer への負荷集中が最大のリスク。特にイベント時など負荷が変動するワークロードでは、ピーク時の Write パターンを把握した上で負荷試験を実施することが重要です。
- Reader/Writer の分離設計を事前に計画する: Amazon DocumentDB のアーキテクチャを活かすため、アプリケーション側で Reader と Writer を意識した設計に変更することをお勧めします。
- TLS 通信と認証の影響範囲を事前に確認する: Amazon DocumentDB では TLS と認証がデフォルトで有効化されているため、MongoDB で未設定の場合は接続設定の変更が必要です。
- データ同期ツールを使用する場合、全コレクションのスキーマを網羅的に把握する: 特にデータ型の違い（String vs ObjectID など）に注意が必要です。
「相当凝ったクエリでもなければ MongoDB のまま移行できると思います。今回は ID/パスワード認証の対応が最も大変でした。」
今後に向けて
「今回の移行はラスボスぐらいの強敵でしたが、やっと倒せました。
マネージドで、気持ちの面でも運用の面でも楽になりました。
副次的に、ドライバーのアップグレードや通信の暗号化など、気になっていた部分を改善するきっかけにもなりました。
今後は Database Savings Plans の適用や Amazon DocumentDB Serverless の検証を進め、さらなるコスト最適化を目指していきます。
マネージドに極力寄せていける構成にしていきたいです。」
「これまでバージョンアップやノード障害の対応に追われていましたが、今後はスロークエリの改善など、本来注力すべき領域に集中できるようになりました。
Amazon DocumentDB では Reader の増減やスペックの上げ下げも柔軟にできると期待しています。」
まとめ
AWA 株式会社は、MongoDB on Amazon EC2 から Amazon DocumentDB への移行により、以下の成果を達成しました。
- データベースコスト約 50% 削減（さらに Database Savings Plans で約 20% の追加削減を見込み）
- 23 億ドキュメントのニアゼロダウンタイム移行
- 20 台の Amazon EC2 インスタンスから 1 クラスターへの集約（性能を維持）
- 運用負荷の大幅軽減と属人化の解消
- セキュリティの向上（TLS 通信、認証、ネットワーク構成の簡素化）
2022 年の構想から約 4 年。
マネージドサービスへの集約という一貫した方針のもと、大規模移行を完遂した AWA の事例は、MongoDB 環境から Amazon DocumentDB への移行を検討している企業にとって、具体的な道筋を示すものです。
Amazon DocumentDB の詳細については、以下のリソースをご参照ください。
Amazon DocumentDB のベストプラクティス
MongoDB からの移行に使えるドキュメント
Amazon DocumentDB の便利なツール群
以下のツールは Amazon DocumentDB Tools リポジトリで公開されています。
- compat-tool — MongoDB との互換性チェック
- index-tool — インデックスの分析・最適化
- migration — 移行支援ツール
- sizing-tool — サイジング見積もり
- monitoring — モニタリング
- performance — パフォーマンス分析
- operations — 運用支援
信田 悟至 氏 |
山下 剛史 氏 |
小林 健太郎 氏 |
AWA 株式会社
信田 悟至 氏
山下 剛史 氏
株式会社サイバーエージェント メディア統括本部 SRE
小林 健太郎 氏
本ブログは、データベーススペシャリストソリューションアーキテクトの藤田 将大とシニアソリューションアーキテクトの半場 光晴が執筆しました。