# コンピュートストレージ分離 ## 定義 コンピュートストレージ分離（Compute-Storage Disaggregation）とは、データベースシステムにおいてクエリ処理・トランザクション管理・バッファキャッシュ等のコンピュート機能と、ログ記録・永続化ストレージ・クラッシュリカバリ等のストレージ機能を独立したスケール可能なサービスに切り出すアーキテクチャパターンである。クラウド環境では、コンピュート層とストレージ層を分離することで、各層を独立してスケーリングし、障害の局所化と運用の効率化を実現できる。(Source: [[@2017__SIGMOD__Amazon Aurora - Design Considerations for High Throughput Cloud-Native Relational Databases]]) 分離の粒度はシステムによって異なる。Deuteronomy はトランザクションコンポーネントとデータコンポーネントを分離する（アクセスメソッド・ログ・リカバリを含む DC が一体）。Aurora はそれより下位のレイヤ（ログ・ストレージ・リカバリ）を独立サービスに切り出し、クエリ処理・トランザクション・バッファキャッシュ・アクセスメソッドはコンピュート層に残す。(Source: [[@2017__SIGMOD__Amazon Aurora - Design Considerations for High Throughput Cloud-Native Relational Databases]]) ## 横断的知見 - **分離レイヤの粒度が設計トレードオフの中心**: Deuteronomy・Hyder・Sinfonia・Yesquel と Aurora では分離の境界が異なり、何をどちらの層に置くかがスループット・一貫性・移行容易性のトレードオフを決定する。Aurora はログ+ストレージ+リカバリのみを分離し、MySQL 互換性を維持した。Aurora Limitless ではさらにルータ/シャード構成を加えることで水平スケールアウトに対応した（ただし互換性コストが増加）。(Source: [[@2017__SIGMOD__Amazon Aurora - Design Considerations for High Throughput Cloud-Native Relational Databases]], [[@2026__SIGMOD Companion__Aurora PostgreSQL Limitless Database - Building a Highly Scalable OLTP Database]]) - **コンピュートストレージ分離によりストレージ層のスケールアウトが独立可能になるが、新たなネットワークボトルネックを生む**: Aurora の経験では、I/O を複数ノードに分散すると個別ディスクのホットスポットは解消されるが、データベース層 ↔ ストレージ層のネットワークが新たなボトルネックになった。「ログがデータベース」設計はこの問題に対し、ネットワーク越しに送るデータ量そのものを削減（ページではなくログのみ）することで応答した。(Source: [[@2017__SIGMOD__Amazon Aurora - Design Considerations for High Throughput Cloud-Native Relational Databases]]) - **分離により MTTR と運用柔軟性が改善する**: ストレージが独立サービスになることで、OS パッチ・ソフトウェアアップグレードが PG（Protection Group）単位でローリング実施可能になり、ダウンタイムなしで運用できる。Aurora ではセグメント単位（10GB）の修復が 10 秒で完了する。これは「可用性イベントを長期の性能変動」として均一に扱うという設計哲学から来る。(Source: [[@2017__SIGMOD__Amazon Aurora - Design Considerations for High Throughput Cloud-Native Relational Databases]]) - **NVMe-oF がコンピュートストレージ分離のレイテンシ障壁を大幅に低下させた**: [[VAST Data]] の [[DASEアーキテクチャ]] (2016–) は NVMe over Fabrics を前提とし、分離されたストレージへのアクセスをマイクロ秒オーダーに保つことで「ノード DRAM 書き込みキャッシュ不要」という Aurora とは逆の設計選択をとる。Aurora が「ネットワーク越しのページ転送を減らすために Log is Database」を採用したのに対し、DASE は「NVMe-oF の低レイテンシで直接ランダムアクセスする」という別の解法をとった。どちらも「ネットワークがボトルネック」という同一課題への対処だが、採用したインターコネクト技術が解法を分岐させる。(Source: [[@2025__VAST Data__VAST AI Operating System]] pp.19–21) - **ストレージ統合の範囲がデータ一貫性保証の範囲を決定する**: Aurora は RDBMS の log/storage のみを分離し、クエリ層・トランザクション層はコンピュート側に残すことで既存 MySQL との互換性を維持した。一方 VAST DASE は Object Store・Database・Event Broker・ベクトルデータベースすべてを同一 CNode プール上で動かすことで、RAG パイプラインの権限同期・埋め込みライフサイクル・監査ログが構造的に一貫性を保つ設計になる。統合の深さが「cross-component の整合性コスト」の排除度を決定する。(Source: [[@2025__VAST Data__VAST AI Operating System]] pp.129–130) ## 未解決の問い - コンピュートストレージ分離のボトルネックがネットワークである場合、RDMA などの高速インターコネクトを利用するとどの程度改善されるか？（[[@2023__NSDI__Empowering Azure Storage with RDMA]] との比較が興味深い） - 分離されたストレージ層に Redo ログ処理を移した場合、ストレージ層の CPU コストはどの程度増加し、どのようにスケールするか？Aurora の論文では各ストレージノードの処理コストの詳細は示されていない。 - 「専用再設計（H-Store 系）」vs「互換性維持の分離（Aurora）」の対比において、ワークロードの種類（OLTP/HTAP/分析）でどちらが優れるか？ - VAST DASE のように「全コンピュートノードが全ストレージデバイスに直接アクセス」する Shared-Everything 設計では、クラスター規模拡大時に NVMe Fabric の帯域とメタデータロック競合がどのようにスケールするか？ベンダー以外の第三者ベンチマークは存在するか？ ## 関連 - [[OLTPシステムアーキテクチャ]] — 分離が適用される基本アーキテクチャの文脈 - [[分散ストレージ]] — 分離されたストレージ層の設計 - [[クォーラムベースレプリケーション]] — Aurora のストレージ層で採用されるレプリケーション手法 - [[Amazon Aurora (Database)]] — コンピュートストレージ分離の実装例 - 関連 MOC: [[structures/分散深層学習 - MOC]] からは参照なし（別ドメイン） ## 出典 - [[@2017__SIGMOD__Amazon Aurora - Design Considerations for High Throughput Cloud-Native Relational Databases]]（Aurora の分離設計・ネットワークボトルネック・"The Log is the Database" アプローチ） - [[@2026__SIGMOD Companion__Aurora PostgreSQL Limitless Database - Building a Highly Scalable OLTP Database]]（分離の上に水平スケールアウトを追加した後継設計） - [[@2025__VAST Data__VAST AI Operating System]]（NVMe-oF を前提とした DASE: ステートレス CNode + Shared-Everything ストレージ）