# Amazon Aurora の高可用性
Amazon Aurora アーキテクチャでは、ストレージとコンピューティングが分離されます。Aurora では、高可用性のためのいくつかの機能が、DB クラスターのデータに対し適用されます。クラスター内の DB インスタンスの一部またはすべてが使用できなくなっても、データは安全に維持されます。その他の高可用性機能は、DB インスタンスに適用されます。これらの機能により、1 つまたはそれ以上の DB インスタンスがアプリケーションからのデータベースリクエストを処理できます。
**Topics**
+ [Aurora データの高可用性](#Concepts.AuroraHighAvailability.Data)
+ [Aurora DB インスタンスの高可用性](#Concepts.AuroraHighAvailability.Instances)
+ [Aurora グローバルデータベースを使用した AWS リージョン間での高可用性](#Concepts.AuroraHighAvailability.GlobalDB)
+ [Aurora DB クラスターの耐障害性](#Aurora.Managing.FaultTolerance)
+ [Amazon RDS Proxy における高可用性](#Concepts.AuroraHighAvailability.Proxy)
## Aurora データの高可用性
Aurora は、単一の AWS リージョン 内の複数のアベイラビリティーゾーンにまたがる DB クラスターにデータのコピーを保存します。Aurora は、DB クラスターのインスタンスが複数のアベイラビリティーゾーンにまたがっているかどうかにかかわらず、これらのコピーを作成します。Aurora の詳細については、「[Amazon Aurora DB クラスターの管理](CHAP_Aurora.md)」を参照してください。
データがプライマリ DB インスタンスに書き込まれると、Aurora によりアベイラビリティーゾーン全体で、クラスターボリュームに関連付けられた 6 つのストレージノードにデータが同期的に複製されます。これにより、データの冗長性が確保されて I/O のフリーズが回避され、システムバックアップ時のレイテンシー急上昇が最小限に抑えられます。高可用性を備えた DB インスタンスを実行すると、計画されたシステムメンテナンス中の可用性が向上し、障害とアベイラビリティーゾーンの中断からデータベースを保護できます。アベイラビリティーゾーンの詳細については、「[リージョンとアベイラビリティーゾーン](Concepts.RegionsAndAvailabilityZones.md)」を参照してください。
## Aurora DB インスタンスの高可用性
プライマリ (ライター) インスタンスを作成した後、最大 15 の読み取り専用 Aurora レプリカを作成できます。Aurora レプリカはリーダーインスタンスとも呼ばれます。Aurora レプリカは、非同期レプリケーションを使用して、プライマリインスタンスのパフォーマンスに影響を与えずに高可用性をサポートします。
日常的な操作で、読み取りを多用するアプリケーションの作業の一部をオフロードするには、リーダーインスタンスを使用して `SELECT` クエリを処理します。問題がプライマリインスタンスに影響する場合、これらのリーダーインスタンスの 1 つがプライマリインスタンスとして引き継ぎます。このメカニズムは*フェイルオーバー*と呼ばれます。多くの Aurora 機能がフェイルオーバーメカニズムに適用されます。例えば、Aurora はデータベースの問題を検出し、必要に応じてフェイルオーバーのメカニズムを自動的にアクティブにします。Aurora には、フェイルオーバーが完了するまでの時間を短縮する機能もあります。これにより、フェイルオーバー中にデータベースを書き込みに使用できない時間を最小限に抑えることができます。
Aurora は、できるだけ早く復旧するように設計されており、多くの場合、復旧までの最も速い方法は、再起動または同じ DB インスタンスへのフェイルオーバーです。再起動はフェイルオーバーよりも速く、オーバーヘッドも少なくなります。
フェイルオーバーによって新しいプライマリインスタンスが昇格しても同じ接続文字列を使用するには、クラスターエンドポイントに接続します。*クラスターエンドポイント*は常に、クラスター内の現在のプライマリインスタンスを表します。クラスターエンドポイントの詳細については、「[Amazon Aurora エンドポイント接続](Aurora.Overview.Endpoints.md)」を参照してください。
**ヒント**
各 AWS リージョン 内では、アベイラビリティーゾーンは、停止時に分離できるよう、相互に異なる場所を示します。DB クラスターのプライマリインスタンスとリーダーインスタンスを複数の AZ に分散して、DB クラスターの可用性を改善することをお勧めします。そうすることで、AZ 全体に影響する問題によりクラスターの停止が引き起こされることはありません。
マルチ AZ DB クラスターをセットアップするには、クラスターの作成時に簡単な選択を行います。AWS マネジメントコンソール、AWS CLI、または Amazon RDS API を使用できます。また、既存の Aurora DB クラスターをマルチ AZ DB クラスターに変換するには、新しいリーダー DB インスタンスを追加し、別の AZ を指定します。
## Aurora グローバルデータベースを使用した AWS リージョン間での高可用性
複数の AWS リージョン で高可用性を実現するために、Aurora グローバルデータベースを設定できます。各 Aurora グローバルデータベースは複数の AWS リージョン にまたがっているため、低レイテンシーでのグローバル読み取りが実現し、AWS リージョン 全体の停止からの災害対策を可能とします。Aurora は、プライマリ AWS リージョン から各セカンダリリージョンにすべてのデータと更新を非同期にレプリケートします。詳細については、「[Amazon Aurora Global Database の使用](aurora-global-database.md)」を参照してください。
## Aurora DB クラスターの耐障害性
Aurora DB クラスターは、耐障害性を持つように設計されています。クラスターボリュームは 1 つの AWS リージョン 内の複数のアベイラビリティーゾーン (AZ) にまたがり、各アベイラビリティーゾーンにはクラスターボリュームデータのコピーが含まれます。この機能は、DB クラスターがデータ喪失なしでアベイラビリティーゾーンの障害に耐えることができ、発生するのはサービスの短時間の中断のみであることを意味します。
DB クラスターのプライマリインスタンスが失敗した場合、Aurora は次の 2 つの方法のいずれかで、新しいプライマリインスタンスに自動的にフェイルオーバーします。
+ 既存の Aurora レプリカを新しいプライマリインスタンスに昇格する
+ 新しいプライマリインスタンスを作成する
DB クラスターに 1 つ以上の Aurora レプリカがある場合は、障害発生中に 1 つの Aurora レプリカがプライマリインスタンスに昇格されます。障害イベントによって短い中断が発生し、その間例外によって読み取りと書き込みオペレーションが失敗します。ただし、サービスの一般的な復元時間は 60 秒未満であり、多くの場合 30 秒未満です。DB クラスターの可用性を高めるために、複数のアベイラビリティーゾーン内で少なくとも 1 つ以上の Aurora レプリカを作成することをお勧めします。
**ヒント**
Aurora MySQL では、クラスター内に複数のリーダー DB インスタンスを持つことで、フェイルオーバー中の可用性を向上させることができます。Aurora MySQL では、Aurora は、ライター DB インスタンスとフェイルオーバー先のリーダーインスタンスのみを再起動します。クラスター内の他のリーダー DB インスタンスは、フェイルオーバー中も使用可能であり、リーダーエンドポイントへの接続を通じてクエリの処理を続行します。
また、Aurora DB クラスターで RDS Proxy を使用することで、フェイルオーバー中の可用性を向上させることができます。詳細については、「[Amazon RDS Proxy における高可用性](#Concepts.AuroraHighAvailability.Proxy)」を参照してください。
各レプリカに優先度を割り当てることで、Aurora レプリカがプライマリインスタンスに昇格される順序をカスタマイズできます。優先度の範囲は、最も高い 0 から最も低い 15 までです。プライマリインスタンスが失敗した場合、Amazon RDS は優先度が高い Aurora Replica を新しいプライマリインスタンスに昇格します。Aurora レプリカの優先度はいつでも変更できます。優先度を変更しても、フェイルオーバーはトリガーされません。
複数の Aurora レプリカで同じ優先度を共有でき、その場合は昇格階層が発生します。複数の Aurora レプリカで同じ優先度を共有する場合、Amazon RDS は最大サイズのレプリカを昇格します。複数の Aurora レプリカで同じ優先度とサイズを共有する場合、Amazon RDS は同じ昇格階層の任意のレプリカを昇格します。
**注記**
フェイルオーバーターゲットを特定するには、いくつかの要因が関係します。フェイルオーバーが 5 回失敗すると、昇格階層は考慮されなくなります。
DB クラスターに Aurora レプリカが含まれていない場合、障害イベントの発生時にプライマリインスタンスが同じ AZ に再作成されます。障害イベントによって中断が発生し、その間例外によって読み取りと書き込みオペレーションが失敗します。新しいプライマリインスタンスが再作成されると、サービスが回復します。これは、通常は 10 分未満で行われます。Aurora レプリカのプライマリインスタンスへの昇格は、新しいプライマリインスタンスの作成よりもはるかに短時間で実行されます。
AZ 全体に影響する停止のため、クラスター内のプライマリインスタンスが使用できないとします。この場合、新しいプライマリインスタンスをオンラインにする方法は、クラスターでマルチ AZ 設定を使用するかどうかによって異なります。
+ プロビジョン済みまたは Aurora Serverless v2 クラスターに他の AZ のリーダーインスタンスが含まれている場合、Aurora はフェイルオーバーメカニズムを使用して、それらのリーダーインスタンスのいずれかを新しいプライマリインスタンスに昇格させます。
+ プロビジョン済みまたは Aurora Serverless v2 クラスターに 1 つの DB インスタンスしか含まれていない場合、またはプライマリインスタンスとすべてのリーダーインスタンスが同じ AZ にある場合は、別の AZ に 1 つまたは複数の新しい DB インスタンスを手動で作成する必要があります。
+ クラスターが Aurora Serverless v1 を使用する場合、Aurora は別の AZ に新しい DB インスタンスを自動的に作成します。ただし、このプロセスにはホストの交換が必要であるため、フェイルオーバーよりも時間がかかります。
**注記**
Amazon Aurora では、外部 MySQL データベースまたは RDS MySQL DB インスタンスとのレプリケーションもサポートします。詳細については、「[Aurora と MySQL との間、または Aurora と別の Aurora DB クラスターとの間のレプリケーション (バイナリログレプリケーション)](AuroraMySQL.Replication.MySQL.md)」を参照してください。
## Amazon RDS Proxy における高可用性
RDS Proxy を使用すると、複雑な障害処理コードを記述しなくても、データベースの障害を透過的に許容できるアプリケーションを構築できます。プロキシでは、アプリケーション接続を維持したまま、新しいデータベースインスタンスにトラフィックを自動的にルーティングします。また、ドメインネームシステム (DNS) キャッシュをバイパスすることで、Aurora マルチ AZ データベースのフェイルオーバー時間を最大 66% 短縮できます。詳細については、「[Amazon RDS Proxy for Aurora](rds-proxy.md)」を参照してください。