Kafka의 이해1 - 배경부터 기본 용어 설명

나는 이번에 참여하는 프로젝트에서 Micro Service Architecture를 사용하기로 했기에
데이터 동기화 문제를 해결하기 위해 Kafka를 공부하게 되었다.

Kafka의 탄생 배경 

링크드인이라는 사이트가 급속도로 성장하게 되면서 시스템 유지 문제가 발생하였고
   소스 애플리케이션과 데이터가 최종 적재되는 Target 애플리케이션과 연결하는 복잡성이 있었다.

위와 같이 시스템이 복잡해질수록 아래와 같은 End-to-End 시스템의 문제점이 발생한다.

• 데이터 전송 파이프라인이 기하급수적으로 복잡해짐
• Src-to-Target 파이프라인 개수가 많아지면서 소스코드 및 버전 관리 이슈 발생
• target app에 문제가 발생할 경우, Source app에도 영향을 줌 (높은 결합도)
• 다양한 ETL(Extract Transform Load) 툴을 적용하여 개선의 노력을 했으나 완벽한 해결책이 되지 못함

 

Kafka 

고성능 데이터 파이프라인, 스트리밍 분석, 데이터 통합 및 미션 크리티컬 애플리케이션을 위해 설계된
고성능 분산 이벤트 스트리밍 플랫폼

목표

• 메시지를 생성하는(Producer) 곳과 소비하는(Consumer) 곳의 분리
• 메시징 시스템과 같이 영구 메시지 데이터를 여러 Consumer에게 허용
• 높은 처리량을 위한 메시지 최적화
• 데이터가 증가함에 따라 스케일아웃이 가능한 시스템

활용

• 로그기록
  • 현대의 IT 서비스는 디지털 정보로 기록되는 모든 것을 저장
  • 쇼핑몰의 결제 내역, 방문한 위치 정보, 댓글 등 모든 발자취를 기록
• 다양한 형태의 데이터 처리
  • 스키마 기반의 정형 데이터
  • 비정형 데이터(그림, 영상, 음성)
  • 빅데이터를 처리하기 위한 선행 작업(한 곳에 데이터 모으기 - Data Lake)
• Extract, Transforming, Load(ETL) 하는 과정을 묶은 데이터 파이프라인 구축
  • 파이프라인을 구축하지 않으면 데이터 수집은 파편화 됨

구조

내부 구조

• Producer: 메시지 생산
• Consumer: 메시지 소비
• Broker(Server): 메시지 전달
• Zookeeper: 분산 시스템의 메타 정보를 관리

 

Kafka 기본 용어

1. Topic

• 데이터의 주제를 나타내는 논리적인 개념 (파일 또는 디렉터리와 같은 물리적 대상이 아님)
• 관계형 데이터베이스의 테이블과 유사
• 여러 개의 Partition으로 쪼개질 수 있음
• Key-Value 기반의 메시지 구조

1-1. Topic의 이름 제약 조건

• 빈 문자열 불가능하고 영문, 숫자, '.', '_', '-' 로만 이루어져야 함
• 마침표와 언더바가 동시에 들어가면 안됨
• ex.topic이 존재할 때 ex_topic은 생성 불가능함.

1-2. Topic 이름 권장 사항 (토픽만으로도 데이터가 유추 가능하도록)

• <환경>.<팀-명>.<애플리케이션-명>.<메시지-타입>
• <프로젝트-명>.<서비스-명>.<환경>.<이벤트-명>
• <카프카-클러스터-명>.<환경>.<서비스-명>.<메시지-타입>

2. Partitions

• Topic은 여러 파티션으로 나눠질 수 있음
• 개별 파티션은 서로 완전히 분리되어 있음
• 카프카에서 토픽은 논리적인 개념이고, 파티션은 토픽에 속한 레코드를 실제 저장소에 저장하는 단위
• 각각의 파티션은 Append-Only(차례대로 쌓이는) 방식으로 기록되는 하나의 로그 파일
• 수정, 중간 요소 삭제 등이 없으므로(immutable) 구조가 간단하며 성능이 높다.

3. Offset

파티션 내에서 데이터의 위치를 표시하는 유니크한 정수형 숫자

• 카프카의 consumer가 poll()을 호출할 때마다, 카프카에 저장되어 있지만 아직 읽지 않은 메시지들을 가져옴
  • 하나의 메시지 단위를 Record라고 함.
• 카프카는 consumer group 단위로 offset을 관리
• Producer로부터 메시지가 생성되면 오프셋 숫자는 하나씩 증가
• 개별 파티션내에서 정렬되고 offset이 할당됨
• Consumer는 토픽에서 메시지를 읽은 후 읽었다는 커밋을 표시함

4. Partition Replication

• 토픽의 파티션들이 여러개의 분산 브로커에 저장됨 ( 복제가 발생하면 파티션은 Leader와 Follower로 구분)
• Producer는 메시지를 Leader로만 전달

replication factor가 2일 때

• 파티션들은 어떤 브로커에 존재하는 파티션이 리더가 될지 모르며 리더 선출은 Zookeeper가 진행
• 카프카의 데이터 복제는 파티션 단위로 이루어짐
• 토픽을 생성할 때 파티션의 복제 개수 설정
• 복제 개수의 최솟값은 1 (복제 없음), 최대값은 브로커 개수만큼
• 복제된 파티션은 Leader와 Follower로 구성
  • Leader: Producer 또는 Consumer와 직접 통신하는 파티션
  • Follower: 복제본을 가지고 있는 파티션
• Follower들은 Leader의 Offset을 확인하여 현재 자신이 가지고 있는 Offset과 차이가 있는 경우, 복제를 시도
• 당연하지만, 복제 개수만큼 저장 용량이 증가
• 하나의 Leader가 장애가 발생하면 ISR 중에서 새 Leader가 선출됨

5. Controller

• 클러스터의 다수 브로커 중 하나가 컨트롤러의 역할을 수행
• 컨트롤러는 다른 브로커들의 상태를 체크하고 브로커가 클러스터에서 빠지는 경우 해당 브로커에 존재하는 리더 파티션을 재분배
• 컨트롤러에 문제가 생기는 경우에는 Zookeeper가 다른 브로커를 컨트롤러로 선출함

6. 데이터 삭제

• Consumer가 데이터를 가져가더라도 토픽의 데이터는 삭제 안됨
• Consumer나 Producer가 데이터 삭제를 요청할 수 없음 ( 브로커만 삭제 권한을 가짐 )
• 데이터 삭제는 파일 단위로 이루어지며 이 단위를 Log Segment라고 부름

7. Segment

• 파티션은 세그먼트로 구성됨 (파티션(세그먼트1, 세그먼트2))
•  다수의 데이터가 들어있으므로 일반적인 데이터베이스처럼 특정데이터를 선별해서 삭제할 수 없음
• 세그먼트는 크기가 기본적으로 1GB이며 조절 가능함
• 너무 작은 용량으로 설정하면 데이터들을 저장하는 동안 세그먼트 파일을 자주 여닫음으로써 부하가 발생하므로 주의해야 함.
• 파티션당 하나의 Segment가 활성화됨

8. 부트스트랩 서버

• 클러스터에 존재하는 모든 브로커는 BootStrap Server라고 부름
• Client가 특정 하나의 Broker에만 연결하면 자동으로 Broker가 Broker 전체 List를 전달
• Client는 이 정보를 통해서 내가 접속해야(Read/Write) 하는 Topic 그리고 그 Topic을 구성하는 Partition이 어디에 있는지 알게되고 Client는 자동으로 자기가 필요한 Broker들로 연결

9. Zookeeper

• Zookeeper는 Broker를 관리하는 소프트웨어
• 클러스터 내의 Broker들의 목록/설정 관리, 토픽 목록 관리, 파티션 관리
• 주키퍼 없이는 카프카가 동작할 수 없음

9-1. Zookeeper Failover

• Zookeeper가 홀수 서버로 작동하게 설계되는 이유는 Quorum(정족수) 알고리즘 기반 때문
• Quorum은 합의체가 의사를 진행시키거나 의결을 하는데 필요한 최소한도의 인원수
• Distributed Coordination 환경에서 예상치 못한 장애가 발생하더라도 분산 시스템의 일관성을 유지

10. Broker

• 카프카 클라이언트와 데이터를 주고받기 위해 사용하는 주체
• Producer와 Consumer 사이에서 메시지를 저장, 전달하는 역할
• 한 대 이상의 노드로 클러스터를 구성할 수 있음

카프카 장점

1. 높은 처리량

• 대용량의 실시간 로그데이터를 처리하는데 적합
• 배치처리: Producer -> broker, broker -> consumer 데이터를 묶어서 전송
• 파티션을 통한 병렬처리: 파티션 개수만큼 프로듀서 연결
  • 하지만 파티션의 수가 많아지면 장애 복구 시간이 증가
• Append-Only 기반 Simple한 데이터 구조

2. 확장성

• 데이터 파이프라인에서 데이터를 모을 때 들어오는 데이터 크기를 예측하기 어려운데
  카프카 클러스터 내의 브로커 구성을 유연하게 변경 가능하게 해줌 ( scale-in, scale-out)
• scale-in, scale-out은 무중단 운영을 지원

3. 고가용성

• 3개 이상의 서버들로 운영되는 카프카 클러스터는 일부 서버에 장애가 발생하더라도 무중단으로 안전하고 지속적으로 데이터를 처리
• Replication 지원 ( 대부분의 시스템이 고가용성을 제공하는 방식)
• 데이터가 복제되는 시간 차이로 인해 일부 데이터가 유실될 가능성이 있음

4. 영속성

• 프로그램이 종료되더라도 데이터가 사라지지 않음
• 다른 메시징 플랫폼과 다르게 전송 받은 데이터를 메모리에 저장하지 않고 파일 시스템에 저장
• Page Cache 사용
  • 운영체제에서는 파일 I/O 성능 향상을 위해 페이지 캐시 영역을 메모리에 생성함
  • producer가 서버인 broker에게 넣는 데이터는 consumer가 사용하기 전 일정시간동안 Page Cache에 올려 두어, consumer가 데이터를 읽어가는 속도를 빠르게 함

토픽의 적절한 파티션 수는?

파티션 개수의 증가는 언제든 가능하지만 감소하는 방법은 제공하지 않으므로 초기에 파티션 개수를 작게 잡고 점차 늘려야 함