Kafka + Flink 스트림 처리에서 흔히 발생하는 장애 5가지

Kafka와 Flink를 사용하면 실시간 데이터 처리 파이프라인을 쉽게 구축할 수 있다.

대표적인 구조는 다음과 같다.

Producer → Kafka → Flink Stream Processing → Sink(DB, ElasticSearch, etc)

하지만 스트림 처리 시스템은 Batch 시스템과 다른 특성 때문에 예상하지 못한 장애가 자주 발생한다.

실제 운영하면서 자주 마주치는 Kafka + Flink 스트림 처리 장애 5가지를 정리해봤다.

 

1️⃣ Consumer Lag이 계속 증가하는 문제

증상

Kafka Topic에 메시지는 계속 쌓이는데 Consumer Lag이 줄어들지 않는다.

Kafka CLI나 Kafbat/kafka UI 로 확인하면 다음처럼 Lag이 계속 증가한다.

TOPIC      PARTITION  CURRENT-OFFSET  LOG-END-OFFSET  LAG
events     0          1020            15000           13980

원인

주로 다음 원인 때문이다.

1️⃣ Consumer 처리 속도 부족
2️⃣ poll loop 지연
3️⃣ max.poll.interval 초과

특히 메시지 처리 시간이 길어지면 다음 상황이 발생할 수 있다.

poll → 메시지 가져오기
처리 (오래 걸림)
poll 호출 지연
→ consumer group 제거

이 경우 Lag은 계속 쌓이지만 Kafka에서는 consumer가 inactive 상태로 보인다.

 

해결 방법

대표적인 해결 방법은 다음과 같다.

max.poll.records 감소
poll thread / worker thread 분리
consumer scale-out

 

 

2️⃣ Flink Window 결과가 DB에 저장되지 않는 문제

증상

Kafka 메시지는 정상적으로 들어오는데 집계 결과가 DB에 저장되지 않는다.

특히 마지막 메시지 결과가 저장되지 않는 현상이 발생한다.

원인

Event Time + Watermark 방식 때문이다.

Flink Window는 다음 조건에서만 결과를 출력한다.

window_end < watermark

하지만 watermark는 새로운 이벤트가 들어와야 증가한다.

즉 다음 상황에서는 window가 닫히지 않는다.

event1
event2
event3 (마지막 이벤트)
→ 이후 이벤트 없음

이 경우

window close 조건 미충족
→ 결과 emit 안됨

그래서 마지막 이벤트 결과가 메모리에 남는다.

해결 방법

대표적인 방법

scan.watermark.idle-timeout 설정
processing time window 사용

 

 

3️⃣ Kafka Partition Skew 문제

증상

Kafka Topic Partition 중 특정 partition만 lag이 크게 증가한다.

예시

partition 0 lag: 10
partition 1 lag: 15
partition 2 lag: 30000

원인

대부분 Kafka message key 때문이다.

Kafka는 같은 key를 같은 partition에 저장한다.

예를 들어

user_id = 100

같은 key로 계속 메시지가 들어오면 특정 partition에 데이터가 몰린다.

결과

partition hotspot 발생

해결 방법

• key 분산
• partition 증가
• random key 사용

 

4️⃣ Flink Checkpoint 실패

증상

Flink Job이 다음과 같은 에러를 발생시킨다.

Checkpoint declined
Checkpoint timeout

혹은

Checkpoint failed

원인

대표적인 원인은 다음이다.

1️⃣ Sink(DB) write 지연
2️⃣ state size 증가
3️⃣ checkpoint storage 문제

특히 stateful aggregation job에서 자주 발생한다.

예를 들어

user_id 별 aggregation

을 오래 수행하면 state가 매우 커진다.

해결 방법

• checkpoint interval 조정
• state ttl 설정
• backend storage 튜닝

 

 

5️⃣ Kafka Offset Reset 문제

증상

Flink Job 재시작 이후 다음 문제가 발생한다.

데이터 중복 처리
또는 데이터 유실

원인

Kafka Consumer Offset 설정 때문이다.

대표적인 설정

auto.offset.reset

옵션

earliest
latest

예를 들어

latest

설정이면 Consumer 시작 시점 이후 데이터만 읽는다.

그래서 restart 이후 데이터 유실이 발생할 수 있다.

 

해결 방법

보통 다음 전략을 사용한다.

• checkpoint 기반 offset 관리
• exactly-once processing

 

Kafka + Flink 스트림 처리에서 중요한 것

Batch 시스템과 달리 Stream 시스템에서는 다음을 항상 고려해야 한다.

항목	설명
Backpressure	downstream 처리 속도
Watermark	event time 처리
Checkpoint	state consistency
Partition	data distribution
Offset	data replay

이 5가지를 이해하면 대부분의 장애를 빠르게 분석할 수 있다.

 

정리

Kafka + Flink 스트림 처리 시스템에서는 다음 장애가 자주 발생한다.

1️⃣ Consumer Lag 증가
2️⃣ Event Time Window 종료 안됨
3️⃣ Partition Skew
4️⃣ Checkpoint 실패
5️⃣ Offset Reset 문제

스트림 시스템은 데이터가 계속 흐르는 구조이기 때문에 시간 개념, state 관리, offset 관리 를 이해하는 것이 매우 중요하다.