5_Replication

Replication

replication은 기본적으로 데이터의 손실을 최소화하기 위해서 만든 개념이다.

partition을 복제하여 다른 broker상에서 복제물(replicas)을 만들어서 장애에 따른 손실을 대비한다.

원본 - Leader, 복제 - Follower

 

producer, consumer는 Leader에만 pub/sub한다. replication은 broker 내부적으로 만든다.
Follower가 요청해서 메시지를 가져가는 방식이다.

 

Leader 장애가 나면 새로운 Leader 선정 및 선출된 Leader partition으로 pub/sub 한다.

 

하나의 Broker에만 Leader가 몰린다면?

하나의 broker에만 부하가 집중되는 것을 Hot Spot이라고 한다.

Hot Spot을 방지하는 방법

auto.leader.rebalance.enable=enable
leader.imbalance.check.interval.seconds=300

 

Rack Awareness

동일한 rack, AZ 상의 broker들에 동일한 rack name을 지정한다.

replica는 최대한 rack간의 균형을 유지하여 rack에서 장애가 나는 것을 대비하게 된다.

auto data balancer / self balancing cluster 동작때만 실행한다.

broker.rack=ap-northeast-2a

 

In-Sync-Replication(ISR)

replication에서 ISR은 꽤 중요한 개념이라고 할 수 있다.

ISR의 기본 개념은 High Water Mark라고 하는 지점까지 동일한 replicas의 목록이다.

 

High Water Mark는 쉽게 설명해서 replicas들 중에서 잘 복제를 하고 있는 것의 기준선이다.

replica.lag.max.messages=4
# 최대 4개 정도의 차이만 나는 Replica들의 모임.
# 그 이상 차이가 나면 OSR이 된다.

OSR(Out-of-Sync): 잘 따라잡고 있지 못한 replicas.

하지만 위의 설정에서는 문제점이 있다. 

log 데이터를 수집하는 예로 들때, 갑자기 traffic이 대량으로 발생해

kafka에 publishing된 record가 확 늘어나는 경우 갯수에 미치지 못한 replicas는 모두 OSR이 되어 버린다.

replica.lag.time.max.ms=10000
# 갯수가 아닌 시간으로 판단한다.

따라서 다음과 같은 변수로 시간으로 판단하는 것이 운영환경에서는 더 좋다.

 

ISR은 broker가 관리한다.

• Follower가 너무 느리면 Leader는 ISR에서 Follower를 제거하고 zookeeper에 ISR을 유지 시킨다.
• Controller는 partition metadata에 대한 변경 사항에 대해서 zookeeper로부터 수신한다.

 

메시지가 복제되는 과정

1. producer가 Leader에서 메시지를 publishing
2. Follower의 broker에 있는 Fetch Thread가 Leader에 새롭게 추가된 메시지를 복제
3. 이후 Fetch Thread가 다시 요청을 한 뒤 null을 받게 되면 Leader partition의 High Water Mark를 변경
4. 다시 Fetch Thread가 fetch를 수행하고 Follower partition의 High Water Mark를 업데이트 하게 된다.

ISR - Commited

ISR 목록의 모든 replicas가 메시지를 성공적으로 가져오면 Commited라고 한다.

• Consumer는 Commited(ISR상 복제가 완료된 위치) 메시지만 읽을 수 있음.
• Leader는 메시지를 Commit할 시기를 결정
• Committed 메시지는 모든 Follower에서 동일한 Offset을 갖도록 보장.
• 어떤 Replica가 Leader에 관계없이 모든 Consumer는 해당 Offset에서 같은 데이터를 볼 수 있음.

Committed Offset은 replication-offset-checkpoint라는 파일에 기록

 

Leader Epoch

새 Leader가 선출된 시점을 Offset으로 표시

leader-epoch-checkpoint 파일에 체크포인트를 기록

 

Replica Failure

1. Follower가 실패하는 경우
   • Leader에 의해 ISR리스트에서 삭제
   • Leader는 새로운 ISR을 사용하여 Commit
2. Leader가 실패하는 경우
   • Controller는 Follwer중에서 새로운 Leader를 선출
   • Controller는 새 Leader와 ISR 정보를 먼저 zookeeper에 push한 다음 local caching을 위해 broker에 push 함

partition에 Leader가 없을시 사용할 수 없고, retry 설정을 해놓으면 다시 요청하게 된다.

 

Replica Recovery

1. Ack가 all(-1)일 경우
   • Leader가 죽고 ack를 못받았을 경우에 Commited 지점부터 재전송을 시작한다. 여기서 데이터 중복이 일어날 수 있다.
   • 이후, 죽었던 Leader가 복구될 경우 Follower로 합류한다.
   • 기존의 Leader가 변경된 시점부터 삭제한 뒤, 다시 없어진 시점부터 복제하고, ISR로 복귀하게 된다.
2. Ack가 1일 경우
   • Leader가 죽으면 Leader에 들어간 메시지 이후부터 새로운 Leader에 전송이 시작된다.
   • 데이터 유실 가능성 있음.

가용성 vs 내구성

unclean.leader.election.enable = false
# ISR 리스트에 없는 Replica를 Leader로 선출할 것 인지?
# 믿을만한 ISR이 없으면 Leader 선출 x - 서비즈 중단
# true로 할경우 데이터 유실이 있지만 서비스가 중단되진 않는다.

min.insync.replicas = 1
# 최소요구 ISR 개수(보통 2로 설정을 많이 한다.)
# 만족하지 못할경우 producer는 NotEnoughReplicas 예외를 발생 시킨다.
# 보통 ack=all과 함께 사용한다.