1 つのスタンバイを備えた Amazon RDS マルチ AZ
| 自動フェイルオーバー | データベースのパフォーマンスを保護する | 耐久性を向上させる | 可用性を高める |
| データの損失と手動による介入なしで、60 秒という速さで完了する自動データベースフェイルオーバーにより、アプリケーションの高可用性をサポートします。 |
スタンバイインスタンスからバックアップすることにより、バックアップ中にプライマリでの I/O アクティビティの一時停止を回避します。 |
Amazon RDS マルチ AZ 同期レプリケーションテクノロジーを使用して、スタンバイデータベースインスタンスのデータをプライマリに合わせた最新の状態に保ちます。 | 2 つ目の AZ にスタンバイインスタンスをデプロイすることで可用性を高め、AZ またはデータベースインスタンスに障害が発生した場合の耐障害性を実現します。 |
2 つの読み取り可能なスタンバイを備えた Amazon RDS マルチ AZ
| 通常 35 秒以内の自動フェイルオーバー | 読み取りと書き込みに別々のエンドポイントを使用する | トランザクションコミットレイテンシーを最大 2 倍高速化 | マイナーバージョンアップグレードは通常 1 秒未満 |
| データ損失も手動による介入もなしで、通常 35 秒未満で自動的にフェイルオーバーします。 | 書き込みサーバーと適切なリードレプリカスタンバイインスタンスにクエリをルーティングして、パフォーマンスとスケーラビリティを最大化します。 | 1 つのスタンバイを備えたマルチ AZ と比較して、レイテンシーを最大 2 倍改善します。 | マイナーバージョンアップグレードのダウンタイムを通常 35 秒未満に短縮します。デプロイにオープンソースまたは RDS プロキシを追加することで、ダウンタイムを通常 1 秒未満にさらに短縮できます。 |
比較表
1 つのスタンバイを備えた Amazon RDS シングル AZ もしくは Amazon RDS マルチ AZ、または 2 つの読み取り可能なスタンバイを備えた Amazon RDS マルチ AZ
機能 |
シングル AZ |
1 つのスタンバイを備えたマルチ AZ |
2 つの読み取り可能なスタンバイを備えたマルチ AZ |
利用可能なエンジン |
|
|
|
追加の読み取り |
|
|
· |
トランザクションコミットの低いレイテンシー (より高いスループット) |
|
|
|
自動フェイルオーバー期間 |
|
|
|
| マイナーバージョンアップグレードのダウンタイム |
|
|
|
AZ の停止に対するより高い回復力 |
|
|
|
トランザクションコミットのより低いジッター |
|
|
|
お客様
SysCloud は、重要な Software as a Service (SaaS) アプリケーションの自動バックアップを作成し、悪意のあるファイルをモニタリングし、データとコンプライアンスに関する強力なインサイトを提供します。これらはすべて、1 つのダッシュボードから行われます。SysCloud は、内部モニタリングシステム用に 2 つの読み取り可能なスタンバイを備えた Amazon RDS マルチ AZ を使用しています。「新しい Amazon RDS マルチ AZ 配置オプションは、パフォーマンス、可用性、および読み取りスケーラビリティを向上させるための費用対効果に優れた方法を提供します」と、SysCloud のインフラストラクチャ担当ディレクターである Vikram Srinivasan 氏は述べています。「新しい Amazon RDS マルチ AZ 配置オプションにより、お客様により優れたエクスペリエンスを提供できると考えています」
料金
Amazon RDS マルチ AZ は、RDS for PostgreSQL、RDS for MySQL、RDS for MariaDB、RDS for SQL、RDS for Oracle、および RDS for Db2 でご利用いただけます。2 つの読み取り可能なスタンバイを備えた Amazon RDS マルチ AZ は、RDS for PostgreSQL と RDS for MySQL で利用できます。Amazon Aurora が 3 つのアベイラビリティーゾーンにわたってデータの耐久性を向上させることで可用性を高める方法については、「Aurora レプリカをによるマルチ AZ 配置」をご覧ください。
シングル AZ 配置、1 つのスタンバイインスタンスを使用するマルチ AZ 配置、および 2 つの読み取り可能なスタンバイを使用するマルチ AZ 配置の場合、料金は、DB インスタンスが起動されてから停止または削除されるまでに消費された DB インスタンス時間あたりで発生します。DB インスタンスクラスの作成、起動、変更などの請求対象となるステータス変更に続いて、1 時間未満の DB インスタンス時間は 10 分を最小料金として、秒単位で請求されます。
Amazon RDS マルチ AZ の料金の詳細については、Amazon RDS の料金ページを参照してください。
リソース
開始方法
以下のユーザーガイドとチュートリアルを使用して、Amazon RDS マルチ AZ をすぐに使用開始できます。
ドキュメント
1 つのスタンバイを備えた Amazon RDS マルチ AZ の概念について説明し、DB インスタンスをマルチ AZ 配置に変更する方法と Amazon RDS のフェイルオーバープロセスを説明します。
ドキュメント
2 つの読み取り可能スタンバイを備えた Amazon RDS マルチ AZ の概念について説明し、クラスターの変更、名前変更、再起動、削除、リードレプリカの使用、マルチ AZ DB クラスターでの PostgreSQL 論理レプリケーションの使用の方法を説明します。
入門チュートリアル
このチュートリアルでは、ライセンス込みモデルを使用して Amazon RDS に Oracle データベースのスタンダードエディション 2 インスタンスを作成し、マルチ AZ やパフォーマンスインサイトなどの機能を有効にする方法を示します。
動画
セッション、オンラインセミナー、その他の動画を視聴して、Amazon RDS マルチ AZ の詳細を知ってください。
オンライン Teck Talk
このセッションでは、マルチ AZ とそのデプロイオプション、各オプションの利点について簡単に説明し、2 つの読み取り可能スタンバイオプションとその最近の機能強化について詳しく説明します。
ブログ
Amazon RDS マルチ AZ の最新の改善点を読み、Amazon RDS のユースケースでどのように使用できるかを詳しく調べてください。
よくある質問
DB インスタンスをマルチ AZ 配置として実行することにはどのような意味がありますか?
マルチ AZ 配置として実行するように DB インスタンスを作成または変更すると、Amazon RDS では、同期 "スタンバイ" レプリカが別のアベイラビリティーゾーンで自動的にプロビジョニングされ、維持されます。DB インスタンスに対する更新は、別のアベイラビリティーゾーンにあるスタンバイに同時にレプリケートされるため、同期が維持されるとともに、最新のデータベース更新が DB インスタンスの障害から保護されます。
特定の種類の計画的なメンテナンスの期間中や、DB インスタンスの障害もしくはアベイラビリティーゾーンの障害といった予期せぬイベントが発生した際には、Amazon RDS はスタンバイに対して自動的にフェイルオーバーし、スタンバイが昇格したら直ちにデータベースの読み込みと書き込みを再開できるようにします。DB インスタンスの名前レコードは変化しないため、アプリケーションによるデータベースオペレーションは、管理者による手動での介入なしで再開できます。マルチ AZ 配置のレプリケーションは透過的です。スタンバイと直接やり取りすることはできません。また、スタンバイを読み取りトラフィックの処理に使用することはできません。マルチ AZ 配置の詳細については、「Amazon RDS ユーザーガイド」をご覧ください。
アベイラビリティーゾーンとは何ですか?
アベイラビリティーゾーンとは、別のアベイラビリティゾーンで発生した障害から隔離するために作られたリージョン内の場所です。各アベイラビリティーゾーンは、その独自の、物理的に区分され独立したインフラストラクチャ上で稼動しています。また高い信頼性を保つように設計されています。発電機や冷却装置などの障害対策用装置がアベイラビリティーゾーン間で共有されることはありません。さらに、これらは物理的にそれぞれ別々の場所にあるため、火災、竜巻、または洪水などの極めてまれな災害が発生しても、影響を受けるのは単一のアベイラビリティーゾーンのみです。同一リージョンにあるアベイラビリティーゾーンには、ネットワーク接続のレイテンシーが低いという利点があります。
マルチ AZ 配置のコンテキストにおいて "プライマリ" と "スタンバイ" は何を意味しますか?
DB インスタンスをマルチ AZ 配置として実行する場合、"プライマリ" はデータベースに読み込みと書き込みの機能を提供します。さらに、Amazon RDS は、背後で「スタンバイ」を設定して管理します。これはプライマリの最新レプリカになります。スタンバイはフェイルオーバー時に（プライマリに）「昇格」します。フェイルオーバー後、スタンバイはプライマリとなり、お客様のデータベースオペレーションを受け付けるようになります。昇格前には、どの時点においても、スタンバイと直接やりとり (例: 読み込みオペレーション) することはありません。単一の DB インスタンスの容量制限を超えて読み込みトラフィックをスケーリングする方法に関心のあるお客様は、リードレプリカのよくある質問をご覧ください。
マルチ AZ 配置の利点は何ですか?
DB インスタンスをマルチ AZ 配置として実行することの主な利点は、データベースの耐久性と可用性が向上することです。マルチ AZ 配置によって高められる可用性と耐障害性は、本番環境に最適です。
DB インスタンスをマルチ AZ 配置として実行すると、万一 DB インスタンスコンポーネントに障害が発生した場合や、特定のアベイラビリティーゾーンで可用性が失われた場合でも、データの安全が守られます。例えば、プライマリ上のストレージボリュームが障害を受ける場合、Amazon RDS はスタンバイに対して自動的にフェイルオーバーを開始し、お客様のデータベース更新はそのスタンバイですべて完全な状態に保たれます。これは、単一の AZ における標準配備と比較した場合、さらなるデータ堅牢性を提供するものです。単一の AZ における標準配備では、ユーザーによって開始される復元オペレーションが必要で、復元可能な最新時刻 (一般的には過去５分以内) 後に発生した更新は利用できません。
データベースの可用性を向上できることも、DB インスタンスをマルチ AZ 配置として運用する場合の利点の 1 つです。アベイラビリティーゾーンの障害または DB インスタンスの障害が発生した場合、可用性が影響を受けるのは、自動フェイルオーバーが完了するまでの間のみです。Multi-AZ の可用性に対する恩恵は、計画されたメンテナンスにも拡大されます。
例えば、自動バックアップでは、バックアップがスタンバイから取得されるため、お好みのバックアップウィンドウで、プライマリ上での I/O アクティビティが中断されることはありません。パッチの適用や DB インスタンスクラスのスケーリングを行う場合、これらのオペレーションは、自動フェイルオーバーの前にスタンバイで最初に行われます。結果的に、可用性が影響を受けるのは、自動フェイルオーバーが完了するのに必要な時間に限定されます。
DB インスタンスをマルチ AZ 配置として実行することによる暗黙の利点は他にもあります。それは、DB インスタンスのフェイルオーバーが自動で行われ、手動管理が必要ないことです。Amazon RDS のコンテキストでは、これはアベイラビリティゾーンや DB インスタンスの障害時に、(RestoreDBInstanceToPointInTime または RestoreDBInstanceFromSnapshot API を使用して) DB インスタンスのイベントをモニタリングし、手動で DB インスタンスの復旧を開始する必要がないことを意味します。
DB インスタンスをマルチ AZ 配置として実行することにパフォーマンス上の意味がありますか?
自動的に実行される同期的データレプリケーションの結果として、シングルアベイラビリティーゾーンにおける標準 DB インスタンス配置と比較した場合、レイテンシーが増加する可能性があります。
マルチ AZ DB インスタンス配置のセットアップはどのように行うのですか?
マルチ AZ DB インスタンス配置を作成するには、AWS マネジメントコンソールで DB インスタンスを起動する際に、[マルチ AZ 配置] で [はい] のオプションをクリックするだけです。
代わりに、Amazon RDS API を使用している場合は、CreateDBInstance API を呼び出して "マルチ AZ" パラメータの値を "true" に設定することもできます。 既存の標準 (シングル AZ) DB インスタンスをマルチ AZ に変換するには、AWS マネジメントコンソールで DB インスタンスを変更するか、ModifyDBInstance API を使用してマルチ AZ パラメータを true に設定します。
Amazon RDS インスタンスをシングル AZ からマルチ AZ に変換するとどうなりますか?
RDS for PostgreSQL、RDS for MySQL、RDS for MariaDB、RDS for SQL Server、RDS for Oracle、および RDS for Db2 データベースエンジンでは、Amazon RDS インスタンスをシングル AZ からマルチ AZ に変換することを選択すると、次のようになります。
- プライマリインスタンスのスナップショットが取得されます。
- そのスナップショットから新しいスタンバイインスタンスが別のアベイラビリティーゾーンに作成されます。
- 同期レプリケーションがプライマリインスタンスとスタンバイインスタンスとの間に構成されます。
結果として、インスタンスがシングル AZ からマルチ AZ に変換される際には、ダウンタイムは発生しません。ただし、スタンバイのデータがプライマリと一致するように処理されている間は、レイテンシーが増加することがあります。
Amazon RDS によるスタンバイレプリカへのフェイルオーバーは、どのようなイベントのときに発生しますか?
Amazon RDS では、マルチ AZ 配置における一般的な障害シナリオが検出され自動的に復旧されるので、管理者の介入は不要でデータベース操作を可能な限りすみやかに再開できます。Amazon RDS によって自動的にフェイルオーバーが実行されるのは、次のことが発生したときです。
- プライマリ利用可能ゾーンの可用性損失
- プライマリに対するネットワーク接続の喪失
- プライマリ上でのコンピューティングユニット障害
- プライマリ上でのストレージ障害
注: DB インスタンスのスケーリングやシステムアップグレード (OS のパッチ適用など) のオペレーションがマルチ AZ 配置に対して行われるときは、可用性を高めるために、これらが最初にスタンバイに適用されて、その後で自動フェイルオーバーが実行されます。したがって、可用性への影響が現れるのは自動フェイルオーバーを完了するのに必要な時間までとなります。なお、Amazon RDS マルチ AZ 配置での自動フェイルオーバーは、データベース操作におけるエラー (長時間実行クエリ、デッドロック、データベース破損など) の発生に対しては行われません。
Amazon RDS で自動フェイルオーバーが発生する際、アラートは届きますか?
はい。Amazon RDS では DB インスタンスイベントが発行され、自動フェイルオーバーの発生が通知されます。Amazon RDS コンソールの [イベント] セクションをクリックするか、DescribeEvents API を使用して、DB インスタンスに関係のあるイベントについての情報を返すことも可能です。また、Amazon RDS Event Notifications を使用して、特定の DB イベントが発生したときに、通知を受け取ることも可能です。
マルチ AZ のフェイルオーバー中どのようなことが起こるのですか? またこれはどれくらいの間継続するのですか?
フェイルオーバーは Amazon RDS によって自動的に処理されるため、管理者の介入なく、可能な限り迅速にデータベース操作を再開することができます。フェイルオーバーの際には、Amazon RDS は単純に DB インスタンスの正規名レコード (CNAME) を反転させ、スタンバイをポイントします。そしてこのスタンバイが今度は新しいプライマリになります。ベストプラクティスに従い、アプリケーションレイヤーでデータベース接続のリトライを実施することを推奨いたします。
フェイルオーバーは、プライマリで障害が検出されてからスタンバイでトランザクションが再開されるまでの間隔として定義され、通常 1 ～ 2 分以内に完了します。コミットされていない大きなトランザクションを回復させる必要があるかどうかによっても、フェイルオーバー時間は異なります。最適の結果を得るには、マルチ AZ では十分に大きなインスタンスタイプを使用することをお勧めします。また、高速かつ予測可能で、安定したスループットパフォーマンスを得るには、マルチ AZ インスタンスとともにプロビジョンド IOPS を使用することをお勧めします。
マルチ AZ DB インスタンス配置に対して "強制フェイルオーバー" を開始できますか?
Amazon RDS は、さまざまな障害状態のときにユーザーが介入しなくても、自動的にフェイルオーバーを行います。さらに、Amazon RDS ではインスタンスが再起動されたときにフェイルオーバーを開始することもできます。この機能にアクセスするには、AWS マネジメントコンソールを使用するか、RebootDBInstance API コールを使用してください。
マルチ AZ の同期レプリケーションはどのようにコントロール/設定するのですか?
マルチ AZ 配置を使用するには、"Multi-AZ" パラメータを true に設定するだけです。スタンバイ、同期的レプリケーションおよびフェイルオーバーの作成は、すべて自動的に処理されます。つまり、スタンバイが配置されているアベイラビリティーゾーンを選択したり、利用可能なスタンバイ数を変更したりすることはできません (Amazon RDS は、DB インスタンスプライマリごとに 1 つの専用スタンバイを設定します)。また、スタンバイは、データベースの読み取りアクティビティを許可するよう設定できません。マルチ AZ 配置の詳細はこちら。
スタンバイはプライマリと同一のリージョンになりますか?
はい。スタンバイは、DB インスタンスプライマリと同一のリージョンの異なるアベイラビリティーゾーンに自動的にプロビジョニングされます。
私のプライマリが現在所在するアベイラビリティーゾーンを確認できますか?
はい。AWS マネジメントコンソールまたは DescribeDBInstances API を使用することで、現在のプライマリの場所を確認できます。
フェイルオーバー後、プライマリは他の AWS リソース (EC2 インスタンスなど) と異なるアベイラビリティーゾーンに所在するようになります。レイテンシーは懸念材料ですか?
アベイラビリティーゾーンは、同一リージョンの別のアベイラビリティーゾーンに対して低レイテンシーでネットワーク接続できるように設計されています。さらに、1 つのアベイラビリティーゾーンでサービスに障害が発生してもお客様のアプリケーションが柔軟性を保てるよう、複数のアベイラビリティーゾーン全体で冗長性を持つようにアプリケーションや他の AWS リソースのアーキテクチャーを設計することも検討できます。マルチ AZ 配置は、お客様サイドでの管理作業なく、データベース層に対するこのニーズを解決します。
DB スナップショットと自動バックアップは、マルチ AZ 配置とどのように連携しますか?
自動バックアップと DB スナップショットの機能の扱い方は、シングル AZ での標準的な配置とマルチ AZ 配置のどちらで実行するかにかかわらず同一です。マルチ AZ 配置で実行している場合は、自動バックアップと DB スナップショットはスタンバイから取得されます。これは、プライマリでの I/O 中断を避けるためです。なお、単一 AZ とマルチ AZ のどちらの配置の場合も、バックアップ取得中は I/O レイテンシーが増加する可能性があることにご注意ください（一般的には数分で元に戻ります）。
復元操作（特定時点への復元または DB スナップショットからの復元）についても、マルチ AZ 配置での機能は標準の単一 AZ 配置の場合と同じです。新しい DB インスタンスの配置は、RestoreDBInstanceFromSnapshot または RestoreDBInstanceToPointInTime API のどちらかで作成できます。これらの新しい DB インスタンスの配置は、ソースバックアップが標準配置で開始されていても、マルチ AZ 配置で開始されていても、それとは無関係に標準またはマルチ AZ のどちらかに設定できます。