Towards Effortless Transaction Management in Microservices @KubeDay Japan 2024

Abstract:
Developing microservice applications based on the database-per-service pattern is challenging because you need to ensure the transactional consistency of multiple, possibly diverse, databases of microservices. Saga and TCC are widely used to address the challenge, but these approaches require the applications to ensure isolation, forcing the application developers to implement complex recovery mechanisms. Another way is using a two-phase commit (2PC). However, 2PC is often discussed as an anti-pattern in microservice architecture since it is considered limited in scalability and availability. In this session, we revisit the benefits of microservice architecture and rethink the advantages and disadvantages of the existing approaches for transaction management. We also introduce a solution that achieves effortless transaction management in microservices without losing the most benefits.

Speakers:
Hiroyuki Yamada, Toshihiro Suzuki

Transcript

1. Towards Effortless Transaction Management in Microservices Hiroyuki Yamada and Toshihiro Suzuki, Scalar, Inc.
2. © 2024 Scalar, inc. Who We Are • Hiroyuki Yamada • CTO and co-CEO of Scalar, Inc. • Ph.D. in Computer Science 2 • Toshihiro Suzuki • Architect at Scalar, Inc. • Apache HBase Committer
3. © 2024 Scalar, inc. Microservices / Microservice Architecture 3 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
4. © 2024 Scalar, inc. Pros of Microservices 4 Reference: Data Management in Microservices: State of the Practice, Challenges, and Research Directions @VLDB’21
5. © 2024 Scalar, inc. Cons of Microservices • Hard to guarantee (transactional) consistency of databases. • Hard to operate diverse databases. (e.g., taking correct backups of multiple databases is difficult.) • More code to create applications. 5 DB1 DB2 DB3 App1 App2 App3 Microservice1 Microservice2 Microservice3 Application => Biggest issue. Inconsistent Inconsistent
6. © 2024 Scalar, inc. Reserve Why Is Guaranteeing Consistency Important? 6 • Without (transactional) consistency, some data can be seen as lost or wrong. ◦ Such incidents are called anomalies in databases. The icons are taken from vecteezy.com. Transfer $100 Decrease $100 Increase $100 Database anomalies could harm your business tremendously, especially in enterprise applications.
7. © 2024 Scalar, inc. How Can We Guarantee Consistency of Databases? • Need to coordinate operations in some form of transaction. • Existing approaches: ◦ Saga, 2PC (Two-Phase Commit), TCC (Try-Confirm/Cancel) 7 DB1 DB2 DB3 App1 App2 App3 Microservice1 Microservice2 Microservice3 Application Consistent Consistent Coordinate operations with transactions
8. © 2024 Scalar, inc. Saga 8 • A mechanism to maintain transactional consistency in microservices. • Use a sequence of local transactions that are coordinated using asynchronous messaging. • Roll back transactions by using application-defined compensating transactions.
9. © 2024 Scalar, inc. Pros and Cons of Saga • Pros ◦ No locking or resource reservation required. ◦ Can be applied to various databases. ◦ Can be faster than the other approaches. • Cons ◦ Must define application-defined compensating transactions. ◦ No isolation and atomicity guarantee. ◦ Requires idempotent participants (services). ◦ Difficult to implement and debug. 9 Start Create an order Update credit usage Update the order End Cancel the order Undo credit usage Cancel the order Cancel
10. © 2024 Scalar, inc. 2PC (Two-Phase Commit) • An atomic commitment protocol that coordinates global transactions. • Two-phase protocol ◦ The prepare phase: make all the participants ready to commit. ◦ The commit phase: commit all the participants. • The protocol guarantees recovery from intermediate states. 10
11. © 2024 Scalar, inc. Pros and Cons of 2PC • Pros ◦ Extremely effortless for application developers to implement transactions. ◦ Provides correctness (ACID). • Cons ◦ Can be slower than the other approaches. ◦ Blocking protocol. ▪ A coordinator crash will block the protocol from proceeding. ◦ A well-known protocol (i.e., X/Open XA) is legacy. 11
12. © 2024 Scalar, inc. TCC • A mechanism to maintain transactional consistency in microservices. • Implements 2PC at the business layer rather than the resource layer. ◦ Allow businesses to flexibly select a resource locking granularity. • Roll back transactions by using application-defined compensating transactions. 12
13. © 2024 Scalar, inc. Pros and Cons of TCC • Pros ◦ Provides correctness. ◦ Useful for long transactions. • Cons ◦ Must define application-defined compensating transactions. ◦ Requires idempotent participants (services). 13
14. © 2024 Scalar, inc. Saga TCC Comparison of the Approaches 14 Correctness (Safety) Effortlessness Effortlessness Performance Availability (Liveness/Applicability) Correctness (Safety) 2PC Saga 2PC TCC 2PC TCC Saga
15. © 2024 Scalar, inc. Saga TCC 15 Correctness (Safety) Effortlessness Effortlessness Performance Availability (Liveness/Applicability) Correctness (Safety) 2PC Saga 2PC TCC 2PC TCC Saga Can We Make Them Better?
16. © 2024 Scalar, inc. Towards Effortless Transaction Management • Can we make Saga more correct? ◦ Difficult due to the mechanism that doesn’t have global coordination. • Can we make Saga or TCC more effortless? ◦ Difficult due to the mechanism that requires application-defined recovery logic. • Can we make 2PC more available and faster without sacrificing its effortlessness? ◦ Possible. ◦ Can we make 2PC provide high availability (better liveness) and high scalability (scalable throughput) without compromising safety? ◦ Can we make the latency of 2PC lower? ◦ Can we make 2PC support diverse data stores (e.g., Non-XA-compliant data stores)? 16
17. © 2024 Scalar, inc. 2PC is not an option? 17 • 30-year-old 2PC approaches are not an option. • Recent 2PC approaches are definitely an option. Reference: QCONSF - ACID Is So Yesterday: Maintaining Data Consistency with Sagas
18. © 2024 Scalar, inc. How Can We Make 2PC Provide High Availability and Scalability? • Use a consensus protocol for coordinating transactions. (i.e., use Paxos Commit) ◦ Apply replication and partitioning to coordinator logs. ◦ “2PC coordinator is single point of failure” is a myth. 18 DB DB DB App App ・・・ Coordinator partitioned and replicated
19. © 2024 Scalar, inc. How Can We Make The Latency of 2PC Lower? • Parallel and asynchronous commit • One-phase commit optimization • For other optimizations, read this paper. 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. How Can We Make 2PC Support Diverse Data Stores? • Create an abstraction and transaction component on top of the abstraction. 20 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.
21. © 2024 Scalar, inc. Any Products that Implement Such Enhanced 2PC? 21 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 ✓ ✓ ✓ • Yes, there are several good ones.
22. © 2024 Scalar, inc. Do Enhanced 2PC Approaches Sacrifice the Pros of Microservices? 22 Reference: Data Management in Microservices: State of the Practice, Challenges, and Research Directions @VLDB’21
23. © 2024 Scalar, inc. Do Enhanced 2PC Approaches Sacrifice the Pros of Microservices? 23 • Short answer: Not really. • Scalability through functional decomposition. ◦ The scalability of such 2PCs can be increased (by scalable coordinators) along with the microservice scalability through functional decomposition. • Fault-isolation. (e.g., increasing data availability) ◦ Faults are isolated even with such 2PCs. ◦ The coordinating component cannot be isolated. • Agility on data change (e.g., facilitating schema evolution) ◦ Schemas can still be independently updated in each microservice. • To enable event-driven data management. ◦ Event-driven data management is achievable outside 2PC by using message brokers. • Polyglot persistence. ◦ 2PC won’t sacrifice this. (e.g., ScalarDB achieves great polyglot persistence.)
24. © 2024 Scalar, inc. Review: Cons of Microservices • Hard to guarantee consistency of multiple databases. => Biggest issue. • Hard to operate diverse databases. (e.g., taking correct backups of multiple databases is difficult.) • More code to create applications. 24 DB1 DB2 DB3 App1 App2 App3 Microservice1 Microservice2 Microservice3 Application => Most frameworks mitigates the issue. => How can we make this better?
25. © 2024 Scalar, inc. Use 2PC with a Scalable Distributed Database 25 App1 App2 App3 Microservice1 Microservice2 Microservice3 Application Distributed Database • Use a scalable distributed database and logically separated tables/databases for microservices.
26. © 2024 Scalar, inc. Conclusion • Managing multiple databases in microservices is challenging. • Enhancing 2PC is a promising way for effortless transaction management. ◦ State-of-the-art 2PC-based products are highly available, scalable, and fast enough. ▪ Oracle MicroTx, Atomikos, ScalarDB ▪ ScalarDB is the only one that can do transactions across non-XA-compliant data stores. ◦ Enhanced 2PC does not sacrifice the benefits of microservices. • Using enhanced 2PC with a scalable distributed database achieves further effortless transaction management and operations. 26