Amazon DocumentDBの導入効果をレビューでご紹介(株式会社現場サポート)

参考になった

レビュー投稿日の情報になります

株式会社現場サポート / 飯伏政樹

開発部長 / SRE / 従業員規模: 101名〜300名 / エンジニア組織: 11名〜50名

最終更新日2026/01/07投稿日2026/01/08

利用プラン	ツールの利用規模	ツールの利用開始時期	事業形態
5.0	11名〜50名	2023年1月	B to B

利用プラン	5.0
ツールの利用規模	11名〜50名
ツールの利用開始時期	2023年1月
事業形態	B to B

導入の背景・解決したかった問題

導入背景

ツール導入前の課題

アプリと同インスタンスでmongodbをシングル運用してきていたが、ストレージ管理の煩雑さだったり、アプリとDBが分離できていないことによる手間だったり、スケールしづらいことからDBを分けることを検討。 MongoDB AtlasとAmazon DocumentDBで比較検討してDocumentDBを採用

どのような状態を目指していたか

比較検討したサービス

MongoDB Atlas

比較した軸

パフォーマンスが低下しないこと
運用の手間がかからないこと
金銭コストがある程度おさえられること

選定理由

パフォーマンス面で、アプリのEC2インスタンスと同VPC内に配置できるDocumentDB

導入の成果

改善したかった課題はどれくらい解決されたか

工数は1割ほどにまで削減された。適切なアラーム設定やパフォーマンスログの活用が軌道に乗ったいまはインスタンスやクラスタに対する再起動をともなうパッチ適用をサービス影響を最小化するために手動で実施する他はさらに少なくなっている。

導入時の苦労・悩み

互換性の確認に工数がかかった(トータルで1人月以上) 当時はDMSがなく(もしくは知らず)システム停止時間を抑えるための検討に苦慮した。

導入に向けた社内への説明

上長・チームへの説明

アプリケーションとmongodbが同インスタンス内に同居することでリソースを奪い合いパフォーマンス低下が時々発生していたので両者の分離については容易に合意がとれた。開発者が運用を兼任していたため、工数削減のためにマネジメントサービスを利用することも説得材料のひとつとなった。

また、GridFSをファイル格納に用いていたことでストレージ枯渇しそうになることがあったため、ストレージがスケーラブルなDocumentDBの利用を通しやすかった。

活用方法

よく使う機能

mongodb互換機能
自動バックアップ
ストレージの自動スケール
failoverによるメンテナンス時のダウンタイム最小化

ツールの良い点

ストレージがスケーラブルでメンテナンスいらず
パフォーマンスログでアプリケーションの最適化のための情報をフィードバック
サーバーレスインスタンスによって性能とコスト最適化を両立

ツールの課題点

GridFSの肥大化による性能劣化(これはmongodbのものか、documentdbなのか不明瞭)
メンテナンス時のダウンタイム(2,3ヶ月に1度くらいの頻度でどうしても不可避)
日本語検索機能が弱い

ツールを検討されている方へ

mongodbの機能を小工数で効率的に利用したいならとてもよい選択肢だとおもいます。スケールが容易ですし。運用している最中もインスタンスタイプの拡充やRI/SavingsPlansへの対応などどんどん改善されて来ています。

ただしGridFSは複数chunksに渡る大サイズ(数MBを超えるようなサイズ)の場合は使わないほうがいいです。少なくとも、chunksサイズを調整した上でのパフォーマンス検証は事前に済ませておくことは必要です(要件が途中で変わってしまうこともあるのでファイルサイズの想定は十分に大きめに)。もしくは、最初からS3など大容量向きのツール活用をオススメします。