들어가기 전우리 팀은 Reactor Kafka 기반으로 직접 구성한 컨슈머 구현체에서 classic 프로토콜을 사용해 왔다. 배포로 pod가 교체되는 몇 분 동안 컨슈머 랙이 쌓였다가 줄어드는 일이 반복됐고, 컨슈머 수가 늘면서 소비가 지연되는 구간도 길어졌다. 확인해 보니 원인은 크게 두 가지였다.eager 리밸런스에서 기존 멤버가 보유 파티션을 모두 반납했다.pod 이름으로 만든 정적 멤버 ID가 배포마다 달라져, 종료된 멤버의 세션 타임아웃을 기다려야 했다.두 문제를 해결하려고 Spring Boot와 Kafka를 4.x로 올린 뒤 KIP-848의 consumer 프로토콜을 적용하고, 컨슈머 구현도 Spring Kafka 컨테이너로 교체했다. 이 글에는 consumer 프로토콜로 바꾸면서 달라진 동작..

들어가기 전컨슈머 A와 B가 파티션 6개를 나누어 처리하고 있다. 처리량을 늘리려고 C를 추가하면 기존 컨슈머의 파티션 일부를 C에게 넘겨야 한다. 파티션을 넘기는 동안에는 소비가 지연될 수 있다.이 지연을 보려면 최종 할당표보다 새 할당을 적용하기까지 누가 무엇을 기다리는지를 확인해야 한다. 전체 파티션을 반납한 뒤 다른 멤버의 합류를 기다리는지, 이동할 파티션만 반납하는지, 반납 확인에 그룹 전체가 참여해야 하는지에 따라 영향 범위가 달라진다.classic의 eager에서는 전체 파티션을 반납한 뒤 재할당을 받는다. classic의 cooperative에서는 반납 범위가 이동 파티션으로 줄어든다. KIP-848의 consumer 프로토콜에서는 그룹 단위의 합류 대기가 멤버별 할당 조정으로 바뀐다. 같..

🧐 들어가기 전파티션 8개짜리 토픽에서 컨슈머 랙이 계속 쌓였다. 그래서 컨슈머 인스턴스를 8대에서 16대로 늘려 배포했는데 랙 그래프는 그대로였다. 컨슈머 그룹 상태를 확인해 보니 새로 뜬 8대는 할당된 파티션이 하나도 없었다. 일반 컨슈머 그룹에서는 파티션 하나가 같은 시점에 그룹 내 컨슈머 하나에게만 배타적으로 할당되기 때문이다. 애플리케이션 내부에서 별도 병렬화를 하지 않는 전통적인 소비 모델이라면, 그룹 전체 병렬성의 상한은 컨슈머 수가 아니라 파티션 수다.그렇다면 파티션을 늘리면 되지만 여기에는 되돌리기 어려운 결정이 끼어 있다. Kafka는 파티션 수를 줄이는 기능을 제공하지 않는다. 파티션을 추가하면 이후 레코드의 키-파티션 매핑도 달라질 수 있어, 파티션 내 키 순서에 의존하는 애플리케..

🧐 들어가기전우리팀은 서비스 데이터는 AWS Aurora에서 관리하고, 마케팅 데이터나 외부 데이터의 수집 분석 도구로는 GCP BigQuery를 사용하고 있었다. 서로 다른 클라우드 플랫폼을 쓰다 보니, AWS 쪽 서비스 데이터를 주기적으로 BigQuery로 동기화해줘야 했다. 그리고 이 동기화를 위해 GCP에서 제공하는 Datastream 파이프라인을 이용하고 있었다. 하지만 문제는 비용이었다. Datastream 과금이 데이터 트래픽량에 따라 일별 1만~3만 원씩 빠져나가는 구조였으며, 월 30만~90만 원 사이를 오갔다. 그래서 이러한 비용 부담으로 인해 우리팀은 비용 절감이 필요하다고 판단이 들었고, 이를 위해 Datastream을 걷어내기로 하였다. Datastream을 대체하기 위해 애플리..

🧐 들어가기전"정말 필요한" 에러로그의 알림만 바로 슬랙으로 받으면 얼마나 좋을까?Datadog을 사용하던 시절에는 자동 그룹화, 패턴 인식, 알림 설정까지 잘 갖춰져 있었기 때문에 에러 로그 모니터링이 비교적 수월했다고 한다 (팀에서 Datadog을 사용하던 당시에 나는 없었기에 그 이점을 잘 모른다). 그러나 Datadog의 비용 부담이 커지면서 지속해서 사용하기 어려웠고, 대체재로 오픈소스 기반의 Prometheus + Loki + Grafana + Tempo 스택으로 전환하게 되었다. 회사를 처음에 들어오던 당시에는 해당 스택에 대한 불편함을 전혀 느끼지 못하였다. 하지만 이제 서비스를 개발하기 시작하면서 정말 필요한 에러 로그 알림만 바로 받아보고 싶다는 생각이 강하게 들기 시작하였다. 그래서..

🧐 들어가기전"서비스 응답이 느려졌다." "간헐적으로 504 Gateway Timeout이 발생한다." "Pod가 재시작을 반복한다."분산 환경에서 이런 증상을 마주했을 때, 원인을 얼마나 빠르게 특정할 수 있는가? 증상은 하나지만 원인은 네트워크 지연, 메모리 부족, 외부 API 장애, 잘못된 설정 등 수십 가지가 될 수 있다. Prometheus 대시보드에서 CPU 사용률이 정상이고, Pod 상태도 Running이라면 어디서부터 추적을 시작해야 하는가? 이 질문에 체계적으로 답하려면 두 가지가 필요하다.첫째, 장애가 어떻게 발생하고 전파되는지에 대한 개념적 이해.둘째, 그 흐름을 실시간으로 관측할 수 있는 데이터 수집 체계.전자는 분산 시스템 이론에서 다루는 Fault/Error/Failure 모델..