Kafka를 이용하는 메시지 플랫폼에서 장애를 겪으며 아키텍처를 개선한 이야기 #우아콘2024 #우아한형제들

우아한테크·woowacon-2024 ·2024년·

#performance-optimization#dead-letter-queue#exactly-once-semantics#redis-deduplication#asynchronous-processing#apache-kafka

AI 요약

전사 메시지 플랫폼에서 Kafka exactly-once transaction의 hanging 문제가 대형 장애로 번진 것을 계기로, 그 기능을 걷어내고 중복 차단을 다시 설계한 뒤 3배 트래픽 요구까지 대응한 개선기다. partition을 720개에서 100개로 줄이면서도 latency·처리량을 높인 과정을 다룬다.

핵심 포인트

exactly-once transaction은 여러 message를 묶는 장점이 있으나 consumer business logic의 멱등성까지 보장하지 못하고 hanging transaction은 사람이 진단·복구해야 해 오히려 유지 비용을 키워, 제거하고 API request hash를 cache key·topic retention을 TTL로 쓰는 Redis dedup으로 Kafka 내부 중복만 차단
Redis 용량을 `MEMORY USAGE` 기준 key당 120byte로 잡고 4GB cluster를 배포했으나 실제 overhead 포함 272byte로 약 2.5배였고 eviction·replication 부하 위험에 rollback해 TTL·key 수·용량을 재조정한 함정
partition 증설은 recovery·commit latency를 키우고 되돌릴 수 없으므로, timeout과 무관하게 15분+ 멈춰 rebalance를 유발하는 FCM outlier를 application time limiter로 끊고, 순서 불필요 message는 비동기 commit + TTL dead-letter topic 재시도, metadata 조회·발송 분리, 트래픽 성격별 thread pool, router 제거, 100건 batch commit으로 partition을 720→100개로 줄이고도 2배 트래픽 대부분 1분·실시간 10초 내 처리

왜 읽나Kafka 기반 대규모 발송 플랫폼 운영자에게 exactly-once의 함정과 Redis dedup·time limiter·비동기화·partition 축소라는 실전 개선 레퍼런스를 준다.

챕터별 상세

010:50 – 4:50

장애가 일상인 전사 message platform

고객·사장님·라이더와 사내 service의 모든 push·SMS·알림톡을 한곳에서 관리해 위험과 비용을 줄이지만, 외부 통신사·FCM·vendor, 내부 bug와 Kafka까지 실패 지점이 많아 집계 기간에 장애 41건을 경험했다. 발송 history와 통신사·vendor별 성공률을 관측하고 remote config로 traffic을 전환하며 critical metric을 Opsgenie에 연결했지만, architecture 자체를 바꾸게 만든 더 큰 장애가 남아 있었다.

두 차례 장애에서 발송의 56%가 실패하고 대응에 합계 8시간이 들었으며, producer epoch 오류와 특정 partition consume 중단의 원인을 exactly-once transaction으로 좁혔다. Idempotent producer와 transaction coordinator는 여러 message를 묶는 장점이 있지만 consumer business logic의 멱등성까지 보장하지 않고, hanging transaction은 사람이 진단·복구해야 해 장애가 잦은 platform의 유지 비용을 오히려 높였다.

Client가 의도한 동일 message까지 platform이 판단하지 않고 Kafka 내부 재전송만 막기 위해 API request hash를 cache key로, topic retention을 TTL로 사용하는 deduplication 구조를 선택했다. `MEMORY USAGE` 기준 key당 120byte로 계산해 4GB Redis cluster를 배포했지만 실제 overhead를 포함한 값은 272byte로 약 2.5배였고 eviction·replication 부하 위험 때문에 rollback한 뒤 TTL과 key 수, cluster 용량을 다시 조정했다.

Push partition 720개를 3배로 늘리면 recovery·commit latency와 resource가 늘고 partition 수는 되돌릴 수 없으므로, 오히려 partition을 줄이면서 처리량을 높이는 방향으로 pipeline의 병목을 추적했다. FCM 호출이 timeout 설정과 무관하게 15분 넘게 멈춰 consumer rebalance를 유발하는 outlier를 application time limiter로 끊어, 예측 불가능한 긴 꼬리를 traffic 증가에 비례하는 latency로 바꿨다.

순서가 필요 없는 message는 발송 응답을 기다리지 않고 commit하는 비동기 구조로 바꾸고, 일시적 FCM·APNs 실패는 TTL이 있는 dead-letter topic에서 재시도해 worker thread가 쉬지 않도록 했다. Metadata 조회와 발송을 분리하고 실시간·batch·광고 traffic별 thread pool을 두며 push에 불필요한 router를 제거하고 100건을 한 번에 commit해 Kafka I/O를 줄인 결과, partition을 720개에서 100개로 줄이고도 2배 traffic을 대부분 1분, 실시간 message를 10초 안에 처리했다.