AWS re:Invent 2023 - Navigating the journey to serverless event-driven architecture (API303)

'구현부터 시작'하면 EventBridge로 프로듀서·컨슈머를 붙이며 가치가 한 번 치솟지만, 시간이 지나 둘이 늘수록 표준·거버넌스·발견 가능성의 부재와 불명확한 도메인 탓에 가치는 정체되고 복잡도만 커진다. 주문 서비스가 "order created"를 EventBridge로 올리는 예제로 메시지 봉투를 해부한다 — detail-type(불변 사실), source(도메인), 그리고 작성자에게 달린 detail 객체. 문제는 시간이 지나며 드러난다. "type tww" 같은 구현 디테일을 넣으면 컨슈머에게 무의미해지고, 민감 정보 공유 여부가 불분명해지며, 이벤트를 명령처럼 쓰는 이상한 영역으로 빠진다. 'policy'를 팀마다 다르게 이해해 '진흙 공'이 된 보험 스타트업 경험과 "프로덕션에 배포되는 것은 개발자의 오해"라는 Alberto Brandolini의 말을 인용한다.

해법은 이벤트 스토밍 이다. 도메인 전문가·PO·고객과 협업해 포스트잇으로 "이 일이 일어나면 다음에 이 일이"를 타임라인에 배치해 경계와 공통 언어를 찾는다(주차장 시스템 예). 도메인을 이해한 뒤엔 메시지의 세 유형 을 알아야 한다 — 거절될 수 있는 명령(command), 일어난 일을 알리는 이벤트(event), 정보를 요청하는 쿼리(query). "컨슈머가 없어도 도메인 이벤트를 발생시키라"는 팁도 준다.

메시징 패턴을 트레이드오프와 함께 파고든다. 주문 서비스가 풀필먼트를 직접 호출 하면 너무 많이 알게 되고 같은 속도로 처리해야 하며 실패가 전파된다. 해법은 점대점 큐 다. 큐에 넣으면 다운스트림을 몰라도 되어 디커플링되고, 풀필먼트가 원하는 속도로 당겨(pull) 처리하며, 실패는 데드레터 큐(DLQ)로 잡는다. 컨슈머를 여러 개 두면 줄이 빨리 빠지듯 스케일 아웃되며, DLQ·FIFO를 지원하는 Amazon SQS 로 구현한다.

"다운스트림에 일어났음을 알려야" 할 땐 발행/구독(pub/sub) 으로 넘어간다. 프로듀서가 누가 소비하는지 모른 채 브로커에 미는 push 모델이며, 라우팅·강화로 일부 수신자만 특정 이벤트에 반응하게 할 수 있다. 이를 돕는 EventBridge 는 28개+ AWS 타깃에 도달하고 API destinations 로 서드파티에도 보낸다. 끝으로 클릭스트림 같은 무한(unbounded) 데이터를 다루는 이벤트 스트리밍(Apache Kafka)과, 올해 출시된 EventBridge 커넥터로 스트림 토픽을 버스로 잇는 '두 세계의 장점' 방식, 그리고 DB 변경을 잡는 CDC(DynamoDB Streams)를 짚는다.

"이벤트 안에 무엇을 담는가"가 가장 중요한 함정이다. 정보가 너무 적으면 컨슈머가 프로듀서에서 다시 정보를 가져오느라 호출이 폭증하는 콜백을 통한 우연한 결합 이 생긴다(그래프 우상향을 '바이럴'로 착각한 보험 스타트업 일화). 이벤트로 디커플링했어도 스키마가 결합을 만든 것이다. 해법은 콘텐츠 인리처(content enricher) 로, 프로듀서는 작은(sparse) 스키마를 유지하고 중간의 인리처가 정보를 채운다. 서버리스 구현은 EventBridge Pipes 로, 소스(DynamoDB Streams·Kinesis·SQS)와 타깃 사이에서 필터링(거른 것만 과금)과 Lambda·Step Functions·API destinations로의 강화·변환 을 지원한다.

둘째 함정은 이벤트 안의 민감 데이터 다. detail 객체 전체를 암호화하면 EventBridge 필터링을 잃으므로, 이름·신용카드 같은 일부 속성만 골라 암호화하고 나머지는 평문으로 두는 절충이 권장된다. 프로듀서가 AWS KMS 공유 키로 일부를 암호화해 올리고 다운스트림이 같은 키로 복호화하며, 키 소유·접근을 프로듀서가 통제한다. 끝으로 256KB 한도를 넘는 큰 페이로드는 클레임 체크(claim check) 로 S3에 저장하고 참조 키만 버스에 올린 뒤 컨슈머가 S3에서 가져온다.

"통합 비용을 낮추면 새 통합과 실험이 폭발한다"는 James Urquhart의 말과 함께, 본인이 만든 오픈소스 Serverless Video(휴대폰 방송·이모지, 종료 후 Step Functions·EventBridge·Rekognition·Bedrock로 MP4 처리)를 사례로 든다. 트위치와 같은 기술인 Amazon IVS 가 first-party 이벤트를 발행하고 "이벤트와 MP4"만으로 플러그인을 만들도록 개방하자 이틀 만에 Bedrock 제목·태그 생성, Rekognition 모더레이션·리더보드가 등장했다. 이번 주 출시된 Stripe ↔ EventBridge 연동과 Step Functions HTTPS 통합으로 조직 경계를 넘나드는 흐름도 보인다.

계약을 통한 결합 도 짚는다. 이벤트를 "있는 그대로" 소비하면 conformist가 되어 스키마 변경에 깨지므로, 받은 이벤트를 자기 언어로 바꾸는 부패 방지 계층(ACL) 이나 프로듀서에게 매핑을 미루는 open host service 같은 바운디드 컨텍스트 매핑이 필요하다. 사적/공개 이벤트를 구분하고, EDA란 결국 '패턴의 모음'이며 DDD가 보완한다고 정리한다. 마지막은 3·5·10년 뒤의 운영 유지보수 다 — 표준(상관관계 ID·커스텀 타임스탬프·도메인·문서 URL), '이벤트 우선 사고', 그리고 EventBridge 스키마 레지스트리/디스커버리(JSON Schema·OpenAPI + 코드 바인딩)와 본인이 참여했던 오픈소스 AsyncAPI 를 언급하던 지점에서 자막이 끊긴다.