[대규모 시스템 설계] Kafka의 기초

Kafka 기본 개념 정리

1. Kafka Cluster와 Broker

• Cluster: 여러 Kafka Broker가 모여서 이루어지는 것. Broker는 하나의 Kafka 서버를 의미.
• Broker: 데이터를 저장하고, Producer로부터 데이터를 받아와 Consumer에게 전달하는 역할을 수행.

2. Consumer Lag

• Lag: Producer가 데이터를 추가하는 속도가 Consumer가 데이터를 소비하는 속도보다 빠를 때, 마지막으로 소비된 오프셋(offset)과 마지막으로 추가된 오프셋 간의 차이. Consumer의 상태를 파악하는 데 중요한 지표로 사용됨.

3. Topic과 Partition

• Topic: Kafka에서 데이터를 저장하고 관리하는 단위.
• Partition: Topic을 분할한 단위. 각 Partition은 독립적으로 읽기와 쓰기가 가능하며, 생성 후 추가만 가능하고 줄일 수는 없음.

4. Record

• Producer가 보내는 데이터의 단위. Record는 타임스탬프, 메시지 키, 메시지 값, 오프셋, 헤더로 구성됨. 브로커에 적재된 Record는 수정이 불가능하며, 설정된 로그 리텐션 기간이나 용량에 따라 삭제됨.

5. Controller와 Coordinator

• Controller: 클러스터의 브로커 중 하나가 Controller 역할을 하며, 다른 브로커의 상태를 관리하고 브로커 장애 시 파티션을 재분배함.
• Coordinator: 특정 브로커가 Coordinator 역할을 하여 Consumer 그룹의 상태를 체크하고 파티션을 Consumer에게 분배하는 작업(리밸런스)을 수행함.

6. 데이터 삭제

• Kafka에서는 데이터가 소비되어도 토픽의 데이터는 삭제되지 않으며, 브로커 설정에 따라 삭제 가능.
• retention.bytes와 retention.ms 옵션을 통해 데이터의 보존 크기와 시간을 조정 가능.

7. Replication Factor

• 파티션의 복제본 개수를 지정하는 값. 읽기와 쓰기는 리더 파티션을 통해서만 수행되며, 복제본을 유지하기 위해 리더와 팔로워 개념이 존재.

8. Leader와 Follower

• Leader: 모든 읽기와 쓰기 작업을 처리.
• Follower: 주기적으로 리더의 데이터를 복제하여 데이터를 유지.

9. ISR (In-Sync Replicas)

• 팔로워가 리더로부터 데이터를 복제하고, 리더 장애 시 데이터를 복제하지 못한 팔로워를 ISR에서 제거하는 방식으로 데이터 정합성을 보장.

1. Producer가 리더에게 메세지를 보내면 팔로워가 리더로부터 메세지를 복제
2.  
3. Broker 2 팔로워는 복제를 했지만, Broker 3 팔로워에는 문제가 생겨 복제를 하지 못함
4.  
5. 메세지를 받은 후에 리더 브로커는 Producer 에게 ack 응답으로 돌려줌
6.  
7. 설정한 값 만큼 확인 요청이 오지 않는다면, 문제가 있는 팔로워를 ISR 그룹에서 제거
8.  

10. Producer 주요 옵션

• bootstrap.servers: Kafka 클러스터에 연결하기 위한 호스트와 포트 정보.
• acks: 메시지의 성공 여부를 리더가 확인하는 수준.
  • ack=0: 응답 기다리지 않음.
  • ack=1: 리더만 확인.
  • ack=all: ISR 내 모든 팔로워가 확인.
• min.insync.replicas: 성공으로 간주되기 위해 메시지를 쓰기 위해 필요한 최소 복제본 수. 즉, 최소 리플리케이션을 유지해야 하는 수
• 예시
  • ack=all, min.insync.replicas=1min.insync.replicas 옵션이 1 이기 때문에, 프로듀서가 리더에게 메세지를 보냈을 때 리더는 최소 1개의 브로커에게만 메세지를 잘 받았는지 확인하면 된다. 즉, 리더 자신 하나가 잘 받았기 때문에 바로 ack를 응답
  •  
  • ack=all, min.insync.replicas=2리더는 팔로워에게 메세지가 잘 복제되었는지 확인한다. min.insync.replicas 옵션이 **2**이기 때문에 리더 1개, **팔로워 1개**만 확인
  •  
  따라서, Kafka는 ack=all일 때, min.insync.replicas=2로 권장하고 있다.min.insync.replicas 옵션이 2 라면 위와 같이 하나의 브로커가 문제가 생겨도 클러스터 전체 장애로 이어지지 않는다. 하지만 min.insync.replicas 옵션을 **3**을 사용했을 때는 하나의 브로커에 문제가 생겨도 클러스터 전체 장애로 이어지게 된다. 그렇기 때문에 **ack=all**를 사용할 때 브로커 설정 min.insync.replicas=2 옵션 사용을 권장하고 있다.
•  

11. Consumer 주요 옵션

• group.id: Consumer가 속한 그룹을 식별하는 ID.
• enable.auto.commit: 오프셋을 주기적으로 자동 커밋할지 여부.
• auto.offset.reset: 초기 오프셋이 없거나 현재 오프셋이 없을 경우의 동작 옵션.
• max.poll.records: 단일 poll() 호출에 대한 최대 레코드 수.
• max.poll.interval.ms: Consumer 그룹에서 Consumer가 poll() 메소드를 호출하지 않을 때 장애로 간주하는 시간.

12. Consumer Group

• Consumer Group은 Kafka에서 동일한 작업을 수행하는 Consumer들의 집합. 하나의 토픽(Topic)에 대해 여러 Consumer Group이 동시에 메시지를 가져갈 수 있음.
• 동일한 Consumer Group 내에서 Consumer를 추가하거나 제거하면, 각 Consumer가 담당하는 Partition의 소유권이 바뀌게 됨. 이러한 소유권 이동을 리밸런스라고 함.
• 리밸런스를 통해 Consumer Group은 Consumer를 안전하게 추가하거나 제거할 수 있어, 높은 가용성과 확장성을 제공.
• 리밸런스가 발생하면, 해당 Consumer Group 내의 모든 Consumer는 일시적으로 메시지를 가져올 수 없음.
• 컨슈머가 컨슈머 그룹 안에서 멤버로 유지하고 할당된 파티션의 소유권을 유지하는 방법은 하트비트를 보내는 것이다. 즉, 컨슈머가 일정한 주기로 하트비트를 보낸다는 사실은 해당 파티션의 메세지를 잘 처리하고 있다는 것 → 만약 컨슈머가 오랫동안 하트비트를 보내지 않으면 세션은 타임아웃되고 해당 컨슈머가 다운되었다고 판단하여 리밸런스가 시작
• 여러 컨슈머 그룹들이 하나의 토픽에서 메세지를 가져갈 수 있는 이유는 컨슈머 그룹마다 각자의 오프셋을 별도로 관리하기 때문 → 즉, 하나의 토픽에 두 개의 컨슈머 그룹뿐만 아니라 더 많은 컨슈머 그룹이 연결되어도 다른 컨슈머 그룹에게 영향 없이 메세지를 가져갈 수 있다는 특징 (Kafka의 가장 중요한 특징!! RabbitMQ는 Queue라서 메시지가 사라진다.)
• 단순히, Consumer만 늘리거나, Partition만 늘린다고 메시지 처리량이 늘지 않는다. 왜냐하면 한 파티션은 하나의 컨슈머만 연결이 가능하기 때문. 즉, 컨슈머를 늘리고 싶으면 토픽의 파티션도 늘려야 됨.
•  

13. Zookeeper의 역할

• Controller election: 리더 선출 시 메타데이터를 참조.
• Configuration of Topics: 파티션 수, 복제본 위치, 설정 재정의 정보 등을 관리.
• Access control lists: 사용자 역할과 관련된 권한 정보를 관리.
• Membership of the cluster: 클러스터의 일부인 모든 브로커의 목록을 유지 및 관리
  • • • • • •