Azure Container Storage

解決する課題

データベースやメッセージキューなど**状態を持つコンテナ（ステートフルワークロード）**を AKS で動かすとき、ボリュームの作成が遅い・台数が増える・性能を引き出しにくい、といった課題を解消します。

• ポッドの数だけ大量の永続ボリュームを素早く作りたい（マネージドディスクは VM あたりのアタッチ数に上限がある）
• ローカル NVMe SSD の高速な一時領域を Kubernetes ボリュームとして安全に使いたい
• 複数のバッキング（ディスク / SAN / ローカル）を同じ操作感でプロビジョニングしたい
• Kubernetes ネイティブな宣言（PVC / StorageClass）でストレージ運用を自動化したい

主要概念と用語

• ストレージプール（Storage Pool）: バッキングストレージをまとめた論理的な容量の単位。ここからボリュームを切り出す
• バッキングストレージ（Backing Storage）: プールの裏付け。Azure マネージドディスク、Azure Elastic SAN、ノードのローカル NVMe（一時 SSD）から選ぶ
• CSI ドライバ / StorageClass: Container Storage Interface 準拠のドライバ。プールごとに StorageClass が用意され、標準の PVC でボリュームを要求する
• PV / PVC（永続ボリューム / 要求）: Kubernetes 標準の抽象。PVC を作るとプールからボリュームが動的にプロビジョニングされる
• レプリケーション: ローカル NVMe バッキングで、ノード障害に備えてボリュームを複数ノードに複製する設定
• 拡張機能（AKS Extension）: Azure Container Storage 自体は AKS の拡張機能としてクラスタに導入される

仕様・制限・クォータ

• AKS 上で動作するサービスで、対象クラスタに拡張機能として導入する
• バッキングごとに特性が異なる: マネージドディスクは永続・ゾーン内冗長、Elastic SAN は共有しやすくスケール、ローカル NVMe は最速だがノードに紐づく揮発的な領域
• ローカル NVMe バッキングは対応する VM サイズ（ローカル NVMe を持つ SKU）が必要
• プール容量やノード数、対応リージョン・可用性ゾーンには制約があり、ワークロード規模に合わせて計画する
• 導入には一定以上のノードリソース（CPU / メモリ）が必要で、小さすぎるノードでは利用できないことがある

内部の仕組み

Azure Container Storage は AKS クラスタ内で動くコントロールプレーンとして、選んだバッキングストレージをストレージプールに束ね、そこから Kubernetes の永続ボリュームを切り出します。利用者は CSI ドライバが提供する StorageClass を指定して PVC を作るだけで、裏側のマネージドディスク作成やアタッチ、ローカル NVMe の組み込みが自動化されます。

バッキングの選択がそのまま性能・耐久性のトレードオフになります。マネージドディスクはディスク自体が冗長化された永続ストレージで、ポッドが別ノードへ移ってもデータが残ります。Elastic SAN は大容量を多数のボリュームへ柔軟に割り当てやすく、スケールアウト用途に向きます。ローカル NVMe はノード直結の SSD を使うため最も低遅延・高 IOPS ですが、ノードに紐づくためそのままでは揮発的で、ノード障害でデータが失われる前提です。

ローカル NVMe の揮発性を補うため、レプリケーションを有効にするとボリュームを複数ノードに同期複製し、ノード障害時にも別レプリカから継続できます。レプリカ数を増やすほど可用性は上がりますが、書き込みは全レプリカへ反映するためスループットとコストに影響します。

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

• キャッシュ / 一時インデックスなど消えてよい高速領域にはローカル NVMe を、永続が必要な DB データにはマネージドディスクや Elastic SAN を割り当てる
• ステートフルワークロードは StatefulSet + PVC テンプレートで、ポッドごとに専用ボリュームを安定して確保する
• 可用性ゾーンをまたぐクラスタでは、ボリュームのゾーン配置とポッドのスケジューリングを揃える（別ゾーンのディスクはアタッチできない）
• ローカル NVMe で可用性が要るならレプリケーションを有効化し、必要なレプリカ数を性能・コストと天秤にかける
• ボリュームのサイズは将来の拡張を見据えつつ、過剰プロビジョニングを避けてプール容量を計画する

運用・監視

• AKS / Azure Monitor（Container Insights） でノードとポッド、ボリュームの使用率・IOPS・遅延を監視する
• kubectl get pvc / kubectl get pv でバインド状態とプロビジョニングの進捗を確認し、Pending が続く場合はプール容量やゾーン不整合を疑う
• ローカル NVMe 構成ではノードの入れ替え（アップグレード / スケール）時のデータ移行手順を事前に決めておく
• 拡張機能と CSI ドライバのバージョン更新を AKS のアップグレード運用に組み込む
• プール容量の逼迫に備え、空き容量のしきい値アラートを設定する

コスト

Azure Container Storage の課金は基本的に選んだバッキングストレージの料金に従います。マネージドディスクや Elastic SAN はプロビジョニング容量と性能に応じた課金で、ローカル NVMe は VM 価格に含まれる一時 SSD を使うため追加のストレージ課金は発生しにくい一方、その VM サイズ自体のコストがかかります。

• レプリカ数を増やすほど実効容量と書き込み負荷が増えるため、必要な可用性に見合うレプリカ数に抑える
• 使われていない PVC / PV やプールの空き容量を定期的に棚卸しして無駄を削る

セキュリティ

• バッキングがマネージドディスク / Elastic SAN の場合、保存時暗号化（SSE）が既定で有効。要件に応じカスタマー管理キー（CMK）を Key Vault で管理する
• クラスタや拡張機能の操作は Microsoft Entra ID + Azure RBAC で最小権限に制御する
• ボリュームへのアクセスは Kubernetes の RBAC と名前空間分離で制御し、不要なポッドから参照させない
• ノードとストレージ間の通信は AKS のネットワーク構成に従い、必要ならプライベートな経路で閉域化する

関連サービス・比較

土台となる Azure Managed Disks との関係を整理します。Container Storage はディスクを「コンテナ向けに束ねて自動供給する層」で、ディスク自体の置き換えではありません。

ハンズオン / CLI例

# Azure Container Storage の拡張機能を有効にして AKS クラスタを作成
az aks create \
  --resource-group demo-rg \
  --name demo-aks \
  --node-count 3 \
  --enable-azure-container-storage azureDisk \
  --location japaneast

# クラスタ認証情報を取得
az aks get-credentials \
  --resource-group demo-rg \
  --name demo-aks

# 用意された StorageClass を確認し、PVC を作成してボリュームを動的プロビジョニング
kubectl get storageclass

cat <<'EOF' | kubectl apply -f -
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: demo-pvc
spec:
  accessModes:
    - ReadWriteOnce
  storageClassName: acstor-azuredisk
  resources:
    requests:
      storage: 100Gi
EOF

# バインド状態を確認
kubectl get pvc demo-pvc