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

Transcript

1. 0 Amazon AuroraとMongoDBの アーキテクチャを⽐較してみたら 結構違った件について 2025-04-04 第118回NearMe技術勉強会 @yujiosaka
2. 1 データベース⽐較 • Amazon Aurora ‒ クラウドネイティブなリレーショナルデータベース • MongoDB ‒ オープンソースのドキュメント指向NoSQLデータベース
3. 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.find() [ { _id: ObjectId("66a9d3c73dbe30f7509034fd"), createdAt: ISODate("2024-07-31T06:03:51.762Z") }, { _id: ObjectId("66a9d3c93dbe30f7509034fe"), createdAt: ISODate("2024-07-31T06:03:53.490Z") } ]
4. 3 機能⽐較 • インデックスの機能はほぼ同等 • MongoDBにもJoin、View、トランザクションのようなRDBMSライクな機能がある
5. 4 構成⽐較 App Write Replica Read Replica Read Replica Read Read Write
6. 5 構成の共通点 • 分散環境で⾼可⽤性と⾼性能を実現 • ⼀つのWriterレプリカと複数のReaderレプリカを持つ
7. 6 古典的なデータベースのアーキテクチャ • ⼀台のサーバーに計算とストレージが同居している • ⼀台のサーバーが停⽌すると使⽤できなくなる • ⼀台のサーバーからデータが失われると復旧できなくなる App DB Read & Write
8. 7 MongoDBのアーキテクチャ App Primary Replica Secondary Replica Secondary Replica ①データをストレージと  Oplogに書き込む ②Oplogからデータを  コピーする ②Oplogからデータを  コピーする ③データをストレージから  読み込む ③データをストレージから  読み込む
9. 8 Read Replica Read Replica MongoDBのPrimaryレプリカが停⽌した場合 App Primary Replica Secondary Replica Primary Replica Read Write ①投票 ②選出
10. 9 Replica∕Arbiter数 必要な票数 最⼤失敗数 1 1 0 2 2 0 3 2 1 4 3 1 5 3 2 6 4 2 7 4 3 必要な票数
11. 10 MongoDBのアーキテクチャのメリット • ローカルでも動作する • スタンドアロンの構成は古典的なデータベースと同じ • Secondaryへのデータコピーが⾮同期なので書き込みが爆速 • Primaryが停⽌しても、ほぼ遅延なくSecondaryが選出される
12. 11 MongoDBのアーキテクチャのデメリット • Secondaryから読み込まれるデータが最新ではない可能性がある • 最新のデータを保証しなければならない場合はPrimaryから読み込む • Primaryが復旧できなくなると、Secondaryにコピーされる前のデータは失われる
13. 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
14. 13 MongoDBのシャーディング • データを複数のシャードに分散させることで、書き込みを⾼速化させる • mongocが振り分けのルールを保存し、mongosがルーティングを⾏う • それぞれのシャードは、⾃分たちがシャードされていることを知らない（例外あり） • シャード間でデータ量のバランスが悪くなったら、⾃動∕⼿動でリバランシングする
15. 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
16. 15 コピーへの書き込み AZ1 AZ2 Storage 1 Storage 2 Storage 3 Storage 4 Storage 5 Storage 6 AZ3 Write Replica 4以上のコピーへの書き込みで成功
17. 16 コピーへからの読み込み AZ1 AZ2 Storage 1 Storage 2 Storage 3 Storage 4 Storage 5 Storage 6 AZ3 Read Replica 3以上のコピーからの読み込みで成功
18. 17 コピー数 書き込みコピー数 読み込みコピー数 1 1 1 2 2 1 3 2 2 4 3 2 5 3 3 6 4 3 7 4 4 必要なコピー（クォーラム）数
19. 18 Amazon Auroraのアーキテクチャのメリット • Readから読み込まれるデータも最新であることが保障されている • Writeが復旧できなくなってもデータが失われない
20. 19 Amazon Auroraのアーキテクチャのデメリット • 書き込みはスケールしない • Primaryが停⽌すると、60-120秒間使⽤できなくなる • ローカルでは動作しない（MySQLとPostgreSQLと互換性があるため実質問題ない）
21. 20 Amazon Auroraのシャーディング • 不可 • DocumentDB（MongoDBのAPIとの互換性を謳ったサービス）でも不可
22. 21 まとめ • Amazon Aurora ‒ 書き込み性能がスケールしない代わりに、データの完全性を担保 • MongoDB ‒ 多少のデータが失われることを許容することで書き込み性能に特化
23. 22 結局使い分けが⼤事 22
24. 23 Thank you