04 데이터 정합성 - Event-Driven Architecture

1. Note

• 추상화 + 스프링이랑 비슷한 느낌으로 바라봐야할듯
  • 명시되거나 보이지는 않지만, 큰 시스템내에서 뭔가 각기 역할이 존재하고 있고
  • 그 틀들을 구성해주면, 시스템별로 알아서 그것들을 작동하는 구조.
• A,B,C 서비스가 순서대로 흐를때
  • A,B,C는 서로의 존재와 역할을 모름,
  • 그냥 단지 누군가 입력해놓은 이벤트가 있다면,
  • 그것을 처리할뿐.

2. Event-Driven Architecture

1. Event-Driven Architecture 개념

• 서비스 간 통신을 이벤트(Event) 기반으로 처리하는 아키텍처 방식
• 서비스가 직접 호출하지 않고 이벤트를 발행(Publish)하고, 필요한 서비스가 이를 구독(Subscribe)하여 처리
• 서비스 간 직접 호출을 줄이고, 이벤트를 통해 느슨하게 연결(Loose Coupling)하는 것
  • 서비스 독립성 향상
  • 확장성 증가
  • 비동기 처리 가능

2. 동기/비동기 구조

• 기존 동기 호출(Synchronous) 방식
  • 요청을 보낸 서비스가 상대 서비스의 응답을 받을 때까지 기다려야함
  • 각 서비스는 이전 작업이 완료될 때까지 대기해야 하며,
  • 중간 서비스 장애가 전체 흐름에 영향을 줄 수 있음
• 비동기 구조
  • 서비스 간 결합도 감소 / 이벤트만 발행하고, 그 이후 처리는 이벤트를 구독하는 서비스가 담당
  • 장애 전파 최소화 / 이벤트가 메시지 브로커에 저장, 특정 서비스가 문제가 생겨도 티켓보고 처리함.
  • 응답 속도 향상 / 응답을 기다리는 시간이 줄어 처리속도가 빠름
  • 확장성 향상 / 기존 로직 변경 없이 Consumer만 추가하면 서비스 확장이 가능함.

3. 주요 구성요소

1. 체크 포인트

• 협력 구조

  Producer   # 비즈니스 로직 수행
  ↓
  Event      # 이벤트 생성
  ↓
  Message Broker  # 이벤트 저장 및 전달
  ↓
  Consumer   # 이벤트 구독 후 처리
  

• Producer / Consumer는 “서비스 기준”이 아니라 “이벤트 기준 역할”
• 비즈니스로직에 따라
  • 첫 로직은 Producer 역할 확률이 높고
  • 두번째부터는 Consumer / Producer 역할 확률이 높고
  • 마지막은 Consumer 역할 확률이 높음
  • 고정은 아님!

2. Event

• 시스템 내부에서 발생한 상태 변화 또는 행동 사실

  OrderCreated # 주문생성
  PaymentCompleted # 결제완료
  InventoryFailed # 재고 증가/감소 실패
  UserRegistered # 유저등록
  

• 과거형 느낌(?)으로 표현됨 / 작업 결과 묘사가 가까운 것 같음

  • Request 표현 -> Event 표현
  • 주문을 했으니 결제해줘 -> 주문을 완료 했음 (오더 서비스)
  • 결제 완료했으니 재고 차감해줘 -> 결제 완료 했음

3. Producer

• 이벤트를 생성(Publish)하는 주체

• 비즈니스 작업을 먼저 수행하고, 그 결과로 이벤트를 발행

  Order Service # 비즈니스 로직을 수행하고
  ↓
  OrderCreated Event # 이벤트를 발행
  

• 전체 적인 흐름이 하나 있고 그안에서 캡슐화되서 자신의 일만하는 느낌

4. Consumer

• 이벤트를 구독(Subscribe)하고 처리하는 주체

• 특정 이벤트 발생 시 반응하여 작업을 수행하는 역할

  OrderCreated Event # 이벤트 생성( 프로듀서 )
  ↓
  Payment Service 수신 # Payment Service는 ORderCreated 이벤트 구독 중, 변화확인
  ↓
  결제 처리 #비즈니스 로직 실행
  

5. Message Broker

• Producer와 Consumer 사이에서 이벤트를 전달하는 중개 시스템

• 이벤트를 안전하게 저장하고 전달하는 역할

  Producer #프로듀서가 이벤트 생성
  ↓
  Message Broker # 메시지 브로커가 저장 / 전달
  ↓
  Consumer # 컨슈머는 소비
  

4. Event-Driven Architecture 특징

1. 비동기(Asynchronous) 처리

• EDA는 서비스 간 작업을 비동기적으로 처리

• 응답 대기 시간이 줄어들고 시스템 처리 효율이 향상될 수 있음

  OrderCreated Event 발행
  ↓
  즉시 종료 # Order
  ↓
  Payment Service가 별도 처리
  

2. 느슨한 결합 (Loose Coupling)

• 특정 서비스가 다른 서비스를 직접 의존하지 않음

• 서비스 변경이나 확장이 다른 서비스에 미치는 영향을 줄일 수 있음

  OrderService에서 OrderCreated Event 발행
    
  Payment Service는 
   - OrderService가 아니라 
   - 이벤트를 구독함. 
  

3. 확장성(Scalability)

• Consumer를 독립적으로 확장하기 쉬움

  OrderCreated Event
  ├─ Payment Service # 구독자 1
  ├─ Notification Service # 구독자 2
  └─ Analytics Service # 구독자 3
    
  # 새로운 서비스가 등장하면 추가로 구독하게 하면됨
  

4. 최종 일관성(Eventual Consistency)

• 즉시 일관성(Strong Consistency)보다 최종 일관성(Eventual Consistency)

• 흐름

  Order 완료       # DB 반영
  Payment 처리 중  # DB 작업중
  Inventory 미처리**** # 작업대기로 데이터가 다름
  

5. 장점과 단점

구분	내용
장점	서비스 간 결합도가 낮음(Loose Coupling) 비동기 처리 가능 기존 서비스 수정 없이 Consumer 추가 가능하여 확장성 높음 일부 서비스 장애가 전체 시스템 장애로 전파될 가능성 감소
단점	이벤트 흐름 파악이 어려움 분산 환경 특성상 디버깅 및 장애 추적 복잡성 증가 즉시 일관성(Strong Consistency) 보장이 어려움 메시지 중복 및 순서 문제 고려 필요

6. Event 기반 전체 흐름

1. 성공 흐름

  Order Service # Order 컨텍스트
  ↓
  OrderCreated Event # 브로커
  ↓
  Payment Service # Payment 컨텍스트
  ↓
  PaymentCompleted Event # 브로커
  ↓
  Inventory Service # Inventory 컨텍스트
  ↓
  InventoryCompleted Event # 브로커

2. 실패흐름 Choreography

  Order Service # Order 컨텍스트
  ↓
  OrderCreated Event # 브로커
  ↓
  Payment Service # Payment 컨텍스트
  ↓
  PaymentCompleted Event # 브로커
  ↓
  Inventory Service # Inventory 컨텍스트
  ↓
  InventoryFailed Event # 실패 이벤트 발행
  ↓
  Payment Service # 결제 취소 보상 트랜잭션 ( saga Pattern )
  ↓
  PaymentCanceled Event 발행 # 결제 실패 이벤트 발행
  ↓
  Order Service # 주문 취소 종결