企業の規模が拡大し、データの需要が急激に増えていくと、データベース技術の選択はますます重要になってきます。
最初は良さそうに見えた判断も、企業の成長とともに必ずしもうまくいかないことがあります。
MongoDBは、柔軟性と使いやすさから開発者に人気のNoSQLデータベースとして知られていますが、大規模で高性能な環境では必ずしも要求を満たせないケースがありました。
以下では、MongoDBでの課題から最終的に自社のニーズに合った別のソリューションに切り替えた企業の実例を見ていきましょう。
MongoDBのスケーラビリティに関する課題
MongoDBには、うまく対応できる面もあります。
例えば、ストレージ容量を増やしたりレプリカセット（データのコピーを保持するサーバーのグループ）を大きくしたりするための、段階的なアップグレードが可能です。
また、必要に応じてレプリカセットを小さくすることもできます。
しかし、サーバーレベルになると話が変わってきます。
垂直スケール（サーバーの性能を上げること）を推奨していますが、これにも限界があります。
その限界を超えると、MongoDBは単一のレプリカセットからシャーディング構成（データを分散して保存する仕組み）への移行が必要になります。
ただし、一度シャーディング構成にすると、レプリカセットには戻せません。これは一方通行の作業なのです。
さらに、MongoDBのレプリケーション方法にも課題があります。
レプリカセット（同じデータセットを保持するプロセス群）を使用しますが、1つのノードが「プライマリ」として動作し、他のノードは「セカンダリ」として扱われます。
これにより、再バランスが複雑になります。
また、スケールアップやダウン、またはティアの調整中にサービスが中断されることがあります。
プライマリノードの選出（レプリカセット選挙）が必要になるためです。
このような複雑さとコストの増加が、大規模データ環境での課題として浮き彫りになっています。
ユースケース1：SnapDealのパフォーマンス問題
SnapDealというeコマースプラットフォームは、データ量が増えるにつれてパフォーマンスの問題に直面していました。
最初はMongoDBで問題なかったものの、負荷がかかると応答時間が5ミリ秒から1秒以上に膨れ上がり、リアルタイムの取引処理には受け入れられないものでした。
高負荷時の低遅延を維持できないという問題により、SnapDealはより性能の高い解決策を探すことになりました。
スケーリングのコストと性能のトレードオフ
MongoDBの最も一般的な問題点の1つは、スケーリングに伴う費用の増加です。
企業が成長するにつれて、シャーディングによる性能維持のために必要なハードウェアが増え、インフラ費用が急上昇します。
さらに、MongoDBが高速なクエリのためにセカンダリインデックスをDRAM（メモリ）に保持する方式も、これらのコストを増加させる要因となっています。
ユースケース2：世界トップの証券会社が抱えたコストジレンマ
ある大手証券会社は、高い書き込み負荷時に必要な低い読み取りレイテンシーを実現できないという課題に直面していました。
必要とする性能を達成するには、サーバー数を大幅に増やす必要があり、持続不可能なコストになってしまうことがわかりました。
この会社はMongoDBの採用を検討しましたが、代わりに性能、効率性、アーキテクチャの耐久性を提供できる別のデータベースソリューションを選びました。
Aerospikeを採用することで性能が向上し、150台のRAMキャッシュサーバーから10台のクラスターに移行でき、設備投資と運用コストの両方を削減することができました。
MongoDBのシャーディングアーキテクチャの複雑さ
MongoDBのシャーディングモデルは強力ですが、シャードの数が増えるにつれて管理が難しくなる複雑さがあります。
シャーディング戦略が適切でないと、データの偏りや非効率な分散が起こり、性能の問題を悪化させ、保守を複雑にします。
ユースケース3：MarTech業界におけるインフラ簡素化
MarTech業界のある顧客データプロバイダーは、当初9TBのアプリケーションで複雑なクエリを処理するためにMongoDBを使用していました。
しかし、会社が成長するにつれて、MongoDBのシャーディングの複雑さがボトルネックになっていることがわかりました。
よりシンプルで効率的なスケーリングを提供する別のデータベースに切り替えることで、半分のハードウェアで5倍のスループットを達成し、全体的な運用効率を大幅に改善することができました。
運用のダウンタイムとサービスの中断
MongoDBでは、スケールアップやダウン、段階の調整、またはノードがオフラインになった時など、日常的な操作中にサービスが中断することがあります。
これは、これらの処理中にレプリカセット内のプライマリノードを削除してアップデートする必要があるためです。
特にリアルタイム環境では、これらの中断がビジネス運営に支障をきたす可能性があります。
ユースケース4：ZoneTapのリアルタイムIoTの課題
ZoneTapは、建設現場で従業員の位置を把握するためのセンサーデータを提供する会社です。
当初MongoDBを使用していましたが、リアルタイムのデータ処理に必要なサービスの中断という問題に直面しました。
会社は数千台の安全装置へのスケーリングを計画していましたが、わずか24台の段階で早くもボトルネックに遭遇しました。
予測できないダウンタイムにより、ZoneTapは可用性が高く、より安定した稼働時間を提供するデータベースシステムに切り替え、重要なサービスの中断を防ぐことができました。
コスト効率の達成：AdTech業界の転換
AdTech（広告技術）業界の企業にとって、MongoDBの増加するコストは特に負担となりえます。
この業界で必要なデータ量はペタバイト規模に達することがあり、10ミリ秒以下の間に数十回のデータ取得が必要となる場合があります。
サーバー数の多さと高価なクラウドインスタンスにより、特にデータサイズが大きくなるにつれて、MongoDBは高コストな選択肢となります。
ユースケース5：AdTechのコスト削減
あるAdTech企業は、パートナーのXenossを通じてMongoDBから移行することで、サーバー数を150台から10台に削減し、データベースの年間コストを250万ドルから14.4万ドルに削減することができました。
別のAdTech企業は、スループットを40%以上増加させながら、月額料金を3万ドルから5千ドルに削減することができました。
MongoDBの限界から学ぶ教訓
これらの企業の経験は、データベースの選択肢を評価するすべての企業にとって重要な教訓となります。
MongoDBは多くの利点を提供しますが、スケーリング、コスト、運用の複雑さに関する制限により、高性能で大規模な環境には適さない場合があります。
データの成長を予測し、一貫した低遅延、高可用性、予測可能なコストを必要とする企業は、これらの要求により適したデータベースを検討すべきでしょう。
長期的なデータニーズを評価し、データベース技術のトレードオフを理解することで、ビジネス目標に沿い、事業の成長に伴うスケーラビリティとパフォーマンスを確保できる、より適切な判断を下すことができます。
その他の事例はこちらからもご覧いただけます。
本ブログは2024年11月7日「5 real-world examples of MongoDB issues」の翻訳です。
