[レポート] Amazon AuroraのHA/DR設計パターンでグローバルレジリエンスを実現するためのセッションに参加しました #AWSreInvent #DAT442

はじめに

皆様こんにちは、あかいけです。

AWS re:Invent 2025に参加しており、
「Amazon Aurora HA and DR design patterns for global resilience」というセッションを聞いてきました。

Amazon Auroraは、グローバル規模でPostgreSQLとMySQLに対応した高いパフォーマンスと可用性を提供するサーバーレスリレーショナルデータベースです。
本セッションでは、AuroraのHA(高可用性)とDR(災害復旧)の機能について、リージョン内およびクロスリージョンでの設計パターンが詳しく解説されましたので、その内容をまとめてみました。

セッション概要

タイトル
Amazon Aurora HA and DR design patterns for global resilience [SIMULCAST] (DAT442-SC)

概要

Amazon Aurora is a serverless relational database with unparalleled high performance and availability at global scale for PostgreSQL, MySQL, and DSQL. Aurora provides managed high availability (HA) and disaster recovery (DR) capabilities in and across AWS Regions. In this session, explore the Aurora HA and DR capabilities and discover design patterns that enable the development of resilient applications. Learn how to establish in-Region and cross-Region HA and DR using Aurora features including Multi-AZ deployments and Aurora Global Database, and how Aurora DSQL multi-Region clusters provides the highest level of availability and application resilience.

Amazon Aurora は、PostgreSQL、MySQL、DSQL に対応した、比類のない高性能とグローバル規模の可用性を備えたサーバーレスリレーショナルデータベースです。Aurora は、AWS リージョン内およびリージョン間でマネージド型の高可用性 (HA) と災害復旧 (DR) 機能を提供します。このセッションでは、Aurora の HA および DR 機能の詳細と、耐障害性に優れたアプリケーション開発を可能にする設計パターンを紹介します。マルチ AZ 配置や Aurora Global Database などの Aurora 機能を使用して、リージョン内およびリージョン間で HA と DR を確立する方法、そして Aurora DSQL マルチリージョンクラスターが最高レベルの可用性とアプリケーションの耐障害性を実現する仕組みを学習します。

スピーカー

• Tim Stoakes, Sr. Principal Technologist, AWS
• Marc Bowes, Sr. Principal Engineer, AWS

セッション情報

• レベル: 400 - Expert
• セッションタイプ: Breakout session
• トピック: Databases

セッション内容

セッションの構成

本セッションは大きく3つのパートで構成されていました。

1. Setting the stage - レジリエンスの基本概念
2. Amazon Aurora PostgreSQL (APG) & Amazon Aurora MySQL (AMS) - 従来のAuroraのHA/DR機能
3. Amazon Aurora DSQL - 新しい分散SQLデータベースのアーキテクチャ

レジリエンスとは

セッションの冒頭で、レジリエンスの定義が説明されました。

レジリエンス(Resilience) とは、以下の能力を指します

• 依存関係の障害から復旧する能力
• リソースを取得・解放する能力
• 一時的な問題を緩和する能力

可用性とDRの指標

可用性(Availability) は、一定期間内にシステムが利用可能な時間の割合を表します。
例えば、99.99%/年という形で表現されます。

災害復旧(Disaster Recovery) には2つの重要な指標があります

• RTO (Recovery Time Objective): 障害発生から復旧までの最大許容時間(ダウンタイム)
• RPO (Recovery Point Objective): 障害発生後に許容されるデータ損失の最大量(時間で表現)

---

Amazon Aurora PostgreSQL & MySQL

Auroraの特徴

Amazon Aurora PostgreSQLとAurora MySQLは、グローバル規模で比類のない高いパフォーマンスと可用性を提供します。主な特徴は以下の通りです

• パフォーマンスとスケーラビリティ
• 可用性と耐久性
• 高いセキュリティ
• フルマネージド

Q1: DBノードが故障したらどうなる?

単一AZにDBノードがある場合、ノードが故障するとS3へのバックアップからリストアする必要があり、RPOは最大24時間になる可能性があります。

Auroraストレージの耐久性

AuroraはGroverと呼ばれる分散ストレージシステムを使用し、データを3つのAZに6つのコピーで保存します。

これにより、1つのAZ全体と追加の1ノードが障害を起こしても、データは安全に保持されます。

ストレージのDeep Dive

Auroraでは、ログレコードのみをストレージに書き込み、ストレージ側でDBページへの適用を行います。

バックアップとリストア

Auroraは継続的なバックアップをS3に保存し、ポイントインタイムリカバリをサポートしています。

リストア時には、S3のバックアップから指定した時点のデータを復元し、新しいクラスターを作成します。処理中のトランザクションは停止されます。

Multi-AZ可用性

Multi-AZ構成では、複数のAZにリードレプリカを配置することで、RPO = 0、RTO = 約30秒を実現できます。

Q2: パフォーマンスは?

リードレプリカ

Auroraでは最大15個のリードレプリカを作成でき、自動ストレージスケーリングもサポートしています。
リードレプリカは読み取りワークロードの分散に加え、フェイルオーバー時のターゲットとしても機能します。

インスタンススケーリング

フェイルオーバーの優先順位をTierで設定でき、異なるインスタンスサイズの混在も可能です。
Tier 0が最優先でフェイルオーバーターゲットになります。

Q3: 接続はどう管理する?

接続管理のベストプラクティス

• DBインスタンスごと、タイプごとに接続数を制限
• 再接続を避ける(プーリングを活用)

エンドポイント

AuroraはWriterエンドポイントとReaderエンドポイントを提供します。フェイルオーバー時には、DNS lookupと再接続により新しいプライマリに自動的に接続されます。

AWS Advanced Wrapper Drivers

AWS Advanced Wrapper Driversを使用すると、以下の機能が利用できます。

• 66%以上高速なチェンジオーバー
• Enhanced failover
• Read-write splitting
• Blue/Green対応
• その他多数

---

Q4: リージョン障害への対策

リージョン全体が障害を起こした場合、論理レプリケーションだけでは不十分です。
ここでAurora Global Databaseが活躍します。

Aurora Global Database

Aurora Global Databaseは、create-db-cluster --global-cluster-identifierコマンドで作成でき、非同期レプリケーションによりRPO = 1秒未満のレプリケーションラグを実現します。

Global EndpointとFailover

Aurora Global Databaseは、Amazon Route 53と連携したグローバルエンドポイントを提供し、リージョン間のフェイルオーバーを簡素化します。

Global Database Switchover

switchover-global-clusterコマンドにより、マーカーログレコードを挿入してスムーズなスイッチオーバーを実現します。

---

Q5: メンテナンスはどうする?

アップグレード時には以下の課題があります。

• ダウンタイムウィンドウ
• ロールバック
• 調整
• 互換性
• テスト
• パフォーマンス

Managed & Automated Upgrades

Auroraでは以下が自動化されています。

• Managedなマイナーアップグレードとパッチ
• Rolling OSアップグレード

AWS Organizations Upgrade Rollout Policy

AWS Organizationsを使用して、リソースタグに基づくアップグレードのロールアウトポリシーを設定できます。

• first: 最初にアップグレード(dev環境など)
• second: 2番目(QA環境など)
• last: 最後にアップグレード(prod環境)

Aurora Fast Clones

Aurora Fast Clonesを使用すると、本番データベースの完全なコピーを素早く作成し、新しいバージョンでのテストが可能です。

Blue/Green Deployments

Amazon Aurora Blue/Green Deploymentsでは。

• メジャー/マイナーアップグレード
• スキーマ変更
• 静的パラメータ変更
• メンテナンスアップデート

論理レプリケーションを使用してBlue環境とGreen環境を同期します。

Blue/Green Deployments for Global Database

Global Databaseでも Blue/Green Deploymentsが利用可能で、RPO = 0、RTO = 約1分を達成できます。

---

Amazon Aurora DSQL

DSQLのアーキテクチャ

Aurora DSQLは、従来のAuroraとは全く異なるアーキテクチャを持つ分散SQLデータベースです。

主要コンポーネント

• Server: PostgreSQL互換のフロントエンド
• Fork(): クエリプロセッサ
• Backend: 分散バックエンド
• WAL: Write-Ahead Log
• Tables/Indexes: 分散ストレージ

Q0: DSQLのDBノードとは?

DSQLでは、全てのAZにバックエンドが分散配置され、Journalを通じて同期されます。

Q1: DSQLでDBノードが故障したら?

DSQLでは、ノード障害時も他のAZのノードが処理を継続できます。S3にもバックアップが保存されます。

競合のハンドリング

DSQLはOptimistic Concurrency Control(楽観的同時実行制御)を採用しています。
競合が発生した場合は、「error: change conflicts with another transaction, please retry」というエラーが返され、アプリケーション側でリトライを行います。

Q2: パフォーマンスは?

DSQLは水平スケーリングが可能で、各AZに多数のバックエンドノードを配置できます。

Q3: DSQLでの接続管理

DSQLではSession routing layerがあり、接続管理が簡素化されています。

DSQLのスケーリング

1つのAZが障害を起こしても、他のAZのバックエンドが自動的にスケールして処理を継続します。

なお、Aurora DSQLのアーキテクチャについてさらに詳しく知りたい方は、別セッション「DAT439: Deep dive into Amazon Aurora DSQL and its architecture」がおすすめです。

Q4: DSQLのリージョン障害対策

Aurora DSQLのマルチリージョンクラスターでは、Region A、Region B、Region C(Witnessリージョン)を使用して、リージョン障害に対応します。

DSQLのマルチリージョン構成では、全てのリージョンでActive-Activeな読み書きが可能です。

---

全体のまとめ (Key Takeaways)

セッションの最後に、4つの重要なポイントがまとめられました:

カテゴリ	ポイント
Aurora Innovations	アーキテクチャがすぐに使えるレジリエンスを提供。3 AZの耐久性
Scaling	あらゆるスケールで動作。プロビジョンドまたはオートスケール
Multi-Region	災害復旧とグローバル可用性
Maintenance	自動化されたセキュリティとマイナーバージョンアップグレード

---

さいごに

本セッションでは、Amazon AuroraのHA/DR機能について、基本概念から実践的な設計パターンまで幅広く解説されました。

従来のAurora PostgreSQL/MySQLと新しいAurora DSQLでは、アーキテクチャが大きく異なりますが、どちらもそれぞれのユースケースに応じた高い可用性とレジリエンスを実現できることがわかりました。

グローバルに展開するアプリケーションの設計において、本セッションで紹介されたパターンは非常に参考になると思います。