📌 はじめに
ミッションクリティカルなデータベース基盤において、「ダウンタイムをいかに極小化するか」は可用性設計の最重要課題です。
従来の Amazon RDS for MySQL（Multi-AZ） では、フェイルオーバー時に 30〜60 秒以上のダウンタイムが発生し、厳格な SLA を満たせないケースがあります。今回は、このフェイルオーバー時間を 20秒未満（< 20s） に圧縮するための標準設計パターン**「Amazon Aurora MySQL ＋ リードレプリカ ＋ Amazon RDS Proxy」**の組み合わせについて整理します。
1. 業務シナリオと従来のボトルネック分析
現行の構成と課題
- 現行基盤: Amazon RDS for MySQL（Multi-AZ 構成）。
- 課題: 障害テストを実施したところ、フェイルオーバーに伴うアプリケーションの中断時間が 約 40 秒 発生した。
従来の RDS Multi-AZ が遅い根本原因
従来の RDS Multi-AZ は、ブロックレベルの同期物理レプリケーション（EBS ボリュームのミラーリング）を採用しています。主ノード障害時には以下のステップを順次通過する必要があります。
- 主インスタンスの障害検知
- スタンバイインスタンスのマスター昇格処理（未コミットトランザクションのロールフォワード/バック）
- Route 53 CNAME レコードの切り替え（DNS レコード更新）
- クライアント側の DNS キャッシュ失効待ち ＆ コネクションプールの再接続
この一連のオーバーヘッドにより、どんなにチューニングしても通常 30〜60 秒以上（場合によっては 120 秒）の中断が発生します。
業務改善ゴール
- 障害発生時のフェイルオーバーに伴う中断・復旧時間を 20 秒未満（RTO < 20s） に抑え込むこと。
2. アーキテクチャトポロジー（超高速フェイルオーバー構成）
[ アプリケーション接続プール ]
│
│ クライアント側の持続的コネクション (DNS再解決の遅延を完全排除)
▼
┌────────────────────────────────────────────────────────┐
│ Amazon RDS Proxy │
│ - フロントエンド接続をプールし、セッション切断を防止 │
│ - Aurora クラスターの状態をリアルタイム感知し、 │
│ プロキシレイヤーで新マスターへミリ秒級ルーティング │
│ - 全体のフェイルオーバー時間を最大 66% 短縮 │
└──────────────────────────┬─────────────────────────────┘
│ 内部切り替え（秒級）
▼
┌────────────────────────────────────────────────────────┐
│ Amazon Aurora MySQL クラスター │
│ │
│ ┌────────────────────────┐ 秒級で昇格 ┌────────────────────────┐
│ │ ライター (Writer) │ ◄─────────── │ Aurora レプリカ (Reader)│
│ │ 障害発生 │ │ 新しいライターへ自動昇格│
│ └───────────┬────────────┘ └───────────┬────────────┘
│ │ │
│ ▼ ▼
│ ┌────────────────────────────────────────────────────────┐
│ │ Aurora 共有分散ストレージ (3 AZ × 6 プレースメント) │
│ │ (ストレージの再同期・再生処理が不要、即時マウント可能) │
└────────────────────────────────────────────────────────┘
3. なぜこの3要素なのか？
目標である「20秒未満の復旧」を達成するには、ストレージ層・インスタンス層・ネットワーク/クライアント層 のボトルネックを同時に解消する必要があります。
① インフラ底座の近代化：Amazon Aurora MySQL への移行
- コンピュートとストレージの完全分離:
- 従来の RDS ではストレージがノードに直結していましたが、Aurora では 3 つのアベイラビリティゾーン（AZ）に 6 つのコピーを保持する共有分散仮想ストレージを採用しています。
- 障害発生時にストレージブロックの同期やクラッシュリカバリ（REDOログの大量再生）を待つ必要がないため、切り替え時間を劇的に短縮できます。
② ホットスタンバイの常駐：別 AZ への Aurora レプリカ配置
- メモリ常駐型の即時昇格:
- Aurora の Multi-AZ 構成は、別 AZ に Aurora リードレプリカ（Reader） を配置することで機能します。
- ライター（Writer）障害時、稼働中の Aurora レプリカが即座に新しいライターへ昇格します。ストレージ層を共有しているため、昇格処理自体は通常 10〜15 秒程度 で完了します。
③ クライアント側の DNS 待機時間をゼロ化：Amazon RDS Proxy の導入
-
最大のボトルネックは「クライアントの DNS キャッシュ」:
-
データベース本体が 10 秒で昇格しても、アプリケーション側の JVM や OS が保持する DNS キャッシュ、あるいはコネクションプールの切断・再接続の再試行によって、実質的なダウンタイムが 30〜40 秒以上に引き延ばされてしまいます。
-
RDS Proxy による透過的ルーティング:
-
アプリケーションは RDS Proxy のエンドポイントとのみ持続的接続（長接続）を維持します。
-
RDS Proxy は Aurora クラスター内部のトポロジー変更イベントをネイティブに検知するため、DNS の伝播を待つことなく、プロキシレイヤーで通信トラフィックを昇格した新ライターへ数秒以内に自動ルーティングします。
-
これにより、フェイルオーバーに伴う中断時間を 最大 66% 削減 し、全体の中断時間を 数秒〜十数秒（確実に 20 秒以下） に収めることが可能になります。
4. Terraform による構成コード例 (Aurora ＋ RDS Proxy)
# 1. Aurora MySQL クラスター定義 (Multi-AZ)
resource "aws_rds_cluster" "aurora_cluster" {
cluster_identifier = "aurora-ha-cluster"
engine = "aurora-mysql"
engine_version = "8.0.mysql_aurora.3.05.2"
database_name = "appdb"
master_username = "admin"
master_password = "SecurePassw0rd123!"
backup_retention_period = 7
preferred_backup_window = "02:00-03:00"
skip_final_snapshot = true
}
# 2. Writer インスタンス (AZ-a)
resource "aws_rds_cluster_instance" "writer_instance" {
identifier = "aurora-instance-writer"
cluster_identifier = aws_rds_cluster.aurora_cluster.id
instance_class = "db.r6g.xlarge"
engine = aws_rds_cluster.aurora_cluster.engine
engine_version = aws_rds_cluster.aurora_cluster.engine_version
availability_zone = "ap-northeast-1a"
}
# 3. Reader レプリカ (AZ-c / 高可用性フェイルオーバー先)
resource "aws_rds_cluster_instance" "reader_instance" {
identifier = "aurora-instance-reader"
cluster_identifier = aws_rds_cluster.aurora_cluster.id
instance_class = "db.r6g.xlarge"
engine = aws_rds_cluster.aurora_cluster.engine
engine_version = aws_rds_cluster.aurora_cluster.engine_version
availability_zone = "ap-northeast-1c"
promotion_tier = 0 # 優先的にマスターへ昇格させる設定
}
# 4. Amazon RDS Proxy 定義
resource "aws_db_proxy" "aurora_proxy" {
name = "aurora-ha-proxy"
debug_logging = false
engine_family = "MYSQL"
idle_client_timeout = 1800
require_tls = true
role_arn = aws_iam_role.proxy_iam_role.arn
vpc_subnet_ids = [aws_subnet.private_a.id, aws_subnet.private_c.id]
vpc_security_group_ids = [aws_security_group.proxy_sg.id]
auth {
auth_scheme = "SECRETS"
iam_auth = "DISABLED"
secret_arn = aws_secretsmanager_secret.db_secret.arn
}
}
resource "aws_db_proxy_default_target_group" "proxy_target_group" {
db_proxy_name = aws_db_proxy.aurora_proxy.name
connection_pool_config {
max_connections_percent = 90
max_idle_connections_percent = 50
}
}
resource "aws_db_proxy_target" "proxy_target" {
db_proxy_name = aws_db_proxy.aurora_proxy.name
target_group_name = aws_db_proxy_default_target_group.proxy_target_group.name
db_cluster_identifier = aws_rds_cluster.aurora_cluster.id
}
5. 設計比較まとめ
| 検討軸 | 従来の RDS for MySQL (Multi-AZ) | 最適化後：Aurora MySQL ＋ RDS Proxy |
|---|---|---|
| ストレージ構造 | EBS ボリューム単位の物理ミラー同期 | 3 AZ 分散共有ストレージ（クラッシュリカバリ不要） |
| フェイルオーバー時間 | 30〜60 秒以上（DNS 切替待ちが発生） | 20 秒未満（数秒〜15 秒程度） |
| クライアント影響 | コネクション切断 ＋ DNS キャッシュ再取得 | プロキシが接続を維持し、背後で透過的に新ライターへ接続 |
| スタンバイ機の活用 | 完全待機系（読取クエリも不可、リソース遊休） | 通常時はリードレプリカとして参照負荷分散に活用可能 |
6. まとめ
- Aurora への切り替え: ストレージの同期遅延とログ再生オーバーヘッドを排除し、データベース層の昇格速度を最大化する。
- Aurora レプリカの常駐: 別 AZ に昇格優先度（Promotion Tier）を設定したレプリカを配置し、15 秒以内のインスタンス昇格を担保する。
- RDS Proxy の介在: クライアント側の DNS キャッシュ遅延を完全に無効化し、切り替え時間を最大 66% 短縮して「20 秒未満」の復旧 SLA を確実に達成する。