[Kafka] - 6. Replication

Broker에 장애 발생 시?

장애가 발생한 Broker의 Partition들은 모두 사용할 수 없는 문제 발생

 

대안? 다른 Broker들에게 Partition을 만든다

하지만, 기존 Message(data)와 Offset 정보는 어떻게 처리해야할까? 라는 의문 발생

 

Replication

---

Partition을 Replication하여 다른 Broker에 replicas(복제물)을 미리 만들어 대비한다.

 

• 즉, Leader(원본)와 Follower(복제물)을 만들어 구성한다.
• Client(Producer/Consumer)는 Leader에게서만 Write, Read 처리 할 수 있다.
• Follower는 Broker의 장애 시 안정성을 제공하기 위한 존재이다.
• Follower는 Leader의 Commit log(Partition)을 가져오기 위해 Fetch request 하여 복제한다.
• Replication Factor 값은 Leader+Follwer를 합한 갯수.

 

Replicate achitecture

Client는 Leader에게만 처리

 

장애 발생 시

1. 복사본(Follower) 중에서 Leader 선택

2. Client(Producer/Consumer)는 자동으로 새로운 Leader에게 요청

 

Hot Spot

---

• 하나의 Broker에게 Partition들의 Leader가 몰려 있는 경우를 말한다.
• Client들은 모두 Broker101에게만 부하를 집중 시킨다.

# leader를 broker에게 골고루 분산 처리
auto.leader.rebalance.enable

# 특정 시간마다 Broker에게 쏠려 있는지 check
# default 300 seconds
leader.imbalance.check.internal.seconds

# Broker가 다른 Broker들보다 N%더 가지고 있으면 불균형하다고 인식
# Default N=10
leader.imbalance.per.broker.percentage

Hot spot

 

Rack Awareness

---

복제할 broker들을 찾아야 하는데, 더 가까이 있고 근처에 있는 것을 그룹화한다고 생각

• 동일한 Rack, Available Zone 상에 Broker들에게 Rack-name을 지정(Hadoop rack awareness 참고 )
• 복제본은 최대한 Rack 간의 균형을 유지, Rack 장애에 대비한다.
• Topic 생성 or Auto Data Balancer/Self Balance cluster 동작 시 실행