JSCODE Logo
JSCODE 박재성JSCODE 제이온JSCODE 시니
과외유튜브블로그후기
완강 후기 이벤트블로그 리뷰 이벤트AWS SAA 합격 후기 이벤트
회사명 : JSCODE대표 : 박재성사업자 등록번호 : 244-22-01557통신판매업 : 제 2023-인천미추홀-0381 호

서울특별시 구로구 경인로 20가길 11(오류동, 아델리아)

Copyright ⓒ 2026 JSCODE - 최상위 현업 개발자들의 프로그래밍 교육 All rights reserved.

이용약관개인정보처리방침

실전에서 바로 써먹는 Kafka 입문

Kafka 사전 지식 / 환경 셋팅

Kafka를 왜 배워야할까?
Kafka란? / 메시지 큐(Message Queue)란?
Kafka 설치할 환경 셋팅하기 (feat. EC2)
AWS EC2에 Kafka 설치/실행하기

Kafka 기본 개념

Kafka의 기본 구성 (Topic, Consumer, Producer)
토픽 생성하기 / 조회하기 / 삭제하기
Kafka에 메시지 넣기 / Kafka에서 메시지 조회하기
메시지를 어디까지 읽었는 지 기억하고, 그 다음 메시지부터 처리하기 (Consumer Group, Offset)
[보충 자료] 토픽, 컨슈머 그룹 이름 짓는 법 (Naming Convention)
[실습] Spring Boot에 Kafka 연결을 위한 코드 추가하기
[실습] Spring Boot로 Kafka에 메시지 넣는 코드 작성하기 (Producer)
[실습] Spring Boot가 Kafka에 메시지 잘 넣는 지 테스트해보기
[실습] Spring Boot로 Kafka에서 메시지 조회하기 (Consumer)
Kafka의 비동기 처리로 인한 성능 이점 느껴보기

Kafka 메시지 처리 실패 시 대처 방법

[실습] Spring Boot로 Kafka에서 처리에 실패한 메시지를 재시도(Retry)하도록 만들기
[실습] Spring Boot로 Kafka에서 재시도조차 실패한 메시지를 따로 보관하기 (DLT, Dead Letter Topic)
[실습] Spring Boot로 재시도조차 실패한 메시지 사후 처리하기

Kafka 메시지 처리 성능 높이기 (병렬 처리)

컨슈머가 메시지를 하나씩만 처리하는 현상
파티션(Partition)이란? / 특징
[실습] Spring Boot로 하나의 파티션에는 정말 하나의 컨슈머만 할당되는 지 확인해보기
특정 토픽의 파티션 수 조회하기 / 설정하기 / 변경하기
[실습] Spring Boot로 여러 개의 파티션에 메시지가 골고루 들어가는 지 확인해보기
[실습] Spring Boot에서 여러 개의 컨슈머로 메시지 병렬적으로 처리하기
[실습] Spring Boot에서 하나의 컨슈머로 메시지 병렬적으로 처리하기
적정 파티션 개수 계산하는 방법
컨슈머가 메시지를 지연 없이 잘 처리하고 있는 지 확인하는 방법 (Consumer Lag)

Kafka 장애 대비하기 (고가용성)

노드(node), 브로커(broker), 컨트롤러(controller), 클러스터(cluster), 레플리케이션(replication)이란?
[실습] kafka 서버 총 3대 셋팅하기
[실습] Kafka 서버 3대가 서로 잘 연동됐는 지 확인하기
토픽 세부 정보 출력값 정보 해석하기 (Isr, Leader, Replicas 등)
[실습] 팔로워 파티션에 메시지를 넣으면 어떻게 될까?
[실습] 리더 파티션에 장애가 발생하면 어떻게 될까? / Kafka 서버 1대가 고장나면 어떻게 될까?
Kafka 서버는 몇 대를 운용하는 게 좋을까?
Spring Boot에 Kafka 서버 3대를 연결해서 사용하는 방법

[프로젝트] MSA 프로젝트에서 Kafka 도입하기

프로젝트 설계
[실습] Spring Boot로 UserService 서버 초기 환경 설정하기
[실습] 회원가입 API 전체 뼈대 만들기
[실습] 회원 가입 비즈니스 로직 짜기
[실습] Spring Boot로 EmailService 서버 초기 환경 설정하기
[실습] 이메일 발송을 처리할 Consumer 로직 짜기
[실습] 프로젝트 구조에 맞게 Kafka 셋팅하기
[실습] 잘 작동하는 지 테스트해보기
← 블로그 목록으로 돌아가기

[실습] 리더 파티션에 장애가 발생하면 어떻게 될까? / Kafka 서버 1대가 고장나면 어떻게 될까?

JSCODE 박재성
JSCODE 박재성
2026. 03. 13.
author
JSCODE 박재성
category
Kafka
createdAt
Dec 6, 2025 05:14 AM
isPublic
isPublic
series
실전에서 바로 써먹는 Kafka 입문
slug
practice-leader-failure-and-server-crash
type
post
updatedAt
Mar 13, 2026 09:00

✅ 리더 파티션에 장애가 발생하면 어떻게 될까?

이전 강의에서 아래와 같이 설명했었다. 정말 그런지 실습을 통해 확인해보자.
리더 파티션에 장애가 발생하면 팔로워 파티션이 리더 역할(프로듀서로부터 메시지를 받고, 컨슈머가 메시지를 처리)을 대신 수행한다.
 
 

✅ 실습

  1. 리더 파티션을 가지고 있는 노드 조회하기
    1. # 토픽 세부 정보 조회 $ bin/kafka-topics.sh \ --bootstrap-server localhost:9092 \ --describe \ --topic email.send
      notion image
      1번 노드가 리더 파티션을 가지고 있다. 그럼 1번 노드에 장애가 발생했다는 걸 가정하기 위해 1번 노드를 종료시켜보자.
       
  1. 리더 파티션의 노드를 종료시키기
    1. 포그라운드에서 실행 중이던 노드 서버를 Ctrl + c로 종료시키기
      notion image
       
  1. 다시 리더 파티션을 가지고 있는 노드 조회하기
    1. 1번 노드가 종료됐기 때문에 다른 노드의 주소로 정보를 조회해야 한다.
      # 토픽 세부 정보 조회 $ bin/kafka-topics.sh \ --bootstrap-server localhost:19092 \ --describe \ --topic email.send
      notion image
      • 출력 정보를 보니 Leader의 값이 2로 바뀌어있는 걸로 봐서, 리더 파티션이 2번 노드로 바뀌었다는 걸 알 수 있다. 즉, 리더 파티션에 장애가 발생해서 팔로워 파티션이 리더 역할을 대신 수행하게끔 리더 파티션으로 승격된 것이다.
      • Isr 값을 보니 1번 노드가 빠져있고 2, 3번 노드만 있는 걸 확인할 수 있다. 1번 노드가 ISR에 빠졌다는 것은 1번 노드의 네트워크가 끊겼거나, 서버에 장애가 생겼거나, 아직 리더 파티션의 데이터와 동기화가 되지 않았다는 뜻이다.
       
  1. kafka 서버 1대가 고장난 상태에서, 원래처럼 메시지를 넣고 읽어들일 수 있는 지 확인하기
    1. 고장나지 않은 kafka 서버 주소를 기입해서 명령어를 입력해야 한다.
      # 토픽에 메시지 넣기 $ bin/kafka-console-producer.sh \ --bootstrap-server localhost:19092 \ --topic email.send # 메시지를 입력할 수 있는 창이 나오면 아래 값 입력하기 test # 토픽으로부터 메시지 조회 $ bin/kafka-console-consumer.sh \ --bootstrap-server localhost:19092 \ --topic email.send \ --from-beginning
      정상적으로 토픽에 메시지를 넣을 수 있고 조회까지 할 수 있을 것이다. 이렇게 할 수 있던 이유가 kafka 서버 3대를 운용했기 때문이다. 1대가 고장나더라도 남은 2대가 작동하고 있기 때문에 서비스 장애를 어느 정도 예방할 수 있다.
      당연히 kafka 서버 3대가 동시에 장애가 나서 멈춰버리면 서비스도 같이 장애가 나버린다. 그래도 kafka 서버를 1대만 운용하다가 1대가 장애날 확률보다, kafka 서버 3대를 운용하다가 3대가 전부 장애날 확률이 훨씬 작기 때문에 kafka 서버를 여러 대 운용하는 것이다.
       
  1. 고장난 kafka 서버 복구해보기
    1. kafka 서버 1대의 장애를 가정하기 위해 종료시켰던 kafka 서버를 다시 실행시키자. 종료시켰던 kafka 서버에 맞게 설정 파일(config/server.properties, config/server2.properties, config/server3.properties)을 입력해야 한다.
      $ bin/kafka-server-start.sh config/server.properties
       
  1. 정상적으로 복구됐는 지 체크하기
    1. # 토픽 세부 정보 조회 $ bin/kafka-topics.sh \ --bootstrap-server localhost:19092 \ --describe \ --topic email.send
      notion image
      Isr에 1,2,3의 숫자가 다 있는 걸로봐서 1, 2, 3번 노드의 데이터가 전부 동일하게 동기화 됐음을 알 수 있다. 정말 그런지 명령어로 알아보자.
       
      # 이전에 고장났던 kafka 서버로 토픽의 메시지 조회해보기 $ bin/kafka-console-consumer.sh \ --bootstrap-server localhost:9092 \ --topic email.send \ --from-beginning
      위에서 넣었던 test라는 메시지가 잘 읽히는 걸로 봐서, 장애가 났던 kafka 서버도 확실하게 잘 동기화 된 걸 확인할 수 있다.
 
 

✅ 정리

지금까지 Kafka 서버 3대를 운용함으로써, 특정 kafka 서버에 장애가 발생하더라도 시스템 전체가 중단되지 않고 지속적으로 서비스를 제공할 수 있다는 점을 알아봤다. 이러한 구성은 Kafka의 고가용성(시스템이 장애 상황에서도 멈추지 않고 정상적으로 서비스를 제공할 수 있는 능력)을 확보하기 위한 대표적인 방법으로, 브로커 간 복제를 통해 데이터 손실을 방지하고, 리더 파티션 장애 시에도 다른 팔로워 파티션이 자동으로 리더로 승격되며 kafka 서버가 지속적으로 운영될 수 있게 만든다.
 
 
📎
이 글은 실전에서 바로 써먹는 Kafka 입문 강의의 수업 자료 중 일부입니다.