[MSA] 이벤트 기반 아키텍처(EDA)의 이유와 바람직한 설계

데이터 통신 구조 - EDA의 이유

여러 마이크로서비스로 분리된 서버들의 통신은 불가피하다.

 

서비스 내의 통신 구조, 서비스 간의 통신 구조는 유연성, 확장성, 효율성에 영향을 미치게 된다.

 

시나리오 #1

한 팀에서 새로운 비즈니스 요건을 구현하면서 두 방법을 고민한다.

 

• 기존 프로젝트에 추가한다

이 상황에서 빠르고 쉬운 방법일 것이다.

 

이미 필요한 데이터가 모두 연결되어 있고, 로깅, 모니터링, 배포, 롤백 프로세스 등 여러 환경이 구축되어 있다.

 

하지만 새로운 기능을 구현하면서 기존 코드와 엮이며 구현체 내부 경계가 모호해질 수 있다.

 

결합도는 올라가고 응집도는 떨어지는 것이다.

 

• 새로운 서비스로 구현한다

확장성을 생각한다면 모듈화한 독립적인 시스템이 더 좋아보이기도 한다.

 

새로운 기능은 옛 데이터도 참조해야 하는데, 기존 서비스에 데이터가 묶여있다.

 

이 데이터를 저장소로 복사할 방법이 필요하고, 그 과정에서 내부 로직이 노출되지 않도록 신경써야 한다.

 

또한 복사 과정에서 과도한 부하, 동기화 실패, 의존관계 발생, 잘못된 데이터 사용 등 여러 문제점이 생길 수 있다.

 

데이터를 어떻게 복사하더라도, 김빠진(stale) 데이터가 되지 않도록 동기화 작업이 필요하다.

 

 

이벤트 기반 통신 구조

위 시나리오에서 결합도와 확장성을 고려하여 새로운 서비스를 구축하려고 했지만, 데이터와 관련된 여러 문제들이 있다.

실제로 나도 MSA 프로젝트를 설계하며 정말 많이 고민했던, 마이크로서비스의 데이터는 여러가지를 고려해야 한다.

 

• 어떤 서비스가 어떤 데이터를 소유해야 하는지?
• 데이터는 어디에 두어야 하는지?
• 두 서비스가 모두 값을 변경하는 데이터는 어떻게 처리해야 하는지?

 

이벤트 기반 통신은 기존의 구현/데이터 통신 구조의 대안이다.

 

당시 MSA를 잘 몰랐던 시절에 열심히 구글링해서 구현한 아키텍처인 이벤트 기반 아키텍처로 해결했다.

 

이벤트 스트리밍 방식은 데이터 생산/소유와 데이터 접근이 철저하게 분리되기 때문에

서비스는 더이상 직접 요청-응답 API에 얽매이지 않고, 이벤트를 통해 소통한다.

 

Producer는 그저 이벤트 스트림에 잘 정의된 데이터를 생산하기만 하면 된다.

이벤트 받아서 알아서 써

 

다른 서비스에서 관심 있는 데이터를 공용 이벤트 스트림 세트에 발행함으로써 데이터의 생산과 소유권을 완전히 분리한 것이다.

 

느슨한 결합과 높은 응집도를 준수할 수 있게 됐다.

 

또한, Producer와 Consumer는 Pub/Sub 구조로 연결되어 있기 때문에 해당 데이터가 필요한 새로운 서비스/기능은 언제든지 이벤트를 구독해서 사용하고, 원하는 데이터만 추출해서 사용하면 된다.

 

 

비동기식 이벤트 기반 마이크로서비스

비동기식 이벤트 기반 아키텍처의 중요한 이점들을 정리해 보겠다.

 

• 세분성(granularity) :서비스가 경계 컨텍스트에 알맞게 매핑, 요건이 바뀌어도 쉽게 재작성 할 수 있음
• 확장성(scalability) : 필요 시 규모를 늘리거나 줄일 수 있음
• 기술 유연성(technological flexibility) : 서비스마다 필요한 언어, 기술로 구현할 수 있음
• 비즈니스 요건 유연성(business requirement flexibility) : 단위가 작은 서비스는 요건 변화에 신속하게 대응할 수 있음
• 느슨한 결합(loosely coupling) : 어떤 특정한 구현 API에 구애받지 않음.
• 지속적 전달 지원(continuous delivery support) : 옮기기 쉽고 간편하게 롤백할 수 있음.
• 우수한 시험성(high testability) : 규모가 큰 모놀리스보다 의존성이 적어 테스트 커버리지 유지가 쉬움.

 

경계 컨텍스트간 느슨한 결합 - EDA의 설계

DDD에서 등장하는 개념인 경계 컨텍스트(Bounded Context)는 논리적으로 한 개의 모델을 가지며, 각 모델의 경계를 결정한다.

 

경계 컨텍스트는 응집력이 강해야하고, 경계 컨텍스트끼리는 느슨하게 결합되어야 한다.

 

응집도는 높게, 결합도는 낮게

 

평소 아키텍처, 개념 공부를 할때 자주 듣는 말이다. 

 

그렇다면 이 경계 컨텍스트는 어떤 기준을 중심으로 정해야 할까?

 

 

경계 컨텍스트 : 기술 요건 vs 비즈니스 요건

만약 쇼핑몰 서버를 개발한다고 가정해보자. 기술 요건 또는 비즈니스 요건 중심으로 경계 컨텍스트를 결정하려고 한다.

 

 

어떤 프로덕트에 대한 비즈니스 요건은 수시로 변경된다.

 

반대로, 비즈니스 요건 변경 없이 제품의 근본적인 구현체를 뜯어고치는 경우는 거의 없다.

 

경계 컨텍스트를 기술 요건이 아닌 비즈니스 요건 중심으로 정해야 하는 이유이다.

 

팀별로 비즈니스 요건에 따라 나누고, 느슨하게 결합하여

응집된 마이크로서비스를 구축하여 각 팀별 요건에만 전념할 수 있는 환경이어야 한다.

 

만약 경계를 기술 요건에 맞추게 된다면, 여러 경계에 걸쳐 비즈니스 기능을 수행할 책임이 여러 팀으로 분산된다.

 

한 기능을 개발하려면 팀별로 다른 스케줄로 진행해야 하는 비효율적인 상황이 일어나게 되는 것이다.

 

 

 

위 그림과 같이 비즈니스 요건에 따른 경계 내에서

각 서비스가 코드, DB등 자신의 레이어를 알아서 책임지는 각자 소유(sole ownership) 구조가 바람직하다.

 

여기서 코드가 중복되거나 비슷한 패턴이 나올 수도 있는데, (실제로도 그랬다)

장기적인 관점에서는 데이터 소스를 공유하거나 경계를 연결하는 것 보다 로직을 반복하거나 비슷한 데이터를 저장하는게 훨씬 낫다.

 

 

 

 

 

참고
Building Event-Driven Microservices: Leveraging Organizational Data at Scale, 애덤 벨메어