MongoDBのスケーリング手法：シャーディングインフラの構築ガイド

前回のブログ記事では、MongoDBのスケーリングが「いつ」必要になるのかについて解説しました。今回は、MongoDBを「どのように」スケーリングするかに焦点を当てていきます。

MongoDB 3.0では、WiredTigerがデフォルトのストレージエンジンとして導入されました。これにより、MongoDBはスケーラビリティに関して2つのアプローチを提供できるようになりました。すなわち、垂直スケーリング（スケールアップ）と水平スケーリング（スケールアウト）です。それぞれのアプローチについて詳しく見ていきましょう。

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

垂直スケーリングは、CPUの数や種類、RAM容量、ディスク容量といったコンピューティングリソースを増強する手法です。WiredTigerを使用して垂直方向にスケールする場合、まずボトルネックの原因となっているリソースが何か（CPU・RAM・ディスク容量のいずれか、あるいはそれらの組み合わせか）を特定する必要があります。

WiredTigerとRAMに関する注意点

割り当てられたRAMが1GB未満の場合、WiredTigerは通常、256MBまたは利用可能なRAMの50%のいずれかをデフォルト値として使用します。そのため、より多くのRAMを割り当てた場合は、WiredTigerキャッシュのサイズを再設定する必要があります。

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

水平スケーリングは、一般的にサーバーを追加することで、ネットワーク全体にコンピューティングリソースを分散させる手法です。ノードを追加する際にデータを複数のノードへ分散するため、MongoDBでは「シャーディング」と呼ばれるデータベースアーキテクチャを採用しています。シャーディングはキーの範囲（キーレンジ）を利用してデータを分割し、複数のデータベースインスタンスに配信します。

シャーディングインフラストラクチャの構築

シャーディング構成をセットアップするために必要な物理コンポーネントは以下の通りです。

• Mongos：クエリルーターとして機能します。
• Configサーバー：シャーディングのメタデータを保持します。
• データノード：実際のデータを保持します。

物理コンポーネントの詳細については、弊社の「MongoDB Overview」をご参照ください。

シャードキーの定義方法

物理的なシャーディングインフラの構築が完了したら、次はシャーディングの論理的な側面に取り組みます。シャードキーとは、コレクション内の各フィールドのうち、MongoDBがデータ分割に使用するものを指します。幸いにも、Mongoではこれらのキーを自由に定義できます。

シャードキーを実装すべきフィールドを特定するには、以下の手順に従います。

1. シャーディング対象のコレクションを特定する。サイズが200MBを超え、かつデータを均等に分散できるコレクションは、シャーディングの有力な候補となります。
2. 適切なシャードキーを作成または設計する。シャードキーを作成する際は、以下の推奨事項と質問事項を考慮してください。

• アプリケーションがどのようにデータベースとやり取りしているかを把握する。
• アプリケーションが読み取り中心か書き込み中心か、あるいはバランス型かを検討する。
• データベースに対する最も重要な処理は何かを見極める。例えば、アプリケーションは大量のデータを書き込んでいても、最も重要な処理は「100ミリ秒以内でデータを返すクエリ」である場合があります。
• 週単位・月単位で予想されるデータ増加のパターンはどうか。
• 遅いクエリなど、改善が必要な課題や問題領域は存在するか。
• アプリケーションのアクセスが特定の時間帯・曜日・月・時期に集中するか、それとも常に一定の負荷があるか。

これらの調査を終えたら、より詳細な分析に進むことができます。次回のブログ記事では、「最適なシャードキーの見つけ方」について詳しく解説しますので、ぜひご期待ください。