Amazon Aurora の高可用性 - Amazon Aurora

Amazon Aurora の高可用性

Amazon Aurora アーキテクチャには、ストレージとコンピューティングの分離が含まれます。Aurora には、DB クラスターのデータに適用されるいくつかの高可用性機能が含まれます。クラスター内の DB インスタンスの一部またはすべてが使用できなくなっても、データは安全に維持されます。その他の高可用性機能は、DB インスタンスに適用されます。これらの機能により、1 つまたはそれ以上の DB インスタンスがアプリケーションからのデータベースリクエストを処理できます。

Aurora データの高可用性

Aurora では、1 つの AWS リージョン内の複数のアベイラビリティーゾーン間で DB クラスター内のデータのコピーを保存します。Aurora は、DB クラスター内のインスタンスが複数のアベイラビリティーゾーンにまたがっているかどうかに関係なく、これらのコピーを保存します。Aurora の詳細については、「Amazon Aurora DB クラスターの管理」を参照してください。

データがプライマリ DB インスタンスに書き込まれると、Aurora によりアベイラビリティーゾーン全体で、クラスターボリュームに関連付けられた 6 つのストレージノードにデータが同期的に複製されます。これにより、データの冗長性が確保されて I/O のフリーズが回避され、システムバックアップ時のレイテンシー急上昇が最小限に抑えられます。高可用性を備えた DB インスタンスを実行すると、計画されたシステムメンテナンス中の可用性が向上し、障害とアベイラビリティーゾーンの中断からデータベースを保護できます。アベイラビリティーゾーンの詳細については、「 リージョンとアベイラビリティーゾーン 」を参照してください。

Aurora DB インスタンスの高可用性

シングルマスターレプリケーションを使用するクラスターの場合、プライマリインスタンスを作成した後、最大 15 個の読み取り専用 Aurora レプリカを作成できます。Aurora レプリカはリーダーインスタンスとも呼ばれます。

日常的な操作で、読み取りを多用するアプリケーションの作業の一部をオフロードするには、リーダーインスタンスを使用して SELECT クエリを処理します。問題がプライマリインスタンスに影響する場合、これらのリーダーインスタンスの 1 つがプライマリインスタンスとして引き継ぎます。このメカニズムはフェールオーバーと呼ばれます。多くの Aurora 機能がフェールオーバーメカニズムに適用されます。たとえば、Aurora はデータベースの問題を検出し、必要に応じてフェールオーバーメカニズムを自動的にアクティブにします。Aurora には、フェールオーバーが完了するまでの時間を短縮する機能もあります。これにより、フェールオーバー中にデータベースを書き込みに使用できない時間を最小限に抑えることができます。

フェールオーバーによって新しいプライマリインスタンスが昇格しても同じ接続文字列を使用するには、クラスターエンドポイントに接続します。クラスターエンドポイントは常に、クラスター内の現在のプライマリインスタンスを表します。クラスターエンドポイントの詳細については、「Amazon Aurora 接続管理」を参照してください。

ヒント

各 AWS リージョン内では、アベイラビリティーゾーンは、停止時に分離できるよう、相互に異なる場所を表します。DB クラスターのプライマリインスタンスとリーダーインスタンスを複数のアベイラビリティーゾーンに配信して、DB クラスターの可用性を改善することをお勧めします。そうすることで、アベイラビリティーゾーン全体に影響する問題によりクラスターの停止が引き起こされることはありません。

マルチ AZ クラスターをセットアップするには、クラスターの作成時に簡単な選択を行います。AWS マネジメントコンソール、AWS CLI、Amazon RDS API のいずれを使用する場合でも、選択は簡単です。既存の Aurora クラスターをマルチ AZ クラスターにするには、新しいリーダーインスタンスを追加し、別のアベイラビリティーゾーンを指定します。

Aurora グローバルデータベースを使用した AWS リージョン間の高可用性

複数の AWS リージョンで高可用性を実現するために、Aurora グローバルデータベースを設定できます。各 Aurora グローバルデータベースは複数の AWS リージョンにまたがっており、低レイテンシーのグローバル読み取りと、AWS リージョン全体での停止からの災害復旧を可能にします。Aurora は、プライマリ AWS リージョンから各セカンダリリージョンへのすべてのデータと更新のレプリケートを自動的に処理します。詳細については、「Amazon Aurora グローバルデータベースの使用」を参照してください。

Aurora DB クラスターの耐障害性

Aurora DB クラスターは、耐障害性を持つように設計されています。クラスターボリュームは 1 つの AWS リージョン内の複数のアベイラビリティーゾーンにまたがり、各アベイラビリティーゾーンにはクラスターボリュームデータのコピーが含まれます。この機能は、DB クラスターがデータ喪失なしでアベイラビリティーゾーンの障害に耐えることができ、発生するのはサービスの短時間の中断のみであることを意味します。

シングルマスターレプリケーションを使用した DB クラスターのプライマリインスタンスが失敗した場合、Aurora は以下のいずれかの方法で、新しいプライマリインスタンスに自動的にフェイルオーバーします。

  • 既存の Aurora レプリカを新しいプライマリインスタンスに昇格する

  • 新しいプライマリインスタンスを作成する

DB クラスターに 1 つ以上の Aurora レプリカがある場合は、障害発生中に 1 つの Aurora レプリカがプライマリインスタンスに昇格されます。障害イベントによって短い中断が発生し、その間例外によって読み取りと書き込みオペレーションが失敗します。ただし、一般的なサービスの復元時間は 120 秒未満であり、多くの場合 60 秒未満で復元されます。DB クラスターの可用性を高めるために、複数のアベイラビリティーゾーン内で少なくとも 1 つ以上の Aurora レプリカを作成することをお勧めします。

各レプリカに優先度を割り当てることで、Aurora レプリカがプライマリインスタンスに昇格される順序をカスタマイズできます。優先度の範囲は、最も高い 0 から最も低い 15 までです。プライマリインスタンスが失敗した場合、Amazon RDS は優先度が高い Aurora レプリカを新しいプライマリインスタンスに昇格します。Aurora レプリカの優先度はいつでも変更できます。優先度を変更しても、フェイルオーバーはトリガーされません。

複数の Aurora レプリカで同じ優先度を共有でき、その場合は昇格階層が発生します。複数の Aurora レプリカで同じ優先度を共有する場合、Amazon RDS は最大サイズのレプリカを昇格します。複数の Aurora レプリカで同じ優先度とサイズを共有する場合、Amazon RDS は同じ昇格階層の任意のレプリカを昇格します。

DB クラスターに Aurora レプリカが含まれていない場合、障害イベントの発生時にプライマリインスタンスが再作成されます。障害イベントによって中断が発生し、その間例外によって読み取りと書き込みオペレーションが失敗します。新しいプライマリインスタンスが再作成されると、サービスが回復します。これは、通常は 10 分未満で行われます。Aurora レプリカのプライマリインスタンスへの昇格は、新しいプライマリインスタンスの作成よりもはるかに短時間で実行されます。

AZ 全体に影響する停止のため、クラスター内のプライマリインスタンスが使用できないとします。この場合、新しいプライマリインスタンスをオンラインにする方法は、クラスターでマルチ AZ 設定を使用するかどうかによって異なります。クラスターに他の AZ のリーダーインスタンスが含まれている場合、Aurora はフェイルオーバーメカニズムを使用して、それらのリーダーインスタンスのいずれかを新しいプライマリインスタンスに昇格させます。プロビジョニングされたクラスターに 1 つの DB インスタンスしか含まれていない場合、またはプライマリインスタンスとすべてのリーダーインスタンスが同じ AZ にある場合は、別の AZ に 1 つ以上の新しい DB インスタンスを手動で作成する必要があります。クラスターが Aurora Serverless を使用する場合、Aurora は別の AZ に新しい DB インスタンスを自動的に作成します。ただし、このプロセスにはホストの交換が必要であるため、フェイルオーバーよりも時間がかかります。

注記

Amazon Aurora では、外部 MySQL データベースまたは RDS MySQL DB インスタンスとのレプリケーションもサポートします。詳細については、「Aurora と MySQL との間、または Aurora と別の Aurora DB クラスターとの間のレプリケーション (バイナリログレプリケーション)」を参照してください。