[카프카] 무엇이고, 왜 필요할까?

카프카 데이터 플랫폼의 최강자 1장을 읽고 정리한 내용입니다.

배경지식

1. MOM(Message Oriented Middleware) : 메시지 지향 미들웨어
   1.1 다른 미들웨어 종류: RPC 방식, ORB 방식
   1.2 미들웨어: 어플리케이션들을 연결시켜, 서로 데이터를 교환할 수 있게 해주는 소프트웨어
   1.3 메시지 지향: 메시지 전달을 통해 데이터를 교환할 수 있게 만들어주는 시스템.

2. Message Broker
   
   2.1 MOM 기반으로 메시지 전송을 담당하는 시스템.
   2.2 Publisher(송신자)로부터 전달받은 메시지를 Subscriber(수신자)로 전달해주는 중간 역할 → 응용 소프트웨어 간에 메시지 교환 담당
   2.3 이때, 메시지가 적재되는 공간: Message Queue.
   2.4 오픈소스 종류 : RabbitMQ,Apache Kafka, ActiveMQ, ... 
   2.5 장점

   비동기(Asynchronous) : Queue에 넣기 때문에 후처리 가능
   비동조(Decoupling) : 애플리케이션과 분리 가능
   탄력성(Resilience) : 일부가 실패해도, 전체에 영향 미비
   과잉(Redundancy) : 실패 할 경우 재실행 가능
   보증(Guarantees) : 작업완료 확인 가능
   확장성(Scalable) : 다수의 프로세스들이 큐에 메시지를 보낼 수 있음

 탄생 배경 이해

카프카란?!

1. 메시징 시스템
2. 대용량, 대규모 메시지 데이터를 빠르게 처리할 수 있는 메시징 시스템
   링크드인에서 시작했으나 → 현재는 아파치 공식 오픈소스

링크드인은 왜 카프카를 만들었을까?

기존 ene-to-end 연결 방식 아키텍처의 많은 문제점 해결을 위해서

1. 통합/ 중앙화된 전송 영역이 없음 → end-to-end 연결이 갈수록 복잡해짐
2. 문제 발생 시 관련 여러 시스템을 확인해야 함 → 문제 해결이 어려워짐
   하드웨어 증설 같은 작업이 어려움
3. 데이터 파이프라인 관리의 어려움
4. 연결된 시스템 마다 제각기 다른 방식으로 구현될 수 있음 → 파이프라인 통합(확장)이 어려움

---

이런 문제를 해결하기 위해

1. 모든 시스템으로 데이터를 전송할 수 있고
2. 실시간 처리 가능하고
3. 급속도로 성장하는 서비스를 위해 확장이 용이한

시스템(카프카)을 만들자

카프카 개발팀의 목표
1. 프로듀서와 컨슈머의 분리
2. 메시징 시스템과 같이 영구 메시지 데이터를 여러 컨슈머에게 허용
높은 처리량을 위한 메시지 최적화
3. 데이터가 증가함에 따라 scale - out 이 가능한 시스템
4. end-to-end 방식 => 이벤트/ 데이터의 흐름을 중앙에서 관리하는 방식
4.1 end-to-end 방식

4.2 이벤트/데이터 흐름을 중앙에서 관리하는 방식

카프카의 동작 방식과 원리

카프카는 pub/sub 모델을 기반으로 만들어진 메세징 시스템

메시징 시스템이란?!
"로그 데이터, 이벤트 메시지 등 API 로 호출할 때 보내는 데이터들을 처리하는 시스템"

pub/sub 모델이란?
중앙에 메시징 시스템 서버를 두고, 메시지를 보내고(publish), 받는(subscribe) 형태의 통신
구독을 신청한 수신자만 메세지를 전달받을 수 있음
장점(기존 네트워크 통신 방식의 단점 극복)
개체가 빠지거나 수신 불능이 되도, 메시징 시스템만 살아있으면 전달한 메시지가 유실 x
N:M으로 연결되는 것이 아니기 때문에 확장성이 용이

1. 데이터 단위: 메시지(로그 데이터, 이벤트 메시지 등등)
2. 데이터 보내는 측 : Publisher, Producer
3. 데이터 가져가는 측: Subscriber, Consumer
4. 주제별 데이터 저장소: 토픽

---

전체 돌아가는 방식을 간단히 정리하면

1. 포르듀서가 새로운 메시지를 카프카로 보냄
2. 프로듀서가 보낸 메시지는 카프카에 컨슈머 큐(카프카 기준 토픽-식별자-)에 도착해 저장됨
3. 컨슈머는 카프카 서버에 접속해 새로운 메시지 가져감

추가 용어 정리

1. 카프카 : 아파치 프로젝트 애플리케이션 이름. 클러스터 구성이 가능하며 카프카 클러스터라고 부름 
2. 브로커 : 카프카 애플리케이션이 설치되어 있는 서버 또는 노드
3. 토픽 : 메시지 그룹. 프로듀서와 컨슈머들이 카프카로 보낸 자신들의 메시지를 구분하기 위한 이름으로 사용함. 많은 수의 프로듀서, 컨슈머들이 동일한 카프카를 이용하게 된다면 메시지들이 서로 뒤섞여 각자 원하는 메시지를 얻기가 어려워짐. 그래서 토픽이라는 이름으로 구분해서 사용
4. 파티션 : 병렬처리가 가능하도록 토픽을 나눌수 있고 많은 양의 메시지를 처리하기 위해 파티션의 수를 늘릴수 있다. 
5. 프로듀서 : 메시지를 생산하여 브로커의 토픽 이름으로 보내는 서버 또는 애플리케이션을 말함
6. 컨슈머 : 브로커의 토픽 이름으로 저장된 메시지를 가져가는 서버 또는 애플리케이션을 말함

pub/sub 모델의 장/단점

장점

1. 기존 네트워크 통신 방식의 단점 극복
2. 개체가 빠지거나 수신 불능이 되도, 메시징 시스템만 살아있으면 전달한 메시지가 유실 x
3. N:M으로 연결되는 것이 아니기 때문에 확장성이 용이

단점

1. 직접 통신하는 것이 아니기 때문에 메시지가 정확하게 전달되었는지 확인하려면 코드가 복잡해짐
2. 메시징 시스템이 있기 때문에 메시지 전달속도가 느림

만약, 메시징 시스템 서버 없이(pub/sub 모델 없이) 직접 연결해서 통신하면?

1. 장점: 속도 빠름
2. 단점: 송,수신자 상태에 따라 장애 처리를 해줘야 함
   참여하는 개체가 많아질수록 각 개체를 연결해줘야 함 → 확장성 불리

카프카는 기존 메시징 시스템의 한계를 어떻게 극복했을까?

기존 메시징 시스템

1. 목적: 간단한 이벤트(n KB 정도의 크기) 전송
2. 특징
   • 메시지 보관, 전달 과정에서 속도, 용량보다 신뢰성 보장을 중요하게 여김
   • 많은 양의 데이터 관리 못함
     (이유: 메시징 시스템 내부의 교환기의 부하, 컨슈머 큐 관리를 직접함, 메시지의 정합성, 전달결과 관리등을 위하여 프로세스가 복잡하고 다양했기 때문에)
     => 데이터를 모으고, 전달함에 있어서 성능 이슈 발생

극복 방법

1. 메시지 교환 전달의 신뢰성 관리를 프로듀서, 컨슈머 쪽으로 넘김
2. 부하가 많이 걸리는 교환기 기능을 컨슈머가 만들 수 있게 함
   -> 메시징 시스템 내의 작업량 줄어듦
   -> 절약한 작업량을 메시징 전달 성능에 집중시킴
   => 고성능 메시징 시스템 만듦

카프카의 특징

1. 프로듀서와 컨슈머의 분리

   • pub / sub 방식을 통해 메시지를 보내는 역할과 받는 역할이 완벽하게 분리됨
     => 다른 시스템, 서비스 서버의 상태와 상관없이 그저 메시지 시스템과 메시지 기반 송/수신 하면 됨.

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

   • 하나의 토픽에 여러 프로듀서 또는 컨슈머들이 접근 가능한 구조 => 이를 통해 카프카는 중앙 집중형 구조로 구성할 수 있음

3. 프로듀서는 1개 이상의 토픽으로 메시지 전송 가능

   • 컨슈머는 1개 이상의 토픽에서 메시지 가져올 수 있음
   • 멀티 기능이 필요한 이유: 데이터 분석 및 처리 프로세스에서 하나의 데이터를 다양한 용도로 사용하는 요구가 많아졌기 때문

4. 디스크에 메시지 저장

   • (기존 메시징 시스템 - RabbitMQ, ActiveMQ): 컨슈머가 메시지 읽어가면 큐에서 바로 삭제

   • (카프카): 보관 주기 동안 디스크에 메시지 저장 -> 트래픽이 폭주해 컨슈머의 처리가 늦어져도 카프카 디스크에 안전하게 보관 됨 -> 메시지 손실x

     디스크 I/O 는 느리지 않을까?
     답: 아니다! 카프카는 페이지 캐시를 이용해서 디스크 접근을 최소화 시켜, 처리 속도가 빠름

     페이지 캐시?!
     OS에서 사용하는 페이지 캐시와 동일함
     → 한 번 읽은 파일의 내용을 페이지 캐시라는 영역에 저장시킴. 파일의 논리적인 내용을 페이지 단위로 캐시하기 위해 사용되며, 파일과 파일 내의 오프셋을 통해 접근. 디스크에서 메모리로 페이지들을 읽어 들이면, 페이지들은 페이지 캐시에 캐싱
     메모리(RAM) 영역에 어플리케이션이 사용하는 부분을 할당하고 남은 잔여 메모리를 캐시로 전환 → 디스크 접근을 최소화시켜 I/O 성능을 향상시키는 메모리 영역
     카프카는 페이지 캐시를 적극적으로 사용함 →  페이지 캐시를 사용하기 위해서 잔여 메모리를 쓰기 때문에, 카프카 서버에 다른 어플리케이션을 함께 실행하는 것을 권장하지 않음.

5. 확장성: 시스템 확장이 용이하다

   • 분산 시스템을 기반으로 설계 → 분산 시스템 구성 및 복제에 대한 설정을 쉽게 할 수 있음
   • 수십 대의 브로커로 간단하게 확장 가능(1개의 카프카 클러스터는 초기 3대로 시작함)
   • 확장 시 서비스의 중단 없이 온라인 상태에서 작업 가능

6. 높은 성능

   • 분산 처리 가능 -> 하나의 서버/노드에서 장애 발생하면 다른 서버/노드가 대신 처리 가능
     
   • 배치 처리 가능
     • 예상 문제 상황: 서버와 클라이언트간에 데이터를 주고 받는 경우라면 I/O가 발생 → 네트워크 I/O, 디스크 I/O가 자주 일어나 서버의 속도를 저하
     • 해결 방법 : 크기가 작은 I/O를 그룹핑해서 처리할 수 있도록 배치작업을 통한 처리
   • TCP 기반의 프로토콜을 사용해 오버헤드 감소
     • AMQP 프로토콜을 사용하지 않음
       => 기존의 메시징 시스템과 달리 프로토콜로 인한 오버헤드는 없도록 설계

참고: https://kafka.apache.org/protocol#protocol_network

카프카의 확장과 발전

1. 플러그인을 통해 외부 데이터를 가져와 기업 내에서 활용
2. 기존 메시징 시스템과 브릿지로 연결해서 활용
3. 외부 퍼블릭 클라우드에서 연결해서 사용
4. 데이터 파이프라인으로 활용 가능 ex. 넷플릭스