クラスターの展開は、データの高可用性を確保し、データを保護する上で非常に重要です。 MongoDBは、レプリケーションとシャーディングによってこれを強化します。これにより、レプリケーションは冗長性を持ち上げることで垂直方向のスケーリングを保証し、シャーディングは水平方向のスケーリングを膨らませます。
一般に、どちらのアプローチも、メンバー間でワークロードを分散しようとするため、単一のノードが受ける可能性のあるワークロードを削減します。データベースのパフォーマンスは、スループット操作でユーザーにサービスを提供する際に高速であると見なすことができます。ただし、プライムクラスターアーキテクチャがないと、シャーディングとレプリケーションを試しても、同じレベルの結果が表示されない場合があります。
レプリカセットのメンバーが偶数の場合、既存のプライマリが失敗した場合、メンバーが投票して新しいプライマリを選択することは困難になります。このブログでは、使用できる標準のデプロイメントアーキテクチャについて説明しますが、これはアプリケーションの要件によって異なる場合があります。
MongoDBデプロイメント戦略
レプリカセットのアーキテクチャは、MongoDBの容量と機能を大きく左右します。
3ノードのレプリカセットは、データの冗長性とフォールトトレランスを提供するため、あらゆる実稼働環境でのMongoDBの標準的なクラスター展開です。冗長性は、特に災害発生後のデータベースの復旧において重要です。 3ノードのレプリカセットが基本的な展開アーキテクチャである場合がありますが、これはアプリケーションの仕様と要件によって異なる場合があります。ただし、構成上の大きな問題が発生する可能性があるため、複雑にしすぎないでください。
MongoDBシャーディング戦略
シャーディングは、処理する必要のあるドキュメントの数を減らすことにより、特定のクエリに対してデータベースが処理するワークロードを削減します。したがって、水平方向のスケーリングが向上し、データベースを単一サーバーのハードウェア制限を超えて拡張できるようになります。ワークロードの需要に応じて、ノードをクラスターに追加したり、クラスターから削除したりできます。MongoDBは、操作の介入なしに最適な方法でデータのバランスを取り直します。
シャーディングの背後にある理由は、データベースを水平方向にスケーリングし、単一のインスタンスが実行できるスループット操作の数を減らすためです。シャードキーを均一に分散しないと、シャードの数が少なくなる可能性があります。シャードが少ないと、単一のシャードの容量によって操作が制限される可能性があるため、読み取りおよび書き込み操作が遅くなります。
チャンクは事前に分割し、最初に分散する必要があります
シャードには、いくつかのシャードキー基準に従ってグループ化されたデータチャンクがあります。新しいシャードコレクションを作成するときは、データをロードする前に、空のチャンクを作成して、すべてのシャードに均等に分散する必要があります。 MongoDBにデータを取り込む場合、関連するシャード間で負荷を簡単に分散できます。ハッシュベースのシャーディングを使用している場合は、numInitialChunksオプションを使用してこれらを自動的に実行できます。ただし、整数値はシャードあたり8192未満である必要があります。
シャーディングの重要性を達成するための最小数として、2つのシャードが必要になることがよくあります。単一のシャードは、将来シャーディングを有効にするための基盤をレイアウトし、展開時に必要がない場合にのみ役立ちます。
範囲ベースのシャーディングは、より多くのシャードを提供するため、有益です。したがって、操作は、必要な最小のシャード、より多くの場合は単一のシャードにルーティングできます。実際には、関連するデータとクエリパターンを十分に理解していない限り、これは難しい場合があります。ハッシュシャーディングは、劣った範囲ベースの操作を提供することを犠牲にして、スループット操作の均一な分散を改善します。
シャードキーに基づいてルーティングできないクエリは、評価のためにすべてのシャードにブロードキャストする必要があります。また、リクエストごとに複数のシャードが含まれるため、シャードが追加されてオーバーヘッドが発生するため、線形にスケーリングされません。これにより、データベースのパフォーマンスが低下します。この操作はスキャッターギャザーと呼ばれ、クエリにシャードキーを含める場合にのみ回避できます。
このアプローチは、各クエリをすべてのシャードで並行して実行できる大規模な集計クエリを処理する場合にのみ役立ちます。
MongoDBレプリケーション戦略
レプリケーションにより、MongoDBの垂直スケーリングが強化され、関係するメンバー間でワークロードが分散されます。本番環境では、これらは最適なクラスターアーキテクチャーのために考慮すべきいくつかの考慮事項です。
レプリカセットが持つことができるノードの最大数は50で、投票メンバーは7人です。 7日以降のメンバーは投票権がないと見なされます。したがって、優れたクラスターには、選挙プロセスを便利にするために7人の投票メンバーが必要です。
奇数の投票メンバーを配置します。メンバーの数が7未満で偶数の場合は、別の投票メンバーとしてアービターを配置する必要があります。アービターはデータのコピーを保存しないため、管理に必要なリソースが少なくなります。その上、他のメンバーに服従させることができなかった環境に彼らを服従させることができます。
停電やネットワークの一時的な切断、切断などの要因により、一部のメンバーが利用できなくなる場合があります。セットに残り、プライマリを選出できるメンバーの数は、フォールトトレランスと呼ばれる状況を生み出します。したがって、これは、レプリカセットメンバーの総数と、プライマリを選出するために必要な投票メンバーの過半数との差です。プライマリがない場合は、書き込み操作を実行できません。
次の表は、3つの間の関係の例を示しています。
| | | |
| 3 | 2 | 1 |
| 4 | 3 | 1 |
| 5 | 3 | 2 |
| 6 | 4 | 2 |
| 7 | 5 | 2 |
セットにメンバーを追加すると、表からわかるようにフォールトトレランスが増加することはないという点で、この関係はそれほど直接的ではありません。追加のメンバーは、バックアップやレポートなどの専用機能をサポートします。
現在の需要が既存のセットの容量を飽和させる前に、新しいメンバーを追加して、展開用の予備の容量を用意する必要があります。
読み取りトラフィックが非常に多い場合は、スループット読み取りをセカンダリメンバーに分散し、クラスターが大きくなるたびに、メンバーを代替データセンターに追加または移動して、冗長性を実現し、データの可用性を高めます。
タグセットでターゲット操作を使用して、読み取り操作を特定のメンバーにターゲットにしたり、書き込みの懸念を変更して特定のメンバーからの確認応答を要求したりすることもできます。
データセンターも、何らかの大惨事のために失敗する可能性があります。したがって、データ保護の目的で、少なくとも1つまたは2つのメンバーを別のデータセンターに保管することをお勧めします。可能であれば、奇数のデータセンターを使用し、データセンターが失われた場合でも、残りのレプリカセットメンバーが過半数を形成するか、少なくともデータのコピーを提供できる可能性を最大化する分布を選択します。
デフォルトでは、これはMongoDBで有効になっています。突然の再起動や電源障害などのサービスの中断が発生した場合にデータが失われるのを防ぐために、このオプションが有効になっていることを確認する必要があります。
主に、次の2つの展開アプローチがあります。
- 停電などの施設固有の障害から保護するために、2つ以上のデータセンターに分散されたレプリカセット。
ただし、パターンはアプリケーションの要件によって異なりますが、可能であれば、デプロイメントアーキテクチャでこれら2つの機能を組み合わせることができます。
レプリカセットメンバーまたはシャードクラスターメンバーを構成するときは、IPアドレスではなく論理DNSホスト名を使用してください。これは、IPアドレスの変更の結果として行う必要のある構成の変更に伴う苦痛を回避するためです。
レプリカセットの命名の場合、一部のドライバーはレプリカセットの接続をレプリカセット名でグループ化するため、セットには個別の名前を使用します。
レプリカセットのアーキテクチャレイアウトによって、展開の容量と機能が決まります。データ保護とシステムパフォーマンスは、アーキテクチャを設定する際の主要な考慮事項です。フォールトトレランス、レプリカセットメンバーの数、最適なシャーディングキー、高可用性とデータ保護のための展開パターンなどの重要な要素を考慮する必要があります。レプリカセットノードの地理的分布は、冗長性を確保し、データセンターの1つが存在しない場合にフォールトトレランスを提供することで、これらの要因の多くに対処できます。