Event Driven Architecture 톺아보기

주니어 개발자의 입장에서 바라본 EDA

 많은 회사에서 비지니스 성장에 대비하기 위한 확장 가능한 구조를 구축하기 위해 Microservice- Architecture(MSA)와 Event Driven Architecture(EDA)를 사용하고 있습니다. MSA를 직접적으로 경험해본 것은 아니지만 학생일 때도 이런 저런 활동을 하면서 많이 들어 익숙한데 비해, EDA는 회사에 들어와 처음 접한 생소한 개념입니다. 이번에는 EDA를 처음 접한 초심자의 입장에서 EDA에 대해 소개하고자 합니다. 혹시라도 틀린 개념이 있다면 말씀 해주시면 감사하겠습니다.

EDA 소개와 예

 EDA를 아마존 AWS에서 소개하기를 "Event Driven Architecture는 분리된 (decoupled) 서비스 간 동작과 통신을 위해서 이벤트를 사용하며 마이크로서비스로 개발된 최근 애플리케이션에서 주로 사용한다"라고 합니다. 여기서 이벤트란 애플리케이션 내의 모든 상태 변화를 뜻합니다.

이런 이벤트가 아닙니다...

 이벤트를 흔히 우리가 실생활에서 사용하는 E-commerce의 예를 들어 설명 해보겠습니다. 상품 A가 있다고 가정을 하면 예상할 수 있는 이벤트는 "상품 A를 장바구니에 담는다.", "상품 A의 재고가 줄어든다." 가 있습니다. 즉, 이벤트란 상태가 변화하는 행동이라고 생각할 수 있습니다.

EDA가 필요한 이유

 그렇다면 EDA를 왜 사용할까요? MSA는 각 마이크로서비스마다 데이터를 가지고 있고 다른 서비스와의 통신시에는 API를 사용합니다. (Database per service)

https://docs.microsoft.com/ko-kr/azure/architecture/includes/images/microservices-logical.png

 EDA를 사용하면 API를 사용하는 서비스(Api Client) 입장에서 API 를 제공하는 서비스 (API Server)가 추상화되어 API 호출을 비동기 적으로 처리할 수 있습니다. 조금 더 자세히 설명하면, API Client가 API Server와 직접적으로 연결하지 않아 요청을 보내면 응답이 올 때 까지 기다리는 대신 다른 작업을 하고 응답이 올 때 응답 처리를 합니다. EDA를 사용하지 않는다면 API Client는 API Server의 상태에 의존적입니다.

 EDA를 사용하면 API Client는 API Server를 알지 못해도 이벤트 채널 (Event Channel) 에서 이벤트를 구독하여 비동기 적으로 처리할 수 있습니다. 비동기 처리를 하면 API 호출에 블락되지 않고 다른 작업을 할 수 있어 처리 성능이 증가합니다. 하지만 비동기 호출은 애플리케이션 개발의 복잡성이 증가하고 디버깅이 어려워집니다.

 API Server가 추상화 되면 API Server 확장에도 도움이 됩니다. API Client는 API Server와 직접적인 통신을 하지 않아 API Server가 잠시 죽어도 상관 없습니다. API Server의 이벤트 채널에 이벤트만 정상적으로 생성(Produce) 해준다면 동일한 응답을 기대할 수 있습니다. 확장이 필요할 때 다른 처리 없이 서버만 추가하면 됩니다. 하지만 단점도 있습니다. 이벤트 채널의 복잡성이 증가합니다. 이벤트 채널 생성과 소비(Consume) 정도를 측정하고 배압 (backpressure) 처리를 해야 합니다.

 주니어 개발자로서 EDA를 처음 접했을 때 가장 궁금했던 것은 "이걸 왜 사용하는가" 였습니다. 정리하자면 MSA를 사용할 때 API 사용 서비스와 API 제공 서비스를 추상화하여 비동기 적으로 API를 사용할 수 있고 손쉽게 확장할 수 있다는 것입니다. 많이 적고 싶지만 아직 알지 못해 자세히 적지는 못했지만 프로젝트가 끝날 때 쯤에 기회가 된다면 다시 EDA에 관한 글을 적고 싶습니다. 그때 다시 봅시다:)