翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。 # 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 クラスターの異なるアベイラビリティーゾーンに配置します。 詳細については次を参照してください: + [Amazon DocumentDB クラスターの耐障害性について理解する](db-cluster-fault-tolerance.md) + [Amazon DocumentDB フェイルオーバー](failover.md) + [フェイルオーバーターゲットの制御](failover.md#failover-target_control) ### グローバルクラスターによる高可用性 複数の AWS リージョン にわたる高可用性に関して、[Amazon DocumentDB グローバルクラスター](https://docs.aws.amazon.com/documentdb/latest/developerguide/global-clusters.html) をセットアップできます。各グローバルクラスターは複数のリージョンにまたがっており、低レイテンシーのグローバル読み取りと、AWS リージョン 全体の停止からの災害対策を有効にします。Amazon DocumentDB は、プライマリリージョンから各セカンダリリージョンへのすべてのデータと更新の複製を自動的に処理します。 ## レプリカの追加 クラスターに追加される最初のインスタンスは、プライマリインスタンスです。最初のインスタンスの後に追加されるすべてのインスタンスはレプリカインスタンスです。クラスターは、プライマリに加えて 15 個までのレプリカインスタンスを持つことができます。 AWS マネジメントコンソール を使用してクラスターを作成した場合、同時にプライマリインスタンスが自動的に作成されます。クラスターとプライマリインスタンスを作成すると同時にレプリカを作成するには、[**別のゾーンにレプリカを作成します**] を選択します。詳細については、「[Amazon DocumentDB クラスターの作成](db-cluster-create.md)」のステップ 4.d を参照してください。Amazon DocumentDB クラスターにさらにレプリカを追加するには、[クラスターへの Amazon DocumentDB インスタンスの追加](db-instance-add.md) を参照してください。 AWS CLI を使用してクラスターを作成する場合は、プライマリインスタンスとレプリカインスタンスを明示的に作成する必要があります。詳細については、次のトピックで「AWS CLI の使用」セクションを参照してください。 + [Amazon DocumentDB クラスターの作成](db-cluster-create.md) + [クラスターへの Amazon DocumentDB インスタンスの追加](db-instance-add.md) # Amazon DocumentDB フェイルオーバー 特定のタイプの計画的メンテナンスなどの特定の場合、またはプライマリノードまたはアベイラビリティーゾーンの障害が発生する可能性が低い場合、Amazon DocumentDB (MongoDB 互換) が障害を検出し、プライマリノードを置き換えます。フェイルオーバー中、書き込みのダウンタイムは最小限になります。これは、プライマリノードのロールが新しいプライマリノードを作成してプロビジョニングする代わりに、リードレプリカのいずれかにフェイルオーバーするためです。この障害検出とレプリカの昇格により、昇格が完了したらすぐに新しいプライマリへの書き込みを再開できます。 フェイルオーバーが機能するためには、クラスターには少なくとも 2 つのインスタンス、プライマリおよび少なくとも 1 つのレプリカインスタンスが必要です。 **注記** このトピックは、元の Amazon DocumentDB インスタンスベースのクラスターにのみ適用されます。Elastic クラスターまたはグローバルクラスターには適用されません。 ## フェイルオーバーターゲットの制御 Amazon DocumentDB は、フェイルオーバーが発生した場合にプライマリに昇格されるレプリカインスタンスを制御するための手段として、フェイルオーバー階層を提供します。 **フェイルオーバー階層** 各レプリカインスタンスは、フェイルオーバー階層 (0 〜 15) と関連付けられます。メンテナンスのためフェイルオーバーが発生するか、予期しないハードウェア障害が発生した場合、プライマリインスタンスは優先度の最も高い (番号が最も小さい層) レプリカにフェイルオーバーします。優先度が同じ階層を持つ複数のレプリカがある場合、プライマリは、プライマリに最も近いサイズのその階層のレプリカにフェイルオーバーします。 選択したレプリカのグループのフェイルオーバー階層を `0` (最大の優先度) に設定することで、フェイルオーバーでそのグループ内のいずれかのレプリカを昇格することができます。フェイルオーバーが発生した場合に、優先度の低い階層 (高い番号) をこれらのレプリカに割り当てることで、特定のレプリカのプライマリへの昇格を実質的に防ぐことができます。これは、特定のレプリカがアプリケーションによって多く使用され、それらの 1 つへのフェイルオーバーによって重要なアプリケーションに悪影響を与える可能性がある状況で役立ちます。 インスタンスのフェイルオーバー階層は、インスタンスの作成時に設定するか、後でインスタンスを変更して設定できます。インスタンスを変更してインスタンスのフェイルオーバーを設定しても、フェイルオーバーはトリガーされません。詳細については、以下のトピックを参照してください。 + [クラスターへの Amazon DocumentDB インスタンスの追加](db-instance-add.md) + [Amazon DocumentDB インスタンスの変更](db-instance-modify.md) 手動でフェイルオーバーを開始するときは、プライマリに昇格するレプリカインスタンスを制御するための 2 つの方法として、先ほど説明したフェイルオーバー階層と `--target-db-instance-identifier` パラメータがあります。 **--`target-db-instance-identifier`** テストでは、`failover-db-cluster` オペレーションを使用してフェイルオーバーイベントを強制できます。`--target-db-instance-identifier` パラメータを使用して、プライマリに昇格させるレプリカを指定します。`--target-db-instance-identifier` パラメータの使用は、フェイルオーバー優先度階層よりも優先されます。`--target-db-instance-identifier` パラメータを指定しなかった場合、プライマリフェイルオーバーはフェイルオーバー優先度階層に従います。 ## フェイルオーバー中の処理 フェイルオーバーは Amazon DocumentDB によって自動的に処理されるため、アプリケーションは管理上の介入なく、可能な限り迅速にデータベースオペレーションを再開することができます。 + Amazon DocumentDB プリカが同じアベイラビリティーゾーンや別のアベイラビリティーゾーンにあると、フェイルオーバーが発生した場合、Amazon DocumentDB はインスタンスの正規名レコード (CNAME) を切り替えて正常なレプリカを指定します。これに伴い、この正常なレプリカが新しいプライマリに昇格されます。通常、フェイルオーバーは開始から終了まで 30 秒以内に完了します。 + Amazon DocumentDB レプリカインスタンス (単一インスタンスのクラスターなど) がない場合、Amazon DocumentDB は元のインスタンスと同じアベイラビリティーゾーンに新しいインスタンスを作成しようとします。このような元のインスタンスの置換処理はベストエフォート方式で行われるため、アベイラビリティーゾーンの広範囲に影響する問題がある場合などは失敗する可能性があります。 接続が切断された場合、アプリケーションはデータベースへの接続を再試行する必要があります。 ## フェイルオーバーのテスト クラスターのフェイルオーバーにより、クラスター内の Amazon DocumentDB レプリカの 1 つ (読み取り専用インスタンス) が、プライマリインスタンス (クラスターライター) に昇格されます。 Amazon DocumentDB は、プライマリインスタンスが失敗した場合に、存在する場合、自動的に Amazon DocumentDB レプリカにフェイルオーバーします。テストのため、プライマリインスタンスの失敗をシミュレートする場合は、フェイルオーバーを強制できます。クラスター内の各インスタンスには、独自のエンドポイントアドレスがあります。したがって、フェイルオーバーの完了時にこれらのエンドポイントアドレスを使用するすべての既存の接続をクリーンアップして再度確立する必要があります。 フェイルオーバーを強制するには、これらのパラメータを指定して、`failover-db-cluster` オペレーションを使用します。 + `--db-cluster-identifier` — 必須 フェイルオーバーするクラスターの名前。 + `--target-db-instance-identifier` - オプションです。プライマリインスタンスに昇格するインスタンスの名前。 **Example** 以下のオペレーションでは、`sample-cluster` クラスターのフェイルオーバーを強制します。新しいプライマリインスタンスを作成するインスタンスが指定されないため、Amazon DocumentDB はフェイルオーバー階層の優先度に従ってインスタンスを選択します。 Linux、macOS、Unix の場合: ``` aws docdb failover-db-cluster \ --db-cluster-identifier sample-cluster ``` Windows の場合: ``` aws docdb failover-db-cluster ^ --db-cluster-identifier sample-cluster ``` 以下のオペレーションでは、`sample-cluster` クラスターのフェイルオーバーを強制し、`sample-cluster-instance` がプライマリロールに昇格することを指定します。(出力の `"IsClusterWriter": true` に注目してください。) Linux、macOS、Unix の場合: ``` aws docdb failover-db-cluster \ --db-cluster-identifier sample-cluster \ --target-db-instance-identifier sample-cluster-instance ``` Windows の場合: ``` aws docdb failover-db-cluster ^ --db-cluster-identifier sample-cluster ^ --target-db-instance-identifier sample-cluster-instance ``` このオペレーションによる出力は、次のようになります（JSON 形式）。 ``` { "DBCluster": { "HostedZoneId": "Z2SUY0A1719RZT", "Port": 27017, "EngineVersion": "3.6.0", "PreferredMaintenanceWindow": "thu:04:05-thu:04:35", "BackupRetentionPeriod": 1, "ClusterCreateTime": "2018-06-28T18:53:29.455Z", "AssociatedRoles": [], "DBSubnetGroup": "default", "MasterUsername": "master-user", "Engine": "docdb", "ReadReplicaIdentifiers": [], "EarliestRestorableTime": "2018-08-21T00:04:10.546Z", "DBClusterIdentifier": "sample-cluster", "ReaderEndpoint": "sample-cluster.node.us-east-1.docdb.amazonaws.com", "DBClusterMembers": [ { "DBInstanceIdentifier": "sample-cluster-instance", "DBClusterParameterGroupStatus": "in-sync", "PromotionTier": 1, "IsClusterWriter": true }, { "DBInstanceIdentifier": "sample-cluster-instance-00", "DBClusterParameterGroupStatus": "in-sync", "PromotionTier": 1, "IsClusterWriter": false }, { "DBInstanceIdentifier": "sample-cluster-instance-01", "DBClusterParameterGroupStatus": "in-sync", "PromotionTier": 1, "IsClusterWriter": false } ], "AvailabilityZones": [ "us-east-1b", "us-east-1c", "us-east-1a" ], "DBClusterParameterGroup": "default.docdb3.6", "Endpoint": "sample-cluster.node.us-east-1.docdb.amazonaws.com", "IAMDatabaseAuthenticationEnabled": false, "AllocatedStorage": 1, "LatestRestorableTime": "2018-08-22T21:57:33.904Z", "PreferredBackupWindow": "00:00-00:30", "StorageEncrypted": false, "MultiAZ": true, "Status": "available", "DBClusterArn": "arn:aws:rds:us-east-1:123456789012:cluster:sample-cluster", "VpcSecurityGroups": [ { "Status": "active", "VpcSecurityGroupId": "sg-12345678" } ], "DbClusterResourceId": "cluster-ABCDEFGHIJKLMNOPQRSTUVWXYZ" } } ``` ## レプリケーションの遅延 レプリケーションラグは通常 50 ms 以下です。レプリカのラグが上がる最も一般的な理由は次のとおりです。 + リードレプリカがプライマリより遅くなる原因として、プライマリの書き込みレートが高いです。 + 長時間実行されるクエリ (大規模なシーケンシャルスキャン、集約クエリなど) と着信書き込みレプリケーションの間のリードレプリカの競合。 + リードレプリカの同時クエリが非常に多いです。 レプリケーションの遅延を最小限に抑えるには、次のトラブルシューティング方法を試してください。 + 書き込みレートが高いか CPU 使用率が高い場合は、クラスター内のインスタンスをスケールアップすることをお勧めします。 + リードレプリカで長時間実行されるクエリがあり、クエリ対象のドキュメントが非常に頻繁に更新される場合は、リードレプリカでの競合を回避するために、長時間実行されるクエリを変更するか、プライマリ/書き込みレプリカに対して実行することを検討してください。 + 同時クエリが非常に多い場合や、リードレプリカでのみ高い CPU 使用率がある場合、別のオプションは、リードレプリカの数をスケールアウトしてワークロードを分散することです。 + レプリケーションラグは、高い書き込みスループットと長時間実行されるクエリの結果であるため、DBClusterReplicalagMaximum CW メトリクスを低速クエリロガーと `WriteThroughput`/`WriteIOPS` メトリクスと組み合わせて、レプリケーションラグをトラブルシューティングすることをお勧めします。 一般に、クラスターのフェイルオーバーによってパフォーマンスが低下しないように、すべてのレプリカが同じインスタンスタイプであることを推奨します。 スケールアップとスケールアウト (例：6 つの小さいインスタンスと 3 つの大きなインスタンス) を選択する場合は、DB インスタンスごとに大きなバッファーキャッシュが得られるため、スケールアウト前に最初に (より大きなインスタンス) にスケールアップすることをお勧めします。 プロアクティブに、レプリケーション・ラグ・アラームを設定し、アプリケーションの機能に影響を及ぼす前に、しきい値をレプリカ・インスタンス上のデータがどの程度遅れる (または「古い」) 上限であると感じる値に設定する必要があります。一般に、一時的なワークロードが原因で、アラームが発生する前に、複数のデータポイントについてレプリケーションラグのしきい値を超えることをお勧めします。 **注記** さらに、10 秒を超えるレプリケーションラグに対して別のアラームを設定することをお勧めします。複数のデータポイントでこのしきい値を超える場合は、インスタンスをスケールアップするか、プライマリインスタンスの書き込みスループットを削減することをお勧めします。