シングル AZ Amazon RDS インスタンスをマルチ AZ インスタンス、またはその逆に変換すると、どのような影響がありますか?

簡単な説明

シングル AZ 設定では、1 つの Amazon RDS DB インスタンスと 1 つ以上の Amazon Elastic Block Store (Amazon EBS) ストレージボリュームが、1 つのアベイラビリティーゾーンにデプロイされます。マルチ AZ 設定では、DB インスタンスと EBS ストレージボリュームは 2 つのアベイラビリティーゾーンにデプロイされます。

インスタンスでマルチ AZ を有効にすると、Amazon RDS は同期ストレージレプリケーションを使用して、冗長で一貫性のあるデータのスタンバイコピーを維持します。Amazon RDS は、マルチ AZ 配置の最も一般的なインフラストラクチャ障害シナリオを検出し、自動的に回復します。この検出と回復は、データベース操作をできるだけ早く再開できるようにするために行われます。詳細については、「Amazon RDS での高可用性 (マルチ AZ) 」を参照してください。

DB インスタンスをシングル AZ 配置からマルチ AZ 配置に、またはその逆に変更するには、「<t1>Amazon RDS インスタンスの変更</t1>」を参照してください。

解決方法

シングル AZ インスタンスをマルチ AZ インスタンスに変更することの影響

シングル AZ インスタンスをマルチ AZ に変更しても、インスタンスのダウンタイムは発生しません。変更中、Amazon RDS はインスタンスのボリュームのスナップショットを作成します。次に、このスナップショットは、別のアベイラビリティーゾーンに新しいボリュームを作成するために使用されます。これらの新しいボリュームはすぐに使用可能ですが、パフォーマンスへの影響が発生する可能性があります。この影響は、新しいボリュームのデータが Amazon Simple Storage Service (Amazon S3) からまだロードされているために発生します。その間、DB インスタンスはバックグラウンドでデータをロードし続けます。遅延読み込みと呼ばれるこのプロセスは、変更プロセス中および変更後の書き込みレイテンシーの増加とパフォーマンスへの影響につながる可能性があります。

パフォーマンスへの影響の量は、ボリュームタイプ、ワークロード、インスタンス、ボリュームサイズの関数です。この影響は、オペレーションのピーク時に大量の書き込みが集中する DB インスタンスに対して重大な影響を及ぼす可能性があります。そのため、この変更を本番環境で実行する前に、テストインスタンスへの影響をテストすることがベストプラクティスです。この変更を、メンテナンスまたは低スループットの時間帯に完了することもベストプラクティスです。

ロード時間を短縮

ロードの持続時間と影響を事前に減らすには、次の操作を行います。

1. DB インスタンスのストレージタイプを [プロビジョンド IOPS] に変更します。必ず、ワークロードが必要とする量よりも大幅に高い量の IOPS をプロビジョニングしてください。
   **注意:**インスタンスがカスタムパラメータグループを使用している場合、このステップによって短時間のダウンタイムが発生する可能性があります。
2. インスタンスをマルチ AZ に変更します。
3. インスタンスでフェイルオーバーを開始して、新しい AZ がプライマリ AZ であることを確認します。
4. インスタンスでデータのフルダンプを実行します。または、最もアクティブなテーブルに対してフルテーブルスキャンクエリを実行して、ボリュームへのデータのロードを高速化します。
5. Amazon CloudWatch のWriteLatency メトリクスを確認して、書き込みレイテンシーが通常のレベルに戻ったことを確認します。
6. インスタンスのストレージタイプまたは IOPS を以前の設定に戻します。
   注意: このステップにはダウンタイムは必要ありません。

インスタンスがすでにマルチ AZ の場合はレイテンシーを減らします

すでにインスタンスをマルチ AZ に変更している場合にレイテンシーを減らすには、次の手順を実行します。

1. インスタンスでフェイルオーバーを開始して、新しい AZ がプライマリ AZ であることを確認します。
2. DB インスタンスのストレージタイプを [プロビジョンド IOPS] に変更します。必ず、ワークロードが必要とする量よりも大幅に高い量の IOPS をプロビジョニングしてください。
   注意: このステップにはダウンタイムは必要ありません。
3. インスタンスでデータのフルダンプを実行します。または、最もアクティブなテーブルに対してフルテーブルスキャンクエリを実行して、ボリュームへのデータのロードを高速化します。
4. Amazon CloudWatch のWriteLatency メトリクスを確認して、書き込みレイテンシーが通常のレベルに戻ったことを確認します。
5. インスタンスのストレージタイプまたは IOPS を以前の設定に戻します。
   注意: このステップにはダウンタイムは必要ありません。

DB インスタンスをシングル AZ からマルチ AZ に変更すると、別のアベイラビリティーゾーンに同じ設定でスタンバイインスタンスが作成されます。これにより追加コストが発生します。また、マルチ AZ 配置は同期レプリケーションを使用するため、書き込みはシングル AZ の書き込みよりも遅くなります。

マルチ AZ インスタンスをシングル AZ インスタンスに変更した場合の影響

インスタンスをマルチ AZ からシングル AZ に変更しても、インスタンスのダウンタイムは発生しません。変更中、Amazon RDS はセカンダリインスタンスとボリュームのみを削除し、プライマリインスタンスは影響を受けません。

ここでは、インスタンスをマルチ AZ 配置からシングル AZ 配置に変更する前に考慮すべき事項をいくつか挙げます。

• マルチ AZ 配置では、DB インスタンスの計画的または予期しない停止時に、Amazon RDS は別のアベイラビリティーゾーンのスタンバイコピーに自動的に切り替わります。ただし、シングル AZ インスタンスでは、ポイントインタイム復元オペレーションの開始が必要になる場合があります。このオペレーションの完了には数時間かかる場合があります最新の復元可能時間よりも後に発生したデータ更新は利用できなくなりますしたがって、障害が発生した場合にシングル AZ インスタンスでさらにダウンタイムが発生する可能性があります。
• マルチ AZ インスタンスでは、自動バックアップウィンドウ中にセカンダリインスタンスから自動バックアップが作成されます。Amazon RDS for MariaDB、Amazon RDS for MySQL、Amazon RDS for Oracle、および Amazon RDS for PostgreSQL の場合、マルチ AZ 配置のバックアップ中にプライマリインスタンスでの I/O アクティビティは中断されません。これは、バックアップがセカンダリインスタンスから取得されるためです。Amazon RDS for SQL Server の場合、マルチ AZ 配置のバックアップ中に I/O アクティビティが一時的に中断されます。Single-AZ DB インスタンスのバックアッププロセスでは、数秒から数分間続く短時間の I/O 停止が発生します。所要時間は DB インスタンスのサイズとクラスによって異なります。
• マルチ AZ 配置では、オペレーティングシステムのメンテナンスは最初にセカンダリインスタンスに適用されます。セカンダリインスタンスがプライマリに昇格し、元のプライマリでメンテナンスが実行され、これが新しいスタンバイインスタンスになります。したがって、マルチ AZ インスタンスでの特定の OS パッチ中のダウンタイムは最小限です。
• マルチ AZ インスタンスをスケーリングする場合、ダウンタイムは最小限です。これは、セカンダリインスタンスが最初に変更されるためです。セカンダリインスタンスがプライマリに昇格されます。次に、古いプライマリ (現在はセカンダリインスタンス) が変更されます。シングル AZ インスタンスは、スケーリング操作中は使用できなくなります。

---

関連情報

Amazon RDS マルチ AZ 配置