データの障害復旧シナリオ

この記事は、Google Cloud Platform(GCP)における障害復旧(DR)について説明する、マルチパート シリーズのパート 3 です。このパートでは、データのバックアップと復元のシナリオについて説明します。

このシリーズは次のパートで構成されています。

はじめに

障害復旧計画では、障害の発生時にデータを失わないようにする方法を指定しなければなりません。ここでの「データ」という語は、2 つのシナリオに対応しています。データベース、ログデータ、および他のデータタイプをバックアップして復元することは、次のいずれかのシナリオに該当します。

  • データのバックアップ。データのバックアップだけであれば、個別の量のデータをある場所から別の場所にコピーする作業になります。バックアップは、データの破損から復旧して、良好な状態が既知であるディレクトリを本番環境に復元するため、または本番環境がダウンしている場合は DR 環境にデータを復元するため、復旧計画の一環として行われます。通常、データ バックアップの RTO は小~中程度であり、RPO は小さくなります。
  • データベースのバックアップ。データベースのバックアップは通常、その時点までのデータの復旧を伴うため、やや複雑になります。そのため、データベース バックアップをバックアップして復元する方法を検討し、リカバリ データベース システムが本番環境構成(同一バージョン、ミラーリングしたディスク構成)を反映していることを確認するのに加えて、トランザクション ログをバックアップする方法も検討する必要があります。復旧の際は、データベース機能を復元した後、最新のデータベース バックアップを適用してから、最後のバックアップ後にバックアップされた復元済みのトランザクション ログを適用する必要があります。データベース システムに固有の複雑な要因(本番環境システムとリカバリ システムのバージョンを一致させる必要があるなど)のため、高可用性第一のアプローチを採用して、データベース サーバーが使用不能になる可能性のある状況からの復旧時間を最小限に抑えることで、RTO と RPO の値を小さくできます。

この記事の残りの部分では、RTO と RPO の目標を達成しやすいデータやデータベースのシナリオを作成する方法の例を紹介します。

本番環境がオンプレミスの場合

このシナリオでは、本番環境はオンプレミスであり、障害復旧計画では GCP を復旧サイトとして使用します。

データのバックアップとリカバリ

データをオンプレミスから GCP に定期的にバックアップするプロセスを実装するには、さまざまな戦略を利用できます。このセクションでは、最も一般的なソリューションのうち 2 つを検討していきます。

ソリューション 1: スケジュールされたタスクを利用して Cloud Storage にバックアップする

DR 構成要素:

  • Cloud Storage

データをバックアップするための方法の 1 つは、Cloud Storage にデータを転送するスクリプトまたはアプリケーションを実行するタスクをスケジュールすることです。Cloud Storage へのバックアップ プロセスは、gsutil コマンドライン ツールを使用するか、Cloud Storage クライアント ライブラリのいずれかを利用して自動化できます。たとえば次の gsutil コマンドは、ソース ディレクトリにあるすべてのファイルを、指定されたバケットにコピーします。

gsutil -m cp -r [SOURCE_DIRECTORY] gs://[BUCKET_NAME]

次の手順は、gsutil ツールを利用してバックアップと復元のプロセスを実装する方法を示したものです。

  1. データファイルのアップロードに使用するオンプレミスのマシンに gsutil をインストールします
  2. データのバックアップ先としてバケットを作成します
  3. JSON 形式で、専用サービス アカウントのサービス アカウント キーを生成します。自動スクリプトでは、その一環としてこのファイルを使用し、gsutil に認証情報を渡します
  4. バックアップをアップロードするスクリプトを実行するオンプレミスのマシンに、サービス アカウント キーをコピーします。

  5. IAM ポリシーを作成して、バケットとそのオブジェクトにアクセスできるユーザーを制限します(この目的専用に作成されたサービス アカウントと、オンプレミス オペレータのアカウントを含めます)。Cloud Storage へのアクセス権の詳細については、gsutil コマンドの IAM 権限をご覧ください。

  6. ターゲット バケットでファイルのアップロードとダウンロードをテストします。

  7. データ転送タスクのスクリプト作成のガイダンスに従って、スケジュール設定済みのスクリプトを設定します。

  8. gsutil を利用して GCP の復旧 DR 環境にデータを復元する、復元プロセスを構成します。

詳細については、コロケーションまたはオンプレミスのストレージから転送(転送プロセスを最適化する方法を含む)をご覧ください。

ソリューション 2: パートナーのゲートウェイ ソリューションを使用して Cloud Storage にバックアップする

DR 構成要素:

  • Cloud Interconnect
  • Cloud Storage の階層型ストレージ

オンプレミスのアプリケーションは、データのバックアップおよび復元の戦略の一環として利用できるサードパーティのソリューションと統合されることがよくあります。こうしたソリューションでは、最新のバックアップをより高速なストレージに保存し、古いバックアップをより安価な(低速)ストレージにゆっくり移行するという、階層型ストレージのパターンがよく使用されます。GCP をターゲットとして使用する場合は、Cloud Storage Nearline または Cloud Storage Coldline のストレージを、低速の階層に相当するものとして使用できます。

このパターンを実装する 1 つの方法は、オンプレミス ストレージと GCP の間でパートナーのゲートウェイを利用して、この Cloud Storage へのデータ転送を円滑化することです。次の図では、オンプレミスの NAS アプライアンスまたは SAN からの転送を管理するパートナー ソリューションを使ってこの手法を示しています。

専用の相互接続を利用して GCP に接続されたオンプレミスのデータセンターを示すアーキテクチャ図

障害が発生した場合は、バックアップしたデータを DR 環境に復元する必要があります。DR 環境は、環境を本番環境に戻すことができるまで、本番環境トラフィックを提供するために使用されます。これを実現する方法は、アプリケーションのほかパートナー ソリューションとそのアーキテクチャによっても異なります(DR アプリケーションのドキュメントで、エンドツーエンドのシナリオをいくつか説明します)。

オンプレミスから GCP にデータを転送する方法の詳細については、ビッグデータ セットを GCP に転送するをご覧ください。

パートナー ソリューションの詳細については、GCP ウェブサイトのパートナーのページをご覧ください。

データベースのバックアップと復元

データベース システムをオンプレミスから GCP に復元するプロセスを実装するには、さまざまな戦略を採用できます。このセクションでは、最も一般的なソリューションのうち 2 つを検討します。

この記事では、サードパーティのデータベースに組み込まれているさまざまなビルトインのバックアップおよび復元のメカニズムについては、詳しく説明しません。このセクションでは、ここで説明しているソリューションで実装される一般的なガイダンスを提供します。

ソリューション 1: GCP 上のリカバリ サーバーを利用したバックアップと復元

  1. データベース管理システムに組み込みのバックアップ メカニズムを利用して、データベースのバックアップを作成します。
  2. データのバックアップ先として、Cloud Storage バケットを作成します
  3. gsutil かパートナーのゲートウェイ ソリューションを利用して、バックアップ ファイルを Cloud Storage にコピーします(データのバックアップと復元のセクションで説明した手順をご覧ください)。詳細については、ビックデータ セットを Cloud Platform に転送するをご覧ください。
  4. トランザクション ログを GCP のリカバリサイトにコピーします。 トランザクション ログのバックアップを取ると、RPO 値を小さく保つのに役立ちます。

このバックアップ トポロジを構成したら、GCP 上にあるシステムに復元できることを確認する必要があります。この手順では通常、バックアップ ファイルをターゲット データベースに復元するだけでなく、同時にトランザクション ログを再生して最小の RTO 値を達成します。一般的な復旧シーケンスは次のとおりです。

  1. オンプレミス ネットワークと GCP ネットワークを接続します。
  2. GCP でデータベース サーバーのカスタム イメージを作成します。イメージ上のデータベース サーバーの構成は、オンプレミスのデータベース サーバーと同じにする必要があります。
  3. オンプレミスのバックアップ ファイルとトランザクション ログファイルを Cloud Storage にコピーするプロセスを実装します。前述の実装例をご覧ください。
  4. 最小サイズのインスタンスをカスタム イメージから起動し、必要な永続ディスクを接続します。
  5. 永続ディスクの自動削除フラグを false に設定します。
  6. バックアップ ファイルの復元に関するデータベース システムの指示に従って、あらかじめ Cloud Storage にコピーされた最新のバックアップ ファイルを適用します。
  7. Cloud Storage にコピーした最新のトランザクション ログファイルを適用します。
  8. 最小限のインスタンスをより大きなインスタンスに置き換えます。置き換え後のインスタンスは本番環境トラフィックを受け入れられる大きさでなければなりません。
  9. GCP の復元されたデータベースを指すようにクライアントを切り替えます。

本番環境が実行され、本番稼働ワークロードへの対応が可能になったら、GCP 復旧環境へのフェイルオーバーの際に行った手順を逆に行います。本番環境に復帰する一般的なシーケンスは次のとおりです。

  1. GCP 上で実行されているデータベースのバックアップをとります。
  2. バックアップ ファイルを本番環境にコピーします。
  3. 本番環境データベース システムにバックアップ ファイルを適用します。
  4. クライアントが GCP のデータベース システムに接続できないようにします。たとえば、データベース システム サービスを停止します。 この時点から本番環境の復元が完了するまで、アプリケーションは使用できなくなります。
  5. すべてのトランザクション ログファイルを本番環境にコピーして適用します。
  6. クライアント接続を本番環境にリダイレクトします。

ソリューション 2: GCP 上のスタンバイ サーバーへのレプリケーション

RTO と RPO の値を非常に小さくするための 1 つの方法は、データを(バックアップするだけでなく)レプリケートし、場合によってはデータベース状態もリアルタイムでデータベース サーバーのホット スタンバイに複製することです。

  1. オンプレミス ネットワークと GCP ネットワークを接続します。
  2. GCP でデータベース サーバーのカスタム イメージを作成します。イメージ上のデータベース サーバーの構成は、オンプレミスのデータベース サーバーと同じにする必要があります。
  3. カスタム イメージからインスタンスを起動し、必要な永続ディスクを接続します。
  4. 永続ディスクの自動削除フラグを false に設定します。
  5. 各データベース ソフトウェアの手順に従って、オンプレミスのデータベース サーバーと GCP のターゲット データベース サーバー間のレプリケーションを構成します。
  6. クライアントは、通常のオペレーションで、オンプレミスのデータベース サーバーを指すように構成されます。

このレプリケーション トポロジを構成したら、GCP ネットワークで実行されているスタンバイ サーバーを指すようにクライアントを切り替えます。

本番環境のバックアップが作成され、本稼働ワークロードへの対応が可能になったら、本番環境データベース サーバーを GCP のデータベース サーバーと再同期してから、再度本番環境を指すようにクライアントを切り替える必要があります。

本番環境が GCP の場合

このシナリオでは、本番環境と障害復旧環境の両方が GCP 上で実行されます。

データのバックアップとリカバリ

データ バックアップの一般的なパターンは、階層型のストレージ パターンを使用することです。本番環境ワークロードが GCP 上にある場合、階層型ストレージ システムは次の図のようになります。バックアップされたデータにアクセスする必要性が低いため、データはストレージ コストがより安い階層に移行します。

DR 構成要素:

データが永続ディスクから Nearline、そして Coldline に移行される際のコスト低下を表すイメージを示した概念図

Cloud Storage Nearline と Cloud Storage Coldline はアクセス頻度の低いデータを格納するためのものなので、これらのクラスに格納されているデータやメタデータには、最小保存期間の課金に加え、取得に付随する追加コストがかかります。

データベースのバックアップと復元

自己管理型データベースを使用する場合は(たとえば MySQL、PostgreSQL、または SQL Server を Compute Engine のインスタンスにインストールした場合)、本番環境データベースをオンプレミスで管理する場合と同じ運用上の懸念事項がありますが、基盤となるインフラストラクチャを管理する必要はなくなります。

適切な DR 構成要素機能を利用して HA 構成を設定すれば、RTO を小さく保つことができます。データベース構成は、障害発生前にできるだけ近い状態に復旧しやすいように設計すると、RPO 値を小さく保つのに役立ちます。GCP にはこのシナリオに対応するさまざまなオプションが用意されています。

このセクションでは、GCP 上のセルフマネージド データベースのデータベース復旧アーキテクチャを設計する際の、一般的な 2 つのアプローチについて説明します。

状態を同期せずにデータベース サーバーを復旧させる

一般的なパターンは、システム状態をホット スタンバイと同期せずにデータベース サーバーを復旧できるようにすることです。

DR 構成要素:

  • Compute Engine
  • マネージド インスタンス グループ
  • Cloud Load Balancing(内部負荷分散)

下の図は、このシナリオに対処したアーキテクチャの例を示しています。このアーキテクチャを実装することで、手動復旧を要することなく自動的に障害に対応する DR 計画を作成できます。

1 つのゾーンの永続ディスクから取得された永続ディスクのイメージを示すアーキテクチャ図

次の手順は、このシナリオを構成する方法の概要を示したものです。

  1. VPC ネットワークを作成します
  2. 次の手順に従って、データベース サーバーで構成されたカスタム イメージを作成します。

    1. 接続された標準永続ディスクにデータベース ファイルとログファイルが書き込まれるように、サーバーを構成します。
    2. 接続された永続ディスクからスナップショットを作成します
    3. スナップショットから永続ディスクを作成してディスクをマウントするように、起動スクリプトを構成します。
    4. ブートディスクのカスタム イメージを作成します。
  3. このイメージを使用するインスタンス テンプレートを作成します。

  4. インスタンス テンプレートを利用して、ターゲット サイズが 1 のリージョン マネージド インスタンス グループを構成します。

  5. StackDriver の指標を使用してヘルスチェックを構成します。

  6. リージョン マネージド インスタンス グループを利用して、内部負荷分散を構成します。

  7. 永続ディスクのスナップショットを定期的に作成する、スケジュール設定されたタスクを構成します。

置換用のデータベース インスタンスが必要な場合、この構成では自動的に次の処理が行われます。

  • 正しいバージョンの別のデータベース サーバーが起動されます。
  • 最新のバックアップとトランザクション ログファイルを含む永続ディスクが、新しく作成されたデータベース サーバー インスタンスに接続されます。
  • イベントに応じてデータベース サーバーと通信するクライアントを再構成する必要性が最小限に抑えられます。
  • 本番環境データベース サーバーに適用される GCP セキュリティ コントロール(IAM ポリシー、ファイアウォール設定)が、復旧したデータベース サーバーに確実に適用されます。

置換インスタンスはインスタンス テンプレートから作成されるため、元のインスタンスに適用されたコントロールは置換インスタンスにも適用されます。

このシナリオでは、GCP で利用可能な HA 機能の一部を活用しています。フェイルオーバー手順は障害発生時に自動的に起動されるため、手動で開始する必要はありません。内部ロードバランサにより、置換インスタンスが必要な場合でも、データベース サーバーには確実に同じ IP アドレスが使用されます。インスタンス テンプレートとカスタム イメージによって、置換インスタンスは必ず置換前のインスタンスと同一の構成になります。永続ディスクの定期的なスナップショットを作成することで、スナップショットからディスクを再作成して置換インスタンスに接続する際、置換インスタンスでは RPO 値に従って復元されたデータが使用されます。この値は、スナップショットの頻度に応じて異なります。このアーキテクチャでは、永続ディスクに書き込まれた最新のトランザクション ログファイルも自動的に復元されます。

リージョン マネージド インスタンス グループは、高度な HA を提供します。アプリケーション、インスタンス、またはゾーンのレベルでの障害に対応するメカニズムが提供されるため、これらのシナリオが発生した場合、手動で介入する必要はありません。ターゲット サイズを 1 に設定すると、実行されるインスタンスは常に 1 つだけになります。

標準永続ディスクはゾーン単位なので、ゾーン単位での障害が発生した場合、ディスクを再作成するにはスナップショットが必要になります。スナップショットはリージョン間でも使用できるため、ディスクは同じリージョンに復元するのと同じくらい簡単に別のリージョンにも復元できます。

次の図は、永続ディスクのスナップショットを利用して永続ディスクを別のゾーンに復元した復旧シナリオを示しています。

2 番目のゾーンに復元するために使用される永続ディスクのイメージを示すアーキテクチャ図

この構成には、次のようなバリエーションがあります。

  • 標準永続ディスクの代わりにリージョンの永続ディスクを使用する方法。 この場合、復旧手順の一環としてスナップショットを復元する必要はありません。
  • リージョン マネージド インスタンス グループではなくマネージド インスタンス グループを利用して、障害が発生したインスタンスと同じゾーンで起動される置換インスタンスに永続ディスクを接続する方法。この場合、永続ディスクの自動削除設定は no-auto-delete にする必要があります。

どのバリエーションを選択するかは、予算および RTO と RPO の値によって決まります。

GCP での HA シナリオおよび DR シナリオ用に設計されたデータベース構成の詳細については、以下をご覧ください。

非常に大規模なデータベースの部分的な破損からの復旧

ペタバイト単位のデータを格納できるデータベースを使用している場合は、一部のデータに影響を与えるがすべてのデータには影響しない障害が発生する可能性があります。その場合、復元すべきデータの量を最小限に抑える必要があります。一部のデータを復元するために、データベース全体を復元する必要はありません。

採用できる緩和策はいくつかあります。

  • 特定の期間ごとに、データを異なるテーブルに格納します。この方法では、データセット全体ではなく、データのサブセットのみを新しいテーブルに復元する必要があります。
  • 元のデータを Cloud Storage に保存します。これにより、新しいテーブルを作成して、破損していないデータを再読み込みできます。そこから、新しいテーブルを指すようにアプリケーションを調整できます。

さらに、RTO に応じて可能であれば、破損していないデータを新しいテーブルに復元するまでアプリケーションをオフラインにしておくことで、データが破損しているテーブルへのアクセスを防止できます。

GCP のマネージド データベース サービス

このセクションでは、GCP上 のマネージド データベース サービスに適切なバックアップと回復のメカニズムを実装するための方法をいくつか説明します。

マネージド データベースはスケールを考慮して設計されているため、従来の RDMBS で行われている従来のバックアップおよび復元メカニズムは通常利用できません。セルフマネージド データベースの場合と同様、ペタバイト単位のデータを格納できるデータベースを使用している場合は、DR シナリオにおいて復元するべきデータの量を最小限に抑える必要があります。この目標を達成するには、マネージド データベースごとにさまざまな戦略を採用できます。

Cloud Bigtable では、Cloud Bigtable のリージョン間レプリケーションができます。レプリケートされた Cloud Bigtable データベースは、ゾーンの障害に直面した際も、単一クラスタより高い可用性、読み取りスループットの向上、より高い耐久性と復元性を実現できます。

また、Cloud Bigtable のテーブルを一連の Hadoop シーケンス ファイルとしてエクスポートすることもできます。これらのファイルは Cloud Storage に保存するか、Cloud Bigtable の別のインスタンスにデータを再インポートするために利用できます。Cloud Bigtable のデータセットは、GCP リージョン内のゾーン間で非同期に複製できます。

BigQuery: データをアーカイブする場合は、BigQuery の長期保存を活用できます。連続する 90 日間にわたってテーブルが編集されていない場合、そのテーブルのストレージ料金は自動的に 50% 値引きされます。テーブルを長期にわたって保存していても、パフォーマンス、耐久性、可用性などの各種機能性が損なわれることはありません。ただしそのテーブルを編集すると、価格は通常のストレージ価格に戻り、90 日間のカウントダウンが再び開始されます。

BigQuery はレプリケートされますが、これはテーブル破損への対処には役立ちません。そのため、そのようなシナリオから復旧できる計画が必要です。たとえば、次の操作が可能です。

  • 破損の検出が 7 日以内の場合、過去の時点のテーブルに対してクエリを行い、スナップショット デコレータを利用して、破損する前のテーブルを復元します。
  • BigQuery からデータをエクスポートし、エクスポートしたデータを含む(ただし破損したデータは含まない)新しいテーブルを作成します。
  • 特定の期間ごとに、データを異なるテーブルに格納します。この方法では、データセット全体ではなく、データの一部のみを新しいテーブルに復元するだけで済みます。
  • 元のデータを Cloud Storage に保存します。これにより、新しいテーブルを作成して、破損していないデータを再読み込みできます。そこから、新しいテーブルを指すようにアプリケーションを調整できます。

Cloud Datastore: マネージド インポートおよびエクスポート サービスを使用すると、Cloud Storage バケットを利用して Cloud Datastore エンティティをインポート / エクスポートできます。これにより、偶発的なデータの削除から復旧するためのプロセスを実装できます。

Cloud SQL: フルマネージドの GCP MySQL データベースである Cloud SQL を使用する場合は、Cloud SQL インスタンスの自動的なバックアップとバイナリログを有効にする必要があります。これにより、データベースをバックアップからリストアして新しい Cloud SQL インスタンスに復元する、ポイントインタイム リカバリを簡単に実行できます。詳細は、Cloud SQL のバックアップと復旧をご覧ください。

また、Cloud SQL を HA 構成で設定して、稼働時間を最大化することもできます。

Cloud Spanner: Cloud Dataflow テンプレートを利用して、Cloud Storage バケット内の一連の Avro ファイルにデータベースを完全にエクスポートし、さらに別のテンプレートを利用してそのエクスポート ファイルを新しい Cloud Spanner データベースに再インポートできます。

より制御されたバックアップを行うには、Cloud Dataflow コネクタを使用すると、Cloud Spanner にデータを読み書きするためのコードを Cloud Dataflow パイプラインで記述できます。たとえば、このコネクタを利用して Cloud Spanner からバックアップ ターゲットの Cloud Storage にデータをコピーできます。Cloud Spanner からデータを読み取る(または書き戻す)速度は、構成されたノードの数によって異なります。これは RTO 値に直接影響を与えます。

Cloud Spanner の commit タイムスタンプ機能は、前回の完全バックアップ以降に追加または変更された行のみを選択できるため、増分バックアップに役立ちます。

RTO 値を小さくするには、ストレージおよび読み取り / 書き込みスループットの要件を満たすために必要な最小限のノード数で構成された、ウォーム スタンバイの Cloud Spanner インスタンスを設定します。

Cloud Composer: Cloud Composer(Apache Airflow の管理対象バージョン)を利用すると、複数の GCP データベースの定期的なバックアップをスケジュールできます。スケジュールどおりに(毎日など)実行される有向非巡回グラフ(DAG)を作成すれば、データを別のプロジェクト、データセット、またはテーブル(使用するソリューションにより異なる)にコピーしたり、データを Cloud Storage にエクスポートしたりできます。

データのエクスポートまたはコピーは、さまざまな Cloud Platform 演算子を使用して行うことができます。

たとえば、DAG を作成すると次のようなことが可能になります。

本番環境が別のクラウドの場合

このシナリオでは、本番環境で別のクラウド プロバイダを利用しており、障害復旧計画では GCP を復旧サイトとして使用します。

データのバックアップとリカバリ

オブジェクト ストア間でデータを転送することは、DR シナリオの一般的なユースケースです。 Storage Transfer Service は Amazon の S3 と互換性があり、オブジェクトを Amazon S3 から Cloud Storage に転送する際に推奨される方法です。転送ジョブを構成すると、ファイル作成日、ファイル名フィルタ、およびデータをインポートする時刻に基づく高度なフィルタを利用して、データソースからデータシンクへの定期的な同期をスケジュールできます。

AWS から GCP へデータを移動するもう 1 つの方法は、Amazon S3 および Cloud Storage と互換性のある Python ツール boto を使用することです。これは gsutil コマンドライン ツールのプラグインとしてインストールできます。

データベースのバックアップと復元

この記事では、サードパーティのデータベースに組み込まれているさまざまなビルトインのバックアップおよび復元のメカニズムや、他のクラウド プロバイダで利用されているバックアップと復元の手法については、詳しく説明しません。非管理型のデータベースをコンピューティング サービス上で運用している場合は、本番環境クラウド プロバイダが提供している HA 設備を活用できます。それらを拡張して HA デプロイを GCP に組み込んだり、データベース バックアップ ファイルのコールド ストレージの最終的な宛先として Cloud Storage を使用したりすることも可能です。

次のステップ

このページは役立ちましたか?評価をお願いいたします。

フィードバックを送信...