카프카 팬싱이란? (fencing)

카프카 트랜잭션의 팬싱(Fencing)은 트랜잭션 프로듀서 간의 중복 방지 및 일관성 보장 메커니즘입니다. 이 기능은 트랜잭션 ID(transactional.id)를 기반으로 작동하며, 특정 트랜잭션이 잘못되거나 장애 상황이 발생했을 때, 중복 트랜잭션 프로듀서가 메시지를 잘못 기록하는 것을 방지합니다.

---

1. 팬싱이 필요한 이유

트랜잭션 프로듀서는 상태를 유지하며 트랜잭션 ID(transactional.id)를 통해 클러스터와 연관됩니다. 이때 다음과 같은 상황에서 중복 프로듀서가 발생할 수 있습니다:

• 프로듀서 장애로 인해 클러스터와 연결이 끊긴 경우.
• 네트워크 지연 또는 일시적인 장애로 기존 프로듀서가 복구되지 못했는데, 동일한 transactional.id로 새 프로듀서가 시작된 경우.

이 상황에서 두 프로듀서가 동시에 같은 transactional.id를 사용해 메시지를 보내면 데이터 불일치 또는 중복 기록 문제가 발생할 수 있습니다. 팬싱은 이런 문제를 방지하기 위한 장치입니다.

 

2. 팬싱의 동작 방식

팬싱은 Producer ID (PID)와 Epoch라는 두 가지 메타데이터를 사용하여 동작합니다:

Producer ID (PID)

• 프로듀서가 시작될 때 카프카 브로커에서 부여받는 고유 ID.
• 동일한 transactional.id를 사용하는 프로듀서는 항상 동일한 PID를 공유하지 않습니다.

Epoch

• PID와 함께 관리되는 버전 번호로, 특정 transactional.id와 연관됩니다.
• Epoch은 프로듀서가 새로 시작될 때마다 증가합니다.
• 클러스터는 최신 Epoch를 확인하여 새로운 프로듀서만 허용하고, 이전 Epoch를 사용하는 프로듀서는 팬싱(Fenced) 처리하여 트랜잭션 작업을 차단합니다.

 

3. 팬싱의 트랜잭션 처리 과정

1. 프로듀서 시작:
   • 새 프로듀서가 transactional.id를 등록하면 브로커는 PID와 Epoch를 부여합니다.
2. 트랜잭션 진행 중 장애 발생:
   • 기존 프로듀서가 장애로 클러스터와 연결이 끊기거나 응답하지 않는 경우.
3. 새 프로듀서 시작:
   • 동일한 transactional.id로 새 프로듀서가 시작되면, 브로커는 Epoch를 증가시켜 새로운 PID와 Epoch를 부여.
4. 팬싱 동작:
   • 클러스터는 이전 Epoch를 사용하는 프로듀서를 차단하여 메시지 생산 및 트랜잭션 작업을 중단시킴.

 

4. 팬싱이 보장하는 것

중복 방지

• 트랜잭션 ID와 Epoch를 통해 동일 트랜잭션의 중복 메시지 기록을 방지.

일관성 유지

• 장애 발생 시에도 새로운 프로듀서만 메시지를 기록하도록 보장하여 데이터 불일치 방지.

 

5. 팬싱 예시

정상 시나리오:

1. 프로듀서 A는 transactional.id="txn-1"로 메시지 생산 시작.
2. 브로커는 PID=1234와 Epoch=1을 부여.

장애 발생 후 팬싱:

1. 프로듀서 A 장애로 연결이 끊김.
2. 프로듀서 B가 동일한 transactional.id="txn-1"로 시작.
3. 브로커는 PID=5678과 Epoch=2를 부여.
4. 기존 Epoch=1을 가진 프로듀서 A는 팬싱 처리되어 작업 차단.

 

6. 팬싱 설정 관련

• 팬싱은 기본적으로 트랜잭션 ID를 사용하면 활성화됩니다.
• 프로듀서 구성:

  Properties props = new Properties();
  props.put("transactional.id", "my-transaction-id");
  KafkaProducer<String, String> producer = new KafkaProducer<>(props);
  producer.initTransactions();

 

7. 요약

• 팬싱(Fencing)은 중복 트랜잭션 프로듀서를 방지하고, 트랜잭션 ID와 Epoch를 통해 트랜잭션의 일관성을 보장하는 메커니즘입니다.
• 카프카는 Epoch를 통해 항상 최신 프로듀서만 활성 상태로 유지하며, 잘못된 프로듀서의 작업을 차단하여 데이터 무결성을 보호합니다.