Amazon RDS での高可用性 (マルチ AZ) - Amazon Relational Database Service

Amazon RDS での高可用性 (マルチ AZ)

Amazon RDS は、マルチ AZ 配置を使用して DB インスタンスの高可用性およびフェイルオーバーサポートを提供します。Amazon RDS は複数の異なるテクノロジーを使用してフェイルオーバーサポートを提供します。MariaDB、MySQL、Oracle、PostgresSQL DB インスタンスのマルチ AZ 配置では、Amazon のフェイルオーバーテクノロジーが使用されます。SQL Server DB インスタンスでは、SQL Server データベースのミラーリング (DBM) または Always On 可用性グループ (AGs) が使用されます。

Amazon RDS のマルチ AZ 配置では、異なるアベイラビリティーゾーンに同期スタンバイレプリカが自動的にプロビジョニングされて維持されます。プライマリ DB インスタンスは複数のアベイラビリティーゾーンにまたがって、スタンバイレプリカに同期してレプリケートされます。これにより、データの冗長性を提供し、I/O のフリーズを防ぎ、システムバックアップの間のレイテンシーの急上昇を最小限に抑えることができます。高可用性を備えた DB インスタンスを実行すると、計画されたシステムメンテナンス中の可用性が向上し、DB インスタンスの障害とアベイラビリティーゾーンの中断からデータベースを保護できます。アベイラビリティーゾーンの詳細については、「 リージョン、アベイラビリティーゾーン、およびローカルゾーン 」を参照してください。

注記

読み取り専用シナリオでは、高可用性機能が拡張ソリューションとならない点に注意してください。スタンバイレプリカを使用して読み取りトラフィックを処理することはできません。読み取り専用トラフィックを処理するには、リードレプリカを使用する必要があります。詳細については、「リードレプリカの使用」を参照してください。


			高可用性シナリオ

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

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

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

DB インスタンスを変更してマルチ AZ 配置にする

シングル AZ 配置の DB インスタンスをマルチ AZ 配置に変更すると (エンジンは Amazon Aurora 以外)、Amazon RDS でいくつかのことが実行されます。まず、Amazon RDS は配置から、プライマリ DB インスタンスのスナップショットを撮ります。その後、他のアベイラビリティーゾーンにスナップショットを復元します。その後、Amazon RDS によりプライマリ DB インスタンスと新しいインスタンスとの間に同期レプリケーションが設定されます。

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

重要

このアクションにより、シングル AZ からマルチ AZ への変換時のダウンタイムを回避できますが、マルチ AZ への変換中と変換後にパフォーマンスに影響が出ることがあります。この影響は、書き込み頻度の高い大規模な DB インスタンスで大きくなる可能性があります。

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

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

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

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

注記

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

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

  • アベイラビリティーゾーンの機能停止

  • プライマリ DB インスタンスのエラー

  • DB インスタンスのサーバータイプ変更

  • DB インスタンスのオペレーティングシステムでソフトウェアのパッチ適用中

  • DB インスタンスの手動フェイルオーバーが [Reboot with failover] を使用して開始された

マルチ AZ DB インスタンスがフェイルオーバーされたかどうかを判断する方法は複数あります。

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

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

  • Amazon RDS コンソールおよび API オペレーションを使用して、マルチ AZ 配置の現在の状態を表示できます。

フェイルオーバーへの応答、復旧時間の短縮、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 を使用するすべてのアプリケーションのプロパティ値をグローバルに設定するには、$JAVA_HOME/jre/lib/security/java.security ファイルで networkaddress.cache.ttl を設定します。

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

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