06. Replication

Broker 장애 발생

• Broker에 장애가 발생하는 경우 해당 Broker의 Partition을 모두 사용 할 수 없게 된다. → Replication을 통한 장애 대비

Replication

• Partition을 복제(Replication)하여 다른 Broker 상에서 복제물(Replicas)를 만들어서 장애를 미리 대비.

• Leader Partition, Follower Partition으로 구성.

• Producer는 Leader에 Write / Follower는 Leader로부터 Read

• Follower가 Leader의 Commit Log를 Fetch Request한다.

• Apache Kafka 2.4부터 Follower Fetching(Read) 가능

장애 발생

1. Kafka 클러스터는 Follower 중에서 새로운 Leader 선출

2. Clients(Producer/Consumer)는 자동으로 새 Leader로 전환

Partition Leader에 대한 자동 분산(Hot Spot방지)

• 하나의 브로커에 Partition의 Leader들이 몰려 있는 경우, 특정 broker에 부하 집중(Hot Spot)

• Hot Spot 방지 옵션

  • auto.leader.rebalance.enable: 기본값 enable

  • leader.imbalance.check.interval.seconds: 기본값 300 sec

  • leader.imbalance.per.broker.percentage: 기본값 10%

Rack Awareness

• Rack간 분산하여 Rack 장애를 대비

  • 랙(Rack)은 PC나 서버, 통신장비, 각종 계측기 등 일정 시스템을 구성하는 장비들을 보관하고 시스템 구성에 필요한 환경을 만들어주는 제품.

• 동일한 Rack 혹은 Avilable Zone 상의 Broker들에 동일한 “rack name” 지정

• 복제본(Replica-Leader/Follower)은 최대한 Rack 간에 균형을 유지하여 Rack 장애 대비

• Topic 생성시 또는 Auto Data Balancer/Self Balancing Cluster 동작 때만 실행

Rack Awareness를 하는 이유?

데이터의 복사본들이 동일한 랙에 저장이 되면, 스위치(Switch) 장비의 고장이나 정전으로 인하여 복제를 했는데도 마찬가지로 서비스를 받지 못하게 될 수 있다.

이러한 문제를 미연에 방지하기 위해서 데이터 복제본이 클러스터의 어느 장소에 위치시켜야 하는지에 대한 지적인 결정(Intelligent decision)을 해야 한다.