LASSIC Media らしくメディア

LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託

MongoDB Atlasのコスト構造とは

MongoDB Atlasコスト最適化とは、クラスター階層・ストレージ・バックアップ・データ転送など複数の課金要素を継続的に見直し、無駄な支出を抑えながら性能を維持する取り組みを指します^*1。クラウドプロバイダー（AWS・Azure・Google Cloud）とリージョンの選択、クラスター階層、ストレージ容量、ノード数がそれぞれ独立して課金対象になる点が特徴です^*1。

Atlasの課金要素は大きく分けて、クラスター階層（コンピュートとデフォルトストレージ）、カスタムストレージ容量、カスタムIOPS、ノード数（レプリカ数・シャード数）、バックアップ、データ転送の6つです^*1。このうちどれか一つを見誤ると、想定より高い請求につながりやすい構造になっています。

請求内容を継続的に把握するには、Atlas標準のCost Explorerを使い、組織・プロジェクト・クラスター・サービスの単位で定期的に確認することが推奨されています^*2。月次のコスト閾値を超えた場合に通知する課金アラートの設定も、公式ドキュメントが推奨する運用方法の一つです^*2。

クラスター階層とインスタンスサイズが費用を左右する

MongoDB Atlasのクラスターは、無料のFree（M0）、少量データ向けのFlex、本番向けの専用（Dedicated）クラスターに大別されます^*3。2025年2月には、従来のM2/M5共有クラスターとサーバーレスインスタンスを置き換える形でFlexティアが正式提供（GA）されました^*3。2026年1月22日以降、AtlasはM2/M5クラスターとサーバーレスインスタンスの新規作成をサポートしておらず、既存インスタンスは利用状況に応じてFree・Flex・専用クラスターのいずれかへ移行されています^*3。

専用クラスターはM10からM700まで段階的に用意されており、階層が上がるごとにRAM・ストレージ上限・ネットワーク帯域幅・同時接続数が拡大します^*4。M10とM20は共有vCPUを使い、レプリカセット構成のみをサポートする低トラフィック向けの階層です^*4。M30以上は専用vCPUを持ち、レプリカセットとシャードクラスターの両方に対応する構成で、公式ドキュメントは持続的な負荷がかかる本番環境ではM30以上を推奨し、M10・M20を継続的な高負荷用途に使うことは推奨していません^*4。

階層選定では、ワーキングセット（頻繁にアクセスするデータとインデックスの合計サイズ)に対して十分な物理RAMを確保できるかが判断基準になります^*4。M30以下はWiredTigerキャッシュとして物理RAMの約25%を使う設計であるのに対し、M40以上では50%以上を使う設計になっており、同じデータ量でも階層によって余裕度が変わってきます^*4。この計算を誤って小さい階層を選ぶと、キャッシュミスの増加によって性能が低下し、結局は上位階層への移行が必要になるケースも起こり得ます。

ストレージ容量とIOPSカスタマイズの費用影響

各クラスター階層には既定のストレージ容量が含まれており、この既定容量分はクラスターの時間単価に含まれます^*1。一方でストレージ容量をデフォルトから引き上げると、増量分は個別に課金される仕組みです^*1。例えばM10クラスターは既定10GBですが、これを50GBにカスタマイズした場合は50GB分がまるごと課金対象になります^*1。

ストレージの速度（IOPS）もコストに影響する要素です。AWSでは汎用SSDからプロビジョニングIOPS SSDへ変更する形でStandardからFast・Fastestへアップグレードでき、AzureのPremium SSDやGoogle CloudのSSD永続ディスクでは、ストレージ容量の増加に伴うIOPS増加分が費用に含まれます^*1。AWSのGen2専用クラスターでは、拡張Standard IOPSによりIOPSとストレージ容量を独立してスケーリングでき、IOPS費用がストレージとは別に課金される構成も用意されています^*1。

ストレージ関連費用を抑える手段として、公式ドキュメントはOnline Archiveによる古いデータのコールドストレージ移行や、TTL（Time To Live）インデックス（一定期間経過後にドキュメントを自動削除する仕組み）を使った不要データの自動削除を挙げています^*2。アーカイブしたデータはAtlas Data Federationを通じて引き続き参照できるため、参照頻度が低いデータを本体クラスターから切り離すことでストレージコストの圧縮につながります^*2。

オートスケーリングの仕組みとコスト管理の勘所

Atlasのオートスケーリングには、コンピュート階層を自動調整する仕組みと、ストレージ容量を自動拡張する仕組みの2種類があります^*5。コンピュート側にはリアクティブ型と予測型の2方式があり、リアクティブ型は現在のリソース使用率を見てスケーリング後に対応するのに対し、予測型は機械学習で将来の負荷を見込んでスケーリング前に対応します^*5。

スケールアップの判定基準は階層によって異なります。M30以上は過去10分間の平均CPU使用率が90%を超えた場合、M10・M20は過去1時間の相対CPU使用率が75%を超えた場合にスケールアップが検討されます^*5。スケールダウンには、直近24時間にスケール変更がないこと、CPU使用率が過去4時間と過去10分間の両方で45%未満であることなど、複数条件を同時に満たす必要があります^*5。

この設計をコスト最適化に活かすには、下限と上限のクラスターサイズを明示的に指定し、想定外の高額階層まで自動的に引き上がらないよう範囲を制御することが欠かせません^*5。スケーリングにはバックエンドリソースの準備時間を要するため、突発的な大量データ投入のような急激な負荷増には追随しきれない場合があり、事前の手動スケールアップが推奨されています^*5。オートスケーリングを設定しただけで放置すると、需要が落ち着いた後も上位階層に張り付いたままになり、コスト増加に気づきにくい状態が続くこともあります。

バックアップ課金とデータ転送コストの内訳

Atlasのクラウドバックアップは、クラウドプロバイダーごとに1GB・1か月あたりの単価が設定されており、公式ドキュメントの目安ではAWSが0.14〜0.19ドル、Azureが0.34〜0.65ドル、Google Cloudが0.08〜0.12ドルとなっています^*1。ポイントインタイムリストア（任意の時点への復元）に対応する継続バックアップは、保持データ量に応じたティア制の単価が適用され、データ量が大きいクラスターほど1GBあたりの単価が下がる階段状の料金構造です^*1。

データ転送費用は転送経路によって単価が異なり、同一リージョン内の転送が最も低コストで、リージョンをまたぐ転送、インターネット経由の転送の順にコストが上がる構造です^*2。公式ドキュメントは、可能な限りアプリケーションとクラスターを同じクラウドプロバイダー・同じリージョンに配置し、リージョン間転送やインターネット転送を必要な場合に限定することを推奨しています^*2。

バックアップコストを抑えるには、重要度の低いクラスターでバックアップ頻度を落とす、継続バックアップが不要な場合は無効化する、復元ウィンドウの期間を短縮するといった調整が有効です^*1。ただし、これらは復旧時点(RPO)や障害対応の要件と表裏一体であるため、コスト削減だけを目的に一律で頻度を下げると、いざという時の復旧可否に影響しかねません。

クラスター一時停止とシャーディングの費用影響

M10以上の専用クラスター（NVMeストレージを使わない構成に限る）は一時停止（Pause）が可能で、一時停止中はストレージ費用のみが発生し、コンピュートやデータ転送の課金は止まります^*6。一時停止できる期間は最長30日間で、30日を超えると自動的に再開される仕様です^*6。また、再開直後のクラスターは、一時停止中に滞留したメンテナンス処理を実行するため、最低60分間の稼働を経てからでないと再び一時停止できません^*6。Free（M0）クラスターは30日間操作がない場合に自動一時停止となる一方、Flexクラスターはそもそも一時停止に対応していません^*6。

シャーディング（データを複数のシャードに分割して格納する構成）は、単一クラスターでは物理RAMが足りない場合に必要になる選択肢です^*4。公式ドキュメントの試算例では、データサイズ512GB・インデックス32GBのワークロードに対しワーキングセットが172GBとなり、必要な物理RAMは344GB規模になるとされています^*4。この規模はAWS・AzureのM300（384GB RAM)であれば単一クラスターでも収容できますが、Azure M200（256GB RAM）のように十分なRAMを持たない階層では、シャーディングが実質的に必須になります^*4。

シャーディングを導入すると、課金対象のノード数はレプリケーション係数×シャード数で計算されるため、単純な垂直スケール（階層を上げる）よりもノード数の増え方が大きくなりやすい点に注意が必要です^*1。シャード数を増やすほど水平方向の性能は伸びますが、その分だけ課金対象のノードも比例して増える構造だと理解しておく必要があります。

外注と内製、コスト最適化はどちらが向くか

MongoDB Atlasのコスト最適化を内製で継続するには、複数の専門知識が必要になります。具体的には、ワーキングセット計算に基づくクラスター階層の見直し、オートスケーリング条件の設計、バックアップポリシーとRPO要件のすり合わせ、Cost Explorerを使った定期監視の4領域です^*2。これらを兼務者だけで回そうとすると、リソース使用状況の変化を追い切れず、気づかないうちに過剰な階層やストレージが積み上がってしまうことがあります。

クラスター階層の見直しを誤ると、性能面と費用面の両方でリスクが生じます。階層を下げすぎればキャッシュミスの増加によるレイテンシ悪化とアプリケーション障害の連鎖につながりかねず、逆に階層を上げすぎれば使われない計算資源に対して継続的な支出が発生し続けます。オートスケーリングの上限を設定しないまま運用すると、一時的な負荷急増が引き金となって上位階層に張り付き、需要が落ち着いた後もコストだけが高止まりする事態も起こり得ます。

専門パートナーに依頼する場合と内製で対応する場合とでは、見直しの網羅性に差が出やすいところが実務上の違いです。内製では日々の開発業務と並行してコスト監視を行うため見直しの頻度が下がりがちですが、外部パートナーは複数クラスターの課金内訳を定点観測する体制を前提に稼働するため、階層・ストレージ・バックアップ・データ転送の各要素を横断して継続的に点検しやすくなります。自社に構築・運用の専任者を確保しにくい場合は、要件整理から運用設計までを外部の開発・運用パートナーに委託する外注という選択肢が現実的な手段になります。

まとめ：MongoDB Atlasのコスト最適化を進める3つの判断軸

本稿ではMongoDB Atlasのコスト構造と最適化の勘所を整理しました。要点を3つに集約すると次の通りです。第一に、費用はクラスター階層・ストレージ/IOPS・バックアップ・データ転送という複数要素の合算で決まるため、単一の指標だけを見て判断しないことです。第二に、オートスケーリングやクラスター一時停止は有効な手段ですが、範囲設定や運用ルールを誤ると想定外の課金や性能低下を招きます。第三に、これらを継続的に見直す体制を自社で維持するのが難しい場合は、外部パートナーへの外注が現実的な選択肢になります。

よくある質問

著者：テレリモ総研編集部　鈴木 亮佑

ご不明な点はお問い合わせフォームからもご連絡いただけます。

1. *1　出典：MongoDB「Cluster Configuration Costs」（MongoDB Atlas公式ドキュメント）
2. *2　出典：MongoDB「Billing Breakdown and Optimization」（MongoDB Atlas公式ドキュメント）
3. *3　出典：MongoDB「Now GA: MongoDB Atlas Flex Tier」（MongoDB公式アップデート情報）
4. *4　出典：MongoDB「Atlas Cluster Sizing and Tier Selection」（MongoDB Atlas公式ドキュメント）
5. *5　出典：MongoDB「Configure Auto-Scaling」（MongoDB Atlas公式ドキュメント）
6. *6　出典：MongoDB「Pause, Resume, or Terminate a Cluster」（MongoDB Atlas公式ドキュメント）

Tweet