Replication

💡 이번 포스팅에서는 Replication에 대해 정리해 보도록 하겠습니다.

 

이전 멀티 노드 카프카 - 1, 멀티 노드 카프카 - 2 포스팅에서 토픽 생성 시 replication-factor 옵션을 통해 토픽의 각 파티션들을 여러 브로커에 복제해 보았습니다.

 

이번 포스팅에서는 파티션 복제, Replication에 대해 조금 더 자세하게 정리해 보도록 하겠습니다.

 

멀티 노드 카프카의 핵심은 바로 Replication입니다. Replication을 통해서 개별 노드(브로커)의 장애를 대비하여 높은 가용성을 제공할 수 있기 때문입니다.

 

Replication은 토픽 생성 시 replication-factor 값을 통해 구성할 수 있습니다.

만약 replication-factor가 3이면 리더 파티션, 팔로워 파티션을 포함해 모두 3개의 파티션을 가짐을 의미하며, 브로커 3개에 replication-factor가 3일 경우 총 9개의 파티션 정보가 생성됩니다.

 

출처: https://damdam-kim.tistory.com/17

 

그리고 replication-factor의 개수는 브로커의 총개수보다 클 수 없습니다.

 

replication-factor에 의해 생성될 때 리더 파티션, 팔로워 파티션을 구분하는데 토픽에 대한 read/write는 모두 리더 파티션과 이루어지며,

복제 방향은 리더 파티션 → 팔로워 파티션 방향으로 복제가 진행됩니다.

 

 

리더 파티션과 팔로워 파티션의 단계별 Replication

카프카로 향하는 수많은 메시지를 읽고 쓰기를 처리하는 리더는 매우 바쁘게 동작합니다. 이렇게 바쁜 리더가 Replication 동작을 위해 팔로워 파티션들과 많은 통신을 주고받거나 Replication 동작에 많은 관여를 한다면, 결과적으로 리더의 성능은 떨어지고 카프카의 장점인 빠른 성능을 내기도 어려울 것입니다. 따라서 카프카는 리더와 팔로워 간의 Replication 동작 처리할 때 서로의 통신을 최소화할 수 있도록 설계함으로써 리더의 부하를 줄였습니다.

 

위 그림에서 peter-test01 토픽이 1개의 파티션과 3개의 Replication Factor를 가지고 있음을 알 수 있습니다.

현재는 리더 파티션만이 0번 오프셋에 message1이라는 메시지를 갖고 있는 상태입니다.

리더만 메시지를 저장하고 아직 팔로워들은 리더에게 저장된 메시지를 Replication 하기 전입니다.

 

 

팔로워들은 리더에게 0번 오프셋 메시지를 가져오기(fetch) 요청을 보낸 후 새로운 메시지 message1이 있다는 사실을 인지하고 message1 메시지를 Replication 하는 과정입니다.

현 상태에서 리더는 모든 팔로워가 0번 오프셋 메시지를 Replication 하기 위한 요청을 보냈다는 것을 알고 있지만, 팔로워들이 0번 오프셋에 대한 Replication 동작을 성공했는지 실패했는지 여부는 알지 못합니다.

 

메시징 큐 시스템 중 래빗 MQ의 트랜잭션 모드에서는 모든 미러(팔로워)가 메시지를 받았는지에 대한 ACK를 리더에게 리턴하므로, 리더는 미러(팔로워)들이 메시지를 받았는지 알 수 있습니다.

하지만 카프카의 경우에는 리더와 팔로워 사이에서 ACK를 주고받는 통신이 없습니다. 오히려 카프카는 리더와 팔로워 사이에 ACK 통신을 제거함으로써 Replication 동작의 성능을 더욱 높였습니다.

 

 

다음 리더는 1번 오프셋의 위치에 두 번째 새로운 메시지인 message2를 프로듀서로부터 받은 뒤 저장합니다.

0번 오프셋에 대한 Replication 동작을 마친 팔로워들은 리더에게 1번 오프셋에 대한 Replication을 요청합니다. 팔로워들로부터 1번 오프셋에 대한 Replication 요청을 받은 리더는 팔로워들의 0번 오프셋에 대한 Replication 동작이 성공했음을 인지하고, 오프셋 0에 대해 커밋 표시를 한 후 하이워터마크를 증가합니다.

 

📢 하이워터마크 (High Water Mark)

하이워터마크란 팔로워 파티션에서 복제가 완료된 오프셋 위치를 의미합니다.

 

팔로워들로부터 1번 오프셋에 대한 Replication 요청을 받은 리더는 응답에 0번 오프셋 message1 메시지가 커밋되었다는 내용도 함께 전달합니다.

📢 팔로워가 0번 오프셋에 대한 Replication을 성공하지 못했다면, 팔로워는 1번 오프셋에 대한 Replication 요청이 아닌 0번 오프셋에 대한 Replication 요청을 보내게 됩니다.
따라서 리더는 팔로워들이 보내는 Replication 요청의 오프셋을 보고, 팔로워들이 어느 위치의 오프셋까지 Replication을 성공했는지 인지할 수 있습니다.

 

Replication의 마지막 과정으로, 리더의 응답을 받은 모든 팔로워는 0번 오프셋 메시지가 커밋되었다는 사실을 인지하게 되고, 리더와 동일하게 커밋을 표시합니다. 그리고 1번 오프셋 메시지인 message2를 Replication 합니다.

이런 과정을 계속 반복하며 동일한 파티션 내의 리더와 팔로워 간 메시지의 최신 상태를 유지하게 됩니다.

 

💡Replication 과정서 중요한 점은 다른 메시징 시스템들과 달리 카프카는 ACK 통신 단계를 제거했다는 사실입니다.

예를 들어 메시지 하나를 Replication 하는 데 총 2회의 ACK 통신을 주고받는다고 가정하면 1,000개의 메시지는 2,000회의 ACK 통신이 필요하며, 1만 개의 메시지는 2만 회의 ACK 통신이 필요합니다. 이렇게 ACK 통신을 제외한 카프카의 리더는 메시지를 주고받는 기능에 더욱 집중할 수 있습니다.

그리고 ACK 통신을 제외했음에도 리더, 팔로워 간의 Replication 동작이 매우 빠르면서도 신뢰할 수 있다는 것도 장점입니다. 카프카에서 리더와 팔로워들의 Replication 동작 방식은 리더가 푸시(push)하는 방식이 아닌 팔로워들이 풀(pull)하는 방식으로 동작하는데, 풀 방식을 채택한 이유도 Replication 동작에서 리더의 부하를 줄여주기 위해서입니다. 

 

 

 

참고 자료

• <실전 카프카 개발부터 운영까지> - 고승범 지음
• <인프런 카프카 완벽 가이드 - 코어편> - 권철민