Event Driven Microservices and Data Consistency, Example

https://dev-punxism.tistory.com/entry/Event-Driven-Microservices 의 연속본, Data Consistency가 핵심인듯하여 따로 정리한다.

Data is a precious thing and will last longer than the systems themselves. by Tim Berners-Lee

Software에서 중요한 것은 데이터이다. 결국 우리가 Software를 개발하는 이유가 데이터를 헨들링하기 위해서가 아닐까 생각된다.

 

MSA에서 데이터를 다루는 것은 어렵다. 특히 트랜잭션이 필요한 환경에서는 더 어렵다. 여러가지 방법들이 있지만 전반적으로 대세는 Event Souring으로 보여진다. 개인적으로는 local transaction을 이용한 ebay에서 사용한다는 BASE 모델이 마음에 들긴한다. Ordering이나 Loss에 대한 걱정을 많이 하지 않아도 될 것 같아서이다.

 

Event Sourcing은 서비스들과 통신하는 Client가 결국 비동기 방식으로 작성되어야 완성 될 수 있지 않을까 생각한다. Event Sourcing에서는 soft weak가 되면서 CQRS가 필수적으로 적용되어야 한다고 생각된다. 예를 들어 Order를 했으면 Order를 확인 하는 것은 폴링을 하거나 푸시를 하거나 비동기로 처리될 수 있어야 하며 결국 정통적인 서버, 클라이언트 구조에서 많은 부분들의 변경이 필요하지 않을까 생각된다. 

 

아래는 강의 중 소개된 nginx에서 MSA를 설명하는 링크이다. 대략적으로 비슷한 내용이라 아래 링크를 참조하는 것도 좋을 것 같다.

https://www.nginx.com/blog/event-driven-data-management-microservices/

Event-Driven Data Management for Microservices - NGINX

•  Forces
  • Some businees trasancions must update data owned by multiple services
  • Some queries must join data that is owned by multiple servies
  • Different have different data storage requirements
  • Databases must sometimes be replicated and sharded for scalavility
  • Services must be lossely coupled so that they can be developed, deployed and scaled independently
• Shared database
  • benefits
    
    • easier operationally
    • local trasactions only
  • drawbacks
    
    • lack of encapsulation/tight coupling
    • Single database might not satifsy the data access requirements of
    • many connections
• Database per service
  • variations
    • private tables
    • private schema
    • private database server
  • Escapes the constraints of relational databases
    • Scalability
    • Multi data center, distributed database
    • Schema updates
    • O/R impedance mismatch
      • mismatch rich object vs shcema (maping object to database table)
    • Handling semi structured data
  • How does each service access data
    • Velocity and Volume
    • Variety of Data
    • Fixed or ad hoc queries
    • Latency
    • Access Patterns
    • Distrubution
  • benefits
    
    • service are loosely coupled
    • Each service can use the data that is
  • drawbacks
    
    • Implementaing transactions and queries theat span multiple service
    • more complex to operate
  • problem
    • ACID broken
    • 2 phase commit
  • how to maintain invariants
    • event driven approach
• Using Events to Maintain Data Consistency
  • Use an event driven ar
    • publish
    • subscribe
      • Maintain eventual consistency across multiple aggregates
  • ACID vs Eventual Consistency
  • problem
    • How to design eventually consistency business logic
    • How atomically update database and publish an event
    • Failure = inconsistent system
    • Update and publish using 2PC
      • Guaranteed atomicity BUT
      • need a distributed trsasaction manager
      • Databse and message broker must support 2pc
      • impacts reliability
      • Not fashionable
      • 2PC is best avoided (2pc는 피하는 것이 가장 좋습니다.)
    • Transaction log tailing
      • linkedin : databus
      • AWS DynamoDB Streams
      • benefits
        
        • No 2PC
        • NO application changes required
        • Guaranteed to be accurate
      • drawbacks
        
        • immature
        • database specific
        • low level db changes rather business level event = need to reverse engineer domain events
    • Application created events
      • Local Transaction with acid - db table
      • Event publisher query to publish
      • See BASE (https://queue.acm.org/detail.cfm?id=1394128)
      • benefits
        
        • high level domain events
        • No 2PC
      • drawbacks
        
        • requries changes to the appliation
        • only works for sql and some nosql databses
        • error prone
  • Overview of Event Sourcing
    • Event Sourcing
      • For each aggregate (Business entity)
        • Identify (state changing) domin events
        • Define Event classes
      • Persistes events NOT current state
      • Replay events to recreate state
        • Periodically snapshot to avoid lodaing all events
      • Request Handling in an event sourced application (event-centric way)
        • pastEvents = findEvent(entityId) to event store
        • new() to service
        • applicaEvents(pastEvents) to service
        • newEvents = processCmd(SomeCmd) to service
        • apply(newEvents) to service
        • saveEvents(newEvents) to event store with optimistic locking
      • Event store = database + message broker
        • Hybrid database and messge broker
        • Implementations:
          • Home grown/DIY
          • geteventstore.com by greg young
          • http://eventuate.io
      • Benefis of Event sourcing
        • Solves data consistency issues in a microservice/NoSql based architecture
        • Reliable event publishing: publishes events neede by predictive analytics etc, user notifications..
        • Eliminates O/R mapping problem (mostly)
        • Reifies stat changes:
          • Bulit in, reliable audit log,
          • temporal queries
        • Preserved history => More easily implement future requirements
      • Drawbacks of
        • Requires application rewrite
        • Weird and unfamiliar style of programming
        • Events = a historical record of your bad design decisions
        • Must detect and ignore duplicate events
          • Idempotent event handlers
          • Tarack most recent event and ignore older ones
        • Querying the event store can be challenging
          • Some queries might be complex/inefficient e.g.accounts with a balance > X
          • Event store might only support lookup of events by entify id
          • Must use Command QUery Responseisbility Segregation(CQRS) to handle queries => application must handle eventually consisten data
  • Desining a Domain Model Based on Event Sourcing
    • Use the familiar building blocks of DDD
      • Entity
      • Value obejct
      • Service
      • Repositories
      • Aggregates <= essential
    • Abot Aggregates
      • Graph Consistin of a root entity and one or more other entities and value objects
      • Each core business entity = Aggregate: e.g. customer, Account, Order, Product,...
      • Reference other aggregate roots via primary key
      • Often contains parial copy of other aggregates, data
    • Domain model = collection of loosely connected aggregates
    • Easily partition intto microservices
    • Transaction = processing one command by one aggregate
      • No opportunity to update multiple aggregates within a transaction => event driven eventual consistency between aggregates
      • If an update must be atomic then it must be hanndled by a single aggregate
      • Therefore, aggregate granularity is important
    • Aggregate granularity
      • consistency <-> scalability / User experience
    • Designing domain events
      • Record state changes(and other notable things) for an aggregate
      • Part of the public API of the domain model
    • Designing commands
      • Created by a service from incoming request
      • Processed by an aggregate
      • Immutable
      • Contains value objects for
        • Validating request
        • Createing event
        • Audit user
    • Various programming models
      • Traditional java mutable object-oriented domain object
      • Functional scala with immutable domain objects
      • Hydrid OO/Functional Scala with immutable domain object
  • Event Sourcing Domain Model
    • https://github.com/cer/event-sourcing-examples.git