개발지식

이벤트 기반 아키텍처 (feat. 배달의민족 마이크로서비스 여행기)

우루쾅 2024. 3. 19. 18:53
728x90
반응형
SMALL

우아콘 2020 - 배달의 민족 마이크로서비스를 보던 중

이벤트 기반 아키텍처 부분에 흥미가 생겨 공부도 할 겸 정리를 해보았습니다!

 

API 기반 데이터 전달 방식의 문제

 

배달의 민족에서는 주문시스템에서 주문이 들어오면 아래의 순서대로 처리가 되는데

 

주문 생성 ▶ 접수 ▶ 배달완료 ▶ 리뷰 알림

 

예를 들어 리뷰 시스템은 리뷰를 작성해 달라는 푸쉬 알림을 위해 주문 완료 정보가 필요합니다.

이는 주문 시스템에서 리뷰 시스템으로 API를 전달해주어야하는데,

리뷰시스템 측 API 에서 timeout 또는 500 에러(내부서버 오류)가 발생하는 상황이 있을 수 있습니다.

 

장애의 전파를 막기위해 MSA 를 도입하였지만 연계가 되는 API들의 요청이 실패한다면 주문 시스템에도 영향이 갈 수 있습니다.

 

이에 대한 난점을 극복하기 위해 서버간의 메시지를 전달하는 미들웨어인 메시징 큐를 도입하고, 각각의 서버는 이벤트를 통해 소통하는 이벤트 기반 아키텍처를 구성합니다.

 

 

문제 해결

다른 어플리케이션에서 필요한 주문 정보를, 이벤트라는 이름으로 정의합니다.

이후 메시징 큐에 이벤트를 발행하면, 필요한 어플리케이션에서 해당 이벤트를 구독해갑니다.(pub-sub 패턴)

pub-sub 기반의 메시징 큐에는 Apache Kafka 등 다양한 종류가 있으며 해당 시스템에서는

발행자 역할로 AWS SNS(Simple Notification Service),

구독자 역할로 AWS SQS(Simple Queue Service)를 활용하였습니다

 

해당 구조에서 주문 시스템 프로세스를 다시 예시로 들어보겠습니다.

주문이 생성되는 시점에 SNS 에 해당 이벤트를 발행합니다.

리뷰 시스템은 SQS 를 활용하여 주문시스템이 이벤트를 발행하는 SNS를 구독하고 있다가, 이벤트를 수신하면 리뷰 알림을 전달해주는 방식으로 활용할 수 있습니다.

 

이 아키텍처에는 여러 장점이 있습니다

① 혹시나 리뷰 시스템이 다운되더라도, 향후 복구되었을 때 SQS 에 있는 이벤트를 재수신하여 처리할 수 있습니다.

② 주문 시스템에서 주문 생성이 실패하는 문제가 발생하면, 문제가 되었던 부분을 찾아 이벤트를 재발행 함으로써 문제를 해결할 수 있습니다.

③ 주문 시스템이 더이상 다른 시스템에 대해 자세히 알 필요가 없어집니다. 주문 이벤트를 발행하고 나면, 그 이벤트로 각 도메인에 특화된 비즈니스 로직을 수행하는건 각 시스템의 역할로 맡겨집니다.

 

위와 같은 방식을 통해 유사한 프로세스에 동일한 방식으로 다양하게 적용이 가능할 것으로 보입니다!

 

추가로 위 방식에서 사용한 AWS SNS(Simple Notification Service)와 SQS(Simple Queue Service)와 pub-sub 패턴에 대해서 살짝 맛만 봐보겠습니다

 

 

AWS SNS(Simple Notification Service)

AWS SNS 는 AWS에서 제공하는 푸시알림 서비스로, 애플리케이션 대 애플리케이션(A2A) 및 애플리케이션 대 개인(A2P) 통신에 사용되는 분산 pub/sub 시스템입니다.

 

발행자(Publisher)는 Topic에 대한 메시지를 게시(pub)하고 Consumer는 메시지를 수신하기 위해 이러한 Topic에 가입(sub)하여 발행자가 SNS에 메시지를 보낼 때 메시지가 구독자(Subscriber)에게 푸시가 됩니다.

 

AWS SQS 대기열, AWS Lambda 함수 및 HTTP endpoint와 같은 다양한 유형의 구독자(Subscriber)에게 메시지를 전송할 수 있습니다(A2A). 또한 SNS를 사용하여 end-user 장치에 SMS 메시지, 전자 메일 및 푸시 알림을 보낼 수 있습니다(A2P).

 

 

AWS SQS (Simple Queue Service)

AWS SQS는 마이크로서비스, 분산 시스템 및 서버리스 애플리케이션을 위한 완전관리형 메시지 대기열입니다.

SNS를 통해 전달된 메시지들을 안전하게 저장하고, 여러 컨슈머가 메시지를 처리할 수 있도록 합니다.

 

대부분의 메시징 미들웨어와 마찬가지로 SQS는 세 가지 주요 구성 요소로 구성됩니다.

SNS vs. SQS

▶ SNS와 SQS를 연계하여 사용할 경우

SNS와 SQS를 조합하면, 여러 SQS 큐에 동시에 메시지를 전달하는 팬아웃(Fan-out) 패턴을 구현할 수 있습니다.

이는 다음과 같은 방식으로 작동합니다.

 

① SNS 토픽을 생성합니다.(이벤트 발행)

② 여러 SQS 큐를 생성하고, 이들 큐를 SNS 토픽에 구독시킵니다.(이벤트 구독)

③ 메시지를 SNS 토픽에 발행하면, 구독한 모든 SQS 큐에 메시지가 전달됩니다.(이벤트 전달)

④ 각 SQS 큐는 독립적으로 메시지를 처리합니다.(이벤트 처리)

 

 SNS와 SQS 의 주요 차이점

● SNS는 A2A와 A2P 통신을 지원하는 반면, SQS는 A2A 통신만 지원합니다.

SQS가 큐잉 시스템인 반면, SNS는 pub/sub 시스탬입니다. 일반적으로 SNS 를 사용할 땐 Topic을 통해 여러 소비자에게 동일한 메시지를 보냅니다. 이에 비해 대부분의 경우에서 SQS 대기열의 각 메시지는 한 소비자에 의해서만 처리가 됩니다.

SQS를 사용하면 메시지가 긴 폴링(풀) 메커니즘을 통해 전달되는 반면, SNS는 푸시 메커니즘을 사용하여 가입된 엔드 포인트로 메시지를 즉시 전달합니다.

SNS는 일반적으로 실시간 알림이 필요한 애플리케이션에 사용되는 반면, SQS는 메시지 처리 사용 사례에 더 적합합니다.

SNS는 메시지를 지속하지 않습니다. 메시지를 존재하는 구독자에게 전달한 다음 삭제를 합니다. 이에 비해 SQS는 메시지를 지속할 수 있습니다.(1분에서 14일)

 

SNS SQS
Topic(Pub/Sub) Queue
A2A, A2P 통신 A2A 통신
Push : 사용자에게 메세지 전송 Pull : 사용자가 메세지를 가져온다
Fanout : 같은 메세지를 여러 방향으로 발행 Decouple : 여러 서비스로 분리하여 병렬식 비동기 처리
메세지를 받는 사용자가 없으면 몇 번 시도하다가 삭제된다. 메세지는 일정 기간동안 유지된다.
하나의 메세지를 사용자들이 각각 다른 방식으로 활용 하나의 메세지를 사용자들이 동일한 방식으로 활용

 

pub-sub 패턴

pub-sub 패턴은 발행구독 패턴으로도 풀리며 비동기 메시징 패러다임입니다.

발행자와 구독자가 있고, 그 사이에 브로커(=메시지큐)가 존재하는 형태입니다.

 

발행자(=pub)와 구독자(=sub)의 특징

① 발행자 메시지의 수신자가 정해져있지 않습니다.

② 수신자는 발행자에 대한 정보 없이, 원하는 메시지를 수신할 수 있습니다.

③ pub와 sub는 서로 선언 위치나 존재를 알 필요가 없습니다.

    ● pub는 메시지 큐와 같은 브로커 역할을 하는 중간 지점에 메시지를 던져 두기만 하면, 브로커가 알아서 처리합니다.

    ● sub는 브로커에 할당된 작업만을 모니터링하고, 원하는 작업이 발생하면 할당받아 작업을 수행하면 됩니다.

 

그러므로 pub과 sub은 서로 알 필요가 없으며, 브로커와의 통신만을 잘 수행하기만 하면 됩니다.

 

브로커

주로 메시지큐가 브로커로서의 역할을 수행하며, 두 객체 사이에서 구독과 발행 이후의 메시지를 처리해줍니다.

즉, 브로커가 모든 들어오는 메시지를 필터링하며, 타켓들(=구독자)에게 메시지를 배포하는 역할을 합니다.

 

메시지 큐

메시지 큐는 프로세스나 프로그램 인스턴스가 데이터 상호 교환 시 사용하는 통신 방법입니다.

메시지 지향 미들웨어(MOM = Message Oriented Middleware)를 구현한 시스템을 의미하며, 비동기 메시지를 사용하는 응용 프로그램 간 데이터 송수신을 의미합니다.

 

 

 

출처

기록하는 습관 - https://dev-minjeong.tistory.com/39

refactoring.guru - https://refactoring.guru/ko/design-patterns/observer

Go devlog - https://gobae.tistory.com/122

웨지의 개발 블로그 - https://sihyung92.oopy.io/architecture/woowa-msa-travel#30fc0e0ce15c4235a1f90f347da324a6

[우아콘2020] 배달의민족 마이크로서비스 여행기 - https://www.youtube.com/watch?v=BnS6343GTkY&t=1366s

728x90
반응형
LIST