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