背景・目的
- データベースごとの可用性について整理する。
前提
- 一部埋められていない(調べられていない)箇所がある。後ほど更新する。
内容
一覧
- ここで説明する可用性は、システムが停止することなくサービスを提供し続けることを指す。
- 可用性を高めるための考え方として、以下を整理する。
- AWSインフラの機能として、マルチAZ、マルチリージョン
- データベースサービス機能として、プライマリ、セカンダリインスタンス
- なお、仕組みが異なるものは、同一データベースサービス内でもエンジン別に切り出して整理している。
- ここでいうレプリカは、スタンバイレプリカを指しており リードレプリカとは異なる。(Auroraだけは異なる。)
- 以下に整理した内容を記載する。
| データベース | 配置可能なロケーション | コンピュートとストレージの分離 | データベース機能 | 備考 | |||
|---|---|---|---|---|---|---|---|
| マルチAZ | マルチリージョン | マルチマスタ | レプリカ | Fail Over(F/O) （※2） |
|||
| RDS(Aurora) | ◯ | ◯ (※3) |
◯ (※1) |
◯ (※4) |
リードレプリカ、スタンバイレプリカ兼用（※10） （最大15ノード） |
◯ 120秒未満（多くは60秒）でF/O（※11） |
|
| RDS（MySQL、MariaDB、PostgreSQL、Oracle） | ◯ | ✕ | ✕ | ✕ | スタンバイレプリカ | ◯ 60秒〜120秒でF/O F/OはAWS独自の仕組みを利用。 |
|
| RDS（SQL Server） | ◯ | ✕ | ✕ | ✕ | ◯ | スタンバイレプリカ (※5) 60秒〜120秒でF/O |
|
| DynamoDB | ◯ | ◯ | ？ おそらくされている。 |
◯ (※6) |
◯ （※7） |
？ ドキュメント見つけられず |
|
| DocumentDB | ◯ | ✕ | ◯ | ✕ | リードレプリカ （最大15ノード） |
◯ リードレプリカがプライマリに昇格 |
|
| ElastiCache for Memcached | ◯ | ✕ | ✕ (※8) |
◯ | リードレプリカ （最大20ノード） |
✕ | |
| ElastiCache for Redis | ◯ | ◯ (※9 最大2つのリード専用クラスタ) |
◯ | ✕ | リードレプリカ （最大5ノード） |
◯ リードレプリカがプライマリに昇格 |
|
| Neptune | ◯ | ✕ | ◯ | ✕ | リードレプリカ （最大15ノード） |
◯ リードレプリカがプライマリに昇格 |
|
| Timestream | ◯ | ✕ | ◯（※12） | ✕ | ? | ? | |
| QLDB | ◯ | ✕ | ? | ✕ | ? | ◯ | |
- ※1.書き込みにはクォーラムモデルを採用している。
- ※2. F/O時の挙動
- レプリカには優先度が設定可能
- 設定しない場合は、インスタンスタイプが大きいレプリカが優先。
- ※3. Auroraグローバルデータベースにより、マルチリージョンに渡るグローバルデータベースが構築可能。1つのプライマリAWSリージョンと最大5つのセカンダリAWSリージョン。書き込みはプライマリのみ。リージョン間コピーは通常1秒未満。
- 類似した機能でクロスリージョンレプリケーションもある。
- 他のリージョンにAuroraクラスタを作成し、そのクラスタをRO専用クラスタとして利用する。
- リージョン間コピーに時間がかかるので、グローバルデータベースを利用したほうが良いらしい。
- 類似した機能でクロスリージョンレプリケーションもある。
- ※4. Auroraマルチマスタを構成する場合、マルチリージョンは利用できない。また、使用できるリージョンやデータベースエンジンおよびバージョンに制限がある、インスタンスは最大2つなど使用するには注意が必要。
- F/Oの概念がない。
- MySQLのみサポート
- インスタンスの停止は不可
- 書き込みパフォーマンスは落ちる場合あり
- バックトラックは利用不可
- ※5. ServerのDBM、またはAGsが使われる。
- ※6. DynamoDBグローバルテーブル。マルチリージョン、マルチマスタを展開する。
- ※7. DynamoDBグローバルテーブルで、レプリカとしてリージョンを指定する。
- ※8. そもそも永続化できない。
- ※9. グローバルデータストアと呼ばれる。
- ※10.レプリカは、リードレプリカとスタンバイレプリカを兼ねており、障害発生時にはプライマリに昇格してF/Oする。
- クラスターエンドポイントにアプリケーションは接続することで、切り替え作業は不要にある。
-
※11.Aurora for PostgreSQLにはクラスターキャッシュ管理機能がある。
- プライマリインスタンスで使用していたキャッシュをレプリカに同期することで、F/O時のパフォーマンス影響を最低限に抑える狙いがある。
※12 Architectureに記載されているように、Ingestion layerとStorage layaerということで分離されている。さらに、ストレージは、メモリとマグネティックの2つレイヤに分かれている
クォーラムモデル
- AWSデータベースで採用されているクォーラムモデルは以下の仕様（6コピー）で統一されているようだ。
- ストレージは、クラスターボリュームという機構で管理されている。
- ３つのAZに2つずつ、合計6つのコピーが行われるクォラームシステムを導入している。（確か、ZooKeeperやCassandraなどでも採用していた。）
- 6つのうち、同時に2つの障害が発生した場合（AZ１つがダウンなど）でも、書き込み、読み込み可能。
- 6つのうち、同時に３つの障害が発生した場合でも、読み込み可能
- クォーラムモデルとは別に、10GBのブロック単位にコピーが行われ、ディスク障害時には自己修復機能により自動的に修復される。
考察
- Auroraは、クォーラムモデルを採用している。
- リードレプリカの上限数は、最大15が多い。DBによって異なるのはエンジンの制約か、それとも方針の違いか。
- まだ、早くや理解できてないところ（特にDynamoDB、QLDB、Timstream）もあるので、後ほど更新する。