[Kafka] 카프카, 데이터 플랫폼의 최강자 1~3장

앞으로 하게 될 프로젝트가 이벤트 기반으로의 전환이라 카프카 스터디를 시작하게 되었다.

http://www.yes24.com/Product/Goods/104722929

아파치 카프카의 모든 것 세트 - YES24

세트로 구성된 책을 구매하였고 데이터 플랫폼 책을 먼저 끝낸 후 나머지 책을 스터디 할 예정이다. 화이팅..!!

 

1~3장 : 카프카 탄생 배경, 설치 방법, 장단점

4~5장 : 프로듀서와 컨슈머

6~10장 : 운영 가이드, 람다 아키텍처, 카파 아키텍처와 KSQL 등의 내용으로 이루어져있다.

 

들어가며

과거에는 많은 이벤트들에 대한 부하를 건딜 수 있는 Service Bus system이 없었다. 하지만 최근에는 강력한 메시지 처리 성능과 빠른 수평확장성, 고장감내성에 기반한 이벤트 버스 어플리케이션인 카프카의 도입으로 서비스가 가능해졌다.

그에따라 카프카를 도입해 데이터 파이프라인으로 사용하는 회사들이 늘어났다.

 

1장. 카프카란 무엇인가

1-1. 카프카의 탄생 배경

링크드인에서 출발해 아파치 공식 오픈소스로 공개되었다.

 

기존 링크드인 서비스의 문제점

• 실시간 트랜잭션처리와 비동기 처리에 대한 복잡도 증가
• 데이터 파이프라인 관리의 어려움

 

카프카 도입 후 링크드인 서비스

• 카프카를 전사 데이터 파이프라인으로 도입
• 포맷관리가 필요없이 데이터만 전달하면 나머지는 필요한 곳에서 가져가서 사용하면됨, 본연의 업무에 집중

 

카프카의 목표

• 프로듀서와 컨슈머의 분리
• 메시징 시스템과 같이 영구 메시지 데이터를 여러 컨슈머에게 허용
• 높은 처리량을 위한 메시지와 최적화
• 데이터가 증가함에 따라 스케일아웃이 가능한 시스템

 

1.2 카프카의 동작 방식과 원리

카프카는 메시징 서버로 동작한다. 메시징 시스템이란 데이터를 보내는측에서 카프카에 토픽이라는 메시지를 저장하면 가져가는측에서 데이터를 가져간다.중앙에 메시징 시스템 서버를 두고 메시지를 보내고 받는 형태를 pub/sub 모델이라고 한다. 참고로 구독을 신청한 수신자만 정해진 메시지를 받을 수 있다.

프로듀서가 컨슈머에게 메시지를 직접 전달하는 방식이 아닌 중간의 메시징 시스템에 전달하면, 수신자를 확인 후 메세지를 전달해주는 방식이다. 그렇기 때문에 수신 불능 상태가 되덜도 메시징 시스템만 살아있으면 전달된 메시지는 유실되지 않는다.

각각의 개체가 N:N 통신을 하는것이 아닌 메시징 시스템을 중심으로 연결되기 때문에 확장성이 용이하다. 그리고 데이터 유실의 염려가 없다. 다만 pub/sub 모델의 단점은 직접 통신을 하지 않기 때문에 정확하게 전달되었는지 확인을 위한 코드가 필요하기에 좀 더 복잡하고 중간에 메시징 시스템으로 인해 전달 속도가 빠르지 않다.

기존의 메세징 시스템의 경우 메시지의 교환과 전달 과정의 신뢰성이 중점이었기에 속도와 용량은 중요하지 않았다.

하지만 카프카는 메시징 시스템이 지닌 이러한 성능의 단점을 극복하기 위해 메시지 교환 전달의 신뢰상 관리를 프로듀서와 컨슈머 쪽으로 넘기고, 부하가 많이 걸리는 교환기 기능 역시 컨슈머가 만들 수 있게 함으로써 메시징 시스템 내에서 작업량을 줄여 고성능 메시징 시스템을 만들어냈다.

요약 : 메시징 시스템을 가볍게 만들었다.

 

1.3 카프카의 특징

프로듀서와 컨슈머의 분리

각각의 서비스들의 상태유무와 관계없이 카프카로 메시지를 보내기만하면 되고, 저장되어있는 메시지를 가져오기만 하면 된다.

 

멀티 프로듀서, 멀티 컨슈머

하나의 토픽에 여러 프로듀서와 컨슈머가 접근 가능하다. (= 중앙 집중형 구조로 구성이 가능하다)

 

디스크에 메시지 저장

일반적인 메시징 시스템은 컨슈머가 메시지를 읽으면 큐에서 메시지를 삭제한다. 하지만 카프카는 정해진 보관 주기 만큼 디스크에 메시지를 저장한다.

• 트래픽이 폭주해 컨슈머의 처리가 늦어져도 디스크에 저장되어있기 때문에 메시지 손실 없이 메시지를 가져갈 수 있다.

 

확장성

확장이 매우 용이하다. 기본적으로 하나의 카프카 클러스터는 3대의 브로커를 가지며, 수십 대의 브로커로 확장이 가능하다. 무중단 확장 가능

 

높은 성능

내부적으로 분산 처리, 배치 처리 등을 사용한 고성능 어플리케이션이다.

 

1.4 카프카의 확장과 발전

• 다양한 시스템과 연동하기 위한 멀티 프로토콜과 데이터 타입 지원
• 느슨한 결합을 위한 메시지 큐 지원
• 이벤트 기반 통신 지향

---

 

2장. 카프카 설치

카프카 설치는 직접 하지는 않고, 간단한 내용만 정리할 예정

2.1 카프카 관리를 위한 주키퍼

카프카는 프로듀서 컨슈머 이외에도 주키퍼와 통신을 한다. 주키퍼는 컨슈머와 통신하는 부분 이외에도 카프카와 직접 통신을 하면서, 카프카의 메타데이터 정보를 저장하고, 카프카 상태관리 등의 목적으로 주키퍼를 이용한다. 그렇기에 카프카 설치시 주키퍼 또한 필수적이다.

• 카프카는 주키퍼를 코디네이션 로직으로 이용
• 주키퍼는 분산 어플리케이션을 위한 코디네이션 시스템으로 분산어플리케이션이 안정적인 서비스를 할 수 있도록 각 어플리케이션의 정보를 중앙에 집중하고 구성 관리, 그룹 관리 네이밍, 동기화 서비스 제공
• 주키퍼에 저장되는 데이터는 모두 메모리에 저장되어 처리량이 매우 크고 속도가 빠름
• 신뢰성 있는 서비스를 위해 앙상블(클러스터) 이라는 호스트를 세트로 구성 가능 - 살아 있는 노드 수가 과반수 이상 유지되면 지속적 서비스 가능
• 앙상블 구성이 많을 수록 초당 처리량 증가

 

주키퍼를 사용하는 자바 어플리케이션 주의사항

주키퍼로 노드를 관리하는 어플리케이션들은 임시 노드를 이용해 어플리케이션 호스트를 등록하고, 어플리케이션의 통신이 끊어지면 임시 노드에서 해당 호스트를 삭제한다. 자바 기반 어플리케이션의 경우 풀GC 발생시 멈춤 상태에 빠지게 된다.

• 자바 어플리케이션의 GC타임을 주기적으로 체크하고, 세션 타임아웃 설정도 3초이상으로 설정하기를 권장

 

카프카 상태확인

systemctl status -> active 상태여야함

---

 

3장. 카프카 디자인

3.1 카프카 디자인 특징

3.1.1 분산 시스템의 장점

• 단일 시스템보다 더 높은 성능을 얻을 수 있다
• 분산 시스템 중 하나의 서버 또는 노드에 장애 발생시 다른 서버 또는 노드가 대신 처리
• 시스템 확장이 용이

 

3.1.2 페이지 캐시

처리량을 높이기 위해 페이지 캐시를 사용한다.

• OS에서 물리적 메모리에 어플리케이션이 사용하는 부분을 할당 후 남은 잔여 메모리 일부를 페이지 캐시로 유지해 성능 향상
• 디스크에 읽고 쓰기를 하지 않고 페이지 캐시를 통해 읽고 쓰는 방식

JVM 힙 사이즈

카프카는 기본값으로 1GB의 힙 메모리를 사용

공식 문서에 따르면 5GB면 충분, 남은 메모리는 페이지 캐시로 사용하기를 권장

 

3.1.3 배치 전송 처리

데이터를 주고 받는 과정에서 I/O 발생시 속도를 저하시키는 원인이 된다. 따라서 카프카에서는 작은 I/O 작업들을 배치 처리한다.

 

3.2 카프카 데이터 모델

3.2.1 토픽의 이해

카프카가 발전하는데에는 토픽, 파티션의 데이터 모델의 역할이 크다.

토픽 : 데이터를 저장하는곳

 

3.2.2 파티션의 이해

파티션 : 토픽을 분할한 것

토픽을 분할하여 처리량을 늘릴 수 있음 -> 그럼 무조건 파티션 수를 늘리면 좋을까??

No

• 파일 핸들러의 낭비
• 각 파티션은 브로커의 디렉토리와 매핑되는데, 카프카에서는 모든 디렉토리의 파일들에 대해 파일 핸들을 열게된다. 그래서 리소스 낭비 발생

• 장애 복구 시간 증가이 과정에서 파티션이 많을 경우 각 파티션별 새로운 리더를 선출하는 시간 소요가 증가하여 일부 파티션의 장애 시간이 길어질 수 있다.
• 카프카는 높은 가용성을 위해 리플리케이션을 지원한다. 각 파티션마다 리플리케이션이 동작하며, 하나는 파티션의 리더 나머지는 팔로워가 된다. 만약 브로커가 다운되면 해당 브로커에 리더가 있는 파티션은 일시적으로 사용할 수 없게 된다. 리더를 팔로워로 이동시켜 클라이언트 요청을 처리하게 한다.

그럼 적절한 파티션 수는 어떻게 설정할까

• 원하는 목표 처리량의 기준 잡기

ex) 4개의 프로듀서로 초당 10개의 메시지 발행 -> 카프카에서 초당 총 40개의 메시지를 받아 줘야함 -> 파티션이 1일때 10개의 메시지만 수신시 파티션을 4개로 늘려 목표 처리량 달성 (컨슈머 고려 안함)

컨슈머에서 8개의 컨슈머를 통해 각각 초당 5개의 메시지를 토픽으로부터 가져올 수 있다면, 해당 토픽의 파티션수는 컨슈머 수와 같은 8개 필요

파티션의 수를 줄일 수 없음 소극적으로 파티션을 생성 후 병목현상 발생시 조금씩 늘려가는 방법이 적당

• 카프카에서는 브로커당 약 2000개의 최대 파티션 수를 권장

 

3.2.3 오프셋과 메시지 순서

오프셋 : 각 파티션마다 메시지가 저장되는 위치, 순차적으로 증가하는 숫자(64비트 정수)형태, 해당 파티션 내에서만 고유한 값, 오프셋 순서 바꾸기 x

 

3.3 카프카의 고가용성과 리플리케이션

• 분산 어플리케이션으로 물리적 장애 발생시 높은 고가용성을 제공
• 토픽을 복제하는 것이 아닌 해당 토픽의 각각의 파티션을 복사

 

3.3.1 리플리케이션 팩터와, 리더 팔로워

Replication Factor : 기본값 1, 모든 브로커에 동일하게 설정해야함, 컨피그 내용 변경 후 브로커를 1대씩 재시작

• 간단하게 말해 리플리케이션 요소를 몇개 배치할거냐
• 파티션에 장애 발생시 팔로워가 리더로 바뀌면서 브로커 역할 수행

리플리케이션 단점

1. 브로커1이 100GB면, 브로커2에도 100GB가 필요하기 때문에 토픽 사이즈 * factor 만큼의 저장소 필요
2. 리소스 사용량 증가 -> 완벽한 리플리케이션 보장을 위해 비활성화된 토픽의 헬스 체크를 하여 리소스 사용량 증가

모든 토픽에 Replication Factor를 적용하기보다는, 해당 토픽의 중요도에 따라 2 혹은 3으로 설정해 운영하는 것이 효율적

 

3.3.2 리더와 팔로워의 관리

팔로워에 문제가 발생해 리더로부터 데이터를 가져오지 못한다면???

ISR(In Sync Replica) 도입

• 현재 리플리케이션 되고 있는 그룹데이터 동기화 작업을 매우 중요하게 처리하고 있으며, ISR 그룹을 퉁해 리플리케이션의 신뢰성을 높인다.
• ex) replication factor 2로 리더 1 팔로워 2로 운영되고있다면 ISR 그룹에는 1,2가 존재, 1이 다운되면 2가 새로운 리더로

 

3.4 최악의 상황

모든 브로커 다운?!?!

1. 마지막 리더가 살아나기를 기다린다 (기도메타)
2. ISR에서 추방되었지만 먼저 살아나면 자동으로 리더가 된다.