Azure File Sync

解決する課題

オンプレミスの Windows ファイルサーバーを使い続けながら、容量逼迫やバックアップ・拠点間共有の手間を解消したい場面で使います。

• ファイルサーバーのローカル容量が逼迫しているが、ユーザーには従来どおり SMB 共有のまま使わせたい
• 複数拠点に分散したファイルサーバーを1つの Azure ファイル共有へ集約し、どの拠点からも同じデータにアクセスさせたい
• アクセス頻度の低いコールドデータをクラウドへ逃がし、ローカルには使うファイルだけ残したい
• サーバーが壊れても、新しいサーバーを立ててクラウドから素早く復旧したい

主要概念と用語

• ストレージ同期サービス（Storage Sync Service）: File Sync 全体を束ねる最上位リソース。Azure 上に1つ作り、その配下に同期グループを複数持つ
• 同期グループ（Sync Group）: 同期トポロジの単位。1つのクラウドエンドポイントと、複数のサーバーエンドポイントで構成され、グループ内のデータは相互に同期される
• クラウドエンドポイント: 同期グループに紐づく Azure ファイル共有。データの正本（フルセット）を保持する中心
• サーバーエンドポイント: 登録した Windows Server 上の特定のパス（ボリュームやフォルダー）。ここがローカルキャッシュになる
• Azure File Sync エージェント: 各 Windows Server にインストールするソフトウェア。サーバー登録・同期・クラウドティアリングを担う
• クラウドティアリング（Cloud Tiering）: アクセスの少ないファイルの実体をクラウドへ移し、サーバー上は小さなポインター（再解析ポイント）だけ残す機能
• 登録済みサーバー: ストレージ同期サービスに信頼関係を結んだ Windows Server。サーバーエンドポイントを作れるようになる

仕様・制限・クォータ

• 対応 OS は Windows Server（サポート対象のバージョン）。クラウドエンドポイントの実体は SMB の Azure ファイル共有
• 1つのクラウドエンドポイントには Azure ファイル共有を1つだけ紐づける。複数の同期グループで同じ共有を共有しない
• 同期グループあたりのサーバーエンドポイント数、サービスあたりの同期グループ数などに上限がある（スケール目標として定義）
• NTFS ボリュームが前提。クラウドティアリングはシステムボリュームやブートボリュームでは使えない
• 双方向同期のため、サーバー側・クラウド側どちらの変更も伝播する。ただし変更検出には検出サイクルがあり、即時反映ではない
• ファイル名・パス長・属性の扱いは Azure ファイル共有側の制約を受ける

内部の仕組み

File Sync は、Azure ファイル共有を「正本（フルデータ）」、各 Windows Server を「キャッシュ」とみなす多対多の同期エンジンです。サーバー上の変更は USN ジャーナル（変更ログ）と定期スキャンで検出され、エージェントがクラウドエンドポイントへ反映します。クラウド側の変更は検出サイクルでサーバーへ取り込まれます。

• 名前空間とデータの分離: ティアリング有効時、サーバーはフォルダー構造とファイル名（名前空間）はすべて保持し、実体はクラウドにある。ユーザーがファイルを開くと、その場でクラウドから取得して実体化（リコール）する
• ポインター（再解析ポイント）: ティアリングされたファイルはサイズが小さなスタブになり、ローカル容量をほとんど消費しない
• 多対多同期: 1つの同期グループに複数サーバーを参加させると、各サーバーが同じクラウド共有を介して相互に同期される（拠点間共有）

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

• ファイルサーバーの容量拡張: 既存サーバーにエージェントを入れ、ティアリングでコールドデータをクラウドへ。ローカルディスクを増設せず実効容量を伸ばす
• 拠点間の共有とハブ＆スポーク: 各拠点のサーバーを同じ同期グループに参加させ、Azure ファイル共有をハブにして全拠点で同じデータを共有
• 災害復旧（DR）と高速リプロビジョニング: サーバー障害時は新サーバーを登録し、まず名前空間だけ高速に復旧。実体は必要時にリコールするため利用再開が早い
• 初期移行（シード）: 大量データの初回アップロードは時間がかかるため、ネットワーク帯域や移行手段を事前に検討する
• アンチウイルスとの共存: フルスキャンがティアリング済みファイルを一斉リコールしないよう、スキャン設定を見直す

運用・監視

• Azure Monitor / メトリクスで同期状態、同期エラー、サーバーの接続状況を監視する
• サーバー側はイベントログ（Telemetry / 同期ログ） とエージェント付属のツールで、同期の進捗やエラーファイルを確認する
• 検出サイクルがあるため、クラウド側で直接変更したファイルがサーバーへ反映されるまでに時間差が出る点を運用設計に織り込む
• 空き容量の枯渇に注意。ティアリングの空き容量ポリシーが緩いとローカルが埋まり、リコールやアプリ動作に影響する
• エージェントは定期的に更新される。サポート対象バージョンを保つようアップデート計画を立てる

コスト

File Sync 自体の課金に加え、クラウドエンドポイントである Azure ファイル共有のストレージ料金とトランザクション料金がかかります。階層化したデータの**読み出し（リコール）**でもトランザクションや下り通信が発生します。

• サーバーごとに同期サーバーの単位課金が発生する（登録サーバー数に依存）
• クラウド側は Azure ファイル共有の課金体系（容量・トランザクション・冗長性）に従う
• リコールが頻発するとトランザクションが増え割高になりやすい。ティアリングのしきい値はアクセス傾向に合わせて調整する
• 地理冗長（GRS / GZRS）を選ぶと冗長性の分だけ単価が上がる

セキュリティ

• 保存時暗号化はクラウドエンドポイント（Azure ファイル共有）側で既定で有効
• 転送時暗号化: エージェントとサービス間、サーバーと Azure ファイル共有間の通信は暗号化される
• サーバー登録は信頼関係に基づき、登録解除でサーバーをサービスから切り離せる
• ネットワーク制限: クラウドエンドポイントの Azure ファイル共有にプライベートエンドポイントを併用し、アクセスを VNet 内に閉じられる
• サーバー上の NTFS ACL はそのまま維持され、ユーザー単位のアクセス制御を引き継げる

関連サービス・比較

クラウドエンドポイントの実体は Azure Files です。「共有そのもの」を提供するのが Azure Files、それを「オンプレのキャッシュとして同期・階層化」するのが File Sync という役割分担になります。

ハンズオン / CLI例

# リソースグループとストレージ同期サービスを作成
az group create --name fsync-rg --location japaneast

az storagesync create \
  --resource-group fsync-rg \
  --name demo-sync-service \
  --location japaneast

# 同期グループを作成（クラウドエンドポイントに既存の Azure ファイル共有を指定）
az storagesync sync-group create \
  --resource-group fsync-rg \
  --storage-sync-service demo-sync-service \
  --name demo-sync-group

# クラウドエンドポイント（Azure ファイル共有）を登録
az storagesync sync-group cloud-endpoint create \
  --resource-group fsync-rg \
  --storage-sync-service demo-sync-service \
  --sync-group-name demo-sync-group \
  --name demo-cloud-endpoint \
  --storage-account <storage-account-id> \
  --azure-file-share-name shared

# サーバーエンドポイントの追加（事前にサーバーへエージェント導入・登録が必要）
# クラウドティアリングを有効化し、ボリュームの空き容量を一定割合確保する
az storagesync sync-group server-endpoint create \
  --resource-group fsync-rg \
  --storage-sync-service demo-sync-service \
  --sync-group-name demo-sync-group \
  --name demo-server-endpoint \
  --server-id <registered-server-id> \
  --server-local-path "D:\shares\data" \
  --cloud-tiering on \
  --volume-free-space-percent 20