Replication Factor 결정
Replication Factor는 데이터 내구성과 가용성을 결정하는 중요한 설정입니다.
Replication Factor 개요
기본 개념
┌─────────────────────────────────────────────────────────────────┐
│ Replication Factor = 3 Example │
├─────────────────────────────────────────────────────────────────┤
│ │
│ Topic: orders, Partition: 0, RF: 3 │
│ │
│ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │
│ │ Broker 1 │ │ Broker 2 │ │ Broker 3 │ │
│ │ (Leader) │ │ (Follower) │ │ (Follower) │ │
│ │ ┌───────┐ │ │ ┌───────┐ │ │ ┌───────┐ │ │
│ │ │ P0 │ │ │ │ P0 │ │ │ │ P0 │ │ │
│ │ │ Copy 1│ │ │ │ Copy 2│ │ │ │ Copy 3│ │ │
│ │ └───────┘ │ │ └───────┘ │ │ └───────┘ │ │
│ └─────────────┘ └─────────────┘ └─────────────┘ │
│ │
│ 장애 허용: Broker 2개까지 손실 가능 │
│ │
└─────────────────────────────────────────────────────────────────┘
RF 값에 따른 특성
| RF | 장애 허용 | 디스크 사용 | 쓰기 지연 | 적용 사례 |
|---|---|---|---|---|
| 1 | 없음 | 1x | 최소 | 개발, 임시 데이터 |
| 2 | 1 Broker | 2x | 낮음 | 테스트, 로그 |
| 3 | 2 Broker | 3x | 중간 | 프로덕션 (권장) |
| 4+ | 3+ Broker | 4x+ | 높음 | 규제 준수, 크리티컬 |
RF 결정 요소
데이터 중요도
┌─────────────────────────────────────────────────────────────────┐
│ Data Classification │
├─────────────────────────────────────────────────────────────────┤
│ │
│ Critical (RF=3, min.insync.replicas=2) │
│ ├── 금융 거래 │
│ ├── 주문/결제 │
│ ├── 사용자 인증 │
│ └── 규제 대상 데이터 │
│ │
│ Important (RF=3, min.insync.replicas=2) │
│ ├── 비즈니스 이벤트 │
│ ├── 알림/메시지 │
│ └── 분석 데이터 │
│ │
│ Standard (RF=2 또는 3) │
│ ├── 로그 데이터 │
│ ├── 메트릭 │
│ └── 캐시 무효화 │
│ │
│ Temporary (RF=1) │
│ ├── 개발/테스트 │
│ ├── 임시 데이터 │
│ └── 재생성 가능 데이터 │
│ │
└─────────────────────────────────────────────────────────────────┘
클러스터 구성
기본 규칙:
RF ≤ Broker 수
권장:
- 3 Broker 클러스터: RF = 3
- 5 Broker 클러스터: RF = 3
- 7+ Broker 클러스터: RF = 3 (또는 필요시 더 높게)
RF = Broker 수인 경우:
- 모든 Broker에 복제본 존재
- 단일 Broker 추가/제거에도 영향
가용성 요구사항
가용성 계산 (독립 장애 가정):
RF=1: 가용성 = 단일 Broker 가용성
예: 99.9% (연간 8.7시간 다운타임)
RF=2: 가용성 ≈ 1 - (1-p)²
예: 1 - (0.001)² = 99.9999%
RF=3: 가용성 ≈ 1 - (1-p)³
예: 1 - (0.001)³ = 99.9999999%
실제로는:
- 상관 장애 (전원, 네트워크) 고려
- Rack Awareness로 상관 장애 완화
min.insync.replicas 설정
RF와 min.insync.replicas 조합
┌─────────────────────────────────────────────────────────────────┐
│ RF와 min.insync.replicas 권장 조합 │
├─────────────────────────────────────────────────────────────────┤
│ │
│ RF=3, min.insync.replicas=2 (가장 일반적) │
│ ├── 1 Broker 장애: 정상 운영 │
│ ├── 2 Broker 장애: 쓰기 불가, 읽기 가능 │
│ └── 권장 환경: 대부분의 프로덕션 │
│ │
│ RF=3, min.insync.replicas=1 │
│ ├── 2 Broker 장애: 쓰기 가능 (위험) │
│ └── 권장 환경: 가용성 > 내구성인 경우 │
│ │
│ RF=2, min.insync.replicas=2 │
│ ├── 1 Broker 장애: 쓰기 불가 │
│ └── 권장 환경: 비권장 (취약) │
│ │
│ RF=2, min.insync.replicas=1 │
│ ├── 1 Broker 장애: 쓰기 가능 (위험) │
│ └── 권장 환경: 테스트, 로그 │
│ │
└─────────────────────────────────────────────────────────────────┘
설정 예시
# Broker 기본 설정
default.replication.factor=3
min.insync.replicas=2
# 토픽별 설정
kafka-configs.sh --bootstrap-server localhost:9092 \
--alter --entity-type topics --entity-name critical-topic \
--add-config min.insync.replicas=2acks와의 관계
// acks=all + min.insync.replicas=2
// → 최소 2개 replica에 쓰여야 성공
Properties props = new Properties();
props.put("acks", "all");
// RF=3, ISR=[1,2,3]: 3개 모두에 쓰기
// RF=3, ISR=[1,2]: 2개에 쓰기 (min.insync.replicas 충족)
// RF=3, ISR=[1]: 쓰기 실패 (NotEnoughReplicasException)Rack Awareness
설정
# server.properties (각 Broker)
broker.rack=rack1 # Broker 1, 2
broker.rack=rack2 # Broker 3, 4
broker.rack=rack3 # Broker 5, 6
# Broker 설정
replica.selector.class=org.apache.kafka.common.replica.RackAwareReplicaSelectorRack 분산
┌─────────────────────────────────────────────────────────────────┐
│ Rack Awareness (RF=3) │
├─────────────────────────────────────────────────────────────────┤
│ │
│ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │
│ │ Rack 1 │ │ Rack 2 │ │ Rack 3 │ │
│ │ ┌───────┐ │ │ ┌───────┐ │ │ ┌───────┐ │ │
│ │ │Broker1│ │ │ │Broker3│ │ │ │Broker5│ │ │
│ │ │ P0-L │ │ │ │ P0-F │ │ │ │ P0-F │ │ │
│ │ └───────┘ │ │ └───────┘ │ │ └───────┘ │ │
│ │ ┌───────┐ │ │ ┌───────┐ │ │ ┌───────┐ │ │
│ │ │Broker2│ │ │ │Broker4│ │ │ │Broker6│ │ │
│ │ │ P1-F │ │ │ │ P1-L │ │ │ │ P1-F │ │ │
│ │ └───────┘ │ │ └───────┘ │ │ └───────┘ │ │
│ └─────────────┘ └─────────────┘ └─────────────┘ │
│ │
│ 전체 Rack 장애에도 데이터 보존 │
│ │
└─────────────────────────────────────────────────────────────────┘
시나리오별 권장 설정
프로덕션 (일반)
# 토픽 생성
kafka-topics.sh --create \
--topic production-topic \
--partitions 12 \
--replication-factor 3 \
--config min.insync.replicas=2 \
--bootstrap-server localhost:9092
# 설정 요약
replication.factor=3
min.insync.replicas=2
acks=all (Producer)프로덕션 (Critical)
# 토픽 생성
kafka-topics.sh --create \
--topic critical-topic \
--partitions 12 \
--replication-factor 3 \
--config min.insync.replicas=2 \
--config unclean.leader.election.enable=false \
--bootstrap-server localhost:9092
# 추가 보호
unclean.leader.election.enable=false
# ISR이 아닌 replica가 leader가 되는 것 방지
# 데이터 손실 방지, 가용성 희생로그/메트릭
# 토픽 생성
kafka-topics.sh --create \
--topic logs \
--partitions 24 \
--replication-factor 2 \
--config min.insync.replicas=1 \
--bootstrap-server localhost:9092
# 더 높은 처리량, 약간의 내구성 타협
acks=1 (Producer)개발/테스트
# 토픽 생성
kafka-topics.sh --create \
--topic dev-topic \
--partitions 3 \
--replication-factor 1 \
--bootstrap-server localhost:9092
# 리소스 절약, 내구성 없음리소스 영향
디스크 사용량
총 디스크 사용량 = 데이터 크기 × RF
예시:
- 일일 데이터: 100GB
- 보관 기간: 7일
- RF: 3
총 디스크 = 100GB × 7 × 3 = 2.1TB
RF 증가 시:
- RF 2→3: 디스크 50% 증가
- RF 3→4: 디스크 33% 증가
네트워크 트래픽
복제 트래픽 = Producer 트래픽 × (RF - 1)
예시:
- Producer 처리량: 100MB/s
- RF: 3
복제 트래픽 = 100MB/s × 2 = 200MB/s
총 Broker 수신 = 100 + 200 = 300MB/s
쓰기 지연
acks=all 지연 ∝ RF
RF=1: ~5ms
RF=2: ~8ms
RF=3: ~12ms
(네트워크 조건에 따라 다름)
Best Practices
1. 환경별 기준
production:
default_rf: 3
min_insync_replicas: 2
critical_topics:
rf: 3
min_insync: 2
unclean_leader_election: false
staging:
default_rf: 2
min_insync_replicas: 1
development:
default_rf: 1
min_insync_replicas: 12. 토픽 분류 정책
Critical Data (RF=3, min.ISR=2):
□ 금융 거래
□ 주문/결제
□ 사용자 데이터
□ 감사 로그
Standard Data (RF=3, min.ISR=2):
□ 비즈니스 이벤트
□ 알림
□ 분석 데이터
Operational Data (RF=2, min.ISR=1):
□ 애플리케이션 로그
□ 메트릭
□ 임시 데이터
3. RF 변경 주의
# RF 증가 (안전)
kafka-reassign-partitions.sh --execute \
--bootstrap-server localhost:9092 \
--reassignment-json-file increase-rf.json
# RF 감소 (위험 - 데이터 손실 가능)
# 신중하게 계획 필요4. 모니터링
모니터링 항목:
- UnderReplicatedPartitions
- UnderMinIsrPartitionCount
- ISR 변동
- Leader 변경 빈도
알림 설정:
- UnderReplicatedPartitions > 0 for 5m
- ISR < RF for 10m
RF 결정 체크리스트
□ 데이터 중요도 분류됨
□ 가용성 요구사항 정의됨
□ Broker 수 >= RF
□ min.insync.replicas 설정됨
□ Rack Awareness 검토됨
□ 디스크/네트워크 용량 확인됨
□ acks 설정 결정됨
□ unclean.leader.election 설정됨
□ 모니터링 설정됨
댓글 (0)