◽ 서론
뭐 요청을 10,000번째 보내면 당첨되는 이벤트인가?!
사람들은 누구나 어디에서나 시공간을 제약받지 않고 통신하는 시대가 왔다.
그만큼 수많은 트래픽을 서버는 감당해야된다.
'대용량 트래픽 처리'는 백엔드 개발자의 디폴트 능력이 된 시대다.
대용량 트래픽하면 꼭 듣는 단어..
"이벤트 형식으로 처리해보셨나요?"
"Event Driven 구조는 뭔지 알고 있나요? 혹시 구현해보신 적은...?"
"그럼 Domain – Driven – Design가 뭔지는 알고 계신가요...?"
아뇨... 이제 해봐야죠...ㅠㅠㅠㅠ
❓ 이벤트(Event)
시스템(또는 도메인)에서 발생한 의미 있는 상태 변화나 사건
주문 도메인
• 주문이 생성됐다 (OrderCreated)
• 주문이 취소됐다 (OrderCancelled)
• 결제가 완료됐다 (PaymentCompleted)회원 도메인
• 회원 가입 완료 (MemberRegistered)
• 비밀번호 변경 완료 (PasswordChanged)게시글 도메인
• 글 작성 완료 (PostPublished)
• 댓글 달림 (CommentAdded)이런 느낌이다.
◽ Micro Service Architecture (MSA)
하나의 애플리케이션을 '독립적으로 배포 가능한 서비스 단위'로 분할.
서로 간의 변경과 조합이 가능하도록 이루는 구조
내가 가장 최근에 했던 프로젝트인데,
서버를 기본 API 서버(8080)와 웹소켓을 담당하는 채팅 서버(8081)로 분할했다.
이러한 구조를 MSA라고 한다.
장점
1) 부하분산에 유리하다.
웹소켓은 양방향 통신이라 네트워크 소스를 많이 잡아먹는다. 그럼 서버를 증설해야 된다.
기존의 모놀리식 아키텍처는 서버를 증설하게 되면, 기본 API들도 같이 증설되게 된다.
저런 MSA 구조 형태면 딱 채팅만 늘어나게 하면 되는거 아닌가?
2) 서버간 의존성이 낮아짐
만약에 채팅 기능이 고장났다고 가정하면?
기본 API 서버는 정상적으로 서비스가 된다. 그럼 이때 채팅 서버를 조치하면 된다.
단점
1) 개발하기 힘들다
당연히 개발하기가 복잡하다...
깃 레포도 "모노로 해야되나? 멀티로 해야되나?" 부터 걸리게 되고,
중간에 DB는 어케해야 할지, 토큰은 어떻게 처리해야할지? 등등 많은 것을 생각해야 된다.
근데 데브코스를 할 당시에, MSA를 어케 설계해야할지 고민 도중...
"이벤트 형식으로 해보는건 어떤가?" 라고 멘토님께서 추천해주셨다.
◽ MSA와 이벤트
분산 아키텍처다 보니, 서비스(프로세스)간에도 통신이 필요하다.
IPC(Inter Process Communication) - 프로세스 간 통신
프로세스들 사이에 서로 데이터를 주고받는 행위 또는 그에 대한 방법이나 경로
예시)
HTTP/REST API, Message Queue (MQ), GraphQL, 이벤트 기반 통신
gRPC - 구글이 만든 고성능 바이너리 기반 RPC 프로토콜
◽ 왜 Event Driven인가?
Event Driven은 IT 영역에서 오래 사용된 키워드이며, 현재도 그 영향력이 대단하여 2018년 Gartner에서 선정한 유망한 기술 트렌드 중 하나로 뽑히기도 했다.
(Top 10 Strategic Technology Trends for 2018: Event-Driven Model)
결론부터 말하면, 현대 서비스에 가장 잘 맞는 방식이기 때문이다.
1. 서비스간 의존성 문제 (feat. 장애 전파)
요즘은 주문, 결제, 배송, 알림 등 서비스가 수십 ~ 수백개가 있다.
애네들을 REST로 다 붙이면, 결합 지옥 & 장애 전염 등이 발생한다. 🥵🥵
MSA로 일단 서비스를 분리시켜 놓으면, 장애 격리가 쉽다.
(장애가 발생한 서비스만 고치면 되기 때문)
2. 트래픽 폭증 (feat. 비동기)
게다가... 수백만 명이 동시에 사용해버리니, 트래픽 폭증 현상도 많아지고 있다.
Event Driven의 특징 중 하나가, 비동기 방식이다.
그냥 이벤트만 Message Queue(MQ)에 던저놓고 "야 Event 발행했어. 처리해줘!" 라고 넘겨버리기 때문이다.
3. 빠른 기능 추가
"이벤트만 던지면, 누가 그걸 듣든 상관 없음."
새 기능 추가해도 기존 서비스 코드 안 건드린다.
→ 팀 간 협업 구조와 궁합 좋음
이러한 Event Driven을 아키텍처 수준에서 활용하는 방식을 EDA 라고 한다.
Event Driven Architecture (EDA)
서비스들이 Event를 주고받으며 동작하게 하는 구조
◽ EDA는 어떻게 작동하는가?
이벤트 기반 아키텍처는 일반적으로
Event (Publish / Subscribe), Broker(Event Bus)로 구성된다.
Broker: Kafka, RabbitMQ 등
1. Message (Publish / Subscribe)
이벤트가 생성되면 Sub(수신자)에게 전달한다.
이벤트는 반복되어 전달되지 않으며, 수신자는 송신자의 정보를 알 필요 없다.
2. Event Source
Event Processor 에게 이벤트를 전달하는 역할이다
Event Source 는 1개 이상일 수 있으며, 1개 이상의 Event Proceesor 에게 전달한다.
3. Event Processor
수신된 이벤트에 대한 여러 action 을 수행하는 역할이다.
4. Event Consumer
이벤트에 대한 처리를 담당.
실질적인 비즈니스 로직을 수행한다.
