마이크로 서비스 : 이벤트 주도 아키텍처 : 개념, 정의, 개요

마이크로 서비스 통신 방법

Rest API는 클라이언트에서 서버 쪽에 존재하는 마이크로서비스를 호출할 때 기본 통신방법이 되며, 다양한 클라이언트 채널 연계나 외부에 API의 공개를 원활하게 하기 위한 방법으로는 API G/W를 사용하는 것을 살펴봤습니다.

제일 먼저 검토해야 할 방법은 Rest API 같은 동기식 호출입니다. Sync 방식이라고도 합니다. 동기식 호출은 Request를 하면 바로 Response가 오는 방식을 말합니다.모바일 UI에서 상품서비스에 Post 방식의 요청을 하고, 상품은 주문 서비스에 Get 방식의 동기호출을 하고 있습니다. 그에 따라 바로 응답이 발생하고, 200이라는 OK 코드도 받아오는 것을 볼 수 있습니다. 바로 요청하면 응답이 오는 패턴이기 때문에 가장 많이 쓰이는 방식이고 구현하기 쉽습니다.

장애가 생기면 호출한 서비스는 반응이 올 때까지 기다리게 되고, 반응이 오지 않으면 계속 기다리면서 재호출하게 됩니다. 그렇다면 여러 개의 서비스간의 연계로 업무를 처리하는 마이크로서비스 구조에서는 장애가 연쇄적으로 발생할 수 있는 것이죠. 그래서 이러한 문제를 해결하기 위한 다른 통신방법이 필요합니다.

다음 방식은 메시지 기반의 Asynchronous 비동기식 호출입니다. 이 방식은 동기식 호출처럼 응답을 기다리지 않습니다. 메시지를 보낸 다음에 응답을 기다리지 않고 자신의 일을 처리합니다. 물론 보낸 결과가 어떻게 되었는지 응답을 받지 않으니 동기식처럼 완결성을 보장할 수는 없습니다. 따라서 이를 보장하기 위한 메커니즘이 필요한데요. 보통 Apache Kafka, RabbitMQ, ActiveMQ 같은 메시지 브로커를 사용합니다.

이러한 메커니즘에서는 메시지를 보내는 Producer와 메시지를 가져다가 처리하는 Consumer가 서로 직접 접속하지 않고 메시지 브로커에 연결됩니다. 메시지에 전달할 메시지 이벤트를 던지고 자신의 일을 처리하면 메시지 브로커가 전송을 보장하는 것입니다. 그런데 여러 서비스에서 던진 메시지 이벤트를 처리하기 위해서는 부하가 걸릴 수가 있을 겁니다. 그래서 메시지 브로커는 메시지 처리 규모에 따라 확장이 가능합니다.

이러한 방식은 메시지가 브로커에 의해 중계되기 때문에 통신하는 서비스들이 물리적으로 동일한 시스템에 위치할 필요도 없습니다. 그리고, 서로 프로세스를 공유할 필요도 없습니다. 심지어 동일한 시간대에 동시에 동작하지 않아도 됩니다. 따라서 서비스 요구에 따라 늘어나거나 줄어들 수 있는 탄력성이 높은 클라우드 플랫폼 환경에서 서비스가 다운되었을 때 또는 시스템을 더 확장해야 할 때 사용할 수 있는 매우 효과적인 방법을 제공 해줍니다. 사실 이러한 메시지 이벤트를 통한 비동기 통신은 최근에 탄생한 방식이 아니라 기존 시스템에서도 오랫동안 사용했던 기술입니다.

 

 

이벤트 주도 아키텍처

이벤트 주도 아키텍처라고 부르는데요. 일반 실생활에서도 효율성을 위해 이미 많이 사용하는 방식입니다. 예를 들어 보도록 하겠습니다. 커피숍이 있는데요. 손님이 주문을 하게 되면 주문접수자는 주문을 받습니다. 그리고 바리스타에게 커피제작을 의뢰하게 됩니다.

동기 방식처럼 아무것도 안 하고 기다리지 않습니다. 여러 개의 주문을 받아 순차적으로 주문목록에 적고, 커피주문이 들어왔다는 이벤트를 바리스타에게 전달합니다. 그럼 바리스타는 커피주문 이벤트를 순차적으로 제작목록에 기입하고 주문한 종류에 해당하는 커피를 만들게 됩니다.

그리고 커피가 다 만들어지면 커피제작완료 이벤트를 보내고, 이것이 진동벨을 통해 손님에게 통보되는 것입니다. 하나의 커피주문을 받고 이것이 제작될 때까지 다른 주문접수가 안 된다면 매우 비효율적일 것입니다. 그렇지만 이런 이벤트 기반의 방식은 여러 개의 주문을 받아 여러 개의 커피를 제작할 수 있는 효율성을 만들어 줍니다.

 

마이크로 서비스 : 이벤트 주도 아키텍처 : 개념, 정의, 개요

 

이와 같이 이벤트 기반 아키텍처는 이벤트를 생산하는 모듈과 이벤트에 대응하는 모듈을 분리하고 상호 독립적으로 동작하게 함으로써 병렬처리를 촉진하게 해줍니다. 또한 이벤트 메시지를 사용하면 발신자와 수신자를 장소와 시간에서 쉽게 분리할 수 있습니다. 이벤트 주도 아키텍처는 이러한 느슨한 결합으로 인해 확장성 및 수정 가능성에 많은 이점을 제공합니다.