Google Cloud リージョン間の移行: リージョン間で移行するデータとバッチ ワークロードを準備する

Last reviewed 2023-12-08 UTC

このドキュメントでは、他のリージョンへの今後の拡張やリージョン間の移行の影響を最小限に抑えるように、Google Cloud でデータ プラットフォームを設計する方法について説明します。このドキュメントは、データ プラットフォームを別のリージョンに拡張した場合の影響を理解するうえで役立つシリーズの一部です。このドキュメントでは、次のことを行う方法を説明します。

  • データとデータ パイプラインの移行を準備する。
  • 移行フェーズでのチェックを設定する。
  • データ ストレージとデータ コンピューティングを分離して、柔軟な移行戦略を作成する。

このシリーズのガイダンスは、リージョン間の移行や複数リージョンへの拡張を事前に計画していない場合にも役立ちます。この場合、リージョン間の移行や複数のリージョンへの拡張のために、インフラストラクチャ、ワークロード、データの準備に追加の作業が必要になることがあります。

このドキュメントは次のシリーズの一部です。

このシリーズは、次のドキュメントを読み、その内容を理解していることを前提としています。

次の図は、移行の過程を示しています。

4 フェーズの移行パス

各移行ステップでは、Google Cloud への移行: スタートガイドで定義されている次のフェーズに沿って作業します。

  1. ワークロードを評価して検出する。
  2. 基盤を計画して構築する。
  3. ワークロードをデプロイする。
  4. 環境を最適化する。

Google Cloud 上の最新のデータ プラットフォーム

このセクションでは、最新のデータ プラットフォームのさまざまな部分と、それらが Google Cloud で通常どのように構築されるかについて説明します。一般的なコンセプトとしてのデータ プラットフォームは、次の 2 つの部分に分けることができます。

  • 一つは、データ ストレージ レイヤで、ここにデータが保存されます。保存するデータは、Hadoop Distributed File System（HDFS）や Cloud Storage などのファイル システムで実際のバイト列を管理するファイル形式の場合もあれば、ドメイン固有言語（DSL）を使用して、データベース管理システムでデータを管理する場合もあります。
  • もう一つは、データ コンピューティング レイヤで、ストレージ システム上であらゆるデータ処理が行われる部分です。ストレージ レイヤと同様に、多くの実装が可能であり、一部のデータ ストレージ ツールはデータ コンピューティングにも対応します。プラットフォームにおけるデータ コンピューティング レイヤの役割は、ストレージ レイヤからデータを読み込み、データを処理して、結果をターゲット システムに保存することです。ターゲット システムは元のストレージ レイヤでもかまいません。

データ プラットフォームの中には、データ ストレージ レイヤに複数のストレージ システムを使用し、データ処理レイヤに複数のデータ コンピューティング システムを使用するものもあります。ほとんどの場合、データ ストレージ レイヤとデータ コンピューティング レイヤは分離しています。たとえば、次の Google Cloud サービスを使用してデータ ストレージ レイヤを実装することが考えられます。

これ以外に次のような Google Cloud サービスを使用してデータ コンピューティング レイヤを実装されている場合も考えられます。

通信時間やレイテンシ、アウトバウンド データ転送の費用、ストレージ レイヤとコンピューティング レイヤ間の I/O オペレーション回数を削減するために、データを処理するゾーンと同じゾーンにデータを保存することをおすすめします。

また、データ ストレージ レイヤとデータ コンピューティング レイヤを分けることもおすすめします。これらのレイヤを分けておくことで、コンピューティング レイヤの変更やデータの移行における柔軟性が改善されます。また、レイヤを分けておくことで、コンピューティング レイヤを常に動作させ続ける必要がなくなるため、リソースの使用量も削減されます。したがって、データ ストレージとデータコンピューティングを、同じゾーンとリージョン内の別々のプラットフォームにデプロイすることをおすすめします。たとえば、データ ストレージを HDFS から Cloud Storage に移行して、Dataproc クラスタをコンピューティングに使用できます。

環境を評価する

評価フェーズでは、デプロイしたバッチデータ パイプラインを移行するための要件と依存関係を明確にします。

  1. データ パイプラインの包括的なインベントリを作成します。
  2. プロパティと依存関係に応じてパイプラインを分類します。
  3. チームを Google Cloud でトレーニングして教育します。
  4. Google Cloud 上でテストと概念実証を作成する。
  5. ターゲット環境の総所有コスト（TCO）を計算する。
  6. 最初に移行するワークロードを選びます。

評価フェーズとこれらのタスクの詳細については、Google Cloud への移行: ワークロードの評価と調査をご覧ください。以下のセクションは、このドキュメントの情報に基づいています。

インベントリを構築する

移行の範囲を設定するために、データ パイプラインがデプロイされているデータ プラットフォーム環境を把握する必要があります。

  1. データ インフラストラクチャ（データ ストレージとバッチデータ処理に使用しているさまざまなストレージ レイヤとさまざまなコンピューティング レイヤ）のインベントリを作成します。
  2. 移行予定のデータ パイプラインのインベントリを作成します。
  3. データ パイプラインによって読み取られ、移行される必要があるデータセットのインベントリを作成します。

データ プラットフォームのインベントリを作成するには、データ インフラストラクチャの各部分について次の点を考慮してください。

  • ストレージ レイヤ。Cloud Storage のような標準のストレージ プラットフォームだけでなく、Firebase、BigQuery、Bigtable、Postgres などのデータベースや、Apache Kafka といった他のクラスタなど、他のストレージ レイヤも検討してください。それぞれのストレージ プラットフォームには、移行を完遂するための独自の戦略と方法があります。たとえば、Cloud Storage にはデータ移行サービスがありますし、データベースには移行ツールが組み込まれている場合があります。データ ストレージに使用している各プロダクトが、移行先の環境で利用できるか、互換性のある代替プロダクトがあるかどうかを確認します。関連する各ストレージ プラットフォームの技術的なデータ移行プロセスを実践して検証します。
  • コンピューティング レイヤ。それぞれのコンピューティング プラットフォームについてデプロイプランを確認し、さまざまなプラットフォームに対して行った構成変更を検証します。
  • ネットワーク レイテンシ。移行元の環境と移行先の環境間のネットワーク レイテンシをテストして検証します。データのコピーにかかる時間を把握することが重要です。また、クライアントや外部環境（オンプレミス環境など）から移行先の環境までのネットワーク レイテンシを、移行元の環境と比較してテストする必要があります。

  • 構成とデプロイ。データ インフラストラクチャ プロダクトにはそれぞれ独自の設定方法があります。各コンポーネント用に作成したカスタム構成と各プラットフォームでデフォルト バージョンを使用しているかコンポーネント（使用している Dataproc バージョンや Apache Kafka バージョンなど）についてのインベントリを行います。そうした構成が自動デプロイ プロセスの一部としてデプロイ可能であることを確認します。

    コンピューティング エンジンは、構成が異なる（特に移行中に処理レイヤのフレームワークが変更される）と動作が変わる可能性があるため、各コンポーネントがどのように構成されているかを理解しておく必要があります。たとえば、移行先の環境で異なるバージョンの Apache Spark が実行されている場合、Spark フレームワークの構成の一部がバージョン間で変わっている可能性があります。この種の構成の変更により、出力、シリアル化、コンピューティングが変わる場合があります。

    移行の際は、自動デプロイを使用して、バージョンと構成が同じものになるようにすることをおすすめします。バージョンと構成を同じものに保つことができない場合は、フレームワークが生成するデータ出力を検証するテストを実施してください。

  • クラスタサイズ。セルフマネージド クラスタ（長期間稼働している Dataproc クラスタや Compute Engine で稼働している Apache Kafka クラスタなど）の場合は、ノードと CPU の数、クラスタ内の各ノードのメモリに注意してください。別のリージョンに移行すると、デプロイで使用するプロセッサが変更されることがあります。そのため、移行したインフラストラクチャを本番環境にデプロイした後、ワークロードのプロファイリングと最適化を行うことをおすすめします。コンポーネントがフルマネージドまたはサーバーレス（Dataflow など）の場合、サイジングはクラスタ自体の要素ではなく、個々のジョブの要素になります。

インベントリで評価する以下の項目では、データ パイプラインに焦点を当てます。

  • データソースとデータシンク。各データ パイプラインがデータの読み取りと書き込みに使用するソースとシンクを考慮してください。
  • サービスレベル契約（SLA）とサービスレベル目標（SLO）。通常、バッチデータ パイプラインの SLA と SLO は、完了までの時間で測定されますが、使用したコンピューティング パワーなど、他の方法で測定することもできます。このビジネス メタデータは、ゾーンまたはリージョンの障害が発生した場合に、最も重要なパイプラインの一部を別のリージョンにフェイル オーバーするなど、事業継続と障害復旧計画プロセス（BCDR）を推進するうえで重要です。
  • データ パイプラインの依存関係。データ パイプラインの中には、別のデータ パイプラインが生成したデータに依存しているものがあります。パイプラインを移行スプリントに分割する場合は、データの依存関係を考慮してください。
  • 生成および使用されるデータセット。データ パイプラインごとに、パイプラインで使用するデータセットと、パイプラインが生成するデータセットを特定します。そうすることで、パイプライン間の依存関係や、アーキテクチャ全体における他のシステムやコンポーネント間の依存関係を特定することが容易になります。

インベントリで評価する以下の項目では、移行するデータセットに焦点を当てます。

  • データセット。移行先の環境に移行する必要があるデータセットを特定します。過去のデータがアーカイブされていて積極的に使用されていない場合は、そのデータを移行不要と判断する場合もあれば、別のタイミングで移行すると判断する場合もあります。移行プロセスの範囲と移行スプリントを定義することで、移行のリスクを軽減できます。
  • データサイズ。転送前にファイルを圧縮する予定がある場合は、圧縮前後のファイルサイズに注意してください。データのサイズは、ソースから宛先にデータをコピーするために必要な時間と費用に影響します。これらの要素を考慮することは、このドキュメントで後述するダウンタイム戦略の選択に役立ちます。
  • データ構造。移行する各データセットを分類し、そのデータが構造化データ、半構造化データ、非構造化データのどれに該当するかを把握してください。データ構造を把握すると、データが正確かつ完全に移行されたことを確認する方法の戦略がわかります。

評価を完了する

Kubernetes クラスタとワークロードに関連するインベントリを作成した後は、Google Cloud への移行: ワークロードの評価と調査における評価フェーズの残りの作業を実施します。

基盤を計画して構築する

Google Cloud への移行の計画と構築のフェーズは、次のタスクで構成されます。

  1. リソース階層を構築する。
  2. Identity and Access Management（IAM）を構成する。
  3. お支払いとご請求を設定する。
  4. ネットワーク接続を設定する。
  5. セキュリティを強化する。
  6. ロギング、モニタリング、アラートを設定する。

これらの各タスクの詳細については、Google Cloud への移行: 基盤の計画と構築をご覧ください。

データとデータ パイプラインを移行する

以降のセクションでは、データとバッチデータ パイプラインの移行プランに関するいくつかの側面について説明します。移行プランを作成するうえで理解しておくことが重要なデータ パイプラインの特性に関するコンセプトをいくつか定義します。また、データ移行の信頼性を高めることに役立つデータテストのコンセプトについても説明します。

移行プラン

移行プランには、データ移行を完了するまでの時間を含める必要があります。実際のプランでは、ネットワーク レイテンシ、データの完全性のテストと移行に失敗したデータの取得にかかる時間、ネットワークの費用などを考慮する必要があります。データはあるリージョンから別のリージョンにコピーされるため、ネットワーク費用の計画にはリージョン間のネットワーク費用を含める必要があります。

さまざまなパイプラインとデータセットをスプリントに分割し、別々に移行することをおすすめします。この方法により、各移行スプリントのリスクを軽減し、各スプリントの改善が可能になります。移行戦略を改善し、問題を早期に発見するために、大規模で重要度の高いワークロードを移行する前に、小規模で重要性の低いワークロードを優先することをおすすめします。

移行プランのもう一つの重要な部分は、コンピューティング レイヤのさまざまなデータ パイプラインの戦略、依存関係、性質を記述することです。データ ストレージ レイヤとデータ コンピューティング レイヤが同じシステム上に構築されている場合は、データのコピー中にシステムのパフォーマンスをモニタリングすることをおすすめします。一般的に、大量のデータをコピーすると、システムで I/O オーバーヘッドが発生し、コンピューティング レイヤのパフォーマンスが低下する可能性があります。たとえば、Kafka クラスタからバッチ方式でデータを抽出するワークロードを実行する場合、大量のデータを読み取るための余分な I/O オペレーションが、移行元の環境で実行中のアクティブなデータ パイプラインのパフォーマンス低下を引き起こす可能性があります。その種のシナリオでは、組み込み指標またはカスタム指標を使用してシステムのパフォーマンスをモニタリングする必要があります。システムが過負荷になることを避けるため、データのコピープロセス中に一部のワークロードを中止するか、コピーフェーズを減速させるプランを立てることをおすすめします。

データをコピーすると移行が長期にわたるプロセスになるため、移行中に問題が発生した場合に備え、緊急時対応策を用意しておくことをおすすめします。たとえば、データの移動に想定よりも時間がかかる場合や、新しいシステムをオンラインにする前に整合性テストが失敗した場合は、ロールバックするか、失敗したオペレーションを修正して再試行するかを検討します。ロールバックはより間違いのない解決策になる可能性がありますが、大規模なデータセットを何度もコピーするには、時間と費用がかかる可能性があります。どのような条件でどのアクションを取るか、パッチの作成にどの程度の時間をかけるか、どのようなときに完全なロールバックを実行するかなどを決めるために、十分に理解すること、および事前定義されたテストを用意することをおすすめします。

移行に使用するツールやスクリプトと、コピーするデータを区別することが重要です。データの移動をロールバックするには、データを再コピーし、すでにコピーしたデータをオーバーライドするか削除する必要があります。ツールやスクリプトへの変更をロールバックする方が、簡単で費用も安く済む可能性がありますが、ツールの変更によってデータの再コピーを余儀なくされる場合があります。たとえば、Cloud Storage のロケーションを動的に生成するスクリプトで新しいターゲットパスを作成すると、データの再コピーが必要になることがあります。データの再コピーを回避するには、再開可能でべき等性を備えたスクリプトを作成します。

データ パイプラインの特徴

最適な移行プランを作成するには、さまざまなデータ パイプラインの特性を理解する必要があります。データを書き込むバッチ パイプラインは、データを読み取るバッチ パイプラインとは異なることに注意してください。

  • データを書き込むデータ パイプライン: データを書き込むデータ パイプラインは移行元システムの状態を変更するため、データを移行先の環境にコピーするのと同時に移行元の環境へデータを書き込むことは困難になります。データを書き込むパイプラインの実行時間を考慮し、プロセス全体の早い段階で優先的に移行を行うようにします。これにより、データを読み取るパイプラインを移行する前に、移行先の環境でデータを準備できます。
  • データを読み取るデータ パイプライン: データを読み取るパイプラインは、データの更新速度に関する要件が異なる場合があります。データを生成するパイプラインが移行元のシステムで停止している場合でも、データを読み取るパイプラインは、データが移行先の環境にコピーされている間、実行できる可能性があります。

データは状態であり、リージョン間でのデータのコピーはアトミック オペレーションではありません。そのため、データのコピー中の状態変化に注意する必要があります。

移行プランでは、システムを区別することも重要です。システムの機能要件や非機能要件が異なる場合があります（たとえば、あるシステムはバッチ用で、別のシステムはストリーミング用など）。そのため、実際のプランには、各システムを移行するために別々の戦略を含める必要があります。システム間の依存関係を明記し、移行の各フェーズで各システムのダウンタイムを短縮する方法を示してください。

通常、移行スプリントのプランには、以下のようなものが含まれます。

  • 全体的な戦略。このスプリントで移行を処理するための戦略を記述します。一般的な戦略については、ワークロードのデプロイをご覧ください。
  • データのコピーとリソースのデプロイのためのツールと方法のリスト。移行先の環境へのデータのコピーやリソースのデプロイに使用するツールを明記します。このリストには、Cloud Storage アセットのコピーに使用するカスタム スクリプト、Google Cloud CLI などの標準ツール、移行サービスなどの Google Cloud ツールを含める必要があります。
  • 移行先の環境にデプロイするリソースのリスト。移行先の環境にデプロイする必要があるすべてのリソースをリストアップします。このリストには、Cloud Storage バケット、BigQuery データセット、Dataproc クラスタなど、すべてのデータ インフラストラクチャ コンポーネントを含める必要があります。場合によっては、初期の移行スプリントで小さい容量にサイズ調整したクラスタ（Dataproc クラスタなど）をデプロイし、その後のスプリントで新しいワークロードに合わせてサイズ変更します。実際のプランにサイズ変更の想定が含まれていることを確認してください。
  • コピーするデータセットのリスト。各データセットについて、次の情報を指定します。
    • コピーの順序（該当する場合）: ほとんどの戦略では、オペレーションの順序が重要になります。例外は、このドキュメントで後述する定期メンテナンス戦略です。
    • サイズ
    • 主要な統計情報: データセットが正常にコピーされたことを確認することに役立つ、行番号などの主要な統計情報を表にします。
    • コピーにかかる推定時間: 移行プランに基づくデータ移行完了までにかかる時間。
    • コピー方法: このドキュメントで前述したツールと方法のリストをご覧ください。
    • 検証テスト: データが完全にコピーされたことを確認するために実施するテストを明示的にリストアップします。
    • 緊急時対応プラン: 検証テストが失敗した場合の対処方法を記述します。緊急時対応プランでは、コピーの再開やギャップを埋めるタイミング、データセット全体の完全なロールバックや再コピーを行うタイミングを指定する必要があります。

テスト

このセクションでは、計画できる一般的なテストの種類について説明します。テストは、データの整合性と完全性を確認するのに役立ちます。また、コンピューティング レイヤが期待どおりに動作し、データ パイプラインを実行する準備ができていることの確認にも役立ちます。

  • サマリーまたはハッシュの比較: データをコピーした後にデータの完全性を検証するには、元のデータセットを移行先環境の新しいコピーと比較する必要があります。データが BigQuery テーブル内で構造化されている場合、テーブルは異なるリージョンに存在するため、クエリで 2 つのテーブルを結合してすべてのデータが存在するかどうかを確認することができません。費用とレイテンシの問題により、BigQuery では、クエリでリージョンをまたぐデータの結合ができません。代わりに、各データセットを要約して結果を比較する方法が必要になります。データセットの構造により、要約の方法は異なる場合があります。たとえば、BigQuery テーブルでは、集約クエリを使用する一方、Cloud Storage にある一連のファイルでは、Spark パイプラインを使用して各ファイルのハッシュを計算し、そのハッシュを集約する場合があります。

  • カナリアフロー: カナリアフローでは、データの整合性と完全性を検証するために構築されたジョブを動作させます。データ分析などのビジネス ユースケースに進む前に、カナリアフロー ジョブを実行し、入力データが一連の前提条件を満たしていることを確認すると効果的です。カナリアフローは、カスタムメイドのデータ パイプラインとして実装することも、Cloud Composer に基づく DAG のフローとして実装することもできます。カナリアフローは、特定のフィールドに欠損値がないことの確認や、特定のデータセットの行数が想定される数と一致することを検証するタスクの遂行に役立ちます。

    カナリアフローを使用して、列または部分的なデータのダイジェストやその他の集約値を作成することもできます。その後、データを、データのコピーから取得した同様のダイジェストや集約値と、カナリアフローを使用して比較できます。

    カナリアフロー方式は、Cloud Storage 上の Avro ファイルなどのファイル形式で保存およびコピーされるデータの精度を評価する必要がある場合に役立ちます。通常、カナリアフローは新しいデータを生成しませんが、入力データ内で一連のルールが満たされない場合に失敗します。

  • テスト環境: 移行プランが完了した後は、テスト環境でそのプランをテストする必要があります。テスト環境には、ネットワーク経由でデータのコピーにかかる時間を見積もるために、サンプリング データまたはステージング データを別のリージョンにコピーすることを含める必要があります。このテストは、移行プランの問題を特定し、データが正常に移行されることを確認するのに役立ちます。テストには、機能テストと非機能テストの両方を含める必要があります。機能テストでは、データが正しく移行されることを検証します。非機能テストでは、移行がパフォーマンス、セキュリティなどの非機能要件を満たしていることを検証します。実際のプランの各移行ステップには、そのステップが完了したとみなされるタイミングを詳細に示す検証基準を含める必要があります。

データの検証を容易にするために、データ検証ツール（DVT）を使用できます。このツールは、テーブルレベルから行レベルまで複数レベルのデータ検証機能を実行し、移行元システムの結果と移行先システムの結果を比較できるようにします。

テストでは、コンピューティング レイヤのデプロイを検証し、コピーされたデータセットをテストする必要があります。これを行う方法の一つは、コピーされたデータセットの集約値を計算できるテスト パイプラインを構築し、移行元のデータセットと移行先のデータセットで一致することを確認することです。移行元のデータセットと移行先のデータセットの間の不一致は、リージョンをまたいでコピーしたファイルが、移行元システムと移行先システムとの間で正確にバイトコピーされていない場合（ファイル形式やファイル圧縮を変更した場合など）によく発生します。

たとえば、改行区切りの JSON ファイルで構成されたデータセットの場合で説明します。ファイルは Cloud Storage バケットに保存され、BigQuery の外部テーブルとしてマウントされます。ネットワーク経由で移行するデータの量を削減するため、移行の一環として、ファイルを移行先の環境にコピーする前に Avro 圧縮を実行できます。この変換には多くのメリットがありますが、移行先の環境に書き込まれるファイルは移行元環境のファイルのバイトコピー表現ではないため、ある程度のリスクを伴います。

変換に伴うリスクを軽減するには、Dataflow ジョブを作成するか、BigQuery を使用してデータセットの集約値とチェックサム ハッシュを計算します（合計、平均、分位の計算など）。文字列の列の場合は、文字列の長さまたはその文字列のハッシュコードに基づいて集約値を計算できます。各行については、他のすべての列の組み合わせから集約ハッシュを計算でき、ある行がその元になるものと同等であることを高い精度で検証できます。これらの計算を、移行元と移行先の環境の両方で行い比較します。データセットが BigQuery に保存されている場合など、移行元と移行先の環境が異なるリージョンにありテーブルを結合できないときは、両方の環境に接続できるクライアントを使用する必要があります。

上記のテスト方法は、BigQuery またはバッチジョブ（Dataflow など）として実装できます。その後、集約ジョブを実行し、移行元の環境について計算された結果と移行先の環境について計算された結果を比較します。この方法は、データが完全かつ正確であることを確認するうえで役立ちます。

コンピューティング レイヤをテストするもう一つの重要な側面は、あらゆる種類の処理エンジンとコンピューティング方式を含むパイプラインを実行することです。BigQuery や Dataflow などのマネージド コンピューティング エンジンでは、パイプラインをテストすることはそれほど重要ではありません。しかし、Dataproc などの非マネージド コンピューティング エンジンでは、パイプラインをテストすることが重要です。たとえば、Apache Spark、Apache Hive、Apache Flink、Apache MapReduce など、複数の異なるタイプのコンピューティングを処理する Dataproc クラスタがある場合は、各ランタイムをテストして、異なるワークロード タイプが転送できることを確認する必要があります。

移行戦略

移行プランを適切なテストで確認した後は、データを移行できます。データを移行するときは、ワークロードごとに異なる戦略を使用できます。以下に、そのまま使用することも、ニーズに合わせてカスタマイズすることもできる移行戦略の例を示します。

  • 定期メンテナンス: カットオーバー期間が発生するタイミングを計画します。この戦略は、データが頻繁に変更されるものの、SLO と SLA が多少のダウンタイムを許容できる場合に適しています。この戦略では、データがコピーされている間にデータが完全に古いものになるため、転送されたデータの信頼度が高まります。詳細については、「Google Cloud への移行: 大規模なデータセットの転送」の定期メンテナンスをご覧ください。
  • 読み取り専用カットオーバー: 定期メンテナンス戦略を少し変化させたもので、移行元システムのデータ プラットフォームにおいて、データのコピー中に読み取り専用のデータ パイプラインがデータの読み取りを継続できるようにします。この戦略は、一部のデータ パイプラインが動作を継続し、エンドシステムに分析情報を提供できる利点があります。この戦略の欠点は、移行元のデータが更新されないため、生成されたデータが移行中に古くなることです。そのため、移行後に、エンドシステムの古いデータを考慮したキャッチアップ戦略を採用する必要が生じる可能性があります。
  • フルアクティブ: 移行元の環境が読み取りと書き込みの両方のデータ パイプラインに対してまだ有効である間に、特定のタイムスタンプでデータをコピーします。データをコピーして新しいデプロイに切り替えた後は、差分コピーフェーズを実行して、移行タイムスタンプの後に移行元の環境で生成されたデータを取得します。この方法は、他の戦略と比較して、より多くの調整と検討が必要になります。したがって、移行プランには、移行元のデータの更新と削除のオペレーションをどのように処理するかを含める必要があります。
  • 二重書き込み: データをコピーしている間、移行元と移行先の両方の環境でデータ パイプラインを実行できます。この戦略では、フルアクティブ戦略または読み取り専用戦略を使用する場合、データをバックフィルするために必要となる差分コピーフェーズを回避できます。ただし、二重書き込み戦略では、データ パイプラインが同じ結果を生成するように、移行前により多くのテストを行う必要があります。事前にテストを実施しない場合、スプリット ブレインのシナリオを統合しようとしたときに問題が発生します。また、二重書き込み戦略では、同じワークロードを別々のリージョンで 2 回実行することによる潜在的な費用も発生します。この戦略では、ダウンタイムなしでプラットフォームを移行できる可能性がありますが、正しく実行するには、かなり調整が必要になります。

移行後のテスト

移行が完了した後は、データの完全性をテストしてデータ パイプラインの有効性をテストする必要があります。スプリントで移行を実施する場合は、各スプリントの後にこれらのテストを行う必要があります。この段階で実施するテストは統合テストと似ています。本番環境レベルの完全なデータを入力に使用して、ビジネス ユースケースを実行しているデータ パイプラインの有効性をテストした後、出力の妥当性を確認します。移行元の環境と移行先の環境の両方で同じデータ パイプラインを実行することで、統合テストの出力と移行元の環境からの出力を比較できます。このタイプのテストが機能するのは、データ パイプラインが確定的で、両方の環境への入力が同一であることを確認できる場合に限られます。

一連の事前定義された基準をデータが満たした場合（移行元の環境のデータが移行先の環境のデータと同等か十分に類似している場合）、そのデータは完全であると確認できます。前のセクションで使用した戦略によっては、データが 1 対 1 で一致しないこともあります。したがって、ユースケースに応じてデータの完全性を表す基準を事前に定義しておく必要があります。たとえば、時系列データの場合、最新のレコードが現在のタイムスタンプから 5 分以上遅れていない場合にデータが完全であるとみなすことなどが考えられます。

カットオーバー

移行先の環境でデータとデータ パイプラインの検証とテストを行うと、カットオーバー フェーズを開始できます。このフェーズの開始は、クライアントが新しいシステムを参照するために、構成の変更を必要とする可能性があるということを意味します。場合によっては、その構成を、移行元のシステムの傾向を示す構成と同じものにできないことがあります。たとえば、サービスが Cloud Storage バケットからデータを読み取る必要がある場合、クライアントは使用するバケットに関する構成を変更する必要があります。Cloud Storage バケット名はグローバルに一意であるため、移行先の環境の Cloud Storage バケットは移行元の環境とは異なります。

カットオーバー フェーズでは、移行元の環境のワークロードを廃止して、スケジュールを解除する必要があります。ロールバックが必要になった場合に備え、移行元の環境のデータはしばらく保持しておくことをおすすめします。

移行前のテストフェーズは、データ パイプラインの本番環境での実行ほど完全ではありません。したがって、カットオーバーが完了し、移行先のシステムが稼働した後は、データ パイプラインの指標、ランタイム、セマンティック出力をモニタリングする必要があります。このモニタリングは、テストフェーズで見落とした可能性のあるエラーを検出して、移行の成功を確実なものにするのに役立ちます。

環境を最適化する

最適化が移行の最終フェーズになります。このフェーズでは、環境が最適化要件を満たすまで、繰り返し可能なループを何度も実行することで、環境をより効率的なものにします。

  1. 現在の環境、チーム、最適化ループを評価する。
  2. 最適化の要件と目標を設定する。
  3. 環境とチームを最適化する。
  4. 最適化ループを調整する。

Google Cloud 環境を最適化する方法の詳細については、Google Cloud への移行: 環境の最適化をご覧ください。

リージョン間の移行に向けて Google Cloud のデータとコンピューティング リソースを準備する

このセクションでは、Google Cloud 上のデータとコンピューティング リソースの概要と、リージョン間の移行に備えるための設計原則について説明します。

BigQuery

BigQuery はサーバーレス SQL データ ウェアハウスであるため、コンピューティング レイヤをデプロイする必要はありません。BigQuery クライアントで処理対象のリージョンが指定されているものがある場合は、そうしたクライアントを調整する必要があります。そうでない場合、BigQuery は移行元の環境と移行先の環境で同じものになります。BigQuery データは、次の 2 種類のテーブルに保存されます。

  • BigQuery テーブル: BigQuery 形式のテーブル。BigQuery がデータファイルを自動で管理します。BigQuery 形式でデータを移行する詳細については、データセットを管理するをご覧ください。
  • BigQuery 外部テーブル: データが BigQuery の外部に保存されるテーブル。データの移行後、新しい移行先で外部テーブルを再作成する必要があります。外部テーブルの移行について詳しくは、外部テーブルの概要をご覧ください。

Cloud Storage

Cloud Storage には、データの移行に役立つ Storage Transfer Service が用意されています。

Dataflow（バッチ）

Dataflow は Google が管理するデータ処理エンジンです。Dataflow の移行を簡素化し、ジョブを任意のリージョンに簡単にデプロイできるようにするには、すべての入力と出力をパラメータとしてジョブに挿入する必要があります。入出力データの場所をソースコードに記述するのではなく、Cloud Storage のパスとデータベース接続文字列を、引数やパラメータとして渡すことをおすすめします。

Dataproc

Dataproc はマネージド Apache Hadoop 環境であり、Apache Hadoop フレームワークと互換性のあるあらゆるワークロードを実行できます。Apache Spark、Apache Flink、Apache Hive などのフレームワークと互換性があります。

Dataproc は以下のような方法で使用でき、使用する方法によってリージョン間で Dataproc 環境を移行する方法に影響があります。

  • Cloud Storage にデータがあるエフェメラル クラスタ: クラスタは特定のジョブを実行するように構築され、ジョブが終了すると破棄されます。これは、HDFS レイヤや他のクラスタの状態も破棄されることを意味します。構成が次の条件を満たしている場合は、他のタイプと比べて移行が簡単です。
    • ジョブの入力と出力がソースコードにハードコードされておらず、入力と出力を引数として受け取る。
    • Dataproc 環境のプロビジョニングが、環境で使用している個々のフレームワークの構成を含め、自動化されている。
  • 外部データを使用する長寿命のクラスタ: クラスタに実行中のジョブがない場合でも稼働を続ける、存続期間が長い 1 つ以上のクラスタです。データはクラスタの外部で Cloud Storage や BigQuery などの Google Cloud ソリューションに保存されるため、データとコンピューティングが分離されます。通常このモデルは、ジョブがクラスタで常に実行されていて、エフェメラル モデルのようにクラスタを破棄して設定する意味がない場合に効果的です。データとコンピューティングが分離されるため、移行はエフェメラル モデルの移行と類似しています。
  • クラスタ内にデータを持つ長寿命のクラスタ: クラスタの存続期間が長く、状態、データ、またはその両方をクラスタ内に（通常は HDFS 上のデータとして）保持します。このタイプは、データとコンピューティングが分離されていないため、移行作業が複雑になります。一方だけを移行すると、不整合が生じるリスクが高くなります。このシナリオでは、移行前にデータと状態をクラスタの外部に移動して、両者を分離することを検討してください。それができない場合は、データに不整合が生じるリスクを軽減するために、定期メンテナンス戦略を使用することをおすすめします。

使用可能なフレームワークが多く、フレームワークのバージョンと構成も多数存在するため、移行プランを実行する前に徹底的なテストを行う必要があります。

Cloud Composer

Cloud Composer は、Google Cloud の Apache Airflow のマネージド版で、フローのオーケストレーションとスケジューリングに使用します。DAG、構成、ログは、Cloud Storage バケットで管理され、Cloud Composer デプロイとともに移行する必要があります。Cloud Composer デプロイの状態を移行するために、環境のスナップショットを保存して読み込みできます。

Cloud Composer インスタンスにカスタム プラグインをデプロイしている場合は、Infrastructure as Code の手法を適用して、完全に自動化された方法で環境を再作成することをおすすめします。

Cloud Composer はデータを管理しませんが、他のデータ処理フレームワークやプラットフォームを機能させます。したがって、Cloud Composer の移行はデータから完全に切り離せます。また、Cloud Composer はデータを処理しないため、デプロイがデータと同じリージョンである必要はありません。そのため、移行先の環境に Cloud Composer のデプロイを作成しても、移行元の環境でパイプラインを実行できます。そうすることで、プラットフォーム全体の移行中に、別々のリージョンで別々のパイプラインを運用できるので便利な場合があります。

Cloud Data Fusion

Cloud Data Fusion は、ビジュアル エディタを使用してデータ パイプラインを構築できるビジュアル統合ツールです。Cloud Data Fusion は、オープンソース プロジェクトの CDAP をベースにしています。Cloud Composer のように、Cloud Data Fusion はデータ自体は管理しませんが、他のデータ処理フレームワークやプラットフォームを有効にします。Cloud Data Fusion パイプラインは、次のいずれかの方法で移行元の環境からエクスポートし、移行先の環境にインポートする必要があります。

移行が必要なフローの量によって、どちらかの方法が別の方法より適している場合があります。CDAP API を使用して移行スクリプトを作成することは難しい可能性があり、より高度なソフトウェア エンジニアリング スキルが必要になります。しかし、フローの数が多い場合や、フローが比較的頻繁に変更される場合は、自動化されたプロセスが最善の方法になる可能性があります。

次のステップ

寄稿者

著者: Eyal Ben Ivri | クラウド ソリューション アーキテクト

その他の寄稿者: Marco Ferrari | クラウド ソリューション アーキテクト