Amazon RDS Under the Hood: Multi-AZ

Amazon Web Services (AWS)のお客様はデータストアと、そのデータストアの高可用性にお客様のビジネスを委ねています。そのようなお客様に向けて、Multi-AZ配置は高可用性を実現する方法を容易に提供します。

Amazon Relational Database Service (Amazon RDS)でMulti-AZを有効にすることで、データの冗長かつ一貫した状態を維持します。もし、primaryデータベースサーバに問題が発生した場合は、standbyデータベースサーバに自動的に変更しデータへアクセスし続けられるようにします。2つのデータのコピーはそれぞれ別のAvailability Zones (AZs)内で管理されています(そのため、Multi-AZと呼ばれています)。別々のAvailability Zones を持つことで、両方のデータが同時に障害に見舞われるリスクを軽減させています。データの適切な管理、簡単な再構成、およびコピーへの信頼できるユーザーアクセスは、顧客環境が要求する高可用性要件に対処するための鍵です。

この投稿では、MySQL、MariaDB、PostgreSQL、およびOracleデータベースインスタンスのAmazon RDS Multi-AZ設定について説明します。Amazon RDS for SQL ServerおよびAmazon Auroraは、異なるテクノロジースタックを使用してマルチAZ機能を提供します。

基本デザイン

Mult-AZ機能はデータベースアプリケーションとAmazon Elastic Block Store(Amazon EBS)ボリュームの間にあるレプリケーションレイヤーを使用して実装されています。このレイヤーは、アプリケーションの読み取りおよび書き込み要求を処理し、2つの個別のEBSボリュームコピーがある環境に適用されます。1つはローカルアクセス、もう1つはリモートアクセスです。

通常時は、レプリケーションレイヤーがインストールされた、2つのアクティブなAmazon EC2インスタンスがあります。 各インスタンスは、データの完全なコピーが行われているEBSボリュームを管理しています。この構成により、2つのインスタンスとそのボリュームがMulti-AZデータベースインスタンスとして稼働しています。 レプリケーションレイヤーは、TCP接続を介して互いに直接通信を行っています。

各インスタンスには特定のロールが割り当てられます。1つはプライマリであり、ユーザーがデータにアクセスするための外部エンドポイントを提供します。もう1つはスタンバイであり、プライマリから受信するすべてのデータを同期的に書き込むセカンダリインスタンスとして機能します。データベースの書き込みは、正常応答が呼び出し側アプリケーションに送り返される前に、データが両方のボリュームに適切に書き込まれます。ただし、読み取り操作は常にプライマリEBSボリュームを介して実行されます。データベースサーバープロセスは、スタンバイインスタンスで実行されていないため外部エンドポイントは公開されません。そのため、ユーザーはstandbyデータベースインスタンス上のデータのコピーは使用できません。

可用性を向上させるためにMulti-AZは、インスタンスの1つがプライマリロールにあることを一貫して保証し、データのコピーへのアクセスを提供します。もし可用性の問題が発生した場合、スタンバイインスタンスを自動的にプライマリロールに昇格させ、リダイレクトによって可用性を復元させます。 このイベントは、フェイルオーバーと呼ばれます。旧プライマリがまだ稼働している場合、スタンバイロールに降格されます。

新しいプライマリインスタンスへのリダイレクトは、DNSを介して提供されます。クライアントDNSクエリの結果に含まれるレコードのTTLは非常に短くなっています。アドレス情報の長期間のキャッシングを禁止することを目的としています。これにより、クライアントはフェールオーバープロセスで情報をより早く更新し、DNSリダイレクトの変更をより迅速に取得します。

以下の図が正常時のMulti-AZインスタンスの状態を示しています。

Figure 1: Multi-AZ instance

データベースアプリケーション(黄色で表示されるDB APP)は、DNS)オレンジ色で表示)使用して、データへのアクセスを提供している現在の外部エンドポイントのアドレス情報を取得します。

このマルチAZインスタンスには2つのRDS DBインスタンスがあります。プライマリインスタンス(左側に緑色で表示)とスタンバイインスタンス)右側に青色で表示)です。この例では、DNSはアプリケーションをプライマリインスタンスEC2＃1に向けており、Availability Zone＃1で利用可能なEBS＃1のプライマリコピーを提供しています。2つのEC2インスタンスの複製レイヤーが接続されています。アプリケーションが発行する書き込み操作は、2番目のインスタンスへの書き込みにもなります(パスは灰色で表示)。

レプリケーションレイヤーは、それ自体の可視性が制限されているため、より詳細な決定を下すことができません。たとえば、クライアントからの接続問題、ローカルまたはregionの停止、または予期せずサイレントな状態になったEC2ピアの状態などを知るすべがありません。このため、2つのインスタンスは、より重要な情報にアクセスし、インスタンスのステータスを定期的に監視する外部システムによって監視および管理されています。必要に応じて、管理システムは、可用性とパフォーマンスの要件が満たされてるためのアクションを実行します。

Multi-AZが提供する可用性と耐久性の改善は、最小限のパフォーマンスコストで実現しています。通常の使用例では、レプリケーションレイヤーが接続され、スタンバイEBSボリュームへの同期書き込み操作が発生します。スタンバイインスタンスとボリュームは、地理的に離れた個別のAvailability Zoneに配置されています。評価では、データベースのコミットへのオーバーヘッドが2ミリ秒から5ミリ秒増加していることが示されています。ただし、実際の使用例に対する実際の影響は、ワークフローに大きく依存します。ほとんどのお客様のMulti-AZインスタンスは、影響があったとしてもパフォーマンスにわずかな影響を示します。

この設計により、AWSはお客様のデータに対して99.95％の可用性を超えるサービスレベルアグリーメント(SLA)を提供しております。詳細については、Amazon RDSサービスレベルアグリーメントをご覧ください。

実装について

ボリューム複製機能の設計は単純で簡単だと思われるかもしれません。しかし、実際の実装はかなり複雑です。これは、絶えず変化し、時には大きく変動する環境内で、2つのネットワークで接続された個別のインスタンスおよびボリュームが遭遇する可能性があるすべての事象を考慮する必要があるためです。

通常の進行中のレプリケーションは、すべてが適切に機能し、正常に動作していることを前提としています。EC2インスタンスが利用可能で、通常のインスタンス監視が機能し、EBSボリュームが利用可能で、ネットワークが期待どおりに動作しています。しかし、これらのピースの1つ以上が誤動作しているとどうなるでしょうか？ 発生する可能性のある問題とその対処方法を見てみましょう。

接続に関する問題と同期

問題または意図的な管理アクションのために、プライマリインスタンスとスタンバイインスタンスが相互に接続されていない場合があります。継続的な複製は不可能であり、接続が復元されるまで長時間待つことは受け入れられません。接続が失われるか、意図的に中断されると、インスタンスは一時的に一時停止し、管理システムによる決定を待ちます。管理システムはこの状態を検出すると、使用可能なインスタンスにプライマリロールを引き継ぎ、複製なしで独自に処理を続行するよう指示します。現在、データのコピーは1つだけで、もう1つのコピーはますます古くなっています。

接続性の問題は通常調査され、多くの場合、問題はすぐに修正されます。問題が既定値を超えて続く場合、オペレーターが調査を行います。したがって、接続の問題の大部分は比較的短い状態であり、2つのインスタンスはすぐに接続が復元されることが期待されます。接続が復元した後、通常の進行中のレプリケーション状態に戻る前に、ボリュームの再同期を行う必要があります。

再同期プロセスにより、データの両方のコピーが一貫した状態に復元されます。再同期に必要な時間を短縮するために、プライマリは2つのインスタンスが切断されている間に変更されたブロックを追跡します。再同期が発生すると、それらの変更のみをプライマリインスタンスからスタンバイインスタンスに送信するだけでよく、プロセスが高速化されています。

動的な環境での耐障害性

AWSは大規模で非常に動的な環境であり、Amazon RDS Multi-AZはソフトウェアとハ​​ードウェアの中断が発生した場合に介入してアクションを起こすように設計されています。

障害が発生した場合、インスタンスまたはボリュームの可用性の問題は最も一般的なケースであり、単純なフェイルオーバー操作を実行することで主に解決されます。これにより、スタンバイインスタンスとボリュームを通じて可用性が復元されます。

万が一、ボリュームに障害が発生した場合、新しいボリュームと交換されます。交換のプロセスは、残っているボリュームのスナップショットを保護することから始まります。これは主に耐久性の理由によるものですが、ボリュームのその後の再同期のパフォーマンスを向上させるのにも役立ちます。その後、インスタンスは新しいボリュームに接続されます。完了すると、ボリュームが再同期され、レプリケーションが復元されます。

インスタンスまたはボリュームの交換は、コンポーネントが規定外の動作を示す状況でもオプションになる可能性があります。たとえば、待ち時間の大幅な増加または長期間の増加または帯域幅の減少は、リソースへの経路に問題があることを示している可能性があります。このような状況では、交換が永続的な解決策になると予想されます。置換はパフォーマンスに影響する可能性があるため、必要な場合にのみ実行されることに注意してください。

AWSリージョンまたはアベイラビリティーゾーン全体が影響を受ける状況があります。たとえば、極端な天候や広範囲にわたる停電などです。これらの状況では、Multi-AZ インスタンスが引き続き利用できるように特別な注意が払われます。問題をより深刻な状況に拡大しないように注意する必要があります。管理システムはリージョンの可用性情報を使用して、根本的な問題が解決されるまで不必要な自動回復アクションを一時停止します。

まとめ

Amazon RDS Multi-AZ構成により、お客様のデーターの可用性と耐久性が向上します。 問題検出のための自動監視と、中断が発生した場合に可用性を復元するためのその後の修正アクションにより、Multi-AZはデータが損なわれないようにします。 詳細については、 Amazon RDS High Availabilityを参照してください。

原文: Amazon RDS Under the Hood: Multi-AZ

About the Author

John Gemignani is a principal software engineer in RDS at Amazon Web Services.