Amazon Aurora の高可用性

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

Aurora データの高可用性

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

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

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

プライマリ (ライター) インスタンスを作成した後、最大 15 の読み取り専用 Aurora レプリカを作成できます。Aurora レプリカはリーダーインスタンスとも呼ばれます。

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

Aurora は、できるだけ早く復旧するように設計されており、多くの場合、復旧までの最も速い方法は、再起動または同じ DB インスタンスへのフェイルオーバーです。再起動はフェイルオーバーよりも速く、オーバーヘッドも少なくなります。

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

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

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

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

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

DB クラスターのプライマリインスタンスが失敗した場合、Aurora は次の 2 つの方法のいずれかで、新しいプライマリインスタンスに自動的にフェイルオーバーします。

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

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

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

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

AZ 全体に影響する停止のため、クラスター内のプライマリインスタンスが使用できないとします。この場合、新しいプライマリインスタンスをオンラインにする方法は、クラスターでマルチ AZ 設定を使用するかどうかによって異なります。

Amazon RDS Proxy における高可用性

RDS Proxy を使用すると、複雑な障害処理コードを記述しなくても、データベースの障害を透過的に許容できるアプリケーションを構築できます。プロキシでは、アプリケーション接続を維持したまま、新しいデータベースインスタンスにトラフィックを自動的にルーティングします。また、ドメインネームシステム (DNS) キャッシュをバイパスすることで、Aurora マルチ AZ データベースのフェイルオーバー時間を最大 66% 短縮できます。詳細については、「Amazon RDS Proxy for Aurora の使用」を参照してください。