[Kafka] Replication, Leader

토픽 정보

카프카 서버 3개를 띄운 환경

• 각 노드 ID 는 1, 2, 3 으로 지정
• ID 1 → kafka1:9093
• ID 2 → kafka2:19093
• ID 3 → kafka3:29093

• PartitionCount : 해당 토픽의 파티션 수
  • 현재 토픽의 파티션 개수는 1개
• ReplicationFactor : 해당 토픽의 레플리케이션 수
  • 현재 토픽의 복제본 개수는 3개
• Partition: 파티션 번호
  • 현재 토픽의 0번 파티션 내용
• Leader : 해당 토픽의 리더 파티션을 가지고 있는 노드 ID
  • 리더 파티션 (Leader Partition)
    • 복제된 파티션들은 리더 파티션(원본)과 팔로워 파티션(복제본)으로 구분된다
    • 리더 파티션은 프로듀서나 컨슈머가 직접적으로 메시지를 쓰고 읽는 파티션이다. 반면에 팔로워 파티션은 프로듀서나 컨슈머가 직접적으로 메시지를 쓰고 읽지 않는다
    • 팔로워 파티션은 리더 파티션의 메시지를 실시간으로 복제하며 유지한다
    • 리더 파티션에 장애가 발생하면 팔로워 파티션이 리더 역할(프로듀서로부터 메시지를 받고, 컨슈머가 메시지를 처리)을 대신 수행한다
    • 이미 팔로워 파티션은 리더 파티션 내부에 있는 메시지까지 복제해서 가지고 있기 때문에, 리더 파티션의 노드가 중간에 장애가 나더라도 메시지는 정상적으로 이어서 처리할 수 있다
• Replicas : 해당 토픽의 파티션을 복제하기로 설정된 노드들의 ID
  • 3개의 복제본으로 나뉘어 있음 (1, 2, 3)
• Isr (In-Sync-Replicas) : 리더 파티션과 똑같은 상태로 복제(동기화)가 완료된 노드들의 ID
  • 복제를 못한다면 해당 값에서 제외된다
  • Replicas 의 숫자의 개수와 해당 값의 개수가 맞지 않으면 장애가 발생한다는 걸 유추할 수 있다

팔로워 파티션에 메시지를 넣으면 어떻게 되는가?

• 실제 테스트를 통해서 확인해본 결과 팔로워 파티션을 가진 카프카 서버에서 메시지를 생성해도 제대로 생성되며 각 카프카 서버에서 소비할 수도 있다는 것을 확인했다

• 사실은 Kafka 프로듀서는 메시지를 보내기 전에 해당 파티션의 리더가 누구인지 확인하고, 자동으로 리더 파티션에 메시지를 전송한다.
  • 프로듀서가 브로커에 연결되면, 그 브로커는 클러스터 메타데이터(파티션 → 리더 매핑 정보) 를 응답
  • 프로듀서는 이 메타데이터를 보고 실제 메시지를 보낼 때 리더 브로터에 직접 전송한다
• 이게 가능한 이유는 Kafka 노드들끼리 서로 연동되어 있어서, 리더 파티션을 가진 Kafka 노드가 누구인지에 대한 정보를 주고 받을 수 있기 때문이다

카프카 서버 3대를 운영함으로 장점

• 실제로 리더로 선택된 카프카 서버를 중지하고 토픽의 정보를 출력해보자

• 레플리케이션 설정은 1, 2, 3 그대로 이지만 Isr 은 1번 카프카 서버(리더) 를 중지했으므로 동기화되지 않았다는 정보가 출력되었다
• 그리고 자동으로 페일오버 기능을 사용해서 3번 카프카 서버가 리더로 승격되었다
• 이후 다시 "test" 라는 메시지를 넣고 소비되는 것을 보니 한대의 서버가 장애를 일으켜도 정상적으로 운영되는 것을 확인할 수 있다

• 다시 1번 카프카 서버(kafka1:9093)를 실행한 뒤 이전에 메시지를 잘 읽는지도 테스트해보니 제대로 읽는 것을 확인했다

카프카 서버의 대수는

• 서버는 많이 운영할수록 서비스 장애가 발생할 확률이 줄어들지만 중요한건 비용이 그만큼 늘어난다는 것 이다
• 그러므로 서버 대수를 잘 판단해야 한다
• Kafka 1대를 운영해도 서비스를 아예 운영하지 못할 상황이 생기는게 아니라면 1대를 운영하는 것도 좋은 방법이다
• 만약 장애 상황이 크게 발생해서 서비스에 문제가 생긴다면 최소 3대 이상을 운영하는 것도 방법이다 이 경우 장애 발생이 카프카 운영 비용보다 큰 경우 선택할 수 있는 방안이다