Event Driven Microservices

https://learning.oreilly.com/videos/event-driven-microservices/9781491944165/

Event-Driven Microservices

이 글은 위 링크의 강의를 보고 요약/정리, 개인적인 생각을 첨가했다. 약파는 이야기(?)가 좀 있으나 전반적으로 들을만했다. 몇몇 중요하지 않다는 주제에 대해서 여러가지 view에서 설명하는 것이 흥미로웠다. 

 

몇 년전 MSA로 프로젝트를 진행하다 큰 코 다쳤다. DDD용어로 이야기하면 Domain Aggregates가 요구사항에 따라 변경되어 발생한 문제였는데 그 이후 MSA라하면 치를 떨었다. 하지만 많은 시간이 지났고 DDD와 MSA를 함께 이야기하는 것을 보거나 Event Driven, Event Sourcing등의 설계가 분산처리 시스템에서 중요하게 자리잡는 것을 보고 다시 한 번 알아볼 마음이 생겨 코스를 수강했다.

 

예제 소스 보다 강사의 repository를 보게 되었는데 아직도 왕성하게 commit이 올라온다. 보고 배울만한 점이다.

 

소프트웨어 아키텍쳐에 대해서 은탄환은 없다. MSA에 대한 강의이지만 Monolitic이나 다른 architecture도 충분히 사용 가능하다는 것을 인지해야한다. 요즘 읽는 책에서 본 인상 깊었던 문장이 떠오른다.

 

Don’t try to find the best design in software architecture; instead, strive for the least worst combination of trade-offs.

소프트웨어 아키텍처에서 최상의 디자인을 찾으려고 하지 마십시오. 대신, 최소 최악의 절충안 조합을 위해 노력하십시오.

Monolitic architecture

• easy / past, simple
• slow start application
  • 오픈소스 소프트웨어 최적화 보고서에서 느리게 시작하는 프로젝트의 경우 개발자들의 참가율이 떨어진다는 글을 본적이 있다.  간과 할 수 있는 부분이지만 개발자의 만족감을 주거나 수십번의 Test를 수행한다 생각하면 어떻게든 줄이는게 좋다고 생각한다. 
• more coordinator
  • 관계자가 많기 때문에 더 많은 커뮤니케이션이 발생한다. 현 부서가 이렇게 일하고 있는데 참 공감가는 부분이다.
• cpu, io, memory intensive
• 기술 트랜드를 따라가기 힘들다

 

MicroService Architecure

• The Scale Cube - https://microservices.io/articles/scalecube.html

The Scale Cube

Scale에 대해 Cube로 설명한다. X축은 instance를 늘리는 것이다. 가장 보편적으로 하고 있는 scale 방식이지만 원천적인 복잡한 문제를 해결해 주진 않는다. Y축의 확장은 서비스를 분리 확장하는 MSA의 개념이다 Z축은 data paritioning 또는 그와 비슷한 확장 방식이라 한다. X의 확장과 비슷하나 다른 점은 각 서버가 subset의 data만의 책임을 가지는 개념이다.

 

• benefits
  • easy understand
  • less jar, classpath hell = who needs osgi?
  • faster to build and deploy
  • reduce start up time & test time
  • scales development
  • fault isolation - impact toe one small service
• drawbacks
  • complexity of developing a distrubuted system
  • vs complexity of monolitic architecture
  • multiple databases & transaction management
    • fun with eventual consistency
    • can`t use ACD, CAP
  • complexity of test, deploying, operating
    
    • need a lot of automation
  • developing features that span multiple services requires careful coordination
• Conway Law
  • software의 구조는 조직의 모양을 미러한다. 
  • https://thecustomizewindows.com/2021/01/what-is-conways-law/

What is Conway's Law?

 

Partitioning Strategies

• partition by noun (service), verb(checkout ui), subdomain
• Single Responsibility Principle
• Major Challeange
  • How to enforce invariants across paritioned service without 2PC
  • Partitioning requires you understand the design
    • Existing Monolith
      • You understand the dependencies but decomposion
    • Greenfield Development - No code -> No tangled dependencies, but no design either Therefore do some upfront design / prototyping to understand what you are partitioning

Greenfield development refers to developing a system for a totally new environment and requires development from a clean slate – no legacy code around. It is an approach used when you’re starting fresh and with no restrictions or dependencies. 

• • • • https://synoptek.com/insights/it-blogs/greenfield-vs-brownfield-software-development/

Brownfield vs. Greenfield Development: What’s the Difference in Software? | Synoptek

 

• How many services
  • Too few
    • Drawbacks of the monolithic architecture
  • Too many - a.k.a Nano-service anti-pattern
    • Runtime overhead
    • Potential risk of excessive ntework hops
    • Potentially difficult to understans system
• Anti-pattern : Distributed Monolith
  • Remember the goal : Partition you application so that most chanes only impact a single service
  • But if you get it wrong : Each change reqquires you to update and deploy all services
  • Therefore : Common Closure Principle
    • Components that change for the same reason should be packaged together
• Partitioning is something of an art
  • nginx introducion-to-microservice : https://www.nginx.com/blog/introduction-to-microservices/?_bt=576183938381&_bk=&_bm=&_bn=g&_bg=136047553361&gclid=Cj0KCQiAjJOQBhCkARIsAEKMtO3_ldPBdSDBTKipGKcBnr8Q9cipfObRmWCNI1qyztITSi3SOwQxAeoaAg7SEALw_wcB

Introduction to Microservices | NGINX

아래는 MSA에 필요한 피처들의 나열이다. 일반적으로 많이 알려진 내용이라 생각되어 별도의 코멘트는 하지 않았다.

Deployment Patterns

• multiple service per host
  • Benefits
    • Efficient resource utilization
    • fast deployment
  • Drawbacks
    • Poor/Terrible isolation
    • poor visibility
    • difficult to limit resource utilization
    • risk of dependency version conflicts
    • poor encapsulation of implementation technology
• service per vm
  • Benefits
    • Greate isolation
    • Greate manageability
    • Vm encapsulates
    • Leverage Cloud infrastructure for Autoscaling
  • Drawbacks
    • Less efficient resource utilization
    • slow deploymnet
• service per container
  • Benefits
    • Greate isolation
    • Greate manageability
    • Container encapsulate implementation technology
    • Efficient resource utilization
    • Fast deployment
  • drawbacks
    • immature infrastructure for deploying containers
    • Containers are not as secure as VMs

 

Communication Patterns

• API Gateway
  • MIsmatch between the fine-grained microservices and needs of the clients
  • Different clients need different data
  • LAN vs WAN vs Mobile network performance
  • The number of service instances and their locations (host _ port) changes dynamically
  • Partitioning into services can change over time and should be hidden from clients
  • API
    • SIngle entry point
    • protocol trasnlate
  • Benefits
    • Insulates the clients from the partitioning
    • Insulates the clients from the problem of discovery
    • Provides the optimal api for each client
    • Reduces the number of requests/roundtrips
    • simplefies the client by moving logic for calling mulple services from the client to API gateway
    • Gateway translates between we-unfriendly protocols
  • Drawbacks
    • Increased complexity
    • Increased response time due to the additional network hop
• IPC
  • The need for IPC
    • Monolith application
      • Single process
      • all invocations are local, language level calls
    • Microservices
      • Almost always separate processes
      • Usually on separate machines
    • There
  • Interaction styles
    • one to one
      • synchronous
    • one to many
      • synchronous
        • one way notification
        • request/async response
      • asynchronous
        • publish/subscribe
        • publish/async responses
  • Messger formats
    • Text
      • bulky slow to parse
    • Bianry
      • protocol buffers, avro
      • Compact, fast to parse
  • Envolving APis
    • Chagnes is inevitable
    • minor, backwards compatible chagnes
      • Robustness principle
    • major changes
      • Verson number in url and mime types
• Messaging
  • benefits
    • decouples
    • broker buffers messages
    • variety of communcation patterns
  • Drawbacks
    
    • additional complexity of message broker
    • request/reply - style communication is more complex
    • Client needs to discover location of message broker
• RPI(Rest, Thrift)
  • benefits 
    • simple and familar
    • easy
    • no need broker
  • Drawbacks
    
    • only supports request/reply
    • service must be available
    • client needs to discover locations of service instances
  • Rest
    • https://martinfowler.com/articles/richardsonMaturityModel.html

Richardson Maturity Model

Servie Discovery

• client - side discovery by service registry
  • netflix eureka and ribbon
  • b
    • flexible, application specific load balancing
    • fewer network hos and moving parts compared to server-side discovery
  • d
    • couples the client to the service registry
    • need implement client side discovery and load balancing
    • service registry is yet another moving part to setup and operate - highly avaliable
• service-dise discovery with router by service registry
  • k8s ingress, aws elb
  • b
    • simper client code
    • buildt-in some cloud
  • d
    • limited to load banlcing algorithms
    • more network hop
    • router and servbice registry is yet another moving part to setup and operate highly avalable
• Service Registry
  • EUreka
  • zookeeper
  • Consul
  • Etcd
  • Must be highly-avaliable

• • Service Registration
    • who does?
    • Self registration
      • b
        • simple
      • d
        • couples the service to service registry
        • implement registration logic
        • servic emight lack the self awareness to unregister
    • 3rd party registration
      • registar health check sergvice instance
      • register heart-beat unregister
      • example
        • aws autoscaling
        • registrator
        • container buddy
        • Consul or Etcd
        • k8s, eureka prana
      • b
        • simpler service
        • registar can
      • d
        • registrar is often yet another hightly avaliable components