Kafka의 인기 중 하나는 Broker의 장애에 대한 강력한 내구성을 제공하는 데에 있습니다.
Kafka는 실패에 대응하여 가동 시간과 데이터 정확성을 유지하기 위해 복제를 핵심 기능으로 설계되었습니다.

Kafka Topic Replication

• Kafka Replication이란 동일한 데이터를 둘 이상의 Broker에 기록하여 데이터 손실을 방지합니다.

Kafka Topic Replication Factor

• Kafka에서 복제란 데이터가 하나의 Broker뿐만 아니라 여러 Broker에 기록되는 것을 의미합니다.
• replication factor는 topic의 설정이며, topic 생성 시에 설정됩니다.
• replication factor가 1인 경우는 복제가 없음을 의미합니다. 이는 주로 개발 목적으로 사용되며 테스트 및 프로덕션 Kafka Cluster에서는 피하는 것이 좋습니다.
• replication factor가 3인 경우는 일반적으로 사용되는 것으로, Broker 손실과 복제 오버헤드 사이의 적절한 균형을 제공합니다.
• 아래 그림의 Cluster는 3개의 Broker로 구성되어 있으며 replication factor는 2입니다.
  Topic-A의 Partition 0에 메시지가 Broker 101에 기록될 때, Partition 0이 복제본으로 있는 Broker 102에도 동일한 메시지가 기록됩니다.
  
• replication factor가 2인 덕분에 하나의 Broker 고장에 견딜 수 있습니다. 따라서 아래 그림에서 보는 것처럼 Broker 102가 실패하더라도 Broker 101 및 103에는 여전히 데이터가 남아 있을 것입니다.
  

Kafka Partition Leader && Replicas는 무엇인가?

• 주어진 Topic-Partition에 대해 Cluster에서는 클라이언트와 데이터를 주고받을 책임이 있는 Kafka Broker가 지정됩니다. 해당 Broker는 해당 Topic Partition Reader Broker로 알려집니다.
  해당 파티션에 대한 복제된 데이터를 저장하고 있는 다른 모든 Broker는 Replica로 참조됩니다.
• 따라서 각 파티션은 하나의 리더, 여러 개의 레플리카를 갖습니다.

In-Sync Replicas ISR은 무엇인가?

• ISR은 파티션의 Reader Broker와 함께 최신 상태인 복제본입니다.
• Reader와 최신 데이터를 가지지 못하는 레플리카는 동기화되지 않은 것으로 간주됩니다.
  
  • Partition 0 Reader로 Broker 101을, Partition 1 Reader 로 Broker 102를 가지고 있습니다. Broker 102는 Partition 0의 레플리카이며, Broker 103은 Partition 1의 레플리카입니다.
  • Reader Broker가 실패하면 Replica 중 하나가 선출되어 새로운 Partition Reader가 됩니다.

Kafka producers acks 설정

• Kafka Producer는 파티션의 현재 Reader Broker에만 데이터를 기록합니다.
• 또한 Kafka Producer는 메시지가 성공적으로 기록되기 위해 최소한의 레플리카 수에 기록되어야 하는지를 지정하기 위해 확인 수준(acks)을 명시해야 합니다.

  Kafka v.30의 Default acks 값

  • Kafka v3.0 에서는 acks 기본값이 변경되었습니다.
  • kafka < 3.0 : acks=1
  • kafka ≥ 3.0 : acks=all

acks = 0

• acks=0 은 Producers는 Broker가 메시지를 전혀 수락할 때까지 기다리지 않고 메시지가 전송된 순간을 메시지를 “성공적으로 기록된 것”으로 간주합니다.
  
• 만약 Broker가 오프라인 상태가 되거나 예외가 발생하면, 우리는 알 수 없고 데이터를 잃게 될 것입니다. 이는 메트릭 수집과 같이 메시지를 잠재적으로 잃어도 괜찮은 데이터에 유용하며, 네트워크 오버헤드가 최소화되므로 가장 높은 처리량 설정을 제공합니다.

acks = 1

• acks = 1일 때, Producers는 메시지가 Reader에 의해 확인됐을 때 메시지를 “성공적으로 기록된 것”으로 산주합니다.
  
• Reader 응답이 요청되지만 복제는 보장되지 않으며 백그라운드에서 발생합니다. 만약 ack를 받지 못하면 Producer는 요청을 다시 시도할 수 있습니다. Reader Broker가 예기치 않게 오프라인 상태가 되지만 레플리카가 데이터를 아직 복제하지 않은 경우 데이터 손실이 발생합니다.

acks = all

acks = all일 때, Producer는 메시지가 모든 ISR에서 수락되었을 때 메시지를 “성공적으로 기록된 것”으로 간주합니다.

• 파티션의 Reader 레플리카는 메시지를 안전하게 기록할 충분한 in-sync replicas가 있는지 확인합니다.
  (Broker 설정 min.insync.replicas 에 의해 제어됨) Reader가 추적하는 동안 요청은 Reader가 follower 레플리카가 메시지를 복제한 것을 확인하는 순간에 클라이언트로 성공적인 확인이 반환될 때까지 버퍼에 저장됩니다.
• min.insync.replicas는 Topic 및 Broker 수준에서 구성할 수 있습니다. 데이터는 모든 in-sync-replica에 기록되면(즉, min.insync.replicas 이상), 커밋된 것으로 간주됩니다. 값이 2이면 적어도 2개의 ISR 레플리카(리더 포함)가 데이터를 갖고 있다고 응답해야 합니다.
• 커밋된 데이터를 두 개 이상의 레플리카에 기록하려면 최소 in-sync replica 수를 더 높은 값으로 설정해야 합니다. Topic에 세 개의 레플리카가 있고 min.insync.replicas를 2로 설정하면 세 개 중 최소 2개의 레플리카가 in-sync인 경우에만 해당 Topic의 파티션에 데이터를 기록할 수 있습니다. 3개의 레플리카가 모두 in-sync 상태인 경우에는 모든 것이 정상적으로 진행됩니다. 하지만 레플리카 중 2개가 사용 불가능한 경우 Broker는 더 이상 Producer 요청을 수락하지 않게 됩니다. 데이터를 전송하려는 Producers는 NotEnoughReplicasException을 받게 됩니다.
  

Kafka Topic 내구성(Durability) && 가용성(Availability)

• Topic의 replication factor가 3이라면, Topic 데이터 내구성은 최대 2개의 Broker 손실을 견딜 수 있습니다. 일반적인 규칙으로, replication factor가 N인 경우 N-1개의 Broker를 영구적으로 손실해도 데이터를 복구할 수 있습니다.
• 가용성 측면에서는 조금 더 복잡합니다.

ex) replication factor가 3인 경우

• Reads: 최소 하나의 파티션이 ISR로 간주되고 있으면 Topic은 읽기용으로 사용 가능합니다.
• Writers
  • acks=0 or acks=1: 최소 하나의 파티션이 ISR로 간주되고 있으면 Topic은 쓰기용으로 사용 가능합니다.
  • acks=all
    • min.insync.replicas=1(default)
      • Topic은 적어도 하나의 파티션이 ISR로 간주되어 있어야 하며(이는 reader 포함), 따라서 두 개의 Broker가 다운된 상황을 견딜 수 있습니다.
    • min.insync.replicas=2
      • Topic은 적어도 2개의 ISR이 작동 중이어야 하며, 따라서 최대 1개의 Broker 다운 상황을 견딜 수 있습니다.(replication factor가 3인경우), 또한 매 쓰기마다 데이터가 적어도 2번 기록되는 것을 보장합니다.
    • min.insync.replicas=3
      • 이는 replication factor가 3인 경우에는 별다른 의미가 없으며, 어떤 Broker 하나도 다운되는 것을 허용할 수 없습니다.
• 요약하면, acks=all, replication factor: N이고 min.insync.replicas가 M일 때, Topic 가용성 목적으로는 N-M개의 Broker 다운을 견딜 수 있습니다.

  Kafka Topic Replication Settings

  • acks=all, min.insync.replicas=2 는 데이터 지속성 가용성 측면에서 가장 많이 사용되는 설정 값이며 최대 1개의 Kafka Broker 손실을 견딜 수 있습니다.

Kafka Consumers 복제본 가져오기

• Kafka Consumer는 기본적으로 Partition Reader로 부터 읽습니다.
  
• 그러나 Apache Kafka 2.4부터는 Consumer가 동일하게 Partition Reader 대신에 ISR에서 읽도록 구성할 수 있습니다. (대신 가장 가까운)
• 가장 가까운 ISR(동기화 복제본)에서 읽는 것은 요청 지연을 개선하고 대부분의 클라우드 환경에서는 데이터 센터 간의 네트워크 요청에 비용이 발생하기 때문에 네트워크 비용을 감소시킬 수 있습니다.
  

선호 리더(Preferred leader)

• 기본 Reader는 Topic 생성 시에 파티션에 대한 지정된 Reader Broker입니다.(레플리카 아닌)

  선호 리더 선출
  Topic 생성 시 어떤 Broker가 Reader인지를 결정하는 프로세스를 선호 리더 선출이라고 합니다.

• 선호 리더가 다운되면 ISR인 모든 파티션이 새로운 리더가 될 수 있지만, 선호 리더 브로커를 복구하고 해당 파티션 데이터를 다시 동기화한 후에는 선호 리더가 해당 파티션의 리더 자격을 되찾게 됩니다.