Kafka

What is Kafka?

Apache Kafka is an open-source distributed event streaming platform used by thousands of companies for high-performance data pipelines, streaming analytics, data integration, and mission-critical applications. More than 80% of all Fortune 100 companies trust, and use Kafka.

Apache Kafka는 수천 개의 회사에서 고성능 데이터 파이프라인, 스트리밍 분석, 데이터 통합 및 중요한 응용 프로그램에 사용되는 오픈 소스 분산 이벤트 스트리밍 플랫폼입니다. 포춘 100대 기업의 80% 이상이 Kafka를 신뢰하고 사용하고 있습니다.

Why named Kafka?

People often ask how Kafka got its name and if it signifies anything specific about the application itself. Jay Kreps offered the following insight:

I thought that since Kafka was a system optimized for writing, using a writer’s name would make sense. I had taken a lot of lit classes in college and liked Franz Kafka. Plus the name sounded cool for an open source project.

So basically there is not much of a relationship.

사람들은 종종 Kafka가 어떻게 그 이름을 얻었는지, 그리고 그 이름이 애플리케이션 자체에 대해 어떤 특정한 의미를 갖는지 묻곤 합니다. Jay Kreps는 다음과 같은 통찰을 제공했습니다:

"Kafka가 글쓰기에 최적화된 시스템이기 때문에 작가의 이름을 사용하는 것이 의미가 있을 것이라고 생각했습니다. 저는 대학에서 많은 문학 수업을 들었고 Franz Kafka를 좋아했습니다. 또한 그 이름은 오픈 소스 프로젝트로서 멋지게 들렸습니다."

그래서 기본적으로 특별한 관련성은 없습니다.

The Origin of Kafka

• LinkedIn에서 사이트 전반에 걸쳐 대량의 활동 데이터를 처리하는 데 문제 겪고 있었습니다.
  • 폴링 기반 시스템 및 애플리케이션 메트릭 수집(CPU 사용량, 애플리케이션 성능 등)
  • 모든 서비스의 로그 집계
  • 배치 기반 사용자 활동정보 추적(서버가 주기적으로 HTTP call)
  • 페이지 뷰 등 이벤트 추적에 대한 데이터 수집
  • inMail 메시징 시스템용 이메일 대기열
  • 프로필 업데이트 할 때마다 검색 시스템의 데이터 최신화
• 지속적인 데이터 스트림을 실시간으로 처리하기 위해 확장 가능하고 신뢰할 수 있는 솔루션이 필요해졌습니다. (ActiveMQ를 검토하였으나 브로커가 중단 되는 등 문제가 있었음)
• 결국 확장 가능하고, 장애 내성이 있으며, 초당 수백만 개의 메시지를 처리할 수 있도록 설계한 Kafka를 개발 함. 결국 Kafka는 LinkedIn의 데이터 아키텍처의 핵심 부분이 되었습니다.
• Kafka의 성공은 LinkedIn을 넘어 오픈 소스 프로젝트로 발전하여 Apache Swftware Foundation의 관리하에 채택, 다양한 산업 분야에서 강력한 스트리밍 기능으로 인기를 얻으며 계속 발전하고 있습니다.
  • 2010년말 GitHub에 오픈소스로 공개
  • 2011년 7월 Apache Software Foundation 인큐베이터 프로젝트로 제안 및 승인
  • 2012년 10월 인큐베이터 졸업 후 많은 기여자와 커미터를 통해 견고한 커뮤니티 형성
  • 2014년 가을 Confluent 설립(LinkedIn에서 Kafka를 개발한 사람들이 떠나서 설립)
  • Netflix, Uber 등 셰게 최대의 데이터 파이프라인에서 사용됨
  • 수 많은 오픈소스 파생 : Cruise Control, Monitor, Burrow, ksqlDB, Schema Registry, REST Proxy 등

The Architecture of Kafka

일반적으로 Kafka가 pub-sub 메시징 미들웨어로 사용되는 시나리오에서는 세 가지 중요한 구성 요소가 있습니다.

1. Producer - 프로듀서는 Kafka에 이벤트를 발행(쓰기)하는 클라이언트 애플리케이션
2. Broker - 들어오는 메시지를 처리하고 이를 브로커 파티션에 기록하여 컨슈머가 읽을 수 있도록 하는 역할
3. Consumer - 컨슈머는 이러한 이벤트를 구독(읽기 및 처리)하는 애플리케이션

참고로, Kafka는 이벤트 스트리밍 플랫폼으로 위치하고 있기 때문에, 메시지 큐에서 자주 사용되는 "메시지"라는 용어는 Kafka에서 사용되지 않습니다. 대신, 이를 "이벤트"라고 부릅니다. Kfaka에서 "메시지"는 "데이터의 단위"입니다.

Key Point!

이벤트는 세상이나 비즈니스에서 "무언가가 발생했다"는 사실을 기록한 것입니다. 문서에서는 이를 레코드 또는 메시지라고도 부릅니다. Kafka에 데이터를 읽거나 쓸 때, 이는 이벤트의 형태로 수행됩니다. 개념적으로, 이벤트는 키, 값, 타임스탬프, 그리고 선택적인 메타데이터 헤더를 가집니다. 예시 이벤트는 다음과 같습니다:

이벤트 키: "Alice"

이벤트 값: "Bob에게 $200 결제를 했다"

이벤트 타임스탬프: "2020년 6월 25일 오후 2시 6분"

아래의 다이어그램은 Kafka의 아키텍처와 클라이언트 API 구조를 상세히 보여줍니다. 프로듀서, 컨슈머, 그리고 브로커가 여전히 아키텍처의 핵심이지만, 고처리량과 저지연의 Kafka를 구축하기 위해서는 더 많은 요소들이 필요하다는 것을 알 수 있습니다.

고수준 추상레벨 에서 볼 때, 아키텍처에는 두 개의 레이어가 있습니다: 컴퓨트 레이어와 스토리지 레이어입니다.

Compute Layer

컴퓨트 레이어, 또는 처리 레이어는 다양한 애플리케이션이 API를 통해 Kafka 브로커와 TCP 통신할 수 있도록 합니다. 자주 사용하는 API와 특징은 아래와 같습니다.

• Admin API - 토픽, 브로커 및 기타 Kafka 객체를 관리하고 검사하는 데 사용
• Producer API - 하나 이상의 Kafka 토픽에 이벤트 스트림을 발행(쓰기)하는 데 사용
• Consumer API - 하나 이상의 토픽을 구독(읽기)하고 생성된 이벤트 스트림을 처리하는 데 사용
• Streams API - 스트림 처리 애플리케이션과 마이크로서비스를 구현하는 데 사용됩니다. 이벤트 스트림을 처리하기 위한 고급 기능을 제공하며, 변환, 집계 및 조인과 같은 상태 기반 연산, 윈도우 처리, 이벤트 시간 기반 처리 등을 포함합니다. 입력은 하나 이상의 토픽에서 읽어 들여 하나 이상의 토픽으로 출력하여 입력 스트림을 출력 스트림으로 효과적으로 변환
• Connect API - 외부 시스템 및 애플리케이션에서 이벤트 스트림을 소비(읽기)하거나 생산(쓰기)하여 Kafka와 통합할 수 있도록 재사용 가능한 데이터 가져오기/내보내기 커넥터를 구축하고 실행하는 데 사용됩니다. 예를 들어, PostgreSQL과 같은 관계형 데이터베이스에 대한 커넥터는 특정 테이블 세트의 모든 변경 사항을 캡처할 수 있습니다. 하지만 실제로는 직접 커넥터를 구현할 필요가 없으며, Kafka 커뮤니티에서 이미 제공하는 수백 개의 사용 가능한 커넥터를 사용할 수 있음

Storage Layer

이 레이어는 Kafka 브로커로 구성됩니다. Kafka 브로커는 여러 클러스터에서 실행됩니다. 데이터는 다양한 토픽의 파티션에 저장됩니다. 토픽은 데이터베이스의 테이블과 유사하며, 토픽 내의 파티션읕 클러스터 노드에 분산될 수 있습니다. 파티션 내에서는 오프셋에 따라 엄격히 순서가 정해집니다.

Kafka 브로커의 책에서는 파티션 관리, 읽기 및 쓰기, 그리고 파티션 복제 관리가 포함됩니다. 클러스터 모드로 배포되기 때문에, 노드 관리를 위해 두 가지 필수 구성 요소가 있습니다.

• Control Plane - Kafka 클러스터의 메타데이터를 관리
• Data Plane - 데이터 복제를 처리

How a broker works

우리는 브로커를 스토리지 레이어로 논의했습니다. 데이터는 토픽으로 조직되고 브로커의 파티션으로 저장됩니다. 이제 브로커가 어떻게 작동하는지 자세히 살펴보겠습니다.

단계 1 - 프로듀서는 브로커로 요청을 보냅니다. 이 요청은 먼저 브로커의 소켓 수신 버퍼에 도착합니다.

단계 2와 3 - 네트워크 스레드 중 하나가 소켓 수신 버퍼에서 요청을 가져와 공유 요청 큐에 넣습니다. 이 스레드는 특정 프로듀서 클라이언트에 바인딩되어 있습니다.

단계 4 - Kafka의 I/O 스레드 풀은 요청 큐에서 요청을 가져옵니다.

단계 5와 6 - I/O 스레드는 데이터의 CRC를 검증하고 이를 커밋 로그에 추가합니다. 커밋 로그는 디스크에 세그먼트로 구성되어 있습니다. 각 세그먼트에는 실제 데이터와 인덱스의 두 부분이 있습니다.

단계 7 - 프로듀서의 요청은 복제를 위해 일시적으로 대기 구조(purgatory)에 저장됩니다. 이를 통해 I/O 스레드는 다음 요청을 처리할 수 있게 됩니다.

단계 8 - 요청이 복제되면 대기 구조에서 제거됩니다. 응답이 생성되어 응답 큐에 넣어집니다.

단계 9와 10 - 네트워크 스레드는 응답 큐에서 응답을 가져와 해당 소켓 송신 버퍼로 보냅니다. 네트워크 스레드는 특정 클라이언트에 바인딩되어 있습니다. 요청에 대한 응답이 전송된 후에야 네트워크 스레드는 해당 클라이언트로부터 다른 요청을 처리합니다.

이 과정을 통해 브로커는 효율적으로 데이터를 처리하고 요청에 응답할 수 있습니다.

Event Streaming VS Message Broker

https://amecoder.hashnode.dev/kafka-vs-rabbitmq

Terms and Concept

• 메시지(Message): Kafka의 데이터 단위로, 바이트 배열로 구성되며 특정 형식이나 의미를 가지지 않습니다.
• 키(Key): 선택적인 메타데이터로, 메시지를 특정 파티션에 제어된 방식으로 분배 및 기록하기 위해 사용됩니다.
• 배치(Batch): 동일한 토픽과 파티션으로 전송되는 메시지 모음으로, 네트워크 오버헤드를 줄이고 효율성을 높이기 위해 사용됩니다.
• 스키마(Schema): 메시지 내용에 구조를 부여하여 이해하기 쉽게 만듭니다.(JSON, XML) Avro 직렬화 프레임워크를 추천합니다.
• 토픽(Topic): 카프카에서 메시지는 토픽으로 분류됩니다. 토픽의 가장 가까운 유사체는 데이터베이스의 테이블이나 파일 시스템의 폴더입니다. 토픽은 여러개으 파티션으로 나뉩니다.
• 파티션(Partition): Topic의 분산된 저장소로써 역할은 아래와 같습니다.
• 쓰기 및 읽기: 메시지는 파티션 끝에 추가되며, 처음부터 끝까지 순서대로 읽힙니다.
• 순서 보장: 파티션 내에서만 메시지 순서가 보장됩니다. 전체 토픽에 걸친 순서 보장은 없습니다.
• 확장성: 각 파티션은 다른 서버에 호스팅될 수 있습니다. 따라서 단일 토픽은 여러 서버에 걸쳐 수평적으로 확장되어, 단일 서버의 성능 한계를 넘어설 수 있습니다.
• 중복성: 파티션은 복제될 수 있습니다. 이는 다른 서버가 동일한 파티션의 복사본을 저장하여, 한 서버가 장애를 겪을 경우를 대비할 수 있음을 의미합니다.
• 프로듀서(Producer): 프로듀서는 새로운 메시지를 생성합니다. 다른 pub/sub 시스템에서는 이를 발행자(publishers) 또는 작성자(writers)라고 부를 수 있습니다. 메시지는 특정 토픽에 생성됩니다. 기본적으로 프로듀서는 메시지를 토픽의 모든 파티션에 균등하게 분배합니다. 경우에 따라 프로듀서는 메시지를 특정 파티션으로 보냅니다. 이는 일반적으로 메시지 키와 파티셔너를 사용하여 키의 해시 값을 생성하고 이를 특정 파티션에 매핑함으로써 이루어집니다. 이렇게 하면 주어진 키로 생성된 모든 메시지가 동일한 파티션에 기록되도록 보장됩니다. 프로듀서는 또한 메시지를 파티션에 매핑하기 위한 다른 비즈니스 규칙을 따르는 사용자 지정 파티셔너를 사용할 수 있습니다
• 컨슈머(Consumer): 컨슈머는 메시지를 읽습니다. 다른 pub/sub 시스템에서는 이를 구독자(subscribers) 또는 독자(readers)라고 부를 수 있습니다. 컨슈머는 하나 이상의 토픽을 구독하고 각 파티션에 생성된 순서대로 메시지를 읽습니다. 컨슈머는 메시지의 오프셋을 추적하여 이미 소비한 메시지를 기록합니다. 오프셋은 메시지가 생성될 때 Kafka가 각 메시지에 추가하는 지속적으로 증가하는 정수 값입니다. 주어진 파티션의 각 메시지는 고유한 오프셋을 가지며, 다음 메시지는 더 큰 오프셋을 가집니다(반드시 단조롭게 증가하지는 않습니다). 각 파티션의 다음 가능한 오프셋을 Kafka 자체에 저장함으로써, 컨슈머는 위치를 잃지 않고 중지 및 재시작할 수 있습니다.
• 컨슈머 그룹(Consumer Group): 컨슈머는 하나 이상의 컨슈머가 함께 작업하여 토픽을 소비하는 컨슈머 그룹의 일부로 작동합니다. 그룹은 각 파티션이 한 멤버에 의해서만 소비되도록 보장합니다. Figure 1-6에서는 하나의 그룹에서 세 명의 컨슈머가 하나의 토픽을 소비하고 있습니다. 두 명의 컨슈머는 각각 하나의 파티션을 담당하고 있으며, 세 번째 컨슈머는 두 개의 파티션을 담당하고 있습니다. 컨슈머가 파티션에 매핑되는 것을 종종 파티션 소유권이라고 합니다.

Kafka Top 5 Usecases