翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
Amazon DocumentDB の高可用性とレプリケーション
レプリカインスタンスを使用すると、Amazon DocumentDB で高可用性と読み取りスケールインを実現できます。1 つの Amazon DocumentDB クラスターは、1 つのプライマリインスタンスと 15 までのレプリカインスタンスをサポートします。これらのインスタンスは、クラスターのリージョン内のアベイラビリティーゾーンに分散することができます。プライマリインスタンスでは、読み込みと書き込みトラフィックを受け入れ、レプリカインスタンスは読み込みリクエストのみを受け入れます。
クラスターボリュームはクラスターのデータの複数のコピーで構成されます。ただし、クラスターボリューム内のデータは、プライマリインスタンスおよびクラスター内の Amazon DocumentDB レプリカに対する単一の論理ボリュームとして表されます。レプリカインスタンスには、結果整合性があります。これによって、最短のレプリカラグでクエリ結果を返します。通常の場合、プライマリインスタンスが更新を書き込みしてから 100 ミリ秒未満になります。レプリカラグは、データベースの変更レートによって異なります。つまり、データベースに対して大量の書き込みオペレーションが発生している間、レプリカラグが増加することがあります。
読み取りのスケーリング
Amazon DocumentDB プリカは、クラスターボリュームでの読み取りオペレーションに特化しているため、読み取りのスケーリングに最適です。書き込みオペレーションはプライマリインスタンスによって管理されます。クラスターボリュームは、クラスター内のすべてのインスタンス間で共有されます。したがって、各 Amazon DocumentDB レプリカごとにデータのコピーを複製して維持する必要はありません。
高可用性
Amazon DocumentDB クラスターを作成するときは、サブネットグループ内のアベイラビリティーゾーン の数に応じて (少なくとも 2 つ存在する必要があります)、Amazon DocumentDB は、アベイラビリティゾーン間でインスタンスをプロビジョニングします。クラスター内でインスタンスを作成する場合、Amazon DocumentDB はサブネットグループ内のアベイラビリティゾーン間でインスタンスを自動的に配信して、クラスターのバランスを取ります。また、このアクションは、すべてのインスタンスが同じアベイラビリティーゾーンに配置されることを回避します。
例
ポイントを説明するために、、、 AZ1 AZ2の 3 つのアベイラビリティーゾーンを持つサブネットグループを持つクラスターを作成する例を考えてみましょうAZ3。
クラスター内の最初のインスタンスが作成されると、それがプライマリインスタンスとなり、いずれかのアベイラビリティゾーンに配置されます。この例では、 にありますAZ1。作成される 2 番目のインスタンスはレプリカインスタンスで、他の 2 つのアベイラビリティーゾーンの 1 つにあります。例: AZ2。作成された 3 番目のインスタンスはレプリカインスタンスで、残りのアベイラビリティーゾーン にありますAZ3。さらにインスタンスを作成する場合、クラスター内でバランスが取れるようにアベイラビリティゾーン間で分散します。
プライマリインスタンス (AZ1) で障害が発生した場合、フェイルオーバーがトリガーされ、既存のレプリカの 1 つがプライマリに昇格されます。古いプライマリが復旧すると、プロビジョニングされたのと同じアベイラビリティーゾーン () のレプリカになりますAZ1。3 つのインスタンスクラスターをプロビジョニングすると、Amazon DocumentDB はその 3 つのインスタンスクラスターを引き続き保持します。Amazon DocumentDB は、手動による介入なしに、インスタンス障害の検出、フェイルオーバー、および回復を自動的に処理します。
Amazon DocumentDB がフェイルオーバーを実行してインスタンスを復旧すると、復旧したインスタンスはプロビジョニングされていたアベイラビリティーゾーンに残ります。ただし、インスタンスのロールはプライマリからレプリカに変更される場合があります。これを実行することで、一連のフェイルオーバーによってすべてのインスタンスが結果として同じアベイラビリティゾーンになるというシナリオを回避することができます。
フェイルオーバーターゲットとして Amazon DocumentDB レプリカを指定できます。つまり、プライマリインスタンスが失敗した場合、指定された Amazon DocumentDB プリカまたは層からのレプリカがプライマリインスタンスに昇格します。短い中断があり、その間はプライマリインスタンスに対して行われた読み取りおよび書き込みリクエストは、例外により失敗します。Amazon DocumentDB クラスターに Amazon DocumentDB レプリカが含まれていない場合は、プライマリインスタンスに障害が発生すると再作成されます。Amazon DocumentDB レプリカを昇格するほうが、プライマリインスタンスの再作成よりも大幅に短時間で行えます。
高可用性のシナリオでは、1 つ以上の Amazon DocumentDB レプリカを作成することをお勧めします。これらのレプリカは、プライマリインスタンスと同じインスタンスクラスとし、Amazon DocumentDB クラスターの異なるアベイラビリティーゾーンに配置します。
詳細については、次を参照してください。
グローバルクラスターでの高可用性
複数の で高可用性を実現するために AWS リージョン、Amazon DocumentDB グローバルクラスター を設定できます。各グローバルクラスターは複数のリージョンにまたがり、低レイテンシーのグローバル読み取りと、 全体の停止からのディザスタリカバリを可能にします AWS リージョン。Amazon DocumentDB は、プライマリリージョンから各セカンダリリージョンへのすべてのデータと更新の複製を自動的に処理します。
レプリカの追加
クラスターに追加される最初のインスタンスは、プライマリインスタンスです。最初のインスタンスの後に追加されるすべてのインスタンスはレプリカインスタンスです。クラスターは、プライマリに加えて 15 個までのレプリカインスタンスを持つことができます。
を使用してクラスターを作成すると AWS Management Console、プライマリインスタンスが自動的に同時に作成されます。クラスターとプライマリインスタンスを作成すると同時にレプリカを作成するには、[別のゾーンにレプリカを作成します] を選択します。詳細については、「Amazon DocumentDB クラスターの作成」のステップ 4.d を参照してください。Amazon DocumentDB クラスターにさらにレプリカを追加するには、クラスターへの Amazon DocumentDB インスタンスの追加 を参照してください。
を使用してクラスター AWS CLI を作成する場合は、プライマリインスタンスとレプリカインスタンスを明示的に作成する必要があります。詳細については、以下のトピックの「Using the AWS CLI"」セクションを参照してください。
レプリケーションの遅延
レプリケーションラグは通常 50 ms 以下です。レプリカのラグが上がる最も一般的な理由は次のとおりです。
-
リードレプリカがプライマリより遅くなる原因として、プライマリの書き込みレートが高いです。
-
長時間実行されるクエリ (大規模なシーケンシャルスキャン、集約クエリなど) と着信書き込みレプリケーションの間のリードレプリカの競合。
-
リードレプリカの同時クエリが非常に多いです。
レプリケーションの遅延を最小限に抑えるには、次のトラブルシューティング方法を試してください。
-
書き込みレートが高いか、CPU使用率が高い場合は、クラスター内のインスタンスをスケールアップすることをお勧めします。
-
リードレプリカで長時間実行されるクエリがあり、クエリ対象のドキュメントが非常に頻繁に更新される場合は、リードレプリカでの競合を回避するために、長時間実行されるクエリを変更するか、プライマリ/書き込みレプリカに対して実行することを検討してください。
-
リードレプリカでのみ非常に多くの同時クエリがある場合やCPU使用率が高い場合は、別のオプションとして、リードレプリカの数をスケールアウトしてワークロードを分散します。
-
レプリケーションラグは書き込みスループットが高く、クエリの実行時間が長いため、CW メトリクスをスロークエリロガーおよび DBClusterReplicaLagMaximum
WriteThroughput
/WriteIOPS
メトリクスと組み合わせて使用して、レプリケーションラグをトラブルシューティングすることをお勧めします。
一般に、クラスターのフェイルオーバーによってパフォーマンスが低下しないように、すべてのレプリカが同じインスタンスタイプであることを推奨します。
スケールアップとスケールアウト (例:6 つの小さいインスタンスと 3 つの大きなインスタンス) を選択する場合は、DB インスタンスごとに大きなバッファーキャッシュが得られるため、スケールアウト前に最初に (より大きなインスタンス) にスケールアップすることをお勧めします。
プロアクティブに、レプリケーション・ラグ・アラームを設定し、アプリケーションの機能に影響を及ぼす前に、しきい値をレプリカ・インスタンス上のデータがどの程度遅れる (または「古い」) 上限であると感じる値に設定する必要があります。一般に、一時的なワークロードが原因で、アラームが発生する前に、複数のデータポイントについてレプリケーションラグのしきい値を超えることをお勧めします。
注記
さらに、10 秒を超えるレプリケーションラグに対して別のアラームを設定することをお勧めします。複数のデータポイントでこのしきい値を超える場合は、インスタンスをスケールアップするか、プライマリインスタンスの書き込みスループットを削減することをお勧めします。