メインコンテンツまでスキップ

PolarDB のストレージ・コンピュート分離

· 約9分
tanzhuo

ビジネス規模の拡大に伴い、従来のリレーショナルデータベースアーキテクチャは、拡張能力の不足、高いストレージコスト、読み書き負荷の集中といったボトルネックを露呈するようになりました。クラウドベンダーはこれに対して新しいアーキテクチャパターンを設計しました。それが ストレージ・コンピュート分離（Storage-Compute Decoupling） です。本記事ではアーキテクチャの観点から PolarDB のストレージ・コンピュート分離設計を分析し、AWS Aurora および従来型 MySQL アーキテクチャと比較します。

背景​

PolarDB は Alibaba Cloud が提供するクラウドネイティブデータベースで、その中核となる設計思想の一つが 計算層とストレージ層のデカップリング です。このアーキテクチャにより、データベースはより強い弾力的な拡張能力と、より高いリソース利用効率を備えます。

従来型 MySQL アーキテクチャの問題​

従来の MySQL アーキテクチャでは、データベースは通常 1 台のサーバー上で動作し、計算とストレージが同じマシンに同居します：

MySQL Server
 ├── CPU
 ├── Memory
 └── Local Disk      # データと計算が同じマシンに束縛される

このアーキテクチャは初期のインターネット時代には十分でしたが、ビジネス規模が拡大するにつれ、いくつかの明白な問題が現れます。

1) ストレージの拡張が難しい​

データベースのデータは通常ローカルディスクに保存されるため、データ量が増えた場合、ディスクのアップグレードやより大きなマシンへの交換しかできず、拡張能力に限界があります。

2) 読み取りスケールのコストが高い​

MySQL でよく使われる拡張方式は マスター・スレーブレプリケーション です：

Master
 ├── Slave1      # 各スレーブが完全なデータコピーを保持する
 ├── Slave2
 └── Slave3

各リードオンリーノードは完全なデータコピーを必要とします。リードノードが増えるほどストレージコストは急速に増大し、データ同期の負荷も増していきます。

3) 高可用性の実現が複雑​

マスターノードに障害が発生した場合、手動または自動でマスター・スレーブの切り替えを行う必要があり、その間にレプリケーション遅延が発生する可能性があるほか、データ整合性の担保にも追加の対応が必要です。

PolarDB のストレージ・コンピュート分離アーキテクチャ​

PolarDB の中核設計は、計算ノードとストレージノードの完全なデカップリング です。アーキテクチャの概略は次のとおりです：

          +--------------------+
          |    Compute Node    |
          | (MySQL / PG / ORA) |   # 計算層：SQL 解析、実行、トランザクション
          +---------+----------+
                    |
          +---------+----------+
          | Distributed Storage|   # ストレージ層：データ、ログ、レプリカ
          |     (PolarStore)   |
          +--------------------+

計算ノードは SQL 解析、クエリ実行、トランザクション処理を担当し、ストレージ層はデータ保存、ログ管理、レプリカ複製を担当します。すべての計算ノードが同一の分散ストレージを共有するこのアーキテクチャは、Shared Storage Architecture と呼ばれます。

ストレージ・コンピュート分離は何を解決したのか​

この設計は主に、従来のデータベースが抱えるいくつかの核心的な問題を解決します。

1) 弾力的な拡張能力​

従来のデータベースでは計算能力を増やすにはサーバーのアップグレードが必要でしたが、PolarDB では計算ノードを直接追加できます：

Storage Layer
   ↑
   │
Compute1      # 計算ノードの追加にデータコピーは不要
Compute2
Compute3

すべてのノードが同一のデータを共有するため、読み取りスケール、分散計算、秒単位のスケールアウトが実現できます。

2) ストレージコストの削減​

従来の MySQL のリードノードには完全なデータコピーが必要ですが、ストレージ・コンピュート分離アーキテクチャでは複数の計算ノードが同じストレージシステムを共有するため、完全なデータの複製が不要になり、ストレージコストが大幅に下がります。

3) より強い高可用性​

PolarDB のストレージ層は通常、分散レプリカ機構を使用します：

Storage Node
 ├── Replica1      # 複数レプリカでデータの永続性を保証
 ├── Replica2
 └── Replica3

あるノードに障害が発生しても、システムは非常に高速に復旧できます。この設計により、自動障害復旧、高可用アーキテクチャ、データ永続性の保証が実現できます。

4) 極めて高い性能​

PolarDB のストレージ層は通常、分散ログ構造、並列 I/O、SSD クラウドストレージを採用しており、データベース性能を大幅に向上させられます。主なボトルネックはストレージ層から内部ネットワークの I/O 層へと移りました。

PolarDB の弱点​

ストレージ・コンピュート分離アーキテクチャには多くの利点がある一方で、いくつかの課題も存在します。

1) ネットワーク遅延​

計算層とストレージ層が分離されているということは、データアクセスがネットワーク経由になるということであり、ローカルディスクと比べて一定の遅延が加わります。

2) アーキテクチャの複雑さ​

ストレージ・コンピュート分離アーキテクチャでは、分散ストレージシステム、ネットワークプロトコル、データ整合性機構の設計が必要となり、実装の難易度は従来のデータベースよりはるかに高くなります。

3) クラウドインフラへの強い依存​

このアーキテクチャは高性能ネットワーク、分散ストレージ、クラウドプラットフォームのスケジューリング能力に大きく依存するため、通常はクラウド環境でのみ適用可能です。

PolarDB vs AWS Aurora​

PolarDB と Aurora の全体的な設計思想は非常に近く、どちらも典型的な クラウドネイティブデータベースアーキテクチャ であり、ストレージ・コンピュート分離（Compute + Storage Decoupling） の設計を採用しています。

Aurora は計算ノードと分散ストレージクラスタを分離し、複数の計算ノードが同一のストレージシステムを共有します。アーキテクチャの概略：

          Writer Node
               |
       +-------+-------+
       |               |
   Reader1         Reader2         # リードノードは下層ストレージを共有
       |               |
   +-----------------------+
   |   Distributed Storage |
   +-----------------------+

Aurora の分散ストレージは通常、可用性向上のため複数のアベイラビリティゾーンをまたいでデプロイされます。しかし具体的な実装においては、両者には依然としていくつかの重要な違いがあります。

1) ストレージアーキテクチャ設計の違い​

Aurora の中核設計は ログ駆動ストレージ（Log Structured Storage） です。Aurora では計算ノードがデータベースページを直接書き込むのではなく、redo log をストレージノードに送信し、ストレージ層がそれらのログに基づいてデータページを再構築します。簡略化したフローは次のとおりです：

Client
↓
Aurora Compute Node
↓
Redo Log                    # ログのみを転送し、完全なデータページは転送しない
↓
Distributed Storage Nodes
↓
Storage Node がデータページを再構築

Aurora のストレージ層は通常 6 つのレプリカで構成 され、3 つのアベイラビリティゾーン（AZ） に分散されます：

AZ1 : Storage Node A / Storage Node B
AZ2 : Storage Node C / Storage Node D
AZ3 : Storage Node E / Storage Node F

書き込み時には 4/6 quorum を満たせばトランザクションをコミットできます。この設計にはいくつかの利点があります：

  • 書き込みはログの送信だけで済み、ネットワーク転送量が小さい
  • データベースページの完全な複製が不要
  • 障害復旧の速度が速い

一方、PolarDB のストレージ実装は少し異なります。PolarDB は 共有分散ストレージ（Shared Storage） アーキテクチャを採用し、計算ノードは下層の PolarStore / PolarFS 分散ファイルシステム に直接アクセスでき、データベースページは引き続きページの形で保存されます。簡略化した構造は次のとおりです：

Client
↓
Compute Node (MySQL / PG / Oracle)
↓
PolarFS / PolarStore        # 分散ファイルシステム、ページ形式のストレージ
↓
Distributed Storage Nodes

この設計は従来のデータベースのストレージ方式に近いため、データページ構造の互換性が保たれ、データベースカーネルへの改修が比較的少なくて済みます。ただし書き込みパスにおいては、ネットワーク転送のデータ量が Aurora のログ方式より大きくなる可能性があります。

2) リードノードのアーキテクチャ​

Aurora のリードノードは主に Reader Instance で、通常は読み取りのみを担当し、書き込みは Writer Node に集中します。一方 PolarDB は Reader Node + マスターノードによる共有ストレージ のモードをサポートし、複数のノードが共有ストレージに直接アクセスできるため、より柔軟な読み取りスケールが実現できます。

3) エコシステムと互換性の戦略​

Aurora は AWS が深く改造したデータベースエンジンで、MySQL / PostgreSQL と互換性はあるものの、下層の実装は大きく変わっています。PolarDB はより ネイティブなデータベース互換性 を重視しています：

  • PolarDB MySQL
  • PolarDB PostgreSQL
  • PolarDB Oracle

そのため多くのアプリケーションは、PolarDB への移行時の修正コストがより低く抑えられます。

まとめ​

ストレージ・コンピュート分離の本質は、データベースの計算能力とストレージ能力を、独立して拡張できる 2 つの層に切り分けることです。PolarDB は共有分散ストレージによって、秒単位のスケールアウト、低コストの読み取りスケール、より強い高可用性を手に入れました。その代償がネットワーク遅延とアーキテクチャの複雑さの増大です。Aurora と比べると両者の思想は近いものの、PolarDB は共有ファイルシステム路線を採り、従来のデータベースのストレージ形態に近く互換性に優れています。一方 Aurora はログ駆動ストレージによって、書き込み時の転送量の小ささを手に入れました。この 2 つの路線のトレードオフを理解しておくことは、クラウドデータベースの選定評価に大いに役立ちます。

COMMENTS