Kafka 니 누군데.

About this offer

실제 비즈니스 이슈를 마주쳤더니 눈물이 질질.. 토스 러너스하이 3기 연사를 듣고 백엔드 엔지니어로써 실무에서 발생하는 여러 이슈들에 대해 관심이 생겼다. 하지만 무직백수 2학년 나. 하나도 이해하지 못했다. 연사에서 언급하신 문제들의 키워드조차 내게는 버거웠기에 그 개념과 실습부터 차근차근 공부하고자 한다. 토스 이직하는 상상 ON. (무직임) 먼저 Kafka란? 팬아웃을 제공해주는 서버 프로그램 이라고 나는 쉽게 쉽게 이해했다.. MQ 브로커 서버 프로그램을 제공함으로써 원활한 1:N 메세지 전송을 보장하는 프로그램인거 같다, 기본 작동 흐름은 다음과 같다. Kafka 기본 흐름 Topic: order │ ├─▶ [재고 그룹] 서버1, 서버2 ← 메시지를 둘이 나눠 가짐 (분배) ├─▶ [알림 그룹] 서버1, 서버2, 서버3 ← 마찬가지 └─▶ [배송 그룹] 서버1 ← ↑ 그룹 사이에서는 전부 같은 메시지를 받음 (팬아웃) -> Producer 1명이 order 토픽을 보냄 -> 각 그룹(재고, 알림, 배송)이 order 토픽의 같은 A메세지를 받음 -> 단 같은 그룹의 다른 서버는 로드밸런싱으로 메세지를 분배받음 토픽에 대해서 다른 그룹은 Fan out, 같은 그룹은 load balance 조금 더 구체적으로 * 이제 Partition, Offset 이라는 개념이 나온다. * Order 토픽에 대해서 Key에 따라서 파티션 N개로 나눠져 메세지를 적재한다. 그리고 파티션 1개 - 서버 1대의 매핑. (메세지의 순차성 보장 목적) Topic: order (이름표일 뿐, 실제 데이터는 아래 파티션에 있음) ├─ Partition 0: [0][1][2][3][4] ← 새 메시지는 오른쪽 끝에 append ├─ Partition 1: [0][1][2] └─ Partition 2: [0][1][2][3] 왜 이런 구조인가? (왜 파티션으로 토픽을 다시 쪼갠거지?) 순차성 보장이 필요한 요청들이 있기 때문이다. “한 서비스 안에서 처리량을 늘리면서 순서도 지키기 위한 것” Kafka가 순차성 문제를 해결하는 방식 순서를 지키려면 같은 주문의 이벤트(생성→결제→취소)는 한 줄(로그)에 쌓여야 한다. 한 줄은 한 명만 읽어야 순서대로 처리된다. (두 명이 읽으면 뒤 메시지를 먼저 끝낼 수 있음) 근데 줄이 하나뿐이면 처리량 한계 가 있다. 그래서 줄을 여러 개로 늘린다 = 파티션. 같은 key는 같은 줄로 → "주문 단위 순서는 유지, 주문들끼리는 병렬" 이 가능해진다. 예시로 하는 정리 order-A는 항상 같은 파티션0에 있고, 그 안에서 생성 → 결제 → 취소 순서가 유지된다. order-C처럼 다른 key가 order-A와 같은 파티션0에 섞일 수 있다. 이건 문제가 없다. 비는 파티션도 생길 수 있기거나 특정 파티션으로 쏠릴 수 있다. 참고: 그럼에도 순차성 이슈가 발생할 수 있다! 서버 안에서 멀티쓰레드 : 비동기 처리시에 생성보다 결제가 먼저 끝난다면? 좀비서버 : 서버A - 파티션0 매핑이었음. 근데 서버A가 죽었다고 판단해서 서버B - 파티션0로 재매핑된 상황. 그런데 서버A가 사실 살아있었다면?? 확실히 백엔드에서 어려운 문제 중 하나가 병렬처리인거 같다.. 이*원 교수님이 항상 수업에서 하시는 말씀이 병렬처리 해봤냐? 멀티 쓰레드 해봤냐? 이었는데.. "순차성 보장과 병렬 처리는 충돌하는데 이걸 어떻게 해결하는가?"가 Kafka의 핵심인듯. Kafka 관련 연사 내용 해석 1 Comsumer 속도를 높이려면? 상황: 메시지는 계속 쌓이는데 Comsumer가 느려서 lag(latest offset - commit)이 늘어나는 상황. 고려 사항 rebalance : Comsumer가 늘고 줄 때마다 멈춤·중복이 생긴다. 순서 보장 : 병렬로 돌리면 메시지 A, B의 처리 완료 순서가 뒤바뀔 수 있다. *"같은 key끼리는 순서대로, 다른 key끼리는 병렬로"** 설계한다. 장애 처리 : 병렬 작업 중 3번만 실패하고 4, 5번은 성공했다면 offset을 어디까지 commit할지 정해야 한다. 잘못하면 유실되거나 중복. 2 처리에 실패하면? 상황: 어떤 메시지가 데이터 오류 등으로 계속 실패하는 상황. 계속 재시도하면 그 뒤 메시지가 전부 막힘. DLQ (Dead Letter Queue) : 여러 번 재시도해도 실패한 메시지를 별도 토픽(예: order.DLQ )으로 치워두는 곳. 재발행 시스템 (retry / redrive) : 일시적 오류(네트워크 끊김 등)는 재시도하면 됨. 일정 간격을 두고 다시 시도하는 retry 토픽 ( retry-1분 , retry-10분 등) - DLQ가기 전 버그를 고친 뒤 DLQ의 메시지를 원래 토픽으로 다시 발행 하는 기능 3 브로커 성능을 개선하려면? 상황: 메시지를 한 건씩 보내면 네트워크 왕복이 너무 많아져 브로커가 느려지거나 다운되는 상황. Producer 설정으로 개선. batch.size : 메시지를 모아서 한 번에 보낼 묶음 크기 linger.ms : 묶음이 찰 때까지 최대 얼마나 기다릴지 (예: 5ms) compression.type : 압축 방식 ( lz4 , snappy , zstd 등). 네트워크·디스크 사용량이 줄어요. buffer.memory : 보내기 전 쌓아두는 메모리 버퍼 크기 트레이드오프는 처리량(throughput) ↑ 대신 지연(latency)이 약간 ↑ . 그래서 "최적화"(서비스 성격에 맞게 균형 잡기)가 필요함. 4 처리 속도를 높이려면? 처리 속도를 높이는 가장 직접적인 방법은 파티션을 늘려서 컨슈머를 더 붙이는 것. (병렬성 상한이 올라가니까). 그런데 병목이 있다.. auto.offset.reset : commit이 없을 때 어디서부터 읽을지 정하는 옵션 latest : 지금 이후 들어오는 메시지부터 읽음 earliest : 가장 처음부터 읽음 Ex) 파티션을 새로 늘리면 새 파티션에는 commit 기록이 없음. 이때 latest 면 새 파티션이 생기고 컨슈머가 인식하기 전까지 들어온 메시지를 건너뛰어 유실 됨. 그래서 earliest 로 설정해야 안전. 5 중복 처리를 막으려면? Kafka는 기본이 at-least-once라 같은 메시지가 두 번 올 수 있음. (리밸런스, 재시도 등) 멱등성(Idempotency): 같은 작업을 여러 번 해도 결과가 한 번 한 것과 같은 성질. 예를 들어 "잔액을 +100 한다"는 멱등하지 않지만, "주문 1234의 상태를 PAID로 설정한다"는 멱등하다. 이건 별도 스터디로 빼서 깊게 공부할 예정 SQL UPDATE문으로 멱등성 보장 SELECT ... FOR UPDATE (비관적 락) unique 제약 등이 있다. producer의 enable.idempotence 같은 기능을 Kafka 내부에서 지원하긴 하지만 이는 Kafka에서의 멱등성만 보장할 뿐, 외부 시스템 호출 (알람 발송, MSA api 호출 등)에서의 멱등성까지 보장하진 못하기에 추가 처리 로직이 필요하다고 한다. Kafka 멱등성 뚫림! (리밸런스 때문에) -> DB에 주문 생성1234 중복 INSERT 요청 -> DB에서 unique로 제약 검 -> 아 Kafka 뚫렸지만? 서비스는 멱등성 보장ᄒᄒ 이런 느낌~? 6 안정적으로 배포하려면? 상황: 서버를 배포하면 컨슈머가 하나씩 껐다 켜지고, 그때마다 리밸런스가 일어나 처리가 흔들림. assigner (partition assignment strategy): 리밸런스 때 파티션을 어떻게 재분배할지 정하는 전략입니다. *_기본 방식: 전부 회수했다가 다시 나누기. 전체가 멈춤. _ CooperativeStickyAssignor 는 기존 배정을 최대한 유지 하고 바뀌는 파티션만 멈추고 옮김. <CooperativeStickyAssignor> [리밸런스 전] 서버A: P0, P1 서버B: P2, P3 [1단계: 옮길 것만 반납] 서버A: P0, P1 ← 계속 처리 중 ▶️ 서버B: P2 ← 계속 처리 중 ▶️ (P3만 회수됨 ⏸️) [2단계: P3을 서버C에게] 서버A: P0, P1 서버B: P2 서버C: P3 -> 배포 시에 롤링 배포를 주로 하는데, 1개씩 서버 - 파티션을 리밸런싱해주니 lag가 덜 튄다! 7 모니터링·장애 대응은? config 점검: 설정이 서비스 특성에 맞는지 확인한다. lag 모니터링: lag은 "컨슈머가 얼마나 밀렸는가"로, Kafka 운영에서 가장 중요한 지표 후속 대책 수립: lag이 늘 때 어떻게 할지를 미리 정해두는 것. Ex) 컨슈머 증설, 파티션 증설, DLQ 확인, 장애 대응 절차서(runbook) 작성 등 <본인 정리본 원본> https://app.notion.com/p/Kafka-3ed0ea4df785800c8cdff0bbf702bfdc?source=copy_link <본인 정리본 원본 2> https://app.notion.com/p/Kafka-3ed0ea4df7858069a6caf5b33bc77a8f?source=copy_link 다음은 실습 다음 Kafka 스터디는 컨테이너 환경에서 Kafka를 열어서 개념 실습 및 실제 연사자분이 말하신 7가지 케이스에 대한 이슈를 경험해보고 토스의 해결방법을 실제 재현해 볼 것이다. 기대해라. 토*. 내 거름이 되어라.