왜 kafka를 선택했는가?
기존의 MSA 도메인의 동기식 HTTP 통신 방식은 요청이 끝날 때까지 서버가 대기해야 하는 강한 결합 상태였습니다. 이를 비동기로 전환하고자 했습니다.
2. kafka 도입 시 마주한 5가지 핵심 고민
1. 서버가 상대방의 성공 여부를 끝까지 감시해야 하는가 ?
응답을 끝까지 기다린다면 비동기의 의미가 없다 생각했습니다.
감시 대신 '장부 기반 시스템'을 택했습니다. 발행(Producer)-큐(Kafka)-소비(Consumer) 각 단계에 장부를 두어 시스템이 스스로 자신의 상태를 증명하게 설계했습니다.
2. 비동기 환경에서 데이터의 ACID 원자성
비동기로 전환한다고 하여 DB 정합성이 깨진다면 기술 도입의 의미가 퇴색한다고 생각했습니다.
트랜잭션 아웃 박스 패턴, saga 패턴, 비지니스 로직과 메세지 발행을 하나의 db 트랜잭션으로 묶어 발행의 원자성 서비스간 정합성은 saga 패턴을 통해 최종적으로 일치
3. 메시징 큐 서버에서 단일 메세지 마다 내보내면 네트워크 비용은 ?
대용량 요청을 효율적으로 처리하기 위함인데 네트워크 비용이 인프라 증설 비용과 큰 차이 없으면 의미가 없음
메세징 버스의 배치 전송 기능을 활용 데이터를 적절히 묶어 내보냄으로써 네트워크 오버헤드를 줄이고 인프라 효율성을 극대화
4. 만약 똑같은 메세지가 두 번 오거나, 순서가 뒤바뀐다면 ?
요청 처리 중 실패하거나 오류로 인해 두 번 오거나 순서가 바뀐다면?
중복방지 : 아웃박스/소비자 장부 로그 대조 하여 멱등성 보장
순서보장 : 소비자 장부를 통해 인과 관계가 깨진 요청 인지 및 대응 가능 구조
5. 장부들의 막대한 로그들의 생명주기 설정
메세지 브로커인 kafka를 도입하여 요청과 처리를 분리 하고 비동기 시스템으로 전환 해보기
Docker-Compose 로 zookeeper와 kafka 컨테이너를 하나로 묶어 관리
spring boot 프로젝트에서 config 폴더 안에 kafka 설정(구독,소비) 추가해서 관리
