マイクロサービスにおける容易なトランザクション管理に向けて

Database Engineering Meetup (DBEM) #5 「KubeDay Japan Revisited」における発表スライドです。

Database Engineering Meetup (DBEM) #5 :
https://scalar.connpass.com/event/338134/

Transcript

1. Towards Effortless Transaction Management in Microservices マイクロサービスにおける容易なトランザクション管理に向けて Database Engineering Meetup (DBEM) #5 2024年12月17日 Hiroyuki Yamada (Scalar, Inc.)
2. © 2024 Scalar, inc. マイクロサービス / マイクロサービスアーキテクチャ 2 A microservice architecture is an architectural pattern that arranges an application as a collection of loosely coupled, fine-grained services, communicating through lightweight protocols. One of its goals is to enable teams to develop and deploy their services independently. Wikipedia DB1 DB2 DB3 App1 App2 App3 Microservice1 Microservice2 Microservice3 Application アプリケーションを、疎に結合された複数の小さいサービスの集合体として構成するアーキテクチャ
3. © 2024 Scalar, inc. マイクロサービスの利点 3 Reference: Data Management in Microservices: State of the Practice, Challenges, and Research Directions @VLDB’21
4. © 2024 Scalar, inc. マイクロサービスの欠点 • データベース間のトランザクション一貫性が保証できない • 複数データベースの扱いが困難 (e.g., 複数データベースからのバックアップが困難) • アプリケーションのコード量の増加と複雑化 4 DB1 DB2 DB3 App1 App2 App3 Microservice1 Microservice2 Microservice3 Application => 最も大きい問題 Inconsistent Inconsistent
5. © 2024 Scalar, inc. Reserve なぜデータベース間の一貫性の保証が重要か？ 5 • データベース間の一貫性が無いと、データが消失もしくは間違っているように見える ◦ いわゆるデータベースアノマリーが発生 The icons are taken from vecteezy.com. Transfer $100 Decrease $100 Increase $100 データベースアノマリーはビジネスに甚大な影響を与えうる （特にエンタープライズビジネスにおいては）
6. © 2024 Scalar, inc. どのようにしてデータベース間の一貫性を保証することができるか？ • 複数データベースへの複数の操作をまとめる必要がある • 既存の方法: ◦ Saga, 2PC (Two-Phase Commit), TCC (Try-Confirm/Cancel) 6 DB1 DB2 DB3 App1 App2 App3 Microservice1 Microservice2 Microservice3 Application Consistent Consistent 複数データベースへの 複数の操作をまとめる
7. © 2024 Scalar, inc. Saga 7 • マイクロサービスにおけるトランザクショ ン一貫性を維持する方法 ◦ 元々はLong Lived Transactions (LLTs)を 通す方法 (SIGMOD’87) • 一連のローカルトランザクションを使用 ◦ 典型的には、当該トランザクション は非同期メッセージングによりコー ディネーション（Orchestrationアプ ローチ） • 補償トランザクションによりロールバック ◦ 補償トランザクションはアプリケーション が定義
8. © 2024 Scalar, inc. Sagaの利点と欠点 • 利点 ◦ リソースのロックや予約が不要 ◦ 多種のデータベースに適用可能 ◦ 他のアプローチよりも高速な場合が多い • 欠点 ◦ アプリケーションが補償トランザクションを定義する必要がある ◦ 独立性（分離性）、原子性の補償がない ◦ アプリケーションを冪等にする必要がある ◦ 実装とデバッグが困難 8 Start Create an order Update credit usage Update the order End Cancel the order Undo credit usage Cancel the order Cancel
9. © 2024 Scalar, inc. 2PC (Two-Phase Commit) • グローバルトランザクションを実現する プロトコル ◦ Jim Gray, 1977 • 2つのフェーズ ◦ 準備フェーズ: すべての参加者をコミッ ト準備状態にする ◦ コミットフェーズ: すべての参加者をコ ミット • 中間状態からのリカバリを保証 9
10. © 2024 Scalar, inc. 2PCの利点と欠点 • 利点 ◦ アプリケーション開発者の苦労がとても少ない ◦ 正しさ（ACID）を保証 • 欠点 ◦ 他のアプローチよりも遅い場合が多い ◦ ブロッキングプロトコル ▪ コーディネータのクラッシュにより停止 ◦ よく知られたプロトコル (i.e., X/Open XA) はレガシーで対応データベースが少ない 10
11. © 2024 Scalar, inc. TCC • マイクロサービスにおけるトランザクショ ン一貫性を維持する方法 ◦ CIDR’07 • 2PCの様なプロトコルをビジネスレイ ヤーで実施 ◦ リソースの確保をアプリケーションに合 わせて柔軟に行うことが可能 • 補償トランザクションによりロールバック ◦ 補償トランザクションはアプリケーション が定義 11
12. © 2024 Scalar, inc. TCCの利点と欠点 • 利点 ◦ 一定の正しさを保証 ◦ ロングトランザクションで有効 • 欠点 ◦ アプリケーションが補償トランザクションを定義する必要がある ◦ アプリケーションを冪等にする必要がある 12
13. © 2024 Scalar, inc. Saga TCC アプローチの比較 13 Correctness (Safety) Effortlessness Effortlessness Performance Availability (Liveness/Applicability) Correctness (Safety) 2PC Saga 2PC TCC 2PC TCC Saga
14. © 2024 Scalar, inc. Saga TCC 14 Correctness (Safety) Effortlessness Effortlessness Performance Availability, Applicability Correctness (Safety) 2PC Saga 2PC TCC 2PC TCC Saga 改善できそうか？
15. © 2024 Scalar, inc. 容易なトランザクション管理に向けて • Sagaの正確性を向上できるか？ ◦ グローバルでの調整を行わないため困難 • SagaまたはTCCをより容易にできるか？ ◦ アプリケーションによる補償トランザクションの定義が必要のため困難 • 2PCの可用性・適用性と性能を（容易性を犠牲にすることなく）向上できるか？ ◦ 可能 ◦ 2PCの可用性（活性）を安全性を犠牲にすることなく向上できるか？ ◦ 2PCが多様なデータストア（e.g,, XA準拠ではないデータストア）をサポートできるか？ ◦ 2PCのレイテンシを短くできるか？ 15
16. © 2024 Scalar, inc. 2PC is not an option? 16 • 30-year-old 2PC approaches are not an option. • Modern 2PC approaches are definitely an option. Reference: QCONSF 2017 - ACID Is So Yesterday: Maintaining Data Consistency with Sagas
17. © 2024 Scalar, inc. どのようにして2PCの可用性を向上できるか？ • トランザクションの調整にコンセンサスプロトコルを利用 (i.e., use Paxos Commit) ◦ コーディネータのログにレプリケーションとパーティショニングを適用 ◦ “2PCコーディネータがSPOF” はミスリーディングです 17 DB DB DB App App ・・・ Coordinator partitioned and replicated
18. © 2024 Scalar, inc. どのようにして多様なデータストアをサポートできるか？ • 抽象化層を作り、その上でトランザクションを実現 18 Multi-level Transaction Management (e.g., Oracle MicroTx XA, Atomikos XA) Single-level Transaction Management (e.g., ScalarDB) TM (Coordinator) Abstraction Abstraction TM Abstraction TM DB1 Global Transactions Local Transactions DB2 TM: Transaction Manager TM (Coordinator) Abstraction DB1 Global Transactions Local Transactions DB2 CC: Concurrency Control No CC is required No CC is required Read this paper for details about this approach.
19. © 2024 Scalar, inc. どのようにして2PCのレイテンシを短くできるか？ • 並列・非同期コミット • 1フェーズ最適化 • 詳細は論文を参照ください 19 W(X) W(Y) P(X) P(Y) C C(X) C(Y) Preapare Phase Coordinator Logging Commit Parallel Commit Asynchronous Commit W(X) W(Y) P(X) P(Y) C C(X) C(Y) W(X) W(Y) P(X) P(Y) C C(X) C(Y) Return to the client
20. © 2024 Scalar, inc. 拡張版2PCを実現したプロダクト 20 Highly available and scalable coordinator Transactions across diverse data stores Better performance Oracle MicroTx (XA) ✓ ✗ (XA-compliant DBs only) ✓ Atomikos (XA) ✓ ✗ (XA-compliant DBs only) ✓ ScalarDB ✓ ✓ ✓ • Oracle MicroTx, Atomikos, ScalarDB など
21. © 2024 Scalar, inc. 拡張版2PCはマイクロサービスの利点を阻害するか？ 21 Reference: Data Management in Microservices: State of the Practice, Challenges, and Research Directions @VLDB’21
22. © 2024 Scalar, inc. 拡張版2PCはマイクロサービスの利点を阻害するか？ 22 • いいえ • Scalability through functional decomposition. ◦ 拡張版2PCのスケーラビリティはマイクロサービスのスケーラビリティと一緒に向上する ことが可能 • Fault-isolation. (e.g., increasing data availability) ◦ 拡張版2PCであっても故障は分離される ◦ ただし、コーディネータの故障は全体に影響を与える可能性あり（Saga/TCCでも同様） • Agility on data change (e.g., facilitating schema evolution) ◦ スキーマはマイクロサービスごとに独立して更新可能 • To enable event-driven data management. ◦ イベントドリブンなデータ管理は2PCの外側でメッセージブローカー等を用いて可能 • Polyglot persistence. ◦ 2PCにより阻害されるものではない（一部の拡張版2PCはPolyglot persistenceを実現）
23. © 2024 Scalar, inc. 再掲: マイクロサービスの欠点 • データベース間のトランザクション一貫性が保証できない • 複数データベースの扱いが困難 (e.g., 複数データベースからのバックアップが困難) • アプリケーションのコード量の増加と複雑化 23 DB1 DB2 DB3 App1 App2 App3 Microservice1 Microservice2 Microservice3 Application => フレームワークの活用等により軽減可能
24. © 2024 Scalar, inc. 拡張版2PC＋スケーラブルな分散DB 24 App1 App2 App3 Microservice1 Microservice2 Microservice3 Application Distributed Database • スケーラブルな分散DBを活用し、マイクロサービスごとにテーブル・データベース を論理的に分離 ◦ スケーラブルな分散DB：Google Spanner, TiDB, YugabyteDBなど
25. © 2024 Scalar, inc. まとめ • マイクロサービスにおいて複数のデータベースを扱うこと困難が伴う • 2PCを拡張して”容易なトランザクション管理”を実現する方法は有望 ◦ 最先端の2PC製品は高い可用性、高いスケーラビリティ、高い性能を実現 ▪ Oracle MicroTx, Atomikos, ScalarDB ▪ ScalarDBはXA準拠でないデータストアに対してもトランザクションを実現 ◦ 拡張版2PCはマイクロサービスの利点を阻害しない • 拡張版2PCをスケーラブルな分散データベース上で用いることで、マイクロサービス においてより容易なトランザクション管理が実現可能 25