障害復旧のユースケース: 地域制限のあるデータ分析アプリケーション

この記事は、Google Cloud の障害復旧(DR)について説明するシリーズの一部です。このドキュメントでは、地域制限があるワークロードの障害復旧の設計のドキュメントから、地域制限をデータ分析アプリケーションに適用する方法について説明します。具体的には、データ分析プラットフォームで使用するコンポーネントが、アプリケーションやデータに適用される地域制限を満足する DR アーキテクチャにどのように適合するかについて説明します。

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

このドキュメントは、システム アーキテクトと IT マネージャーを対象としています。以下の知識とスキルがあることを前提としています。

データ分析プラットフォームの地域要件

データ分析プラットフォームは、通常、保存データを保存する複雑な多層アプリケーションです。これらのアプリケーションは、処理されて分析システムに保存されたイベントを生成します。アプリケーション自体とシステムに保存されたデータの両方に地域規則が適用される場合があります。これらの規制は、国だけでなく、業種によっても異なります。したがって、DR アーキテクチャを設計する前に、データの局所性要件を明確に理解しておく必要があります。

次の 2 つの質問に答えると、データ分析プラットフォームに地域的な要件があるかどうかを確認できます。

  • アプリケーションを特定のリージョンにデプロイする必要がありますか?
  • データの保存が特定のリージョンに制限されていますか?

両方の質問に「いいえ」と回答すると、お客様のデータ分析プラットフォームには地域固有の要件はありません。プラットフォームに地域要件がないため、障害復旧計画ガイドに概説されている適合サービスとプロダクトについて、DR ガイダンスに従ってください。

ただし、いずれかの質問に「はい」と答えるアプリケーションは、地域が制限されます。分析プラットフォームには地域制限があるため、次の質問をする必要があります。保存データの要件を軽減するために暗号化手法を使用できますか?

暗号化技術を使用できる場合は、Cloud External Key Manager と Cloud Key Management Service のマルチリージョンとデュアルリージョンのサービスを使用できます。その後、データの障害復旧シナリオで概説されている標準の高可用性と障害復旧(HA/DR)手法を実行することもできます。

暗号化技術を使用できない場合は、DR 計画にカスタム ソリューションまたはパートナー サービスを使用する必要があります。DR シナリオの地域制限に対応する手法の詳細については、地域制限があるワークロードの障害復旧の設計をご覧ください。

データ分析プラットフォームのコンポーネント

地域要件を理解したら、次のステップではデータ分析プラットフォームが使用するコンポーネントを理解します。データ分析プラットフォームの一般的なコンポーネントには、以下のリストに示すとおり、データベース、データレイク、処理パイプライン、データ ウェアハウスなどがあります。

  • Google Cloud には、さまざまなユースケースに適合する一連のデータベース サービスがあります。
  • データレイク、データ ウェアハウス、処理パイプラインの定義は多少異なります。このドキュメントでは、Google Cloud サービスを参照する一連の定義を使用します。
    • データレイクは、複数のシステムからデータの取り込みと保存を行うためのスケーラブルで安全なプラットフォームです。一般的なデータレイクでは、Cloud Storage が中央ストレージ リポジトリとして使用されます。
    • 処理パイプラインは、1 つ以上のシステムからデータまたはイベントを取得し、そのデータまたはイベントを変換して、別のシステムに読み込むエンドツーエンドのプロセスです。パイプラインは、抽出、変換、読み込み(ETL)プロセスまたは抽出、読み込み、変換(ELT)プロセスを実行できます。通常、処理されたデータが読み込まれるシステムはデータ ウェアハウスです。Pub/Sub、Dataflow、Dataproc は、処理パイプラインの一般的に使用されるコンポーネントです。
    • データ ウェアハウスは、通常は運用データベースから得られる、データの分析とレポート作成に使用される企業システムです。BigQuery は、Google Cloud 上で実行される一般的なデータ ウェアハウス システムです。

実際の DR 実装は、地域要件と使用しているデータ分析コンポーネントによって異なります。次のセクションでは、このバリエーションを 2 つのユースケースで説明します。

バッチ ユースケース: 定期的な ETL ジョブ

最初のユースケースでは、小売プラットフォームがさまざまなストアからファイルとして定期的に販売イベントを収集し、それらのファイルを Cloud Storage バケットに書き込むバッチプロセスについて説明します。次の図は、この小売業者のバッチジョブのデータ分析アーキテクチャを示しています。

POS データを伴うバッチ ユースケースのアーキテクチャ図。

このアーキテクチャには、次のフェーズとコンポーネントが含まれています。

  • 取り込みフェーズは、店舗の POS(Point Of Sale)データを Cloud Storage に送信する店舗で構成されます。この取り込まれたデータは処理を待機します。
  • オーケストレーション フェーズでは、Cloud Composer を使用して、エンドツーエンドのバッチ パイプラインをオーケストレートします。
  • 処理フェーズでは、Dataproc クラスタで実行される Apache Spark ジョブが関与します。Apache Spark ジョブは、取り込まれたデータに対して ETL プロセスを実行します。この ETL プロセスは、ビジネス指標を提供します。
  • データレイク フェーズは、処理済みのデータを受け取り、次のコンポーネントに情報を保存します。
    • 処理されたデータは一般的に、ParquetORC のような Cloud Storage のカラム型で保存されます。これらの形式を使用すると、分析ワークロードに対して効率的なストレージと高速アクセスが可能になるからです。
    • プロセスデータに関するメタデータ(データベース、テーブル、列、パーティションなど)は、Dataproc Metastore で提供される Hive メタストア サービスに保存されます。

地域制限があるシナリオでは、可用性維持のための冗長な処理とオーケストレーションの容量を提供することが難しい場合があります。データはバッチで処理されるため、処理およびオーケストレーション パイプラインを再作成でき、障害シナリオが解決した後にバッチジョブを再起動できます。したがって、障害復旧では、実際のデータの復元が特に重要です。データには、取り込まれた POS データ、データレイ保存された処理データ、データレイクに保存されたメタデータが含まれます。

Cloud Storage への取り込み

最初に、POS システムからのデータ取り込みに使用する Cloud Storage バケットの地域要件を考慮する必要があります。この地域情報は、次のオプションを検討する際に使用してください。

  • 地域要件により、保存データがマルチリージョンまたはデュアルリージョンのロケーションのいずれかに存在する場合、Cloud Storage バケットの作成時に対応するロケーション タイプを選択します。選択したロケーション タイプによって、保存データの複製に使用される Google Cloud リージョンが決まります。いずれかのリージョンでサービスが停止しても、マルチリージョンまたはデュアルリージョンのバケットに存在するデータにはアクセスできます。
  • Cloud Storage は、顧客管理の暗号鍵(CMEK)顧客指定の暗号鍵(CSEK)の両方もサポートしています。一部のロケーション ルールでは、鍵管理に CMEK または CSEK を使用すると、保存データを複数の場所に格納できます。地域区分ルールで CMEK または CSEK の使用が許可されている場合は、Cloud Storage リージョンを使用するように DR アーキテクチャを設計できます。
  • 地域要件により、ロケーション タイプまたは暗号鍵管理のいずれも使用できない場合があります。ロケーション タイプや暗号鍵の管理を使用できない場合、gsutil rsync コマンドを使用して別のロケーション(たとえば、別のクラウド プロバイダのオンプレミス ストレージまたはストレージ ソリューション)にデータを同期させることができます。

障害が発生すると、Cloud Storage バケットに取り込まれた POS データには、未処理でデータレイクにインポートされていないデータが存在する可能性があります。または、POS データを Cloud Storage バケットに取り込むことができない場合があります。このような場合、障害復旧オプションが用意されています。

  • POS システムを再試行します。 システムが POS データを Cloud Storage に書き込むことができない場合、データの取り込みプロセスは失敗します。この状況を軽減するには、切り捨て型指数バックオフ アルゴリズムを実装して、POS システムがデータ取り込みオペレーションを再試行できるようにします。Cloud Storage の耐久性は 99.999999999% なので、Cloud Storage サービスが再開した後も、データの取り込みやその後の処理パイプラインはほとんどデータを失うことなく再開されます。

  • 取り込んだデータのコピーを作成する。 Cloud Storage は、マルチリージョンとデュアルリージョンのロケーション タイプをサポートしています。データの局所性の要件に応じて、マルチリージョンまたはデュアルリージョンの Cloud Storage バケットを設定してデータの可用性を高めることができます。gsutil などのツールを使用して、Cloud Storage と別の場所の間でデータを同期することもできます。

取り込まれた POS データのオーケストレーションと処理

バッチユースケースのアーキテクチャ図では、Cloud Composer が次の手順を実施します。

  • 新しいファイルが Cloud Storage 取り込みバケットにアップロードされたことを検証します。
  • Dataproc のエフェメラル クラスタを起動します。
  • Apache Spark ジョブを開始してデータを処理します。
  • ジョブの最後で Dataproc クラスタを削除します。

Cloud Composer では、これらの一連のステップを定義する有向非巡回グラフ(DAG)ファイルが使用されます。これらの DAG ファイルは、アーキテクチャ図には示されていない Cloud Storage バケットに保存されます。デュアルリージョンとマルチリージョンのロケーションについては、DAG ファイル バケットの DR に関する考慮事項は取り込みバケットで説明したものと同じです。

Dataproc クラスタはエフェメラルです。つまり、処理ステージが実行されている間のみ、クラスタは存在します。つまり、Dataproc クラスタに関して DR に対して明示的に何もする必要はありません。

Cloud Storage でのデータレイクのストレージ

データレイクに使用する Cloud Storage バケットには、取り込みバケットで説明したものと同じ局所性に関する考慮事項(デュアルリージョンとマルチリージョンに関する考慮事項、暗号化の使用、gsutil rsync の使用)があります。

データレイクの DR 計画を設計する際は、次の点を考慮してください。

  • データサイズデータレイク内のデータ量は大きくなる可能性があります。大量のデータを復元するには時間がかかります。DR シナリオでは、次の条件を満たすポイントにデータを復元するために必要な時間に対して、データレイクのボリュームが与える影響を考慮する必要があります。

    現在のバッチのユースケースでは、Cloud Storage がデータレイクのロケーション用に使用され、99.999999999% の耐久性を提供します。しかし、ランサムウェア攻撃が増加しています。このような攻撃から確実に復旧できるように、Cloud Storage が 99.999999999% の耐久性を実現する方法に記載されているベスト プラクティスをおすすめします。

  • データ依存関係。 データレイク内のデータは通常、処理パイプラインなどのデータ分析システムの他のコンポーネントによって使用されます。DR シナリオでは、処理パイプラインと依存するデータは同じ RTO を共有する必要があります。このコンテキストでは、システムが使用不能になる時間の長さに重点を置きます。

  • データの経過時間。 過去のデータにより RPO が高くなる可能性があります。このタイプのデータは、他のデータ分析コンポーネントによってすでに分析または処理されている場合があり、独自の DR 戦略を持つ別のコンポーネントに保存されている場合もあります。たとえば、Cloud Storage にエクスポートされる販売レコードは、分析のために BigQuery にインポートされます。BigQuery に対する適切な DR 戦略では、BigQuery にインポートされた過去の販売レコードは、インポートされていないレコードの復元目標よりも低くなる可能性があります。

Dataproc Metastore によるデータレイクのメタデータ ストレージ

Dataproc Metastore は、フルマネージドで、可用性が高く、自動修復を備えたサーバーレスの Apache Hive メタストアです。メタストアは、データ抽象化機能とデータ検出機能を提供します。障害発生時には、メタストアをバックアップし、復元できます。Dataproc Metastore サービスでは、メタデータのエクスポートインポートも可能です。タスクを追加して、メタストアをエクスポートし、ETL ジョブとともに外部バックアップを維持できます。

メタデータが一致しない場合は、MSCK コマンドを使用して、データ自体からメタストアを再作成できます。

ストリーミングのユースケース: ELT を使用してデータ キャプチャを変更する

2 番目のユースケースは、変更データ キャプチャ(CDC)を使用してバックエンド在庫システムを更新し、リアルタイムの売上指標を追跡する小売プラットフォームを示しています。次の図は、Cloud SQL などのトランザクション データベースからのイベントが処理されて、データ ウェアハウスに保存されるアーキテクチャを示しています。

小売データの変更データ キャプチャを含むストリーミングのユースケースのアーキテクチャ図。

このアーキテクチャには、次のフェーズとコンポーネントが含まれています。

  • 取り込みフェーズでは、受信変更イベントが Pub/Sub に push されます。メッセージ配信サービスとして、Pub/Sub を使用してストリーミング分析データを確実に取り込み、配信します。Pub/Sub には、スケーラブルであり、サーバーレスであるという利点があります。
  • 処理フェーズでは、Dataflow を使用して、取り込まれたイベントに対して ELT プロセスが実行されます。
  • データ ウェアハウス フェーズでは、BigQuery を使用して処理されたイベントを保存します。統合操作では、BigQuery にレコードを挿入または更新します。このオペレーションにより、BigQuery に格納された情報が、トランザクション データベースで最新の状態に保たれます。

この CDC アーキテクチャは Cloud Composer に依存していませんが、一部の CDC アーキテクチャでは、Cloud Composer がバッチ ワークロードへのストリームの統合をオーケストレートする必要があります。このような場合、Cloud Composer ワークフローは、整合性チェック、バックフィル、予測を実装しています。これらはレイテンシの制約のため、リアルタイムでは実行できません。Cloud Composer の DR 手法については、前述のバッチ処理のユースケースで説明しています。

ストリーミング データ パイプラインでは、DR アーキテクチャを計画する際に次の点を考慮する必要があります。

  • パイプラインの依存関係。 処理パイプラインは、1 つ以上のシステム(ソース)から入力を取得します。パイプラインは、これらの入力を処理、変換し、他のシステム(シンク)に格納します。エンドツーエンドの RTO を達成するために、DR アーキテクチャを設計することが重要です。データソースとシンクの RPO が RTO を満たすことを確認する必要があります。地域要件を満たすためにクラウド アーキテクチャを設計するだけでなく、送信元の CDC ソースを設計して、エンドツーエンドの RTO を満たす必要もあります。
  • 暗号化と局所性。暗号化で地域制限を緩和できる場合、Cloud KMS を使用して次の目標を達成できます。
    • 独自の暗号鍵を管理する。
    • 個々のサービスの暗号化機能を利用する。
    • 緩和策を講じない場合は、地域制限により使用できないリージョンにサービスをデプロイする。
  • 移動中のデータに対する地域区分ルール。 一部の地域区分ルールは、保存データのみに適用され、移動データには適用されません。移動データに地域区分ルールが適用されない場合は、DR アーキテクチャを設計し、他のリージョンのリソースを活用して復旧の目標を改善してください。暗号化技術を統合することで、リージョン アプローチを強化できます。

Pub/Sub への取り込み

地域制限がない場合、グローバル Pub/Sub エンドポイントにメッセージを公開できます。グローバル Pub/Sub エンドポイントは、Google Cloud のすべてのロケーションに表示され、アクセスできます。

地域要件で暗号化の使用が許可されている場合は、グローバル エンドポイントと同レベルの高可用性を実現するように Pub/Sub を構成できます。Pub/Sub メッセージはデフォルトで Google が管理する鍵で暗号化されますが、CMEK を使用するように Pub/Sub を構成することもできます。CMEK で Pub/Sub を使用すると、高可用性を維持しながら、暗号化に関する地域ルールを満たすことができます。

一部の地域区分ルールでは、暗号化後も特定のロケーションにメッセージを残す必要があります。地域ルールにこの制限がある場合は、Pub/Sub トピックのメッセージ ストレージ ポリシーを指定してリージョンに制限できます。このメッセージ ストレージ アプローチを使用すると、トピックにパブリッシュされたメッセージが、指定した Google Cloud リージョンのセット外に保持されることはありません。地域区分ルールで複数の Google Cloud リージョンの使用が許可されている場合は、Pub/Sub トピックでこれらのリージョンを有効にすることで、サービスの可用性を高めることができます。メッセージ ストレージ ポリシーを実装して Pub/Sub リソースのロケーションを制限すると、可用性に関するトレードオフが生じるので注意してください。

Pub/Sub サブスクリプションを使用すると、未確認のメッセージを最大 7 日間保存し、メッセージの数に制限はありません。サービスレベル契約で遅延データが許可されている場合、パイプラインの実行が停止すれば、Pub/Sub サブスクリプションでデータをバッファリングできます。パイプラインを再度実行するときは、バックアップされたイベントを処理できます。この設計には、低 RPO という利点があります。Pub/Sub のリソース上限の詳細については、Pub/Sub の割り当てのリソース上限をご覧ください。

Dataflow によるイベント処理

Dataflow は、さまざまなデータ処理パターンの実行に対応したマネージド サービスです。Apache Beam SDK は、バッチとストリーミングの両方のパイプラインの開発に対応したオープンソースのプログラミング モデルです。Apache Beam プログラムでパイプラインを作成し、Dataflow サービスで実行します。

ローカルでの制限を設計する場合は、ソース、シンク、一時ファイルがある場所を考慮する必要があります。これらのファイルがジョブのリージョン外にある場合、データはリージョン間で送信される可能性があります。地域ルールによって別のロケーションでデータを処理できる場合は、高可用性を実現できるように、他の Google Cloud リージョンにワーカーをデプロイするように DR アーキテクチャを設計します。

地域制限により処理が単一のロケーションに限定されている場合、特定のリージョンまたはゾーンに制限される Dataflow ジョブを作成できます。Dataflow ジョブを送信するときに、リージョン エンドポイント、ワーカー リージョン、ワーカーゾーンのパラメータを指定できます。これらのパラメータは、ワーカーがデプロイされる場所とジョブのメタデータの保存場所を制御します。

Apache Beam は、さまざまなランナーでパイプラインを実行できるようにするフレームワークを提供します。この機能を使用するように、DR アーキテクチャを設計できます。たとえば、Apache Spark Runner を使用して、DR アーキテクチャを設計し、ローカルのオンプレミス Spark クラスタで実行されるバックアップ パイプラインを持つようにできます。特定のランナーが特定のパイプライン オペレーションを実行できるかどうかを確認するには、Beam 機能マトリックスをご覧ください。

暗号化により地域制限を軽減できる場合、Dataflow の CMEK を使用して、パイプライン状態アーティファクトの暗号化と Cloud KMS 鍵で保護されているソースとシンクへのアクセスの両方を行うことができます。暗号化を使用すると、地域制限により利用できなかったリージョンを使用する DR アーキテクチャを設計できます。

BigQuery 上に構築されたデータ ウェアハウス

データ ウェアハウスは分析と意思決定をサポートします。データ ウェアハウスには、分析データベースに加え、複数の分析コンポーネントやプロシージャが含まれています。

データ ウェアハウスの DR 計画を設計する際は、次の点を考慮してください。

  • サイズ。 データ ウェアハウスは、オンライン トランザクション処理(OLTP)システムよりもはるかに大きいです。データ ウェアハウスでテラバイトからペタバイト規模のデータが使用されることは珍しくありません。RPO と RTO の値を達成するには、このデータの復元にかかる時間を検討する必要があります。DR 戦略を計画する際は、テラバイト規模のデータの復元に関連する費用も考慮する必要があります。BigQuery の DR 軽減手法の詳細については、Google Cloud のマネージド データベース サービスのバックアップと復元のメカニズムに関する BigQuery の情報をご覧ください。

  • 可用性。BigQuery データセットを作成するときは、データを保存するロケーション(リージョンまたはマルチリージョン)を選択します。リージョンのロケーションは、アイオワ(us-central1)やモントリオール(northamerica-northeast1)など、単一で特定の地理的位置です。マルチリージョンのロケーションは、米国(US)やヨーロッパ(EU)など、2 つ以上の地理的な場所を含む広い地理的なエリアとなります。地域制限を満たす DR 計画を設計する場合、障害発生ドメイン(障害がマシンレベル、ゾーン、リージョンで発生するか)は、定義したRTOを満たすために直接影響を与えます。これらの障害発生ドメインと可用性への影響については、BigQuery の可用性と耐久性をご覧ください。

  • データの性質。 データ ウェアハウスには履歴情報が含まれています。通常、古いデータのほとんどは静的です。多くのデータ ウェアハウスは、追加のみに対応するように設計されています。データ ウェアハウスが追記専用の場合、追加されているデータのみを復元することで、RTO を達成できることがあります。この方法では、追加されたデータのみをバックアップします。障害が発生した場合は、付加されたデータを復元し、データ ウェアハウスを(データのサブセットとともに)使用できるようにします。

  • データの追加と更新のパターン。 データ ウェアハウスは通常、ETL または ELT のパターンを使用して更新されます。更新パスを管理している場合は、代替ソースからの最新の更新イベントを再現できます。

地域要件によって、データ ウェアハウスに単一のリージョンまたは複数のリージョンを使用できるかどうかが制限される可能性があります。BigQuery データセットはリージョン単位を使用できますが、マルチリージョンのストレージは、障害発生時にデータの可用性を確保する最も簡単で費用対効果の高い方法です。マルチリージョン ストレージがリージョンで利用できないが、別のリージョンを使用できる場合は、BigQuery Data Transfer Service を使用して、データセットを別のリージョンにコピーします。暗号化を使用して地域要件を緩和できる場合、Cloud KMS と BigQuery を使用して独自の暗号鍵を管理できます。

1 つのリージョンのみを使用できる場合は、BigQuery テーブルのバックアップを検討してください。テーブルをバックアップする最も費用対効果の高いソリューションは、BigQuery のエクスポートを使用することです。Cloud Scheduler または Cloud Composer を使用して、Cloud Storage に書き込むためのエクスポート ジョブを定期的にスケジュールします。SNAPPY 圧縮の Avro や GZIP 圧縮の JSON などの形式を使用できます。エクスポート戦略を設計する際は、エクスポートの上限に注意してください。

BigQuery のバックアップを Parquet や ORC などのカラム型で保存することもできます。これらは高圧縮度を実現するとともに、オンプレミス システムに使用される Hive や Presto などの多くのオープンソース エンジンとの相互運用性も提供します。次の図は、BigQuery データをオンプレミス ロケーションに保存するために、カラム型でエクスポートするプロセスの概要を示しています。

障害復旧用の BigQuery データのカラム型ストレージへのエクスポートを示すアーキテクチャ図。

BigQuery データをオンプレミスのストレージ ロケーションにエクスポートするこのプロセスには、具体的に次のステップが含まれます。

  • BigQuery データは、Dataproc の Apache Spark ジョブに送信されます。Apache Spark ジョブを使用すると、スキーマが進化します。
  • Dataproc ジョブが BigQuery ファイルを処理した後、処理されたファイルは Cloud Storage に書き込まれ、オンプレミスの DR ロケーションに転送されます。
  • Cloud Interconnect は、Virtual Private Cloud ネットワークをオンプレミス ネットワークに接続する目的で使用されます。
  • オンプレミスの DR ロケーションへの転送は、Spark ジョブを介して行うことができます。

ウェアハウスの設計が追記専用であり、日付でパーティション分割されている場合は、新しいテーブルで BigQuery のエクスポート ジョブを実行する前に、新しいテーブルに必要なパーティションのコピーを作成する必要があります。gsutil などのツールを使用して、更新されたファイルをオンプレミスまたは別のクラウドのバックアップ ロケーションに転送できます。Google Cloud からデータを転送する場合は、下り(外向き)料金が発生する可能性があります。

たとえば、現在の日付を表すパーティションに新しい注文が追加される、追記専用の orders テーブルで構成される販売データ ウェアハウスがあるとします。ただし、返品ポリシーによって、商品が 7 日以内に返却される場合があります。したがって、過去 7 日間の orders テーブルのレコードが更新されることがあります。エクスポート戦略では、返品ポリシーを考慮する必要があります。この例では、orders テーブルをバックアップするエクスポート ジョブでは、返品による更新の欠落を避けるため、過去 7 日間の注文を表すパーティションもエクスポートする必要があります。

次のステップ