RDS Multi-AZのメリットを正しく理解する — 高可用性とフェイルオーバーの仕組み

RDS Multi-AZを有効にしたのに「パフォーマンスが上がるはず」と期待して、後から「何も変わっていない」と気づく — これは本番環境でよく見かける誤解だ。Multi-AZはパフォーマンス機能ではなく、高可用性とフェイルオーバーのための機能であり、その設計思想を正しく理解しないと、コストと効果のバランスを見誤る。

TL;DR — RDS Multi-AZの要点

観点Multi-AZの動作
目的高可用性・自動フェイルオーバー
スタンバイインスタンス読み取り/書き込みトラフィックを受け付けない（通常時）
レプリケーション同期レプリケーション（プライマリ → スタンバイ）
フェイルオーバー所要時間通常1〜2分（DNSエンドポイント切り替え）
読み取りスケールアウト対象外（Read Replicaが別途必要）
コストシングルAZ比でインスタンス料金が約2倍

RDS Multi-AZの仕組み — 有効化する前に理解すべきこと

Multi-AZを有効にすると、RDSはプライマリインスタンスとは別のアベイラビリティゾーンにスタンバイインスタンスを自動的にプロビジョニングする。プライマリへの書き込みはすべて同期的にスタンバイへレプリケートされる。つまり、プライマリがコミットを返す前にスタンバイへの書き込みも完了していることが保証される。

この同期レプリケーションが、Multi-AZがパフォーマンス向上に寄与しない理由でもある。書き込みレイテンシはスタンバイへの往復時間分だけ増加する可能性がある。アプリケーションからは単一のDNSエンドポイントしか見えず、スタンバイインスタンスへの直接アクセスは通常時は不可能だ。

graph TD App["アプリケーション"] -->|"単一DNSエンドポイント"| Primary["プライマリインスタンス (AZ-A)"] Primary -->|"同期レプリケーション (コミット前に完了)"| Standby["スタンバイインスタンス (AZ-B)"] Primary -->|"読み書き処理"| App Standby -->|"通常時: トラフィックなし"| NoAccess["アプリからアクセス不可"] Primary -->|"障害発生"| Failover["自動フェイルオーバー"] Failover -->|"DNSエンドポイント切り替え"| Standby Standby -->|"フェイルオーバー後: 新プライマリ"| App style NoAccess fill:#f5f5f5,stroke:#999,color:#999 style Failover fill:#ff9900,stroke:#cc7700,color:#fff
  1. アプリケーションはRDSが提供する単一のDNSエンドポイントに接続する。
  2. プライマリインスタンス（AZ-A）が読み書きを処理し、コミット前にスタンバイへ同期レプリケーションを行う。
  3. スタンバイインスタンス（AZ-B）は通常時、アプリケーションからのトラフィックを一切受け付けない。
  4. プライマリに障害が発生すると、RDSはDNSエンドポイントをスタンバイへ自動的に切り替える（フェイルオーバー）。
  5. アプリケーションは同じエンドポイントを使い続けるだけでよい。接続の再確立は必要だが、手動操作は不要。

Multi-AZが提供する具体的なメリット

1. 自動フェイルオーバーによるダウンタイム最小化

プライマリインスタンスに以下のような障害が発生した場合、RDSは自動的にスタンバイへフェイルオーバーする。

  • インスタンスホストの障害
  • AZ全体の障害
  • ネットワーク障害
  • OSパッチ適用などのメンテナンス操作

フェイルオーバーはDNSエンドポイントの切り替えで実現される。アプリケーション側はエンドポイントを変更する必要はないが、既存のデータベース接続は切断されるため、接続プールの再接続ロジックが実装されていることが前提となる。

2. 計画メンテナンス時のダウンタイム短縮

OSパッチやDBエンジンのマイナーバージョンアップグレードなど、AWSが管理するメンテナンスウィンドウ中の操作では、Multi-AZが有効な場合にスタンバイ側から先にアップグレードが適用される。その後フェイルオーバーが実行され、旧プライマリがアップグレードされる。これによりメンテナンス中のダウンタイムを大幅に短縮できる。

3. データ耐久性の向上

同期レプリケーションにより、プライマリがコミットを返した時点でスタンバイにもデータが存在することが保証される。シングルAZ構成と比較して、ストレージ障害によるデータ損失リスクが実質的に低減される。

Multi-AZがパフォーマンスを向上させない理由 — よくある誤解

「スタンバイがあるなら読み取りを分散できるはず」という発想は自然だが、Multi-AZのスタンバイはそのように設計されていない。

Multi-AZのスタンバイは、空港のゲート待機機のようなものだ。乗客（クエリ）を乗せることはなく、プライマリが離陸できなくなったときだけ即座に代替として動く。読み取りスケールアウトが必要なら、Read Replicaという別の「運航便」を追加する必要がある。

読み取りトラフィックをスケールアウトしたい場合は、RDS Read Replicaを使用する。Read Replicaは非同期レプリケーションを使用し、読み取り専用エンドポイントをアプリケーションに公開できる。ただしRead ReplicaはMulti-AZとは独立した機能であり、フェイルオーバーの対象にはならない点に注意が必要だ。

graph LR App["アプリケーション"] subgraph MultiAZ ["Multi-AZ構成 — 高可用性"] Primary2["プライマリ (読み書き)"] Standby2["スタンバイ (フェイルオーバー専用)"] Primary2 -->|"同期レプリケーション"| Standby2 end subgraph ReadReplica ["Read Replica構成 — 読み取りスケールアウト"] Primary3["プライマリ (読み書き)"] Replica1["レプリカ1 (読み取り専用)"] Replica2["レプリカ2 (読み取り専用)"] Primary3 -->|"非同期レプリケーション"| Replica1 Primary3 -->|"非同期レプリケーション"| Replica2 end App -->|"書き込み + 読み取り"| Primary2 App -->|"書き込み"| Primary3 App -->|"読み取り分散"| Replica1 App -->|"読み取り分散"| Replica2 style Standby2 fill:#f0f0f0,stroke:#aaa,color:#666
  1. Multi-AZ構成では、スタンバイへのアクセスパスはアプリケーションに公開されない。
  2. Read Replica構成では、レプリカへの読み取り専用エンドポイントがアプリケーションに公開される。
  3. 両者は組み合わせて使用可能。Multi-AZで高可用性を確保しつつ、Read Replicaで読み取りスケールアウトを実現できる。

実際の障害で学んだこと — 誤診から正しい理解へ

あるケースで、Multi-AZ有効化後に「書き込みレイテンシが増加した」という報告があった。最初の仮説はネットワーク設定の問題だった。CloudWatchのメトリクスを確認すると、WriteLatencyが有効化前と比較して微増していた。

調査を進めると、原因はMulti-AZの同期レプリケーション自体だった。プライマリとスタンバイが異なるAZに配置されているため、コミット確認の往復時間が加算される。これはバグでも設定ミスでもなく、Multi-AZの設計上の動作だ。書き込みレイテンシの微増を許容した上で高可用性を得るか、シングルAZのままパフォーマンスを優先するか — これはビジネス要件の判断であり、技術的な問題ではない。

この経験から得た教訓: Multi-AZを有効化する前に、WriteLatencyのベースラインを記録しておくこと。有効化後の変化を定量的に把握できなければ、正常な動作と問題を区別できない。

フェイルオーバー状態の確認コマンド

現在のMulti-AZ構成とフェイルオーバー状態を確認するには以下のCLIを使用する。

aws rds describe-db-instances \
  --db-instance-identifier your-db-instance-id \
  --query 'DBInstances[0].{MultiAZ:MultiAZ,SecondaryAvailabilityZone:SecondaryAvailabilityZone,DBInstanceStatus:DBInstanceStatus,AvailabilityZone:AvailabilityZone}' \
  --output table \
  --region us-east-1

出力例で確認すべき項目:

  • MultiAZ: trueであることを確認
  • AvailabilityZone: プライマリのAZ
  • SecondaryAvailabilityZone: スタンバイのAZ（プライマリと異なるAZであることを確認）
  • DBInstanceStatus: availableであることを確認（failing-overの場合はフェイルオーバー中）

フェイルオーバーイベントの履歴確認

過去のフェイルオーバーイベントを確認するには、RDSイベントログを参照する。

aws rds describe-events \
  --source-identifier your-db-instance-id \
  --source-type db-instance \
  --duration 10080 \
  --region us-east-1

--durationは分単位で指定する。10080は過去7日間を意味する。フェイルオーバーが発生した場合、イベントメッセージに'Multi-AZ instance failover'が含まれる。

CloudWatchでWriteLatencyを監視する

Multi-AZ有効化前後のレイテンシ変化を定量的に把握するために、以下のコマンドでメトリクスを取得する。

aws cloudwatch get-metric-statistics \
  --namespace AWS/RDS \
  --metric-name WriteLatency \
  --dimensions Name=DBInstanceIdentifier,Value=your-db-instance-id \
  --start-time 2024-01-01T00:00:00Z \
  --end-time 2024-01-02T00:00:00Z \
  --period 300 \
  --statistics Average \
  --region us-east-1

Multi-AZを有効にすべきケースと不要なケース

有効化を強く推奨するケース

  • 本番環境のデータベースで、計画外ダウンタイムが許容できない
  • RTO（目標復旧時間）が数分以内であることが要件
  • AWSによる計画メンテナンス中のダウンタイムを最小化したい
  • コンプライアンス要件として高可用性構成が求められている

Multi-AZだけでは解決しないケース

  • 読み取りスループットの向上 → Read Replicaを追加する
  • 書き込みスループットの向上 → インスタンスクラスのスケールアップ、またはAurora Serverlessの検討
  • クロスリージョン災害対策 → Multi-AZはリージョン内の複数AZに限定される。クロスリージョンDRにはRead Replicaのクロスリージョン構成やAurora Global Databaseを検討する

Multi-AZはリージョン内の障害に対する保護であり、リージョン全体の障害には対応しない。この境界を明確に理解しておくことが設計上重要だ。

RDS Multi-AZのメリットまとめと次のステップ

RDS Multi-AZの本質は高可用性とフェイルオーバーの自動化であり、パフォーマンス向上ではない。スタンバイインスタンスは通常時に読み取りトラフィックを処理せず、プライマリ障害時のDNS切り替えによる自動復旧のために存在する。書き込みレイテンシが微増する可能性があることも設計上の特性として把握しておく必要がある。

読み取りスケールアウトが目的であればRead Replicaを、クロスリージョンDRが目的であればAurora Global Databaseをそれぞれ検討すること。Multi-AZはその目的に特化した機能として、本番データベースの基本構成として位置づけるのが適切だ。

用語集

用語説明
Multi-AZRDSが異なるアベイラビリティゾーンにスタンバイインスタンスを自動配置し、障害時に自動フェイルオーバーを行う高可用性機能
同期レプリケーションプライマリがコミットを返す前にスタンバイへのデータ書き込みが完了することを保証するレプリケーション方式
フェイルオーバープライマリインスタンスの障害時にスタンバイインスタンスへ自動的に切り替わる動作。DNSエンドポイントの更新で実現される
Read Replica非同期レプリケーションを使用した読み取り専用のレプリカインスタンス。読み取りスケールアウトに使用する
RTO（目標復旧時間）障害発生からシステムが復旧するまでの目標時間。Multi-AZはRTOを数分以内に抑えることを目的とする

Related Posts

コメント

コメントを投稿

このブログの人気の投稿

EC2 SSH接続タイムアウトの原因と修正方法 — セキュリティグループのインバウンドルール完全ガイド

新しいEC2インスタンスを起動してSSH接続を試みたとき、 ssh: connect to host xx.xx.xx.xx port 22: Connection timed out というエラーで止まった経験は多くのエンジニアにある。アプリケーションのエラーではなく、パケットがインスタンスに届いていないことを示すタイムアウトだ。原因の大半はセキュリティグループのインバウンドルール設定にあるが、それだけで解決しないケースも存在する。 TL;DR — EC2 SSHタイムアウトの主な原因と対処 原因レイヤー 確認項目 修正方向 セキュリティグループ ポート22のインバウンドルールが存在するか TCP 22をソースIPに対して許可 ネットワークACL サブネットレベルでポート22がブロックされていないか インバウンド/アウトバウンド両方のルールを確認 パブリックIPアドレス インスタンスにパブリックIPが割り当てられているか ElasticIPの関連付けまたはパブリックIP自動割り当ての有効化 インターネットゲートウェイ VPCにIGWがアタッチされているか IGWを作成してVPCにアタッチ ルートテーブル サブネットのルートテーブルに0.0.0.0/0 → IGWのルートがあるか デフォルトルートをIGWに向ける EC2 SSH接続の仕組み — パケットが届くまでの経路 SSHタイムアウトを正確に診断するには、クライアントのパケットがEC2インスタンスに到達するまでに通過するレイヤーを理解する必要がある。セキュリティグループだけを見て終わりにすると、別のレイヤーでブロックされているケースを見逃す。 graph LR Client["クライアント ローカルマシン"] -->|"TCP SYN port 22"| IGW["インターネット ゲートウェイ (IGW)"] IGW --> RT["ルートテーブル 0.0.0.0/0 → IGW"] RT --> ...
続きを読む

S3パブリックアクセス拒否の原因と解決策：バケットレベルの「Block Public Access」が優先される仕組み

S3に画像をアップロードしてオブジェクトACLを「public-read」に設定したのに、URLにアクセスすると「Access Denied」が返ってくる。オブジェクト単体の設定は正しいはずなのに、なぜ拒否されるのか——この問題の原因はほぼ確実に、バケットレベルの「Block Public Access」設定にある。オブジェクトACLより上位のレイヤーが存在することを知らないと、何度設定を変えても解決しない。 TL;DR：S3パブリックアクセス拒否の原因まとめ 確認レイヤー 設定項目 影響範囲 アカウントレベル S3 Block Public Access（アカウント全体） 全バケットに適用 バケットレベル S3 Block Public Access（バケット個別） そのバケット内の全オブジェクト バケットポリシー Principal: * を許可するポリシーの有無 ポリシーで指定したリソース オブジェクトACL public-read ACL 個別オブジェクト 結論： オブジェクトACLを「public-read」にしても、バケットまたはアカウントレベルの「Block Public Access」が有効な場合、そのACLは無効化される。上位レイヤーの設定が下位を上書きする構造になっている。 S3パブリックアクセス制御の仕組み：なぜオブジェクトACLだけでは不十分か S3のアクセス制御は複数のレイヤーが重なって機能する。オブジェクトACLはその中で最も下位のレイヤーに位置する。AWSは2018年以降、誤ったパブリック公開によるデータ漏洩を防ぐため「Block Public Access」という上位の制御機構を導入した。この設定が有効な場合、オブジェクトACLやバケットポリシーで「public」を許可しようとしても、Block Public Accessがそれを遮断する。 Block Public Accessには4つの独立した設定項目がある。それぞれが異なるシナリオをカバーしており、全部オフにしないとパブリックアクセスが通らないケースもある。 graph TD A[...
続きを読む

EC2インスタンスIDをメタデータから取得する方法 — IMDSv2が安全な理由

サーバー上で動作するスクリプトから自分のインスタンスIDを取得したい場面は多い。デプロイスクリプト、ログ集約、Auto Scalingグループのインベントリ管理など、用途は様々だ。ただし、EC2インスタンスメタデータサービス（IMDS）には2つのバージョンが存在し、 IMDSv1とIMDSv2の選択はセキュリティ上の重大な差異 を生む。本番環境でIMDSv1を使い続けることは、SSRF（Server-Side Request Forgery）攻撃の踏み台になるリスクを放置することと同義だ。 TL;DR — IMDSv1 vs IMDSv2 早見表 観点 IMDSv1 IMDSv2 認証方式 なし（直接GETのみ） セッショントークン必須（PUT → GET） SSRF耐性 なし あり（PUT不可なSSRFはトークン取得不可） TTL制御 なし X-aws-ec2-metadata-token-ttl-secondsで指定 デフォルト状態 新規インスタンスでも有効（設定次第） IMDSv2-onlyに変更可能 推奨度 非推奨 AWS公式推奨 IMDSの仕組み — なぜインスタンス内からだけ到達できるのか EC2インスタンスメタデータサービスは、リンクローカルアドレス 169.254.169.254 で提供される。このアドレスはRFC 3927で定義されたリンクローカル範囲であり、インスタンスのネットワークインターフェース外には到達できない。つまり、インターネット経由や他のインスタンスから直接アクセスすることは原理的に不可能だ。 ただし、 SSRF脆弱性があるアプリケーションが動作している場合は話が変わる 。攻撃者がアプリケーションを経由して http://169.254.169.254/latest/meta-data/iam/security-credentials/ へリクエストを誘導できれば、インスタンスにアタッチされたIAMロールの一時クレデンシャルを盗める。IMDSv1はこのシナリオに対して無防備だ。 graph TD subgraph v1[...
続きを読む