백엔드 데이터 인프라 보강 — Kafka 장애 대응

이 글은 백엔드 데이터 인프라 시리즈의 보강편이에요. 100편 Kafka Monitoring에서 JMX 메트릭 30가지로 "무엇을 볼지" 를 잡았죠. 그런데 막상 운영하다 보면 그다음이 문제예요. 지표가 빨개졌을 때 뭘 보고, 어떻게 되돌리나. 메트릭을 아는 것과 Kafka 장애를 실제로 복구하는 건 전혀 다른 일이거든요. 이 글은 자주 터지는 장애를 다섯 영역으로 나눠 증상 → 원인 → 조치 흐름으로 풀어 가요.

모니터링과 장애 대응은 다른 일이에요

이 부분이 처음엔 잘 구분이 안 돼요. "메트릭 대시보드 띄워 놨으니 장애 대응 준비 끝난 거 아냐?" 싶거든요. 아니에요. 둘은 병원으로 치면 이래요.

• 모니터링 = 건강검진 수치표. 혈압·혈당이 숫자로 찍혀요.
• 장애 대응 = 응급실 진단·처치. "이 수치가 왜 튀었고, 지금 뭘 해야 하나" 를 판단하고 손을 씁니다.

대시보드는 증상 을 보여줄 뿐, 원인 과 조치 는 안 알려줘요. 그 사이를 잇는 게 장애 대응 플레이북이에요. 그래서 이 글은 메트릭 나열이 아니라, "이 증상이면 여기부터 의심하고 이렇게 손쓴다" 순서로 갑니다.

Kafka 장애 진단의 공통 순서 — 트리아지

영역별로 들어가기 전에, 어떤 장애든 똑같이 밟는 순서가 있어요. 응급실 트리아지처럼요.

증상 확인(어떤 메트릭·에러가 떴나) → 시점(언제부터) → 최근 변경(배포·설정·트래픽) → 로그·메트릭 교차 확인 → 가설 → 좁은 조치 → 회복 확인

여기서 가장 자주 빠뜨리는 게 "최근 변경" 이에요. Kafka 장애의 상당수는 미스터리한 내부 결함이 아니라 직전 배포·설정 변경·트래픽 급증 이 방아쇠예요. 장애가 나면 먼저 "최근 30분~몇 시간 사이 뭐가 바뀌었나" 부터 떠올리세요. 그게 진단 시간을 절반으로 줄여 줍니다.

Broker 장애 — UnderReplicated·Offline Partition

가장 먼저 보는 신호가 두 개예요. UnderReplicatedPartitions(URP)가 0보다 크거나, OfflinePartitionsCount가 0보다 큰 경우.

증상 — URP가 치솟으면 "복제본이 리더를 못 따라오고 있다" 는 뜻이고, OfflinePartition이 생기면 "리더가 없어 읽기·쓰기 자체가 멈춘 파티션" 이 있다는 거예요. 후자가 훨씬 위험해요. 그 파티션은 지금 장애 상태입니다.

원인 — 브로커 하나가 죽었거나(프로세스 다운·OOM·긴 GC), 디스크가 가득 찼거나, 네트워크가 끊겨 ISR(동기화된 복제본 집합)에서 떨어져 나간 경우가 대부분이에요. 89편 복제에서 본 ISR이 min.insync.replicas 밑으로 떨어지면 쓰기가 거부돼요.

조치 — 죽은 브로커를 살리는 게 1순위예요. 재기동하면 복제본이 리더를 따라잡으며 URP가 서서히 0으로 돌아와요. 여기서 함정이 하나 있어요 — 복구 중에는 URP가 천천히 줄어드는 게 정상이라, 조급하게 다른 브로커까지 건드리면 오히려 ISR 회복을 방해해요. OfflinePartition이면 어느 파티션인지 확인하고, 정상 복제본이 살아 있으면 리더 선출을 기다리거나 99편 운영 도구의 리더 재배치를 씁니다.

Producer 장애 — TimeoutException·전송 실패

증상 — 애플리케이션 로그에 TimeoutException이 깔리고, producer 메트릭 record-error-rate가 튀어요. 메시지가 안 들어가고 쌓여요.

원인 — 패턴이 몇 가지예요. acks=all인데 ISR이 부족해 브로커가 응답을 못 주는 경우(위 Broker 장애와 연결돼요), 네트워크 지연으로 request.timeout.ms 안에 응답이 안 오는 경우, 또는 전송 속도가 소비 속도를 넘어 producer 버퍼(buffer.memory)가 꽉 차 max.block.ms만큼 막히는 경우.

원인을 가르는 법 — 여기서 정말 중요한 진단 포인트 — 모든 producer가 동시에 느린가, 특정 토픽·파티션만 그런가 를 봐요. 전체면 브로커·네트워크 쪽, 일부면 그 파티션의 리더 브로커나 핫 파티션 쪽이에요.

조치 — 브로커 측 원인이면 위 Broker 절차로. producer 측이면 96편 Producer 설정의 retries·delivery.timeout.ms로 재시도 여유를 주되, 근본 원인(ISR 부족·핫 파티션)을 안 고치면 재시도는 증상만 미뤄요.

Consumer 장애 — Lag 폭증·리밸런스 루프

증상 — records-lag-max(소비 지연)가 계속 우상향하거나, 컨슈머 그룹이 끊임없이 리밸런스를 반복해요(로그에 rebalance가 도배돼요).

원인 — Lag 폭증은 생산 속도 > 소비 속도 예요. 트래픽이 늘었거나, 컨슈머 처리 로직이 느려졌거나, 컨슈머 수가 파티션 수보다 적어 병렬도가 모자란 경우. 리밸런스 루프는 더 까다로운데, 한 번 poll 한 뒤 처리에 너무 오래 걸려 max.poll.interval.ms를 넘기면 그 컨슈머가 죽은 걸로 간주돼 그룹에서 쫓겨나고, 다시 합류하며 리밸런스가 무한 반복돼요.

조치 — Lag은 컨슈머 인스턴스를 늘리거나(단, 파티션 수가 상한이에요), 처리 로직을 가볍게 하거나, max.poll.records를 줄여 한 번에 적게 가져와요. 리밸런스 루프는 97편 Consumer 설정의 max.poll.interval.ms를 처리 시간에 맞게 늘리는 게 1차 처방이에요.

컨트롤러·디스크 — Kafka 장애가 클러스터 전체로 번질 때

컨트롤러 장애 — Kafka 클러스터엔 파티션 리더를 배정하는 컨트롤러가 하나 있어요. 옛 ZooKeeper 모드에선 ZK 세션이 끊기면 컨트롤러가 다른 브로커로 넘어가는데, 그 잠깐 사이 리더 선출이 지연돼요. 105편 KRaft 모드에선 컨트롤러 quorum이 이 역할을 대신하고요. 증상이 "특정 브로커가 아니라 클러스터 전체가 잠깐 먹통" 이면 컨트롤러·메타데이터 쪽을 의심해요.

디스크 풀 — 의외로 흔한 장애예요. 로그 세그먼트가 쌓여 디스크가 100%가 되면 그 브로커는 쓰기를 못 하고 사실상 다운돼요. 예방이 핵심이라, 95편 토픽 설정의 retention(보관 기간·용량)을 트래픽에 맞게 잡고, 디스크 사용률 알람을 80% 선에 걸어 두세요. 이미 찼다면 retention을 줄이거나 디스크를 늘려 숨통을 틔운 뒤 정리합니다.

시험·면접 직전 압축 노트 — Kafka 장애

• 모니터링 = 증상(메트릭) / 장애 대응 = 원인 진단 + 복구 조치
• 진단 공통 순서 = 증상 → 시점 → 최근 변경 → 로그·메트릭 → 가설 → 조치 → 회복 확인
• Kafka 장애의 방아쇠는 대개 직전 배포·설정 변경·트래픽 급증
• UnderReplicatedPartitions > 0 = 복제본이 리더를 못 따라옴 (ISR 이탈)
• OfflinePartitionsCount > 0 = 리더 없는 파티션 = 읽기·쓰기 멈춤(중상)
• Broker 장애 원인 = 프로세스 다운·OOM·긴 GC·디스크 풀·네트워크 단절
• Broker 복구 중 URP는 천천히 0으로 — 조급하게 다른 브로커 건드리면 회복 방해
• min.insync.replicas 밑으로 ISR 떨어지면 acks=all 쓰기 거부
• Producer TimeoutException = ISR 부족 / 네트워크 / 버퍼 풀(max.block.ms)
• 진단 = 전체 느림(브로커·네트워크) vs 일부 느림(핫 파티션·해당 리더)
• Consumer Lag 폭증 = 생산 > 소비 (트래픽↑·처리 지연·병렬도 부족)
• 리밸런스 루프 = 처리 시간이 max.poll.interval.ms 초과 → 그룹서 추방·재합류 반복
• 리밸런스 루프 1차 처방 = max.poll.interval.ms 늘리거나 max.poll.records 줄이기
• Consumer 인스턴스는 파티션 수까지만 병렬 확장됨
• Lag은 절대값보다 추세(기울기) 로 판단
• 컨트롤러/메타데이터 장애 = "클러스터 전체가 잠깐 먹통" 증상
• 디스크 풀 = 흔한 다운 원인 → retention 설정 + 80% 알람으로 예방

공식 문서: Apache Kafka — Operations와 Monitoring에서 운영 메트릭과 복구 절차의 자세한 사양을 확인할 수 있어요.

시리즈 다른 편

같이 읽으면 좋은 글:

• 89편 — Kafka 복제(Replication·ISR)
• 99편 — Kafka 운영 기본(Reassign·Rolling Restart)
• 100편 — Kafka Monitoring(JMX 메트릭 30가지)
• 보강 — Kafka 성능 튜닝(목표별 노브)