Amazon Web Services ブログ

Amazon RDS Under the Hood: シングル AZ インスタンスのリカバリ

アマゾン ウェブ サービス (AWS) のお客様は、あらゆる種類のワークロードのデータを保存するために Amazon Relational Database Service (Amazon RDS) を使用しています。ハイアベイラビリティ (HA) の場合、Amazon RDS のマルチ AZ 機能を使用して、異なるアベイラビリティーゾーン (AZ) 間でデータのコピーを 2 つ維持することにより、復元力を強化できます。この機能については、ブログ記事「Amazon RDS Under the Hood: Multi-AZ」で説明しています。

失敗は稀ですが、ベストプラクティスとして、アプリケーションは潜在的な失敗を回避するように設計する必要があります。RDS マルチ AZ 設定は、短いRTO (リカバリ時間目標) および RPO (リカバリポイント目標) の要件をサポートできるため、本番環境で推奨されるアプローチです。RTO は、障害発生時にリカバリが完了するまでの目標時間数です。 RPO は、障害発生時にデータが損失の危険にさらされている間の目標時間数です。

毎月何百万ものアクティブな顧客が AWS を使用しているため、RDS マルチ AZ が提供するレベルの HA とそれに関連する追加コストを必要としない顧客ワークロードがいくつかあります。これらのワークロードでは RTO と RPO の要件が緩和されている可能性があり、これらのニーズを満たすにはシングル AZ 設定で十分な可能性があります。ただし、シングル AZ のみのソリューションに着手する前に、シングル AZ RDS インスタンスのリカバリの期待値と、どのようなシナリオがあるかを理解する必要があります。

この投稿では、MySQL、MariaDB、PostgreSQL、Oracle、および Microsoft SQL Server データベースが、Amazon RDS シングル AZ RTO と RPO で何を期待できるかについて説明します。 Amazon Aurora は、クラウド用に設計されたさまざまなテクノロジーとストレージサブシステムを使用しています。その単一インスタンスのリカバリプロセスとシナリオの説明は、Aurora FAQ で見つけることができます

設計コンセプト

各 RDS インスタンスは、ストレージのために Amazon EBS ボリュームでバックアップされた Amazon EC2 インスタンス上で実行されます。 RDS は毎日データベースのスナップショットを撮ります。これは Amazon S3 に永続的に保存されます。また、トランザクションログを定期的に S3 にコピーし (最大 5 分間隔で)、必要に応じてポイントインタイムリカバリを実行します。ポイントインタイムリカバリは RDS では自動ではありません。手動で、またはイベントの一部としてスクリプトを介して、それをトリガーしなければなりません。このリカバリは新しい RDS インスタンスで作成されます。

RDS シングル AZ インスタンスの障害によるリカバリの RTO は、数分から数時間とまちまちです。時間の長さは、この記事の後半で説明するように、データベースのサイズ、障害の種類と必要なリカバリ方法によって異なります。

RDS シングル AZ インスタンスの障害にともなうリカバリの RPO は通常 5 分 (トランザクションログを Amazon S3 にコピーするのに必要なインターバル) ですが、異なる場合もあります。これを確認するには、RDS:describe-db-instances:LatestRestorableTime を呼び出します。このサービスにより、ポイントインタイム復元でデータベースを復元できる最新の時刻が返されます。

RDS シングル AZ インスタンスを使用して障害に備えた設計および計画を行う際は、次のシナリオを検討します。

  • 回復可能なインスタンス障害 – 個々の EC2 ノードでハードウェア障害が発生したが、RDS によって自動的に復旧される可能性がある場合。
  • 回復不能なインスタンス障害 – 個々の EC2 ノードでハードウェア障害が発生し、RDS によってが自動的に回復されることはない場合。
  • EBS ボリューム障害 – EBS ボリュームにデータ損失障害が発生した場合。
  • アベイラビリティーゾーンの中断 – アベイラビリティーゾーンレベルでの障害で、RDS インスタンスに影響を与える可能性がある場合。

次のセクションでは、これらのシナリオに対するリカバリの期待値について説明します。

回復可能なインスタンス障害

基になる EC2 インスタンスに障害が発生すると、Amazon RDS インスタンスに障害が発生します。これが発生すると、直面している問題に固有のイベント通知がお客様に送信され、警告を行います (詳細については、「Using Amazon RDS Event Notification」をご覧ください)。ただし、RDS インスタンスの状況は利用可能のままです。

RDS は自動的に同じアベイラビリティーゾーンで新しいインスタンスを起動し、EBS ボリュームをアタッチしてリカバリを試みます。このシナリオでは、RTO は通常 30 分以内です。この場合、EBS ボリュームが回復したため、RPO はゼロです。

EBS ボリュームは単一のアベイラビリティーゾーンにあり、このリカバリは元のインスタンスと同じアベイラビリティーゾーンで行われます。  進行中に加えられたデータおよびテーブルの変更は、障害発生前に完全にコミットされておらず、完了していない可能性があります。  RDS DNS 名はシングル AZ インスタンスでは変更されないため、接続エンドポイントは変わりません。

回復不能なインスタンス障害、または EBS ボリューム障害

RDS インスタンスのリカバリの試みに失敗した場合、または基になる EBS ボリュームでデータ損失の障害が発生した場合、インスタンスの状態は failed となります。この状況では、ポイントインタイムリカバリが必要です。AWS Lambda スクリプトを使用して復旧を自動化することも、手動で復旧することもできます。

RTO のタイミングでは、新しい Amazon RDS インスタンスを起動し、最後のバックアップ以降のすべての変更を適用する必要があります。 RPO は通常 5 分ですが、RDS:describe-db-instances:LatestRestorableTime を呼び出すことで確認することができます。この時間は、適用する必要があるログ数に応じて、10 分から数時間の範囲で変わります。 データベースのサイズ、最後のバックアップ以降に行われた変更の数、データベースのワークロードレベルによって異なるため、テストを行う必要があります。RDS バックアップとトランザクションログは Amazon S3 に保存されるため、このリカバリは、リージョン内のサポートされているどのアベイラビリティーゾーンでも可能です。

新しい RDS インスタンスが作成されると、新しい DNS 名も作成されます。アプリケーションを新しい DNS 名にポイントできます。古い DB インスタンスのエンドポイント名を使用して、新しく復元された DB インスタンスの名前を変更することもできます。これは、アプリケーションの ODBC/JDBC 設定の構成を変更するのが困難または不可能なときに実行できます。それには、最初に失敗した古いインスタンスを削除する必要があります。しかし、削除を行うとAWS サポートが問題の根本的な原因をトラブルシューティングすることができなくなるため、必要な場合にのみ行ってください。

アベイラビリティーゾーンの障害

アベイラビリティーゾーンの障害が起こる可能性は低く、起こっても通常は一時的なものです。アベイラビリティーゾーンの障害がより恒久的なものである場合、インスタンスは failed 状態になります。リカバリは前述のように機能し、ポイントインタイムリカバリを使用して別のアベイラビリティーゾーンに新しいインスタンスを作成できる可能性があります。このシングル AZ インスタンスはアーキテクチャ全体に組み込まれているため、手動またはスクリプトでこの手順を自分で実行する必要があります。そしてこのリカバリシナリオの戦略は、より大規模な障害復旧 (DR) 計画の一部になります。

アベイラビリティーゾーンの障害が一時的なものである場合、データベースは停止しますが、available な状態のままです。アプリケーションレベルを監視したり、他のサードパーティ製ツールを使用したりしてこのシナリオを検出するのは、ユーザーの責任です。この場合、アベイラビリティーゾーンが回復するのを待つか、またはポイントインタイムリカバリを使用してインスタンスを別のアベイラビリティーゾーンにリカバリすることを選択できます。

RTO は、新しい RDS インスタンスを起動し、最後のバックアップ以降に行ったすべての変更を適用するのにかかる時間です。RPO は、もっと長くなる可能性があります (最長でアベイラビリティーゾーンの障害が発生した時点まで)。

考慮事項

RDS シングル AZ インスタンスでバックアップおよびスナップショットを操作している間、I/O パフォーマンスが影響を受けます。MariaDB、MySQL、Oracle、PostgreSQL の場合、RDS インスタンスへのすべての I/O は、バックアップ中およびスナップショット中に一時的に中断されます。これは、バックアップをスケジュールしたりスナップショットを実行したりするときに重要な考慮事項です。

RDS シングル AZ インスタンスの場合、OS にパッチを適用すると、フェイルオーバーの代替手段がないため、可用性とパフォーマンスに影響します。パッチ適用はメンテナンス期間中に行われ、システムはパッチ適用中は使用できません。

可用性を最大化するために、マルチ AZ インスタンスは最初にスタンバイ中の OS にパッチを適用し、次にマスターインスタンスの OS にパッチを適用します。どちらの場合も、システムは RDBMS の更新中は使用できません。

Amazon RDS サービスレベルアグリーメントに適用するには、マルチ AZ RDS の配置も必要です。

結論

AWS は、ベストプラクティスとして、Well-Architected Framework の信頼性の柱の一部として RDS マルチ AZ 配置を使用することをお勧めします。ただし、可用性の要件とコストの削減を考慮して、RDS シングル AZ インスタンスを使用できます。シングル AZ RDS インスタンスの RTO および RPO の期待値を理解することで、可用性、リスク、およびコストといった情報に基づいて決定を下すことができます。

 

著者について

Wesley Wilk は、アマゾン ウェブ サービスのソリューションアーキテクトです。

 

 

 

 

David Gardner は、アマゾン ウェブ サービスのシニアソリューションアーキテクトです。