マルチAZ DB インスタンスのデプロイ - Amazon Relational Database Service

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

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

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

注記

高可用性のオプションは、読み取り専用シナリオ向けのスケーリングソリューションではありません。スタンバイレプリカを使用してリードトラフィックを処理することはできません。読み取り専用トラフィックを処理するには、代わりにマルチ AZ DB クラスターまたはリードレプリカを使用します。マルチ AZ DB クラスターの詳細については、「マルチ AZ 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 でいくつかのことが実行されます。Amazon RDS は、まずデプロイからプライマリ DB インスタンスのスナップショットを作成し、次にこのスナップショットを別のアベイラビリティーゾーンに復元します。その後、Amazon RDS がプライマリ DB インスタンスと新しいDBインスタンスとの間に同期レプリケーションをセットアップします。

DB インスタンスの変更については、Amazon RDS DB インスタンスを変更するを参照してください。

重要

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

DB インスタンスでマルチ AZ を有効にするため、RDS はプライマリ DB インスタンスの Amazon EBS ボリュームのスナップショットを取得し、新しく作成されたスタンバイレプリカにそれを回復します。     次に、RDS は両方のボリュームを同期します。既存の EBS スナップショットを基に作成された新しいボリュームは、バックグラウンドで時間をかけて読み込まれます。この機能を使用すると、スナップショットから大量のボリュームをすばやく復元できますが、変更中および変更完了後にレイテンシーが発生する可能性があります。詳細については、Amazon EC2ドキュメントの「スナップショットからの Amazon EBS ボリュームの復元」を参照してください。

レイテンシーの影響を受けやすいワークロードへの影響を減らすために、メンテナンス期間中またはワークロードの削減時に、最初に DB インスタンスを変更して プロビジョンド IOPS ストレージタイプを使用することをお勧めします。プロビジョンド IOPS ストレージの容量を、ワークロードが必要とするよりも大幅に多く設定します。次に、マルチ AZ 配置の変更を開始します。完了後、新しく作成された AZ にフェイルオーバーし、そこで完全なテーブルスキャンクエリを実行して、必要なデータを新しいストレージボリュームに迅速にロードできます。

現在、機密性の高いワークロードを処理している DB インスタンスへのパフォーマンスへの影響を回避するには、リードレプリカを作成し、リードレプリカでバックアップを有効にし、レプリカをマルチ AZ に変更し、データをリードレプリカのボリューム (両方の AZ) にロードするクエリを実行し、ワークロードをリードレプリカにカットします。

変更が完了した後、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 を設定することが極めて重要です。

注記

デフォルト 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");