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

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

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

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

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

4 フェーズの移行パス

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

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

データ転送とは

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

データ転送の難しさ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

セキュリティ モデル

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

Google Cloud の組織

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

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

Google Cloud 組織の構築方法について詳しくは、エンタープライズ企業のベスト プラクティスをご覧ください。

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

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

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

費用

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

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

時間

コンピューティングでは、大量のデータを転送するなど、ネットワークのハードウェア制限が強調されることはほとんどありません。通常は、1 Gbps ネットワークで 8 秒間に 1 GB を転送できます。これを巨大なデータセット(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 へ プロジェクト期限内に数 TB 未満のデータを
転送できる帯域幅がある
gsutil
プライベート データセンターから Google Cloud へ プロジェクト期限内に数 TB を超えるデータを
転送できる帯域幅がある
オンプレミス データ用の Storage Transfer Service
プライベート データセンターから Google Cloud へ プロジェクト期限内にデータを転送できる帯域幅がない Transfer Appliance

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

gsutil ツールは、一般的なエンタープライズ規模のネットワークを介してプライベート データセンターから Google Cloud へ、小規模から中規模(数 TB 未満)の転送を行う場合の標準ツールです。Cloud Shell を使用するときは、デフォルトのパスに gsutil を含めることをおすすめします。また、Cloud SDK をインストールすると、デフォルトで使用できるようになります。ローカル システムと Cloud Storage 間のデータのコピーなど、Cloud Storage インスタンスの管理に必要な基本機能をすべて備えた、信頼性に優れたツールです。他にも、オブジェクトの移動と名前の変更、rsync のような、Cloud Storage バケットへのリアルタイムの増分同期ができます。

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

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

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

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

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

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

    この方法では、大きなファイルを小さなチャンクに分割して、転送速度を上昇させます。チャンクは並行して転送および検証され、すべてのデータは Google へ送信されます。チャンクが Google へ到着すると、まとめられ(複合と呼ばれます)1 つのオブジェクトを形成します。複合することで、Cloud Storage Coldline および Cloud Storage Nearline に保存されたオブジェクトの早期削除料金が発生する可能性があるため、これらのオブジェクトでの使用は推奨されません。

    この機能には、(オブジェクト全体ではなく)個々の部分のチェックサムが個別に検証されること、コールド ストレージ クラスの複合によって早期取得ペナルティが発生するなど、いくつかのデメリットがあります。

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

gsutil と同じように、Storage Transfer Service for On Premises Data(ベータ版)を使用すると、ネットワーク ファイル システム(NFS)ストレージから Cloud Storage への転送ができるようになります。gsutil がサポートできるのは小規模な転送(最大数 TB)のみですが、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 を使用すると、Cloud Console で直接発生したエラーのサンプルを確認できます。必要に応じて、すべての転送エラーの完全なレコードを 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 の利用方法は簡単です。Cloud Console で、保有しているデータ量を指定して Transfer Appliance をリクエストすると、リクエストした場所に Google からアプライアンスが 1 つまたは複数届きます。数日以内に、データをアプライアンスに転送して(データ キャプチャ)Google に返送します。

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

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 を使用してデータ ストリームを作成をご覧ください。
  • Komprise を使用すると、オンプレミスのストレージ全体でデータを分析して、コールドデータを識別し、それらのデータを Cloud Storage に移動できます。詳細については、Komprise を使用してコールドデータを Cloud Storage にアーカイブするをご覧ください。
  • Signiant は、あらゆるファイルをどこからでも、どこにでも転送するための SaaS ソリューションとして Media Shuttle を提供しています。Signiant ではまた、高度に改善されたプロトコルに基づく自動スケーリング ユーティリティである Flight や、地理的に分散した場所全体を対象とする大規模な転送を自動化するツールである Manager+Agents も提供しています。

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

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

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

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

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

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

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

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

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

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

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

サポート

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

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

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

次のステップ