Amazon EventBridge

주문 발생, 결제 완료, 회원가입 같은 사건마다 서비스끼리 직접 호출을 이어 붙이면 하나를 바꿀 때마다 연결된 곳을 모두 건드려야 합니다. 이벤트를 중앙에서 분류해 보내지 못하면 시스템이 커질수록 결합도가 빠르게 올라갑니다.

초기 이벤트 시스템은 서비스 간 직접 호출이나 커스텀 웹훅 연결이 많아 복잡도가 빨리 올라갔습니다. 그래서 이벤트를 중앙 버스에 모으고 규칙으로 라우팅하는 EventBridge 같은 모델이 중요해졌습니다.

이벤트가 발생한 서비스(프로듀서)는 이벤트를 이벤트 버스에 전달합니다. 이벤트 버스에는 미리 정의된 룰이 있어, 들어온 이벤트의 패턴을 검사하고 조건이 일치하는 이벤트만 지정된 타겟으로 라우팅합니다. Lambda, SQS, Step Functions 같은 타겟은 이벤트 버스가 라우팅한 이벤트만 받아 처리합니다. 프로듀서는 어떤 타겟이 이 이벤트를 소비하는지 알 필요가 없고, 타겟도 어떤 서비스가 이벤트를 발생시켰는지 몰라도 됩니다. 이 구조 덕분에 프로듀서와 컨슈머가 서로를 직접 참조하지 않는 느슨한 결합이 가능해집니다.

EventBridge와 API Gateway는 둘 다 이벤트나 요청의 출발점이 될 수 있지만 입력 성격이 다릅니다. EventBridge는 이미 발생한 사건을 규칙에 따라 비동기로 넘기는 버스이고, API Gateway는 외부 요청을 받아 인증과 정책을 적용하는 진입점입니다. 서비스 안에서 생긴 사건을 느슨하게 연결해야 하면 EventBridge를 보고, 외부 클라이언트가 호출하는 HTTP API를 열어야 하면 API Gateway를 보면 됩니다.

도메인 이벤트 라우팅, AWS 서비스 이벤트 처리, SaaS 연동, 스케줄 실행, 느슨하게 결합된 시스템 설계에 적합합니다. 여러 단계의 상태 관리, 분기, 재시도가 필요한 절차 오케스트레이션에는 맞지 않습니다.