Google Cloud への移行: 大規模なデータセットの転送

Last reviewed 2022-12-29 UTC

多くのお客様にとって、Google Cloud プロダクト導入の最初のステップは、Google Cloud にデータを取り込むことです。このドキュメントでは、データ移転の計画から、計画の実装におけるベスト プラクティスの使用まで、データ取り込みのプロセスについて説明します。

大規模なデータセットを転送するには、適切なチームを構築し、早期に計画を立て、本番環境に実装する前に転送計画をテストする必要があります。これらの手順は移行そのものと同じくらいの時間がかかることもありますが、移行中の業務の中断を最小限に抑えることができます。

このドキュメントは、Google Cloud への移行に関する複数のパートからなるシリーズの一部です。シリーズの概要については、Google Cloud への移行: 移行パスの選択をご覧ください。

この記事はシリーズの一部です。

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

4 フェーズの移行パス

デプロイ フェーズは、Google Cloud への移行の 3 番目のフェーズです。このフェーズでは、ワークロードのデプロイ プロセスを設計します。

このドキュメントでは、オンプレミス環境、非公開のホスティング環境、または別のクラウド プロバイダから Google Cloud への移行を計画する際に役立つ情報を提供します。また、移行について検討している場合、その概要を把握するためにも利用できます。

データ移転とは

このドキュメントでのデータ移転は、ファイルをそのままオブジェクトに移動するなど、データを変換せずに移動するプロセスを指します。

データ転送の難しさ

データ移転は 1 つの巨大な FTP セッションで、片側に入れたファイルが反対側から出てくるのを待つもの、と考えがちです。しかし、ほとんどの企業環境では、移行プロセスには次のような多くの要因が関係します。

  • 転送オプションの決定、承認の取得、予期しない問題への対処など、管理にかかる時間を考慮した転送計画を作成する。
  • 転送を実行するチーム、ツールやアーキテクチャを承認する担当者、データの移行によるメリットや中断を懸念するビジネス関係者など、組織内のユーザーを調整する。
  • リソース、費用、時間、プロジェクトにおけるその他の考慮事項に基づいて、適切な転送ツールを選択する。
  • 「光の速度」の問題(帯域幅不足)、アクティブに使用されているデータセットの移動、処理中のデータの保護とモニタリング、データ移転を確実に成功させるなど、データ転送に関する課題を解決する。

このドキュメントは、移行を成功させるためのサポートを目的としています。

次のリストは、このドキュメントで扱っていない他のタイプのデータ転送プロジェクトのリソースです。

  • データの変換(行の結合、データセットの結合、個人を特定できる情報のフィルタリングなど)が必要な場合は、Google Cloud のデータ ウェアハウスにデータを保存できる抽出、変換、読み込み(ETL)ソリューションを検討してください。このアーキテクチャの例については、こちらの Dataflow のチュートリアルをご覧ください。
  • データベースと関連アプリを移行する必要がある場合(データベース アプリのリフト&シフトなど)は、Cloud Spanner のドキュメント、PostgreSQL のソリューション、およびデータベースの種類に関する他のドキュメントをご覧ください。
  • HBase から HBase API との互換性があり、大規模なワークロードを処理できるフルマネージド NoSQL データベース サービスにデータを移行する場合は、Cloud Bigtable を参照してください。
  • 仮想マシン(VM)インスタンスを移行する必要がある場合は、Google の VM 移行プロダクト(Migrate to Virtual Machines)の使用を検討してください。

ステップ 1: チームを編成する

転送を計画するには、通常、次のロールと責任を持つ担当者が必要です。

  • 移行に必要なリソースの有効化: ストレージ、IT、ネットワーク管理者、上層部のプロジェクト スポンサー、その他のアドバイザー(Google アカウント チームや統合パートナーなど)
  • 移行決定の承認: データ所有者または管理者(誰がどのデータを移行できるかに関する内部ポリシー)、法務アドバイザー(データ関連の規制)、セキュリティ管理者(データアクセスの保護に関する内部ポリシー)
  • 転送の実行: チームリーダー、プロジェクト マネージャー(プロジェクトの実行と追跡)、エンジニアリング チーム、オンサイトでの受け渡し(アプライアンス ハードウェアの受け取り)

転送プロジェクトにおける上記の責任者を特定し、必要に応じて計画や意思決定の場に参加させることが重要です。多くの場合、組織計画が不十分であることが転送イニシアチブの失敗につながります。

これらの関係者からプロジェクトの要件や意見を収集することが容易でないこともありますが、計画を立て、明確なロールと責任を確立すると、最終的には実を結びます。自分 1 人でデータの詳細をすべて把握するのは非常に困難です。チームを編成することで、ビジネスのニーズをさらに詳しく把握できます。ベスト プラクティスとして、移行の完了に時間、資金、リソースを投資する前に、潜在的な問題を特定することをおすすめします。

ステップ 2: 要件と利用可能なリソースを収集する

転送計画を設計する際は、まずデータ移転の要件を収集してから、転送オプションを決定することをおすすめします。要件を収集するには、次の手順を行います。

  1. 移動する必要があるデータセットを特定します。
    • Data Catalog などのツールを選択して、データを論理グループにまとめて移動し、一緒に使用します。
    • 組織内のチームと協力して、これらのグループを検証または更新します。
  2. 移動できるデータセットを特定します。
    • 規制、セキュリティ、その他の要因によって、一部のデータセットの転送を禁止するかどうかを検討します。
    • 移行前にデータの一部などを変換する必要がある場合(センシティブ データの削除やデータの再編成)は、Dataflow または Cloud Data Fusion などのデータ インテグレーション サービス、あるいは Cloud Composer のようなワークフロー オーケストレーション サービスを使用することを検討してください。
  3. 移動可能な各データセットの転送先を決定します。
    • データを保存するために選択したストレージ オプションを記録します。通常、Google Cloud のターゲット ストレージ システムは Cloud Storage です。Cloud Storage は、アプリケーションの運用開始後に複雑なソリューションが必要になった場合でも対応できる、スケーラブルで耐久性のあるストレージ オプションです。
    • 移行後に維持する必要があるデータアクセス ポリシーを理解します。
    • このデータを特定のリージョンに保存する必要があるかどうかを判断します。
    • 転送先でどのようにこのデータを構造化するか計画します。たとえば、ソースと同じ方法で構造化するかどうかなどが考えられます。
    • 継続的にデータを転送する必要があるかどうかを判断します。
  4. 移動可能なデータセットの場合、移動に使用できるリソースを決定します。
    • 時間: いつまでに転送を完了する必要がありますか?
    • 費用: チームが使用できる予算と転送費用はどのくらいありますか?
    • 担当者: 転送を実行できるユーザーは誰ですか?
    • 帯域幅(オンライン転送の場合): Google Cloud で現在使用可能な帯域幅のうち、転送に割り当てることができるのはどのくらいですか?また、割り当てられる期間はどのくらいですか?

計画の次の段階で転送オプションを評価して選択する前に、データ ガバナンス、組織、セキュリティなど、IT モデルの改善が可能な点がないかどうかを評価することをおすすめします。

セキュリティ モデル

データ転送プロジェクトの一環として、転送チームの多くのメンバーに Google Cloud 組織の新しいロールが付与される場合があります。データ転送計画は、Identity and Access Management(Cloud IAM)権限と Cloud IAM を安全に使用するためのベスト プラクティスを確認する絶好の機会です。これらの問題は、ストレージへのアクセス権の付与に影響する可能性があります。たとえば、規制上の理由でアーカイブされたデータへの書き込みアクセスを厳密に制限し、一方でテスト環境への書き込みは多くのユーザーやアプリケーションに許可することもできます。

Google Cloud の組織

Google Cloud のデータ構造は、Google Cloud の使用方法によって異なります。アプリケーションを実行する同じ Google Cloud プロジェクトにデータを保存することは簡単ですが、管理面で最適な方法とは言えません。開発者によっては、本番環境データを表示する権限がない場合もあります。その場合、開発者はサンプルデータのコードを開発し、本番環境データには権限のあるサービス アカウントがアクセスすることが考えられます。そのため、本番環境のデータセット全体を別の Google Cloud プロジェクトに保存し、サービス アカウントを使用して各アプリケーション プロジェクトのデータにアクセスできるようにするとよいでしょう。

Google Cloud はプロジェクトを中心に構成されています。プロジェクトはフォルダにグループ化でき、フォルダは組織の下にグループ化できます。ロールはプロジェクト レベルで設定され、アクセス権限は Cloud Storage バケットレベルで追加されます。この構造は、他のオブジェクト ストア プロバイダの権限構造と一致します。

Google Cloud 組織を構造化するためのベスト プラクティスについては、Google Cloud ランディング ゾーンのリソース階層を決定するをご覧ください。

ステップ 3: 転送オプションを評価する

データ移転オプションを評価するには、転送チームは次のような要素を考慮する必要があります。

  • 費用
  • 転送時間
  • オフラインとオンラインの転送オプション
  • 転送ツールとテクノロジー
  • セキュリティ

費用

データ転送に関連する費用の大半は、次のとおりです。

  • ネットワーク費用
    • Cloud Storage への上り(内向き)は無料です。ただし、パブリック クラウド プロバイダでデータをホストする場合は、データ転送の下り(外向き)料金が発生し、さらにストレージ費用(読み取りオペレーションなど)が発生する可能性があります。この料金は、Google または他のクラウド プロバイダからのデータに適用されます。
    • 独自に運用しているプライベート データセンターでデータがホストされている場合は、Google Cloud の帯域幅を増やすための追加費用が発生する可能性があります。
  • データの転送中と転送後の Cloud Storage のストレージとオペレーションの費用
  • プロダクトの費用(Transfer Appliance など)
  • チームの編成とサポートの取得にかかる人件費

転送時間

コンピューティングでは、大量のデータを転送するなど、ネットワークのハードウェア制限が強調されることはほとんどありません。理論上、1 Gbps のネットワークでは、1 GB を 8 秒で転送できます。これを巨大なデータセット(100 TB など)にスケールアップした場合、転送時間は 12 日間になります。巨大なデータセットを転送すると、インフラストラクチャの制限が試され、ビジネスに問題を引き起こす可能性があります。

次の計算ツールを使用すると、移動するデータセットのサイズと転送に使用できる帯域幅を考慮して、転送にかかる時間を把握できます。計算には、一定割合の管理時間が考慮されます。また、実際の帯域効率も含まれているため、得られる数値はより現実的なものとなり、架空の数値ではなくなります。

ピーク時は、大規模なデータセットを会社のネットワークから転送しない方がよい場合があります。転送によってネットワークが過負荷になると、必要な作業やミッション クリティカルな作業を完了できなくなるからです。このため、転送チームは時間の要素を考慮する必要があります。

データが Cloud Storage に転送された後、Dataflow などのさまざまなテクノロジーを使用して新しいファイルを処理できます。

ネットワーク帯域幅の増強

ネットワーク帯域幅を増やす方法は、Google Cloud への接続方法によって異なります。

Google Cloud と他のクラウド プロバイダの間のクラウド間転送では、Google がクラウド ベンダーのデータセンター間の接続をプロビジョニングします。セットアップは不要です。

プライベート データセンターと Google Cloud の間でデータを転送する場合、主に次の 3 つの方法があります。

  • 公開 API を使用した公共のインターネット接続
  • 公開 API を使用したダイレクト ピアリング
  • 非公開 API を使用した Cloud Interconnect

これらのアプローチを評価する際は、長期的な接続ニーズを考慮することが重要です。転送目的でのみ帯域幅を取得するのは費用がかかりすぎると考えがちですが、Google Cloud の長期使用と組織全体のネットワーク ニーズを考慮すると、投資する価値がある場合もあります。

公共のインターネット接続を利用する場合

公共のインターネット接続を使用する場合、インターネット サービス プロバイダ(ISP)の容量とルーティングによる制限があるため、ネットワーク スループットの予測は難しくなります。ISP が制限付きのサービスレベル契約(SLA)を提供している場合もありますが、提供していない場合もあります。ただし、これらの接続は比較的低コストで利用できます。Google の拡張ピアリングにより、ご使用の ISP から Google のグローバル ネットワークに 2、3 回のホップで転送される場合もあります。

会社のポリシーで公共のインターネット上でのデータセットの移動が禁止されてないかどうか、セキュリティ管理者に確認することをおすすめします。また、本番環境のトラフィックに公共のインターネット接続が使用されているかどうかも確認してください。大規模なデータ転送は、本番環境ネットワークに悪影響を及ぼす可能性があります。

ダイレクト ピアリングで接続する場合

公共のインターネット接続よりも少ないネットワーク ホップで Google ネットワークにアクセスするには、ダイレクト ピアリングを使用します。ダイレクト ピアリングを使用すると、ネットワークと Google のエッジ接続拠点(PoP)の間でインターネット トラフィックを交換できます。つまり、データは公共のインターネットを使用しません。これにより、ネットワークと Google のネットワーク間のホップ数も減少します。Google ネットワークとのピアリングでは、登録済みの自律システム(AS)番号の設定、インターネット エクスチェンジを使用した Google への接続、24 時間体制のネットワーク オペレーション センターの連絡が必要となります。

Cloud Interconnect 接続

Cloud Interconnect は、Google または Cloud Interconnect サービス プロバイダを介して Google Cloud に直接接続します。このサービスを使用すると、データが公共のインターネットに送信されるのを防ぐことができ、大規模なデータ転送に一貫したスループットを提供できます。通常、Cloud Interconnect はネットワークの可用性とパフォーマンスに関する SLA を提供します。詳細については、直接サービス プロバイダにお問い合わせください。Cloud Interconnect はプライベート アドレス指定(RFC 1918)にも対応しているため、パブリック IP アドレスや NAT を必要とせずにプライベート データセンターをクラウドで拡張します。

オンライン転送とオフライン転送

データ転送にオフライン プロセスとオンライン プロセスのどちらを使用するかは、非常に重要です。つまり、専用の相互接続か公共のインターネットかを問わずネットワーク経由で転送するか、ストレージ ハードウェアを使用して転送するかを選択する必要があります。

この決定に活用できるように、これら 2 つのオプションの時間と費用の差を算出できる移行計算ツールをご用意しています。次のグラフは、さまざまなデータセット サイズと帯域幅の転送速度を示しています。これらの計算には一定の管理オーバーヘッドが考慮されています。

転送サイズと転送速度の関係を示すグラフ。

前述のように、データ移転の低レイテンシ(ネットワーク帯域幅の取得など)を実現するための費用が、組織にとっての投資価値に見合うものがどうかを検討する必要があります。

Google が提供するオプション

Google では、データ転送の実行に役立つさまざまなツールとテクノロジーを提供しています。

Google の転送オプションの選択

次の表に示すように、転送オプションの選択はユースケースによって異なります。

データの移行元 事例 おすすめのプロダクト
別のクラウド プロバイダ(Amazon Web Services、Microsoft Azure など)から Google Cloud へ - Storage Transfer Service
Cloud Storage から Cloud Storage へ(2 つの異なるバケット間) - Storage Transfer Service
プライベート データセンターから Google Cloud へ プロジェクト期限内にデータを転送できる帯域幅がある gsutil
プライベート データセンターから Google Cloud へ プロジェクト期限内にデータを転送できる帯域幅がある オンプレミス データ用の Storage Transfer Service
プライベート データセンターから Google Cloud へ プロジェクト期限内にデータを転送できる帯域幅がない Transfer Appliance

gsutil: オンプレミス データの転送量が少ない場合

gsutil ツールは、一般的なエンタープライズ規模のネットワークを介してプライベート データセンターから中小規模の転送を行う場合の標準ツールです。別のクラウドプロバイダから Google Cloud へ移行できます。gsutil は、Cloud Storage オブジェクトの最大サイズまでのオブジェクトのアップロードをサポートしていますが、大規模なオブジェクトの転送は、短時間の転送よりもエラーが高くなる可能性があります。大規模オブジェクトを Cloud Storage に転送する方法について詳しくは、Storage Transfer Service: オンプレミス データの転送量が多い場合 をご覧ください。

Cloud Shell を使用するときは、デフォルトの PATH に gsutil を含めることをおすすめします。また、Google Cloud CLI をインストールすることによっても、デフォルトで使用できます。ローカル システムと Cloud Storage 間のデータのコピーなど、Cloud Storage インスタンスの管理に必要な基本機能をすべて備えた、信頼性に優れたツールです。他にも、オブジェクトの移動と名前の変更、rsync のような、Cloud Storage バケットへのリアルタイムの増分同期ができます。

gsutil は、次のシナリオで特に役立ちます。

  • ユーザーが必要に応じて、またはコマンドライン セッション中に転送を実行する必要がある場合。
  • 転送するファイルが少ないか、非常に大きい、もしくはその両方。
  • プログラムの出力を使用している(Cloud Storage に出力をストリーミングしている)場合。
  • 適度な数のファイルを含むディレクトリを監視し、非常に低いレイテンシで更新を同期する必要がある場合。

gsutil の基本的な使い方は、まず Cloud Storage バケットを作成し、そのバケットにデータをコピーすることです。大規模なデータセットを転送する場合は、次の 2 つの点を考慮する必要があります。

  • マルチスレッド転送の場合は、gsutil -m を使用する。

    複数のファイルが並行処理されるため、転送速度が向上します。

  • 巨大なファイルを 1 つ転送する場合、複合転送を使用する。

    この方法では、大きなファイルを小さなチャンクに分割して、転送速度を上昇させます。チャンクは並行して転送および検証され、すべてのデータは Google へ送信されます。チャンクが Google へ到着すると、まとめられ(複合化と呼ばれます)1 つのオブジェクトを形成します。

    gsutil を使用した複合転送には、オブジェクト全体ではなく個々の部分のチェックサムが個別に検証される、コールド ストレージ クラスの複合化によって早期削除のペナルティが発生するなど、いくつかのデメリットがあります。

Storage Transfer Service: オンプレミス データの転送量が多い場合

gsutil と同じように、Storage Transfer Service for On Premises Data を使用すると、ネットワーク ファイル システム(NFS)ストレージから Cloud Storage への転送ができるようになります。gsutil は大規模な転送サイズをサポートできますが、Storage Transfer Service for On Premises Data は大規模な転送(最大ペタバイトのデータ、数十億のファイル)用に設計されています。完全コピーまたは増分コピーをサポートし、Google の転送オプションの選択で前述したすべての転送オプションで動作します。また、シンプルなマネージド グラフィカル ユーザー インターフェースで、IT に詳しくないユーザーであっても(セットアップ後に)データの移動に使用できます。

Storage Transfer Service for On Premises Data は、次のシナリオで特に役立ちます。

  • データ ボリュームを移動するために十分な帯域幅がある場合(Google Cloud Data Transfer Calculator を参照)。
  • gsutil のようなコマンドライン ツールの使用が難しいと感じる可能性のある、多数の社内ユーザーをサポートしている場合。
  • 堅牢なエラー報告と、移動されたすべてのファイルとオブジェクトの記録が必要な場合。
  • データセンター内の他のワークロードへ転送が与える影響を制限する必要がある場合(このプロダクトはユーザー指定の帯域幅制限内に収まります)。
  • 定期的な転送を実行する場合。

Storage Transfer Service for On Premises Data を設定するには、オンプレミス ソフトウェア(エージェント)をデータセンターのコンピュータにインストールします。これらのエージェントは Docker コンテナ内にあるため、多数のエージェントの実行や Kubernetes でのオーケストレートが簡単になります。

セットアップが完了したら、移行元ディレクトリ、移行先バケット、時間またはスケジュールを指定して、Google Cloud Console で転送を開始できます。Storage Transfer Service は、ソース ディレクトリ内のサブディレクトリとファイルを再帰的にクロールし、対応する名前のオブジェクトを Cloud Storage に作成します(/dir/foo/file.txt オブジェクトは /dir/foo/file.txt という移行先バケットのオブジェクトになります)。Storage Transfer Service は、一時的なエラーが発生すると自動的に再試行します。転送の実行中に、移動済みのファイル数と全体の転送速度をモニタリングし、エラーサンプルを表示できます。

転送が完了すると、扱ったすべてのファイルと受信したエラー メッセージの全レコードを含むタブ区切りファイル(TSV)が生成されます。エージェントはフォールト トレラントであるため、エージェントがダウンしても、残りのエージェントで転送が続行されます。エージェントは自己更新と自己回復も行うため、最新バージョンのパッチを適用する必要や、予期しない問題が発生した場合にプロセスを再開する必要はありません。

Storage Transfer Service を使用する際の考慮事項。

  • すべてのマシンで同一のエージェント セットアップを使用します。すべてのエージェントに同じネットワーク ファイル システム(NFS)を同じように(同じ相対パス)マウントする必要があります。このセットアップは、プロダクトが機能するための必須要件です。
  • エージェントが多いほど、処理速度が向上します。転送はすべてのエージェント間で自動的に並列化されるため、多数のエージェントをデプロイして、使用可能な帯域幅を使用することをおすすめします。
  • 帯域幅の上限によってワークロードを保護できます。他のワークロードがデータセンターの帯域幅を使用することもあるため、転送が SLA に影響しないように帯域幅の上限を設定します。
  • エラーの確認にかかる時間を計画します。大規模な転送では、確認が必要なエラーが発生することがよくあります。Storage Transfer Service を使用すると、Google Cloud コンソールで直接発生したエラーのサンプルを確認できます。必要に応じて、すべての転送エラーの完全なレコードを BigQuery に読み込んで、ファイルのチェックや再試行後に残ったエラーの評価ができます。これらのエラーは、転送中にソースに書き込むアプリを実行している場合や、トラブルシューティングが必要な問題(権限エラーなど)があることを示している場合があります。
  • 長時間実行される転送向けに Cloud Monitoring をセットアップします。Storage Transfer Service を使用すると Monitoring でエージェントの健全性とスループットをモニタリングできるため、エージェントが停止した場合や注意が必要な場合にアラートが通知されます。転送に数日から数週間かかる場合のエージェント障害の対処は重要です。プロジェクト タイムラインの遅れにつながりかねない大幅な速度低下や中断を避けることができます。

Transfer Appliance: 大規模な転送の場合

大規模な転送(特にネットワーク帯域幅が限られている転送)で、とりわけ高速ネットワーク接続が利用できず、帯域幅を増やす費用が高すぎる場合、Transfer Appliance が最適なオプションです。

Transfer Appliance は、次のシナリオで特に役立ちます。

  • データセンターが離れた場所にあり、帯域幅へのアクセスが限られているかまったくアクセスできない場合。
  • 帯域幅があっても、プロジェクトの期限までに取得することができない場合。
  • アプライアンスを受け取りネットワークに接続するための、物流リソースへのアクセスがある場合。

このオプションでは、次の点を考慮します。

  • Transfer Appliance を活用するには、Google が所有するハードウェアを受け取って返送できる必要があります。
  • インターネット接続によって異なりますが、Google Cloud へのデータ転送のレイテンシはオンラインよりも Transfer Appliance の方が通常長くなります。
  • Transfer Appliance は一部の国でのみご利用いただけます。

Transfer Appliance で考慮すべき 2 つの主な基準は、費用と速度です。一般的なネットワーク接続(1 Gbps など)では、100 TB のデータをオンラインで転送するのに 10 日以上かかります。この速度が許容範囲であれば、オンライン転送がニーズに適したソリューションということになります。100 Mbps の接続しか使用していない場合(または遠隔地から接続している場合)、同じ転送に 100 日以上かかります。この時点で、Transfer Appliance などのオフライン転送オプションを検討する価値があります。

Transfer Appliance の利用方法は簡単です。Google Cloud コンソールで、保有しているデータ量を指定して Transfer Appliance をリクエストすると、リクエストした場所に Google からアプライアンスが 1 つまたは複数届きます。数日以内に、データをアプライアンスに転送して(データ キャプチャ)Google に返送します。

ネットワーク アプライアンスのお届け、データの読み込み、返送、Google Cloud での復元までの所要期間は 20 日です。オンライン転送の期間がこの期間よりも大幅に長いと予想される場合は、Transfer Appliance の使用を検討してください。300 TB のデバイス処理にかかる総費用は $2,500 未満です。

Storage Transfer Service: クラウド間転送の場合

Storage Transfer Service は、スケーラビリティに優れたフルマネージド サービスで、他のパブリック クラウドから Cloud Storage への転送を自動化します。Amazon S3 と HTTP から Cloud Storage への転送がサポートされています。

Amazon S3 の場合、選択する S3 オブジェクトで任意にフィルタした S3 バケットとアクセスキーを指定し、S3 オブジェクトを任意の Cloud Storage バケットにコピーします。また、このサービスでは変更が加えられたオブジェクトを毎日コピーできます。現時点では、Amazon S3 へのデータ転送はサポートされていません。

HTTP の場合、Storage Transfer Service に決まったフォーマットでパブリック URL を指定します。このアプローチでは、スクリプトを記述する際に各ファイルのサイズ(バイト)およびファイル コンテンツの Base64 でエンコードされた MD5 ハッシュを指定する必要があります。ファイルサイズとハッシュは、ソースのウェブサイトから利用できる場合もあります。そうでなければ、ファイルへのローカル アクセスが必要となり、前述のとおり gsutil を使用する方が簡単です。

転送の準備ができているなら、Storage Transfer Service はとりわけ別のパブリック クラウドから転送する場合に、データを取得して保持するための優れた方法です。

セキュリティ

セキュリティを最優先に考える多くの Google Cloud ユーザー向けに、さまざまなレベルのセキュリティをご用意しています。セキュリティに関する考慮事項として、保存データの保護(送信元と宛先のストレージ システムへの承認とアクセス)、転送中のデータの保護、転送プロダクトへのアクセスの保護などがあります。次の表に、これらのセキュリティの側面をサービス別に示します。

サービス 保存データ 転送中のデータ 転送プロダクトへのアクセス
Transfer Appliance すべてのデータは保存時に暗号化されます。 データはお客様が管理する鍵で保護されます。 アプライアンスは誰でも注文できますが、使用するにはデータソースへのアクセスが必要です。
gsutil 保管時に暗号化される Cloud Storage にアクセスするために必要なアクセスキー。 データは HTTPS 経由で送信され、転送中に暗号化されます。 gsutil は、誰でもダウンロードして実行できます。データを移行するには、バケットとローカル ファイルに対する権限が必要です。
オンプレミス データ用の Storage Transfer Service 保管時に暗号化される Cloud Storage にアクセスするために必要なアクセスキー。エージェント プロセスは、OS の権限で許可されているローカル ファイルにアクセスできます。 データは HTTPS 経由で送信され、転送中に暗号化されます。 Cloud Storage バケットにアクセスするには、オブジェクトの編集権限が必要です。
Storage Transfer Service Google Cloud 以外のリソース(Amazon S3 など)に必要なアクセスキー。保管時に暗号化される Cloud Storage にアクセスするには、アクセスキーが必要です。 データは HTTPS 経由で送信され、転送中に暗号化されます。 ソースにアクセスするためのサービス アカウントと Cloud Storage バケットのオブジェクト編集者権限の IAM 権限が必要です。

ベースライン セキュリティ強化のため、gsutil を使用した Google Cloud へのオンライン転送は HTTPS で行われます。転送中のデータは暗号化され、保存中の Cloud Storage のデータもすべてデフォルトで暗号化されます。より高度なセキュリティ関連のスキームについては、セキュリティとプライバシーの留意事項をご覧ください。Transfer Appliance を使用する場合は、管理するセキュリティ キーを使用してデータを保護できます。通常は、転送計画が会社と規制の要件を満たしていることを確認するために、セキュリティ チームと連携することをおすすめします。

サードパーティの転送プロダクト

高度なネットワークレベルの最適化や継続的なデータ移転ワークフローが必要な場合、より高度なツールを使用できます。より高度なツールについては、Google パートナーにお問い合わせください。

以下のリンクでは、さまざまなオプションを紹介しています(アルファベット順)。

  • Aspera On Cloud は、特許取得済みの Aspera のプロトコルに基づく、大規模なワークフローに適したツールです。サブスクリプション ライセンス モデルとしてオンデマンドで利用できます。
  • Tervela の Cloud FastPath を使用すると、Google Cloud との間でマネージド データ ストリームを構築できます。詳細については、Cloud FastPath を使用してデータ ストリームを作成をご覧ください。
  • Signiant は、あらゆるファイルをどこからでも、どこにでも転送するための SaaS ソリューションとして Media Shuttle を提供しています。Signiant ではまた、高度に改善されたプロトコルに基づく自動スケーリング ユーティリティである Flight や、地理的に分散した場所全体を対象とする大規模な転送を自動化するツールである Signiant Flight Deck も提供しています。

ステップ 4: データ移行方法を評価する

データを移行する際は、次の一般的な手順を行います。

  1. 前のサイトから新しいサイトにデータを転送する。
  2. 複数のソースから同じデータを同期する場合など、データ インテグレーションで発生した問題を解決する。
  3. データの移行を検証します。
  4. 新しいサイトをプライマリ コピーに昇格する。
  5. フォールバックの必要がなくなったら、前のサイトを廃止する。

データの移行戦略を決める場合、次のことを検討します。

  • 移行が必要なデータの量はどれくらいか
  • このデータはどのくらいの頻度で変更されるのか
  • カットオーバーまでのダウンタイムを許容できるか
  • 現在のデータ整合性モデルは何か

最善の方法はありません。どれを選択するかは環境と要件によって異なります。

以下では、次の 4 つのアプローチについて説明します。

  • 定期メンテナンス
  • 継続的なレプリケーション
  • Y(書き込み / 読み取り)
  • データアクセス マイクロサービス

どのアプローチにも課題はあります。問題点は、データ移行の規模や要件によって異なります。

マイクロサービス アーキテクチャの場合、データアクセス マイクロサービスが最も望ましい選択肢ですが、データ移行という点では他のアプローチも有効です。データアクセス マイクロサービスを使用するためにインフラストラクチャの最新化が必要な場合は、他のアプローチのほうがよい場合もあります。

次のグラフは、それぞれのアプローチのカットオーバーまでの期間、リファクタリングの作業量、柔軟性を比較しています。

4 つのアプローチの柔軟性、リファクタリングの作業量、カットオーバーまでの期間を相対的に表した棒グラフ

これらのアプローチを実施する前に、新しい環境に必要なインフラストラクチャが準備されていることを確認してください。

定期メンテナンス

ワークロードのカットオーバーに余裕がある場合は、定期メンテナンスが理想的な選択肢です。カットオーバーの時期を計画できるため。

このアプローチでは、次の手順で移行を行います。

  1. 前のサイトにあるデータを新しいサイトにコピーします。このコピーを行うことで、カットオーバーまでの時間を短縮できます。この後は、移行期間中に変更されたデータだけをコピーします。
  2. データの検証と整合性のチェックを行い、前のサイトのデータと新しいサイトにコピーしたデータを比較します。
  3. コピーしたデータがこれ以上変更されないように、これらのデータに書き込み権限のあるワークロードとサービスを停止します。
  4. 最初のコピーの後に発生した変更を同期します。
  5. 新しいサイトを使用するように、ワークロードとサービスをリファクタリングします。
  6. ワークロードとサービスを開始します。
  7. フォールバックの必要がなくなったら、前のサイトを廃止します。

このアプローチでは、ワークロードとサービスのリファクタリングは最小限になるため、ほとんどの作業が運用側で行われます。

継続的なレプリケーション

カットオーバーまでに余裕のないワークロードがある場合は、最初のコピーと検証の後にレプリケーションを継続的に行うようにスケジューリングできます。このとき、データが変更される頻度も考慮する必要があります。2 つのシステムが同期された状態を維持するのが難しい場合もあります。

継続的なレプリケーションは、定期メンテナンスよりも複雑になりますが、同期に必要なデータ量が最小限になるため、カットオーバーまでの時間は短くなります。継続的なレプリケーションを行う場合の移行手順は次のようになります。

  1. 前のサイトにあるデータを新しいサイトにコピーします。このコピーを行うことで、カットオーバーまでの時間を短縮できます。この後は、移行期間中に変更されたデータだけをコピーします。
  2. データの検証と整合性のチェックを行い、前のサイトのデータと新しいサイトにコピーしたデータを比較します。
  3. 前のサイトから新しいサイトへの継続的なレプリケーションを設定します。
  4. 移行するデータ(つまり、前の手順に含まれるデータ)にアクセスできるワークロードとサービスを停止します。
  5. 新しいサイトを使用するように、ワークロードとサービスをリファクタリングします。
  6. レプリケーションによって新しいサイトがレガシーサイトに完全に同期されるまで待ちます。
  7. ワークロードとサービスを開始します。
  8. フォールバックの必要がなくなったら、前のサイトを廃止します。

このアプローチでは、定期メンテナンスの場合と同様に、大半の作業は運用側で行います。

Y(書き込み / 読み取り)

ワークロードに高い可用性が必要で、カットオーバーまでのダウンタイムを許容できない場合は、別のアプローチが必要になります。この場合、このドキュメントで Y(書き込み / 読み取り)と呼んでいるアプローチを使用できます。これは一種の並行移行です。移行が終わるまで前のサイトと新しいサイトの両方でデータの書き込みと読み取りを行います。この Y の文字は、移行期間中のデータフローの形を記号として表したものす。

このアプローチの場合、移行手順は次のようになります。

  1. データを前のサイトから読み取り、前のサイトと新しいサイトの両方に書き込むように、ワークロードとサービスをリファクタリングします。
  2. 新しいサイトへの書き込みを有効にする前に書き込まれたデータを識別し、そのデータを前のサイトから新しいサイトにコピーします。前述のリファクタリングとともに、これによりデータストアがアライメントされます。
  3. データの検証と整合性のチェックを行い、前のサイトのデータと新しいサイトのデータを比較します。
  4. 読み取りオペレーションを前のサイトから新しいサイトに切り替えます。
  5. データの検証と整合性のチェックを再度行い、前のサイトのデータと新しいサイトのデータを比較します。
  6. 前のサイトへの書き込みを無効にします。
  7. フォールバックの必要がなくなったら、前のサイトを廃止します。

定期メンテナンスや継続的なレプリケーションとは異なり、このアプローチでは複数のリファクタリングが必要になるため、ほとんどの作業を開発側が行うことになります。

データアクセス マイクロサービス

Y(書き込み / 読み取り)アプローチで必要なリファクタリングを少なくしたい場合は、データアクセス マイクロサービスを使用するようにワークロードとサービスをリファクタリングします。これにより、データの読み取り / 書き込みオペレーションが一元化されます。このスケーラブルなマイクロサービスがデータ ストレージ レイヤへの唯一のエントリ ポイントとなり、レイヤのプロキシとして機能します。アーキテクチャの他のコンポーネントに影響を与えず、カットオーバーまでの期間を考慮せずにコンポーネントをリファクタリングできるため、ここで説明しているアプローチの中では最も柔軟な方法となります。

データアクセス マイクロサービスを使用するアプローチは Y(書き込み / 読み取り)とよく似ています。違うのは、データ ストレージ レイヤにアクセスするすべてのワークロードとサービスをリファクタリングするのではなく、データアクセス マイクロサービスをリファクタリングする点です。このアプローチの場合、移行手順は次のようになります。

  1. 前のサイトと新しいサイトの両方にデータを書き込むように、データアクセス マイクロサービスをリファクタリングします。読み取りは前のサイトに対して行われます。
  2. 新しいサイトへの書き込みを有効にする前に書き込まれたデータを識別し、そのデータを前のサイトから新しいサイトにコピーします。前述のリファクタリングとともに、これによりデータストアがアライメントされます。
  3. データの検証と整合性のチェックを行い、前のサイトのデータと新しいサイトのデータを比較します。
  4. 新しいサイトからデータを読み取るようにデータアクセス マイクロサービスをリファクタリングします。
  5. データの検証と整合性のチェックを再度行い、前のサイトのデータと新しいサイトのデータを比較します。
  6. 新しいサイトにのみ書き込むように、データアクセス マイクロサービスをリファクタリングします。
  7. フォールバックの必要がなくなったら、前のサイトを廃止します。

このアプローチでは、Y(書き込み / 読み取り)と同様に、作業の大半を開発側で行います。ただし、リファクタリングはデータアクセス マイクロサービスにのみ行うため、Y(書き込み / 読み取り)よりも負担はかなり軽減されます。

ステップ 5: 転送を準備する

大規模な転送の場合、もしくは依存関係が大きい転送の場合、移行サービスをどのように運用するか理解することが重要です。通常は次のステップを行います。

  1. 料金と ROI の見積もりこのステップでは、意思決定に役立つさまざまなオプションを提供します。
  2. 機能テストこのステップでは、プロダクトが正常にセットアップされていること、ネットワーク接続(該当する場合)が動作することを確認します。また、データの代表的なサンプルを宛先に移動できるかどうかテストします(VM インスタンスの移動などの転送以外のステップを含む)。

    通常、このステップは転送マシンや帯域幅などのすべてのリソースを割り当てる前に行うことができます。このステップの目標は次のとおりです。

    • 転送をインストールして操作できることを確認する。
    • データ移動(ネットワーク ルートなど)やオペレーション(転送以外のステップで必要なトレーニングなど)を妨げる、潜在的なプロジェクト停止の問題を明らかにする。
  3. パフォーマンス テストこのステップでは、本番環境リソースが次の目的で割り当てられた後に、実際のデータの大型のサンプル(通常は 3~5%)で転送を実行します。

    • 割り当てられたすべてのリソースを使用でき、期待する速度を達成できることを確認する。
    • ボトルネックを明らかにし、解決する(低速なソース ストレージ システムなど)。

ステップ 6: 転送の整合性を確保する

転送中のデータの整合性を確保するため、次の点に注意することをおすすめします。

  • 転送先でバージョニングとバックアップを有効にして、誤って削除した場合の被害を抑える。
  • ソースデータを削除する前にデータを検証する。

大規模なデータ転送(数ペタバイトのデータと数十億のファイル)の場合、基盤となるソース ストレージ システムのベースラインの潜在エラー率が 0.0001% と低くても、数千ものファイルとギガバイトの損失が生じてしまいます。通常、ソースで実行されているアプリケーションはこれらのエラーに対応しているため、追加の検証は必要ありません。例外的なシナリオ(長期間のアーカイブなど)では、ソースから安全にデータを削除する前に追加の検証を行う必要があります。

アプリケーションの要件によっては、転送の完了後にデータの整合性テストを実行して、アプリケーションが意図したとおりに動作するかどうか確認することをおすすめします。多くの転送プロダクトには、データの整合性チェックが組み込まれています。ただし、リスク プロファイルによっては、ソースからデータを削除する前に、データとそのデータを読み取るアプリに対して追加のチェックを行うことをおすすめします。たとえば、記録して計算したチェックサムが宛先に書き込まれたデータと一致するか、アプリケーションで使用されたデータセットが正常に転送されたかを確認してください。

サポート

Google Cloud では、Google Cloud サービスを最大限有効に利用していただくために、必要なヘルプとサポートを見つける際の各種のオプションとリソースを提供しています。

Google Cloud 移行センターには、ワークロードの Google Cloud への移行に利用できるリソースがさらにあります。

これらのリソースの詳細については、Google Cloud への移行: スタートガイドサポートを見つけるをご覧ください。

次のステップ