Amazon EventBridge

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

초기에는 서비스 간 이벤트 전달을 SNS 토픽이나 SQS 큐, 혹은 서비스끼리 직접 웹훅으로 연결하는 방식으로 해결했습니다. 서비스가 5~6개일 때는 이 방식이 충분했습니다. 서비스가 10개를 넘기면서 상황이 달라졌습니다. 웹훅 연결이 수십 개로 불어나고, 한 서비스의 엔드포인트가 바뀌면 그걸 호출하던 모든 서비스를 찾아 수정해야 했습니다. 결합도가 폭발적으로 올라간 겁니다. SNS/SQS 조합으로 이벤트를 라우팅하더라도, 이벤트 내용 안의 특정 필드 값을 기준으로 라우팅하는 패턴 매칭이 없어서 소비자 쪽에서 불필요한 이벤트를 받아 직접 필터링해야 했습니다. 이벤트 구조가 바뀌면 어디서 깨지는지 파악할 스키마 관리도 없었고, Zendesk나 Datadog 같은 SaaS에서 오는 이벤트를 받아들이려면 별도 어댑터를 직접 만들어야 했습니다. 이벤트를 중앙 버스에 모아 규칙 기반 패턴 매칭으로 라우팅하고, 스키마 레지스트리로 이벤트 구조를 관리하며, SaaS 이벤트까지 네이티브로 수용하는 통합 이벤트 계층이 필요해졌고, 그 결과가 EventBridge입니다.

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

EventBridge와 API Gateway는 둘 다 이벤트나 요청의 출발점이 될 수 있지만 입력 성격이 다릅니다. EventBridge는 이미 발생한 사건을 규칙에 따라 비동기로 넘기는 버스이고, API Gateway는 외부 요청을 받아 인증과 정책을 적용하는 진입점입니다. 서비스 안에서 생긴 사건을 느슨하게 연결해야 하면 EventBridge를 보고, 외부 클라이언트가 호출하는 HTTP API를 열어야 하면 API Gateway를 보면 됩니다. SNS도 이벤트를 여러 대상으로 퍼뜨린다는 점에서 비슷해 보이지만, EventBridge는 이벤트 본문의 필드 값까지 검사하는 패턴 매칭과 스키마 레지스트리가 내장돼 있습니다. SNS는 토픽 단위의 팬아웃에 강하고, EventBridge는 이벤트 내용 기반 라우팅과 구조 관리까지 필요한 경우에 맞습니다.

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