* 이 글은 인프런 - [데브원영] 아파치 카프카 for beginners (무료) 강의를 기반으로 작성되었습니다.

브로커(broker), 복제(replication), ISR(In-Sync-Replication)은 카프카 운영에 있어 아주 중요한 역할을 한다.

Replication

: 복제. 파티션의 복제

• 카프카 아키텍처의 핵심이다! 왜냐하면, 클러스터에서 서버에 장애가 생겼을 때 카프카의 가용성을 보장하는 가장 좋은 방법이 복제이기 때문이다.

Broker

: 카프카가 설치되어있는 서버 단위

• 보통 3개 이상의 브로커로 구성하여 사용하는 것을 권장한다.

• 만약 partition=1, replication=1인 topic이 존재하고, broker=3대라면 브로커 3대 중 1대에 해당 토픽 정보(데이터)가 저장된다.

• replication = 1인 경우 : partition = 1개

• replication = 2 : partition = 원본 1개 + 복제본 1개

• replication = 3 : partition = 원본 1개 + 복제본 2개

다만, 브로커 개수에 따라 replication 개수가 제한된다. 브로커 개수가 3이면 replication은 4가 될 수 없다.

• leader 파티션 : 원본 1개의 파티션

• follower 파티션 : 나머지 2개의 파티션

• ISR(In-Sync-Replica) : 리더 파티션과 팔로워 파티션이 모두 싱크가 된 상태

왜 Replication을 사용하는가?

Replication은 partition의 고가용성을 위해 사용된다.

만약 브로커가 3개인 카프카에서, replication이 1이고, partition이 1인 토픽이 존재한다고 생각해보자.

갑자기 해당 애플리케이션이 사용 못하게 된다면, 더이상 해당 파티션은 복구할 수 없다.

만약 replication이 2이면, 브로커 하나가 죽더라도 follower replication이 승계하게 된다.

Leader Partition & Follower Partition

프로듀서가 파티션에 정보를 저장할 때, 이 정보를 전달받는 주체가 Leader Partition이다.

이 때 프로듀서에는 ack이라는 상세 옵션이 있다. 이 ack를 통해 고가용성을 유지할 수 있는데, 이는 partition의 replication과 관련이 있다.

ack는 0, 1, all 옵션 3개 중 1개를 골라 설정할 수 있다.

💡 Case 1 : ack = 0

이때 프로듀서는 leader partition에 데이터를 전달하고 응답을 받지 않는다.

따라서 leader partition에 데이터가 정상적으로 전송됐는지, 나머지 partition에 정상적으로 복제되었는지 확인할 수 없다.

즉, 작업 속도는 월등히 빠르지만 데이터 유실 가능성이 있다.

💡 Case 2 : ack = 1

이때 프로듀서는 leader partition에 데이터를 전달하고 leader partition에 제대로 데이터가 저장이 되었는지에 대한 응답을 받는다.

따라서 leader partition에 데이터가 정상적으로 전송됐는지를 확인할 수는 있지만, replication에 정상적으로 복제되었는지 확인할 수 없다.

즉, 만약 leader partition이 데이터를 받은 즉시 브로커가 장애가 난다면 나머지 partition에 데이터가 미처 전송되지 못한 상황이므로 응답값은 정상이더라도 복제에 대한 데이터 유실 가능성이 있다.

💡 Case 3 : ack = all

ack = 1 옵션에 추가로 follower partition에도 복제가 잘 이루어졌는지에 대한 응답값도 받는다.

즉, 이 옵션을 사용할 경우 데이터 유실은 없다고 봐도 무방하다. 단, 0, 1에 비해 확인하는 부분이 많기 때문에

Replication의 개수?