카프카 운영 - Preferred Replica Election

들어가며

 브로커의 장애는 카프카 운영에서 발생하는 가장 흔한 장애입니다. 이번 글은 브로커 장애로 발생할 수 있는 복제 파티션의 역할 변경과 Preferred Replica Election 방법에 대해 설명합니다.

Preferred Replica Election

Leader & Follower

 토픽은 파티션 단위로 나눠지고, 파티션은 복제 계수(replication factor)에 따라 복제 파티션을 구성합니다. 복제 파티션들은 하나의 Leader(리더)와 그 외의 Follower(팔로워) 형태로 역할을 나눠 구성합니다. 리더 파티션은 복제된 파티션 중 유일하게 메세지 쓰기와 읽기 작업을 담당하여 수행하며, 팔로워들은 리더가 쓰기 작업을 완료한 메세지들을 복제(replication)합니다.

 혹시 모를 장애에 대응하기 위해 복제 파티션을 여러 브로커에 위치시킵니다.

복제 파티션의 브로커 위치 설정

복제 파티션들은 가용성을 위해 여러 브로커에 분산되어 위치합니다. 일반적으로 복제 파티션의 위치는 파티션 생성 시에 자동적으로 설정되지만, 운영자가 수동적으로 위치를 지정해줄 필요도 있습니다. 가장 대표적인 예로 카프카 클러스터를 이루는 서버들의 성능이 모두 동일하지 않을 경우입니다.

복제 파티션이 앞으로 변경될 브로커 위치에 대한 설정은 다음 2가지 방법으로 할 수 있습니다.

1. 카프카에서 제공하는 **kafka-reassign-partitions.sh**를 이용한 방법

2.  카프카 매니저(Kafka Manager)의 Topic 메뉴의 **Reassign Partitions**를 이용한 방법

 특히, 1번 방법은 kafka-reassign-partitions.sh 명령어 파라미터에 다음과 같이 JSON 파일을 전달함으로써 복제 파티션의 위치를 설정합니다.

// 파티션 설정 파일 예시 (json 파일)
{
	"version":1,
  	"partitions":[
     	{"topic":"test-topic", "partition":0, "replicas":[1,2,3]},
     	{"topic":"test-topic", "partition":1, "replicas":[2,1,3]},
     	{"topic":"test-topic", "partition":2, "replicas":[3,1,2]} 
 	]
 }

 2번 방법도 마찬가지로 Generate Partition Assignment 혹은 Manual Partition Assignment를 통해 변경할 복제 파티션 위치를 작성한 뒤, Reassign Partitions를 통해 위치를 변경합니다.

Generate Partition Assignment 은 자동 생성

Manual Partition Assignment 은 수동 생성

누가 파티션 리더 할래?

 그렇다면 여러 복제 파티션 중 누가 파티션 리더의 역할을 맡게 될까요? 카프카 매니저(2번)의 경우는 잘 모르겠지만, 쉘 스크립트 방식(1번)은 파라미터로 전달한 JSON 파일의 "replicas: 속성에서 가장 첫 번째 브로커에 위치한 복제 파티션이 리더 역할을 담당합니다. 위 JSON 파일을 예를 들면, 0번 파티션은 1번 브로커에 위치한 복제 파티션이 리더 역할을 담당하게 됩니다. 이처럼 설정을 통해 미리 지정된 리더 파티션을 preferred leader라고 합니다.

장애 상황 발생!

브로커 다운

 복제 파티션 중 리더 파티션만 쓰기, 읽기 작업을 수행할 수 있습니다. 하지만 어떠한 이유로 브로커가 다운 되면, 그 브로커에 위치했던 리더 파티션은 더 이상 작업을 처리할 수 없게 됩니다. 이 때, 죽은 리더를 대신하여 리더 파티션 역할을 담당할 팔로워 파티션을 ISR(In Sync Replica)에서 선출(election)하게 됩니다. 리더 재 선출은 자동적으로 이뤄지며, 카프카는 이러한 장애 대응 방식으로 다운 타임을 없게 합니다.

 참고로 브로커가 다운 되더라도 설정된 복제 계수를 맞추기 위해 자동적으로 다른 브로커에 복제 파티션을 생성하지 않습니다.

브로커 업

 다운됐던 브로커의 장애가 해소되어 다시 클러스터에 합류하면 어떻게 될까요? 만약 리더가 재 선출된 리더 파티션에 새로운 메세지가 들어오지 않았다면, 오프셋 등의 정보가 변경되지 않았기 때문에 큰 문제는 없을 것입니다. 하지만 새로운 메세지가 1개라도 들어오게 되면 복구된 브로커에 있던 파티션과 기존 파티션들과 차이가 생깁니다. 즉, 되살아난 브로커는 ISR에서 제외된 OSR(Out Sync Replica)가 됩니다.

 만약 OSR 상태에서 브로커가 되살아나게 되면, 복구된 브로커에 있던 파티션들은 모두 팔로워 파티션 역할로 변경됩니다. 이러한 역할 변경이 발생하면 초기에 지정한 파티션 복제 설정과 다른 파티션 복제 구성 상태가 됩니다.

역할 변경이 왜 문제가 될까?

 앞서 잠시 언급했던 것처럼 카프카 클러스터는 모두 동일한 성능의 브로커로 구성되지 않을 수 있습니다. 그래서 운영자가 별도의 파티션 설정을 통해 리더 파티션의 위치를 브로커 서버 성능에 따라 고르지 않게 위치시킬 수 있습니다. 즉, 성능이 좋은 브로커는 리더 파티션이 많게, 반대로 성능이 낮은 브로커는 리더 파티션이 적게 파티션을 설정할 수 있습니다. 그렇기 때문에 복제 파티션의 역할 구성이 기존과 어긋나게 되면 낮은 성능의 브로커에 부하가 몰릴 수 있습니다. 또한 이런 경우에 따라 장애 전이와 같은 위험한 상황이 발생할 수도 있습니다(개인적인 예상입니다).

Preferred Replica Election

 기존과 어긋난 리더-팔로워 역할 구성을 다시 복구하는 명령이 바로 Preferred Replica Election입니다. 이 방법은 마찬가지로 CLI와 카프카 매니저를 통한 GUI 환경에서 실행할 수 있습니다.

 CLI 방식은 카프카에서 제공하는 [kafka-preferred-replica-election.sh](http://kafka-preferred-replica-election.sh)을 이용하여 진행합니다.

root@faa9c20123a0:/# kafka-preferred-replica-election --bootstrap-server broker00:19092
Successfully completed preferred replica election for partitions ...

 카프카 매니저를 이용한 방법은 화면 상단의 Preferred Replica Election 메뉴를 통해 진행할 수 있습니다. 해당 메뉴에서 Run Preferred Replica Election 버튼을 클릭하면 설정에 파티션들의 어긋난 리더 역할을 다시 초기 설정에 맞게 복구합니다. 다음 사진들은 카프카 매니저로 Preferred Replica Election을 진행한 과정입니다.

OSR이 발생하였고, 리더 역할이 초기 설정과 달라져 Preferred Leader?=false 인 상황입니다.

Run Preferred Replica Election  을 통해 실행한 결과입니다.

Replicas 의 첫 번째인 2번 브로커의 복제 파티션이 리더 역할을 담당하여 Preferred Leader?=true 인 상황입니다.

 

마무리

 이번 글을 통해 파티션 역할이 어긋난 상황을 복구하는 Preferred Replica Election을 알아봤습니다. 브로커 중단은 그나마 카프카에서 발생할 수 있는 장애 중 가장 대표적인 장애고, 리더 파티션의 역할을 매우 중요하므로 Preferred Replica Election은 꼭 알아 두어야 할 작업(Operation)일 것 입니다.