Amazon Auroraのアーキテクチャと可用性

Amazon Auroraは、MySQLおよびPostgreSQLと互換性のあるリレーショナルデータベースエンジンです。一般的なDBインスタンスのように、計算資源とデータファイルを一体で増やすのではなく、DBインスタンスの計算層と共有ストレージ層を分けて扱います。この分離により、読み取り処理を担うインスタンスを増やしながら、同じデータボリュームを共有できます。

計算層とクラスターボリューム

Aurora DBクラスターは、データベースを実行するDBインスタンスと、それらが共有するクラスターボリュームで構成されます。DBインスタンスを追加しても、インスタンスごとに独立したデータファイル一式を作るわけではありません。書き込みを処理するライターと、主に読み取りを処理するリーダーが、同じクラスターボリュームを利用します。

この構成では、CPUやメモリが不足する場合にはDBインスタンスのクラスを変更し、参照要求を分散したい場合にはリーダーを追加する、といった計算層の調整ができます。読み取り用インスタンスの追加は読み取り容量を増やす方法であり、書き込みを複数のインスタンスへ単純に分散する仕組みではありません。

クラスターボリュームは3つのアベイラビリティーゾーン（AZ）にまたがり、データを6つのストレージコピーとして保持します。各AZに2コピーずつ配置することで、AZをまたいだ冗長性を持たせます。ストレージ層は障害のあるコピーを検出して修復する設計であり、DBインスタンスの障害とは別の層でデータの耐久性を支えます。

クォーラムによる読み書き

Auroraのストレージは、6コピーすべてが常に応答しなくても処理を継続できるよう、クォーラムを使います。クォーラムとは、ある操作を成立させるために必要な応答数です。Auroraでは書き込みに6コピー中4コピー、読み取りに6コピー中3コピーの応答が必要です。

書き込みでは4コピーへの記録が成立すれば確認応答を返せるため、残り2コピーが一時的に応答できなくても書き込みを続けられます。読み取りでは3コピーから情報を集め、必要な更新を取り込んで一貫した結果を組み立てます。読み取りと書き込みで必要な票数が異なるのは、読み書きの集合が重なり、最新の書き込み情報を読み取り側で確認できるようにするためです。

この数は、DBインスタンスやAZの数ではなく、ストレージコピーに対するクォーラムです。また「2コピーに障害があってもどのような障害でも無条件に安全」という意味ではありません。障害の種類や同時発生数によって可用性への影響は変わります。

ライター、リーダーと接続エンドポイント

標準的なAurora DBクラスターは、書き込み可能なライターインスタンスを1つ持ち、必要に応じて読み取り専用の リーダーインスタンス（Auroraレプリカ） を追加します。リーダーはライターと同じクラスターボリュームを参照するため、通常の別ストレージ複製とは異なる形で読み取り容量を拡張します。利用できるリーダー数はエンジンや構成の現行上限を確認します。代表的な上限は15台ですが、対応リージョン・バージョン・サービスクォータに従います。

アプリケーションは、用途に応じてクラスターのエンドポイントを選びます。

エンドポイント	接続先	主な用途
クラスターエンドポイント	現在のライター	更新処理、書き込みを伴う通常の接続
リーダーエンドポイント	利用可能なリーダー群	読み取り要求の負荷分散
インスタンスエンドポイント	指定したDBインスタンス	特定レプリカの状態確認や個別の運用
カスタムエンドポイント	選択したDBインスタンス群	分析用など、用途を限定した読み取り経路

分析ダッシュボードが定期的に集計クエリを実行する構成では、読み取り要求をリーダーエンドポイントや分析用リーダーだけを含むカスタムエンドポイントへ送る方法があります。これにより、アプリケーションの更新処理と集計処理の接続先を分けられます。カスタムエンドポイントは接続先インスタンスをまとめる機能であり、クエリの内容を解析して書き込みをライターへ転送する機能ではありません。

フェイルオーバーと昇格候補

ライターに障害が発生すると、Auroraはリーダーを新しいライターへ昇格させます。クラスターエンドポイントのDNS応答は新しいライターを指すよう更新されるため、通常はアプリケーション側で別のホスト名へ変更する必要はありません。ただし、フェイルオーバー中は既存のDB接続が切断されます。DNSを長くキャッシュした接続プールや、古い接続を再利用し続けるアプリケーションでは再接続が遅れることがあるため、接続の再確立、タイムアウト、再試行を設計します。

Auroraのフェイルオーバーは多くの場合60秒未満で完了しますが、これは保証された上限時間ではありません。障害状況、インスタンスの状態、接続の再確立を含むアプリケーション側の動作によって、復旧に60秒を超える場合もあります。従来型のRDS Multi-AZ DBインスタンスでは、フェイルオーバーに60〜120秒程度かかる場合があると説明されます。これも構成や障害状況で変わる目安であり、復旧時間の保証ではありません。RDS Multi-AZ DBクラスターなど別の配置モードでは仕組みや所要時間が異なるため、エンジンと配置方式を確認します。

複数のリーダーがある場合は、各インスタンスに フェイルオーバー優先度（promotion tier） を設定できます。数値の小さい優先度層が先に昇格候補となり、同じ層に複数の候補がいる場合は、より大きなDBインスタンスクラスが優先されます。優先度が同じ候補間で能力の高いインスタンスを選ぶのは、ライター昇格後に必要な計算能力を確保しやすくするためです。重要な読み取り処理を担う大きなレプリカと、補助的な小さなレプリカがある場合は、意図しない候補が先に昇格しないよう優先度を設計します。

フェイルオーバー後のキャッシュ

DBインスタンスには、ディスク上のデータをメモリへ読み込んで再利用するキャッシュがあります。フェイルオーバー直後にキャッシュが十分に温まっていないと、クエリがストレージからデータを取得し直すため、一時的に性能が低下することがあります。

対応するAurora MySQLの構成では、DBクラスターキャッシュ管理を使って、昇格候補のレプリカでバッファープールの状態を保ち、フェイルオーバー後のキャッシュ再構築による影響を小さくできます。これは対象エンジン・バージョンで設定条件を満たした場合の性能対策です。障害検知や昇格そのものを省略する機能ではなく、フェイルオーバー中の接続断もなくしません。

Aurora Global Database

Aurora Global Databaseは、1つのプライマリリージョンと、別リージョンのセカンダリーDBクラスターを組み合わせる機能です。通常のクラスター内でAZ間に共有ストレージを持つ仕組みと、リージョン間でデータを複製する仕組みを分けて理解します。リージョン間複製はAuroraのストレージ層で行われ、通常のSQLベースのクロスリージョンレプリカより低いレイテンシーで複製できます。

一般的な構成説明では、プライマリに加えて最大5つのセカンダリーリージョンを作成できます。エンジン、バージョン、リージョン、サービスクォータによって条件が変わるため、作成時にはAWSの現行上限を確認してください。セカンダリークラスターには読み取り接続を受け付けるリーダーを配置できます。

この構成は、複数地域の利用者が近いリージョンから読み取る用途と、プライマリリージョン障害時の災害復旧に役立ちます。アプリケーションがどのリージョンのエンドポイントへ接続するかはアプリケーションやグローバルルーティングの設計で決めます。Global Databaseを作っただけで、利用者が自動的に最寄りリージョンへ振り分けられるわけではありません。

プライマリリージョンでの書き込みはセカンダリーへ非同期に反映されるため、リージョン間に複製遅延があります。通常は非常に小さい遅延を目指す設計ですが、セカンダリーが常にプライマリと同時点のデータを読む強い同期構成ではありません。リージョン障害時にはセカンダリーを昇格させて書き込み先を切り替えます。計画的な切り替えと障害時のフェイルオーバーではデータ保護の条件が異なるため、RTO（目標復旧時間）とRPO（目標復旧時点）に合わせて手順を決めます。多くの障害復旧シナリオで切り替えは60秒未満を目標にできますが、完了時間は保証されません。

通常のクロスリージョンリードレプリカとの比較

Aurora Global Database以外にも、別リージョンに読み取り専用のAuroraクラスターを用意するクロスリージョンレプリカ構成があります。こちらは対応するエンジンやバージョンの条件に従い、データベースレベルの複製を使います。Global Databaseがストレージ層で複製する方式であることに対し、クロスリージョンリードレプリカではより大きな遅延が発生する場合があります。

比較点	Aurora Global Database	クロスリージョンリードレプリカ
複製の仕組み	ストレージ層のリージョン間複製	対応エンジンに応じたデータベースレベルの複製
代表的な目的	低遅延の地理分散読み取り、リージョン障害からの復旧	リージョンをまたぐ読み取り、復旧用の複製
遅延の考え方	小さい遅延を前提に設計されるが、非同期でありゼロとは限らない	Global Databaseより大きくなる場合がある
運用時の注意	セカンダリー昇格後の書き込み先変更、複製状態の監視	エンジン条件、レプリケーションラグ、昇格手順の確認

どちらを選ぶかは、読み取りの近接性、許容できる複製遅延、復旧目標、対応エンジン、コストで判断します。Global Databaseの方が常に必要ということではなく、通常のクロスリージョンレプリカで要件を満たせる場合もあります。リージョンに近い利用者へ読み取り先を配置したり、障害時に別リージョンへ切り替えたりできますが、レプリカは独立したバックアップの代わりではありません。地理的に離れた場所へバックアップを保管する要件では、スナップショットやAWS Backupのクロスリージョンコピーも検討します。料金はリージョン間転送、DBインスタンス、ストレージ、I/Oなど構成要素に応じて発生するため、最新の料金表で見積もります。

Multi-Masterの位置づけ

標準的なAuroraクラスターは、1つのライターと複数のリーダーで構成します。Aurora Multi-Masterは、複数のDBインスタンスが書き込み可能になる旧来の別機能です。これは通常のAuroraレプリカを複数用意することとは異なり、すべてのAurora MySQL構成で選べる現在の標準機能ではありません。過去に説明される代表的な構成では最大2台のライターを置けましたが、実際の可否・台数は対応するAurora MySQLのバージョンなどに依存します。新規設計では現行のエンジンバージョンとAWSの対応表を先に確認してください。

複数ライター間で同じデータへの更新を調整するため、単一ライター構成より書き込み性能が低下する場合があります。ネットワーク上で離れたインスタンス間の調整が増えれば、書き込みレイテンシーにも影響します。複数インスタンスから同時に書き込めるという性質だけを見て、性能が自動的に向上すると判断してはいけません。また、Aurora MySQL Multi-Masterではバックトラックを使用できません。バックトラックは対応するAurora MySQLクラスターを過去の状態へ戻す機能であり、スナップショットやポイントインタイムリカバリとは利用条件も異なります。

試験での見分け方

• ストレージの冗長性と一部障害時の継続性が問われたら、3AZに6コピーを置き、書き込み4票・読み取り3票を必要とするクォーラムを考えます。
• 読み取り負荷をリーダーへ分散したいなら、リーダーエンドポイントを使います。書き込みにはクラスターエンドポイントを使います。
• ライター障害時にどのレプリカを昇格するかを制御したいなら、フェイルオーバー優先度層を設計します。同じ層では大きなDBインスタンスクラスが優先されます。
• フェイルオーバー後の一時的な性能低下を減らしたいなら、対応するAurora MySQLでのDBクラスターキャッシュ管理を検討します。接続断そのものを回避する機能ではありません。
• 複数リージョンから近い場所で読み取りたい、またはリージョン障害に備えたいならAurora Global Databaseを検討します。地域に応じたエンドポイント選択と、昇格後の切り替え設計も必要です。
• 複数ライターを持つAuroraを問われた場合は、通常の1ライター＋リーダー構成とMulti-Masterの違いを読みます。Multi-Masterはエンジンとバージョンに強く依存する機能で、バックトラックも利用できません。

公式ドキュメント

• Amazon Auroraの概要
• Auroraの耐障害性とストレージ
• Aurora DBクラスターのエンドポイント
• Auroraのフェイルオーバー
• Aurora MySQLのDBクラスターキャッシュ管理
• Aurora Global Database
• Aurora MySQLのクロスリージョンリードレプリカ
• Aurora MySQL Multi-Masterの使用
• Amazon Auroraの料金