[MSA] Event Sourcing, Event Driven, Event Driven Architecture

Welcome to Seoyun Dev Log·2024년 11월 29일
0

[MSA] 펌뱅킹 결제 프로젝트

목록 보기
1/1

이벤트

이벤트를 발행(produce)하고 비동기 방식으로 필요한 곳에서 consume 한다

발생(produce)는 누락될 가능성이 거의 없다 (성공률이 높다)
이벤트 자체만으로는 어떤 도메인과도 직접적인 의존성이 없는 느신한 결합을 가능하게 만든다

1. Event Sourcing

Event Sourcing는 데이터 상태를 저장하는 대신, 시스템의 상태 변화를 나타내는 이벤트들의 순서를 기록하고 이 기록을 기반으로 현재 상태를 재구성하는 방법론입니다.

  • 핵심 개념:
    데이터의 상태 변경이 이벤트로 저장됩니다.
    시간 순서로 저장된다.
    모든 상태는 기록된 이벤트를 재생(Replay)하여 복원됩니다.
    이벤트는 이벤트 스트림으로 저장.

  • 특징:
    이력 관리: 시스템의 모든 변경 사항을 추적하고, 과거 상태를 복원할 수 있습니다.
    디버깅과 감사: 이벤트 로그를 통해 왜 특정 상태가 되었는지 추적 가능.
    Event Store: 전통적인 DB 대신 이벤트 저장소를 사용.

  • 사용 예:
    금융 시스템 (거래 기록 추적).
    비즈니스 규칙이 복잡한 도메인.
    이벤트 기반 시스템의 데이터 무결성 보장.

  • 장점:
    데이터 변경이력 추적과 감시에 유용하다.

은행 계좌
은행은 현재 잔액만 저장하는 것이 아니라, 모든 입출금 내역을 기록합니다.
예를 들어:

  • 잔액: 0원
  • 이벤트:
    2023-11-01 → 1000원 입금
    2023-11-02 → 500원 출금
    2023-11-03 → 200원 입금
  • 현재 잔액: 1000 - 500 + 200 = 700원
    여기서 중요한 점은 "현재 잔액을 따로 저장하지 않고, 입출금 기록만을 가지고도 잔액을 계산할 수 있다"는 것

쇼핑몰 주문 시스템
상황: 고객이 쇼핑몰에서 상품을 주문하고, 결제, 배송 등의 상태가 변하는 과정을 관리해야 합니다.

  1. 상태 변화 이벤트
    Event Sourcing에서는 주문 상태를 아래처럼 이벤트로 기록합니다:
  • 이벤트 기록:
    OrderCreated (주문 생성됨) → "주문 번호 1234, 고객: Alice, 상품: 책"
    PaymentCompleted (결제 완료됨) → "주문 번호 1234, 결제 금액: 20,000원"
    OrderShipped (배송 시작됨) → "주문 번호 1234, 배송 시작"
    OrderDelivered (배송 완료됨) → "주문 번호 1234, 배송 완료"
  1. 현재 상태 복원
    사용자는 이벤트를 재생(Replay)하여 현재 주문 상태를 재구성할 수 있습니다:
    주문 생성됨 → 결제 완료됨 → 배송 시작됨 → 배송 완료됨
    결과: 주문 상태 = "배송 완료"
  2. 장점
    이력 관리: 과거의 상태를 복원할 수 있음. (예: "주문이 배송 중이던 시점은 언제였지?")
    디버깅: 문제가 생긴 시점을 파악 가능. (예: "결제가 실패했었다면 왜 그랬을까?")
    복구: 특정 시점까지 상태를 되돌리기 쉽다.

2. Event-Driven

Event-Driven(이벤트 중심)은 이벤트를 중심으로 시스템이 동작하는 패턴으로, 이벤트가 발생했을 때 이를 감지하고 처리하는 방식입니다.

  • 핵심 개념:
    이벤트 프로듀서가 이벤트를 발생시키고, 이벤트 컨슈머가 이를 처리.
    비동기적으로 동작하며, 느슨하게 결합된 시스템 설계.

  • 특징:
    비동기성: 이벤트가 발생하면 즉시 처리되거나, 적절한 시점에 처리됨.
    느슨한 결합: 컴포넌트 간 직접적인 의존성 감소.
    확장성: 이벤트 기반으로 컴포넌트를 쉽게 추가 가능.

  • 사용 예:
    알림 시스템 (SMS, 이메일).
    IoT 환경 (센서 데이터 처리).
    메시징 플랫폼 (Kafka, RabbitMQ).

이벤트 기준으로 모든 데이터의 변경을 처리, 조회
비즈니스를 이벤트를 기반으로 구현하는 방법
(이벤트 소싱 포함)

데이터의 변경

  • 동기
  • 비동기 : membership-svc > 변경 요청 이벤트 소비(consume) > 도메인의 최종 버전 정보를 변경

데이터의 조회
하나의 도메인(DB)를 특정할 수 있는 key(PK)를 조건으로 최종 버전 정보를 조회

장애나 서버, 인프라에 문제가 발생할 지라도 앱이 복구되면 메세지 브로커(이벤트)에 의존해서 일관성(트랜잭션)을 구현할 수 있다.

  • request-response driven에서 100번의 요청을 했을 때 100번의 프로세싱을 해야하지만
    event-driven의 경우 100번의 요청을 받아 1번의 insert로 자원의 효율적 사용이 가능하다.

3. Event-Driven Architecture (EDA)

Event-Driven Architecture (EDA)는 Event-Driven 개념을 전체 시스템 설계에 적용한 구조로, 시스템 구성 요소가 이벤트를 생성, 소비, 처리하며 상호 작용합니다.

  • 핵심 개념:
    시스템이 이벤트 중심으로 설계됨.
    프로듀서와 컨슈머가 독립적으로 동작하며, 이벤트 버스를 통해 통신.

  • 특징:
    확장성: 다양한 마이크로서비스가 이벤트 기반으로 확장 가능.
    유연성: 변경 사항이 특정 컴포넌트에만 영향을 미침.
    이벤트 브로커: Kafka, RabbitMQ, AWS SNS/SQS와 같은 브로커 사용.

  • 사용 예:
    마이크로서비스 아키텍처에서 서비스 간 통합.
    실시간 데이터 처리 시스템.
    대규모 분산 시스템.

전체적으로 아키텍처의 모든것을 이벤트를 기반으로 구현

단점

  1. 이벤트가 한번 잘못 발행, 혹은 consume 이후 잘못된 처리를 하는 순간
    모든 데이터 정합성과 트랜잭션이 크게 망가질 수 있는 상황이 생길수 있다
    • 백업, 통제 정책 등을 잘 수립해야 한다.
    • 너무 risky한 비즈니스에서는 오히려 안 어울릴 수 있다 이때 솔루션으로 eventuate, axon framework가 있다.
Event-Driven Architecture
    ├── Event-Driven
    │     ├── Event Sourcing (이벤트를 저장하고 상태 복원)
    │     └── Saga 트랜잭션 오케스트레이션 (분산 트랜잭션 관리)
    └── 시스템 간 통합 (이벤트를 기반으로 서비스 연결)

차이점

항목Event SourcingEvent-DrivenEvent-Driven Architecture
목적데이터 상태 변화를 이벤트로 기록이벤트 기반으로 동작하는 비동기 처리이벤트 기반으로 시스템 전체를 설계
중점데이터의 상태 복원 및 이력 관리이벤트 생성과 처리이벤트의 생성, 소비, 전파
주요 사용 기술Event Store (ex. Kafka, DB)메시징 시스템 (ex. RabbitMQ, Kafka)이벤트 브로커 (ex. Kafka, AWS SQS/SNS)
적용 범위데이터 관리특정 이벤트 기반 프로세스시스템 전반의 설계
예금융 거래, 감사 시스템알림 시스템, IoT 데이터 처리마이크로서비스 통합, 실시간 처리

이 세 가지 개념은 서로 관련되어 있으나, 다루는 범위와 목적이 다릅니다. Event Sourcing은 데이터 관리에 집중하고, Event-Driven은 동작 방식에 초점을 맞추며, EDA는 시스템 전반의 설계를 아우릅니다.

기술적 동작 방법

  • 이벤트 저장소:
    모든 이벤트는 이벤트 저장소(Event Store)에 기록됩니다.
    예: Kafka, Event Store DB, DynamoDB 등.
  • 이벤트 재생:
    시스템이 재시작될 때, 이벤트를 순서대로 읽고 현재 상태를 재구성합니다.
  • CQRS와의 결합:
    Event Sourcing은 보통 CQRS(Command Query Responsibility Segregation)와 함께 사용됩니다.
    Command: 상태를 변경하는 작업 → 이벤트를 생성하여 저장.
    Query: 현재 상태를 조회 → 이벤트를 기반으로 상태를 재구성.

Event Sourcing과 CQRS를 조합하는 이유

Event Sourcing에서는 데이터의 최종상태를 바로 조회할 수 없다
따라서 데이터를 조회하려면 이벤트를 차례로 수행하여 현재 상태를 조회해야하기 때문에 조회에 비효율적이다

CQRS를 조합할 경우
읽기 모델과 쓰기 모델을 분리하여, 읽기 작업(Query)에서 이벤트 수행없이 최적화된 데이터를 바로 조회할 수 있다.

Event Sourcing으로 쓰기 작업을 처리하고,
CQRS의 Query Model을 사용해 읽기 성능을 개선하는 방법을 사용

  • 읽기 전용 데이터베이스: Query Model은 캐시나 읽기 전용 데이터베이스로 설계 가능
  • Event Sourcing으로 이력을 관리하고, CQRS로 다양한 방식으로 이력을 조회하고 활용할 수 있다
  • CQRS는 Event Sourcing의 비동기 이벤트 처리 방식과 자연스럽게 통합

Axon Framework

Axon Framwork

  • event sourcing 기반으로, 데이터를 관리할 수 있는 도구를 제공하고
    이 도구를 사용하여 CQRS, DDD를 구현할 수 있도록 돕는다.
  • springboot 프로젝트에 의존성으로 사용하여 다양한 어노테이션 기반을 위 기능을 구현할 수 있다.

Axon server

  • Axon Framework를 사용하여 배포된 어플리케이션들의 조율자 역할
  • Axon Framework를 사용하는 어플리케이션들로부터 발행된 이벤트들을 저장하는 역할
  • 각 어플리케이션들의 상태 관리, imbedding된 큐잉을 내재하여 유량 조절
  • 고가용성에 집중된 내부 구현이 되어있고
profile
Welcome to Seoyun Dev Log
하루 일지 보단 행동 고찰 과정에 대한 개발 블로그

0개의 댓글