1. Kafka 서버는 몇 대를 운영하는 게 좋을까?
Kafka 서버를 많이 둘수록 장애를 버틸 여지는 커진다. 하지만 서버 수가 늘어나면 비용, 운영 복잡도, 모니터링 부담도 함께 증가한다.
따라서 “무조건 많이 두는 것이 정답”은 아니다. 서비스 단계와 요구되는 안정성에 맞춰 결정해야 한다.
다만 KRaft 기준 production 환경에서는 공식 문서가 공통적으로 작은 홀수 개수의 controller quorum과 여러 broker 구성을 권장한다.
Apache Kafka 공식 KRaft 문서는 controller 역할에 대해 보통 3대 또는 5대를 선택한다고 설명한다. 3대 controller는 1대 장애를 견딜 수 있고, 5대 controller는 2대 장애를 견딜 수 있다. [1]
Confluent 운영 문서는 production 환경에서 보통 최소 3개의 broker와 3개의 controller를 두라고 설명한다. [2]
또한 Kafka producer 설정 문서는 transaction 기본 구성이 production에서 최소 3 broker cluster를 전제로 하는 점을 언급한다. [3]
즉, 실무적으로는 아래처럼 이해하면 된다.
개발/학습/초기 테스트 = 1대도 가능
실제 운영/장애 대응 중요 = 보통 최소 3대 이상
2. 1대만 운영해도 되는 경우
아래 같은 경우에는 Kafka 서버 1대로 시작할 수 있다.
- 학습용 개인 실습 환경
- 개발 서버
- 테스트 서버
- 아주 초기 단계의 서비스
- 장애보다 비용 절감이 더 중요한 단계
이 구간에서는 가장 중요한 것이 “일단 빠르게 시작하는 것”일 수 있다.
1대 구성의 장점은 아래와 같다.
| 장점 | 설명 |
|---|---|
| 비용 절감 | 서버 비용이 가장 적게 든다 |
| 단순한 운영 | 설정, 모니터링, 장애 대응 포인트가 적다 |
| 빠른 시작 | 복잡한 cluster 구성 없이 바로 실습 가능 |
하지만 단점도 분명하다.
| 단점 | 설명 |
|---|---|
| 단일 장애 지점 | 그 1대가 죽으면 Kafka 전체가 같이 멈출 수 있다 |
| 복제 이점 없음 | replica failover 구조를 제대로 활용할 수 없다 |
| 운영 기능 제약 | production에서 자주 쓰는 고가용성 구성이 약하다 |
따라서 1대는 “못 쓰는 구성”이 아니라, 장애 허용 범위가 넓고 비용 절감이 더 중요한 상황에서 선택할 수 있는 최소 구성이라고 보는 편이 정확하다.
3. 왜 production에서는 보통 3대 이상을 권장할까?
Kafka를 여러 대 운영하는 이유는 leader broker가 죽었을 때 다른 broker가 역할을 이어받을 수 있게 만들기 위해서이다.
broker가 1대뿐이면 장애 시 선택지가 없다. 반면 복제와 ISR이 제대로 구성된 여러 broker cluster에서는 일부 broker 장애가 나도 서비스가 계속 동작할 여지가 생긴다.
Apache Kafka 공식 KRaft 문서는 controller quorum의 과반수가 살아 있어야 availability를 유지할 수 있다고 설명한다. [1]
예를 들어 controller가 3대면 계산은 아래와 같다.
- 전체 controller 수 = 3
- 과반수 = 2
- 따라서 1대 장애까지는 버틸 수 있다.
즉:
3대 중 2대 생존 -> quorum 유지 가능
3대 중 1대만 생존 -> quorum 불가
이 구조 때문에 보통 2대보다는 3대, 4대보다는 3대 또는 5대 같은 홀수 구성을 더 많이 쓴다.
4. 추천 기준을 아주 단순하게 나누면
사용자 초안을 현실적으로 다듬으면 아래 기준이 무난하다.
4-1. 초기 스타트업, 초기 서비스, 개발/테스트 단계
추천 Kafka 서버 수:
1대부터 시작 가능
이 단계에서는 비용 절감과 빠른 구축이 더 중요할 수 있다.
다만 이 선택은 아래 전제를 깔고 해야 한다.
- Kafka 장애가 나도 치명적이지 않다.
- 복구 시간을 어느 정도 감수할 수 있다.
- 메시지 처리 중단이 사업적으로 큰 손실로 이어지지 않는다.
즉, “1대가 가장 좋다”가 아니라 “이 단계에서는 1대로도 시작할 수 있다”가 더 정확한 표현이다.
4-2. 서비스 안정성이 중요한 운영 환경
추천 Kafka 서버 수:
보통 최소 3대 이상
이 단계에서는 아래 요소가 중요해진다.
- 장애 발생 시 서비스 중단 최소화
- leader failover 가능성 확보
- replica 기반 데이터 내구성 확보
- 운영 중 broker 교체나 점검 시 완충 여지 확보
Confluent 운영 문서는 production에서 일반적으로 최소 3 brokers와 3 controllers를 권장한다. [2]
따라서 중견 기업, 대기업, 또는 Kafka가 핵심 업무 흐름을 담당하는 서비스라면 3대 이상 구성을 기본선으로 보는 것이 현실적이다.
5. 2대는 왜 애매할까?
입문자 입장에서는 “1대보다 2대가 낫지 않나?”라는 생각이 들 수 있다.
부분적으로는 맞다. 하지만 quorum 기반 시스템에서는 2대가 생각보다 애매하다.
controller quorum 관점에서 계산해보면:
- 전체 controller 수 = 2
- 과반수 = 2
- 즉 1대라도 죽으면 과반수를 유지하지 못한다.
그래서 KRaft controller quorum은 보통 3 또는 5처럼 홀수 구성을 권장한다. [1]
broker도 비슷하게, 2대만 두면 일부 복제는 가능해도 장애 허용성과 운영 유연성이 3대 구성보다 약하다.
즉, 실무에서는 아래처럼 생각하는 편이 자연스럽다.
간단히 시작 = 1대
제대로 운영 = 3대 이상
2대는 중간 단계처럼 보이지만, quorum과 failover 관점에서는 기대만큼 깔끔하지 않을 수 있다.
6. 최종적으로는 무엇을 보고 결정해야 할까?
Kafka 서버 수는 아래 기준으로 결정하는 것이 현실적이다.
| 기준 | 질문 |
|---|---|
| 장애 허용도 | Kafka가 몇 분 멈춰도 되는가? |
| 비용 | 서버 2~3대를 더 운영할 예산이 있는가? |
| 데이터 중요도 | 메시지 처리 지연이나 손실이 얼마나 치명적인가? |
| 운영 성숙도 | 모니터링, 복구, failover 대응이 가능한가? |
| 기능 요구사항 | transaction, replication, 고가용성 요구가 있는가? |
특히 “Kafka가 핵심 업무 흐름인지”가 중요하다.
예를 들어
- 알림 발송 큐
- 결제 후속 처리
- 주문 이벤트 파이프라인
- 로그 수집/분석 파이프라인
같이 Kafka가 서비스 핵심 경로에 들어가 있다면, 1대 구성은 오래 유지하지 않는 편이 안전하다.
정리
Kafka 서버 수는 많을수록 장애 대응에는 유리하지만, 비용과 운영 복잡도도 함께 증가한다.
핵심만 정리하면 아래와 같다.
- 개발, 실습, 초기 서비스 단계에서는 1대로 시작할 수 있다.
- production 환경에서는 보통 최소 3대 이상의 broker 구성이 현실적이다.
- KRaft controller quorum은 보통 3대 또는 5대의 홀수 구성을 권장한다.
- “몇 대가 정답인가”보다 서비스가 감당할 수 있는 장애 수준과 비용이 더 중요한 판단 기준이다.
즉, 비용이 가장 중요하고 장애 허용 범위가 넓다면 1대부터 시작할 수 있고, 안정성이 중요해지는 시점부터는 3대 이상으로 확장하는 전략이 가장 무난하다.
출처
- Apache Kafka, “KRaft”, https://kafka.apache.org/41/operations/kraft/
- Confluent Documentation, “Running Kafka in Production”, https://docs.confluent.io/platform/current/kafka/deployment.html
- Apache Kafka, “Producer Configs”, https://kafka.apache.org/41/configuration/producer-configs/