Azure Stack HCI

解決する課題

クラウドへ全面移行したいが、レイテンシ・データ所在・規制・既存資産の都合でオンプレに残さざるを得ないワークロードがある、という場面で使います。Azure Stack HCI は、自社データセンターの検証済みハードウェア上で仮想マシンやコンテナを動かしながら、その基盤を Azure 側から一元管理し、Azure のサービスにも接続できるようにします。オンプレとクラウドの「どちらか」ではなく、オンプレを残したまま Azure の運用・課金モデルに揃えていく受け皿になります。

• 工場・店舗・拠点など、現地で低レイテンシに処理したいワークロードを手元に残したい
• データ主権や規制でデータを特定の場所から出せないが、管理やガバナンスは Azure に寄せたい
• 老朽化した仮想化基盤を、Azure と同じ運用・課金に揃えながら刷新したい
• クラウドへ全面移行する前に、段階的にハイブリッド構成へ移行していきたい

主要概念と用語

• ハイパーコンバージドインフラ（HCI）: コンピューティング・ストレージ・ネットワークを専用機器に分けず、汎用サーバー群にソフトウェアで統合した基盤。スケールアウトで容量・性能を足していく
• クラスター: 複数の物理サーバー（ノード）をまとめた単位。ノードをまたいでデータを冗長化し、1 台が落ちても処理を継続する
• ストレージスペースダイレクト（S2D）: 各ノードのローカルディスクをまとめ、ソフトウェアで冗長化・プール化する分散ストレージ機構。HCI のストレージ基盤になる
• Software Defined Networking（SDN）: 仮想ネットワークやロードバランサー、ファイアウォールをソフトウェアで定義する仕組み
• Azure Arc: オンプレや他クラウドのリソースを Azure の管理面に接続する仕組み。Stack HCI のクラスターや VM を Azure ポータルから扱う土台になる
• AKS on Azure Stack HCI: クラスター上でマネージドな Kubernetes を動かし、コンテナワークロードをオンプレで運用する仕組み
• 検証済みハードウェア: パートナーが提供する、Stack HCI 向けに検証されたサーバー構成。要件を満たした機器の上で動かす
• 接続性（クラウド接続）: クラスターは定期的に Azure へ接続して登録・課金・管理を行う。完全にオフラインのままでは継続利用できない

仕様・制限・クォータ

• ノードは最小構成から複数台のクラスターまで構成でき、用途に応じてノード数を選ぶ。少数ノードの小規模拠点向け構成もある
• ストレージは S2D による冗長化が前提で、ノードやディスクの障害に備えてデータを多重化する。冗長度に応じて使える実効容量が変わる
• 利用には検証済みハードウェアが必要で、任意のサーバーに自由に入れる製品ではない
• クラスターは定期的に Azure へ接続して登録・課金・管理を行う必要があり、一定期間オフラインが続くと制限がかかる
• 課金はコア単位のサブスクリプション課金が中心で、従来の永続ライセンスとは考え方が異なる
• 対応リージョンや利用できる付帯サービスは、構成や提供時期によって差がある

内部の仕組み

物理サーバーを複数台まとめてクラスターを組み、各ノードのローカルディスクを S2D で1つのストレージプールに束ねます。VM やコンテナのデータはノードをまたいで冗長化されるため、1 台のノードやディスクが故障しても処理を継続できます。この基盤の上で Hyper-V による仮想マシンや、AKS によるコンテナを動かします。

• ストレージはノード横断で多重化され、ノード障害時には残ったノードがデータと処理を引き継ぐ
• ネットワークは SDN で仮想化でき、仮想ネットワーク・ロードバランサー・ファイアウォールをソフトウェアで定義する
• クラスターやその上の VM は Azure Arc 経由で Azure に接続され、ポータル・テンプレート・ポリシーから一元的に扱える
• クラスターは Azure へ定期的に登録・テレメトリ送信を行い、課金と管理の整合をとる

オンプレで「自分のハードウェアの上で動く」点と、管理・課金・サービス接続が「Azure 側に寄っている」点の両立が、この製品の核心です。VM は手元で動かしつつ、運用は Azure の作法に揃えていきます。

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

• エッジ・拠点配置: 工場や店舗など現地処理が要る拠点に少数ノードで配置し、低レイテンシ処理はローカル、管理は Azure 集中とする
• 段階的ハイブリッド移行: いきなり全面クラウド化せず、まずオンプレ基盤を Stack HCI に刷新して Azure 運用に揃え、移せるものから順にクラウドへ寄せる
• 冗長度の設計: ノード数とストレージの冗長度を要件から逆算し、実効容量と可用性のバランスをとる
• Arc 前提の運用設計: 監視・ポリシー・更新を Azure Arc に寄せ、オンプレとクラウドで運用手順を分断させない
• 接続性の確保: Azure への定期接続経路を冗長化し、接続断による課金・管理の制約を避ける

運用・監視

• クラスターと VM の状態は Azure ポータルや Azure Arc から一元的に監視し、オンプレとクラウドで運用面を揃える
• ノードやディスクの健全性・容量・冗長度を継続的に監視し、障害や容量逼迫の予兆を捉える
• 更新はクラスター対応のローリング更新で、ノードを順に処理しながらワークロードを止めずに適用する
• Azure Monitor などと連携し、メトリクスとログを集約して可観測性を確保する
• Azure への接続状態を監視し、長期の接続断で管理・課金に支障が出ないようにする

コスト

課金は、コア単位のサブスクリプション課金を中心に、その上で利用する VM・コンテナや Azure 付帯サービスの料金が積み上がる構成です。物理サーバーやストレージといったハードウェアの調達・運用コストは別途オンプレ側で発生します。

• 全面クラウドと比べ、オンプレに残す必然性があるワークロードに絞って配置するとコスト効率が出やすい
• ノード数・冗長度・コア数を要件から逆算し、サブスクリプションとハードウェアの両面で過剰構成を避ける

セキュリティ

• ノード間の通信やストレージは暗号化でき、データの保護と改ざん検知を図る
• クラスターや VM へのアクセスは Microsoft Entra ID + RBAC や Azure のポリシーで制御し、権限を最小化する
• セキュアブートや信頼された起動など、ハードウェアレベルの保護を備えた検証済み構成を選ぶ
• 更新をローリングで継続適用し、既知の脆弱性を放置しない運用を組み込む
• Azure Arc 経由でポリシー・コンプライアンスを一元適用し、オンプレとクラウドで統制を分断させない

関連サービス・比較

Azure Stack HCI は、Azure ファミリーの中では仮想マシンを動かす Azure Virtual Machines と役割が近い一方、その実行場所が「自社データセンター」である点が決定的に異なります。クラウド上で動かすか、手元のハードウェアで動かしつつ Azure 管理に接続するか、で使い分けます。

ハンズオン / CLI例

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

# Azure Arc などの拡張機能 CLI を準備（stack-hci 拡張を追加）
az extension add --name stack-hci

# 登録済みの Stack HCI クラスターを一覧表示
az stack-hci cluster list \
  --resource-group demo-hci-rg -o table

# 特定クラスターの状態（ノード・接続状況など）を確認
az stack-hci cluster show \
  --resource-group demo-hci-rg \
  --name demo-hci-cluster -o table

# Arc 接続されたリソース（クラスターや VM）を確認
az resource list \
  --resource-group demo-hci-rg \
  --resource-type "Microsoft.AzureStackHCI/clusters" -o table