MongoDBで大規模にスケールする方法：垂直・水平スケーリングの違いと実践ガイド

本記事は、2018年6月4日にObjectRocket.com/blogで公開された記事をもとに翻訳・再編集したものです。

「スケーリング」と聞くと、魚のウロコを取り除く作業を思い浮かべる人もいるかもしれません。しかし、データベースの世界におけるスケーリングとは、ストレージ、ディスク、RAM、CPU、計算リソース、ネットワークといった各種リソースへの追加需要に対応できるよう、システムを拡張する能力を指します。

スケーリングが必要なタイミングはどう見極める？

近年はデータ量が急速に増加し、アプリケーションが短期間で一気に普及するケースも珍しくありません。アプリがバズって利用者が急増すると、初期の環境ではすぐにキャパシティ不足に陥ります。物理的なデータ保存需要の高まりやパフォーマンス低下への対応として、より多くのリソース（CPU、RAM、ネットワーク、あるいはそれらの組み合わせ）が必要になるのです。成長を見越して事前に対策するか、パフォーマンス低下の兆候が見え始めた段階で対応するか、いずれかのアプローチを選択できます。

プロアクティブ（事前）なスケーリング

あらかじめ拡張を計画しておく場合、一般的には次のようなパターンが考えられます。

• 大規模なマーケティング施策が控えており、顧客数やデータ量が大幅に増加することが予想される
• クリスマス商戦や新年の目標設定のようにビジネスに季節性・周期性があり、アクティビティの増加に伴って大量のデータを取得・保持することになる

リアクティブ（事後）なスケーリング

ボトルネックに直面しており、今後も成長が続くと予想されるなら、スケーリングを検討すべきタイミングです。注意すべき警告サインには、以下のようなものがあります。

• エンドユーザーのクエリ応答時間の増加
• ログイン時間の長期化
• リクエストやサーバーのフリーズ
• 開発者からのデータベースに関する不満
• サーバー応答時間の遅延
• ホストへの負荷増大
• メモリ不足（Out-of-memory）エラー
• 意図しない election（プライマリ再選出）の発生
• ログへのエラー出力

こうしたサインが見え始めたら、需要の増加に追いつき、顧客を失わないためにスケーリングを開始しましょう。

スケーリングのアプローチには、垂直方向（スケールアップ）と水平方向（スケールアウト）の2つがあります。

垂直スケーリング（スケールアップ）

これはいわゆる「ビッグアイアン」方式です。CPUコア数やクロック速度が高く、大容量RAMとストレージを備えた1台の大型マシンにリソースを集中させます。垂直スケーリングの主なメリットは、アーキテクチャの複雑さが抑えられ、管理対象ホストが少なくて済む点です。保守担当を確保できない環境では特に有効でしょう。

現在、垂直スケーリングを実現する手段は多彩です。高性能な汎用ハードウェア、低価格化したディスクやストレージ、優れたストレージオプション、安価になったメモリ、改良されたソフトウェア、そしてフェイルオーバーや障害をより滑らかに処理できるネットワークなどが挙げられます。

多くのアプリケーションにとってスケールアップは理想的な選択肢であり、後述するレプリカセットの活用をおすすめします。ただし、大型のレプリカセットを運用する際は、垂直スケーリング特有の隠れたコストにも注意が必要です。環境が急成長を続ける場合、より大型のマシンへの移行や追加リソースの調達を繰り返すことになり、やがて限界に達します。さらに、単一の大型ホストでのアップグレード作業は、水平スケーリング環境に比べて非効率になりがちな点も考慮すべきです。成長が続く限り、「スケールアップを続けるべきか、スケールアウトへ切り替えるべきか」を継続的に判断していくことになります。

水平スケーリング（スケールアウト）

シャーディングは水平スケーリングに相当します。シャーディングではデータを複数ノードに分散格納し、負荷と処理を各ホストに分散させます。レプリケーションはプライマリ・セカンダリモデルで処理され、必要に応じてノードを追加できます。

ロードバランサーがデータのチャンクを各ノードのディスクに振り分けます。読み書き操作を複数マシンのグループに分散させることで、1台へのアクセス集中を避け、読み書き両方の処理能力を向上させます。幸い、近年のリリースではバランサー機能が大きく改善されています。水平スケーリングはMongoDB®の組み込みシャーディング機能を活かせるうえ、低価格な汎用ハードウェアを利用できる点も大きなメリットです。

水平スケーリングでは、物理または仮想のホストを追加してリソースを増強します。

• 物理：低価格な汎用ハードウェアを大量に追加
• 仮想：VMやクラウドでCPUコアやノードを追加
• ネットワーク：ロードバランサーや追加のmongoS®プロセスなどを導入

改良されたロードバランシング技術（ハードウェア・ソフトウェア双方）を活用すれば、トラフィックを必要な場所へ適切に振り分けられます。

MongoDBでレプリカセットを使ってスケーリングを実装するには？

MongoDBは、1台のプライマリと2台のセカンダリからなる大型レプリカセットを構成することで、水平方向にスケールアウトできます。各ノードはハートビート通信によって稼働状態（up/down）を監視し、セカンダリ側ではオペレーションロジックを通じてレプリケーションが行われます。

水平スケーリング：レプリカセットか、シャーディングか？

シャーディングのトレードオフは、システム全体の複雑さが増すことです。しかし一方で、メンテナンスを簡素化できるという利点もあります。ローリングアップグレードが可能になり、インデックス構築などの特定の操作をシャードやノード全体で並列に同時実行できるのです。以下に、大型レプリカセットとシャーディングクラスタの比較をまとめます。

ObjectRocketのマネージドMongoDBを選ぶ理由

Rackspace ObjectRocketが提供するのは専門性です。私たちは創業当初から大規模MongoDBの運用管理に携わり、大型レプリカセットのサポートを提供するとともに、大型シャーディングMongoDBクラスタをサポートした最初期のプロバイダの一つです。当社のエンジニアとDBAは豊富な経験を持ち、他のプロバイダではまず耳にしないような非常に複雑な課題を数多く克服してきました。

マーケティングテクノロジー分野の主要顧客（モバイルアナリティクス、メディア、メールキャンペーン、モバイル広告の不正検知、デジタルメディアなど）は、他では誰も見たことがなく対処法も不明なバグに頻繁に遭遇します。多様な顧客からの数十億件のメッセージやドキュメント、大小数千におよぶキャンペーン――そのすべてを当社プラットフォームが支えています。

当社が提供するサービスには、以下が含まれます。

• インフラストラクチャ
• ストレージ
• IOPS
• ネットワーク
• 24時間365日、迅速かつ的確に対応する最高峰のハンズオンサポート

私たちの目標は、堅牢な構成を備えたクラウドソリューションの提供です。セカンダリ向けに仮想ボリューム上へプロビジョニングされた性能の低いホストにプライマリがフェイルオーバーした際に発生しうるパフォーマンス問題を回避するため、そのような構成は採用していません。

スケーリングの解説は以上です。MongoDBインスタンスのスケールタイミングの見極め方、シャーディングのコツ、最適なシャードキーの選び方などについても、ぜひ学んでみてください。