조용한 개발 노트

8편에서 Kafka 성능 문제의 상당수가 JVM이 아니라 OS·운영 환경에서 발생한다는 이야기를 했다. 그런데 현장에서 가장 자주 마주치는 질문은 이거다.“Lag이 늘었는데, 어디가 문제지?”Kafka에서 관측이 어려운 이유는 도구가 부족해서가 아니다. 지표가 무엇을 의미하는지 오해하기 쉽기 때문이다.Consumer Lag은 무엇을 말해주는 지표인가Consumer Lag은 단순히 말하면 브로커에 쌓인 데이터와 소비자가 읽은 위치의 차이다.Lag = 아직 읽지 않은 메시지 수Lag = 처리 대기 중인 작업량여기까지는 맞다. 하지만 많은 오해는 여기서 시작된다.Lag이 크다고 반드시 장애는 아니다Kafka의 로그 모델을 떠올려보자.데이터는 삭제되지 않는다소비자는 자기 속도로 읽는다이 구조에서는 Lag이 일시..

5편에서 Offset Commit이 “처리 완료”가 아니라 “읽기 위치”일 뿐이라는 이야기를 했다. 그러면 자연스럽게 이런 기대가 등장한다.“그럼 Exactly-once를 쓰면 되는 거 아닌가?”Kafka의 Exactly-once Semantics(EOS)는 많은 오해를 낳는 개념이다. 이유는 간단하다. Exactly-once는 만능이 아니며, 매우 좁은 조건에서만 성립하기 때문이다.Kafka가 말하는 Exactly-once의 정확한 의미Kafka 공식 문서에서 말하는 Exactly-once는 흔히 기대하는 의미와 다르다.Kafka의 EOS는 다음을 의미한다.“Kafka 내부에서, 입력 레코드 하나가 출력 레코드 하나로 정확히 한 번 반영된다.”여기서 중요한 전제는 Kafka 내부다. DB, 외부 API..

4편에서 Consumer Group과 Rebalance가 왜 운영 사고의 중심이 되는지 살펴봤다. 그 다음에 반드시 등장하는 질문이 있다.“Offset을 커밋했는데, 왜 중복 처리됐지?”이 질문은 Offset Commit을 무엇으로 이해하고 있는지를 그대로 드러낸다. Kafka에서 Offset Commit은 ‘처리 완료’의 의미가 아니다.Offset이 의미하는 것Offset은 단순히 말하면 로그에서의 위치다.Partition은 append-only log이고, Offset은 그 로그에서 “어디까지 읽었는지”를 나타낸다.Offset = 처리 결과Offset = 비즈니스 상태이 둘은 모두 틀린 해석이다.Offset은 오직 “읽기 진행 상황”만 표현한다.Commit은 무엇을 보장하고 무엇을 보장하지 않는가Of..

3편에서 Partition이 순서와 확장을 동시에 만족시키는 설계 단위라는 이야기를 했다. 이제 그 Partition 위에서 실제 처리를 담당하는 Consumer Group으로 넘어가 보자.Kafka 운영 경험이 있는 팀이라면 한 번쯤 이런 말을 해봤을 것이다.“아무 일도 안 했는데 리밸런스가 일어났다.”이 현상은 우연이 아니다. Consumer Group의 설계 자체가 리밸런스를 전제로 하고 있기 때문이다.Consumer Group은 무엇을 해결하려는 개념인가Consumer Group의 목적은 단순하다.하나의 Topic을 여러 Consumer가 나눠서 처리한다Partition은 오직 하나의 Consumer에게만 할당된다Consumer 수에 따라 처리량을 수평 확장한다이 구조 덕분에 Kafka는 병렬 처..

2편에서 Kafka가 Pull 모델을 선택한 이유를 살펴봤다. 이제 Kafka를 Kafka답게 만드는 또 하나의 핵심 질문으로 넘어가자.“Kafka는 어떻게 많은 데이터를 빠르게 처리하면서도, 순서를 보장할 수 있을까?”그 답이 바로 Partition이다.Partition은 단순한 분할이 아니다Topic을 여러 개의 Partition으로 나눈다고 하면, 흔히 이렇게 이해한다.“데이터를 쪼개서 병렬로 처리하겠다는 거구나.”반은 맞고, 반은 틀리다. Partition은 단순한 성능 최적화 수단이 아니다.Kafka가 순서(ordering)와 확장성(scalability)을 동시에 만족시키기 위해 선택한 최소 단위다.Kafka에서 순서는 어디까지 보장되는가Kafka 공식 문서는 순서 보장에 대해 매우 명확하게 ..

1편에서 Kafka가 메시지 큐가 아니라 분산 로그라는 점을 이야기했다. 이 관점을 받아들이면, 다음 질문이 자연스럽게 이어진다.“그럼 왜 Kafka는 메시지를 밀어주지 않고, 소비자가 직접 가져가게 만들었을까?”이 선택은 구현 편의가 아니라, Kafka가 해결하려는 문제의 성격에서 나온 필연이다.Push 모델의 직관과 한계Push 모델은 직관적이다. 데이터가 도착하면, 브로커가 소비자에게 즉시 전달한다.이 방식은 단순한 메시징에서는 잘 동작한다.소비자 수가 적고처리 속도가 비슷하며메시지 크기와 빈도가 안정적일 때하지만 Kafka가 다루는 환경은 이와 다르다.Kafka가 마주한 현실적인 문제Kafka의 설계 문서가 전제로 삼는 환경은 다음과 같다.소비자마다 처리 속도가 다르다같은 데이터를 여러 그룹이 읽..

Kafka를 처음 접하면 흔히 이렇게 부른다. “대용량 메시지 큐”.하지만 이 표현은 Kafka를 이해하는 데 가장 빠르게 길을 잃게 만드는 출발점이다.Kafka는 메시지 큐가 아니다. Kafka 공식 문서에서 반복해서 강조하는 모델은 분산 로그(distributed commit log)다.메시지 큐의 사고방식전통적인 메시지 큐는 다음 질문에 초점을 맞춘다.메시지를 누가 가져갈 것인가한 번만 전달되었는가처리되면 삭제되었는가큐의 핵심은 중간에서 메시지를 관리하는 것이다. 브로커는 “이 메시지는 누가 가져갔는지”를 기억한다.소비자는 수동적이다. 메시지는 밀려오고(push), 소비자는 받아서 처리한다.Kafka의 사고방식은 다르다Kafka는 처음부터 이 질문을 다르게 던진다.“데이터를 어떻게 오래, 많이, 안..

5편에서 OpenTelemetry는 라이브러리가 아니라 표준과 규약의 집합이라는 이야기를 했다. 그렇다면 다음 질문은 자연스럽다.“이 표준 데이터는 대체 어떻게 전달되는 걸까?”OpenTelemetry는 이를 위해 OTLP(OpenTelemetry Protocol)라는 전송 규약을 정의한다. 그리고 기본 전송 방식으로 gRPC를 선택했다.OTLP는 무엇을 위한 프로토콜인가OTLP는 traces-metrics-logs 데이터를 애플리케이션에서 Collector 또는 백엔드로 일관된 형식으로 전달하기 위한 표준이다.여기서 중요한 전제는, OTLP가 다루는 데이터의 성격이다.단일 이벤트가 아니라 연속적인 데이터 스트림요청 단위 Span이 대량으로 생성됨지연이 쌓이면 관측 자체가 무의미해짐즉, OTLP는 “가끔..

4편에서 로그-메트릭-트레이스를 같은 요청으로 연결해야 의미가 생긴다는 이야기를 했다. 그런데 여기서 많은 사람들이 한 번 더 헷갈린다.“그래서 OpenTelemetry를 쓰면 되는 거지? 라이브러리 하나 붙이면 해결되는 거 아니야?”이 질문 자체가 문제의 출발점이다. OpenTelemetry는 라이브러리가 아니다.왜 라이브러리라고 생각하게 될까대부분의 개발자는 이렇게 접한다.Spring Boot에 의존성 추가Java Agent 실행 옵션 추가대시보드에 Trace가 보이기 시작이 경험만 보면, OpenTelemetry는 “관측을 해주는 도구”처럼 보인다. 하지만 실제로 OpenTelemetry가 해결하려는 문제는 훨씬 구조적이다.OpenTelemetry가 해결하려는 진짜 문제OpenTelemetry 이전..

3편에서 Trace가 끊어지는 가장 큰 원인이 Context Propagation이라는 이야기를 했다. 그런데 Context를 잘 전달했더라도, 여전히 이런 상황은 자주 발생한다.“메트릭은 분명히 나빠졌는데, 로그에서는 큰 문제가 안 보인다.” “로그에는 에러가 있는데, 지표는 정상이다.”이 혼란의 원인은 단순하다. 각각 다른 질문에 답하는 도구를, 하나의 답을 기대하며 보고 있기 때문이다.Signals는 역할이 다르다OpenTelemetry 공식 문서는 관측 신호(signals)를 traces, metrics, logs 세 가지로 나눈다. 이 분류는 구현 편의가 아니라, 각각이 답하는 질문이 다르기 때문이다.Metrics: 지금 시스템 상태가 정상인가? (전체적인 건강 상태를 빠르게 본다)Logs: 어..