Transfer Appliance

解決する課題

数百テラバイトからペタバイト級のデータをクラウドへ移すとき、回線の帯域が足りなければオンライン転送には何週間・何カ月もかかります。Transfer Appliance は、データを物理的なアプライアンスに格納して Google へ郵送し、オフラインで Cloud Storage に取り込むサービスです。ネットワークの制約を物理移送で回避します。

• 回線が細く、オンライン転送では移行が現実的な時間で終わらないケースを物理移送で解決する
• データ量が大きすぎて、帯域を使い切っても移行期間が長期化してしまう状況を短縮する
• 移行中に本番トラフィック用のネットワーク帯域を圧迫したくない場合に、回線を使わずに移送する
• 遠隔地・支社・現場など、十分な回線が引かれていない拠点からのデータ持ち出しに使う

主要概念と用語

• Transfer Appliance（転送アプライアンス）: データを格納するための、Google が提供する物理ストレージ機器。耐衝撃の筐体に入った状態で配送される
• アプライアンスの容量タイプ: 格納できるデータ量に応じて複数のモデルが用意されており、移行データ量に合わせて選ぶ。具体的な容量は変動するため公式を確認する
• データキャプチャ（取り込み）: 自社のデータセンターでアプライアンスにデータをコピーする工程。NFS などのプロトコルでマウントし、ローカルからデータを書き込む
• オフライン移送: アプライアンスを Google のアップロード拠点へ**郵送（出荷）**し、ネットワークを介さずにデータを運ぶ流れ
• リハイドレーション（rehydration / 展開）: Google 側でアプライアンスから読み出したデータを、指定した Cloud Storage バケットへ復元・取り込みする処理
• 暗号化と鍵: アプライアンス上のデータは暗号化され、利用者が管理する鍵で保護される。鍵が無ければデータは復号できない
• データの消去（サニタイズ）: 取り込み完了後にアプライアンス上のデータを安全に消去し、次の利用に備える工程

仕様・制限・クォータ

• デスティネーションは Cloud Storage バケット。アプライアンスに溜めたデータは、Google 側での処理を経てバケットへ展開される
• アプライアンスは容量の異なる複数モデルから選べる。1 台で足りない場合は複数台を使って大量データを分割移送する
• データの取り込みは NFS などのファイル共有プロトコル経由で行うのが基本で、ローカル環境からアプライアンスへコピーする
• アプライアンスの提供地域・配送可否は地域によって異なるため、対象リージョンで利用できるかを事前に確認する
• 申し込みからアプライアンス到着、データ取り込み、返送、Cloud Storage への展開までには相応のリードタイムがかかる。移行スケジュールに織り込む
• 容量・台数・配送条件などの具体値は変動するため、公式の最新情報を確認する

内部の仕組み

Transfer Appliance は「現地でアプライアンスにデータを書き込み、それを郵送して Google が取り込む」という、物理移送を前提としたモデルで動きます。

• アプライアンスの受領とマウント: 配送されたアプライアンスを自社ネットワークに接続し、NFS などでマウントしてローカルから書き込める状態にする
• データキャプチャ: 移行対象のファイルをアプライアンスへコピーする。書き込まれるデータは暗号化された状態で保存される
• 出荷（返送）: データを書き終えたアプライアンスを Google のアップロード拠点へ郵送する。データは回線ではなく物理的に運ばれる
• リハイドレーション: Google 側でアプライアンスからデータを読み出し、利用者が管理する鍵で復号して、指定の Cloud Storage バケットへ展開する
• 消去: 取り込み完了後、アプライアンス上のデータは安全に消去される

利用者の鍵が無ければアプライアンス上のデータは復号できないため、郵送中にアプライアンスが第三者の手に渡っても中身は保護される設計になっています。

設計パターン / ベストプラクティス

• オンラインとの使い分け: 回線で現実的な時間に終わるなら Storage Transfer Service などオンライン転送を使い、回線がボトルネックになる超大量データに Transfer Appliance を充てる
• 初回フル＋オンライン差分: 大量の初期データを物理移送で運び、その後の差分はオンライン転送で追従させる、というハイブリッド構成にする
• 複数台で分割移送: 1 台の容量を超える場合は複数アプライアンスに分割し、並行して取り込む
• 取り込みの整合性確保: 書き込み元と展開後のデータが一致するよう、チェックサム等で検証してから元データを破棄する
• スケジュール逆算: 配送・取り込み・返送・展開のリードタイムを見積もり、移行カットオーバーの日程から逆算して手配する

運用・監視

• 移行プロジェクトとしての進捗管理を行い、申し込み・配送・取り込み・返送・展開の各フェーズの状態を追う
• データキャプチャ時には、コピーの進捗とエラーを確認し、書き込みに失敗したファイルが無いかを把握する
• Cloud Storage への展開後は、展開されたオブジェクト数やサイズを元データと突き合わせ、取りこぼしが無いかを検証する
• 取り込み後のアプライアンスが安全に消去・返却されたことを確認し、移行クローズの記録を残す
• 大量データを扱うため、展開先 Cloud Storage の保管コストと容量も合わせて見ておく

コスト

Transfer Appliance のコストは、アプライアンスの利用と関連サービスの組み合わせで決まります。具体的な料金は変動するため、最新の料金ページで確認してください。

• アプライアンスの利用料: 容量タイプや利用期間に応じた料金が発生する。大容量モデルや長期の保有ほど高くなる傾向がある
• 配送関連: アプライアンスの配送・返送に関わる費用が発生し得る
• 展開先のストレージ: 取り込んだデータを保管する Cloud Storage の保管料金・操作料金が継続的にかかる
• オンラインとのコスト比較: 回線が十分にある場合はオンライン転送の方が安く済むこともある。データ量・帯域・期間を踏まえて総コストで比較する

セキュリティ

• アプライアンス上のデータは暗号化され、利用者が管理する鍵で保護される。鍵が無ければ復号できないため、輸送中の盗難・紛失でも中身は守られる
• 復号鍵は利用者側で安全に管理する。鍵を失うと取り込んだデータを復元できない点に注意する
• 取り込み完了後、アプライアンス上のデータは**安全に消去（サニタイズ）**され、残留データのリスクを下げる
• Cloud Storage への展開後のアクセス権限は Cloud IAM で制御し、最小権限で運用する
• 移行プロジェクトの操作は Cloud Audit Logs / Cloud Logging で追跡し、誰が何を行ったかを監査する

関連サービス・比較

最も近い AWS サービスは AWS Snowball です。位置づけと考え方の対応を整理します。

GCP 内では、回線で現実的に終わる移行は Storage Transfer Service などオンライン転送を使い、回線がボトルネックになる超大量データに Transfer Appliance を充てる、という棲み分けになります。両者は競合ではなく、データ量と帯域に応じた使い分けの関係です。

ハンズオン / CLI例

Transfer Appliance の手配やジョブ管理は、コンソールや専用の手順に沿って進めるのが基本です。プロジェクトや API の有効化、移送先バケットの準備といった周辺操作は Google Cloud CLI でも行えます。実際のコマンドやフラグは変わり得るため、最新のドキュメントを確認してください。

# 移行に使うプロジェクトを設定
gcloud config set project my-migration-project

# Transfer Appliance 関連 API を有効化（API 名は最新のドキュメントで確認）
gcloud services enable transferappliance.googleapis.com

# 取り込み先となる Cloud Storage バケットを準備
gcloud storage buckets create gs://my-migration-bucket \
  --location=ASIA-NORTHEAST1

# バケットの一覧と設定を確認
gcloud storage buckets describe gs://my-migration-bucket