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

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

大規模なデータセットを転送するには、適切なチームを構築し、早期に計画を立て、本番環境に実装する前に転送計画をテストする必要があります。これらの手順は、転送自体と同じくらい時間がかかる場合がありますが、このような準備を行うことで、転送中のビジネス オペレーションの中断を最小限に抑えることができます。

このドキュメントは、Google Cloud への移行に関するマルチパート シリーズの一部です。シリーズの概要に興味がある場合は、Google Cloud への移行: 移行パスの選択をご覧ください。

この記事はシリーズの一部です。
- Google Cloud への移行: はじめに
- Google Cloud への移行: ワークロードの評価と発見
- Google Cloud への移行: 基盤の構築
- Google Cloud への移行: 大規模なデータセットの転送 (このドキュメント)
- Google Cloud への移行: ワークロードのデプロイ
- Google Cloud への移行: 手動デプロイから自動化されたコンテナ化されたデプロイへの移行
- Google Cloud への移行: 環境の最適化
- Google Cloud への移行: 移行計画を検証するためのベスト プラクティス
次の図は、移行プロセスのパスを示しています

デプロイ フェーズは、GCP への移行の第 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 アカウント チームや統合パートナーなど) 移管の決定の承認: データ所有者またはガバナーどのデータを転送することが許可されているか)、法律顧問 (データ関連の規制)、およびセキュリティ管理者 (データ アクセスの保護方法に関する内部ポリシー) 転送の実行: チーム リーダー、プロジェクト マネージャー (プロジェクトの実行と追跡) ）、エンジニアリング チーム、オンサイトでの受け取りと発送（アプライアンス ハードウェアを受け取るため）
転送プロジェクトの前の責任者を特定し、必要に応じて計画および決定会議に含めることが重要です。不十分な組織計画は、多くの場合、異動イニシアチブの失敗の原因です
これらの利害関係者からプロジェクトの要件と情報を収集することは困難な場合がありますが、計画を立てて明確な役割と責任を確立することは成果をもたらします。データのすべての詳細を知ることは期待できません。チームを編成することで、ビジネスのニーズに対するより深い洞察が得られます。転送を完了するために時間、お金、およびリソースを投資する前に、潜在的な問題を特定することをお勧めします。

## ステップ 2: 要件と利用可能なリソースの収集
転送計画を設計するときは、まずデータ転送の要件を収集してから、転送オプションを決定することをお勧めします。要件を収集するには、次のプロセスを使用できます。
- 移動する必要があるデータセットを特定する

- Data Catalog などのツールを選択して、移動して一緒に使用できる論理グループにデータを整理します

- 組織内のチームと協力して、これらのグループを検証または更新します

- どのデータセットを特定するか
動ける

- 規制、セキュリティ、またはその他の要因により、一部のデータセットの転送が禁止されているかどうかを検討してください

- 移動する前にデータの一部を変換する必要がある場合 (機密データの削除やデータの再編成など)、Dataflow や Cloud Data Fusion などのデータ統合製品、または Cloud Composer などのワークフロー オーケストレーション製品の使用を検討してください。

- 移動可能なデータセットの場合、各データセットの転送先を決定する

- データを保存するために選択したストレージ オプションを記録します。通常、Google Cloud のターゲット ストレージ システムは Cloud Storage です。アプリケーションの稼働後にさらに複雑なソリューションが必要になった場合でも、Cloud Storage はスケーラブルで耐久性のあるストレージ オプションです

- 移行後に維持する必要があるデータ アクセス ポリシーを理解する

- このデータを特定の地域に保存する必要があるかどうかを判断する

- このデータを目的地でどのように構造化するかを計画します。たとえば、それはソースと同じですか、それとも異なりますか?
- 継続的にデータを転送する必要があるかどうかを判断する

- 移動可能なデータセットの場合、利用可能なリソースを決定します
それらを移動するには

- 時間: いつ転送を完了する必要がありますか?
- 費用: チームに利用できる予算と移籍費用は?
- 人: 誰が転送を実行できますか?
- 帯域幅 (オンライン転送用): Google Cloud で現在使用可能な帯域幅のうち、転送に割り当てられる量と期間はどれくらいですか?
計画の次のフェーズで転送オプションを評価して選択する前に、データ ガバナンス、組織、セキュリティなど、IT モデルのいずれかの部分を改善できるかどうかを評価することをお勧めします。

 セキュリティ モデル
転送チームの多くのメンバーは、データ転送プロジェクトの一環として、Google Cloud 組織で新しいロールを付与される場合があります。 データ転送計画は、Identity and Access Management (IAM) のアクセス許可と、IAM を安全に使用するためのベスト プラクティスを確認する絶好の機会です。 これらの問題は、ストレージへのアクセスを許可する方法に影響を与える可能性があります。 たとえば、規制上の理由でアーカイブされたデータへの書き込みアクセスに厳しい制限を設ける一方で、多くのユーザーとアプリケーションがテスト環境にデータを書き込むことを許可する場合があります。   Google Cloud 組織 Google Cloud でデータをどのように構造化するかは、Google Cloud の使用方法によって異なります。 アプリケーションを実行するのと同じ Cloud プロジェクトにデータを保存するのは簡単な方法ですが、管理の観点からは最適ではない可能性があります。 一部の開発者は、本番データを表示する権限を持っていない場合があります。 その場合、開発者はサンプル データでコードを開発でき、特権サービス アカウントは本番データにアクセスできます。 したがって、本番データセット全体を別の Cloud プロジェクトに保持し、サービス アカウントを使用して各アプリケーション プロジェクトからのデータへのアクセスを許可することができます。  Google Cloud はプロジェクトを中心に編成されています。 プロジェクトはフォルダーにグループ化でき、フォルダーは組織の下にグループ化できます。 役割はプロジェクト レベルで確立され、アクセス権限は Cloud Storage バケット レベルでこれらの役割に追加されます。 この構造は、他のオブジェクト ストア プロバイダーの権限構造と一致しています。  Google Cloud 組織を構築するためのベスト プラクティスについては、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 のグローバル ネットワークにルーティングする可能性があります以下を確認することをお勧めします会社のポリシーで一部のデータセットを公共のインターネット経由で移動することを禁止しているかどうかについて、セキュリティ管理者に相談してください。また、本番トラフィックにパブリック インターネット接続が使用されているかどうかも確認してください。大規模なデータ転送は本番ネットワークに悪影響を与える可能性がありますダイレクト ピアリングによる接続
パブリック インターネット接続より少ないネットワーク ホップで 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 CloudStorage Transfer Service|
|Cloud Storage から Cloud Storage (2 つの異なるバケットストレージ転送サービス|
|プライベート データセンターから Google Cloud へ||プロジェクトの締め切りに間に合う十分な帯域幅
| |
1 TB 未満のデータの場合
| |
| |
|プライベート データセンターから Google Cloud へ||プロジェクトの締め切りに間に合う十分な帯域幅
| |
1 TB を超えるデータの場合
|オンプレミスデータのストレージ転送サービス|
|プライベート データセンターから Google Cloud ||プロジェクトの締め切りに間に合わせるには十分な帯域幅がありません||Transfer Appliance|
オンプレミス データの小規模転送用の gsutil
の
gsutil ツール
小～中規模の送金（200万円未満）の標準ツールです。
プライベート データ センターから、一般的なエンタープライズ規模のネットワーク経由で 1 TB)
Google Cloud に。含めることをお勧めします
デフォルト パスの gsutil
使用するとき
クラウド シェル

をインストールすると、デフォルトで使用可能になります。
Google クラウド CLI

管理に必要なすべての基本機能を提供する信頼できるツールです
きみの
クラウドストレージ
これには、ローカル ファイル システムとの間のデータのコピーが含まれます。
クラウドストレージ。また、オブジェクトを移動および名前変更し、実行することもできます
リアルタイムの増分同期など
rsync、Cloud Storage バケットへ

gsutil は、次のシナリオで特に役立ちます。
- 転送は、必要に応じて、またはユーザーによるコマンドライン セッション中に実行する必要があります。

- 少数のファイルまたは非常に大きなファイル、またはその両方を転送している

- プログラムの出力を使用している (出力を Cloud Storage にストリーミングしている)

- 適度な数のファイルを含むディレクトリを監視し、非常に低いレイテンシーで更新を同期する必要があります

始めるための基本
gsutil は
Cloud Storage バケットを作成する
と
データのコピー
そのバケツに。大規模なデータセットを転送するには、次の 2 つの方法があります。
検討：
マルチスレッド転送の場合は、
gsutil -m

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

単一の大きなファイルの場合は、複合転送を使用します

この方法では、大きなファイルを小さなチャンクに分割して、転送速度を向上させます。チャンクは並行して転送および検証され、すべてのデータが Google に送信されます。チャンクが Google に到着すると、それらが結合されます（
構成) 単一のオブジェクトを形成する

gsutil を使用した複合転送には、(オブジェクト全体ではなく) 各部分が個別にチェックサムされることや、コールド ストレージ クラスの構成によって早期削除ペナルティが発生することなど、いくつかの欠点があります。

 オンプレミス データの大規模な転送用の Storage Transfer Service
好き
gsutil、
オンプレミス データの Storage Transfer Service
ネットワーク ファイル システム (NFS) ストレージから
クラウドストレージ。それでも
gsutil は小さな転送サイズ (最大) をサポートできます。
1 TB まで)、オンプレミス データ用の Storage Transfer Service は、
大規模な転送 (最大でペタバイトのデータ、数十億のファイル)。サポートしています
フル コピーまたは増分コピーであり、リストされているすべての転送オプションで動作します
以前に
Google の転送オプションの決定。これ
また、管理されたシンプルなグラフィカル ユーザー インターフェイスも備えています。技術に精通していなくても
ユーザー（セットアップ後）はそれを使用してデータを移動できます

オンプレミス データの Storage Transfer Service は、次のシナリオで特に役立ちます。
- データ ボリュームを移動するのに十分な帯域幅があること (Google Cloud Data Transfer Calculator を参照)  - コマンドラインを見つける可能性のある内部ユーザーの大規模なベースをサポートします ツールのような gsutil 使い方が難しい  - 堅牢なエラー報告と、移動されたすべてのファイルとオブジェクトの記録が必要です  - データセンター内の他のワークロードへの転送の影響を制限する必要があります (この製品は、ユーザーが指定した帯域幅制限内に留まることができます)。  - 定期的な送金を定期的に実行したい  オンプレミス データ用の Storage Transfer Service をセットアップするには、オンプレミスにインストールします。 プレミス ソフトウェア [*エージェント*として知られる] をデータ センター内のコンピューターに転送します。 これらは エージェントは Docker コンテナー内にあるため、それらの多くを簡単に実行したり、 それらを Kubernetes でオーケストレーションする  セットアップが完了したら、ユーザーは次の方法で Google Cloud コンソールで転送を開始できます。 ソース ディレクトリ、宛先バケット、時間またはスケジュールを提供する  Storage Transfer Service は、サブディレクトリとファイルを再帰的にクロールします。 ソースディレクトリに対応する名前のオブジェクトを作成します Cloud Storage [オブジェクト /dir/foo/file.txt は、/dir/foo/file.txt という名前の宛先バケット内のオブジェクトになります]。 保管転送サービス 一時的なエラーが発生した場合、自動的に転送を再試行します  転送の実行中に、移動されたファイルの数を監視し、 全体的な転送速度、およびエラーのサンプルを表示できます  転送が完了すると、タブ区切りファイル (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 は特定の国でのみ利用可能です考慮すべき 2 つの主な基準Transfer Appliance の利点は、コストと速度です。妥当なネットワーク接続 (たとえば、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 ドル未満ですクラウド間の転送用のストレージ転送サービスストレージ転送サービスはフル マネージドです、他のパブリックから Cloud Storage への転送を自動化する非常にスケーラブルなサービス。Amazon S3 および HTTP から Cloud Storage への転送をサポートしていますAmazon S3 の場合、アクセス キーと S3 バケットをオプションのS3 フィルターで指定できますオブジェクトを選択してから、S3 オブジェクトを任意のにコピーします。
Cloud Storage バケット。このサービスは、任意の日付のコピーもサポートしています。
変更されたオブジェクト。サービスは現在データ転送をサポートしていません
*に*
アマゾン S3

HTTP の場合、Storage Transfer Service に公開 URL のリストを指定できます。
指定された形式

このアプローチでは、それぞれのサイズを提供するスクリプトを作成する必要があります。
バイト単位のファイルと、ファイル コンテンツの Base64 でエンコードされた MD5 ハッシュ

ファイル サイズとハッシュは、ソース Web サイトから入手できる場合があります。もしも
そうではなく、ファイルへのローカル アクセスが必要です。
使用する
前述の gsutil

転送を実施している場合、Storage Transfer Service は、特に別のパブリック クラウドから転送する場合に、データを取得して保持するための優れた方法です。

 安全
多くの Google Cloud ユーザーにとって、セキュリティは最優先事項であり、さまざまなレベルのセキュリティを利用できます。考慮すべきセキュリティのいくつかの側面には、保管中のデータの保護 (ソースおよび宛先ストレージ システムへの許可とアクセス)、転送中のデータの保護、および転送製品へのアクセスの保護が含まれます。次の表は、製品ごとのセキュリティのこれらの側面の概要を示しています

| |
|製品 |
|保存データ |
|転送中のデータ |
|転送製品へのアクセス
|Transfer Appliance||すべてのデータは保存時に暗号化されますデータは顧客が管理するキーで保護されます誰でもアプライアンスを注文できますが、それを使用するにはデータ ソースにアクセスする必要があります。|
| |
||保存時に暗号化される Cloud Storage にアクセスするために必要なアクセス キーデータは HTTPS 経由で送信され、転送時に暗号化されます誰でもダウンロードして実行できます
| |
|オンプレミス データ用のストレージ転送サービス||保存時に暗号化される Cloud Storage にアクセスするために必要なアクセス キー。エージェント プロセスは、OS パーミッションが許可するローカル ファイルにアクセスできます。データは HTTPS 経由で送信され、転送中に暗号化されます。Cloud Storage バケットにアクセスするには、オブジェクト エディターのパーミッションが必要です。|
|Storage Transfer Service||Google Cloud 以外のリソース（Amazon S3 など）に必要なアクセス キー。 Cloud Storage にアクセスするにはアクセス キーが必要です。保存時に暗号化されます。データは HTTPS 経由で送信され、転送時に暗号化されます。ソースにアクセスするには、サービス アカウントの IAM 権限と、任意の Cloud Storage バケットのオブジェクト エディター権限が必要です。|
ベースラインのセキュリティ強化を達成するために、オンライン転送
Google Cloud を使用
gsutil
HTTPS 経由で実行され、データは転送中に暗号化され、すべてのデータは
Cloud Storage は、デフォルトで保存時に暗号化されます。詳細については、
より洗練されたセキュリティ関連のスキームについては、を参照してください。
セキュリティとプライバシーに関する考慮事項

使用する場合
転送アプライアンス、
管理するセキュリティ キーは、データの保護に役立ちます。一般的に、私たちは
転送計画が確実に実行されるように、セキュリティ チームを関与させることをお勧めします。
会社および規制要件を満たす

 サードパーティ転送製品
高度なネットワーク レベルの最適化または進行中のデータ転送ワークフローについては、より高度なツールを使用することをお勧めします。より高度なツールについては、Google パートナーにアクセスしてください

次のリンクは、多くのオプションの一部を強調しています (ここではアルファベット順にリストされています)。
- Aspera On Cloud は、Aspera の特許取得済みプロトコルに基づいており、大規模なワークフローに適しています。サブスクリプション ライセンス モデルとしてオンデマンドで利用可能

- Tervela の Cloud FastPath を使用して、Google Cloud との間でマネージド データ ストリームを構築できます。詳細については、「Cloud FastPath を使用してデータ ストリームを作成する」を参照してください

- Signiant は、Media Shuttle をサービスとしてのソフトウェア (SaaS) ソリューションとして提供し、あらゆるファイルをどこからでも、またはどこからでも転送できます。 Signiant はまた、高度に最適化されたプロトコルに基づく自動スケーリング ユーティリティとして Flight を提供し、地理的に分散した場所間での大規模な転送のための自動化ツールとして Signiant Flight Deck を提供します。

## ステップ 4: 転送の準備
大規模な転送、または重要な依存関係を持つ転送の場合、転送製品の操作方法を理解することが重要です。お客様は通常、次の手順を実行します。
価格設定と ROI の見積もり。このステップでは、意思決定に役立つ多くのオプションが提供されます。機能テスト: このステップでは、製品が正常にセットアップされ、ネットワーク接続 (該当する場合) が機能していることを確認します。また、データの代表的なサンプル (VM インスタンスの移動など、付随する非転送手順を含む) を移動先に移動できることもテストします。

通常、転送マシンや帯域幅などのすべてのリソースを割り当てる前に、この手順を実行できます。このステップの目標は次のとおりです。
- 転送をインストールして操作できることを確認します

- データの移動 (ネットワーク ルートなど) または運用 (転送以外の手順で必要なトレーニングなど) をブロックする、プロジェクトを停止させる可能性のある問題を明らかにします。

パフォーマンス テスト。このステップでは、次のことを行うために運用リソースが割り当てられた後、データの大規模なサンプル (通常は 3±5%) で転送を実行します。
- 割り当てられたすべてのリソースを消費でき、期待する速度を達成できることを確認します

- ボトルネックの表面化と修正 (ソース ストレージ システムの低速化など)

## ステップ 5: 転送の整合性を確保する
転送中のデータの整合性を確保するために、次の予防措置を講じることをお勧めします。
- 宛先でバージョン管理とバックアップを有効にして、誤って削除した場合の損害を制限します

- ソース データを削除する前にデータを検証する

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

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

## 助けを求める
Google Cloud では、Google Cloud サービスを最大限に活用するために必要なヘルプとサポートを見つけるためのさまざまなオプションとリソースを提供しています。
セルフサービス リソース。専用のサポートが必要ない場合は、自分のペースで使用できるさまざまなオプションがあります。テクノロジー パートナー。Google Cloud は複数の企業と提携して、Google のプロダクトやサービスの使用を支援しています。 Google Cloud プロフェッショナル サービス。Google のプロフェッショナル サービスは、Google Cloud への投資を最大限に活用するのに役立ちます。

Google Cloud 移行センターには、ワークロードを Google Cloud に移行するのに役立つその他のリソースがあります

これらのリソースの詳細については、Google Cloud への移行: はじめにの検索ヘルプ セクションをご覧ください。

＃＃ 次は何ですか
- 転送計画の考案や特定のユースケースについて質問がある場合は、Google Cloud サポートに連絡するか、Google アカウント チームに直接連絡してください。

- 転送を開始するために、次のガイドを提供しています。
- 一般的なデータ移行戦略の場合: モノリシック アプリケーションを Google Kubernetes Engine のマイクロサービスに移行する
- オフライン転送の場合: Transfer Appliance
・パブリッククラウドからのオンライン転送の場合：ストレージ転送サービス
- Google Cloud に関するリファレンス アーキテクチャ、図、チュートリアル、ベスト プラクティスを調べます。クラウド アーキテクチャ センターをご覧ください。