코레오그래피 패턴

앞서 다룬 오케스트레이터 패턴의 친척

Microservice(다시 말하지만 서비스의 규모랑 관계없음)들의 모음이 존재할 때, 얘네는 각자의 도메인에서 비즈니스 로직을 수행한다.
분리된 상태이기에 서로의 존재조차 잘 모른다.

이 상황에서 사용자 요청이 들어오면, 여러 Microservice에 걸쳐서 요청 flow가 수행될것이다.

이런 상황에서, 예전에 배운 오케스트레이터 패턴은 훌륭하지만
단점이 있다.
모든 Microservice가 시스템과 긴밀히 연결된다는 점인데, 이로 인해

• 모든 서비스가 요청 처리 flow에 지장을 주지 않도록 조정하며 개발해야 하므로, 빠른 개발 속도라는 Microservice의 장점이 퇴색됨
• Microservice가 아니라 Distributed Monolithic 처럼 될 수 있다.

그래서 상황에 따라 다른 패턴이 필요하고, 코레오그래피 패턴이 중요하다.

코레오그래피 패턴은 오케스트레이터가 없는 대신, 메세지 브로커 혹은 메시지 큐가 존재한다.

시스템에 존재하는 모든 Microservice들은, 메세지 브로커에게서 자신과 관련한 메세지를 구독한다. 그러므로 구독중인 서비스가 메시지를 수신하게 되면 처리하는 것이다.

이러한 코레오그래피패턴의 장점으로는

• 메세지 브로커를 통한 비동기 통신으로 인해, 시스템 확장 및 서비스 변경이 쉽다.
• 오케스트레이터로 인한 cost/overhead가 없다.
• 이벤트 브로커를 통해 메시지가 전달되므로, 유실될 일이 없다.(메시지를 Mircroservice가 못받았으면 재전송하면 끝)

등 등의 장점이 있다.

물론 단점도 존재하는데, 전반적인 요청 처리 flow를 따라잡기 힘들다는 점이다. 흐름을 따라잡기 어려워진다는 것은 Trouble shooting이 어려워짐을 의미한다.