카프카 - 00 - 개요

아래 책을 읽고 정리합니다. : http://www.yes24.com/Product/Goods/59789254

카프카, 데이터 플랫폼의 최강자

 

 

 

엔드투엔드 아키텍쳐 문제점

엔드투엔드 연결은 빠른 전송 속도와 전송 결과를 신속하게 알수 있는 장점이 있는 반면 문제점이 많다.

1. 트랜잭션 처리와 비동기 처리가 동시에 이뤄지지만 통합된 전송영역이 없으니 복잡도가 증가한다.
2. 데이터 파이프라인 관리가 어렵다.
   보통 다양한 데이터 시스템들이 있으면 이 시스템에 저장된 동일한 데이터를 개발 부서들마다 다른 방법으로 파이프라인을 만들고 유지한다. 시간이 지나면서 이 데이터 파이프 라인들은 통합 데이터 분서을 위해 서로 연결되어야하는 일이 필연적으로 발생한다.
3. 특정 연결 포인트에 장애가 발생한 경우 메시지를 보내는 쪽에서 대기처리를 개별적으로 해줘야한다. 그렇지 않으면 장애에 영향을 받아 또다른 장애가 발생할 수 있다.
4. 새로운 서비스가 연결되려하면 데이터 전송을 위해 일일히 다 연결해줘야한다. 더불어 연동해야할 시스템과의 추가적인 작업도 

 

 

 

펍 / 섭 아키텍쳐

엔드투엔드 아키텍쳐를 보완하기 위해 나온 모델

1. 프로듀서는 중간의 메시징 시스템에 메시지를 전달한다
2. 메시징 시스템은 시스템 안에있는 교환기가 메시지의 수신처 ID 를 확인한다.
3. 메시징 시스템은 시스템 안에있는 컨슈커들의 큐로 메시지를 전달한다.
4. 컨슈머들은 자신들의 큐를 모니터링하고 있다가 큐에 메시지가 전달되면 이 값을 가져간다.

 

장점

• 메시징 시스템만 살아있으면 프로듀서에서 전달된 메시지는 유실되지 않는다.
• 메시징 시스템은 교환기의 룰에 의해서 데이터가 수신처의 큐로 전달되므로 컨슈머가도 데이터 유실을 염려하지 않아도 된다.
• 메시징 시스템을 중심으로 연결되기 때문에 확장성에 용이하다.
• 어느 한쪽의 시스템이 문제가 발생해도 연쇄작용이 발생할 확률이 매우 낮다.
• 새로운 서버가 추가되어도 카프카로만 보내면 되기 때문에 서버 추가에 대한 부담도 줄어든다.

 

단점

• 직접 통신을 하지 않았기 때문에 메시지가 정확히 전달되었는지 확인하기 어렵다.
• 엔드투엔드 보다는 느리다.

 

 

 

기존의 메시지 큐 시스템

기존의 메시징 시스템은 메시지의 보관, 교환, 전달 과정에서 신뢰성을 보장하는 것에 중점이 맞춰져 있었다. 

그래서 속도와 용량이 그렇기 중요하지 않았다.

액티브 엠큐 와 같은 기존의 메시지 큐는 성능이 느리고 큰데이터를 처리할 수 없었다.

그래서 원본 데이터를 줄이고 포맷도 변경하는 등의 작업이 추가로 필요하였다.

 

 

 

 

카프카의 목표

• 모든 시스템으로 데이터를 전송할 수 있어야 한다.
• 실시간 처리가 가능해야한다.
• 확장에 용이 해야한다.
• 프로듀서 / 컨슈머응 분리하자
• 메시징 시스템과 같이 영구 메시지 데이터를 여러 컨슈머에 허용하자
• 높은 처리량을 위한 메시지 최적화하자

 

 

 

카프카의 지향점

카프카를 메시지 전달의 중앙 플랫폼으로 두고 기업에서 필요한 모든 서비스 들을 연결하여 연결된 파이프라인을 만드는 것을 목표로 한다.

이러한 철학에서 로고 이미지가 네트워크 모양이다.

 

 

 

카프카 어원

카프카 창시자 제이 크렙스가 대학 시절 심취한 소설가 프란츠 카프카 에서 유래되었다.

메시지를 작성하는 시스템이므로 작가의 이름을 사용하는것이 좋겠다고 생각했다한다.

 

 

 

카프카 소개

기존의 메시징 시스템과 동일하게 비동기 시스템이다.

프로듀서는 컨슈머와 관계없이 새로운 메시지를 카프카로 전송한다.

컨슈머는 프로듀서와 관계없이 카프카에서 새로운 메시지를 가져온다.

 

 

 

카프카의 특징

1. 높은 성능
2. 확장성
3. 프로듀서와 컨슈머 분리
4. 멀티 프로듀서, 멀티 컨슈머
   하나의 토픽에 여러 프로듀서 또는 컨슈머가 접근 가능하다.
   하나의 프로듀서는 여러 토픽에 메시지를 보낼 수 있다.
   하나의 컨슈머는 여러 토픽으로 부터 메시지를 가져올 수 있다.
5. 디스크에 메시지 저장
   카프카가 기존의 메시징과 다른 가장 큰 특징 중 하나다.
   메시지를 디스크에 저장하고 유지한다.
   일반적인 메시징 시스템은 컨슈머가 메시지를 읽어가면 큐에 있는 메시지를 삭제한다.
   카프카는 컨슈머가 메시지를 읽어가도 정해진 보관주기동안 디스크에 메시지를 저장한다.
   컨슈머는 메시지 손실을 걱정하지 않아도된다.

 

디스크에 메시지를 저장하기 때문에 가능한 일

• 멀티 컨슈머가 가능하다.
• 컨슈머에 버그가 있으면 컨슈머를 잠시 중단하고 버그를 해결한후 다시 실행해도된다

 

 

 

카프카의 확장과 발전

2000년대 초에 등장했던 SOA 의 핵심 구성요소중 하나인 ESB 를 쉽게 구현할 수 있다. 

지금으로 비교하면 SOA (=MSA) + ESB (=Kafka) 구조가 이와 유사하다.

 

ESB의 특징

• 다양한 시스템과 연동 지원
• 느슨한 결합의 메시지큐 지원
• 이벤트 기반 통신 지향

 

 

 

카프카 용어 정리

• 브로커 : 카프카 클러스터에 있는 서버 또는 노드
• 토픽 : 메시지를 구분하기 위한 이름
• 파티션 : 토픽을 병렬 처리할 수 있도록 나눌 수 있다.
• 프로듀서 : 토픽에 메시지를 생성하는 어플리케이션
• 컨슈머 : 토픽에서 메세지를 수신하는 어플리케이션

 

 

 

 

카프카를 이용한 실시간 데이터 분석 파이프라인

보통 아래중 하나를 택한다.

• 카프카 + 스톰 + 하둡
• 카프카 + 스파크 + ES
• 카프카 + 카프카 스트림즈
• 카프카 + KSQL

스톰과 스파크는 대규모 시스템을 관리해줄 엔지니어가 필요로 한다.

카프카 스트림즈는 간단한 스트림 처리 앱을 개발 할 수 있다.

KSQL 은 SQL 기반으로 데이터를 분석할 수 있다.

 

 

 

주키퍼

분산 어플리케이션을 사용하게 되면 분산 어플리케이션 관리를 위한 안정적인 코디네이션 어플리케이션이 추가로 필요하게 된다.

주키퍼는 이미 안정적인 코디네이션 서비스라고 검증된 서비스이다.

주키퍼의 서버들은 클라이언트인 분산 어플리케이션들과 커넥션을 맺은 후 상태 정보를 주고 받는다.

주키퍼는 분산된 어플리케이션 정보를 중앙에서 구성 관리, 그룹 관리 네이밍, 동기화등의 서비스를 제공한다.

카프카의 상태 관리등의 목적으로 카프카는 주키퍼를 이용한다.

주키퍼는 카프카와 직접 통신하면서 카프카의 메타데이터를 관리한다.

주키퍼에 저장되는 데이터는 모두 메모리에 저장되어 처리량이 크고 속도가 빠르다.

상태 정보들은 주키퍼의 지노드라는 곳에 key-value 로 저장된다.

 

 

 

지노드

주키퍼에서 데이터를 저장하기위한 공간 이름 (폴더와 유사한 개념이다.)

지노드에 저장하는 데이터 크기는 바이트에서 킬로바이트 정도로 매우작다.

자식노드를 가지고 있는 계층형 구조로 구성되어있다.

지노드는 데이터 변경등에 대한 유효성 검사등을 위해 버전 번호를 관리한다.

지노드는 데이터가 변경될 때마다 버전 번호가 증가한다.

지노드는 크게 두개의 노드로 나뉜다.

1. 임시 노드 : 임시 노드를 생성한 클라이언트와의 연결이 끊어지면 삭제된다.
2. 영구 노드 : delete 를 호출 해야 삭제할 수 있다.

 

 

 

주키퍼 클러스터

주키퍼는 서버 여러대를 클러스터로 구성한다.

주키퍼는 과반수 방식으로 살아있는 노드수가 과반수 이상유지 된다면 서비스가 지속 가능하다. (노드갯수가 홀수여야하는 이유)

IDC 안에 주키퍼를 구성하는 경우 주키퍼 서버들을 서로 다른 렉에 분산하면 렉 전원 장애가 발생해도 장애 상황을 피할 수 있다. (스위치도 마찬가지다.)

주키퍼의 포트는 2181 이며 2888, 3888 은 클러스터 내 노드끼리 연결하는데 사용하고 리더 선출에 사용한다.

 

* 주키퍼로 노드를 관리하는 어플리케이션은 주키퍼가 어플리케이션과 통신을 끊어지는지 감지하게된다.

그런데 자바 기반의 어플리케이션의 경우 간혹 메모리를 많이 사용하여 풀 GC 가 일어나고 이로 인해 일시적 멈춤 상태가 된다.

따라서 자바 기반의 어플리케이션의 주키퍼 세션 타임 아웃 시간을 너무 짧게 하면 해당 노드가 다운 된 것으로 판단 할 수도 있다.

카프카는 자바로 작성된 JVM 기반의 서비스다.

 

 

 

카프카

카프카의 기본 포트는 9092이다.

카프카는 분산 어플리케이션이라는 면에서 보면 주키퍼와 동일하지만 클러스터가 운영되는 방식이 다르다.

카프카는 홀수 운영 구성을 하지 않아도된다.

카프카의 주키퍼 설정 정보 입력시 주키퍼 서버 전체 리스트를 입력하는 것이 좋다.

하나의 주키퍼 서버만 연결하는 경우 해당 서버가 다운 됬을 때 클러스터는 과반수 운영으로 정상 상태이지만 연결이 안될 수도 있다.

zookeeper.connect=myZookeeper001:2181,myZookeeper002:2181,myZookeeper003:2181

 

 

 

 

토핑 생성, 메시지 생성, 메시지 수신 샘플

/usr/local/kafka/bin/kafka-topics.sh --zookeeper myZookeeper001:2181,myZookeeper002:2181,myZookeeper003:2181/my-kafka --replication-factor 1 --partitions 1 --topic my-topic --create

/usr/local/kafka/bin/kafka-console-producer.sh --broker-list myKafka001:9092,myKafka002:9092,myKafka003:9092 --topic my-topic

/usr/local/kafka/bin/kafka-console-consumer.sh --broker-list myKafka001:9092,myKafka002:9092,myKafka003:9092 --topic my-topic --from-beginning

카프카 설치시 내장된 쉘파일로 이를 테스트 해볼 수 있다.

/usr/local/kafka/bin/kafka-topics.sh : 토픽 생성

/usr/local/kafka/bin/kafka-console-producer.sh : 메시지 생성

/usr/local/kafka/bin/kafka-console-consumer.sh : 메시지 수신