KAFKA 개요

INTRODUCTION

APACHE KAFKA ™는 분산 형 스트리밍 플랫폼 입니다. 그게 정확히 무슨 뜻입니까?

우리는 스트리밍 플랫폼이 세 가지 핵심 기능을 가지고 있다고 생각합니다.

이를 통해 레코드 스트림을 게시하고 구독 할 수 있습니다. 이 점에서 메시지 큐 또는 엔터프라이즈 메시징 시스템과 유사합니다.
내결함성있는 방식으로 레코드 스트림을 저장할 수 있습니다.
발생하는 레코드 스트림을 처리 할 수 있습니다.

카프카는 무엇에 좋은가?

그것은 두 가지 광범위한 종류의 응용 프로그램에 사용됩니다.
시스템 또는 응용 프로그램간에 데이터를 안정적으로 얻는 실시간 스트리밍 데이터 파이프 라인 구축
데이터 스트림을 변환하거나 이에 반응하는 실시간 스트리밍 어플리케이션 구축

카프카가 어떻게 이러한 일을하는지 이해하기 위해 카프카의 능력을 알아보자

먼저 몇 가지 개념 :

Kafka는 하나 이상의 서버에서 클러스터로 실행됩니다.

카프카 클러스터는 topic 이라는 범주 에 record stream을 저장 합니다.

각 레코드는 키, 값 및 타임 스탬프로 구성됩니다.

Kafka는 4 가지 핵심 API를 가지고 있습니다.

생산자 API는 하나 개 이상의 카프카 주제에 레코드의 스트림을 게시 할 수있는 응용 프로그램을 할 수 있습니다.

소비자 API는 응용 프로그램이 하나 개 이상의 주제에 가입 그들에게 생산 기록의 스트림을 처리 할 수 있습니다.

스트림 API는 애플리케이션이 역할을 할 수 있도록 스트림 프로세서 유효 입력이 출력 스트림에 스트림 변환, 하나 개 이상의 항목에서 입력 스트림을 소비하는 하나 개 이상의 출력 항목을 출력 스트림을 생성한다.

커넥터 API를 구축하고 기존의 응용 프로그램이나 데이터 시스템에 카프카의 주제를 연결 재사용 생산자 또는 소비자를 실행 할 수 있습니다. 예를 들어, 관계형 데이터베이스에 대한 커넥터는 테이블에 대한 모든 변경 사항을 캡처 할 수 있습니다.

USE CASES

https://kafka.apache.org/uses

MESSAGING

카프카는보다 전통적인 메시지 브로커를 대신하여 잘 작동합니다.
메시지 브로커는 다양한 이유로 사용됩니다 (데이터 생성자에서 처리를 분리하고 처리되지 않은 메시지를 버퍼링하는 등).
대부분의 메시징 시스템과 비교하여, Kafka는 뛰어난 처리량, 기본 제공 파티셔닝, 복제 및 내결함성을 갖추고 있어 대규모 메시지 처리 응용 프로그램에 적합한 솔루션입니다.

WEBSITE ACTIVITY TRACKING

Kafka의 원래의 사용 사례는 사용자 활동 추적 파이프 라인을 실시간 게시 - 구독 피드 집합으로 재구성 할 수 있어야했습니다.
이는 사이트 활동 (페이지 조회수, 검색 또는 사용자가 취할 수있는 기타 작업)이 활동 유형별로 하나의 주제와 함께 중앙 주제에 게시됨을 의미합니다.
이 피드는 실시간 처리, 실시간 모니터링, 오프라인 처리 및보고를위한 Hadoop 또는 오프라인 데이터웨어 하우징 시스템으로의 로드를 포함하여 다양한 사용 사례에 대한 구독에 사용할 수 있습니다.

METRICS

Kafka는 종종 운영 모니터링 데이터로 사용됩니다. 여기에는 분산 응용 프로그램의 통계를 집계하여 운영 데이터의 중앙 집중식 피드를 생성하는 작업이 포함됩니다.

LOG AGGREGATION

많은 사람들이 Kafka를 로그 집계 솔루션 대신 사용합니다.
로그 집계는 일반적으로 물리적 인 로그 파일을 서버에서 수집하여 처리를 위해 중앙 위치 (파일 서버 또는 HDFS 등)에 배치합니다.
Kafka는 파일의 세부 사항을 추상화하여 로그 또는 이벤트 데이터를 메시지 스트림으로보다 깔끔하게 추상화합니다.
이를 통해 대기 시간이 더 낮은 처리가 가능하며 여러 데이터 소스 및 분산 된 데이터 소비를 보다 쉽게 지원할 수 있습니다.
Scribe 또는 Flume과 같은 로그 중심 시스템과 비교하여 카프카는 성능이 우수하고 복제로 내구성이 강화되었으며 엔드 투 엔드 대기 시간이 훨씬 낮습니다.

STREAM PROCESSING

Kafka의 많은 사용자는 여러 단계로 구성된 처리 파이프 라인에서 데이터를 처리합니다. 여기에서는 원시 입력 데이터가 카프카 항목에서 소비 된 다음 추가 소비 또는 후속 처리를 위해 새로운 주제로 집계, 강화 또는 변환됩니다. 예를 들어, 뉴스 기사를 추천하는 처리 파이프 라인은 RSS 피드의 기사 내용을 크롤링하여 "기사"주제에 게시 할 수 있습니다. 추가 처리로이 컨텐츠를 정규화 또는 중복 제거하고 정리 된 기사 컨텐츠를 새 주제에 게시 할 수 있습니다. 최종 처리 단계에서이 내용을 사용자에게 권장하려고 시도 할 수 있습니다. 이러한 프로세싱 파이프 라인은 개별 주제를 기반으로 실시간 데이터 흐름의 그래프를 생성합니다. 0.10.0.0부터 시작하여, 가볍지 만 강력한 스트림 처리 라이브러리 인 Kafka Streams 는 Apache Kafka에서 위에서 설명한 데이터 처리를 수행 할 수 있습니다.

EVENT SOURCING

이벤트 소싱 은 상태 변경이 시간 순서로 기록 된 레코드 순서로 기록되는 응용 프로그램 디자인 스타일입니다. 매우 큰 저장된 로그 데이터에 대한 Kafka의 지원은이 스타일로 구축 된 응용 프로그램을위한 훌륭한 백엔드입니다.

COMMIT LOG

KAFKA OPERATIONS

GRACEFUL SHUTDOWN

카프카는 브로커가 실패하거나 내려갔을때 자동으로 감지해 파티션의 새 리더를 선출

이는 서버 오류, 유지보수나 설정변경으로 내렸을 때 모두 발생

후자일 경우에 카프카는 단순히 죽이는것 보다는 좀더 graceful 한 서버 정지를 지원

장점

재시작 시 로그 복구가 필요하지 않도록 모든 로그를 디스크에 동기화 한다. (예를들어 로그 tail에 있는 모든 메세지의 체크섬의 확인)

로그 복구는 시간이 걸리기 때문에 재시작의 속도를 높일 수 있다.

셧다운 이전에 리더 서버의 파티션들을 다른 레플리카로 migration한다.

이는 리더십 전송을 빠르게 하고, 각 파티션이 사용불가능한 시간을 몇 밀리세컨으로 최소화한다.

controlled.shutdown.enable=true

ALANCING LEADERSHIP

브로커가 정지하거나 충돌했을 때 프로커 파티션의 리더십은 다른 레플리카로 위임된다.

이는 기본적으로 브로커가 재시작 되었을 면 오직 파티션들의 follower만이 될 수 있고 읽기/쓰기 동작으로 사용될 수 없다는 것을 의미한다.

이 불균형을 피하기 위해 카프카에는 우선적인 레플리카 개념이 있다.

파티션의 레플리카가 1,5,9일 때 1번 노드가 리더 우선권이 있다.

왜냐하면 레플리카 리스트에 앞에 있기 때문이다. 다음 커맨드를 실행해 복구된 레플리카에게 리더십을 복구할 수 있다.

bin/kafka-preferred-replica-election.sh \

—zookeeper zk\_host:port

이 커맨드를 실행하는게 귀찮기 때문에 다음 configuration을 설정해서 자동화할 수 있다.

auto.leader.rebalance.enable=true

MIRRORING DATA BETWEEN CLUSTERS

카프카는 카프카 클러스터간의 데이터 미러링을 위한 툴을 갖고 있다.

한개 이상의 source 클러스터로부터 데이터를 읽어 destination cluster로 쓰는 툴이다.

미러링의 일반적인 사용예는 다른 데이터 센터로 복제하는 것이다. source, destination 클러스터는 완전히 독립적이고, 다른 파티션 갯수를 갖고, 오프셋이 같지 않을 것이다.

그래서 클러스터 미러링은 fault-tolerance 매커니점으로서의 진정한 목적은 아니다.

하지만, 미러링 프로세스는 파티션 메시지 키를 유지하고 사용해서 키 기반에서 순서가 유지는 된다.

EXPANDING YOUR CLUSTER

카프카 서버에 서버를 추가하는것은 쉽다. 새 서버에서 카프카 유니크 브로커아이디를 할당해 기동하면 된다.

하지만 이 새로운 서버는 자동으로 데이터 파티션으로 할당되지 않기 때문에, 파티션들이 새 서버로 이동되지 않는 한, Topic이 새로 생길 때까지 어떤 일도 하지 않는다.

그래서 보통 클러스터에 서버를 추가하면 기존 데이터를 이 새 서버로 이동시키려 할 것이다.

새 서버를 마이그레이션 하는 파티션의 follower로 추가하고, 모든 기존 데이터를 복제하도록 한다.

파티션의 내용이 새 서버에 모두 복제 되고 in-sync 레플리카에 연결 되면, 기존 레플리카중 하나가 파티션의 데이터를 삭제한다.

—generate: 이 모드는 토픽과 브로커 리스트가 주어지면 툴이 특정 토픽의 모든 파티션들을 새 브로커들로 이동 시킬 재할당 후보를 생성한다. 이 옵션은 단지 주어진 토픽과 브로커 리스트로 파티션 재할당 플랜을 생성하는 편리한 방법을 제공한다.

—execute: 이 모드는 제공된 재할당 플랜을 기반으로 파티션 재할당을 시작한다. 관리자가 작성한 재배치 플랜이 될수도 있고, -generate 옵션 사용으로 제공될수 있다.

—verify: 이 모드는, 마지막으로 execute 되고 있는 재할당 상태를 확인한다. 상태는 성공적인 완료, 실패, 수행중일 수 있다.

topic, broker 리스트

`“topics”: [{“topic”: “foo1”](),

“topic”: “foo2”],

“version”:1

}

DECOMMISSIONING BROKERS

아직 파티션 재할당 툴은 디커미셔닝 브로커를 위한 재할당 플랜을 자동으로 생성할 수 없다.

관리자가 브로커의 호스팅 되는 모든 파티션 레플리카를 디커미션할 브로커로 옮겨한다.

브로커 디커미셔닝을 지원하는 툴을 추가할 계획

INCREASING REPLICATION FACTOR

재할당 json에 추가할 레플리카를 지정하고, -execute 옵션을 사용해 실행

topic, broker partition 리스트

Kafka 개요