マルチAZ DB インスタンスのデプロイ - Amazon Relational Database Service
DB インスタンスをマルチ AZ DB インスタンスのデプロイに変更するAmazon RDS のフェイルオーバープロセス

マルチAZ DB インスタンスのデプロイ

Amazon RDS は、単一のスタンバイ DB インスタンスでマルチ AZ デプロイを使用して DB インスタンスの高可用性およびフェイルオーバーサポートを提供します。このタイプのデプロイは、マルチ AZ DB インスタンスのデプロイと呼ばれます。Amazon RDS は複数の異なるテクノロジーを使用してフェイルオーバーサポートを提供します。MariaDB、MySQL、Oracle、PostgreSQL、および RDS Custom for SQL Server DB インスタンスのマルチ AZ デプロイでは、Amazon のフェイルオーバーテクノロジーが使用されます。Microsoft SQL Server DB インスタンスでは、SQL Server データベースのミラーリング (DBM) または Always On 可用性グループ (AGs) が使用されます。マルチ AZ の SQL Server バージョンのサポートについては、「Amazon RDS for Microsoft SQL Server のマルチ AZ 配置」を参照してください。マルチ AZ の RDS Custom for SQL Server の使用については、「RDS Custom for SQL Server のマルチ AZ 配置の管理」を参照してください。

マルチ AZ DB インスタンスのデプロイでは、Amazon RDS は、異なるアベイラビリティーゾーンで同期スタンバイレプリカを自動的にプロビジョンおよび維持します。プライマリ DB インスタンスは、アベイラビリティーゾーン間でスタンバイレプリカに同期的に複製され、データの冗長性を提供し、システムバックアップ中の遅延スパイクを最小限に抑えます。高可用性を備えた DB インスタンスを実行すると、計画されたシステムメンテナンス中の可用性が向上する可能性があります。また、DB インスタンスの障害とアベイラビリティーゾーンの中断からデータベースを保護することを助けることもできます。アベイラビリティーゾーンの詳細については、「リージョン、アベイラビリティーゾーン、および Local Zones」を参照してください。

注記

高可用性のオプションは、読み取り専用シナリオ向けのスケーリングソリューションではありません。スタンバイレプリカを使用してリードトラフィックを処理することはできません。読み取り専用トラフィックを処理するには、代わりにマルチ AZ DB クラスターまたはリードレプリカを使用します。マルチ AZ DB クラスターの詳細については、「マルチ AZ DB クラスター配置」を参照してください。リードレプリカの詳細については、「DB インスタンスのリードレプリカの操作」を参照してください。

高可用性シナリオ

RDS コンソールを使用すると、DB インスタンスを作成する際にマルチ AZ を指定するだけでマルチ AZ DB デプロイを作成できます。コンソールを使用し、DB インスタンスを変更し、マルチ AZ オプションを指定して、マルチ AZ DB インスタンスを変更することで、既存の DB インスタンスをマルチ AZ DBインスタンスのデプロイに変換できます。AWS CLIまたは Amazon RDS API を使用して、マルチ AZ DB インスタンスのデプロイを指定することもできます。create-db-instance または modify-db-instance CLI コマンドを使用するか、CreateDBInstance または ModifyDBInstance API オペレーションを使用します。

RDS コンソールには、スタンバイレプリカ (セカンダリ AZ と呼ばれます) のアベイラビリティーゾーンが表示されます。また、describe-db-instances CLI コマンドまたは DescribeDBInstances API オペレーションを使用してセカンダリ AZ を見つけることもできます。

マルチAZ DB デプロイを使用する DBインスタンスは、シングル AZ のデプロイと比較して書き込みとコミットの待ち時間が長くなる可能性があります。これは、同期データレプリケーションが発生しているために起こる可能性があります。AWS はアベイラビリティーゾーン間でのネットワーク接続レイテンシーが低くなるように設計されていますが、配置がスタンバイレプリカにフェイルオーバーした場合はレイテンシーに変化が見られる可能性があります。本番ワークロードの場合、高速で一貫したパフォーマンスを実現するために、プロビジョンドIOPS (1 秒あたりの入出力操作) を使用することをお勧めします。DB インスタンスクラスの詳細については、「 DB インスタンスクラス」を参照してください。

DB インスタンスをマルチ AZ DB インスタンスのデプロイに変更する

シングル AZ デプロイの DB インスタンスをマルチ AZ DB インスタンスのデプロイに変更すると (エンジンは Amazon Aurora 以外)、Amazon RDS でいくつかのアクションが実行されます。

  1. プライマリ DB インスタンスの Amazon Elastic Block Store (EBS) ボリュームのスナップショットを作成します。

  2. スナップショットからスタンバイレプリカ用の新しいボリュームを作成します。これらのボリュームはバックグラウンドで初期化され、データが完全に初期化された後に最大のボリュームパフォーマンスが得られます。

  3. プライマリレプリカとスタンバイレプリカのボリューム間の同期ブロックレベルレプリケーションを有効にします。

重要

スナップショットを使用してスタンバイインスタンスを作成すると、シングル AZ からマルチ AZ への変換時のダウンタイムを回避できますが、マルチ AZ への変換中と変換後にパフォーマンスに影響が出ることがあります。この影響は、書き込みレイテンシーに敏感なワークロードにとって重大な可能性があります。

この機能により、スナップショットから大量のボリュームをすばやく復元できますが、同期レプリケーションのため、I/O 操作のレイテンシーが著しく増加する可能性があります。このレイテンシーはデータベースのパフォーマンスに影響を与える可能性があります。ベストプラクティスとして、本番環境の DB インスタンスでマルチ AZ 変換を実行しないことを強くお勧めします。

機密扱いのワークロードを現在処理している DB インスタンスのパフォーマンスへの影響を避けるには、リードレプリカを作成し、リードレプリカのバックアップを有効にします。リードレプリカをマルチ AZ に変換し、(両方の AZ の) リードレプリカのボリュームにデータをロードするクエリを実行します。次に、リードレプリカがプライマリ DB インスタンスに昇格されます。詳細については、「DB インスタンスのリードレプリカの操作」を参照してください。

DB インスタンスをマルチ AZ DB インスタンスのデプロイに変更するには 2 つの方法があります。

RDS コンソールを使用して、マルチ AZ DB インスタンスのデプロイに変換する

RDS コンソールを使用して、DB インスタンスをマルチ AZ DB インスタンスのデプロイに変換できます。

コンソールは、変換を完了するためにのみ使用できます。AWS CLI または RDS API を使用するには、DB インスタンスをマルチ AZ DB インスタンスのデプロイに変更する の手順に従います。

RDS コンソールを使用して、マルチ AZ DB インスタンスのデプロイに変換するには

  1. AWS Management Console にサインインし、Amazon RDS コンソール https://console.aws.amazon.com/rds/ を開きます。

  2. ナビゲーションペインで、[データベース] を選択し、変更する DB インスタンスを選択します。

  3. [Actions] (アクション) から、[Convert to Multi-AZ deployment] (マルチ AZ 配置に変換) を選択します。

  4. 変更をすぐに適用するには、確認ページで [Apply Immediately] (すぐに適用) を選択します。このオプションを選択してもダウンタイムは発生しませんが、パフォーマンスに影響する可能性があります。または、次のメンテナンスウィンドウの間に更新を適用することもできます。詳細については、「[すぐに適用] 設定を使用する」を参照してください。

  5. [Convert to Multi-AZ] (マルチ AZ に変換) を選択します。

DB インスタンスをマルチ AZ DB インスタンスのデプロイに変更する

次の方法で、DB インスタンスをマルチ AZ DB インスタンスのデプロイに変更できます。

  • RDS コンソールを使用して DB インスタンスを変更し、[Multi-AZ deployment] (マルチ AZ 配置) を [Yes] (はい) に設定します。

  • AWS CLI を使用して modify-db-instance コマンドを呼び出し、--multi-az オプションを設定します。

  • RDS API を使用して、ModifyDBInstance オペレーションを呼び出して、MultiAZ パラメータを true に設定します。

DB インスタンスの変更については、「Amazon RDS DB インスタンスを変更する」を参照してください。変更が完了した後、Amazon RDS は、プロセスが完了したことを示すイベント (RDS-EVENT-0025) をトリガーします。Amazon RDS イベントをモニタリングできます。 イベントの詳細については、「Amazon RDS イベント通知の操作」を参照してください。

Amazon RDS のフェイルオーバープロセス

DB インスタンスの計画的または計画外の停止がインフラストラクチャの欠陥に起因する場合、マルチ AZ を有効にしていると、Amazon RDS は別のアベイラビリティーゾーンのスタンバイレプリカに自動的に切り替わります。　　　　 フェイルオーバーが完了するまでにかかる時間は、プライマリ DB インスタンスが使用できなくなったときのデータベースアクティビティおよびその他の条件によって異なります。フェイルオーバー時間は通常 60～120 秒です。ただし、大規模なトランザクションや長期にわたる復旧プロセスによって、フェイルオーバー時間が増加する場合があります。フェイルオーバーが完了してから、新しいアベイラビリティーゾーンが RDS コンソールに反映されるまでさらに時間がかかる場合があります。

注記

DB インスタンスを再起動するときに手動でフェイルオーバーを強制的に実行することができます。詳細については、「 DB インスタンスの再起動」を参照してください。

Amazon RDS はフェイルオーバーを自動的に処理するため、管理者が操作しなくても可能な限りすみやかにデータベース操作を再開できます。次の表に記載されている条件のいずれかが発生した場合、プライマリ DB インスタンスがスタンバイレプリカに自動的に切り替わります。これらのフェイルオーバーの理由は、イベントログで確認できます。

フェイルオーバーした理由 説明
RDS データベースインスタンスの基盤となるオペレーティングシステムには、オフライン操作でパッチが適用されています。

OS パッチまたはセキュリティ更新プログラムのメンテナンス期間中に、フェイルオーバーがトリガーされました。

詳細については、「DB インスタンスのメンテナンス」を参照してください。
RDS マルチ AZ インスタンスのプライマリホストが異常です。 マルチ AZ DB インスタンスのデプロイは、障害のあるプライマリ DB インスタンスを検出し、フェイルオーバーしました。
RDS マルチ AZ インスタンスのプライマリホストで、ネットワーク接続が切断されたため、到達できません。

RDS モニタリングは、プライマリ DB インスタンスへのネットワーク到達可能性による障害を検出し、フェイルオーバーをトリガーしました。
RDS インスタンスはお客様によって変更されました。

RDS DB インスタンスの変更により、フェイルオーバーがトリガーされました。

詳細については、「Amazon RDS DB インスタンスを変更する」を参照してください。
RDS マルチ AZ プライマリインスタンスはビジーで応答しません。

プライマリ DB インスタンスが応答しません。次のことを行うことをお勧めします。

これらの推奨事項の詳細については、Amazon RDS ​のメトリクスのモニタリングの概要 および Amazon RDS のベストプラクティス を参照してください。
RDS マルチ AZ インスタンスのプライマリホストの基盤となるストレージボリュームでエラーが発生しました。 マルチ AZ DB インスタンスのデプロイは、プライマリ DB インスタンスでストレージの問題を検出し、フェイルオーバーしました。
ユーザーが DB インスタンスのフェイルオーバーをリクエストしました。

DB インスタンスを再起動し、[Reboot with failover (フェイルオーバーで再起動)] を選択しました。

(詳しくは、「 DB インスタンスの再起動」を参照してください。)

マルチ AZ DB インスタンスがフェイルオーバーされたかどうかを判断するには、次を実行します。

  • フェイルオーバーがスタートされたことを電子メールまたはSMSで通知するようにDBイベントサブスクリプションを設定します。 イベントの詳細については、「Amazon RDS イベント通知の操作」を参照してください。

  • RDS コンソールまたは API オペレーションを使用して DB イベントを表示します。

  • RDS コンソールまたは API オペレーションを使用して、マルチ AZ DB インスタンスのデプロイの現在の状態を表示します。

フェイルオーバーへの応答、復旧時間の短縮、Amazon RDS のその他のベストプラクティスについては、「Amazon RDS のベストプラクティス」を参照してください。

DNS 名参照用の JVM TTL の設定

フェイルオーバーメカニズムでは、スタンバイ DB インスタンスをポイントするように DB インスタンスのドメインネームシステム (DNS) レコードが自動的に変更されます。したがって、DB インスタンスへの既存の接続の再確立が必要になります。Java 仮想マシン (JVM) 環境では、Java DNS キャッシュ機構がどのように機能するかによって、JVM 設定の再構成が必要になる場合があります。

JVM は DNS 名参照をキャッシュします。JVM がホスト名を IP アドレスに変換するとき、time-to-live (TTL) と呼ばれる指定期間 IP アドレスをキャッシュします。

AWS リソースは、ときどき変更される DNS 名を使用するため、60 秒を超えない TTL 値で JVM を設定することをお勧めします。こうすることにより、リソースの IP アドレスが変更されたときに、アプリケーションは DNS に対して再度クエリを実行することで、リソースの新しい IP アドレスを取得して使用できます。

一部の Java 設定では JVM のデフォルトの TTL が設定されるため、JVM が再起動されるまで、DNS エントリが更新されることはありません。したがって、アプリケーションがまだ実行中に AWS リソースの IP アドレスが変更された場合、JVM を手動で再起動し、キャッシュされた IP 情報が更新されるまで、そのリソースを使用することはできません。この場合、キャッシュされた IP 情報が定期的に更新されるように JVM の TTL を設定することがきわめて重要です。

JVM のデフォルト TTL は、networkaddress.cache.ttl プロパティ値を取得することで取得できます。


String ttl = java.security.Security.getProperty("networkaddress.cache.ttl");
注記

デフォルト TTL は、JVM のバージョンと、セキュリティマネージャーがインストールされているかどうかに応じて変わります。多くの JVM はデフォルト TTL を 60 秒以下にしています。このような JVM を使用しており、セキュリティマネージャーを使用していない場合、このトピックの残り部分は無視してかまいません。Oracle のセキュリティマネージャーの詳細については、Oracle ドキュメントの 「The Security Manager」を参照してください。

JVM の TTL を変更するには、networkaddress.cache.ttl プロパティ値を設定します。ニーズに応じて、次の方法のいずれかを使用します。

  • JVM を使用するすべてのアプリケーションのプロパティ値をグローバルに設定するには、networkaddress.cache.ttl ファイルで $JAVA_HOME/jre/lib/security/java.security を設定します。

    
networkaddress.cache.ttl=60

  • アプリケーションに対してのみプロパティをローカルに設定するには、ネットワーク接続を確立する前に、アプリケーションの初期化コードで networkaddress.cache.ttl を設定します。

    
java.security.Security.setProperty("networkaddress.cache.ttl" , "60");