Azure Stack Edge

解決する課題

データの発生源がクラウドから遠い・回線が細い・現地で即座に処理したい、といった現場でクラウドの力を借りたいときに使います。すべてのデータを Azure に送ってから処理すると、遅延や帯域コストが問題になります。Azure Stack Edge は、Microsoft が管理するエッジ機器を拠点に設置し、現地でデータ処理や AI 推論を行ったうえで、必要なデータだけを Azure へ転送することでこの問題を解決します。

• 工場・店舗・拠点など、クラウドから物理的に遠い現場で低遅延の処理をしたい
• 回線が細い・不安定な環境で、生データを送る前に現地でフィルタ・集約したい
• カメラ映像やセンサーデータに対し、現地でリアルタイムに AI 推論を回したい
• オンプレのデータを、Azure ストレージへのゲートウェイ経由で継続的に転送したい

主要概念と用語

• Azure Stack Edge: Microsoft が提供・管理する、ラックマウント型やデスクトップ型などのエッジ機器。現地処理と Azure 連携を担う
• エッジコンピューティング: データの発生源に近い場所で処理を行う考え方。クラウド往復の遅延と帯域消費を抑える
• ハードウェアアクセラレーター: 機器に搭載される GPU や FPGA、VPU などの推論用アクセラレーター。モデルによって対応構成が異なる
• エッジ計算（コンピュート）: 機器上で IoT Edge モジュールや Kubernetes ワークロードを動かし、現地でアプリや推論を実行する仕組み
• クラウドストレージゲートウェイ: 機器をローカルのファイル共有として見せ、書き込んだデータを Azure ストレージへ転送する機能
• Azure Stack ファミリー: Stack Edge（エッジ機器）、Stack HCI（ハイパーコンバージド基盤）、Stack Hub（自社運用のクラウド基盤）からなる関連製品群。役割が異なる
• as a service（サービスとしての提供）: 機器自体は購入ではなく、Microsoft が所有・管理する形で月額利用する提供形態

仕様・制限・クォータ

• 機器には複数のフォームファクターがあり、ラックマウント型・デスクトップ型・堅牢（ラギッド）型など、設置環境に応じて選ぶ
• GPU 搭載モデルや FPGA 搭載モデルなど、アクセラレーターの構成が異なるバリエーションが提供される。AI 推論の要件で選定する
• 機器は Azure ポータルからオーダーし、Microsoft が管理する。ファームウェアや基盤の更新も提供元が担う
• ローカルのデータアクセスには SMB / NFS などのファイル共有や、REST 経由のアクセスを使う
• 計算ワークロードは IoT Edge モジュールや Kubernetes を通じて配置する
• 機器の利用可否や対応構成はリージョンによって差があり、提供地域を確認する必要がある
• 月額の利用料金や対応容量・スペックは構成により異なるため、要件に合うモデルを選定する

内部の仕組み

利用の流れは、Azure ポータルから機器をオーダーし、配送された機器を拠点に設置・ネットワーク接続し、ポータルからアクティベートして使い始める、というものです。機器はローカルのファイル共有として見え、書き込んだデータは設定に従って Azure ストレージへ転送されます。あわせて、機器上で IoT Edge モジュールや Kubernetes のワークロードを動かし、転送の前後で現地処理や推論を行えます。

• ローカルへの書き込みは SMB / NFS 経由で、通常のファイル共有と同じ感覚で行える
• 書き込まれたデータはクラウドストレージゲートウェイを通じて Azure の Blob Storage などへ転送される
• 機器上の**計算（コンピュート）**で、転送前にフィルタ・集約・推論を施し、送るデータ量を減らせる
• 搭載された GPU / FPGA などのアクセラレーターを使うことで、映像やセンサーデータの推論を低遅延で処理できる
• 機器の管理（モニタリング・更新）は Azure ポータルから一元的に行える

物理機器を現地に常駐させて処理する点が、一括移送が目的の Data Box との根本的な違いです。Stack Edge は「現地処理 + 継続的なクラウド連携」、Data Box は「大容量の一括郵送」と役割が分かれます。

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

• 現地で前処理してから送る: 生データをそのまま送らず、機器上でフィルタ・集約・推論を済ませ、必要なデータだけを Azure へ転送して帯域を節約する
• 低遅延が要る推論はエッジに置く: 即応性が求められる映像解析や異常検知は、クラウド往復を避けて機器上のアクセラレーターで処理する
• 学習はクラウド、推論はエッジ: AI モデルの学習は Azure 側で行い、できたモデルを機器へ配布して現地推論に使う、という役割分担にする
• ハイブリッド転送: 継続的なデータ流入はゲートウェイ経由で送り、初回の超大容量シードが要る場合は Data Box の物理移送と組み合わせる
• フェイルセーフの設計: 回線断時の挙動（ローカルバッファや再送）を確認し、現地処理が回線に依存しすぎない構成にする

運用・監視

• 機器の状態（接続・容量・ワークロード）は Azure ポータルから一元的に監視する
• ファームウェアや基盤の更新は提供元が管理するが、適用タイミングや影響は運用計画に織り込む
• 転送ジョブの進捗や失敗を監視し、回線断時の再送やバッファが想定どおり機能するか確認する
• 現地で動かす IoT Edge モジュールや Kubernetes ワークロードの稼働状況を監視し、推論パイプラインの健全性を保つ
• 機器のメトリクスやログを Azure Monitor 連携で収集し、容量逼迫や障害の予兆を捉える

コスト

課金は主に、機器の**月額利用料金（as a service の提供料）**を中心に、転送先となる Azure ストレージの保存・操作料金、および機器上で動かすワークロードに関わる費用で構成されます。機器は購入ではなく Microsoft が所有・管理するため、初期のハードウェア購入費ではなく継続的な利用料として捉えます。

• 機器を遊ばせるほど月額が無駄になるため、稼働率に見合うモデル選定が重要
• 現地前処理で送るデータを絞ることが、帯域コストとストレージ料金の両方の削減につながる

セキュリティ

• 機器上のデータは保存時に暗号化され、現地設置や輸送時の物理リスクに備える
• 機器のアクティベートや管理は Azure ポータルと認証情報を通じて行い、許可された管理者のみが操作できる
• 転送先ストレージへのアクセスは Microsoft Entra ID + RBAC や鍵管理で制御する
• ファームウェアや基盤の更新は提供元が管理し、脆弱性対応のパッチが継続的に提供される
• 現地のネットワーク分離やファイアウォール設定で、機器とローカル環境間の通信を最小権限に絞る

関連サービス・比較

Azure Stack Edge は、同じ Data Box ファミリーに属する Azure Data Box とよく比較されます。どちらもオンプレと Azure をつなぐ機器ですが、Stack Edge は「現地で処理しながら継続的に連携するエッジ機器」、Data Box は「大容量データを一括で郵送移送する機器」という違いがあります。

ハンズオン / CLI例

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

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

# Azure Stack Edge のオーダー（デバイスジョブ）を作成
az databoxedge order create \
  --resource-group demo-rg \
  --device-name demo-edge-device \
  --contact-name "Taro Azure" \
  --company-name "Sample Inc" \
  --phone 0000000000 \
  --email-list takashi.matsuda.0627@gmail.com \
  --street-address1 "1-1-1 Sample" \
  --city Tokyo \
  --state Tokyo \
  --postal-code 1000001 \
  --country JP

# 登録済みデバイスの一覧を確認
az databoxedge device list \
  --resource-group demo-rg -o table

# デバイスの詳細（状態・モデル・接続）を確認
az databoxedge device show \
  --resource-group demo-rg \
  --device-name demo-edge-device -o table