Se ha denunciado esta presentación.
Utilizamos tu perfil de LinkedIn y tus datos de actividad para personalizar los anuncios y mostrarte publicidad más relevante. Puedes cambiar tus preferencias de publicidad en cualquier momento.

Microservices: Event Driven Architecture

319 visualizaciones

Publicado el

MSA로 개발 중인 프로젝트에 EDA 적용한 이유..

Publicado en: Software
  • Sé el primero en comentar

Microservices: Event Driven Architecture

  1. 1. Microservices: Event Driven Architecture ACT Kihoon Kim koreakihoon@gmail.com
  2. 2. 아파트 물탱크 청소로 인해 단수가 될 예정이다. 어떻게 알릴 것인가?
  3. 3. 집집 마다 방문해서 알려준다 101호 102호 201호 202호 301호 302호 … 103호 104호 203호 204호 303호 304호 … ………..
  4. 4. 안알려준다 물어보러 오겠지 뭐...
  5. 5. 공고문을 붙인다 볼 사람은 보겠지...
  6. 6. 안내방송을 한다 들을 사람은 듣겠지.. 관리사무소에서 안내말씀 드립니다. 공고해 드린바와 같이…….
  7. 7. 일정이 변경되거나 취소된다면?
  8. 8. 다시 집집 마다 방문해서 알려준다 101호 102호 201호 202호 301호 302호 … 2801호 2802호 103호 104호 203호 204호 303호 304호 … 2803호 2804호 ………..
  9. 9. 역시 안알려준다 다시 물어보러 오겠지 뭐...
  10. 10. 다시 공고문을 붙인다 볼 사람은 보겠지...
  11. 11. 다시 안내방송을 한다 들을 사람은 듣겠지.. 관리사무소에서 안내말씀 드립니다. 공고해 드린바와 같이…….
  12. 12. 어떤 방법을 선택 할 건 가요?
  13. 13. 실 생활에서는 너무 익숙한 이벤트들
  14. 14. 하지만, 개발을 한다면?
  15. 15. 집집 마다 방문해서 알려준다 notifyDansu(jumindle); cancelDansu(jumindle); ControlOffice service Jumin service request response
  16. 16. 상가에도 알려줘야 한다면? notifyDansu(jumindle); notifyDansu(sangga); cancelDansu(jumindle); cancelDansu(sangga); ControlOffice service Jumin service request response SangGa service
  17. 17. 안알려준다 ControlOffice setDansu(); Jumin if( !isDansu() ) { ... } database …. dansu …. true NoticeBoard table
  18. 18. 상가 사람도 궁금하면 직접 물어보겠지 뭐.. ControlOffice setDansu(true); Jumin if( !isDansu() ) { } database …. dansu …. true NoticeBoard table Sangga if( !isDansu() ) { }
  19. 19. DB 컬럼이나 다른 도메인 객체와 의존성이 생기기 때문에 변경을 어렵게 만든다
  20. 20. 특정 상태를 궁금해하는 대상이 늘어날 때마다 알림에 대한 책임이 있는 소스가 변경된다 notifyDansu(jumindl); notifyDansu(sangga); …..
  21. 21. 만약 상가에 알림을 주다가 오류가 났다면, 이미 성공한 다른 알림들은 rollback 해야 하나? notifyDansu(jumindl); // 성공 notifyDansu(sangga); // 실패
  22. 22. 우리는 왜 event를 사용하게 되었나?
  23. 23. ACID Atomicity : 트랜잭션과 관련된 작업들이 부분적으로 실행되다가 중단되지 않는 것을 보장 Consistency : 트랜잭션이 실행을 성공적으로 완료하면 언제나 일관성 있는 데이터베이스 상태로 유지 Isolation : 트랜잭션을 수행 시 다른 트랜잭션의 연산 작업이 끼어들지 못하도록 보장 Durability : 성공적으로 수행된 트랜잭션은 영원히 반영되어야 함 BEGIN TRANSACTION select ... insert ... update ... delete … COMMIT TRANSACTION
  24. 24. 하지만.. 분산환경 이라면?
  25. 25. 2PC (two-phase commit) 아..어렵….. http://apprize.info/php/zookeeper/5.html
  26. 26. CAP Consistency(일관성) : 모든 노드는 같은 시간에 항상 동일한 data를 보여줘야 한다 Availability(가용성) : 모든 요청에 대해서 언제나 응답을 받을 수 있어야 한다 Partition Tolerance(분할용인) : 노드간 네트워크 장애가 있어도 동작해야 한다 CAP 중 2가지를 선택해야 한다. 분산 시스템에서 분할 용인이 없다면 네트워크 상에서 동작할 수 없다. 따라서 분산시스템에서 CA는 존재 할 수 없다.
  27. 27. C, A 중 하나 희생하기 AP node1의 데이터가 변경되고 node2에 복제하는 도중에 오류가 발생했다면 두 노드는 동일한 요청에 다른 결과를 리턴할 수 있다. 일관성은 잃었지만 가용한 상태이다. CP node1의 데이터가 변경되고 node2에 복제하는 도중에 오류가 발생했다면 일관성을 유지할 수 없기 때문에 요청에 응답하지 않는다. 일관성은 달성했지만 가용한 상태가 아니다. node1 node2 복제실패 node1 node2 복제불가 X X
  28. 28. AP vs CP 어떤것을 선택해야 할까? 시스템 전체가 AP이거나 CP일 필요는 없다. 양자 택일의 문제도 아니고, 상황에 따라 다르다. AP : 제품 목록을 보여주는 경우. 잠깐 예전 품목이 보여도 상관없다면.. CP : 재고가 없는 품목을 판매해서는 안된다면..
  29. 29. BASE Basically Available Soft state Eventually consistent # eventually consistent 일시적으로 Consistent하지 않은 상태가 되어도 일정 시간 후에는 Consistent 상태가 되는 성질
  30. 30. Microservices
  31. 31. Microservices - Martin Fowler Componentization via Services Organized around Business Capabilities Products not Projects Smart endpoints and dumb pipes Decentralized Governance Decentralized Data Management Infrastructure Automation Design for failure Evolutionary Design
  32. 32. Componentization via Services a component is a unit of software that is independently replaceable and upgradeable. services are out-of-process components who communicate with a mechanism such as a web service request, or remote procedure call. 그림 : https://www.nginx.com/blog/introduction-to-microservices/
  33. 33. Smart endpoints and dumb pipes Applications built from microservices aim to be as decoupled and as cohesive as possible - they own their own domain logic and act more as filters in the classical Unix sense - receiving a request, applying logic as appropriate and producing a response. The two protocols used most commonly are HTTP request-response with resource API's and lightweight messaging. E S B Central Bus Decentralized ps -ef | grep java
  34. 34. Decentralized Data Management DDD divides a complex domain up into multiple bounded contexts and maps out the relationships between them. each service manage its own database, either different instances of the same database technology, or entirely different database systems - an approach called Polyglot Persistence. Using transactions like this helps with consistency, but imposes significant temporal coupling, which is problematic across multiple services that consistency may only be eventual consistency and problems are dealt with by compensating operations. 그림 : https://martinfowler.com/articles/microservices.html
  35. 35. Design for failure Any service call could fail due to unavailability of the supplier, the client has to respond to this as gracefully as possible. Since services can fail at any time, it's important to be able to detect the failures quickly and, if possible, automatically restore service. Microservice teams would expect to see sophisticated monitoring and logging setups for each individual service such as dashboards showing up/down status and a variety of operational and business relevant metrics.
  36. 36. Evolutionary Design The key property of a component is the notion of independent replacement and upgradeability - which implies we look for points where we can imagine rewriting a component without affecting its collaborators. Parts of a system that change rarely should be in different services to those that are currently undergoing lots of churn. If you find yourself repeatedly changing two services together, that's a sign that they should be merged. With a monolith any changes require a full build and deployment of the entire application. With microservices, however, you only need to redeploy the service(s) you modified.
  37. 37. 즉, MSA는 어렵다 Out-of-process components as decoupled and as cohesive as possible Polyglot Persistence Transaction-less eventual consistency unavailability of the service redundant data service A maria db service B mongo db service C mongo db api gatewayrequest : point of failure
  38. 38. Event Driven Data Management in MSA
  39. 39. Event Driven Architecture Micro services 는 loosely coupled service 들의 집합이다. 각 service는 encapsulated data를 갖는다. 따라서, 내 domain 내의 변화를 다른 서비스에게 dependency 없이 event를 통해 알려주고 싶다. # Event Notification This happens when a system sends event messages to notify other systems of a change in its domain. A key element of event notification is that the source system doesn't really care much about the response. - https://martinfowler.com/articles/201701-event-driven.html 그림:https://www.nginx.com/blog/event-driven-data-management-microservices/
  40. 40. step1. The Order Service creates an Order with status NEW and publishes an Order Created event. https://www.nginx.com/blog/event-driven-data-management-microservices/
  41. 41. step2. The Customer Service consumes the Order Created event, reserves credit for the order, and publishes a Credit Reserved event. https://www.nginx.com/blog/event-driven-data-management-microservices/
  42. 42. step3. The Order Service consumes the Credit Reserved event, and changes the status of the order to OPEN. https://www.nginx.com/blog/event-driven-data-management-microservices/
  43. 43. 하지만, rollback 이 쉽지 않다. rollback 역시 eventually consistent 가 반드시 이루어 져야한다. Order Created Event revise Order Created Event
  44. 44. 하지만, Long Running Process Saga Pattern Process Manager 등등 이라 불리는 상황에서 서비스간 의존성을 줄이는 데 좋을 수 있다. 그림: https://msdn.microsoft.com/en-us/library/jj591569.aspx
  45. 45. 그런데.. Message Broker가 죽어 있다면? Consumer 에서 처리 하는 중에 에러 났다면? event 가 반드시 전달 됨을 보장해야 된다면?
  46. 46. Message Broker는 어떤걸 사용할까?
  47. 47. message queue https://github.com/mqtt/mqtt.github.io/wiki/server-support 대용량 cep 엔진 이라면 kafka 아니면.. RabbitMQ로 충분 QoS(quality of service) level 등 상황에 맞게 queue를 선택하면 됨 0 : At most once. 전달 보장 안됨 1 : At least once. 중복 전달 될 수 있음 2 : Exactly once. 전달 보장 됨. 성능 저하 가능성. Server QoS 0 QoS 1 QoS 2 auth bridge $SYS SSL dynamic topics cluster websockets plugin system Apache ActiveMQ ✔ ✔ ✔ ✔ ✘ ✘ ✔ ✔ ✔ ✔ ✔ RabbitMQ ✔ ✔ ✘ ✔ ✘ ✘ ✔ ✔ ? ? ? mosquitto ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔ § ✔ ✔
  48. 48. RabbitMq RabbitMQ is a message broker: it accepts and forwards messages. You can think about it as a post office: when you put the mail that you want posting in a post box, you can be sure that Mr. Postman will eventually deliver the mail to your recipient. In this analogy, RabbitMQ is a post box, a post office and a postman. http://www.rabbitmq.com/getstarted.html
  49. 49. 기본 용어 publish : message를 보냄 subscribe : message를 수신하기 위해 구독함 producer : message를 보내는 프로그램 consumer : message 오기를 기다리는 프로그램 queue : message가 담겨지는 공간 exchange : producer에게 message를 받아 정해진 rule에 따라서 queue에 넣어 주는 역할 binding : exchange와 queue를 연결해 주는 것 routing : exchange가 queue에게 message를 전달해 주는 작업
  50. 50. Acknowledgment & Confirm message 가 최소 한번은 처리되었음을 보장해 주는 방법 (QoS level 1) acknowledgment : consumer가 message를 받아서 처리 했음을 서버에게 알림 confirm : 서버가 message가 처리됐음을 producer에게 알림 https://www.rabbitmq.com/reliability.html https://www.rabbitmq.com/confirms.html ackconfirm
  51. 51. message 처리 실패 http://www.brianstorti.com/rabbitmq-exponential-backoff/
  52. 52. 단순히 하나의 특정 consumer에게 알리고 싶다 producer는 message를 queue 를 통해 보내고, consumer는 queue를 통해 message를 받는다. //---- Producer @Component public class Tut1Sender { @Autowired private RabbitTemplate template; @Autowired private Queue queue; @Scheduled(fixedDelay = 1000, initialDelay = 500) public void send() { String message = "Hello World!"; this.template.convertAndSend(queue.getName(), message); System.out.println(" [x] Sent '" + message + "'"); } } //---- Consumer @RabbitListener(queues = "hello") public class Tut1Receiver { @RabbitHandler public void receive(String in) { System.out.println(" [x] Received '" + in + "'"); } }
  53. 53. 그 consumer가 scale out 되어 있다면? Round-robin dispatching message는 각 consumer에게 순서대로 전달됨. 모든 consumer는 동일한 수의 message를 전달 받음. 특정 message 가 큰 경우 특정 consumer에 작업이 몰릴 수 있음 Fair dispatch prefetchCount 에 따라서 message를 전달 prefetchCount 가 1인 경우 ack를 받지 못한 message가 있다면 해당 consumer에 새 message를 전달하지 않음 (spring-amqp default) //---- Consumer 1 @RabbitListener(queues = "hello") public class Tut1Receiver { @RabbitHandler public void receive(String in) { System.out.println(" [x] Received '" + in + "'"); } } //---- Consumer 2 @RabbitListener(queues = "hello") public class Tut1Receiver { @RabbitHandler public void receive(String in) { System.out.println(" [x] Received '" + in + "'"); } }
  54. 54. 어떤 consumer 들이 message를 받을 지 모른다면? Exchange type : fanout 바인딩 되어 있는 모든 queue에 message 전달 //---- Producer @Configuration public class Tut3Config { @Bean public FanoutExchange fanout() { return new FanoutExchange("tut.fanout"); } } //---- Consumer @Configuration public class Tut3Config { @Bean public FanoutExchange fanout() { return new FanoutExchange("tut.fanout"); } @Bean public Queue autoDeleteQueue1() { return new AnonymousQueue(); } @Bean public Binding binding1(FanoutExchange fanout, Queue autoDeleteQueue1) { return BindingBuilder.bind(autoDeleteQueue1).to(fanout); } }
  55. 55. consumer가 특정 message만 받고 싶다면 Exchange type : direct routing key를 가진 queue에만 message 전달 //---- Producer @Configuration public class Tut3Config { @Bean public DirectExchange direct() { return new DirectExchange("tut.direct"); } } //---- Consumer @Configuration public class Tut3Config { @Bean public DirectExchange direct() { return new DirectExchange("tut.direct"); } @Bean public Queue autoDeleteQueue1() { return new AnonymousQueue(); } @Bean public Binding bindingOrange(DirectExchange direct, Queue autoDeleteQueue1) { return BindingBuilder.bind(autoDeleteQueue1) .to(direct).with("orange"); } }
  56. 56. consumer가 특정 패턴에 따라 message를 받아야 한다면 Exchange type : topic 패턴에 매칭되는 queue에만 message 전달 //---- Producer @Configuration public class Tut3Config { @Bean public TopicExchange topic() { return new TopicExchange("tut.topic"); } } //---- Consumer @Configuration public class Tut3Config { @Bean public TopicExchange topic() { return new TopicExchange("tut.topic"); } @Bean public Queue autoDeleteQueue1() { return new AnonymousQueue(); } @Bean public Binding binding1a(TopicExchange topic, Queue autoDeleteQueue1) { return BindingBuilder.bind(autoDeleteQueue1) .to(topic).with("*.orange.*"); } }
  57. 57. 그래서 우리 프로젝트는...
  58. 58. Continuous Improvement...
  59. 59. reference site : https://www.nginx.com/blog/event-driven-data-management-microservices/ https://martinfowler.com/articles/microservices.html http://www.rabbitmq.com/getstarted.html http://www.brianstorti.com/rabbitmq-exponential-backoff/ https://github.com/mqtt/mqtt.github.io/wiki/server-support book : 마이크로서비스 아키텍처 구축(http://www.yes24.com/24/Goods/36551677)
  60. 60. Thank you

×