1. 카프카 등장 배경
카프카는 Linked-In에서 소스 애플리케이션고 타켓 애플리케이션을 분리하기 위해 만들어졌다. 기존의 데이터 파이프라인은 아래와 같이 각각의 애플리케이션을 직접 연결하는 구조였는데 아래와 같이 타겟 애플리케이션에 장애가 발생하면 소스 애플리케이션에도 치명적인 문제가 발생한다. 또한, 아키텍처가 복잡해짐에따라 애플리케이션의 갯수가 많아지면서 데이터 파이프라인도 기하급수적으로 복잡해졌다. 이러한 문제를 해결하고자 Linked-In에서는 카프카를 만들어냈고 카프카는 애플리케이션을 직접 연결하는 방식이 아니라 중앙에서 데이터를 처리하는 방식으로 모든 애플리케이션이 카프카를 통해 데이터를 수집하고 분배한다.
2. 카프카의 특징
1️⃣ 높은 처리량
카프카도 결국 데이터를 전송하려면 송수신 네트워크를 열고 통신해야하는데 데이터 전송량이 많을수록 그 비용을 무시할 수 없다. 따라서, 카프카에서는 배치단위로 데이터를 전송할 수 있는 옵션(fetch.min.byte 등)들을 제공해 네트워크 통신 횟수를 최소화해 동일 시간 내에 더 많은 데이터를 전송할 수 있도록 도와준다. 또한, 복수의 파티션과 적절한 사이즈의 컨슈머그룹을 통해 데이터를 병렬처리함으로써 시간당 데이터 처리량을 늘린다.
2️⃣ 확장성
데이터 전송량은 항상 예측하기 어렵다. 그렇기 때문에 카프카 클러스터는 오토스케일링(auto-scailing)을 지원한다. 데이터 전송량에 맞춰 가변적으로 브로커를 무중단 확장/축소해 유연하고 안정적인 운영함으로써 확장성을 보장한다.
3️⃣ 영속성
카프카는 다른 메세징플랫폼과 다르게 데이터를 메모리에 저장하지 않고 디스크기반의 파일 시스템에 저장한다. 성능적인 부분을 고려했을때 디스크 기반으로 느린 문제가 있지만, 카프카에서는 메모리의 페이지캐시를 사용해 한 번 읽은 파일의 내용을 메모리에 캐싱하기 때문에 디스크 기반의 파일시스템을 사용하더라도 높은 처리량을 보장한다.
4️⃣ 고가용성
카프카는 파티션 데이터의 복제(replication)를 통해 고가용성의 특징을 가진다. 실제 프로듀서, 컨슈머 사이에서 데이터를 받고 이벤트를 발생시키는 브로커외에도 복제 옵션을 설정해 다른 브로커에 파티션을 복제해 저장해두는 형식이다. 이렇게 하면 리더 파티션을 포함하는 브로커에 장애가 발생하더라도 복제된 파티션이 다른 브로커에 존재하기 때문에 파티션 리더를 변경해 지속적으로 데이터 처리가 가능하다.
3. 카프카 기본 구조
1️⃣ Broker
Broker는 클라이언트가 메세지를 전송할때까지 대기하고 메세지 수신 시 이벤트를 발생시키는 역할을 한다. 브로커가 이벤트를 발생시키면 메세지를 구독하고 있는 특정 클라이언트들은 브로커에 발생한 이벤트를 감지해 메세지를 읽어온다.
2️⃣ Topic
Topic은 브로커 내부에 존재하며 메세지를 유형별로 분류 해놓은 공간을 의미한다. 예를 들어, 클라이언트의 요청 메세지와 응답 메세지를 카프카를 통해 주고받아야 한다면 "Request Topic"과 "Response Topic"으로 유형을 나눠 메세지를 분리해 저장하겠다는 것이다. 토픽 개념을 추가해 추상적으로 내부를 살펴보면 아래와 같다.
3️⃣ Partition
토픽이 메세지를 유형별로 분류 해놓은 공간을 의미한다면, Partition은 토픽 내부에서 실질적으로 데이터를 저장하는 공간을 의미한다. 토픽 내부에는 파티션을 1개 이상 생성해 사용할 수 있다. 최대 파티션 수는 별도로 없으나 메모리 관점에서 잘 판단해 구성해야한다.
