Azure Data Box Gateway

解決する課題

オンプレで生成し続けるデータを、特別な転送ツールを書かずに継続して Azure へ送りたい場面で使います。Data Box Gateway は、オンプレの仮想化基盤上に置く仮想アプライアンスです。ローカルのファイル共有として見えるため、アプリやスクリプトはいつものファイル書き込みをするだけで、書いたデータが裏で Azure Storage へ自動転送されます。

• 継続的に発生する大量データ（メディア・ログ・バックアップ・センサーなど）を回線経由で休まず取り込みたい
• アプリ側を作り変えず、いつものファイル共有への書き込みのままクラウドへ送りたい
• 拠点やエッジで一時的にデータを受け、まとめて Azure へ流し込む中継点がほしい
• 一度きりの物理移送ではなく、定常的なクラウドへのデータ供給を仕組み化したい

主要概念と用語

• Data Box Gateway: オンプレの仮想化基盤に展開する仮想アプライアンス。ローカル共有への書き込みを Azure Storage へ継続転送する
• 仮想アプライアンス: Hyper-V や VMware などのハイパーバイザー上で動かす仮想マシンとして提供される本体
• 共有（Share）: アプライアンス上に作るファイル共有。ここに書いた内容が紐づけたストレージアカウントへ転送される
• SMB / NFS: 共有へアクセスするためのファイル共有プロトコル。クライアントの環境に合わせて選ぶ
• ストレージアカウント: 転送先となる Azure 側のストレージ。共有はここの Blob／Files にマッピングされる
• ローカルキャッシュ: アプライアンスが持つ一時保管領域。書き込みを受けてから Azure へ送り出すまでの中継に使う
• Data Box Edge（現 Azure Stack Edge）: Gateway に計算・推論機能を足した物理エッジ機器。Gateway がソフトのみなのに対し、こちらはハードを伴う

仕様・制限・クォータ

• 本体は仮想アプライアンスとして提供され、対応ハイパーバイザー上に展開する。物理デバイスの発送はない
• 転送先は Azure Blob Storage や Azure Files が中心。共有ごとに紐づけるストレージアカウントを指定する
• 共有へのアクセスには SMB / NFS を使い、クライアント側からは通常のファイル共有として見える
• アプライアンスにはローカルキャッシュの容量があり、これを超える流入が続くと転送が追いつかない場合がある
• 同時に作れる共有数や、扱えるデータ量には製品上の上限があるため、設計時に見積もる
• アプライアンスとクライアント、Azure の間でネットワーク到達性と帯域が必要。回線が転送スループットの上限になる

内部の仕組み

利用の流れは、ポータルで Gateway のリソースを作成し、提供される仮想アプライアンスのイメージをハイパーバイザーへ展開して初期構成（ネットワーク・アクティベーション）を済ませ、アプライアンス上に共有を作成して転送先ストレージアカウントを紐づける、というものです。あとはクライアントがその共有へ SMB／NFS でデータを書き込むと、アプライアンスがローカルキャッシュで受け止め、裏で Azure Storage へ継続的にアップロードします。

• クライアントからの書き込みはローカル共有への通常のファイル操作として行え、アプリの作り替えが要らない
• 書き込まれたデータはまずローカルキャッシュに置かれ、その後に Azure へ非同期で送り出される
• 転送はネットワーク経由で継続的に行われるため、データは時間差でクラウドへ反映される
• 共有とストレージアカウントの紐づけにより、書いた先がそのまま Blob／Files に現れる

物理デバイスを郵送する Data Box と異なり、Gateway は回線越しに常時転送する点が根本的な違いです。初回の一括移送はデバイス、定常的な流し込みは Gateway、と役割が分かれます。

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

• 継続供給は Gateway、初回一括は物理: 定常的に発生するデータは Gateway で流し込み、過去分の大量な初回移送は物理 Data Box で済ませる使い分けにする
• 流入量と帯域の整合: 書き込みペースと回線スループット、ローカルキャッシュ容量を見比べ、キャッシュが溢れない範囲に収める
• 共有とストレージ設計を先に決める: どの共有をどのストレージアカウント・コンテナーに紐づけるかを事前に設計し、取り込み後の整理コストを下げる
• アプリ非改変での連携: 既存のファイル出力先を Gateway の共有に向けるだけで連携でき、書き込み側を作り替えずに済ませる
• 検証の組み込み: 転送後に Azure 側の件数・容量を書き込み元と突き合わせ、欠損や遅延がないことを確認する

運用・監視

• アプライアンスやリソースの状態はポータルで監視し、転送の滞留やエラーを早めに検知する
• ローカルキャッシュの使用量を継続的に確認し、流入が転送を上回って溜まり続けていないかを見る
• 転送先ストレージの件数・容量を書き込み元と突き合わせ、データが正しく反映されているか検証する
• アプライアンスのソフトウェア更新を計画的に適用し、稼働を維持する
• 回線障害やメンテナンスに備え、書き込みが一時的に滞ってもキャッシュで吸収できる余裕を確保する

コスト

課金は主に、Gateway リソースの利用料金と、転送したデータが収まるAzure Storage の容量・トランザクション料金で構成されます。アプライアンス自体はソフトウェアとしてオンプレの基盤上で動くため、物理デバイスの発送・返送費用は発生しません。

• 物理 Data Box のような発送・延長料金はなく、代わりに回線と稼働の継続コストで考える
• 大量データの初回移送だけが目的なら、継続課金の Gateway よりも一度きりの物理デバイスが見合うこともある

セキュリティ

• クライアントから共有へのアクセスは SMB / NFS の認証で制御し、許可した相手だけが書き込めるようにする
• アプライアンスから Azure への転送、および Azure 側での保存は暗号化で保護される
• 転送先ストレージへのアクセスは Microsoft Entra ID + RBAC や鍵の管理で制御する
• アプライアンスのアクティベーションや管理操作には認証が必要で、勝手な構成変更を防ぐ
• 監査要件があるデータは、書き込みと転送のログを保全し、追跡可能性を確保する

関連サービス・比較

Azure Data Box Gateway は、同じ Data Box ファミリーの物理デバイス（Azure Data Box）と対になる存在です。どちらもオンプレのデータを Azure へ運びますが、Gateway はネットワーク経由の継続転送、Data Box は物理デバイスの一括移送、という違いがあります。

ハンズオン / CLI例

# リソースグループを作成
az group create --name demo-rg --location japaneast

# 転送先となるストレージアカウントを作成
az storage account create \
  --name demogatewaystg \
  --resource-group demo-rg \
  --location japaneast \
  --sku Standard_LRS

# Data Box Gateway のリソース（デバイス枠）を作成
az databoxedge device create \
  --name demo-gateway \
  --resource-group demo-rg \
  --location japaneast \
  --sku Gateway

# 作成した Gateway リソースの状態を確認
az databoxedge device show \
  --name demo-gateway \
  --resource-group demo-rg -o table

# 同じリソースグループ内の Data Box Edge／Gateway リソースを一覧表示
az databoxedge device list \
  --resource-group demo-rg -o table