Topic 의 설계
네이밍
메세지 종류를 표기하는 것이 좋음
토픽은 어떤 종류의 이벤트의 메세지가 머무르는 곳이기 때문 → 메세지 종류라는 것은 이벤트의 종류를 의미
네이밍의 규칙은 {도메인}-{행위} / {도메인}.{행위} 등으로 표기
order-created
user-signup
stock-decresed
payment-completed
order-confirmed
분리하는 경우
완전히 다른 이벤트
주문 이벤트
회원 이벤트
성격이 다른 이벤트
상태 변경 이벤트
로그/추적 관련
운영 레벨이 다른 경우
기간제 이벤트
중요성이 높은 이벤트
Consumer 가 다른 경우
결제 이벤트 → 정산 관련 Consumer
가입 이벤트 → 회원 관련 Consumer
처리 시간이 다른 경우
실시간 이벤트 (주문 관련 등..)
하루 한번의 이벤트 (마감 및 정산 관련 등..)
메세지 크기가 다른 경우
이미지가 포함되는 경우와 아닌 경우 (같은 토픽인 경우 작은 메세지가 큰 메세지에 밀림)
보존 기간의 차이
재처리하는 관점이 다른 경우
즉시 재처리해야 하는 경우
다음날 Batch 로 처리하는 경우
설정 관련이나 Consumer 가 다른 경우나, 처리방식이 다른 경우 → 분리해야 함
Key 의 설계
key 역할
어떤 파티션으로 메세지를 보내는지 결정
같은 key를 가진 메세지에 대해 순서를 보장
key 가 같으면 → 같은 파티션으로 이동 key 가 다르면 → 여러 파티션으로 분산
Key 가 없이 메세지를 보내는 경우
어떤 파티션에 들어가도 상관 없는 경우
처리량의 극대화가 목적일 때
로그 수집 클릭 이벤트 단순 알림 통계 데이터 관련
Key 를 포함해서 메세지를 보내는 경우
순서 보장이 필요할 때
같은 대상의 이벤트를 묶을 때
String userId = "user-1";
String message = "유저 1의 주문 이벤트";
kafkaTemplate.send("order-events", userId, message);
userId에 대한 메세지를 같은 파티션으로 항상 전송내부에서 순서 또한 보장
자주 사용하는 기준
순서 보장이 우선이 되어야 하는 단위에 따라 key 를 사용
주문의 순서 보장이 주요할 경우 → order 의 ID
계좌, 잔액, 누적 상태가 주요할 경우 → account의 ID
회원 단위 순서가 주요할 경우 → user 의 ID
다만 성능 관리도 해야하니 부하의 분산도 고려해야함
Key 설계 실패 시
특정 key 에 메세지가 몰리니 key 가 속한 Partition 이 과도하게 바빠짐
나머지 Partiton 은 쉬게 됨
→ Hot Partition 현상
Partition 의 적절한 수
파티션이 과도하게 많아도 운영의 비용이 늘어남
반대로 파티션이 적으면 Consumer 의 수가 적으니 처리가 바빠짐
고려해야하는 점들
Partiton 의 수 = Consumer 의 상한선
초기 트래픽과 미래 트래픽 고려하기
초기만 보고 Partition 을 적게 잡으면 확장시 힘들어짐
과도하게 미래만 보고 Partiton 을 늘리면 운영 비용 증가
초기엔 적당한 파티션의 수 로 시작 (3의 배수로 시작하는 것은 기본)
트래픽이 점차 증가하면 새로운 토픽으로 점차 전환
또는 기존 Topic 의 Partiton 늘리기 (순서 보장은 힘들 수도 있음)
Lag
Consumer Lag
→ Topic 에 쌓여있는 메세지 중
Consumer Group 에서 읽지 못한 메세지 갯수를 의미
0에 가까울 수록 적절하게 거의 실시간으로 처리 되고 있음을 의미
점점 쌓이면 처리 속도가 느리다는 것을 의미
Consumer 수를 늘리거나, 처리 로직을 개선하거나, 트래픽 제어가 필요