AKS（Azure Kubernetes Service）上でステートフルワークロードを運用するエンジニアにとって、長年の悩みだった「1ノードあたりのディスク接続数上限」がついに本格的に解消される。Azure Container Storage v2.1.0がGAとなり、Elastic SAN（ESAN）との統合が正式サポートされた。単なるバージョンアップではなく、Kubernetesストレージの設計思想そのものを変える可能性がある変更だ。
Elastic SAN統合が「なぜ大きいか」
従来のAzureディスク（Managed Disk）は、VMに直接アタッチするアーキテクチャを取る。これはシンプルで信頼性が高い反面、1台のVMがアタッチできるディスク数に上限がある（一般的なLinuxノードで最大64枚程度）。PVの数が増えるほど、この制約がボトルネックになる。
Elastic SANはこのアーキテクチャを根本から変える。iSCSI over TCP/IPでボリュームを接続するため、VMのディスクアタッチ制限とは独立して動作する。AKSのLinuxノードでは、iSCSIセッション数はディスクアタッチ制限に縛られないため、1ノードに数百〜数千のPVを接続することが現実的になる。
パフォーマンスのスケーリング特性
ESANの容量とIOPS・スループットは線形にスケールする。1 TiBのベース容量あたり5,000 IOPSと200 MB/sのスループットが確保される。50 TiBで25万IOPS、200 TiBで100万IOPSに達する。この数値はエンタープライズのNFS/SANシステムと比較しても十分な性能だ。
注意点として、追加の「容量専用TiB」（ベース容量を超えた部分）はIOPS・スループットを増やさない。性能を確保したい場合はベース容量を増やす設計にする必要がある。
v2.1.0の3つの新機能
1. Elastic SAN（ESAN）統合 数百〜数千のGiB規模の小さなPVを1つのSANに集約できる。個別にManaged Diskをプロビジョニングしていた場合と比べて、管理オーバーヘッドが大幅に下がる。さらにCSIドライバーのオープンソース化も計画中とのことで、将来的な自由度も期待できる。
2. モジュラーなオンデマンドインストール 使用するストレージタイプに必要なコンポーネントだけをデプロイする設計になった。インストール時間が短縮され、クラスターのフットプリントも最小化できる。「全部入り」を前提にしない設計は、本番クラスターの安定性という観点で正しいアプローチだ。
3. ノードセレクターサポート Azure Container Storageのコンポーネントを動かすノードプールを明示的に制御できるようになった。GPUノードやスポットノードにストレージコントローラーを混在させずに済む。リソース最適化の文脈で地味だが重要な改善だ。
どのワークロードが恩恵を受けるか
Microsoftが例示しているユースケースは主に2つ。
マルチテナントDBaaS・データベースプラットフォーム コンテナ化したPostgreSQLや各種DBをAKS上でマルチテナント運用するシナリオ。テナントごとにPVを割り当てると数が膨大になりやすく、これまではノード設計が難しかった。ESANの統合により、PVの高速プロビジョニングとバーストスケーリングに対応しやすくなる。
大規模な開発環境・ユーザー別ボリューム 開発者1人ひとりにPVを割り当てる開発プラットフォームのユースケース。例えば数千人規模の開発者環境をAKS上に構築する場合、従来のManaged Diskアーキテクチャでは接続数制限が先に詰まっていた。
実務への影響——日本の現場エンジニアが押さえるべきポイント
設計見直しのタイミング 現在AKS上でManaged DiskベースのPVを多数使っているワークロードがあるなら、ESANへの移行を検討するフェーズに入った。特に「PVの数が多くてノードのディスク上限に近づいている」「プロビジョニングに時間がかかる」という課題を抱えているチームは優先的に評価してほしい。
コスト計算はESAN専用ツールを使え 記事中でも言及されているESAN料金計算ツールを必ず使う。TiB単位の容量課金とManaged Diskのディスク単位課金は設計の前提が異なるため、単純に置き換えるとコストが想定外になる場合がある。
iSCSIのネットワーク設計 ESANはiSCSI over TCP/IPで通信するため、VNetの帯域とレイテンシが直接影響する。本番導入前にネットワークスループットのベンチマークを必ず取ること。
段階的な移行を モジュラーインストールの特性を活かして、まず開発・ステージング環境でESANを試し、ノードセレクターの設定と合わせて動作を確認してから本番へ展開するフローを強く推奨する。
筆者の見解
Kubernetesのストレージ問題は、クラウドネイティブへの移行を阻む「地味だが根深い」課題の1つだった。ステートフルなワークロードを「Kubernetesで動かしたい」と言いながら、ディスクアタッチの上限に引っかかって仮想マシンの台数を無駄に増やすか、アーキテクチャを妥協するか——そういうケースを何度も見てきた。
ESANの統合はこの問題への正面突破だ。iSCSIという枯れた技術を使いながら、Azureのマネージドサービスとして提供する構成はシンプルで筋がいい。「道のド真ん中を歩く」という観点でも、標準的なプロトコルで実装しているのは長期的な保守性に優れる。
これまでAKSのステートフルワークロードを「不安定だから」と避けていたチームには、改めて評価し直す機会が来たと思う。AzureのKubernetes基盤は着実に成熟してきており、このストレージの改善はその流れの中でも特に実用的な一手だ。
あとはオペレーションの複雑さをどこまで減らせるかが継続的な勝負になる。CSIドライバーのオープンソース化の計画もあるとのことで、エコシステムの広がりにも期待したい。
出典: この記事は Azure Container Storage v2.1.0: Now GA with Elastic SAN の内容をもとに、筆者の見解を加えて独自に執筆したものです。