# コンピュートストレージ分離 ## 定義 コンピュートストレージ分離（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 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]]) ## 未解決の問い - コンピュートストレージ分離のボトルネックがネットワークである場合、RDMA などの高速インターコネクトを利用するとどの程度改善されるか？（[[@2023__NSDI__Empowering Azure Storage with RDMA]] との比較が興味深い） - 分離されたストレージ層に Redo ログ処理を移した場合、ストレージ層の CPU コストはどの程度増加し、どのようにスケールするか？Aurora の論文では各ストレージノードの処理コストの詳細は示されていない。 - 「専用再設計（H-Store 系）」vs「互換性維持の分離（Aurora）」の対比において、ワークロードの種類（OLTP/HTAP/分析）でどちらが優れるか？ ## 関連 - [[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]]（分離の上に水平スケールアウトを追加した後継設計）