概要
本ドキュメントでは、AWS RDS Multi-AZ構成におけるフェイルオーバー検証の考え方と、同一AZ/別AZからの検証における違いについて解説します。
前提環境
RDS Multi-AZ:
├─ Primary: ap-northeast-1c
├─ Standby: ap-northeast-1a
└─ Endpoint: example.ap-northeast-1.rds.amazonaws.com
EC2:
├─ Instance 1: ap-northeast-1a
└─ Instance 2: ap-northeast-1c
RDSエンドポイントの接続メカニズム
通常時の接続動作
EC2 (1a) → DNS解決 → Primary RDS (1c) のプライベートIP
EC2 (1c) → DNS解決 → Primary RDS (1c) のプライベートIP
重要ポイント:
- エンドポイントは常に現在のPrimaryのIPアドレスを返す
- EC2がどのAZにいても、同じPrimary (1c) に接続される
- AZを自動で選択する機能は存在しない
通信特性とコスト
| 接続元 | 接続先 | レイテンシ | データ転送料金 |
|---|---|---|---|
| EC2 (1c) | RDS Primary (1c) | <1ms | 無料 |
| EC2 (1a) | RDS Primary (1c) | 1-2ms | $0.01/GB |
フェイルオーバー後の接続動作
通常時:
EC2 (1a) → Primary (1c) [クロスAZ: 1-2ms、有料]
EC2 (1c) → Primary (1c) [同一AZ: <1ms、無料]
フェイルオーバー後:
EC2 (1a) → Primary (1a) [同一AZ: <1ms、無料] ← パフォーマンス改善
EC2 (1c) → Primary (1a) [クロスAZ: 1-2ms、有料] ← パフォーマンス劣化
フェイルオーバー検証の方針
推奨アプローチ
両方のAZから同時に検証すること
同一AZ (1c) からの検証で観測できる事象
観測項目:
✓ 通常時の最適なパフォーマンス（ベースライン）
✓ フェイルオーバー後のパフォーマンス劣化
✓ Primary側の直接的な影響
パフォーマンス変化:
- 通常時: <1ms（最速）
- フェイルオーバー後: 1-2ms（クロスAZに変化）
別AZ (1a) からの検証で観測できる事象
観測項目:
✓ クロスAZ通信時のパフォーマンス（ワーストケース）
✓ フェイルオーバー後のパフォーマンス改善
✓ 遠隔AZからのアクセスシナリオ
パフォーマンス変化:
- 通常時: 1-2ms（クロスAZ）
- フェイルオーバー後: <1ms（同一AZに変化して改善）
検証における確認項目
1. ダウンタイムの測定
- 想定ダウンタイム: 30-120秒
-
確認事項:
- 両AZで同じタイミングで切断が発生するか
- 復旧のタイミングに差異はないか
- ダウンタイムの長さが想定内か
2. DNS切り替えタイミング
フェイルオーバー前: 10.0.2.100 (ap-northeast-1c)
フェイルオーバー後: 10.0.1.100 (ap-northeast-1a)
- DNS TTL: 通常5秒
-
確認事項:
- 両AZで同じタイミングでIPアドレスが変わるか
- DNSキャッシュの影響がないか
3. レイテンシの変化
| 時点 | EC2 (1a) | EC2 (1c) |
|---|---|---|
| フェイルオーバー前 | 1-2ms (クロスAZ) | <1ms (同一AZ) |
| フェイルオーバー後 | <1ms (同一AZ) ⬇️ | 1-2ms (クロスAZ) ⬆️ |
重要な洞察:
- フェイルオーバーは単なる切り替えではなく、パフォーマンス特性の反転を伴う
- 片方のAZにとっての「改善」は、もう片方にとっての「劣化」となる
- この相反する影響を理解するには、両AZからの観測が不可欠
4. アプリケーション層への影響
- 接続プールの再接続ロジックの動作確認
- リトライ機構の機能確認
- タイムアウト設定の妥当性検証
- 負荷分散されたアプリケーションサーバー全体での影響範囲把握
片側のみの検証における問題点
ケース1: 同一AZ (1c) からのみ検証
観測結果:
✗ フェイルオーバー後にパフォーマンスが悪化した
見落とす情報:
- 別AZ (1a) ではパフォーマンスが改善している
- 全体としてのトレードオフが見えない
- どのAZにアプリを配置すべきか判断できない
ケース2: 別AZ (1a) からのみ検証
観測結果:
✗ フェイルオーバー後にパフォーマンスが改善した
見落とす情報:
- 同一AZ (1c) ではパフォーマンスが劣化している
- 最適なパフォーマンスのベースラインが分からない
- フェイルオーバーの本質的な影響が見えない
両AZから検証することで得られる全体像
[1a からの視点]
通常時: 遅い（クロスAZ） → フェイルオーバー後: 速い（同一AZ）
「フェイルオーバーでパフォーマンスが向上した！」
[1c からの視点]
通常時: 速い（同一AZ） → フェイルオーバー後: 遅い（クロスAZ）
「フェイルオーバーでパフォーマンスが低下した！」
[統合された理解]
✓ フェイルオーバーはゼロサムゲーム
✓ Primaryの位置によってパフォーマンス特性が変わる
✓ アプリケーションサーバーの配置戦略が重要
✓ どのAZに重みを置くべきか判断できる
設計への示唆
アプリケーションサーバー配置戦略
パターンA: アプリサーバーを 1c に集中
通常時: 最高のパフォーマンス
フェイルオーバー時: 全体的にパフォーマンス低下
適用ケース: 読み取り負荷が高いシステム
パターンB: アプリサーバーを 1a と 1c に均等配置
通常時: 平均的なパフォーマンス
フェイルオーバー時: 影響が均等に分散
適用ケース: 高可用性を重視するシステム
パターンC: アプリサーバーを 1a に集中
通常時: やや遅いが安定
フェイルオーバー時: パフォーマンス向上
適用ケース: フェイルオーバー後の性能を重視するシステム
コスト最適化の観点
前提条件: 月間 10TB のデータ転送
| 配置パターン | 通常時コスト | フェイルオーバー後コスト |
|---|---|---|
| アプリ: 1a, Primary: 1c | $100/月 | 無料 |
| アプリ: 1c, Primary: 1c | 無料 | $100/月 |
| アプリ: 均等配置, Primary: 1c | $50/月 | $50/月 |
SLA設計への影響
両AZからの検証データに基づくSLA定義:
- 通常時のSLA: 同一AZ配置時の性能で定義
- 障害時のSLA: クロスAZ配置時の性能で定義
- ダウンタイム: 30-120秒を考慮したSLA設計
- パフォーマンス劣化: 最大2倍のレイテンシ増加を想定
ネットワーク最適化に関する誤解
よくある誤解
✗ 誤解:
「EC2が1aにあれば、RDSも自動的に1aのスタンバイを見に行く」
✓ 実際の動作:
「RDSエンドポイントは常にPrimaryを指す」
「EC2の位置は接続先の選択に影響しない」
正しい理解
- RDSには接続元のAZを考慮する機能は存在しない
- エンドポイントは単純にPrimaryのIPを返すだけ
- 最適化は設計時にPrimaryとEC2を同じAZに配置することで実現する
まとめ
検証のベストプラクティス
- 両方のAZから同時に検証すること
- フェイルオーバー前後でのレイテンシ変化を両面から観測
- ダウンタイム（30-120秒）を正確に計測
- パフォーマンス特性の反転を理解する
両AZ検証の重要性
- 完全な影響範囲の把握: 片方だけでは半分しか見えない
- トレードオフの理解: 改善と劣化の両面を観測
- 設計判断の根拠: データに基づいた配置戦略の決定
- 本番環境の再現: 実際のマルチAZ構成を正確にシミュレート
本質的な理解
Multi-AZ構成のフェイルオーバー検証は、単なる「動作確認」ではありません。
システム全体のパフォーマンス特性とコスト構造を理解するための重要なプロセスです。
両AZから検証することで初めて、RDS Multi-AZの本質的な動作とトレードオフが見えてきます。