# Azure Storage [[Microsoft]] Azure のクラウドストレージサービス。[[@2023__NSDI__Empowering Azure Storage with RDMA]] では、計算クラスタとストレージクラスタを分離したアーキテクチャとして説明される。ストレージはフロントエンド層、パーティション層、ストリーム層からなり、ストリーム層は append-only な分散ファイルシステムとしてデータを複製して格納する。 本論文時点の Azure Storage では、ストレージサーバ間のバックエンド通信に sU-RDMA、計算ホストとストレージクラスタ間のフロントエンド通信に sK-RDMA を導入し、TCP と RDMA の段階的切り替えも実装している。2023年2月時点で Azure パブリックリージョンのトラフィックの約70%が RDMA であり、リージョン内 RDMA は全 Azure パブリックリージョンでサポートされた。 [[@2026__SIGMOD Companion__Scalable and Resilient Storage Tier for Azure SQL Hyperscale]] では、Azure Storage は [[Azure SQL Hyperscale]] の Page Server が管理するページファイル(blob、社内呼称 XStore)の永続化層として位置づけられる。同論文は Azure Storage の性能特性として、Standard storage で 1 blob あたり概ね 500-1000 IOPS の帯域上限があり、これを超えると throttling が発生すると報告する。旧 Hyperscale 実装では 1 論理ファイル=1 blob(最大 1TB)という設計のため、この上限への抵触・大容量ファイルの障害時再シーディング(数時間規模)・頻繁なスナップショットによる metadata 重複やランダム IO 増加が課題となっていた。file anatomization(cell/stripe/slice への分割)により論理ファイルを複数 blob へストライピングすることで、per-blob の IOPS 上限への抵触を緩和する設計が示されている。 > [!contradiction] スケール軸の違い > [[@2023__NSDI__Empowering Azure Storage with RDMA]] は Azure Storage 自体のフロントエンド/バックエンド通信を RDMA で高速化する観点(ストレージサービス内部の実装)を扱うのに対し、[[@2026__SIGMOD Companion__Scalable and Resilient Storage Tier for Azure SQL Hyperscale]] は Azure Storage を「上限のある外部サービス」として扱い、その上限(500-1000 IOPS/blob)を前提にクライアント側(Page Server)でストライピング・非同期書き込み集約により回避する視点を取る。矛盾ではなく別レイヤの最適化だが、RDMA 導入後も per-blob IOPS 上限が Hyperscale 側の設計制約として残っている点は、RDMA 高速化の効果範囲(レイテンシ/帯域)と blob 単位の IOPS 上限が独立した制約であることを示唆する。 ## 関連 - ソース: [[@2023__NSDI__Empowering Azure Storage with RDMA]] / [[@2026__SIGMOD Companion__Scalable and Resilient Storage Tier for Azure SQL Hyperscale]] - 組織: [[Microsoft]] - 概念: [[分散ストレージ]] / [[RDMA]] / [[RDMAネットワーク監視]] / [[コンピュートストレージ分離]] / [[ライトビハインドキャッシング]] - 関連エンティティ: [[RDMA Estats]] / [[SONiC]] / [[Azure SQL Hyperscale]]