Kafka

아파치 카프카

- 여러 대의 분산 서버에서 대량의 데이터를 처리하는 분산 메시징 시스템

- 데이터(메시지)를 받고, 받은 메세지를 다른 시스템이나 장치에 보내기 위해 사용

- 카프카는 여러 시스템과 장치를 연결하는 중요한 역할을 함

- 카프카는 대량의 데이터를 높은 처리량(high-throughput)과 실시간(real-time)으로 취급하기 위한 제품으로 아래 4가지를 실현

 

• 확장성 : 여러 서버로 확장(scale out) 구성할 수 있기 때문에 데이터 양에 따라 시스템 확장이 가능
• 영속성 : 수신한 데이터를 디스크에 유지할 수 있기 때문에 언제라도 데이터를 읽을 수 있음
• 유연성 : 연계할 수 있는 제품이 많기 때문에 제품이나 시스템을 연결하는 허브 역할을 함
• 신뢰성 : 메시지 전달 보증을 하므로 데이터 분석을 걱정하지 않아도 됨

 

탄생 배경

링크드인 시스템 요구 사항

 

- 카프카는 2011년 미국 링크드인(LinkedIn)에서 출발

- 링크드인 웹사이트에서 생성되는 로그를 처리하여 웹사이트 활동을 추적하는 것을 목적으로 개발

- 웹사이트에서의 활동은 사용자가 페이지 뷰와 검색 시 키워드 광고의 이용 상황도 표함

- 웹에서 생성되는 대량의 로그를 분석하여 사용자가 웹에서 하는 활동을 모니터링하고 서비스 개선에 활용하는 것

- 링크드인이 실현하려는 목표

 

• 높은 처리량으로 실시간 처리
• 전 세계 사용자의 방대한 엑세스 데이터를 처리해야 하기에 처리량이 우수해야 함
• 사용자의 활동을 신속하게 파악하거나 사용자의 활동에 따라 즉시 피드백하기 위해서는 사용자의 활동 단위로 실시간 처리
• 임의의 타이밍에서 데이터를 읽음
• 실시간 처리에 대한 요구가 있는 반면, 링크드인은 기존 시스템에서 수집한 액세스 로그를 일정 시간마다 배치 처리로 취급하고 싶다는 요구도 있음
• 데이터를 사용하는 타이밍이 반드시 실시간이 아니라 이용 목적에 따라 다를 가능성이 있기 때문에 방대한 데이터를 전달할때 버퍼 역할도 가능하기를 원함
• 다양한 제품과 시스템에 쉽게 연동
• 링크드인에서 데이터의 발생원인이 되는 데이터 소스와 관련된 시스템이 하나가 아니어서 여러 시스템을 통해 데이터를 받아들여야 함
• 또한 이용 목적에 따라 데이터베이스, 데이터웨어하우스, 아파치 하둡 등 여러 기반이 존재
• 메시지를 잃지 않음
• 메시지가 방대하더라도 메시지를 손실하지 않아야 함
• 링크드인의 원래 목적은 사용자의 활동을 추적하는 것이기 때문에 중복이 있더라도 메시지 손실이 없게 하는 것이 중요했음

카프카와 비슷한 제품

메시지 큐

메시지 큐 제품으로 IBM의  WebSphere MQ, Apache ActiveMQ, RabbitMQ

 

로그 수집 시스템

• 실시간으로 데이터를 수집한다는 관점에서 생각할 수 있는 것은 로그 수집을 위한 미들웨어
• 페이스북이 개발한 Scribe, 클라우데라가 개발한 Flume
• 각 프론트엔드 서버가 로그를 중계용 서버로 전송하고, 거기서 로그를 수집하여 데이터베이스와 분산 파일시스템 HDFS(Hadoop Distributed File System)에 축적
• 대량의 로그를 처리하는 것을 가정하고 있기 때문에 분산 환경의 다중 서버 구성으로 이루어져 있음
• 이들 제품은 대량의 로그를 HDFS에 축적하고 일괄처리하는 것이 주목적이기 때문에 하둡에서 동작하도록 프로그램을 다시 작성해야 함
• 다양한 제품과의 연계를 실현하기 위해서는 이용하기 쉬운 송수신 API가 없음
• 수신하는 쪽이 임의로 메세지를 수신하기 어려움

 

ETL 도구

데이터의 소스에서 데이터를 추출하여 필요에 따라 변환해서 데이터베이스에 적재하는 ETL 도구가 있음

DataStage, Interstage, Cosminexus, Informatica PowerCenter, Talend

이들 제품은 데이터를 파일 단위로 다룸

수신하는 쪽이 임의로 메시지를 수신하기 어려움

 

제품 정리

요구 사항	메시지 큐	로그 수집 시스템	ETL 도구	카프카가 목표로 하는 형태
실시간성 (메시지 단위 교환)	O	O	X (배치/파일 등 일정 묶음으로 전송)	O
확장 구성	X	O	O	O
영속화	△ (장기 보존은 예상 외)	X (자기 자신이 스토리지를 갖고 있는 것이 아니라 NFS나 HDFS와 연계)	X	O
다양한 접속	O	△ (HDFS 접속 중심)	O	O
전달 보증	O (트랜잭션 관리 기능)	△ (트랜잭션 관리 기능은 제공되지 않음)	O (전후의 시스템과 연계하여 실현)	O (메시지 상실은 허용하지 않음/ 트랜잭션 관리는 나중에 구현)

 

메시징 모델

메시징 모델은 다음 세 가지 요소로 구성

• Producer(메시지 생산자)
• Broker(메시지 수집/전달 역할)
• Consumer(메시지 소비자)

큐잉 모델

• 브로커 안에 큐를 준비해, 프로듀서에서의 메시지가 큐에 담기고, 컨슈머가 큐에서 메시지를 추출
• 하나의 큐에 컨슈머가 여러 개 존재하는 것을 생각할 수 있음
• 이 모델은 컨슈머를 여러 개 준비함으로써 컨슈머에 의한 처리를 확장시킬 수 있으며, 컨슈머가 메시지를 받으면 다른 컨슈머는 메시지를 받을 수 없음

펍/섭 메시징 모델

• 이 모델에서는 메시지 생산자인 프로듀서를 퍼블리셔(Publisher)
• 메시지 소비자의 해당 컨슈머를 서브스크라이버(Subscriber)라고 함
• 퍼블리셔는 누가 그 메시지를 수신하는지 알 수 없고 브로커에 있는 토픽(topic)이라고 불리는 카테고리 안에 메시지를 등록
• 서브스크라이버는 여러 개 존재하는 토픽 중 하나를 선택하여 메시지를 받음
• 여러 서브스크라이버가 동일한 토픽을 구독하기로 결정한다면, 이 여러 서브스크라이버는 동일한 메시지를 받음
• 또한 다른 토픽에서 다른 메시지를 받을 수 있음
• 이 모델은 TV 전파 수신을 상상하면 이해하기 쉽다. 방송국에서는 개별 가정에서 누가 수신하고 있는지 고려하지 않고 방송 전파를 발신하여, 각 가정은 자신이 보고 싶은 프로그램만 선택하여 방송을 수신
• 이와 같은 구조를 시스템 간 실현했다고 생각하면 된다.

카프카의 주요 특징

높은 처리량과 낮은 지연시간

• 카프카는 매우 높은 처리량과 낮은 지연시간(latency)을 자랑
• 응답 속도가 가장 빠른 것은 RabbitMQ이지만, 처리량은 단연 독보적으로 카프카가 앞선다.

 

높은 확장성

• 손쉬운 확장(scale out)이 가능하도록 설계된 애플리케이션

 

고가용성

• 고가용성(high availability)이라는 개념은 간단하지만 내부 구현은 매우 어렵고 복잡
• 고가용성을 갖추면서 지연 없는 빠른 메시지 처리 기능을 유지하는 것은 매우 어려움

 

내구성

• 프로듀서는 카프카로 메시지를 전송할 때, 프로듀서의 acks라는 옵션을 조정하여 메시지의 내구성을 강화할 수 있음

 

개발 편의성

• 카프카는 메시지를 전송하는 역할을 하는 프로듀서(producer)와 메시지를 가져오는 역할을 하는 컨슈머(consumer)가 완벽하게 분리되어 동작하고 서로 영향을 주지도 받지도 않음
• 이러한 구성에 따라 프로듀싱을 원하는 개발자는 프로듀서만 개발하면 되고 컨슈밍을 원하는 개발자는 컨슈머만 개발해 사용하면 됨

운영 및 관리 편의

• 카프카는 중앙 메인 데이터 파이프라인 역할을 하게 되는데 운영이나 관리의 편의성이 떨어진다면 그와 같은 주요 역할을 맡기기에 부담이 되기 때문에 성능 확장을 위한 중성 작업이 쉽고 간단해야 하며, 최신 버전이 릴리스되는 경우 무중단으로 버전 업그레이드도 가능

 

카프카의 주요 구성 요소 5가지

- 브로커

• 데이터를 수신, 전달하는 서비스

- 메시지

• 카프카에서 다루는 데이터의 최소 단위, 카프카가 중계하는 로그의 한 줄 한 줄과 센서 데이터 등이 이에 해당
• 메시지는 key와 Value를 갖게 되며 메시지를 전송할 때 파티셔닝에 이용

- 프로듀서

• 데이터의 생산자이며 브로커에 메시지를 보내는 애플리케이션

- 컨슈머

• 브로커에서 메시지를 취득하는 애플리케이션

- 토픽

• 메시지를 종류(토픽)별로 관리하는 스토리지
• 브로커에 배치되어 관리
• 프로듀서와 컨슈머는 특정 토픽을 지정하여 메시지를 송수신함으로써 단일 카프카 클러스터에서 여러 종류의 메시지를 중계

 

시스템 구성

브로커

- 브로커는 하나의 서버 당 하나의 데몬 프로세스로 동작하여 메시지 수신/전달 요청을 받아들임

- 이것을 여러 대의 클러스터로 구성할 수 있으며 브로커를 추가함으로써 수신/전달의 처리량 향상(스케일 아웃)이 가능

- 브로커에서 받은 데이터는 모두 디스크로 내보내기가 이루어져 디스크의 총 용량에 따라 장기간 데이터를 보존할 수 있음

 

프로듀스 API/컨슈머 API

- 프로듀서/컨슈머를 구현하는 기능은 브로커로 데이터를 보내고 브로커에서 데이터를 받기 위한 라이브러리로 제공

- 프로듀서는 프로듀스 API를 이용하여 브로커에 데이터를 송신하기 위해 구현된 애플리케이션

- 실제 사례로는 각종 로그 전송 및 미들웨어와 연동하여 동작하기 때문에 프로듀서 API를 내포한 도구, 미들웨어를 통해 이용하는 형태 등 다양하다

- 사용할 수 있는 서드 파티의 플러그인

• Apache Log4j
• Apache Flume
• Fluentd
• Logstash

컨슈머

- 컨슈머 API를 이용해 브로커에서 메시지를 취득하도록 구현된 애플리케이션

- 브로커는 메시지를 영속화하기 위해 브로커에 도달하는 즉시 컨슈머에서 취득해야 하는 제약이 없어 디스크에 보관되어있는 동안은 메시지 취득이 가능

- 일정 기간 데이터를 축적한 스토리지에서의 데이터 추출 및 실시간 처리를 위한 애플리케이션의 데이터 입력 등으로 이용

- 카프카 연계를 위한 컨슈머 기능을 갖춘 기존 제품들 리스트

• Apache Spark
• Apache Samza
• Apache Flink
• Apache Flume
• Fluentd
• Logstash

주키퍼

• 카프카의 브로커에 있어 분산 처리를 위한 관리 도구로 아파치 주키퍼가 필요
• 주키퍼는 하둡 등 병렬 분산 처리용 프로그램으로 설정 관리, 이름 관리, 동기화를 위한 잠금 관리를 위한 구조로 자주 사용
• 카프카에 있어서는 분산 메시징의 메타데이터를 관리하기 위한 구성 요소로 기능
• 주키퍼 클러스터의 구조상 3, 5처럼 홀수로 구성하는 것이 일반적

카프카 클라이언트

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

카프카 클러스터

• 카프카는 여러 대의 브로커 서버, 주피커 서버로 이루어진 클러스터링의 메시지 중계 기능과 메시지 송수신을 위한 라이브러리 그룹으로 구성
• 주키퍼에 의해 구성된 클러스터 시스템을 카프카 클러스터라고 정의

 

카프카 구축

- 3대의 서버로 카프카 클러스터를 구축할 때의 동작 환경

호스트명	역할	설명
kafka-broker01	브로커	서버 3대에서 카프카 클러스터를 구축한다
kafka-broker02	브로커
kafka-broker03	브로커
producer-client	프로듀서	카프카에 메시지를 송신한다
consumer-client	컨슈머	카프카에서 메시지를 수신한다
kafka-client	카프카 클라이언트	카프카 클러스터의 상태 관리 및 운영을 위한 각종 조작을 처리한다