Project | 실시간 배달 주문 데이터 처리 - Kafka Broker 추가

이전 포스팅까지의 구현으로 목표로 했던 구현은 완료했으나 계속해서 개선할 점이 보여 수정한 부분이 있다.

Kafka Broker 추가

만약 단일 브로커 환경에서 장애가 발생하면 데이터 손실이 발생한다. 실시간 데이터를 다루는 프로젝트에서는 매우 치명적인 결함이다. 따라서 브로커를 추가했다. 브로커는 총 3대이다. Replication factor를 추가해 partition을 복제해두고 리더 장애 발생 시 다시 리더를 선출할 수 있도록 했다. 즉, 한 대의 브로커에서 장애가 발생해도 다른 브로커가 있기 때문에 고가용성을 유지할 수 있다.

Topic 정보를 확인해보면 partition은 1개, replication factor는 3으로 설정되어 있다. 현재 해당 파티션에 리더 ID는 2이고 복제본이 1, 2, 3 브로커에 있다는 것을 확인할 수 있다. 리더, 팔로워 그룹 역시 1, 2, 3으로 구성되어 있어 데이터가 동기화된 것을 알 수 있다.

Leader에 장애가 발생했을 때

만약 리더에 장애가 발생했을 때 어떤 변화가 있을지 확인했다. 확인을 위해 리더 파티션 브로커 컨테이너를 종료했다.

리더가 다시 선출된 것을 확인할 수 있다. 복제본이 1, 2, 3에 있지만 동기화 그룹에서는 2가 빠져있다.

로그도 확인할 수 있다.

 

껐던 브로커 컨테이너를 다시 작동시키면

ISR 업데이트로 동기화 그룹에 다시 ID 2가 포함되는 것을 확인할 수 있다.

Replication Offset Checkpoint

replication-offset-checkpoint 파일에는 토픽의 각 파티션에 대한 복제 오프셋 정보가 저장된다. 복제된 메시지의 위치를 나타내는 값이다.

 

1. 메시지가 publish되면 리더 파티션에 저장되고 나머지 팔로워 파티션에 복제

2. 복제가 성공했음을 인지하면 리더는 해당 메시지를 커밋

3. 커밋된 메시지의 오프셋 정보 replication-offset-checkpoint 파일에 저장

 

마지막 커밋 오프셋 위치가 저장되어 있기 때문에 리더와 팔로워 간 메시지의 최신 상태를 유지할 수 있다. 브로커 장애 발생 후 재시작 시 파일의 정보를 사용해 파티션을 빠르게 복구할 수 있다. 커밋되지 않은 메시지는 consumer가 소비할 수 없으므로 일관성이 유지된다.

메시지가 publish될 때 broker1, broker3 동일 토픽의 커밋 오프셋을 확인해보면 모두 동일하다. 중간에 broker2를 강제로 종료했다.  broker2를 재시작 했을 때 정상적으로 복구 되었으면 커밋 오프셋이 165, 즉 다른 브로커들의 파티션 복제 오프셋 값과 동일해야 한다.

 

broker2를 재시작하고 다시 확인해보면

커밋 오프셋이 모두 동일한 것을 확인할 수 있다.