-
[2023 우아콘] Kafka를 활용한 이벤트 기반 아키텍처 구축카테고리 없음 2024. 11. 7. 09:21
이벤트 기반 아키텍처를 선택한 이유
기존 배달 시스템의 요구사항은 단순하였지만 시간이 지날수록 다양한 요구사항이 추가되었고 그에 따른 복잡도가 증가하게 되었다.
기존의 요구사항은 단순히 ‘배달’ 이었지만 점점 다양한 요구사항들( + 알림 + 배달 시간 + 통계 + 쿠폰 + …)이 추가되었다.
그리고 이들은 처음엔 강한 일관성을 갖게 개발되었지만 위와 같은 기능들은 사실 강한 일관성을 갖을 필요가 없었다.
배달이 변경되었을 때, 관련 기능이 바로 반영되지 않아도 되는 통계나 쿠폰과 같은 기능들이 있었고 이를 이벤트 기반으로 변경하였다.
행위를 표현하는 방법
이벤트의 구성요소는 다음과 같다.
- 대상
- 대상의 식별자 정보를 제공한다.
- 행동
- 이미 벌어진 사건이므로 과거형으로 표현
- 정보
- 행위와 관련된 값들을 표현
- 시간
- 행위가 발생한 시간을 표현
이벤트 기반 아키텍처 적용 후 좋은 점
- 요구 사항이 추가되어도 기존 시스템에 복잡도 영향이 없음
- 소비처와의 결함도가 감소함
- 배달변경 사항을 이벤트로 파악 가능
- 소비처가 배달 상세정보를 조회하지 않아도 됨
- 도메인 히스토리 파악 용이
- 분석정보로 활용 가능
주의점
- 이벤트 데이터에 무분별한 데이터를 추가하면 안된다.
- 소비처와의 결합도가 높아지게 된다.
- 행위 기반으로 데이터를 정의하여 전달할 필요가 있다.
- 이벤트의 순서를 주의해야 한다.
이벤트 파이프라인
카프카 선택 이유
- 순서 보장
- 키별로 순서가 보장된다.
- 고성능/고가용성
- 실시간 이벤트 처리를 위해 필요
- 통합 도구
- Kafka Streams, Kafka Connect 등 제공
- 전담팀 지원
- 우아한 형제들에서는 카프카 클러스터 관리, 모니터링 및 지원도구를 제공해줌
- 안정적으로 카프카를 사용할 수 있었던 가장 큰 이유!
Producer -> Database(Transaction1, Transaction2) -> Message Relay -> Kafka Cluster
Transactional Outbox Pattern 도입
안정적인 메시지 발생을 보장하기 위해 Transactional Outbox Pattern을 도입하였다.
Message Relay를 구현
Message Relay로 Debezium 사용 (오픈소스, CDC에서 자주 사용됨)
고려사항
- 저비용
- 설정을 통해 Connect 등록/실행 및 모니터링 제공
- 안전성
- Binary log를 통한 순서 보장 및 offset을 활용한 발행 보장
- 처리량
- Outbox 테이블 파티셔닝을 통한 처리량 증대
CDC (Change Data Capture)
로그의 변경된 데이터를 감지하는 작업이다.
대표적인 오픈소스로 Debezium MySQL Connector는 Insert, Update, Delete 연산에 대한 변경 이벤트를 만들어 Kafka 토픽으로 전송해준다.
덕분에 DB에서 수행된 모든 이벤트가 안정적으로 수집되고 이벤트 발생 시 정확한 순서가 보장된다.
이벤트 활용 사례
- 순서가 보장된 이벤트는 이벤트 스트림을 구성
- 이벤트 스트림으로 CQRS 적용
- 이벤트 스트림으로 데이터 분석 환경 구축
- Kafka -> S3 Sink Connector -> S3 -> Glue -> Athena
- 이벤트 스트림으로 스트림즈 애플리케이션 구현
- Kafka => Kafka Streams 1, Kafka Streams 2
새롭게 알게된 것
- CDC
후기
뒤로 갈수록 모르는 용어와 기술들이 많아서 이해를 잘 하지 못해 아쉬웠다… 🥲 하지만 정리를 하면서 내가 무엇을 모르는지 알아보니 조금씩 정리가 되어 다행이다. 이번에 알게 된 기술들을 빨리 정리해야겠다!
- 대상