マルチ AZ と自動バックアップ

Multi-AZ は、同じ Region 内の別の Availability Zone に同期スタンバイレプリカを自動的にプロビジョニングする、RDS の高可用性機能です。AWS がレプリケーションを透過的に管理するため、単一の DNS エンドポイントに接続すれば、RDS がプライマリにトラフィックをルーティングします。

ハードウェア、ネットワーク、OS の問題によってプライマリインスタンスに障害が発生すると、RDS は約 60～120 秒でスタンバイへの自動フェイルオーバーを実行します。アプリケーションは同じ DNS エンドポイントを使用して再接続します。このエンドポイントはスタンバイの IP アドレスを解決するようになります。

RDS インスタンスの作成時に Multi-AZ を有効にすることも、既存のインスタンスを変更して有効にすることもできます。稼働中のインスタンスで有効にすると、AWS はプライマリのスナップショットを取得し、2 つ目の AZ に復元してから、エンジン固有のネイティブレプリケーションを使用して同期します。この処理によってプライマリで短時間の I/O 停止が発生する可能性があるため、トラフィックの少ない時間帯にスケジュールするか、メンテナンスウィンドウのタイミングで実施してください。

Multi-AZ は MySQL、PostgreSQL、MariaDB、Oracle、SQL Server を含むすべての RDS エンジンでサポートされており、アプリケーションレベルの変更は必要ありません。

フェイルオーバーが発生すると、RDS は DB エンドポイントの DNS CNAME を更新し、約 60 秒以内にスタンバイを指すようにします。アプリケーションは TCP 接続の切断を検知した後、再接続する必要があります。再接続の遅延を最小限に抑えるには、次の方法を使用します。

• 短い DNS TTLを使用します (通常、RDS によってすでに 5 秒に設定されています)
• 接続ロジックに指数バックオフとリトライを実装します
• 自動的に再接続する RDS Proxy などの接続プーリングツールを使用します

フェイルオーバーは、メンテナンスやインスタンスクラスの変更のために手動でトリガーすることもできます。Multi-AZ が有効になっていれば、ダウンタイムをほぼゼロにしたアップグレードが可能です。

試験でよく混同されるのが、可用性のためのMulti-AZと、スケーラビリティのためのRead Replicaの違いです。主な違いは次のとおりです。

• Multi-AZ スタンバイ: 同期レプリケーション、読み取りトラフィックは処理しない、自動フェイルオーバー、同じ Region
• Read Replica: 非同期レプリケーション、読み取りトラフィックを処理、自動フェイルオーバーなし、リージョン間に配置可能

Multi-AZ ではスタンバイに対してクエリを実行できないため、読み取りパフォーマンスは向上しません。可用性を高めながら読み取りもスケールするには、プライマリで Multi-AZ を使用し、別途 Read Replica を追加してください。

RDS は毎日、データベース全体のスナップショットを自動的に作成し、5 分ごとにトランザクションログを取得します。これらを組み合わせることで、バックアップ保持期間内の任意の時点までのポイントインタイムリカバリ (PITR)が可能になります。その期間内の任意の時点の状態にデータベースを復元できます。

自動バックアップはデフォルトで有効になっており、保持期間は1～35 日に設定できます。保持期間を 0 にすると、自動バックアップ (および PITR) が無効になります。バックアップウィンドウは、指定することも、AWS にオフピーク時間帯で自動選択させることもできる 30 分間の期間です。

バックアップウィンドウとは、毎日のスナップショットが取得される時間帯です。この時間帯には、Single-AZ デプロイでストレージ I/O が一時的に停止する場合があります。Multi-AZ デプロイではスタンバイからスナップショットを取得するため、プライマリへの I/O の影響はありません。

メンテナンスウィンドウとは、AWS が OS パッチ、エンジンのマイナーアップグレード、インスタンスの変更を適用する、毎週設定される別の時間帯です。ベストプラクティスは、どちらのウィンドウもトラフィックの少ない時間帯に設定し、重複しないようにすることです。

特定の時点に復元する場合、RDS はまず最新の日次スナップショットを復元し、その後、指定されたタイムスタンプまでトランザクションログを再適用します。復元の結果として新しい DB インスタンスが作成されます。PITR によってソースインスタンスが上書きされることはないため、本番環境を中断せずに安全に復旧できます。

復元したインスタンスが利用可能になったら、アプリケーションの接続文字列を新しいエンドポイントを指すように更新し、データの整合性を確認します。その後、意図した復旧であれば元のインスタンスを削除します。通常、復元時間はデータベースのサイズと、最後のスナップショット以降のログ量に比例します。

自動バックアップに加えて、いつでも手動スナップショットを取得できます。自動バックアップとは異なり、手動スナップショットは保持期間の対象外であり、明示的に削除するまで保持されます。

手動スナップショットは、大規模なスキーマ移行やアプリケーションのアップグレードの前の状態を保存したり、コンプライアンス目的で請求サイクルの終了時点をアーカイブしたりする場合に適しています。また、手動スナップショットを他の AWS アカウントと共有したり、ディザスタリカバリのために別のリージョンへコピーしたりすることもできます。

ディザスタリカバリのために、自動スナップショットまたは手動スナップショットを別の AWS リージョンへコピーできます。コピーは、コピー先リージョンの S3 インフラストラクチャに保存される完全なスナップショットです。コピーが完了すると、プライマリリージョンが利用できなくなった場合に、そのリージョンで新しい RDS インスタンスを復元できます。

ソースが暗号化されていない場合でも、コピー先でスナップショットを暗号化できます（逆も同様です）。リージョン間コピーにはデータ転送コストがかかります。定期的なリージョン間スナップショットコピーを自動化するには、AWS Backup または EventBridge によってトリガーされる Lambda を使用します。

Amazon RDS Proxyはアプリケーションと RDS の間に配置され、データベース接続をプールします。これは、短時間だけ存続する接続を数千件開いてデータベースの接続上限に達する可能性がある Lambda 関数に特に有効です。RDS Proxy は接続を多重化するため、データベースから見えるアクティブな接続数を大幅に減らせます。

Multi-AZ のフェイルオーバー中、RDS Proxy はアプリケーション接続を保持し、新しいプライマリへのデータベース接続を再確立します。これにより、アプリケーションの再接続時間を数分から数秒に短縮できます。また、RDS Proxy は Secrets Manager と統合されているため、アプリケーションを停止せずに認証情報をローテーションできます。

RDS には現在、2 種類の Multi-AZ オプションがあります。Multi-AZ DB Instance（従来型、スタンバイ 1 台）と、Multi-AZ DB Cluster（異なる AZ に配置された読み取り可能なスタンバイインスタンス 2 台）です。クラスター方式では準同期レプリケーションを使用し、スタンバイで読み取りトラフィックを処理できます。そのため、個別の Read Replicas を用意しなくても、高可用性と読み取りスケーラビリティを向上させられます。

SAA-C03 試験では、従来型の Multi-AZ DB Instance が最も頻繁に出題されます。Multi-AZ Cluster はスタンバイで読み取りを処理できる新しいオプションであり、従来型のスタンバイでは読み取りを処理できないことを覚えておいてください。

このレッスンでは、Multi-AZ は 60～120 秒で自動フェイルオーバーする同期スタンバイレプリケーションを提供すること、自動バックアップによって保持期間（1～35 日）の範囲内で任意の秒単位の PITR が可能になること、そして手動スナップショットは無期限に保持され、DR のためにリージョン間でコピーできることを学びました。次は、読み取りトラフィックを分散し、読み取りスループットを向上させる Read Replicas について説明します。