EDA - Event Driven Architecture

About this offer

아키텍처에 대한 고민 UMC라는 연합동아리에서 2번의 백엔드 개발자로써 참여하게 되면서 백엔드 전체적인 흐름과 구조를 파악할 수 있게 되었고, 최근 들어서는 큰 구조와 틀을 알게 되고 나서 , 이 구조와 틀을 다른 방식으로 구성해보고 싶다는 생각을 많이 하였다. 두번의 프로젝트 모두 하나의 서버에 모든 도메인 로직과 기능들이 구현되어있는 모놀리식 서버 구조였고, 하나의 HTTP 요청에 대하여 하나의 트랜잭션으로 모든 도메인들이 처리되는 구조였다. "확장성 ❌ , 거대한 트랜잭션 안의 동기적 요청 , 도메인간 강결합" 모든 요청들이 동기적으로 연결되는 것에 대한 문제점을 인지하여 Event-Driven Architecture 에 관해 공부해보았다. 확장성 좋은 코드와 좋은 설계는 여러가지 기준이 있겠지만, 확장에 열려 있으며, 변경에는 닫혀있다. 구현에 의존하지 말고, 추상화에 의존하라 라는 것이 크게 가장 신경쓰는 부분들인것같다. 2번의 프로젝트에서의 MVC 아키텍처 , DDD 아키텍처 모두 도메인간의 결합을 최소화 하고자 Port , Adapter , Usecase간의 인터페이스를 이용한 도메인간 소통을 구현해 보았는데, 도메인이 다른 도메인을 호출해야하는 일들이 늘어날때마다 인터페이스를 늘려줘야한다는것은 해결하지 못하는 문제였다. 매번 동료의 usecase추가 요청이 지겨웠다. 그래서 EDA란 ? 앞에서 서술한 문제점 , 서론에서 보았던 문제를 일부분 해결할 수 있는 Event-Driven Architecture이다. 도메인간의 소통의 방식을 설계한 Architecture이다. 가장 다른 점은 도메인에서 이벤트를 발행 그 이벤트를 동시 다발적으로 필요한 Consumer 도메인들이 그 이벤트를 소비한다. 그래서 Event의 Payload를 정해두고, 어떤 Event를 소비하고 발행할것인지 Contract를 정한 후 , Event Hamndler 을 도메인별로 정의해두면 , 도메인간의 결합을 이벤트를 통한 소통으로 변경하여 Loosely Coupling을 구현할 수 있게 되는것이다. EDA 관점 OrderCreated ↓ Message Broker ├─ Inventory Service Event Handler ├─ Notification Service Event Handler └─ Analytics Service Event Handler 이 아키텍처의 가장 큰 장점은 비동기 이벤트 처리를 통해, 트랜잭션을 가볍게 가져가며, 반드시 처리되어야하는 후속 이벤트 처리들을 남겨둠으로써 사용자에게 보다 더 빠른 지연시간을 제공해줄 수 있다는 장점을 가진다. EDA가 적합한 경우 하나의 이벤트에 대하여 여러개의 도메인이 반응해야하는경우. 다시말해, 주문 발행이라는 이벤트에 대하여 알림 도메인 , 광고 도메인 , 유저 도메인 등등 다양한 도메인에서 그 이벤트를 병렬적으로 처리해야하는 경우 적합하다. 서비스간의 통신에서 동기적으로 통신해야하는경우 (HTTP 요청 , gRPC 통신 , 다른 서비스의 응답값이 반드시 필요한)가 많은 경우에는 적합하지 않다. Ex) 유저에게 즉시 결제 성공과 결제 실패를 반환해줘야하는 경우. EDA = MSA ? 처음에는 EDA 와 MSA를 동일한 설계구조라고 생각했다. 🤔 당연히 MSA 마이크로 서비스 환경에서는 EDA가 강제되는 것 아닌가? 하지만 분명히 두 아키텍처 설계의 목표는 다르다는 것. EDA는 도메인간의 소통의 방식을 설계하고 , 도메인간의 결합을 Loosely하게 하기 위한 아키텍처 MSA는 서비스마다 서버를 독립적을 하나씩 구성해 서비스의 독립성을 높이고, 시스템 경계를 정확히 하는데에 목적이 있다. MSA를 통해 독립적인 서비스들의 확장을 가져갈 수 있다는 목적 또한 가진다. 그리고 MSA 마이크로 서비스에서 모두 EDA 를 통한 서비스간의 소통을 하는것은 아니라는것이다. 그 반대도 마찬가지이다. EDA도 모두 MSA로 독립된 서버에서 무조건 사용되는것이 아니라 모놀리식 서버에서 도메인간의 처리를 비동기 이벤트 기반으로 처리할 수 있게 설계할 수 있다. 이 집합관계의 차이를 이해하게 되면 그 차이와 아키텍처의 목적이 다르다는 것을 알 수 있다. 하지만 결국 이 둘은 같이 가는 느낌이기는 하다. Message Broker EDA에서 필수 불가결하게 중요한 것이 이벤트들을 관리하는 기능을 추가해줘야한다는 것이다. 이 Message Broker 의 기능은 메세지 저장 및 이벤트 재발행 등의 책임들을 가진다. 이 Message Broker 의 대표적인 솔루션으로 언급되는것이 바로 RabbitQ, Kafka 이 두개이다. 그 중에서도 대규모 데이터 파이프라인에서 가장 주류를 이루는 것은 카프카. 카프카는 대용량 이벤트 스트림 처리, 메시지 보존 및 재처리, 수평 확장성의 장점을 가진다. Message Broker 의 책임 메시지 전달: Producer가 발행한 이벤트를 적절한 Consumer에게 전달 Producer–Consumer 결합도 감소: Producer는 누가 소비하는지 몰라도 됨 비동기 처리 지원: Consumer가 즉시 응답하지 않아도 메시지를 나중에 처리 가능 버퍼링: 순간적으로 이벤트가 몰려도 Consumer가 처리 가능한 속도로 소화할 수 있도록 완충 내구성 보장: 브로커에 따라 메시지를 디스크에 저장해 장애 후에도 재처리 가능 재전송 / 재처리 지원: Consumer 처리 실패 시 retry나 replay 가능 순서 보장: Kafka의 partition처럼 특정 범위 내 이벤트 순서를 보장할 수 있음 Consumer 분산 처리: 여러 Consumer 인스턴스에 메시지를 나눠 처리해 수평 확장 지원 Fan-out: 하나의 이벤트를 여러 Consumer가 각각 독립적으로 받을 수 있음