[KAFKA] APACHE KAFKA 기초

책 '실전 아파치 카프카'를 보며 정리한 내용

 

2.1 구성 내용

1. 메시지 송수신 기본
2. 시스템 구성
3. 분산 메시징을 위한 구조
4. 데이터 견고함을 담보하는 복제의 구조

 

 

2.2 메시지 송수신 기본

카프카의 주요 구성 요소

• 브로커
  • 데이터를 수신, 전달하는 서비스
• 메시지
  • 카프카에서 다루는 데이터 최소 단위.
• 프로듀서
  • 데이터의 생산자, 브로커에 메시지를 보내는 애플리케이션
• 컨슈머
  • 브로커에서 메시지를 취득하는 애플리케이션
• 토픽
  • 메시지를 (토픽)별로 관리하는 스토리지. 브로커에 배치되어 관리된다.

 

 

2.3 시스템 구성

브로커

• 브로커 하나의 서버(또는 인스턴스) 당 하나의 데몬 프로세스로 동작.
• 여러대의 클러스터로 구성 가능. 브로커를 추가함으로 처리량 향상(스케일 아웃)이 가능.
• 브로커에서 받은 데이터는 모두 디스크로 내보내기(영속화)가 이루어져 디스크의 총 용량에 따라 장기간 데이터 보존

 

프로듀서 API/컨슈머 API

• 구현하는 기능은 '라이브러리'로 제공.
• 서비스(데몬 프로세스)로 작동하는 프로그램은 아니다.
• API는 자바로 제공.

 

프로듀서

• 프로듀서 API를 통해 브로커에 데이터를 송신하는 애플리케이션
• 프로듀서 기능을 내장 or 플러그인 제휴를 통해 제공하는 OSS(Open Source Software)의 종류
  1. Apache Log4j
  2. Apache Flume
  3. Fluentd
  4. Logstash

 

컨슈머

• 컨슈머 API를 통해 브로커에서 메시지를 취득하는 애플리케이션
• 디스크에 보관되어 있는 동안 메시지 취득이 가능.(임의의 타이밍)
• 카프카 연계를 위한 컨슈머 기능을 갖춘OSS의 종류
  1. Apache Spark
  2. Apache Samza
  3. Apache Flink
  4. Apache Flume
  5. Fluentd
  6. Logstash

 

주키퍼

• 카프카의 브로커에 있어 분산 처리를 위한 도구
• 카프카에 있어서는 분산 메시징의 메타데이터(토픽과 파티션 등)를 관리하기 위한 구성요소.
• 주키퍼 클러스터의 구조상 홀수로 구성하는 것이 일반적.

 

카프카 클라이언트

• 토픽 작성 등 카프카의 동작 및 운영 상에 필요한 조작을 실행하는 서버.
• 메시지의 송수신 관리 X

 

카프카 클러스터

• 앞으로의 정리에는 브로커, 주키퍼에 의해 구성된 클러스터 시스템으로 정의한다.

출처 :  실전 아파치 카프카

 

 

2.4 분산 메시징을 위한 구조

 

파티션

• 브로커상의 데이터를 읽고 쓰기위한 분할 단위.
• 토픽을 구성하는 파티션은 브로커 클러스터 안에 분산 배치.
• 각 파티션의 배치 정보는 브로커 측에 유지.
• 프로듀서API/컨슈머API가 파티션을 은폐해서 통신.(의식할 필요X)

 

컨슈머 그룹

• 단일 어플리케이션 안에서 여러 컨슈머가 단일 토픽이나 여러 파티션에서 메시지를 취득하는 방법
• 카프카 클러스터 전체에서 글로벌 ID를 컨슈머 그룹 전체에서 공유, 여러 컨슈머는 자신이 소속한 컨슈머 그룹을 식별해, 읽어들일 파티션을 분류하고 재시도를 제어.

 

오프셋

• 각 파티션에서 부여한 메시지의 일련번호.
• 제어에 사용되는 오프셋의 종류
  1. Log-End-offset(LEO) : 파티션 데이터의 끝을 나타낸다.
  2. Current Offset : 컨슈머가 어디까지 메시지를 읽었는가를 나타낸다.
  3. Commit Offset : 컨슈머가 어디까지 커밋했는지를 나타낸다.
• LEO는 브로커에 의해 관리 및 업데이트.
• Current Offset은 컨슈머 그룹마다 보관되어 관리 및 업데이트.
• Commit Offset은 컨슈머의 오프셋 커밋요청을 계기로 업데이트. 특정 토픽에 대해 여러 컨슈머 그룹이 메시지를 취득하는 경우 파티션에 대한 Commit Offset도 컨슈머 그룹 숫자만큼만 존재한다.

 

2.4.1 메시지 송수신

• 어느 정도 메시지를 축적하여 batch 처리로 송신, 수신하는 기능 제공
• 프로듀서의 메시지 송신
  • trigger : 1. 지정한 크기까지 메시지가 축적 2. 지정한 대기 시간에 도달하는 것
  • 기본 설정 : 하나의 메시지는 1회 송신 작은 단위의 메시지는 batch로 송신함으로 처리 효율 증가. 크기가 큰 텍스트 or 로그 파일에 포함된 레코드 또한 같은 형식으로 송신, 처리 효율 증가.
• Consumer의 메시지 취득
  • 취득 대상의 Topic과 파티션에 대해 Current Offset으로 나타나는 위치에서 마지막으로 취득한 메시지부터 브로커에 보관중인 최신 메시지까지 모아서 요청 및 취득을 실시.

Producer와 Consumer에서 모두 배치 처리함으로 처리 향상을 기대할 수 있지만, 시스템에 따라 처리 지연을 고려해 설계해야 한다.

 

2.4.2 Consumer의 rollback

• Offset Commit 구조를 통해 Consumer치리 실패, 고장 시 rollback 메시지 다시 취득 실현.

1. Offset 2까지 취득해 Offset Commit이 끝난 단계에서 3,4,5의 메시지를 취득.
2. Consumer 처리가 끝나 OffsetCommit을 실행하고, Commit Offset을 5까지 진행. ========= 여기까지 정상 동작 =========
3. Consumer에서 처리 중 Offset Commit을 실행하기 전에 Consumer에서 장애 발생.
4. Consumer가 장애에서 복구 되면 Commit Offset부터 재개
5. 메시지를 다시 취득 한다.

메시지 처리 완료 상태에서 Commit Offset 업데이트 직전의 고장의 경우 메시지 중복 처리(또는 중복 허용)가 필요하다.

고장의 감지, 복구 또한 Kafka 제공이 아니므로, 연계 기능을 제공하는 분산 처리 Framework를 활용

 

2.4.3 메시지 전송 시 Partitioning

• Producer에서 송신하는 메시지를 어떻게 파티션으로 보낼지 결정하는 분할 기능이 제공된다.

1. Key의 hash 값을 사용한 송신 동일한 Key를 가진 메시지는 동일한 ID를 가진 파티션에 송신
2. Key의 종류가 충분하지 않은 때는 파티션에 편향이 발생하여 resource를 부분적으로 사용할 수 없는 상태가 된다.
3. Round Robin에 의한 송신 메시지 key를 지정하지 않고 Null로 한 경우 여러 파티션으로의 메시지 송신을 RR방식으로 실행.

브로커의 데이터 보관 기간

데이터 삭제 정책

1. 오래된 메시지 삭제 시간, 분, 밀리 초 등으로 지정 가능. 지정한 시간보다 오래된 데이터가 삭제된다.
2. 압축 최신 Key의 데이터를 남겨두고 중복되는 Key의 오래된 메시지가 삭제된다. (항상 최신의 Value만 얻을 수 있으면 되는 상황에서 사용 가능)

 

 

2.5 데이터의 견고성을 높이는 복제 구조

Kafka는 메시지를 잃지 않기 위해 복제(Replication)구조를 갖고 있다.

출처 :  실전 아파치 카프카

Topic = 1, Partition =1 인 상황

• Replica 중 하나는 Leader이며, 나머지는 Follower라 한다.
• Producer/Consumer와의 데이터 교환은 Leader가 맡고 있다.

 

2.5.1 Replica 동기 상태

• In-Sync Replica : Leader Replica의 복제 상태를 유지하고 있는 Replica (ISR로 표기되기도 한다.)
• Under Replicated Partitions : 모든 Replica가 복제 상태를 유지하지 않은 파티션

 

2.5.2 복제 완료 최신 Offset(High Watermark)

• 복제 사용 시 High Watermark는 복제가 완료된 Offset으로 반드시 LEO(Log End Offset)와 동일 하거나 오래된 Offset을 나타낸다.

 

2.5.3 Producer의 메시지 도달 보증 수준

• Ack : Broker에서 Producer로 메시지가 송신한 것을 나타낸다.
• Ack를 송신하는 타이밍은 성능과 내장애성(Broker 서버 고장 시 분실 방지)에 큰 영향을 준다.
• Ack 설정1 : Leader Replica에 메시지가 전달되면 Ack를 반환.
• all : 모든 ISR의 수만큼 복제되면 Ack를 반환한다.
• 0 : Producer는 메시지 송신 시 Ack를 기다리지 않고 다음 메시지를 송신.

---

• 이곳의 타이밍은 디스크에 flush 되는 것이 아닌 메모리(OS 버퍼)에 기록. 디스크에 flush(영속화)하는 타이밍은 다른 속성에서 제어.

 

2.5.4 In-Sync Replica와 Ack = all, 쓰기 계속성의 관계

출처 :  실전 아파치 카프카

 

 

2.6 정리

출처 :  실전 아파치 카프카

• 스케일 아웃 구성
  • 메시지를 중계하는 브로커를 여러 대 구성할 수 있으며, 브로커 수를 증가함으로 전체의 처리량을 증가시킬 수 있다.
• 데이터의 디스크 영속화
  • 브로커에서 수신한 메시지는 디스크에 기록되어 영속화된다. 디스크 용량에 따라 장기간의 과거 데이터를 저장, 재취득이 가능.
• 연계할 수 있는 제품 존재
  • Producet/Consumer 를 구현하기 위한 API가 제공되어 이를 구현한 OSS가 다수 존재.
• 메시지의 도달 보증
  • Ack와 Offset Commit 방식으로 메시지가 제대로 송수신되었음을 확인하고 재시도를 허용.