[Daily morning study] AWS EventBridge와 이벤트 기반 아키텍처

#daily morning study

Image


AWS EventBridge란

AWS EventBridge는 서버리스 이벤트 버스 서비스다. 애플리케이션, AWS 서비스, SaaS 애플리케이션에서 발생하는 이벤트를 수신해서 규칙에 따라 다른 서비스로 라우팅한다. 과거 CloudWatch Events의 기능을 확장한 서비스로, 이벤트 기반 아키텍처(EDA, Event-Driven Architecture)를 구현할 때 핵심 역할을 한다.

이벤트 기반 아키텍처(EDA) 개요

이벤트 기반 아키텍처는 시스템 컴포넌트 간의 통신을 이벤트(상태 변화를 나타내는 메시지)를 통해 처리하는 패턴이다.

전통적인 요청-응답 방식 vs EDA

구분요청-응답 방식이벤트 기반 방식
결합도강한 결합 (호출자가 대상 알아야 함)느슨한 결합 (이벤트 발행만 함)
동기/비동기주로 동기주로 비동기
확장성소비자 증가 시 발행자 수정 필요소비자 추가 시 발행자 수정 불필요
장애 전파대상 서비스 장애 시 호출 실패이벤트 버스가 버퍼 역할

EDA에서 이벤트를 발행하는 쪽은 누가 소비하는지 모른다. 덕분에 소비자를 추가하거나 제거해도 발행자 코드에 영향이 없다.

EventBridge 핵심 개념

이벤트 버스(Event Bus)

이벤트가 흘러다니는 채널이다. 세 종류가 있다.

  • 기본 버스(default): AWS 서비스들이 자동으로 이벤트를 발행하는 버스. EC2 인스턴스 상태 변경, S3 오브젝트 업로드 등 AWS 이벤트가 여기에 쌓인다.
  • 커스텀 버스: 직접 만드는 버스. 애플리케이션 간 이벤트를 주고받을 때 사용한다.
  • 파트너 버스: SaaS 서비스(Datadog, Zendesk, GitHub 등)에서 이벤트를 받을 때 사용한다.

이벤트(Event)

JSON 형태의 불변 데이터다. 무슨 일이 일어났는지를 설명한다.

{
  "version": "0",
  "id": "12345678-1234-1234-1234-123456789012",
  "source": "myapp.orders",
  "detail-type": "OrderPlaced",
  "time": "2026-11-05T09:00:00Z",
  "region": "ap-northeast-2",
  "resources": [],
  "detail": {
    "orderId": "ORD-001",
    "userId": "USER-123",
    "amount": 59000
  }
}

이벤트는 최대 256KB까지 지원한다.

규칙(Rule)

특정 이벤트를 필터링해서 타겟으로 라우팅하는 설정이다. 이벤트 패턴 매칭과 스케줄 기반, 두 가지 방식이 있다.

이벤트 패턴 매칭

{
  "source": ["myapp.orders"],
  "detail-type": ["OrderPlaced"],
  "detail": {
    "amount": [{ "numeric": [">=", 50000] }]
  }
}

이 규칙은 myapp.orders에서 발행된 OrderPlaced 이벤트 중 금액이 50,000 이상인 것만 처리한다.

스케줄 기반

cron 표현식이나 rate 표현식으로 주기적으로 타겟을 실행할 수 있다.

rate(5 minutes)        # 5분마다
cron(0 9 * * ? *)      # 매일 오전 9시 UTC

타겟(Target)

이벤트를 수신해서 처리하는 대상이다. 하나의 규칙에 최대 5개의 타겟을 연결할 수 있다.

지원하는 주요 타겟:

타겟용도
Lambda이벤트 기반 로직 실행
SQS메시지 큐에 적재
SNS알림 전송
Step Functions워크플로우 실행
Kinesis Data Streams실시간 스트리밍
ECS Task컨테이너 태스크 실행
API GatewayHTTP 엔드포인트 호출
CodePipelineCI/CD 파이프라인 트리거

이벤트 패턴 매칭 상세

EventBridge의 패턴 매칭은 이벤트 JSON의 특정 필드 값을 조건으로 걸 수 있다.

지원하는 매칭 조건

{
  "detail": {
    "status": ["PENDING", "PROCESSING"],
    "region": [{"prefix": "ap-"}],
    "amount": [{"numeric": [">", 0, "<=", 100000]}],
    "errorCode": [{"exists": false}],
    "userId": [{"anything-but": ["anonymous"]}]
  }
}
  • 정확한 값 매칭: 배열에 나열된 값 중 하나와 일치
  • prefix: 문자열 접두사 매칭
  • numeric: 숫자 범위 조건
  • exists: 필드 존재 여부
  • anything-but: 특정 값 제외

이벤트 아카이브와 리플레이

EventBridge는 수신한 이벤트를 아카이브로 저장했다가 나중에 다시 재생(replay)할 수 있다. 이 기능은 여러 상황에서 유용하다.

  • 버그 수정 후 실패한 이벤트 재처리
  • 새 서비스를 배포하고 과거 이벤트로 초기 데이터 채우기
  • 개발/테스트 환경에서 프로덕션 이벤트 재현
보존 기간: 무제한 ~ 최대 무제한 (설정 가능)

Schema Registry

EventBridge Schema Registry는 이벤트 스키마를 자동으로 발견하고 저장하는 기능이다. 스키마로부터 Java, Python, TypeScript 타입 코드를 자동 생성해주기도 한다.

이벤트 발견 기능을 켜두면 버스로 들어오는 이벤트를 분석해서 스키마를 자동으로 등록한다.

실전 패턴: 주문 처리 시스템

이벤트 기반으로 주문 처리 시스템을 구성하면 아래처럼 된다.

사용자 주문
    │
    ▼
Order Service ──→ EventBridge (custom bus)
                      │
          ┌───────────┼───────────┐
          ▼           ▼           ▼
    Inventory      Payment     Notification
     Service        Service      Service
   (재고 차감)    (결제 처리)   (이메일 발송)

각 서비스는 독립적으로 이벤트를 소비한다. Order Service는 각 서비스의 존재를 몰라도 된다. 나중에 포인트 적립 서비스를 추가해도 Order Service 코드는 수정할 필요가 없다.

SQS, SNS와의 차이점

세 서비스는 모두 메시지/이벤트 처리에 쓰이지만 목적이 다르다.

서비스주요 목적특징
EventBridge이벤트 라우팅패턴 기반 필터링, AWS 서비스 통합
SQS작업 큐메시지 순서 보장, 중복 처리 방지
SNS알림 발송팬아웃(1→N), push 방식

실제로는 조합해서 사용하는 경우가 많다. EventBridge로 이벤트를 라우팅하고, SQS를 타겟으로 연결해서 소비자가 비동기로 처리하게 하는 패턴이 일반적이다.

비용 구조

  • 커스텀/파트너 이벤트: 100만 이벤트당 $1.00
  • 기본 버스 이벤트(AWS 서비스 발행): 무료
  • 스케줄러: 100만 호출당 $1.00 (Scheduler 서비스 기준)
  • 아카이브 저장: GB당 $0.023/월

주의할 점

이벤트 순서 보장 없음

EventBridge는 이벤트 순서를 보장하지 않는다. 순서가 중요한 처리는 Kinesis나 SQS FIFO를 고려해야 한다.

At-least-once 전달

이벤트가 최소 한 번 전달된다. 타겟이 같은 이벤트를 중복으로 수신할 수 있으므로 멱등성(idempotency) 처리가 필요하다.

타겟 실패 처리

타겟에 이벤트 전달이 실패하면 24시간 동안 재시도한다. 최종 실패한 이벤트는 DLQ(Dead Letter Queue)로 보낼 수 있다.

{
  "DeadLetterConfig": {
    "Arn": "arn:aws:sqs:ap-northeast-2:123456789012:my-dlq"
  }
}