# ストレージ計算分離 ## 定義 ストレージ計算分離(Storage-Compute Disaggregation)とは、データベースシステムにおいて、クエリ処理・トランザクション実行などの「計算」と、データの永続化・複製・耐久性確保などの「ストレージ」の責務を独立したコンポーネントに分解するアーキテクチャパターンである。 分離により計算とストレージのコストを独立してスケールさせることができる。大量の計算が必要でストレージ量は少ないワークロードや、逆にストレージ容量は大きいが計算需要は低いワークロードに対して、それぞれ最適なリソース配分が可能になる。 代表的な実装: - **Amazon Aurora**: Redo ログレコードのみをストレージ層に送信し、ストレージサービスが非同期にページを実体化する。「ログがデータベース」の設計 - **Amazon MemoryDB**: インメモリ実行エンジン(Redis)の複製ストリームをマルチ AZ トランザクションログに分離し、ノードの DRAM は実行のみに専念させる - **PolarDB**: RDMA でストレージノードと計算ノードを接続。共有ストレージにより複数の読み取りノードが最新データを参照できる - **Sinfonia・Hyder**: スケールアウトサービス上のトランザクションアクセス抽象化 (Source: [[@2024__SIGMOD__Amazon MemoryDB - A Fast and Durable Memory-First Cloud Database]]) ## 横断的知見 - **インメモリエンジンへの分離適用は「侵襲度を最小化した統合」が鍵**: Aurora はディスクベースエンジンのストレージ I/O パスを置き換える侵襲的変更を加えたのに対し、[[Amazon MemoryDB]] は Redis の複製ストリームをインターセプトするだけで Redis コアを変更しない。これにより OSS Redis との完全 API 互換性と継続的なバージョン追従が可能になった。侵襲度と互換性のトレードオフが設計の核心となる。(Source: [[@2024__SIGMOD__Amazon MemoryDB - A Fast and Durable Memory-First Cloud Database]]) - **耐久性と DRAM コストを分離することでコスト最適化が可能**: MemoryDB では耐久性はトランザクションログが保証するため、ノードの DRAM は稼働中の作業集合(working set)のサイズだけに合わせれば良い。Aurora も同様に、ページバッファプールのサイズをデータセット全体のサイズと分離できる。(Source: [[@2024__SIGMOD__Amazon MemoryDB - A Fast and Durable Memory-First Cloud Database]]) ## 未解決の問い - ストレージ計算分離を採用する場合、ネットワーク遅延が書き込みレイテンシのボトルネックになる。RDMA(PolarDB)・専用 AWS 内部サービス(Aurora・MemoryDB)・Ethernet(一般的)でどの程度のレイテンシ差が生じるか？ - MemoryDB はマルチ AZ トランザクションログへの同期書き込みにより書き込みレイテンシが OSS Redis より高くなる。このレイテンシコストを許容できるユースケースの境界はどこか？ - Redis のシングルスレッド処理モデルとストレージ計算分離の組み合わせでは、CPU スケーリング上限がネックになる。マルチスレッド対応エンジンへの移行余地は？ ## 関連 - [[インメモリデータベース]] — 分離アーキテクチャが特に重要なインメモリエンジンの文脈 - [[Write-Ahead Logging (WAL)]] — Aurora の「ログのみ送信」とストレージ層でのページ実体化との関係 - [[分散 PostgreSQL]] — Aurora Limitless の分散 OLTP における分離アーキテクチャ - [[Amazon Aurora (Database)]] — ストレージ計算分離の先行事例 - [[Amazon MemoryDB]] — Redis インメモリエンジンへの分離適用事例 ## 出典 - [[@2024__SIGMOD__Amazon MemoryDB - A Fast and Durable Memory-First Cloud Database]](MemoryDB のストレージ計算分離設計・Aurora との比較)