214. 이벤트 드리븐 아키텍처 (EDA) - Event-Driven Architecture 비동기 메시지 통신 카프카 이벤트 브로커 마이크로서비스 느슨한 결합 시스템 반응성

핵심 인사이트: (213번 MSA 심화) MSA로 쇼핑몰을 쪼갰다 치자. 결제 서버가 배송 서버한테 "결제 끝났으니 배송 시작해!"라고 다이렉트(HTTP/REST)로 명령을 때렸다. 근데 배송 서버가 뻗어 있으면? 결제 서버도 대답을 기다리다 무한 대기(Timeout)에 걸려 같이 뻗어버리는 도미노 붕괴가 터진다. "야! 서버들끼리 1:1로 직접 멱살 잡고 대화(동기 통신)하지 마! 회사 중앙에 거대한 우체통(카프카 이벤트 브로커)을 하나 세워! 결제 서버는 그냥 '결제 완료 이벤트 발생함!'이라는 쪽지만 우체통에 휙 던져놓고 1초 만에 지 할 일 하러 떠나(비동기)!! 배송 서버는 자기가 살아있을 때 우체통에서 그 쪽지를 주워가서 천천히 일하면 되잖아!!" 수천 대의 서버 결합도를 제로(0)로 박살 낸 궁극의 쿨가이 뼈대, EDA다.

Ⅰ. 동기(Synchronous) 통신의 끔찍한 병목과 결합도

  • MSA 환경에서 컨테이너들이 REST API(HTTP)로 통신하면 **동기식(Synchronous)**이 됩니다.
  • 내가 A 서버를 불렀으면, A가 일 처리를 끝내고 "완료 됨" 응답을 줄 때까지 나는 아무것도 못 하고 멍때리고 멈춰 서서 기다려야 합니다. (강한 결합도, Blocking 발생). A가 죽으면 나도 연쇄적으로 뻗습니다(Cascading Failure).

Ⅱ. 이벤트 드리븐 아키텍처 (EDA)의 개념 🌟

  • 개념: 분산된 시스템 모듈들이 서로를 직접 호출하지 않고, 어떤 상태의 변화(Event, 예: '주문 생성됨', '재고 소진됨')가 발생하면 그 이벤트 메시지를 중앙 브로커(메시지 큐)에 던져놓고(비동기 Asynchronous), 이 이벤트에 관심 있는 다른 놈들이 알아서 낚아채어 묵묵히 자기 할 일을 수행하게 만드는 반응형 아키텍처 패턴입니다.

Ⅲ. EDA를 굴리는 3대 핵심 엑조디아 🌟 핵심 기출 🌟

208번 브로커 패턴의 진화형입니다. (1038번 MQTT와 똑같은 Pub/Sub 뼈대)

1. Event Producer (이벤트 생산자) - "소문 내는 놈"

  • 결제 마이크로서비스입니다.
  • 고객이 결제를 누르면 돈을 빼고, **"주문 번호 101번 결제 완료됨!" 이라는 작은 텍스트 쪽지(이벤트)**를 중앙 우체통(브로커)으로 툭 던집니다.
  • 생산자는 이 쪽지를 누가 주워갈지 1%도 관심 없습니다. 그냥 던지고 0.1초 만에 자기 본업(다음 결제 대기)으로 쿨하게 돌아갑니다.

2. Event Broker (이벤트 브로커/메시지 큐) 🌟 아키텍처의 심장 🌟

  • Kafka(아파치 카프카), RabbitMQ 같은 거대한 전사적 우체통(이벤트 버스) 장비입니다.
  • 생산자가 던진 수백만 개의 쪽지를 절대 잃어버리지 않고 토픽(주제별)으로 분류해서 줄을 세워 보관(Queueing)하는 절대 죽지 않는 무적의 댐입니다.

3. Event Consumer (이벤트 소비자) - "알아서 주워 먹는 놈"

  • 배송 마이크로서비스, 포인트 적립 마이크로서비스입니다.
  • 이놈들은 평소에 브로커 우체통을 쳐다보며 "결제 완료" 칸을 구독(Subscribe)하고 있습니다.
  • 우체통에 쪽지가 툭 떨어지면, 배송 서버도 쪽지를 복사해 가고 포인트 서버도 쪽지를 복사해 가서, 각자 자기 서버 구석에서 묵묵히(비동기로) 택배를 싸고 포인트를 적립합니다. 생산자(결제 서버)가 시킨 게 아닙니다! 스스로 반응(React)한 것입니다.

Ⅳ. 왜 EDA가 현대 클라우드의 지배자인가?

  • 극강의 느슨한 결합 (Loose Coupling): 배송 서버(Consumer)가 트래픽 폭주로 3시간 동안 불타서 죽었습니다.
  • 기적의 결과: 결제 서버(Producer)는 배송 서버가 죽었는지 관심도 없습니다. 결제는 평소대로 0.1초 만에 쭉쭉 성공하고, 브로커 우체통에 "결제 완료" 쪽지만 계속 산더미처럼 쌓여갑니다. 3시간 뒤 배송 서버가 고쳐져서 부팅되면? 우체통에 쌓여있던 밀린 쪽지를 그제야 하나씩 주워가며 택배를 싸기 시작합니다. 서버 하나가 죽어도 다른 서버가 1도 피해를 받지 않는 완벽한 격리와 단절의 미학입니다.

📢 섹션 요약 비유: 기존 마이크로서비스의 REST API(동기 통신) 방식은 주방(결제 서버)에서 요리가 끝나면 요리사가 홀 서빙 직원(배송 서버)을 직접 붙잡고 **"야! 이거 3번 테이블로 배달해!"라고 명령한 뒤, 직원이 배달을 끝내고 돌아올 때까지 요리사가 요리를 멈추고 멍때리며 기다리는 미친 비효율(강한 결합, 동기 대기)**입니다. 서빙 직원이 화장실에 가면 요리사도 뻗어버립니다. **이벤트 드리븐 아키텍처(EDA)**는 요리사와 서빙 직원 사이에 **'거대한 음식 배출구 선반(Kafka 이벤트 브로커)'**을 하나 설치한 기적입니다. 요리사는 햄버거가 완성(이벤트 발생)되면 그냥 선반 위에 햄버거(메시지 쪽지)를 툭 올려놓고 종을 '땡!' 친 뒤, 뒤도 안 돌아보고 바로 다음 햄버거를 굽기 시작합니다(비동기 통신, 쿨가이). 홀 서빙 직원은 자기가 짬이 날 때마다 선반 위에서 햄버거를 알아서 집어 가 배달합니다(이벤트 소비). 서빙 직원이 뻗어서 선반에 햄버거 100개가 밀려 쌓여도, 요리사는 1초의 딜레이도 없이 계속 요리만 뽑아낼 수 있는, 시스템 간의 대기와 의존성을 0%로 박살 내버린 궁극의 논스톱 공장 라인입니다.