このページでは、Cloud SQL での障害復旧について説明します。
概要
Google Cloud のデータベースの障害復旧（DR）は、特にリージョンで障害が発生した場合やリージョンが使用不可になった場合に、処理の継続性を実現することが目的です。Cloud SQL はリージョン サービスです（Cloud SQL が高可用性（HA）用に構成されている場合）。したがって、Cloud SQL データベースをホストする Google Cloud リージョンが使用不可になると、Cloud SQL データベースも使用できなくなります。
処理を続行するには、できるだけ早くセカンダリ リージョンでデータベースを利用できるようにする必要があります。このような DR 計画を実現するには、Cloud SQL の中でクロスリージョン リードレプリカを構成する必要があります。エクスポート / インポートまたはバックアップ / 復元によるフェイルオーバーも可能ですが、この方法では所要時間が長くなり、特に大規模なデータベースの場合は顕著です。
クロスリージョン フェイルオーバー構成を使用するのが適切であるビジネス シナリオの例を以下に示します。
- ビジネス アプリケーションのサービスレベル契約が、リージョンの Cloud SQL サービスレベル契約（Cloud SQL エディションに応じて 99.99% の可用性）を超えています。別のリージョンにフェイルオーバーすることで、サービスの停止を軽減できます。
- ビジネス アプリケーションのすべての階層はすでにマルチリージョンであり、リージョンが停止した場合も処理を続行できます。クロスリージョン フェイルオーバー構成により、データベースの継続的な可用性を確保できます。
- 要求される目標復旧時間（RTO）と目標復旧地点（RPO）は、時間単位ではなく分単位です。別のリージョンへのフェイルオーバーは、データベースの再作成よりも高速です。
通常、DR プロセスには 2 つのパターンがあります。
- データベースがセカンダリ リージョンにフェイルオーバーします。データベースの準備ができてアプリケーションで使用されると、そのデータベースが新たにプライマリ データベースになり、その後もプライマリ データベースを継続します。
- データベースがセカンダリ リージョンにフェイルオーバーしても、プライマリ リージョンが障害から回復すると、プライマリ リージョンにフォールバックします。
この Google Cloud SQL データベースの障害復旧の概要では、2 番目のバリアントについて説明します。これは、障害が発生したデータベースが回復し、プライマリ リージョンにフォールバックするケースです。この DR プロセスは、ネットワークのレイテンシや、プライマリ リージョンでのみ利用可能なリソースがあるため、プライマリ リージョンで実行する必要があるデータベースに特に適しています。このパターンを使用すると、データベースはプライマリ リージョンでサービスが停止している間のみ、セカンダリ リージョンで実行されます。
障害復旧アーキテクチャ
次の図は、HA Cloud SQL インスタンスのデータベース DR をサポートする最小限のアーキテクチャを示しています。
このアーキテクチャは次のように機能します。
- Cloud SQL の 2 つのインスタンス（プライマリ インスタンスとスタンバイ インスタンス）は、単一のリージョン（プライマリ リージョン）内の 2 つの別々のゾーンにあります。インスタンスは、リージョン永続ディスクを使用して同期されます。
- Cloud SQL（クロスリージョン リードレプリカ）の 1 つのインスタンスが 2 番目のリージョン（セカンダリ リージョン）にあります。DR の場合、クロスリージョン リードレプリカは、リードレプリカの設定を使用して（非同期レプリケーションを使用）プライマリ インスタンスとの同期をとるように設定されます。
プライマリ インスタンスとスタンバイ インスタンスは、同じリージョン ディスクを共有しているため、インスタンスの状態は同一です。
この設定では非同期レプリケーションを使用するため、クロスリージョン リードレプリカがプライマリ インスタンスの後で遅延する可能性があります。そのため、フェイルオーバーが発生した場合、クロスリージョン リードレプリカの RPO はゼロではない可能性があります。
障害復旧（DR）プロセス
障害復旧（DR）プロセスは、プライマリ リージョンが使用不可になったときに開始します。セカンダリ リージョンで処理を再開するには、クロスリージョン リードレプリカをプロモートすることによってプライマリ インスタンスのフェイルオーバーをトリガーします。DR プロセスでは、リージョン障害を軽減してセカンダリ リージョンでのプライマリ インスタンスの稼働を確立するために、手動または自動で実行する必要のある運用ステップが規定されます。
次の図は、DR プロセスを示しています。
この DR プロセスは以下の手順で構成されます。
- プライマリ インスタンスを実行しているプライマリ リージョン（R1）が使用不可になります。
- オペレーション チームがこの障害を認識して正式に認め、フェイルオーバーが必要かどうかを判断します。
- フェイルオーバーが必要な場合は、セカンダリ リージョン（R2）にあるクロスリージョン リードレプリカをプロモートして新しいプライマリ インスタンスにすることができます。
- クライアント接続が再構成されて新しいプライマリ インスタンスでの処理が再開し、R2 のプライマリ インスタンスにアクセスされるようになります。
この初期プロセスによって、プライマリ データベースが稼働する状態が再び確立します。ただし、完全な DR アーキテクチャ（新しいプライマリ インスタンス自体にスタンバイ インスタンスとクロスリージョン リードレプリカがある）は確立しません。
完全な DR プロセスによって、単一のインスタンス（新しいプライマリ）が HA に対して有効になり、クロスリージョン リードレプリカを持つ状態になります。また、完全な DR プロセスは、元のプライマリ リージョンでの元のデプロイへのフォールバックも実施します。
セカンダリ リージョンにフェイルオーバーする
完全な DR プロセスでは、フェイルオーバー後に完全な DR アーキテクチャを確立するためのステップを追加することで、基本的な DR プロセスを拡張します。次の図は、フェイルオーバー後の完全なデータベース DR アーキテクチャを示しています。
完全なデータベースの DR プロセスは、次の手順で構成されます。
- プライマリ データベースを実行しているプライマリ リージョン（R1）が使用できなくなります。
- オペレーション チームが障害を認識して正式に応答し、フェイルオーバーが必要かどうかを判断します。
- フェイルオーバーが必要な場合は、セカンダリ リージョン（R2）のクロスリージョン リードレプリカをプロモートして、新しいプライマリ インスタンスにできます。
- クライアント接続が、新しいプライマリ インスタンス（R2）にアクセスして処理するように再構成されます。
- R2 で新しいスタンバイ インスタンスが作成され、プライマリ インスタンスに追加されます。スタンバイ インスタンスは、プライマリ インスタンスとは異なるゾーンにあります。プライマリ インスタンスのスタンバイ インスタンスが作成されたため、プライマリ インスタンスの可用性が向上しました。
- 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 回目のフェイルオーバーによって、出発点となるデプロイが再確立されます（フォールバック）。
元のプライマリ リージョン（R1）へのフォールバックは、次のステップで構成されます。
- 元のプライマリ リージョン（R1）で、新しく作成されたクロスリージョン レプリカをプロモートします。
- プロモートしたインスタンスが HA レプリカとして作成されたものではない場合は、ゾーン障害から保護するためにそのインスタンス上で HA を有効にします。
- 新しいプライマリ インスタンスに接続するようにアプリケーションを再構成します。
- DR リージョン（R2）に新しいプライマリ インスタンスのクロスリージョン レプリカを作成します。
- （省略可）複数の独立したプライマリ インスタンスが実行される状態を回避するために、DR リージョン（R2）のプライマリ インスタンスをクリーンアップします。