📌 개요

최근 링크드인을 보다가 그런 글을 보았다.

내 프로젝트를 남에게 알리는 가장 좋은 방법은 과정을 정리하는 것이다.

(어떤 분이신지 정말 샤라웃 드리고 싶지만, 정말 내 기억 속에만 남아있고 열심히 찾아도 찾을 수가 없었다 ㅠㅠ)

암튼 이 글을 보고 나는 개발을 처음 접했던 시절에 보았던 블로그가 떠올랐다.

이분은 당시 자신이 진행하는 프로젝트 과정을 하나하나 올리셨는데, 개발 응애였던 나에게는 스프링 MVC를 이해하는데 큰 도움이 됐던 시리즈 중에 하나였다.

링크드인의 말을 듣고 생각을 해보니, 난 단 한순간도 기술을 선택하거나ㅡ 아키텍처를 설계함에 있어서 근거를 충분히 정리하지 않았던 것 같다.
그렇다보니 면접의 "왜 그렇게 하셨나요?" 와 같은 질문에서 항상 준비된 답변만을 말하게 되었던 것 같다. 나 조차도 정리가 되지 않았는데 남에게 어떻게 이를 설명할 수 있을까?

그래서 생각했다. 이번에 진행하는 프로젝트는 과정을 모두 담기로.

🎿 이벤트 기반 아키텍처

먼저 이번에 진행할 프로젝트는 이벤트 기반 아키텍처이다.
아무래도 가장 큰 근거는 공부고, 특히 이전의 MSA 프로젝트가 온전치 않는 MSA 프로젝트였다는 것이 마음에 걸렸었기 때문이다.

그럼 이제 이벤트 기반 아키텍처는 어떤 원칙을 지키는 것이 중요한지 알아보자.
다양한 원칙이 존재하지만, 내가 생각한 주요 원칙은 다음과 같다.

1️⃣ 명령 쿼리 책임 분리(CQRS)

CQRS 는 시스템이 읽기 및 쓰기 작업을 개별 구성 요소로 분리하는 패턴입니다. 쓰기 측은 상태 변경을 나타내는 이벤트를 내보내고 읽기 측은 이러한 이벤트를 수신하여 뷰 모델을 쿼리하고 빌드합니다. 이러한 분리를 통해 각 측면은 서로 다른 성능 요구 사항에 따라 독립적으로 확장하고 리소스 사용을 최적화할 수 있습니다.

2️⃣ 애그리게이터

Aggregator 패턴에는 서로 다른 소스의 여러 이벤트를 소비하고 처리하며 원래 이벤트의 집계를 나타내는 단일 이벤트를 생성하는 구성 요소가 포함됩니다. 이 패턴은 집계된 데이터를 다른 시스템 부품으로 전송하기 전에 이벤트 노이즈를 줄이거나, 요약을 만들거나, 다른 시스템 구성 요소의 정보를 통합할 때 유용할 수 있습니다.

3️⃣ 체이닝

연결 패턴에서 한 구성 요소에서 발생하는 이벤트는 하나 이상의 구성 요소에서 이벤트 체인을 트리거하여 결국 원하는 상태 변경 또는 작업으로 이어집니다. 이 패턴을 사용하면 관련된 구성 요소를 긴밀하게 결합하지 않고도 복잡한 워크플로를 구축할 수 있습니다. 연결은 직접 이벤트 기반 통신을 사용하거나 메시지 큐 및 서비스 버스와 같은 미들웨어를 통해 구현할 수 있습니다.

📍 결론

해당 원칙을 지키기 위해서 다음과 같이 설계해야겠다고 생각했다.
1. 가격 수집만을 위한 서비스 생성 (읽기)
2. 김프 계산을 위한 서비스 생성 (쓰기, Aggregator 패턴)
3. 각 마이크로서비스들이 메시지로 통신
4. Kafka를 메시지 브로커로 사용

따라서 내가 설계한 아비터(arbit-er) 프로젝트의 아키텍처는 다음과 같다.

1. 가격 수집(읽기)과 김프 계산(쓰기)를 분리하여 CQRS 패턴을 적용한다.
2. 어그리게이터 서비스는 김프를 계산한 후 소켓 통신을 통해 클라이언트에게 전송
3. 추가적으로 알림 서비스에도 해당 김프 메시지를 발행
4. 수신한 알림 서비스는 멤버가 각자 설정한 임계값을 넘어서는 김프가 수신되는 경우, 그 멤버에게 알림 전송

이렇게 설계 시, 이벤트 기반 아키텍처의 원칙을 지킬 수 있게 되었다.