EDA 간단정리

EDA란 Event Driven Architecture로 Event Sourcing을 기반으로한 아키텍쳐이다.

일반적으로는 Persistence Database를 사용해서 Sync하게 Request를 받고 Processing을 한후 Response를 주는 Flow 였다.

 

이와 달리 EDA에서는 Request가 들어오면 Queue 에  Event를 Produce 한 후 Consume Service가 이를 처리하는 방식이다. Event 관리를 위한 데이터베이스가 존재하며 실제 Domain DB에는 가장 최신 Version의 이벤트가 들어간다.

 

EDA를 사용하면 서비스간 강결합이 낮아지고 서비스간 응집도가 올라가며  데이터 정합성 undo에 대해 관리하기 용이해지고 이벤트에 대해서 일괄 연산도 가능하며, 오류가 나더라도 Queue에 남아 있기 때문에 일관성이 높아진다. 즉 고가용성이다. 

 

EDA는 그럼 무조건 좋은 것인가?
EDA는 디버깅 및 관리가 어려우며, 데이터 일관성이 Eventually Consitency를 갖고, 메세지 브로커에 대한 의존, 그리고 잘못된 이벤트 혹은 중복 이벤트에 대한 관리가 필요하다.

 

따라서 비즈니스가 위험도와 복잡성이 높다면 Persistnce Database 방식을 사용하면서 성능을 위해서 Scaling을 하는 것도 하나의 좋은 방법일 것이다. 

무조건 간단할 수록 좋다. 단 돈이 많이들 수 있다.

추가로 EDA를 통해 CSRF를 구현할 수 있는데

MSA상에서 여러 도메인들이 서로 다른 데이터베이스를 사용하고 도메인들간 Join이 필요할때 
각 서비스에서 필요한 정보를 호출해서 집게하는 Aggregation API Pattern이 가능하다.

하지만 이러한 방식은 간단하지만 많은 API, DATABASE를 호출하기 때문에 서버와 데이터베이스에 부하가 생기기 쉽다.

따라서 Query용 서비스를 따로 만들고 EDA에 생기는 이벤트를 통해 데이터를 쌓아 Query하는 방식이 CSRF이다.

따라서 Query용 서비스는 다른 데이터베이스를 사용하고 이미 정보들이 집계되어 있기때문에 부하분산도 줄어들 것이다.

이는 MSA 철학이 부합하다. 

하지만 해당 도메인에대한 Command는 Write Service에서 진행시켜야한다.