Kafka 이벤트 스트리밍 이해하기

 

Kafka 학습 목적으로 전체 내용은

링크된 도서를 참고하여 카프카 핵심가이드 - 제이펍 출판사 - 심재철 옮김 

글을 정리하였습니다

 

 

Kafka 는 이미 많은 기업에서 사용되고 있다

포춘 500대 기업 중 1/3 이상이 카프카를 사용하고 있습니다

 

 

Kafka 만들게 된 이유

스트림(시간이 흐르면서 사용할 수 있게 되는 데이터 요소)으로 데이터를 처리하는 방법에 중점을 둔 시스템을 개발하기 위해서 입니다

Kafka는 실시간으로 데이터 스트림을 수집하여 처리합니다

Kafka 공식 홈페이지 첫 화면에는 Kafka를 '오픈소스 분산 이벤트 스트리밍 플랫폼'으로 표현하고 있습니다

스트리밍 플랫폼(Streaming Platform)은 데이터 스트림을 읽고 쓰고 저장하고 처리하는 역할을 가진 시스템을 의미합니다

kafka는 메시지 스트림을 쓰고 읽게 해주는 메시징 시스템(ActiveMQ, RabbitMQ)과 같습니다

 

 

Kafka 만의 핵심적인 차이 3가지

1. Kafka는 클러스터로 실행됩니다.

 - 서로 다른 애플리케이션을 수동으로 연결하는 많은 개별적인 메시징 브로커들 대신

 - 회사의 모든 데이터 스트림 처리를 위해서 탄력적으로 확장할 수 있는 하나의 ‘중심 플랫폼’ 역할을 합니다.

2. 원하는 기간 동안 데이터를 저장하기 위해 만들어진 스토리지 시스템입니다.

 - 신뢰성 있는 데이터의 전달을 보장하고 있습니다. Kafka 를 서로 다른 시스템의 연결 계층으로 사용할 수 있습니다.

 - Kafka 의 데이터는 복제되고, 영구적이며, 원하는 만큼 보존 가능합니다.

3. 스트림 프로세싱 능력이 있습니다.

 - 메시징 시스템은 단순히 메시지 전달에만 초점을 두었습니다

 - Kafka는 훨씬 더 적은 코드로 스트림으로부터 파생된 다른 스트림과 데이터 세트를 산출해 낼 수 있는 스트림 프로세싱 능력이 있습니다

 

(Stream Processing ??)

연속적으로 들어오는 데이터에 대한 여러 작업을 처리하는 것을 의미합니다.
집계(예: 합계, 평균, 표준 편차와 같은 계산)
분석(예: 데이터의 패턴을 기반으로 미래 이벤트 예측)
변환(예: 숫자를 날짜 형식으로 변경)이 포함됩니다. )
강화(예: 데이터 포인트를 다른 데이터 소스와 결합하여 더 많은 컨텍스트 및 의미 생성)
수집(예: 데이터를 데이터베이스에 삽입)

참고 : https://hazelcast.com/glossary/stream-processing/ 

 

Stream Processing

Stream Processing 은 Hadoop으로 했던 Batch Processing 의 상위 개념입니다

 

Hadoop

Hadoop 은 큰 규모로 파일 데이터를 저장하고 주기적으로 처리할 수 있습니다

Hadoop 의 실시간 버전으로 카프카가 설계되었습니다

 

 

메시지 발행/구독

메시지 '발행/구독 시스템'에서 데이터(메시지)를 ‘발행자'가 직접 ‘구독자’에게 보내지 않습니다

발행자가 어떤 형태로든 메시지를 구분하여 '발행/구독 시스템'에 전송합니다

 

발행/구독 시스템에 전송이 되면 구독자에게 특정 부류의 메시지를 구독할 수 있게 해줍니다

이때, 발행되어진 메시지를 저장하고 중계 역할을 ‘브로커(broker)’가 수행하고 있습니다

 

 

메시지 발행 / 구독 시스템 아키텍처  3가지

1. 발행자, 구독자를 직접 연결하는 시스템 아키텍처

2. 발행/구독 시스템 아키텍처

3. 여러 종류의 발행/구독 시스템 아키텍처

1번 -> 2번 -> 3번

결국, 다수의 메시지 처리 시스템(발행/구독 서버)을 유지 및 관리해야 하는 문제가 발생합니다

 

이 문제를 카프카를 사용하여 해결합니다

일반화된 유형의 메시지 데이터를 발행/구독하는 하나의 집중 처리 시스템으로 만들게 됩니다

하나의 시스템으로 관리하므로 유연성과 확장성이 좋아지게 됩니다

 

 

Kafka의 메시지 데이터

카프카의 메시지 데이터는 ‘토픽(topic)’ 으로 분류된 ‘파티션(partition)’에 수록됩니다.

이때, 데이터를 수록할 파티션을 결정하기 위해 일관된 해시 값으로 키를 생성합니다.

 

메시지 직렬화 프레임워크 Avro

메시지는 JSON, XML 형식을 사용할 수 있습니다

하지만, 타입에 대한 지원이 부족하고 스키마 버전 간의 호환성이 낮은 문제가 있습니다

 

이 문제를 해결하기 위해 Avro 사용합니다

Avro는 데이터를 직렬화하는 형식을 제공합니다

 

메시지와 별도로 스키마를 유지 관리하므로

스키마가 변경되어도 애플리케이션 코드를 수정할 필요가 없습니다

 

Avro는 데이터 타입을 지원합니다

스키마 신/구버전의 호환성을 제공합니다

 

 

토픽(Topic) 과 파티션(Partition)

하나의 토픽은 여러 개의 파티션으로 구성될 수 있습니다

( 로그 관점에서 보면 파티션은 하나의 로그에 해당됩니다 )

메시지는 파티션에 추가만 해주는 형태입니다

추가되는 메시지는 각 파티션 끝에 수록됩니다

메시지 처리 순서는 토픽이 아닌 파티션별 유지, 관리됩니다

파티션은 서로 다른 서버에서 분산하여 처리할 수 있습니다

 

 

Kafka 시스템의 스트림(Stream)

파티션 개수와 상관없이 하나의 토픽 데이터로 간주됩니다.

데이터를 쓰는 Produce로부터 데이터를 읽는 Consumer로 이동되는 연속적인 데이터를 나타냅니다.

 

프로듀서(Producer)와 컨슈머(Consumer)

Consumer는 하나 이상의 Topic을 구독합니다

메시지는 생성된 순서대로 읽으며,

메시지의 오프셋(offset)을 유지하고 있어

읽고 있는 메시지의 위치를 알 수 있습니다

 

오프셋은 지속적으로 증갸하는 정수값 입니다

메시지가 생성될 때 Kafka는 정수값을 추가해줍니다.

 

kafka는 각 파티션의 마지막으로 읽은 메시지의 오프셋을 저장하고 있어

컨슈머가 메시지 읽기를 중단하여도 이어서 읽을 수 있습니다

 

 

컨슈머 그룹 (Consumer Group)

Consumer는 Consumer Group의 멤버로 동작합니다

Consumer Group은 하나 이상의 Consumer로 구성되며

'한 토픽'을 소비하기 위해 '같은 그룹의 여러 컨슈머'가 함께 동작합니다.

한 토픽의 '각 파티션'은 '하나의 컨슈머'만 소비할 수 있습니다

'각 컨슈머'가 '각 파티션'에 대응되는 것을 파티션 소유권(ownership) 이라고 합니다.

 

 

브로커(Broker)와 클러스터(Cluster)

하나의 카프카 서버를 브로커(broker)라고 합니다

브로커(Broker)는 프로듀서(Producer)로부터 메시지(Topic)를 수신하고

오프셋(offset)을 지정한 후 해당 메시지를 디스크에 저장합니다

 

브로커는 컨슈머(Consumer) 읽기 요청에 응답하고 디스크에 수록된 메시지를 전송합니다

하드웨어 성능에 따라 다르지만 초당 수천개의 토픽과 수백만 개의 메시지를 처리할 수 있습니다

 

Kafka의 클러스터는 브로커의 일부로 동작하도록 설계되어 있습니다

여러개의 브로커가 하나의 클러스터에 포함될 수 있습니다

 

그 중 하나는 자동으로 선정되는 클러스터 컨트롤러 기능을 수행합니다

Kafka의 핵심 기능 중 하나는 ‘보존’입니다. 일정기간 메시지를 보존합니다.

기본적으로 토픽을 보존 설정합니다.

 

 

클러스터 컨트롤러 (Cluster Controller)

클러스터 컨트롤러는 같은 클러스터의 각 브로커에게 담당 파티션을 할당합니다.

클러스터 컨트롤러는 브로커들이 정상적으로 동작하는지 모니터링 관리 기능을 맡고 있습니다

 

각 파티션은 클러스터의 한 브로커가 소유하며, 그 브로커를 파티션 리더l(leader)라고 합니다.

같은 파티션이 여러 브로커에 지정될 수 있습니다. 이때는 해당 파티션이 복제됩니다.

파티션의 메시지는 중복으로 저장되지만

한 브로커에 장애가 생기면 다른 브로커가 소유권을 인계받아 그 파티션을 처리할 수 있습니다.

“각 파티션을 사용하는 모든 컨슈머, 프로듀서는 파티션 리더에 연결해야 합니다.”

Producer -> Broker 1 - Topic A (Partition 0 : Partition Leader) -> Consumer

Producer -> Broker 1 - Topic A (Partition 1 : Broker 2 - Topic A, Partition 1 Copy) -> Consumer

 

Producer -> Broker 2 - Topic A (Partition 0 : Broker 1 - Topic A, Partition 0 Copy) -> Consumer

Producer -> Broker 2 - Topic A (Partition 1 : Partition Leader) -> Consumer

 

 

다중 클러스터

다중 클러스터의 장점

1. 데이터 타입에 따라 구분하여 처리할 수 있습니다

2. 보안 요구사항을 분리해서 처리할 수 있습니다

3. 재해 복구를 대비한 다중 데이터센터를 유지할 수 있습니다

 

 

다중 데이터센터 아키텍처

데이터센터 B의 카프카 클러스터를 -> 미러메이커 A를 이용해 -> 카프카 집중 클러스터 A에 생산할 수 있습니다

데이터센터 B의 카프카 집중 클러스터 B를 -> 미러메이커 C를 이용해 -> 카프카 집중 클러스터 C에 생산할 수 있습니다

 

 

카프카를 선택하는 이유

1. 다중 프로듀서

여러 Producer가 많은 Topic을 사용해도, 같은 Topic을 함께 사용해도

무리 없이 많은 Producer 메시지를 처리할 수 있습니다

여러 프런트엔드 시스템으로부터 데이터를 수집하고 일관성을 유지하는데 이상적입니다

 

2. 다중 컨슈머

Kafka는 많은 Consumer가 상호 간섭없이 어떤 메시지 스트림을 읽을 수 있게 지원합니다

한 클라이언트가 특정 메시지를 소비하면 다른 클라이언트에서 그 메시지를 사용할 수 없는 큐(queue) 시스템과 다릅니다

Kafka Consumer는 Consumer Group의 멤버가 되어 메시지 스트림을 공유할 수 있습니다 (Consumer Group 이미지 참고)

 

3. 확장성

Kafka는 어떤 크기의 데이터도 쉽게 처리할 수 있습니다

그러므로 처음에는 실제 잘 되는지 검증하는 의미로 하나의 브로커로 시작한 후

세 개의 브로커로 구성된 소규모의 개발용 클러스터로 확장하면 좋습니다

 

그 다음 데이터 증가에 따라 10개, 수백 개의 브로커를 갖는 대규모 클러스터로 업무용 환경을 구축하면 됩니다

확장 작업은 시스템 전체 사용에 영향을 주지 않고 클러스터가 온라인 상태일 때도 수행될 수 있습니다

여러 개의 브로커로 구성된 클러스터는 개별적인 브로커의 장애를 처리하면서 클라이언트에게 지속적인 서비스를 할 수 있습니다

동시에 여러 브로커에 장애가 생겨도 정상적으로 처리할 수 있습니다. ‘복제 팩터’를 더 큰 값으로 지정하여 구성할 수 있습니다

 

4. 영속성

메시지(Topic)를 디스크에 저장함으로써 영속성을 보장합니다.

장애 발생시에도 Producer의 개입 없이 offset rewind를 통해 데이터를 다시 보내주는 것이 가능합니다.

(데이터 정합성을 지키기 어려운 MSA 환경에서 매우 중요한 요소입니다.)

(디스크에 저장함에도 불구하고 디스크 순차 I/O 읽기와 Zero Copy 기법으로 메모리와 같이 빠른 성능을 보여주고 있습니다.)

 

(Zero Copy ????)

Zero Copy는 파일 내용이 DMA 엔진에 의해 커널 버퍼에 복사되어 집니다
소켓 버퍼에 데이터가 복사되지 않습니다. 대신 "데이터의 위치와 길이에 대한 정보가 있는 설명자만 소켓 버퍼에 추가됩니다."

Zero Copy에 대한 내용은 IBM 문서에 자세히 설명이 되어 있습니다.

참고 - https://developer.ibm.com/articles/j-zerocopy/