Amazon AuroraとMongoDBのアーキテクチャを比較してみたら結構違った件について

Slide 1

Slide 1 text

0 Amazon AuroraとMongoDBのアーキテクチャを⽐較してみたら結構違った件について 2025-04-04 第118回NearMe技術勉強会 @yujiosaka

Slide 2

Slide 2 text

1 データベース⽐較 • Amazon Aurora ‒ クラウドネイティブなリレーショナルデータベース • MongoDB ‒ オープンソースのドキュメント指向NoSQLデータベース

Slide 3

Slide 3 text

2 データ構造⽐較 mysql> select id, created_at from users; +---+---------------------------+ | id | created_at | +---+---------------------------+ | 1 | 2024-06-15 10:06:27 | | 2 | 2024-06-15 11:11:14 | +---+---------------------------+ test> db.users.ﬁnd() [ { _id: ObjectId("66a9d3c73dbe30f7509034fd"), createdAt: ISODate("2024-07-31T06:03:51.762Z") }, { _id: ObjectId("66a9d3c93dbe30f7509034fe"), createdAt: ISODate("2024-07-31T06:03:53.490Z") } ]

Slide 4

Slide 4 text

3 機能⽐較 • インデックスの機能はほぼ同等 • MongoDBにもJoin、View、トランザクションのようなRDBMSライクな機能がある

Slide 5

Slide 5 text

4 構成⽐較 App Write Replica Read Replica Read Replica Read Read Write

Slide 6

Slide 6 text

5 構成の共通点 • 分散環境で⾼可⽤性と⾼性能を実現 • ⼀つのWriterレプリカと複数のReaderレプリカを持つ

Slide 7

Slide 7 text

6 古典的なデータベースのアーキテクチャ • ⼀台のサーバーに計算とストレージが同居している • ⼀台のサーバーが停⽌すると使⽤できなくなる • ⼀台のサーバーからデータが失われると復旧できなくなる App DB Read & Write

Slide 8

Slide 8 text

7 MongoDBのアーキテクチャ App Primary Replica Secondary Replica Secondary Replica ①データをストレージと Oplogに書き込む ②Oplogからデータをコピーする ②Oplogからデータをコピーする ③データをストレージから読み込む ③データをストレージから読み込む

Slide 9

Slide 9 text

8 Read Replica Read Replica MongoDBのPrimaryレプリカが停⽌した場合 App Primary Replica Secondary Replica Primary Replica Read Write ①投票 ②選出

Slide 10

Slide 10 text

9 Replica∕Arbiter数必要な票数最⼤失敗数 1 1 0 2 2 0 3 2 1 4 3 1 5 3 2 6 4 2 7 4 3 必要な票数

Slide 11

Slide 11 text

10 MongoDBのアーキテクチャのメリット • ローカルでも動作する • スタンドアロンの構成は古典的なデータベースと同じ • Secondaryへのデータコピーが⾮同期なので書き込みが爆速 • Primaryが停⽌しても、ほぼ遅延なくSecondaryが選出される

Slide 12

Slide 12 text

11 MongoDBのアーキテクチャのデメリット • Secondaryから読み込まれるデータが最新ではない可能性がある • 最新のデータを保証しなければならない場合はPrimaryから読み込む • Primaryが復旧できなくなると、Secondaryにコピーされる前のデータは失われる

Slide 13

Slide 13 text

12 MongoDBのシャーディング mongos Shard 1 Shard 1 Shard 3 Primary Replica Primary Replica Primary Replica Second Replica Second Replica Second Replica Second Replica Second Replica Second Replica App mongoc

Slide 14

Slide 14 text

13 MongoDBのシャーディング • データを複数のシャードに分散させることで、書き込みを⾼速化させる • mongocが振り分けのルールを保存し、mongosがルーティングを⾏う • それぞれのシャードは、⾃分たちがシャードされていることを知らない（例外あり） • シャード間でデータ量のバランスが悪くなったら、⾃動∕⼿動でリバランシングする

Slide 15

Slide 15 text

14 Amazon Auroraの構成 App Write Replica Read Replica Read Replica AZ1 AZ2 AZ3 Storage 1 Storage 2 Storage 3 Storage 4 Storage 5 Storage 6 Write Read Read

Slide 16

Slide 16 text

15 コピーへの書き込み AZ1 AZ2 Storage 1 Storage 2 Storage 3 Storage 4 Storage 5 Storage 6 AZ3 Write Replica 4以上のコピーへの書き込みで成功

Slide 17

Slide 17 text

16 コピーへからの読み込み AZ1 AZ2 Storage 1 Storage 2 Storage 3 Storage 4 Storage 5 Storage 6 AZ3 Read Replica 3以上のコピーからの読み込みで成功

Slide 18

Slide 18 text

17 コピー数書き込みコピー数読み込みコピー数 1 1 1 2 2 1 3 2 2 4 3 2 5 3 3 6 4 3 7 4 4 必要なコピー（クォーラム）数

Slide 19

Slide 19 text

18 Amazon Auroraのアーキテクチャのメリット • Readから読み込まれるデータも最新であることが保障されている • Writeが復旧できなくなってもデータが失われない

Slide 20

Slide 20 text

19 Amazon Auroraのアーキテクチャのデメリット • 書き込みはスケールしない • Primaryが停⽌すると、60-120秒間使⽤できなくなる • ローカルでは動作しない（MySQLとPostgreSQLと互換性があるため実質問題ない）

Slide 21

Slide 21 text

20 Amazon Auroraのシャーディング • 不可 • DocumentDB（MongoDBのAPIとの互換性を謳ったサービス）でも不可

Slide 22

Slide 22 text

21 まとめ • Amazon Aurora ‒ 書き込み性能がスケールしない代わりに、データの完全性を担保 • MongoDB ‒ 多少のデータが失われることを許容することで書き込み性能に特化