Cloud SQL データベースの障害復旧

MySQL   |  PostgreSQL   |  SQL Server

このページでは、Cloud SQL での障害復旧について説明します。

概要

Google Cloud のデータベースの障害復旧（DR）は、特にリージョンで障害が発生した場合やリージョンが使用不可になった場合に、処理の継続性を実現することが目的です。Cloud SQL はリージョン サービスです（Cloud SQL が HA 用に構成されている場合）。したがって、Cloud SQL データベースをホストする Google Cloud リージョンが使用不可になると、Cloud SQL データベースも使用できなくなります。

処理を続行するには、できるだけ早くセカンダリ リージョンでデータベースを利用できるようにする必要があります。DR 計画では、Cloud SQL にクロスリージョン リードレプリカを構成する必要があります。エクスポート / インポートによるフェイルオーバーも可能ですが、この方法は特に大規模なデータベースの場合は長時間かかります。

クロスリージョン フェイルオーバー構成を保証するビジネス シナリオの例を以下に示します。

• ビジネス アプリケーションのサービスレベル契約は、リージョンの Cloud SQL サービスレベル契約（99.95% の可用性）を超えています。別のリージョンにフェイルオーバーすることで、サービスの停止を軽減できます。
• ビジネス アプリケーションのすべての階層はすでにマルチリージョンであり、リージョンが停止した場合も処理を続行できます。クロスリージョン フェイルオーバー構成により、データベースの継続的な可用性を確保できます。
• 要求される目標復旧時間（RTO）と目標復旧地点（RPO）は、時間単位ではなく分単位です。別のリージョンへのフェイルオーバーは、データベースの再作成よりも高速です。

通常、DR プロセスには 2 つのパターンがあります。

• データベースがセカンダリ リージョンにフェイルオーバーします。データベースの準備ができてアプリケーションで使用されると、そのデータベースが新たにプライマリ データベースになり、その後もプライマリ データベースを継続します。
• データベースがセカンダリ リージョンにフェイルオーバーしても、プライマリ リージョンが障害から回復すると、プライマリ リージョンにフォールバックします。

この Google Cloud SQL データベースの障害復旧の概要では、2 番目のバリアントについて説明します。これは、障害が発生したデータベースが回復し、プライマリ リージョンにフォールバックするケースです。この DR プロセスは、ネットワークのレイテンシや、プライマリ リージョンでのみ利用可能なリソースがあるため、プライマリ リージョンで実行する必要があるデータベースに特に適しています。このパターンを使用すると、データベースはプライマリ リージョンでサービスが停止している間のみ、セカンダリ リージョンで実行されます。

この DR ドキュメントに関連するチュートリアルは次のとおりです。

• Cloud SQL for MySQL の障害復旧: 完全なフェイルオーバーとフォールバック プロセス
• Cloud SQL for PostgreSQL の障害復旧: 完全なフェイルオーバーとフォールバック プロセス

DR アーキテクチャ

次の図は、HA Cloud SQL インスタンスのデータベース DR をサポートする最小限のアーキテクチャを示しています。

このアーキテクチャは次のように機能します。

• Cloud SQL の 2 つのインスタンス（プライマリ インスタンスとスタンバイ インスタンス）は、単一のリージョン（プライマリ リージョン）内の 2 つの別々のゾーンにあります。インスタンスは、リージョン永続ディスクを使用して同期されます。
• Cloud SQL（クロスリージョン リードレプリカ）の 1 つのインスタンスが 2 番目のリージョン（セカンダリ リージョン）にあります。DR の場合、クロスリージョン リードレプリカは、リードレプリカの設定を使用して（非同期レプリケーションを使用）プライマリ インスタンスとの同期をとるように設定されます。

プライマリ インスタンスとスタンバイ インスタンスは、同じリージョン ディスクを共有しているため、インスタンスの状態は同一です。

この設定では非同期レプリケーションを使用するため、クロスリージョン リードレプリカがプライマリ インスタンスの後で遅延する可能性があります。フェイルオーバーが発生すると、クロスリージョン リードレプリカは RPO ゼロに対応する場合があります。

基本的な DR プロセスの概要

プライマリ リージョンが使用不可になって、プライマリ インスタンスがフェイル オーバーしてセカンダリ リージョンで処理を再開すると、基本 DR プロセスが開始されます。DR プロセスは、手動または自動で実行されるべき運用ステップを規定し、リージョン障害を軽減して、セカンダリ リージョンで実行するプライマリ インスタンスを確立します。

次の図は、DR プロセスを示しています。

この DR プロセスは以下の手順で構成されます。

1. プライマリ インスタンスを実行しているプライマリ リージョン（R1）が使用不可になります。
2. オペレーション チームが障害を認識して正式に応答し、フェイルオーバーが必要かどうかを判断します。
3. フェイルオーバーが必要な場合は、セカンダリ リージョン（R2）のクロスリージョン リードレプリカが新しいプライマリ インスタンスになります。
4. クライアント接続が再構成されて、新しいプライマリ インスタンスで処理を再開し、R2 のプライマリ インスタンスにアクセスします。

この基本的なプロセスにより、稼働中のプライマリ データベースが再び確立されます。ただし、新しいプライマリ インスタンス自体には、スタンバイ インスタンスとクロスリージョン リードレプリカがある完全な DR アーキテクチャは確立されていません。

完全な DR プロセスの概要

完全な DR プロセスにより、単一のプライマリ インスタンス（新しいプライマリ）が HA に対して有効になり、クロスリージョン リードレプリカが確保されます。また、完全な DR プロセスは、元のプライマリ リージョンでの元のデプロイへのフォールバックも実施します。

セカンダリ リージョンにフェイルオーバーする

完全な DR プロセスでは、フェイルオーバー後に完全な DR アーキテクチャを確立するためのステップを追加することで、基本的な DR プロセスを拡張します。次の図は、フェイルオーバー後の完全なデータベース DR アーキテクチャを示しています。

完全なデータベースの DR プロセスは、次の手順で構成されます。

1. プライマリ データベースを実行しているプライマリ リージョン（R1）が使用できなくなります。
2. オペレーション チームが障害を認識して正式に応答し、フェイルオーバーが必要かどうかを判断します。
3. フェイルオーバーが必要な場合は、セカンダリ リージョン（R2）のクロスリージョン リードレプリカをプロモートして、新しいプライマリ インスタンスにできます。
4. クライアント接続が、新しいプライマリ インスタンス（R2）にアクセスして処理するように再構成されます。
5. R2 で新しいスタンバイ インスタンスが作成され、プライマリ インスタンスに追加されます。スタンバイ インスタンスは、プライマリ インスタンスとは異なるゾーンにあります。プライマリ インスタンスのスタンバイ インスタンスが作成されたため、プライマリ インスタンスの可用性が向上しました。
6. 3 番目のリージョン（R3）では、新しいクロスリージョン リードレプリカが作成され、プライマリ インスタンスに接続されます。この時点で、完全な障害復旧アーキテクチャが再構築され、運用が可能になります。

ステップ 6 を実装する前に元のプライマリ リージョン（R1）が使用可能になると直ちに、クロスリージョン リードレプリカはリージョン R3 ではなくリージョン R1 に配置できるようになります。この場合は、元のプライマリ リージョン（R1）へのフォールバックの複雑性が低減し、必要とする手順が減少します。

スプリットブレイン状態を回避する

プライマリ リージョン（R1）の障害が発生しても、R1 が再び使用可能になったときに元のプライマリ インスタンスとスタンバイ インスタンスが、自動によるシャットダウンまたは削除が行われることなどにより、アクセス不可になることはありません。R1 が使用できるようになると、クライアントは（偶発的であっても）元のプライマリ インスタンスのデータの読み取りと書き込みを行うことができます。この場合、スプリットブレイン状態になる可能性があり、一部のクライアントが古いプライマリ データベースの古いデータにアクセスし、他のクライアントが新しいプライマリ データベースの最新データにアクセスして、ビジネス上の問題が起きる可能性があります

スプリットブレイン状態を回避するには、R1 が使用可能になった後でクライアントが元のプライマリ インスタンスにアクセスできないようにする必要があります。クライアントが新しいプライマリ インスタンスの使用を開始する前に、元のプライマリをアクセス不可にし、アクセス不可にした直後に元のプライマリを削除することをおすすめします。

フェイルオーバー後の初期バックアップの確立

クロスリージョン リードレプリカをフェイルオーバーの新しいプライマリに昇格させると、新しいプライマリ内のトランザクションと元のプライマリのトランザクションが完全には同期されないことがあります。したがって、こうしたトランザクションは新しいインスタンスでは使用できません。

ベスト プラクティスとして、フェイルオーバーの開始時とクライアントがデータベースにアクセスする前に、新しいプライマリ インスタンスを直ちにバックアップすることをおすすめします。このバックアップは、フェイルオーバー発生時点の整合性がとれた既知の状態を表しています。このようなバックアップは、新しいプライマリにアクセスするときにクライアントで問題が発生した場合に、規制を行う、または既知の状態に戻すうえで重要であることが考えられます。

元のプライマリ リージョンへのフォールバック

前述したように、このチュートリアルでは元のリージョン（R1）にフォールバックする手順を説明します。フォールバック プロセスには 2 つのバージョンがあります。

• 第 3 リージョン（R3）で新しいクロスリージョン リードレプリカを作成した場合は、プライマリ リージョン（R1）に別の（2 番目の）クロスリージョン リードレプリカを作成する必要があります。
• プライマリ リージョン（R1）で新しいクロスリージョン リードレプリカを作成した場合、R1 で別のクロスリージョン リードレプリカを新たに作成する必要はありません。

R1 のクロスリージョン リードレプリカが存在する場合、Cloud SQL インスタンスは R1 にフォールバックできます。このフォールバックはサービスの停止によってではなく、手動でトリガーされるため、このメンテナンス作業に適した日時を選択できます。

したがって、プライマリ、スタンバイ、クロスリージョン リードレプリカを備えた完全な DR を実現するには、2 回のフェイルオーバーが必要になります。1 回目のフェイルオーバーは、サービスの停止によってトリガーされます（真のフェイルオーバー）。2 回目のフェイルオーバーによって、出発点となるデプロイが再確立されます（フォールバックまたはスイッチオーバー）。

次のステップ

• Cloud SQL for MySQL の障害復旧のチュートリアルを試す。

• Google Cloud に関するリファレンス アーキテクチャ、図、チュートリアル、ベスト プラクティスを確認する。Cloud Architecture Center を確認します。