注意
この機能は、M0
無料クラスターおよびフレックス クラスターでは使用できません。利用できない機能について詳しくは、「Atlas M0(無料クラスター)の制限」を参照してください。
Atlas クラスターは、クラスター内のさまざまなノードタイプに対して事前定義されたレプリカセット タグを使用して構成されます。 これらの事前定義されたレプリカセット タグを利用して、特定のアプリケーションからのクエリを特定のノード タイプ、リージョン、アベイラビリティーゾーンに転送します。 これらの事前定義されたレプリカセット タグを使用すると、レプリカセットの読み込み設定( read preference )をカスタマイズでき、クラスターのパフォーマンスと信頼性を向上させることができます。
注意
これらの事前定義されたレプリカセットのタグは、提供および管理するリソース タグとは異なります。 Atlas が提供するこれらのレプリカセット タグは変更できません。
接続文字列に定義済みのレプリカセットのタグを使用し、特定のノードにクエリを送信するには、次の接続文字列オプションを使用します。
readPreference
readPreferenceTags
readConcernLevel
例については、「ユースケースと例 」を参照してください。
定義済みレプリカセット タグの説明
次の表では、Atlas が提供する定義済みのレプリカセット タグについて説明します。
定義済みタグ名 | 説明 | 例 |
---|---|---|
アベイラビリティーゾーン | Amazon Web ServicesアベイラビリティーゾーンID 、 Google Cloud Platformゾーンの完全修飾名、またはAzureゾーン番号。 Azureでは、リージョンのサブセットのみのアベイラビリティーゾーンをサポートしています。 Atlas は、アベイラビリティーゾーンをサポートするリージョンに対してのみ、 Azure用の事前定義されたアベイラビリティーゾーン タグを提供します。 詳しくは、「 Microsoft Azure 」を参照してください。 各クラウドプロバイダーで利用可能な |
|
ノード タイプ |
| |
プロバイダー | ノードがプロビジョニングされるクラウドプロバイダー。 可能な値は次のとおりです。
|
|
リージョン | ノードが存在するクラウド リージョン。 可能な |
|
ワークロード タイプ | 非分析ノード(選択可能または読み取り専用)ノード間でワークロードを均等に分散するための事前定義されたレプリカセット タグ。 可能な値は次のとおりです。
|
|
ディスクの状態 |
|
ディスクの状態
次の表では、事前定義されたレプリカセット タグで使用可能なdiskState
値について説明しています。
ディスクの状態 | 説明 |
---|---|
| ウォーム ノードのみをターゲットにします。 レイテンシが増加したり予想外になったりすることなく クエリを実行できます。 |
このレプリカセット タグの例については、「セカンダリ ディスク ウォーミングの影響を軽減する 」を参照してください。
ノード タイプ
次の表では、事前定義されたレプリカセット タグで使用可能なnodeType
値について説明しています。
ノード タイプ | 説明 |
---|---|
| プライマリに選出される資格のあるノードから読み取ります。 |
| 読み取り専用 ノードから読み取ります。 |
| 読み取り専用の分析ノードから読み取ります。 |
クラスターの選択可能ノード、読み取り専用ノード、分析ノードを構成する方法については、「高可用性とワークロード分離の構成 」を参照してください。
Tip
これらの事前定義されたレプリカセット タグが BI Connector for Atlas の読み込み設定(read preference)にどのように対応しているかについて詳しくは、 クラスターの作成 ページのBI Connectorクラスター オプション のセクションを参照してください。
ユースケースと例え
事前定義されたレプリカセット タグを利用することが役立つ次のシナリオを検討して、対応するサンプル接続文字列を参照してください。
重要
分析ノードクエリの高可用性
readPreferenceTags=nodeType:ANALYTICS
のようなタグが付いた分析ノードをターゲットとする読み取りでは、ノードの可用性が変動する際の回復力が重要です。フォールバックタグがないと、クエリが次の場合に失敗する可能性があります。
データ圧縮中の最初の同期
ディスクのスケールダウンイベント
あらゆる NVMe クラスター階層の変更
これらのリスクを軽減するには、接続文字列に複数の読み込み設定タグを含めてフォールバックオプションを提供することを確認します。これにより、Atlas はそのようなイベントが発生した際に分析読み取りを利用可能なノードにルーティングできます。以下に例を挙げます。
db+srv://<db_username>:<db_password>@foo-q8x1v.mycluster.com/test?readPreference=secondary&readPreferenceTags=nodeType:ANALYTICS,priority:1&readPreferenceTags=&readConcernLevel=local
この例では、次のことが行われます。
アプリケーションは最初に
nodeType:ANALYTICS
タグが付けられたノードに接続を試みます。そのようなノードが利用できない場合、最後の空の
readPreferenceTags=
により、アプリケーションは利用可能な任意のセカンダリノードに接続することができます。
注意
次の各サンプル接続文字列では、readConcernLevel=local
接続文字列オプションが使用されています。 ローカルの読み取り保証 (read concern) を指定すると、シャーディングされたクラスターでのセカンダリ読み取りによって孤立したドキュメントが返されなくなります。 シャーディングされていないレプリカセットに接続する場合は、このオプションを指定する必要はありません。
分析ノードを使用したワークロードの分離
アプリケーションがETLやレポートなどの複雑な操作や長時間実行される操作を実行する場合は、 分析ノード のみに接続して、アプリケーションのクエリを運用ワークロードの残りの部分から分離することをお勧めします。
次の接続文字列について考えてみます。
mongodb+srv://<db_username>:<db_password>@foo-q8x1v.mycluster.com/test?readPreference=secondary&readPreferenceTags=nodeType:ANALYTICS&readConcernLevel=local
接続文字列オプションは、次の順序で表示されます。
readPreference=secondary
readPreferenceTags=nodeType:ANALYTICS
readConcernLevel=local
secondary
のreadPreferenceオプションと{ nodeType : ANALYTICS }
のreadPreferenceTagオプションは、分析ノードへのアプリケーション接続を制限します。
分析ノードから通常のアプリケーションのセカンダリ読み取りを分離
分析ノードのワークロードから通常のアプリケーション読み取りを分離することをお勧めします。
次の接続文字列について考えてみます。
mongodb+srv://<db_username>:<db_password>@foo-q8x1v.mycluster.com/test?readPreference=secondary&readPreferenceTags=workloadType:OPERATIONAL&readConcernLevel=local
接続文字列オプションは、次の順序で表示されます。
readPreference=secondary
readPreferenceTags=workloadType:OPERATIONAL
readConcernLevel=local
指定されたオプションにより、アプリケーションは 分析ノード からの読み取りを防止できます。 アプリケーションはoperational
または非分析ノードから読み取る必要があります。
地理的に分散されたアプリケーションのローカル読み取りのターゲット化
事前定義されたレプリカセットタグを使用して、グローバルに分散されたアプリケーションの特定のリージョンでのローカル読み取りの対象とします。 これらの事前定義されたレプリカセットがグローバルに導入される前は、分散アプリケーションのローカル読み取りは、最も近い読み込み設定(read preference)を正しく計算することを前提としていました。 事前定義されたレプリカセット タグでは、読み込み設定(read preference)モードがnearest
と組み合わせて適切な地理的タグを指定すると、より一貫した動作が得られます。
次の接続文字列は、 Amazon Web Services US_EAST_1
リージョンへの接続を優先し、次に US_EAST_2
リージョンへの接続を優先します。
mongodb+srv://<db_username>:<db_password>@foo-q8x1v.mycluster.com/test?readPreference=nearest&readPreferenceTags=provider:AWS,region:US_EAST_1&readPreferenceTags=provider:AWS,region:US_EAST_2&readPreferenceTags=&readConcernLevel=local
接続文字列オプションは、次の順序で表示されます。
readPreference=nearest
readPreferenceTags=provider:AWS,region:US_EAST_1
readPreferenceTags=provider:AWS,region:US_EAST_2
readPreferenceTags=
readConcernLevel=local
Atlas は、指定された順序で各読み込み設定(read preference)タグを考慮します。 Atlas がノードをタグに照合すると、そのタグに一致する適格なノードがすべて検索されます。 Atlas は次のreadPreferenceTags
を無視します。
この例では、アプリケーションは最初にAmazon Web Servicesリージョン US_EAST_1
のノードに接続しようとします。 そのリージョンで使用できないノードが利用できない場合、アプリケーションはAmazon Web Servicesリージョン US_EAST_2
のノードに接続しようとします。
最後の(空) readPreferenceTags=
はフォールバック オプションを提供します。 空のreadPreferenceTags=
オプションを使用すると、アプリケーションはプロバイダーやリージョンに関係なく、利用可能な任意のノードに接続できます。
これらのオプションは、アプリケーションが最も近い地理的リージョンに接続するようにし、レイテンシを削減し、パフォーマンスを向上させるのに役立ちます。
注意
アベイラビリティーゾーンに基づいて、読み取りをさらにターゲットにすることもできます。
Tip
さまざまな読み込み設定 (read preference) に関する追加情報とユースケースについては、MongoDB マニュアルの 読み込み設定 (read preference) ページを参照してください。
セカンダリ ディスク ウォーミングの影響軽減
Atlas では、クラスター内のノードを追加または交換する際に、デフォルトでディスクの事前ウォーミングが実行されます。ディスク事前ウォーミング プロセス中、新しく作成されたストレージボリュームは一定期間、IOPS を使用します。これにより、このノードに対して行われた読み取り操作が遅くなります。そのため、ディスク事前ウォーミング プロセス中、Atlas は事前ウォーミングノードをデフォルトで 非表示 に維持し、読み取り操作に参加することを防ぎます。
新しく追加または交換されたノードをすぐにアクティブにして表示したい場合は、次の例のように 接続 を使用して、 高速ディスク事前ウォーミングを無効 にし、ウォーミングstring ノードでの読み取り操作を防ぐことを選択できます。
mongodb+srv://<db_username>:<db_password>@foo-q8x1v.mycluster.com/test?readPreference=secondary&readPreferenceTags=diskState:READY&readConcernLevel=local
接続文字列オプションは、次の順序で表示されます。
readPreference=secondary
readPreferenceTags=diskState:READY
readConcernLevel=local
secondary
のreadPreferenceオプションと{ diskState : READY }
のreadPreferenceTagオプションは、Atlas にウォーム ノードのみをターゲットにするように指示します。
アベイラビリティーゾーンの取得
Atlas は、アベイラビリティーゾーン用の事前定義されたレプリカセット タグをデフォルトで提供します。 これらのタグには、 Amazon Web ServicesアベイラビリティーゾーンID 、ゾーンのGoogle Cloud Platformの完全修飾名、またはAzureゾーン番号が含まれます。 ノードのアベイラビリティーゾーンは、 rs.conf()
shell メソッドを使用するか、クラスター ノードの最後の ping を表示して確認できます。
例
... "tags": { "availabilityZone": "use2-az2", ...
組み込みのカスタム書込み保証 (write concern)
Atlas は、マルチリージョン クラスター向けの組み込みのカスタム書込み機能を提供します。 書込み保証 (write concern) は、クラスターへの書込み (write) 操作に対して MongoDB から要求される確認応答のレベルを記述します。
Atlas に組み込まれているカスタム書込み保証 (write concern) は、成功するリージョンの数に操作を伝播するようにすることで、データの一貫性を向上させるのに役立ちます。
カスタム書込み保証 (write concern) を使用するには、操作の 書込み保証 ( write concern) ドキュメントで書込み保証 (write concern) を指定します。
Atlas は、マルチリージョン クラスターに対して次のカスタム書込み保証 (write concern) を提供します。
書込み保証 (write concern) | tags | 説明 |
---|---|---|
|
| 書込み (write) 操作は、クラスター内の少なくとも 2 つのリージョンによって確認済みである必要があります。 |
|
| 書込み (write) 操作は、クラスター内の少なくとも 3 つのリージョンによって確認済みである必要があります。 |
|
| 書込み (write) 操作は、異なるクラウドプロバイダーを持つクラスター内の少なくとも 2 つのリージョンによって確認される必要があります。 |
例
us-east-1 、 us-east-2 、 us-west-1 の3 つのリージョンにまたがるマルチリージョンクラスターを検討します。 Atlas が書込み (write) 操作を受け入れる前に、クラスター内の 3 つのリージョンすべてに書込み (write) 操作を伝播したい。
次の操作では、ドキュメントを挿入し、 { w: "threeRegions" }
書込み保証(write concern)オブジェクトによって操作が 3 つのすべてのリージョンに伝播される必要があります。
db.employees.insertOne( { name: "Bob Smith", company: "MongoDB" }, { writeConcern: { w: "threeRegions" } } )