나만의 repository

[카프카 핵심 가이드] Ch 13, Ch 14

오렌지색 귤 — Sun, 7 Sep 2025 20:34:20 +0900

1) 모니터링

1-1. 네 가지 숫자

Throughput : 들어오고/나가는 메시지 양 (bytes/sec, records/sec)
Error : 프로듀서/컨슈머 에러율
Lag/Latency
Saturation : 브로커가 바쁨 (Idle% 낮은 경우), 디스크가 꽉 참 (사용량 높은 경우)

지표 몇가지
1. URP > 0 : 불완전 복제 파티션이 있으니 확인 필요
2. RequestHandlerIdle %가 계속 0.3보다 작은 경우 : 브로커 과부화 가능성
3. Consumer Lag이 업무 시간에 계속 증가 : 처리 병목

1-2. SLO란?

SLI (무엇을 측정하는가) : 특정 메시지가 3초 안에 처리되는 비율
SLO (목표) : 영업 시간에 99.9%는 3초 안에 끝낸다
알람 : 3초 넘는 구간이 5분 이상 지속되면 알림

1-3. 클라이언트에서는 무엇을 볼까?

Producer : 재시도 획수, 에러율 (재시도 성공도 포함)
Consumer : 최대 랙, 리밸런스 빈도, 처리 지연
Lag = 0인데 느린 경우 : 앱 내부 처리 지연일 때가 많다 -> E2E 시간을 애플리케이션 지표로 찍어두자

2) 스트림 처리

2-1. 시간

윈도우 : "5분 동안 모아서 집계"와 같은 개념
지연 데이터 (grace) : 늦게 들어온 이벤트를 얼마나 더 받아줄지
- 예 : 5분 윈도우 + grace 10분 -> 윈도우 닫히고 10분 안에 늦게 들어와도 다시 계산한다
- grace가 지나면 버린다

2-2. 키

조인/그룹바이 전에 키가 바뀌면 카프카가 repartition 토픽을 만들어서 데이터를 다시 섞는다 -> I/O 비용이 크다
가능하면 업스트림에서 키를 맞춰서 보낸다

2-3. 상태

EOS : 컨슘 오프셋 커밋 + state 업데이트 + 아웃풋을 한 번에 커밋
단 EOS가 외부 시스템 호출의 중복까지 자동 해결해주지는 않는다

[카프카 핵심 가이드] Ch 11, Ch 12

오렌지색 귤 — Sun, 31 Aug 2025 21:20:49 +0900

Q. 브로커/토픽에 누구나 접근 가능한 상태라면 어떻게 통제해야하나?

1. 접속 통제 : 내부/외부 리스너 분리, mTLS 또는 SASL 필수, ACL 최소 권한, TLS 전체 구간, 방화벽/VPC/VPN

2. 메시지 자체 보호 : 메시지 value 전체 암호화 (AES-GCM 등) + 서명 + 일련번호 + 타임스탬프

- 연속 번호 아니면 버림

- 서명 불일치 버림

3. 전용 통로 : 금융권에서는 사설망/PrivateLink/VPN으로 별도 라인

Q. OIDC로 토큰 인증 쏠 때 갱신/만료/재연결은?

동시 폭주만 막으면 된다.

조기 갱신(만료 5 ~ 10분 전), 지수 백오프 + 지터, 프로세스 내 토큰 공유 캐시
롤링 배포 시 소수씩 재시작
모니터링: 토큰 발급 실패율/지연, 재연결 성공률 알람

Q. ZooKeeper -> KRaft 전환 시 보안 이행은?

덤프 -> 재적용 -> 리허설 순

1. ZK 현행 ACL/주체/SCRAM 덤프

2. KRaft 클러스터에 동일 리스너/보안 구성

3. 자격/ACL 재적용, 인증서/키 배포

4. Mirror/리허설로 인증/인가/지연 점검, 롤백 플랜 준비

5. 점진 전환(읽기 -> 쓰기), 안정 후 ZK 정리

[카프카 핵심 가이드] Ch 09, Ch 10

오렌지색 귤 — Sun, 24 Aug 2025 20:53:56 +0900

1. Kafka Connect는 Spring Kafka로 직접 구현한 Consumer보다 뭐가 더 좋은가?

그냥 JDBC로 읽고 KafkaTemplate으로 전송하면 되는데, Kafka Connect를 왜 써야 하지?

Kafka Connect의 핵심은 운영 편의성과 Pluggability이다.

직접 구현한 Producer/Consumer는:

장애 발생 시 재처리 로직, offset 저장, 실패 전파, 재시작 등 모든 책임이 애플리케이션에 있음
운영자는 해당 서비스를 배포하고, 장애 시 디버깅과 로깅을 파고들어야 함

반면, Kafka Connect는 다음과 같은 특성을 가진다:

항목	Kafka Connect	직접 구현
offset 저장	Kafka 내부 토픽 (__consumer_offsets)	보통 DB or Kafka 자체에 수동 커밋
리스타트/장애 복구	Worker 재시작으로 자동 복구	어플리케이션 재기동 or 별도 로직 필요
구성 변경	REST API로 Connector 설정 변경	코드 수정 + 배포
재사용성	JDBC, Debezium, S3 등 이미 만들어진 connecter 수백 개	직접 개발해야 함

2. Kafka Connect 쓰면 장애났을 때 어떻게 재처리하는가?

Connector가 중간에 죽으면 실패한 레코드는 어떻게 되나?

Kafka Connect는 기본적으로 레코드 단위의 at-least-once 처리를 보장한다.

그리고 각 Connector는 자체적으로 offset을 커밋하고, 실패하면 재시도 -> 실패 -> DLQ 흐름을 따른다.

Kafka Connect에서 errors.deadletterqueue.topic.name 옵션을 설정하면, 실패한 레코드를 Kafka 토픽으로 보내고, 수동으로 확인 및 재처리할 수 있다.

3. MirrorMaker 2.0이면 클러스터 간 동기화는 완벽하게 되는건가?

그럼 A 클러스터 -> B 클러스터로 완전하게 미러링되고 offsest도 동기화되나?

거의 대부분의 메시지는 미러링되지만, 다음과 같은 caveat가 있다:

이슈	설명
Offset translation	MM2는 offset을 따로 저장해서 원본 offset과 일치하지 않음. Consumer가 A의 offset으로 정확히 복원되지 않음.
Loop 방지 필요	양방향 미러링할 경우 A->B->A로 메시지가 순환될 수 있음. Topic 필터링 필요
Config/ACL은 기본 미러링 안 됨	topic metadata, schema, ACL 등은 직접 동기화해야 함

4. 요즘은 MirrorMaker 대신 뭘 써?

Confluent에서는 Cluster Linking도 있고, Kafka 자체에도 diskless 나온다는데?

Cluster Linking (Confluent 전용)은 MM2보다 훨씬 강력한 미러링 기능을 제공한다:

offset 유지, 동일한 topic name 유지, 정확한 시간 기반 리플레이
config / ACL / topic structure까지 복제
단점은 Confluent Enterprise 라이선스 필요

Kafka 4.x의 diskless + tiered storage 구조와 맞물리면:

로그를 직접 복제하지 않고
remote storage를 공유하거나, CDC 수준의 동기화로 분리

이런 구조에서 MM2보다 전사적인 운영 비용이 훨씬 낮아질 수 있다.

5. Kafka를 log 시스템으로 쓸 때 Connect랑 Mirror는 진짜 필요할까?

그냥 Filebeat -> Kafka -> ClickHouse 이런 구조면 되지 않나?

당장은 필요 없을 수도 있다.

하지만 다음과 같은 요구가 생기면 Kafka Connect/Mirror를 고려하게 된다:

Kafka로 적재된 로그를 정기적으로 S3로 내리고 싶다 -> Connect Sink + HDFS/S3 connector
로그 분석용으로 Region B 클러스터로도 동일하게 가져가야 한다 -> MirrorMaker or Cluster Linking
Kafka 내부 파티션 재정렬 없이 다른 클러스터에서 복제하고 싶다 -> MM2 with offset.sync.enabled

[카프카 핵심 가이드] Ch 07, Ch 08

오렌지색 귤 — Sun, 17 Aug 2025 19:29:52 +0900

Q. 카프카에서 발생할 수 있는 대표적인 에러 유형은?

Producer

TimeoutException	브로커 응답 지연 (네트워크, 리더 불안정)
RecordTooLargeException	메시지 크기가 max.request.size 초과
NotEnoughReplicasException	ISR 부족 → acks=all 충족 불가
KafkaStorageException	브로커 디스크 장애 (ISR 탈락 등 발생 가능)

Consumer

RebalanceInProgressException	Rebalance 중 poll 호출
WakeupException	안전한 종료 처리 도중 발생
OffsetOutOfRangeException	커밋된 offset이 사라진 경우 (retention.ms 초과)
CommitFailedException	group 재할당 중 커밋 시도 등 비정상 상황

클러스터/운영

브로커 장애 (Crash)	리더 재선출, ISR 이동, 컨트롤러 재할당 발생
ZK/KRaft delay	메타데이터 지연 → Metadata fetch 문제
네트워크 분리	Leader → Follower 복제 실패, 클라이언트 지연/실패

Q. 위 에러들을 테스트할 수 있는 라이브러리/도구

① Testcontainers + Embedded Kafka

Kafka를 Docker 컨테이너로 테스트용 클러스터로 쉽게 구동
Spring Kafka, Kafka Java Client와 JVM 내에서 통합 테스트 가능
일부 장애 상황을 유도할 수 있음 (브로커 중지, 네트워크 끊김 등)

예:

브로커 1개 중단 (kafkaContainer.stop())
특정 토픽에 메시지 크기 초과 메시지 전송
Rebalance 유도 → onPartitionsRevoked() 확인

② Toxiproxy

Kafka 브로커 ↔ 클라이언트 사이의 네트워크에 의도적으로 지연, 끊김, 제한을 주는 프록시
TimeoutException, NetworkException, leader unavailable 등을 유도 가능

③ Spring Kafka Test + @EmbeddedKafka

JVM 내 임베디드 Kafka 클러스터 구동
특정 상황 (e.g., offset 유실, 재시작) 등을 코드 내에서 테스트 가능
KafkaTestUtils, EmbeddedKafkaBroker 사용

④ Chaos Engineering 툴 (실전 환경)

Gremlin, Chaos Mesh, LitmusChaos	실환경에서 Kafka 브로커/네트워크에 장애 유도
kcat, kafka-producer-perf-test.sh	메시지 전송 상태, 실패율 테스트
JMeter + Kafka plugin	부하 기반 테스트 시나리오 작성 가능

Q. 테스트 케이스는?

브로커 다운 중 producer 전송 → 예외 핸들링	TimeoutException, NotLeaderForPartitionException
offset 커밋 실패 + 재시도	CommitFailedException, 재poll 동작
리밸런싱 도중 메시지 재처리 여부	onPartitionsRevoked(), ack.acknowledge() 누락 시
최대 메시지 크기 초과	RecordTooLargeException, compression.type 등과 연계
DLQ 정상 전송 여부	ErrorHandler 설정 + 메시지 확인

[카프카 핵심 가이드] Ch 05, Ch 06

오렌지색 귤 — Sun, 10 Aug 2025 21:54:01 +0900

Ch 05. 프로그램 내에서 코드로 카프카 관리하기

p. 126

카프카의 AdminClient는 Future 객체를 Result 객체 안에 감싸는데, Result 객체는 작업이 끝날 때까지 대기하거나 작업 결과에 대해 일반적으로 뒤이어 쓰이는 작업을 수행하는 헬퍼 메서드를 가지고 있다.

Q. 실제 클래스 구조는 어떻게 생겼는가?

CreateTopicsResult.java

KafkaFuture.java

p. 137

// ① 커밋된 consumer group offset 조회
Map<TopicPartition, OffsetAndMetadata> offsets = admin
    .listConsumerGroupOffsets(CONSUMER_GROUP)
    .partitionsToOffsetAndMetadata().get();

// ② 다시 최신 offset 조회
Map<TopicPartition, OffsetSpec> requestLatestOffsets = new HashMap<>();
for (TopicPartition tp : offsets.keySet()) {
    requestLatestOffsets.put(tp, OffsetSpec.latest());
}

Map<TopicPartition, ListOffsetsResult.ListOffsetsResultInfo> latestOffsets = 
    admin.listOffsets(requestLatestOffsets).all().get();

Q. ①에서 이미 offset이 있는 것 같은데, 왜 굳이 ②에서 최신 offset을 따로 조회하는가?

두 값은 Kafka에서 lag (지연) 분석, 누락 처리, backlog 확인, 지표 수집 등에서 핵심적으로 사용된다.

Ch 06. 카프카 내부 메커니즘

p. 150

Q. Ephemeral 노드란?

A. Ephemeral 노드는 ZooKeeper에서 클라이언트 세션이 살아있는 동안만 유지되는 임시 노드입니다.
세션이 종료되면 자동으로 삭제됩니다.

p. 150

그렇기 때문에 만약 특정한 브로커가 완전히 유실되어 동일한 ID를 가진 새로운 브로커를 투입할 경우, 곧바로 클러스터에서 유실된 브로커의 자리를 대신해서 이전 브로커의 토픽과 파티션들을 할당받는다.

Q. 동일한 ID를 갖게 만든다는 것이 의도적이냐?

A. 맞다. Kafka에서 브로커 ID는 브로커의 정체성을 나타내는 핵심 식별자이며, 이전 브로커가 사라졌을 때 그 자리를 대체하려면 일부러 같은 ID로 재투입해야 한다.

만약 다른 ID로 띄우면 Kafka는 이 새 브로커를 전혀 다른 새 브로커로 인식한다.

메타데이터에는 새로운 /brokers/ids/N 으로 등록
컨트롤러는 기존 파티션을 절대 이 브로커에 자동으로 매핑하지 않음
명시적으로 파티션 reassignment를 해야 반영 가능

p. 152

컨트롤러가 주키퍼에 메타데이터를 쓰는 작업은 동기적으로 이루어지지만, 브로커 메시지를 보내는 작업은 비동기적으로 이루어진다. 또한, 주키퍼로부터 업데이트를 받는 과정 역시 비동기적으로 이루어진다. 그렇기 때문에 브로커, 컨트롤러, 주키퍼 간에 메타데이터 불일치가 발생할 수 있으며, 잡아내기도 어렵다.

Q. 비동기에서는 어느 시점에 항상 불일치가 발생할 수 있을 것 같은데, 이것이 Zookeeper 기반 메타데이터 구조이기 때문이라고 말할 수 있는가?

A. 위 내용은 다음 구조적 특징들을 포함한다:

컨트롤러 → ZooKeeper: 동기 쓰기
컨트롤러 → 브로커들(리더 변경 알림): 비동기 메시지 전송
브로커 → ZooKeeper(메타데이터 watch): 비동기 업데이트 감지

결국, 동기/비동기 혼합 구조로 인해 모든 컴포넌트가 동일한 시점에 동일한 정보를 가지고 있지 않을 수 있다.

Q. KRaft 모드로 전환하면 메타데이터 불일치 문제가 해결되나?

A. Kafka 2.8+부터 ZooKeeper를 제거한 **KRaft 모드(KIP-500)**가 도입되며:

컨트롤러가 Raft consensus로 직접 메타데이터를 저장
브로커는 controller로부터 push 기반으로 메타데이터를 받음
ZooKeeper의 watch + 비동기 구조에서 생기던 불일치가 줄어듦

즉, 불일치 문제는 ZooKeeper 탓이 아니라 구조적 설계의 한계였고, Kafka는 이를 해결하기 위해 아예 ZooKeeper를 없애는 구조(KRaft)로 진화 중이다.

KRaft 에서는 ZooKeeper를 제거하고, Kafka 내부에서 메타데이터를 일관되게 관리한다.

따라서 기존 ZooKeeper 기반 Kafka보다는 메타데이터 불일치 확률이 획기적으로 줄어든다.

하지만 모든 시점에서 절대적 일치가 항상 즉시 보장되지는 않는다. 다만, Raft 알고리즘 특성상 eventually consistent가 아닌 strictly consistent로 수렴한다.

Q. Raft Quorum, Raft consensus, Raft 알고리즘은 무엇인가?

1. 큰 그림 : 왜 Raft가 필요한가?

Kafka 같은 분산 시스템에서는 메타데이터(토픽, 파티션, 리더 등) 를 여러 노드가 같이 알고 있어야 한다.

하지만 아래와 같은 문제가 발생할 수 있다:

리더가 죽으면?
네트워크가 일시적으로 분리되면?
여러 노드가 서로 다른 상태를 알고 있다면?

이럴 때도 시스템이 안전하게 일관된 결정을 내릴 수 있어야 한다.

이를 해결하기 위해 Kafka는 Raft consensus 알고리즘을 사용한다.

2. Raft Consensus 란?

여러 대의 서버가 서로 다른 네트워크 환경에서도, "하나의 결정"에 다수의 동의를 얻어 일관된 상태를 유지하도록 만드는 알고리즘

3. Raft의 핵심 구성 요소

Leader	유일한 쓰기 권한 보유자. 모든 변경은 리더를 통해서만 가능
Followers	리더의 명령을 따라가는 노드들
Candidate	리더 선출을 위해 임시로 나선 노드
Term	리더 선출 주기 (선거 라운드 같은 개념)
Log	모든 노드가 공유해야 할 기록 (예: 메타데이터 변경, 설정 변경 등)

4. Raft Quorum 이란?

Quorum은 과반수 이상 참여자들의 동의를 의미한다

5. Raft는 어떤 방식으로 일관성을 보장할까?

1️⃣ 리더 선출

모든 노드는 일정 시간 동안 리더 응답이 없으면 후보(candidate) 가 됨
투표를 요청하고, 과반수 이상이 승인하면 리더가 됨

2️⃣ 로그 복제

클라이언트가 어떤 변경 요청(예: 토픽 생성)을 하면
리더는 자신의 로그에 먼저 추가하고, follower들에게 복제를 요청함
Quorum(과반수) 노드가 이 로그를 받았다고 응답하면 commit 확정

3️⃣ 일관성 보장

follower는 리더가 승인한 로그만 최종 반영
로그는 모든 노드에서 같은 순서, 같은 내용으로 유지됨

p. 156

브로커는 추후 시동 시간을 줄이기 위해 메타데이터를 디스크에 저장한다.

Q. 그러면 ZooKeeper 사용할 떄는 브로커가 메타데이터를 디스크에 저장하지 않아?

A. 맞다. ZooKeeper 기반 Kafka에서는 브로커가 메타데이터를 디스크에 직접 저장하지 않는다.

대신, 브로커는 시동 시마다 ZooKeeper에서 메타데이터를 fetch해서 메모리에 적재한다.

즉, 브로커 디스크에는 파티션 데이터만 저장되고, 메타데이터는 저장되지 않는다.

Q. 왜 ZooKeeper 사용 때는 디스크에 저장을 안했을까?

A. Kafka 2.x 구조에선:

메타데이터는 전적으로 ZooKeeper가 authoritative source
브로커는 그때그때 ZooKeeper에서 읽어서 메모리에만 저장
메타데이터가 자주 변경될 수 있고, ZooKeeper와의 정합성 유지가 중요해서 디스크 캐시 유지하지 않음

➡ 디스크 저장의 유익보다 메타데이터 신선도와 consistency 확보가 더 중요했던 구조

[카프카 핵심 가이드] Ch 04

오렌지색 귤 — Sun, 3 Aug 2025 17:19:02 +0900

Ch 04. 카프카 컨슈머: 카프카에서 데이터 읽기

p.88

컨슈머는 해당 컨슈머 그룹의 그룹 코디네이터 역할을 지정받은 카프카 브로커에 하트비트를 전송함으로써 멤버십과 할당된 파티션에 대한 소유권을 유지한다.

Q. 그룹 코디네이터와 컨트롤러의 차이는?

정리하자면 카프카의 단일 브로커는 컨트롤러, 그룹 코디네이터 (복수 개의 group 담당 가능), 파티션의 리더 혹은 팔로워의 세가지 역할을 동시에 수행할 수 있다.

단, Kafka 3.x부터는 KRaft에서 컨트롤러 전용 노드 분리가 가능하다.

p. 89

Q. 컨슈머가 죽었다고 판단해 새로운 컨슈머에 파티션을 할당했으나, 기존 컨슈머가 살아있었고 동일한 레코드를 중복 처리하게 되는 케이스가 발생 가능한가?

A. 아래 시나리오와 같이 가능하다.

1. Consumer-1은 정상적으로 메시지를 처리 중 그러나 GC, 네트워크 지연, I/O 블로킹 등으로 heartbeat를 일정 시간 이상 보내지 못함

2. Group Coordinator는 session.timeout.ms를 넘겼다고 판단 → Consumer-1을 죽었다고 판단 리밸런싱 발생 → 해당 파티션은 Consumer-2에게 재할당

3. Consumer-1은 그 후에 깨어나서 계속 같은 파티션의 메시지를 처리함

4. 결과: 같은 오프셋 범위가 Consumer-1과 Consumer-2 양쪽에서 처리됨 → 중복 처리 발생

Q. 위 시나리오에서 컨슈머 1은 어떻게 살아있다고 다시 인식되는가?

A. Consumer-1은 Group Coordinator에게 "새로운 멤버로 재참여"한다.

예시

1. Consumer-1이 GC or 네트워크 이슈로 session.timeout.ms 이상 동안 heartbeat 미전송

2. Consumer-1이 회복됨

3. heartbeat 재시도 혹은 poll 재시작

4. 하지만 세션은 이미 만료되어 Group Coordinator는 Consumer-1을 새로운 멤버로 인식하여 JOIN_GROUP 요청

Q. 그럼 commitSync는 이미 퇴출된 컨슈머에 의해서도 반영될 수 있는가?

A. 컨슈머가 "이미 죽은 걸로 간주"되어 리밸런싱이 발생한 후에도, Coordinator는 뒤늦게 도착한 commit 요청을 반영할 수 있다.

consumer가 아직 그룹에 있어야만 offset commit을 할 수 있다는 강제 조건이 없고, late commit을 유연하게 수용하기 위한 설계이다.

p. 89

Q. 정적 그룹 멤버십과 timeout, heartbeat 등의 설정을 길게 유지하는 것의 차이는?

정적 멤버십의 장점

1. 재시작, 일시적 장애 시 리밸런싱 없이 복귀 가능

예 : 컨테이너 재기동, rolling deploy

2. 기존 파티션 -> 동일 Consumer에 할당

상태 기반 처리(stateful consumer)에서 매우 중요
Kafka Streams, RocksDB 등을 쓰는 경우 매우 효과적

3. 정적 멤버십 + 충분한 session.timeout.ms 조합

일시적 장애에서 리밸런싱 없이 회복 가능

Q. 정적 멤버십을 사용하는 컨슈머가 timeout 끝나고 복귀하면?

A. 새 멤버로 간주되어 리밸런싱 발생하며, 다른 컨슈머가 동일한 id로 join한 상태라면 MemberIdRequiredException을 일으키거나 기존 멤버를 강제로 퇴출한다.

p. 94

그렇기 때문에 현재 컨슈머 코드에서 레코드를 읽어오지 않고 메타데이터만 가져오기 위해 poll(0)을 호출하고 있다면(상당히 일반적으로 쓰이는 우회 방법이다), 이를 poll(Duration.ofMillis(0))로 바꾼다고 해서 같은 결과를 기대할 수 없는 것이다.

Q. 메타데이터만 가져오는 poll 이란?

A. consumer.poll() 호출 시, 실제 메시지는 없지만, Kafka 브로커로부터 partition, offset, group 상태 등의 메타데이터 정보만 받아오는 상황이다.

대표적인 메타데이터 poll 케이스는 아래와 같다.

p. 95

fetch.max.bytes
브로커가 컨슈머에 레코드를 보낼 때는 배치 단위로 보내며, 만약 브로커가 보내야 하는 첫 번째 레코드 배치의 크기가 이 설정값을 넘길 경우, 제한 값을 무시하고 해당 배치를 그대로 전송한다.

Q. 최대 설정값이 넘어도 전송 가능한가?

A. 맞다. Kafka에서 fetch.max.bytes는 엄격한 hard limit이 아니라 소프트 상한선이라 브로커는 설정된 최대값을 초과하더라도 배치 단위로는 예외적으로 초과 전송할 수 있다.

p. 102

앞에서 설명한 것과 같이, 카프카의 고유한 특성 중 하나는 많은 JMS 큐들이 하는 것처럼 컨슈머로부터의 응답을 받는 방식이 아니라는 점이다.

Kafka

메시지를 보내고 나면 브로커는 "이 메시지를 누가 읽었는지" 알지 못한다
Consumer가 읽었는지, 실패했는지, 중복 처리했는지는 브로커가 관여하지 않고, 오로지 Consumer가 offset을 어디까지 commit 했는지만을 기준으로 판단한다

JMS Queue

Consumer가 처리 후 ack를 보내야만 메시지가 삭제된다
ack가 없으면 다시 전송하거나 DLQ로 이동한다

p. 104

Q. consumer.commitSync()와 acknowledgement.acknowledge()의 차이는?

A. 둘 다 offset 커밋이라는 관점에서는 같다

acknowledgement.acknowledge()는 Spring Kafka Listener에서 추상화된 개념이고, 내부적으로 consumer.commitSync() 또는 commitAsync()를 호출한다.

consumer.commitSync()는 Kafka Consumer API 이며 로우레벨이다.

p. 112

Q. seek(), poll() 의 차이는?

A. seek()은 어떤 오프셋부터 메시지를 읽을지 위치를 지정하는 메서드이고, poll()은 지정된 위치부터 메시지를 실제로 가져오는 메서드이다.

Q. 그렇다면 seek() 호출 시 __consumer_offsets 토픽에 무언가 기록되거나 전송되는가?

A. 아니다.

seek()은 Consumer 인스턴스의 읽기 커서를 바꾸는 클라이언트 측 연산이다.

Kafka 브로커나 __consumer_offsets 토픽에는 아무것도 전송하지 않는다.

p. 121

컨슈머가 그룹에 조인할 필요가 없으니 subscribe() 메서드를 호출할 일이야 없겠지만, 오프셋을 커밋하려면 여전히 group.id 값을 설정해줄 필요가 있을 것이다.

Kafka에서 offset 커밋은 브로커의 내부 토픽인 __consumer_offsets에 다음과 같은 key로 저장됩니다:

(group.id, topic, partition) → offset

즉, Kafka 브로커 입장에서 "이 커밋은 누구의 오프셋인지"를 식별할 수 있어야 저장할 수 있습니다.
→ 따라서 실제로 그룹 참여(subscribe → rebalance)는 하지 않아도, 커밋 자체에는 group.id가 필수입니다.

[카프카 핵심 가이드] Ch 03

오렌지색 귤 — Sun, 27 Jul 2025 16:30:43 +0900

Ch 03. 카프카 프로듀서: 카프카에 메시지 쓰기

p. 62, 63

buffer.memory
이 매개변수는 프로듀서가 메시지를 전송하기 전에 메시지를 대기시키는 버퍼의 크리(메모리의 양)를 결정한다.

batch.size
같은 파티션에 다수의 레코드가 전송될 경우 프로듀서는 이것들을 배치 단위로 모아서 한꺼번에 전송한다.
이 매개변수는 각각의 배치에 사용될 메모리의 양을 결정한다('개수'가 아니라 '바이트' 단위임에 주의하라)

buffer.memory : 기본 값 32MB

batch.size : 기본 값 16KB

buffer.memory 안에 여러 크기의 batch.size를 가진 batch 들이 생성된다

멱등성 보장 관련 설정

acks = all

https://magpienote.tistory.com/251

모든 팔로워가 패치가 되었는지 기다린 후에 ack 응답을 보낸다.

이 설정만으로는 요청 재시도 시 중복 데이터가 생성된다,

enable.idempotence = true

https://medium.com/@shesh.soft/kafka-idempotent-producer-and-consumer-25c52402ceb9

enable.idempotence = true로 설정하면, 각 프로듀서에는 고유한 프로듀서 ID (PID)가 할당된다.

프로듀서는 메시지를 브로커에 보낼 때마다 이 PID를 포함하며, 각 메시지는 순차적으로 증가하는 시퀀스 번호를 받는다.

프로듀서가 메시지를 보내는 각 토픽 파티션마다 별도의 시퀀스가 유지되고, 브로커는 파티션별로 성공적으로 처리된 PID-SEQ 번호 조합 중 가장 큰 값을 추적한다.

https://medium.com/@shesh.soft/kafka-idempotent-producer-and-consumer-25c52402ceb9

브로커는 프로듀서의 요청이 PID/토픽 파티션 쌍에서 마지막으로 커밋된 메시지보다 시퀀스 번호가 정확히 1만큼 크지 않은 경우, 프로듀서 요청을 거절한다.

따라서 프로듀서는 실패에 따른 요청 재시도를 할 수 있지만 모든 메시지는 로그에 정확히 한 번만 기록된다.

(단, 프로듀서마다 고유 PID가 할당되므로, 단일 프로듀서 세션 내에서만 멱등성을 보장할 수 있다)

max.in.flight.requests.per.connection = 5

한 번의 연결에서 동시에 처리할 수 있는 최대 요청수

1. 메시지 순서 보장

카프카의 멱등 프로듀서는 같은 파티션에 대해 메시지의 순서를 보장해야 한다. 이 값이 5 이하일 때, 프로듀서에서 한 메시지가 실패하면 그 후의 메시지들은 서버에 전송되지 않는다. 이러한 동작은 메시지의 순서가 변경되지 않도록 보장하는 데 중요하다.

2. 중복 메시지 방지

카프카의 멱등 프로듀서는 메시지의 중복 전송을 방지한다. 이 값이 너무 크면 네트워크 지연 등의 문제로 인해 중복 메시지가 발생할 가능성이 증가한다.

https://magpienote.tistory.com/251

멱등성 프로듀서의 한계

멱등성 프로듀서는 동일한 세션 내에서만 정확히 한 번의 전달을 보장한다. 여기서 '동일한 세션'이란, PID의 생명주기를 의미한다. 만약 멱등성 프로듀서로 작동하는 프로듀서 애플리케이션에 문제가 발생해 종료되고 다시 시작하면 PID가 변경된다.

동일한 데이터를 전송하더라도, PID가 바뀌면 브로커는 다른 프로듀서 애플리케이션이 다른 데이터를 보냈다고 판단한다. 따라서 멱등성 프로듀서는 장애가 발생하지 않는 상황에서만 데이터를 정확히 한 번 적재하는 것을 보장한다는 점을 명심해야 한다.

[카프카 핵심 가이드] ch 01, 02

오렌지색 귤 — Sun, 20 Jul 2025 17:57:01 +0900

Ch 01. 카프카 시작하기

p. 7

주어진 파티션의 각 메시지는 고유한 오프셋을 가지며, 뒤에 오는 메시지가 앞의 메시지보다 더 큰 오프셋을 가진다(반드시 단조증가할 필요는 없다).

Q. 카프카의 오프셋은 각 파티션 내에서 반드시 단조 증가해야 하지 않나?

A. 카프카에서 각 파티션에 기록되는 메시지는 순차적인 오프셋을 가진다.

즉, offset n 다음엔 반드시 offset n+1 이 온다

그리고 브로커는 메시지 손실 여부를 오프셋의 단절로 인식한다.

따라서 컨슈머 입장에서 만약 오프셋이 100, 101, 102, 104 순으로 온다면 103은 유실 혹은 아직 도착하지 않은 상태로 간주될 수 있다

단조 증가가 깨지면 손실 또는 중복 발생으로 판단할 수 밖에 없다

Q. 그렇다면 왜 책에는 저렇게 쓰여 있을까?

A. 다음과 같은 케이스이지 않을까 추측해볼 수 있다.

Log Compaction이 활성화된 토픽에서는 동일 키의 오래된 레코드가 삭제될 수 있다.
다만 여기에 대해서도 오프셋 자체는 사라지지 않으며, 빈 슬롯으로 존재하거나 skip 된다

p. 8

하나의 클러스터 안에 여러 개의 브로커가 포함될 수 있으며, 그중 하나의 브로커가 클러스터 컨트롤러의 역할을 하게 된다(컨트롤러는 클러스터 안의 현재 작동 중인 브로커 중 하나가 자동으로 선정된다).

Q. 컨트롤러의 역할을 하는 브로커는 파티션 리더/팔로워로서의 역할을 수행하는가?

A. 컨트롤러가 된 브로커도 여전히 파티션 리더/팔로워로서 메시지 저장 및 전달 역할을 정상적으로 수행한다.

컨트롤러의 역할 요약

파티션 리더 선출 : Leader election 수행
메타데이터 관리 : 토픽 파티션, 브로커 상태를 Zookeeper (또는 KRaft)에 반영
브로커 장애 감지 : 다른 브로커의 heartbeat 감시
토픽/파티션 변경 관리 : 새 토픽 생성, 파티션 수 변경 등의 요청 처리
ISR(복제 대기열) 관리 : in-sync replica 리스트 유지/관리

Q. 그렇다면 실무적으로 컨트롤러는 부하 이슈가 없을까?

A. 컨트롤러는 메타데이터 관리를 담당하기 때문에 다음과 같은 단점이 있을 수 있다

리더 선출 등 중요한 이벤트가 몰릴 경우 CPU 사용률이 높아질 수 있다
많은 토픽/파티션 수를 가진 대형 클러스터에서는 컨트롤러 역할이 병목 포인트가 될 수 있다

따라서 Kafka 2.8 이후에는 컨트롤러를 별도 클러스터(KRaft mode)로 분리 운영하는 것도 지원한다

p. 9

아파치 카프카의 핵심 기능 중에 일정 기간 동안 메시지를 지속성 있게 보관하는 보존 기능이 있다.

Q. 하둡으로 영구 보관할 필요성이 있을까?

A. Kafka만으로는 "영구 보관"과 "감사 목적의 이력 관리"에 한계가 있기 때문에, 실무에서는 Hadoop(HDFS), S3, 혹은 Data Warehouse 등으로 Kafka 메시지를 이관하여 저장하는 패턴이 흔히 사용된다

Ch 02. 카프카 설치하기

p. 23

peerPort : 앙상블 안의 서버들이 서로 통신할 때 사용하는 TCP 포트 번호
leaderPort : 리더를 선출하는 데 사용되는 TCP 포트 번호

Q. 포트를 구분하는 이유는 무엇인가?

A. 이유는 아래와 같다

책임이 다른 두 종류의 통신을 분리하기 위해
Zookeeper는 리더 선출을 비동기적으로, 주기적으로 반복할 수 있으며, 이와 동시에 리더-팔로워 간 데이터 sync도 진행되므로 명확한 포트 분리가 필요하다
통신 안정성과 보안을 위해
서로 다른 포트를 사용하면:
- 방화벽, ACL, NAT, 보안 정책 적용이 더 유연
- Election 관련 트래픽과 데이터 트래픽을 독립적으로 모니터링 가능
- 포트 충돌, 병목 등을 줄일 수 있다
확장성을 고려한 설계
Zookeeper는 기본적으로 분산 시스템에서 최소 3노드 이상 구성되며, 서버 수가 많아질수록 내부 통신 복잡도도 증가한다

p. 28

auto.leader.rebalance.enable
이 설정을 활성화해주면 가능한 한 리더 역할이 균등하게 분산되도록 함으로써 이러한 사태가 발생하는 것을 방지할 수 있다.

Q. 리더의 역할을 어떤 단위로 분산하는가?

A. 이 설정은 Kafka 브로커 간 리더 파티션의 부하를 자동으로 분산시켜, 특정 브로커에 리더 파티션이 과도하게 몰리는 현상을 방지하는 역할을 한다.

단순히 리더를 골고루 나누는 것처럼 들릴 수 있지만, 실제로는 정책 기반 리더 재할당 작업이 주기적으로 수행된다.

이 설정을 true로 하면, Kafka Controller가 주기적으로 리더 분포 상태를 점검하고, 특정 브로커에 리더가 과도하게 몰렸으면 일부 파티션의 리더를 다른 브로커로 이동시킨다.

Q. 실무에서의 영향도는?

A. 리더-팔로워 간 리더 리밸런싱은 일반적으로 문제가 거의 없다

(partition reassignment 와 consumer rebalance에 비해 영향 범위가 현저히 낮다)

Kafka의 컨트롤러가 ISR 내에서 리더를 교체하는 것이고, 클러스터 안정성과 부하 분산에 오히려 긍정적이다

파티션 이동 없음
리플리카 재배치 없음
토픽 재설정 없음

다만, 리더 전환 중에는 short-lived consumer rebalance 발생 가능하며, 네트워크 영역 간 리더가 바뀌면 latency가 급증할 수 있다.

[디자인 패턴의 아름다움] ch 8.1 ~ 8.7

오렌지색 귤 — Sun, 27 Apr 2025 21:39:46 +0900

p. 388

8.1.6절에서 guava event bus를 사용하여 UserController 클래스를 다시 구현했다 하지만 UserController 클래스는 여전히 스레드 풀을 생성하고 옵서버를 등록하는 등 옵서버 패턴과 관련된 비지니스와 관련 없는 코드가 많이 남아 있다. 이 UserController 클래스를 어떻게 더 개선할 수 있을지 생각해보자.

EventBusConfigurator 등의 모듈에서 옵서버를 등록한다.

EventDispatcher 같은 추상 인터페이스를 정의하고 GuavaEventDispatcher 구현체를 실제 UserController 에서 사용하도록 한다.

p. 390

read() 함수는 데이터를 읽는 전 과정을 정의하는 템플릿 메서드로, 하위 클래스별로 정의된 추상 메서드를 노출한다. 이 추상 메서드의 이름 역시 read()로 동일하지만, 매개변수와 템플릿 메서드는 같지 않다.

public abstract int read()

한 바이트 단위로 읽는 것이 스트림의 가장 기본 동작이다
각 InputStream 서브클래스는 이 메서드만 최소한으로 구현하면 "스트림에서 데이터 하나를 꺼내는" 기능을 갖추게 된다.

public int read(byte[] b, int off, int len)

여러 바이트를 한 번에 읽어들이는 편의 메서드로, 기본적으로 read()를 여러 번 호출해 구현되어 있다.
구현체가 업로드와 다운로드 같은 “대용량 데이터 처리”에 최적화하려면, 이 메서드를 오버라이드하여 더 효율적인 버퍼 복사 로직을 넣으면 된다.

Q. 스트림에서 데이터 하나를 꺼내는 기능이 구현체마다 다르게 정의되는 이유는?

A. 각 스트림 구현체마다 "한 바이트 읽기"가 실제로 수행하는 일은 완전히 다르다.

1. FileInputStream 은 OS의 파일 디스크립터를 통해 직접 시스템 콜을 발생시켜야 한다.

2. SocketInputStream 은 네트워크 버퍼에서 데이터를 가져오기 위해 소켓 레벨의 I/O 경로를 타야 한다.

3. ByteArrayInputStream 은 JVM 힙에 올라 있는 배열에서 단순히 인덱스를 증가시켜 바이트를 꺼낸다.

Q. 금융 회계 업무에 상태 머신을 활용한다면?

A. 금융·회계 시스템의 전표, 결제, 환불, 승인 등 다단계 프로세스는 상태 머신과 상태 패턴이 딱 맞는 대표적 예

전표 승인 워크플로우

[생성] → [승인 대기] → (승인) → [승인 완료] → [집계 대기] → [집계 완료]
↘ (반려) ↗

이벤트 : 승인, 요청, 반려, 재요청
상태 머신
- 상태 생성, 승인 대기, 승인 완료, 반려, 집계 완료 등
- 전이 : submitForApproval, approve, reject, aggregate

기타 궁금한 사항

1. 팀에서 상태머신이나 상태패턴을 사용해본 경험이 있는지 궁금합니다.

[디자인 패턴의 아름다움] ch 7.5 ~ ch 7.7

오렌지색 귤 — Sun, 20 Apr 2025 20:40:12 +0900

p. 348

어댑터 패턴과 퍼사드 패턴의 공통점은 설계가 좋지 않은 인터페이스를, 사용하기 용이한 인터페이스로 만든다는 점이다.

내가 이해하기로 퍼사드 패턴은 여러 서브시스템을 묶어 클라이언트에 노출할 단일, 간결한 인터페이스를 제공한다.

그래서 어댑터 패턴과는 다르게 좋지 않은 설계에만 사용하는 패턴은 아닌 것으로 보인다.

퍼사드는 단순히 부실한 설계를 감추는 꼼수가 아니라, 건전한 계층화와 관심사 분리를 위한 패턴이라고 생각한다.

p. 348

복합체 패턴은 주로 트리 구조의 데이터를 처리하는 데 사용된다.

Q. 실제 개발을 하면서 트리 구조의 자료 구조를 생성하고 복합체 패턴을 활용해보신 적이 있는지?

회계 시스템에 사용해본다면..?

계정과목 계층 구조
- 계정과목 (Asset, Liability, Equity 등) 과 하위 세부 계정 (Current Assets, Cash 등) 을 하나의 인터페이스 (AccountComponent)로 다루기
- 잔액 합계, 잔액 이동, 재귀적 집계 등을 Composite 노드 (그룹 계정)와 Leaf 노드 (개별 계정)에 동일하게 적용
재무제표 구성 요소
- 재무상태표나 손익계산서의 항목을 챕터 -> 섹션 -> 라인 아이템 구조로 표현
- 각 항목의 금액 집계 (getAmount())를 구현체마다 다르게 처리하되, 클라이언트에서는 인터페이스만 호출
분개 묶음 처리
- 하루치 분개, 월말 분개, 연말 조정 분개 등을 CompositeEntry로 묶고, 개별 분개는 JournalEntry Leaf로 구현
- 일괄 승인, 일괄 롤백, 검증 로직을 Composite에 한 번만 구현
부서, 사업부 비용 집계
- 법인 전체 -> 사업부 -> 부서 -> 팀 단위로 비용을 계층화
- 부서별 비용 합계, 전사 비용 합계를 동일한 코드 (CostComponent.calculate())로 처리
결산 작업 워크플로우
- 여러 단계 (전표검증 -> 조정분개 -> 시산표 생성 -> 재무제표 작성)를 Step 인터페이스로 공통화
- 전체 결산 작업은 CompositeStep으로, 개별 단계는 LeafStep으로 구현

p. 362

플라이웨이트 패턴은 JVM의 가비지 컬렉션 기능과는 상성이 좋지 않다.

Q. 언제 플라이웨이트를 써야 할까?

A. 1번의 경우에만 사용하자

메모리 절약 효과가 더 큰 경우 : 힙 사용량이 크게 내려가면, GC 부하 증가보다 이득이 크다
- 객체 인스턴스를 수백만 개 생성해야 하는 상황
- 인스턴스당 메모리 크기가 크고, 동일한 속성의 객체가 매우 자주 반복될 때
GC 부담이 더 큰 경우 : 오히려 GC가 더 자주, 길게 돌아가 전체 성능이 떨어진다
- 풀에 들어가는 플라이웨이트 객체가 너무 많이 Old 영역이 포화될 때
- 객체 수가 그리 많지 않아 메모리 절약 효과가 미미할 때

p. 368

Q. String은 가비지 컬렉션 대상인가?

1. 새로 생성된 String 객체 (new 생성자)

String s = new String("hello");

힙에 할당된 일반 객체이므로, 참조가 끊기면 GC 대상이 된다

2. 리터럴이나 intern() 된 String 객체

String a = "hello";
String b = new String("hi").intern();

문자열 풀에 저장되어 강한 참조로 유지되므로, 클래스 로더가 언로드되기 전까지는 GC되지 않는다

JVM 7 이후에는 이 풀이 힙 영역으로 옮겨졌지만, 여전히 풀 내부에 강한 참조로 남아 있어 쉽게 회수되지 않는다

Q. 그렇다면 리터럴이 너무 많으면 메모리 에러가 발생하나?

A. 맞다. 다만 리터럴이 수만 개 이상이 아니라면 보통 문제가 되지 않는다. 동적으로 생성해서 intern()을 남발하거나 대량의 클래스를 런타임에 생성, 로딩 (예: 리플렉션 코드 생성 라이브러리) 할 때 리터럴이 폭증하면 문제가 될 수 있따.

JDK6 이하 (PermGen OOM)
- 문자열 리터럴은 PermGen 영역에 올라간다
- 클래스 로딩 시 리터럴이 모두 풀에 적재되고, 해제되지 않으므로 PermGen이 가득차면 java.lang.OutOfMemoryError: PermGen space 에러 발생
JDK7 이상 (힙 OOM)
- PermGen이 사라지고 메타스페이스(Metaspace)로 대체되면서, 상수 풀은 힙 영역에 위치한다
- 리터럴이나 intern()된 문자열이 너무 많아 힙을 과도하게 차지하면 java.lang.OutOfMemoryError: Java heap space 에러 발생