Apache Kafka - BESPIN Tech Blog

안녕하세요, 오늘은 베스핀글로벌 D&A실 한제호님이 작성해 주신 Apache Kafka에 대해 알아보겠습니다.

궁금하신 부분이 있으시면 댓글을 달아주세요 🙂

이벤트: 비즈니스에서 일어나는 모든 일(데이터)을 의미
이벤트 스트림: 연속적인 많은 이벤트들의 흐름을 의미

Client 서비스가 Target 서비스에 요청을 보내면 응답 올 때까지 기다리는 구조
응답 시스템의 응답 시간에 따라 요청이 늦어질 수 있음

Client 서비스가 Target 서비스에 요청을 보내면 응답 올 때까지 기다리지 않고 그다음 일을 수행하는 구조
이벤트를 수신했는지를 파악하지 않아도 되는 구조

토픽 단위로 설정되며 파티션 복제를 통해 장애 발생 시 데이터 유실을 최소화함(내구성)
각 파티션은 리더 파티션을 갖게 되며 리더 파티션을 통해 Read/Write가 발생하게 됨
예시: Replication Fact가 2로 설정되어 있다면…

명시 안하는 경우: 라운드 로빈 형태로 적재
명시하는 경우: Hash 함수를 통해 동일한 키는 동일한 파티션에 적재

Consumer가 제거되거나 추가될 때 rebalancing이 발생함(rebalancing이 발생할 경우 Group내의 모든 consumer가 메시지 소비를 중단하므로 rebalancing이 자주 일어나게 해서는 안됨)

문의: info@bespinglobal.com | 대표번호: 02-1668-1280

1. 개요

Linkedin에서 개발. 2011년에 오픈소스화

분산 스트리밍 플랫폼 = Event Streaming Platform

실시간으로 흐르는 realt-time 이벤트 스트림을 받아주고 그 이벤트 스트림을 필요한 곳으로 전달하는 시스템

Producer를 통해 데이터를 전달받고 Consumer를 통해 데이터를 제공함

확장성이 있고, 장애 허용(fault tolerant)을 하며, 성능이 뛰어남

EDA(Event Driven Architecture) 방법론에서 많이 활용되는 소프트웨어

2. 데이터 전송 측면에서의 전통적인 아키텍쳐 vs Kafka를 이용한 아키텍쳐

전통적인 아키텍쳐(Request-Response Architecture)

Point to Point 방식: 요청 시스템은 연결할 응답 시스템의 주소를 모두 알고 있어야 함

Spaghetti network: 복잡하게 시스템끼리 연결되어 있음(서비스 하나 추가되면 죽어납니다….ㅜㅜ)

Blocking Model:

다양한 프로토콜/데이터 포맷 필요

Point-of-failure가 많음

장애 발생 시 분석 및 모니터링이 어려움(유지보수의 어려움)

Kafka를 이용한 아키텍쳐(Event Driven Architecture)

비동기 통신 방식

서비스 간 디커플링 구조로 의존성이 낮음

Non-Blocking Model:

단일화된 프로토콜/데이터 포맷 사용 가능

장애 격리(Fault Isolation)

고 가용성 측면에서 Client 장애 발생 시 데이터 유실 없이 전송 가능

다양한 에코 시스템을 통해 이기종 시스템과의 통합 및 모니터링 측면에서의 강점이 있음

3. Kafka 구성요소

Topic

파일 시스템의 폴더와 유사함

kafka안에서 메세지가 저장되는 논리적인 공간

토픽에는 다수의 파티션을 구성할 수 있으며 파티션 수는 줄일 수 없음

Replication Fact

Partition(=A Structured commit log)

순서가 있고 변경할 수 없는 메세지 시퀀스

단일 파티션에는 오프셋이라는 순차적 ID 번호가 할당되어 순서가 보장됨

하나의 파티션 내에서만 순서 보장되며 다수의 파티션 내에서는 순서 보장 안됨

오프셋은 파티션 별로 관리 됨

병렬 처리를 위해서 다수의 Partition으로 구성

Segment

각 파티션은 세그먼트로 세분화됨

실제 물리적인 File 단위

설정된 파일 크기 및 기간에 따라 새 파일로 rolling됨

생성된 물리적인 파일은 보관 기간 또는 보관 용량 설정 정보에 따라 삭제되거나 압축됨

Kafka Message

Byte형태의 배열

보통 String, Json, Avro 타입의 포맷을 사용

메세지 크기의 제한 없음(실시간 처리 성능 최적화를 위해 되도록이면 최대~1MB로 처리)

지정된 Retention Period 동안만 저장되고 이후에는 삭제 처리됨

4. Kafka Infra Architecture

Zookeeper

분산 코드네이션 역할

클러스터 관리: 브로커들을 관리하고 모니터링

Topic 관리: 토픽 리스트를 관리하고 파티션과 Replication 관리

파티션 리더 관리: 특정 브로커가 장애가 발생하는 경우 리더가 될 브로커를 선택하는 역할 담당

주키퍼도 고가용성을 위해 홀수로 Instance를 구성하는 것이 일반적임

Kafka Cluster에서 주키퍼를 제외시키는 프로젝트가 진행 중

Kafka Broker

Kafka Application 서버

최소 3대 이상으로 구성하는 것이 일반적임

p2p 구조로 모든 브로커가 클라이언트 요청을 처리할 수 있음

Kafka Producer

토픽에 레코드를 보내는 Client Application

Key 명시 여부에 따라 분산 형태가 달라짐

한번에 하나의 토픽으로만 메세지 송신 가능(비동기로도 처리 가능)

Kafka Consumer & Consumer Group

토픽에 적재된 데이터를 받아오는 Client Application

Consumer Group은 다수의 Consumer를 보유 할 수 있음

Consumer Group은 모든 파티션으로부터 데이터를 받을 수 있지만 Consumer는 지정된 파티션으로부터 데이터를 받을 수 있음(하나의 Consumer는 하나의 파티션과 연결됨)

만약 “파티션 수>Consumer” 인 경우 하나의 Consumer에 여러 개의 파티션이 연결 될 수 있음(반대로 “파티션 수<Consumer” 인 경우 활용되지 않는 Consumer가 발생 할 수 있음)

5. 기존 Message(ActiveMQ, RabbitMQ 등) 시스템과의 차이점

프로토콜

Message 시스템: AMQP 프로토콜이나 JMS API를 사용

Kafka: TCP 프로토콜

TCP의 경우 OSI 7 Layer상에서 Transport Layer에 위치하고 있으며 AMQP의 경우 상위 레이어에 위치하기 때문에 Header 정보를 포함하지 않는 TCP가 성능 관점에서 유리함

Producer와 Consumer 관계

Message 시스템: 1:1 관계에 특화되어 있음(물론 기능 개선이 있었지만 태생 자체가….)

Kafka: 1:N 또는 N:M 관계에 특화되어 있음

메시지 보관 방식

Message 시스템: 메모리에 보관하는 것이 일반적임

kafka: 스토리지에 보관

kafka의 경우 데이터에 대한 영속성 보장

트래픽 증가로 데이터가 밀리는 경우(쌓이는 경우) 메모리에 저장하는 Message 시스템은 성능 저하가 발생하는 반면 스토리지에 보관하는 kafka는 그에 비해 성능 저하가 크지 않음

6. 모니터링