<Kafka 발제 자료>

Kafka

 

 

 

등장배경

 

• 링크드인에서 근무하던 Jay Kreps, Jun Rao, Neha Narkhede가 개발
• 데이터 파이프라인의 확장, 기종 간의 호환성, 고성능 기반의 스트림 데이터 처리의 문제를 해결하기 위해 개발
• 2011년 Apache 오픈소스로 공개

 

• LINE의 Kafka 도입 사례 

 

 

 

• 카카오 전사 모니터링 시스템(KEMI)의 Kafka 도입 사례

 

 

Kafka의 장점

 

높은 처리량, 빠른 응답속도, 안정성

 

1. 빠른 데이터 수집이 가능한 높은 처리량

• HTTP 기반으로 전달되는 이벤트임에도 한 자릿수 밀리초의 응답시간으로 처리
• 카프카 도입 전보다 광범위한 데이터 흐름 만들기 가능

 

1. 이벤트 처리 순서 보장

• 엔터티 간 유효성 검사나 동시 수정 같은 무수한 복잡성 제거

 

1. 적어도 한 번 전송 방식(At least Once)

• 멱등성 보장 : 동일한 작업을 여러 번 수행하더라도 결과가 달라지지 않는다
• 프로듀서가 재전송을 하더라도 데이터 변화가 일어나지 않는다
• 누락 없는 재전송 가능
• 백엔드 시스템 내 복잡한 트랜잭션 처리 불필요

 

1. 자연스러운 백프레셔 핸들링

• Kafka 클라이언트가 Pull 방식으로 동작
• 복잡한 피드백이나 제한의 요구사항이 사라져 매우 간단하고 편리하게 클라이언트 구현

 

1. 강력한 파티셔닝

• 논리적으로 토픽을 여러 개로 분리 가능
• 다른 파티션들과 관계없이 효과적인 수평 확장 가능

 

프로듀서와 컨슈머가 완벽하게 분리된 비동기식 방식을 사용함에 따라 애플리케이션의 병목 현상 정확하게 파악 가능

 

어떤 식으로 구성되어 있는지 좀 더 자세하게 알아보자.

 

구성요소

 

• 주키퍼(Zookeeper) : 카프카의 메타데이터 관리 및 브로커의 정상상태 점검을 담당

 

• 카프카(Kafka / Kafka Cluster) : 여러 대의 브로커를 구성한 클러스터

 

• 브로커(Broker) : 카프카 애플리케이션이 설치된 서버 또는 노드

 

• 프로듀서(Producer) : 카프카로 메시지를 보내는 역할을 하는 클라이언트

 

• 컨슈머(Consumer) : 카프카에서 메시지를 꺼내가는 역할을 하는 클라이언트

 

• 토픽(Topic) : 카프카의 메시지 피드들을 토픽으로 구분

 

• 파티션(Partition) : 병렬 처리 및 고성능을 얻기 위해 하나의 토픽을 여러 개로 나눔

 

• 세그먼트(Segment) :  프로듀서가 전송한 실제 메시지가 브로커의 로컬 디스크에 저장된 파일 

 

• 메시지(Message) 또는 레코드(Record) : 프로듀서가 브로커로 전송하거나 컨슈머가 읽어가는 데이터 조각

 

 

Topic / Partition / Segment

 

• 카프카 클러스터 내 토픽 단위로만 저장이 된다면?

 

Partition

• 토픽 하나를 여러 개로 나눠 병렬 및 분산 처리가 가능하게 만듦
• 나뉜 파티션 수 만큼 컨슈머를 연결할 수 있음
• 프로듀서에 의해 브로커로 전송된 메시지는 토픽의 파티션에 저장

 

 

 

• Partitioner에 의해 레코드는 어느 파티션으로 갈지 정해진다

 

• Defaultpartitioner

 

• Leader Partition / Follower Partition

 

• Leader Partition
• Follower Partition

 

Segment

• 각 메시지들은 세그먼트라는 로그 파일의 형태로 브로커의 로컬 디스크에 저장
• 세그먼트 파일이 지정된 크기보다 크거나 지정된 기간보다 오래되면 새 파일이 열리고 메시지는 새 파일에 추가

 

Zookeeper의 역할

 

• 여러 대의 서버를 클러스터로 구성하고 살아 있는 노드 수가 과반수 이상 유지된다면 지속적인 서비스가 가능한 구조
• Znode를 이용해 카프카의 메타 정보가 주키퍼에 기록
• Kafka의 Zookeeper 의존성을 제거하는 버전 출시(Kafka Connect / Streams)

 

Producer / Consumer

 

Producer

 

 

[주요 옵션]

 

적어도 한 번 전송(At least once)

 

 

• Ack를 받지 못하면 재전송하는 방식으로 구현
• 중복 전송의 가능성 존재
• Delivery.timeout.ms 초과 시 적어도 한번 전송은 지켜지지 않음

 

Consumer

 

 

• 자신의 오프셋 정보를 카프카에서 가장 안전한 저장소인 토픽에 저장
• _consumer_offsets 토픽에 컨슈머 그룹별로 오프셋 위치 정보가 기록

 

Consumer Group

• 컨슈머들을 묶어놓은 그룹
• 파티션이 여러 개이므로, Consumer가 여러 개 있어야 효율적

 

Group Coordinator

• 컨슈머 그룹이 구독한 토픽의 파티션들과 그룹의 멤버들을 트래킹
• 컨슈머들은 하나의 컨슈머 그룹의 구성원

 

컨슈머 리밸런싱

• 일반적인 컨슈머 그룹 : 각 컨슈머를 식별하기 위해 엔티티 ID를 부여
• 컨슈머 설정 변경 or 소프트웨어 업데이트로 인해 컨슈머 재시작 시 기존 동일한 컨슈머 임에도 새로운 엔터티 ID 부여되는 상황 발생
• Static Membership 도입

 

컨슈머 파티션

• 대상 토픽의 어느 파티션으로부터 레코드를 읽어올지를 결정
• 컨슈머 옵션의 partition.assignment.strategy로 표시
• RangeAssignor / RoundRobinAssignor / StickyAssignor / CooperativeStickyAssignor 총 4가지의 파티션 할당 전략 제공

 

 

• RangeAssignor

 

• RoundRobinAssignor

 

위 두 방식에서 컨슈머 리밸런싱 동작이 일어난다면?

 

파티션 재할당 시 기존에 매핑되었던 파티션과 동일한 컨슈머가 다시 매핑된다는 보장이 없다.

 

• StickyAssignor

 

다음과 같은 상황을 가정해보자.

 

• 컨슈머 2가 컨슈머 그룹에서 이탈

 

 

• Round-Robin /. Sticky Assignor 방식의 차이점

 

- 컨슈머 그룹의 리밸런싱으로 인해 새로운 파티션이 할당

 

 

- 컨슈머2에 할당된 파티션들만 컨슈머1과 컨슈머3에 새로 각각 할당된 것을 알 수 있음

 

• CooperativeStickyAssignor

 

 

카프카의 핵심 개념

 

Replication

 

 

• 각 메시지들을 여러 개로 복제해서 카프카 클러스터 내 브로커들에 분산시키는 동작
• 하나의 브로커가 종료되더라도 카프카는 안정성을 유지
• 일반적으로 모든 토픽에 대해 각 3개의 리플리케이션으로 설정

 

분산 시스템

 

• 최초 구성한 클러스터의 리소스가 한계치 도달 시 브로커 추가 방식으로 확장 가능
• 온라인 상태에서 매우 간단히 브로커 추가가 용이 

 

Page Cache

 

• 높은 처리량을 얻기 위해 사용하는 대표적 기능
• 직접 디스크에 읽고 쓰는 대신 물리 메모리 중 애플리케이션이 사용하지 않는 일부 잔여 메모리 활용
• 디스크 I/O 접근이 줄어들어 성능을 높일 수 있음

 

Kafka Connect & Kafka Streams

 

Kafka connect

 

 

• 데이터베이스 같은 외부 시스템과 카프카를 손쉽게 연결하기 위한 프레임워크
• 대용량의 데이터를 카프카의 안팎으로 손쉽게 이동 가능
• 코드를 작성하지 않고도 간단히 사용할 수 있음
• Kafka Connect에서 제공하는 REST API를 통해 빠르고 간단하게 커넥트의 설정을 조정하고 상황에 맞게 유연하게 대응

 

• 장점

 

핵심 개념

 

(총 3대의 워커를 실행한 분산 모드 소스 커넥트)

 

• Worker : 카프카 커넥트 프로세스가 실행되는 서버 또는 인스턴스
• Source Connect : 프로듀서의 역할 담당
• Sink Connect : 컨슈머의 역할 담당
• Connector : 직접 데이터를 복사하지 않고 데이터를 어디에서 어디로 복사해야 하는지의 작업을 정의하고 관리
• Task : 커넥터가 정의한 작업을 직접 수행하는 역할

 

Connector는 데이터 전송에 관한 작업을 정의한 후 각 태스크들을 워커에 분산하고, 워커에 분산 배치된 태스크들은 커넥터가 정의한 작업대로 데이터를 복사한다.

 

Kafka streams

 

• 입력 및 출력 데이터가 Apache Kafka 클러스터에 저장되는 애플리케이션 및 마이크로 서비스 구축을 위한 클라이언트 라이브러리
• 클라이언트 측에서 표준 Java 및 Scala 애플리케이션을 작성하고 배포하는 단순성과 Kafka의 서버 측 클러스터 기술의 이점을 결합

 

• 특징

위 기능을 구현할 수 있도록 Streams API는 filter(), map(), groupBy() 등 다양한 처리 및 집계 함수를 제공한다.

 

 

Kafka Streams는 Streams API에 구축된 애플리케이션으로, 브로커와 별도로 구성된다. 카프카 스트림즈 애플리케이션은 확장에 유연하고, 장애 수용성을 가지며, 분산 형태로 구성할 수 있다.

• 카프카에서 공식적으로 제공하는 자바 라이브러리
• 토픽에 있는 데이터를 낮은 지연과 함께 빠른 속도로 데이터를 처리할 수 있다.

 

1. 카프카와 완벽하게 호환
2. 스케쥴링 도구 불필요
3. 스트림즈 DSL과 프로세서 API 제공

 

1. 로컬 상태저장소 사용

 

• 공식문서

 

 

실습

 

링크 : https://harveywoods.tistory.com/117

 

비밀번호 0000

 

1. Docker 환경 확인
2. docker-compose.yml 작성
3. Docker-compose 실행
4. Container 실행 여부 확인
5. Kafka 컨테이너 접속
6. Kafka 토픽 생성
7. Producer 접속
8. Consumer 접속

 

 

참고자료

 

• <실전 카프카 개발부터 운영까지>, 고승범
• https://docs.confluent.io/platform/current/streams/overview.html

 

• <카프카 스트림즈! 대용량, 폭발적인 성능의 실시간 데이터처리!>, 데브원영

 

• 라인 엔지니어링 블로그