Chapter 1. 카프카란 무엇인가

[kmg28801]

카프카의 탄생과 배경

• 서비스 유지를 위해 필요한 데이터 시스템
  • 메트릭 모니터링용 데이터 시스템 : 앱이나 서비스에서 일어나는 미터링(사용량, 응답 시간, 에러 카운트 등) 정도를 저장할 시계열 데이터 처리용 시스템
  • 로그 모니터링용 데이터 시스템 : 앱/서비스에서 발생하는 로그를 저장하고, 이것을 기반으로 실시간/배치로 분석할 수 있도록 데이터를 저장하는 시스템
  • 서비스에 필요한 컨텐츠와 고객 정보 데이터들을 저장하는 메인 데이터 시스템. 대부분의 앱들에서 보낸 OLTP(OnLine Transaction Process) 쿼리를 실행한다.
  • 추천이나 장바구니와 같이 트랜잭션 처리까진 필요없지만 실시간으로 처리를 해줘야하는 내용을 저장하는 키/값 저장소. 앱이나 사용자는 HTTP프로토콜이나 OLTP 쿼리를 실행한다.
  • 서비스와 제품군 전체에서 발생하는 데이터를 모아서 일간/주간/월간/연간 데이터를 제공하는 데이터 마켓이나 이것을 활용해 배치 분석을 하는 데이터 웨어하우스. 각종 데이터 시스템에서 이곳으로 데이터를 보낸다.
  • 빅데이터를 저장/처리하기 위한 하둡 시스템. 빅데이터를 처리해서 데이터 웨어하우스에 보낸다. 이런 작업을 ETL(Extract, Transform, Load) 작업이라고 한다.

엔드투엔드 연결 방식 아키텍처의 문제점

• 실시간 트랜잭션 처리와 비동기 처리가 동시에 이뤄지지만 통합된 전송 영역이 없으니 복잡도가 증가
  • 문제를 발견하고 조치를 취하려면 이와 관련된 여러 데이터 시스템을 확인
  • 장애나 운영체제 업그레이드, 하드웨어 증설 등과 같은 작업을 위해서도 많은 준비가 필요
• 데이터 파이프라인 관리의 어려움
  • 실시간 트랜잭션 데이터베이스, 아파치 하둡, 모니터링 시스템, 키-값 저장소(Redis, Memcached 등..) 등 많은 데이터 시스템들이 각자의 개발 부서마다 다른 방법으로 관리하고 유지하면서 통합 데이터 분석이 어려워짐

카프카 탄생 목적

• 모든 시스템으로 데이터 전송 가능
• 실시간 처리도 가능
• 확장이 용이한(스케일 아웃이 가능한) 시스템
• 프로듀서와 컨슈머의 분리
• 메시징 시스템과 같이 영구 메시지 데이터를 여러 컨슈머에게 허용
• 높은 처리량을 위한 메시지 최적화

• 아래 그림은 카프카를 메시지 전달의 중앙 플랫폼으로 두고 기업에서 필요한 모든 데이터 시스템(오라클과 같은 실시간 트랜잭션, NoSQL류의 키-값 스토어, 실시간 분석 시스템, 스트림 처리 시스템, 하둡, 데이터 웨어하우스) 뿐만 아니라 마이크로서비스, SaaS 서비스 등과 연결된 파이프라인을 만드는 것을 목표로 두고 개발됨

카프카의 동작 방식과 원리

• 카프카는 기본적으로 메시징 서버로 동작

  메시징 시스템 : 메시지라고 불리는 데이터 단위를 보내는 측(프로듀서)에서 카프카에 토픽 이라는 각각의 메시지 저장소에 데이터를 저장하면, 컨슈머가 원하는 토픽에서 데이터를 가져가게 되어있는 구조

• 위와 같이 중앙에 메시징 시스템 서버를 두고 메시지를 Publish/Subscribe 형태의 통신을 펍/섭 모델이라고 한다.

  펍/섭 모델 : 비동기 메시징 전송 방식으로서, 프로듀서의 메시지에는 수신자가 정해져 있지 않은 상태로 발행한다. 구독을 신청한 컨슈머만이 정해진 메시지를 받을 수 있으며, 컨슈머는 프로듀서 정보가 없어도 원하는 메시지만을 수신 가능

동기 통신 vs 비동기 통신

• 동기 통신의 문제점
  • 수신하는 쪽에서 장애가 발생한 경우, 송신하는 쪽에서 타임아웃 설정을 개별적으로 해주지 않으면 송신자도 장애 발생 가능
  • 통신에 참여하는 개체가 많아질수록 서로 일일이 다 연결을 하고 데이터를 전송해야 하기에 확장성이 좋지 않음

펍/섭 모델

• 프로듀서는 중간의 메시징 시스템에 메시지를 전달 (메시지 데이터와 컨슈머 ID` 포함)

• 메시징 시스템의 교환기가 메시지의 컨슈머 ID값 확인 후 컨슈머들의 큐에 전달

• 컨슈머는 자신들의 큐를 모니터링하고 있다가, 큐에 메시지가 전달되면 이 값을 처리

• 장점

  • 혹시나 컨슈머가 빠지거나 수신 불능 상태가 되었을 때에도, 메시징 시스템만 살아 있으면 프로듀서에서 전달된 메시지가 유실되지 않음
  • 이 메시지는 불능 상태의 컨슈머가 다시 회복되면 언제든지 다시 컨슈밍 가능
  • 각각의 개체가 N:N 통신이 아니고, 메시징 시스템을 중심으로 연결되기에 확장성이 용이

• 단점

  • 직접 통신을 하지 않기에 메시지가 정확하게 전달되었는지 확인하기 위한 코드가 복잡
  • 중간에 메시징 시스템이 있기에 전송 속도가 느림

• 기존 메시징 시스템을 사용하는 펍/섭 모델은 위와 같은 단점으로 간단한 이벤트를 전송하는 데 주로 사용

• 메시징 시스템 내부의 교환기의 부하, 각 컨슈머의 큐 관리, 큐에 전달되고 가져가는 메시지의 정합성, 전달 결과를 정확하게 관리하기 위한 내부 프로세스가 매우 복잡하기에 대규모 메시징 시스템에서는 부적합

카프카

• 위 펍/섭 모델의 문제점을 해결하고자 카프카는 메시지 교환 전달의 신뢰성 관리를 프로듀서와 컨슈머로 넘기고, 부하가 많이 걸리는 교환기 기능 역시 컨슈머가 만들 수 있게 함으로써 메시징 시스템 내에서의 작업량을 줄이고, 메시징 전달 성능에 집중시켜 고성능 메시징 시스템을 만들어냄

• 카프카 메시지 전달 순서

  • 프로듀서는 새로운 메시지를 카프카로 프로듀싱
  • 프로듀서가 보낸 메시지는 카프카 토픽에 도착해 저장
  • 컨슈머는 카프카 서버에 접속해 신규 프로듀싱된 메시지를 컨슈밍

• 프로듀서는 컨슈머와 관계없이 새로운 메시지를 카프카 토픽에 프로듀싱하고, 컨슈머 역시 프로듀서와 관계없이 카프카에서 새로운 메시지를 컨슈밍

• 카프카에는 수많은 메시지들이 저장되고, 그 메시지들은 토픽 단위로 저장

카프카의 특징

• 프로듀서와 컨슈머의 분리
  • 카프카는 메시징 전송 방식 중 메시지를 보내는 역할과 받는 역할이 완벽하게 분리된 펍/섭 방식을 적용

• 위 그림 아키텍처의 문제점

  • 웹 서버 1대 추가된다면, 웹 서버만 추가되는 것이 아니라 웹 서버와 연결될 모니터링 서버, 로그분석 서버, 트랙킹 서버, 데이터저장 서버에 추가된 웹 서버의 IP 정보를 추가해야됨, 방화벽도 뚫어야될 수도
  • 일대일로 통신하고 있던 모니터링 서버에 문제가 생겨 응답이 늦어지면, 연쇄작용으로 모니터링 서버와 연결된 다른 서비스에도 지연이 발생해 장애로 이어질 수 있음

• 카프카 도입 아키텍처

  

• 각각의 서비스 서버들은 모니터링이나 분석 시스템의 상태 유무와 관계없이 카프카로 메시지를 프로듀싱 하는 역할만 수행

• 마찬가지로 모니터링/분석 시스템들도 서비스 서버들의 상태유무와 관계없이 카프카에 저장되어 있는 메시지를 컨슈밍만 하면 됨

• 각자의 역할이 완벽하게 분리되면서, 어느 한쪽 시스템에서 문제가 발생하더라도 연쇄작용이 발생할 확률이 낮아짐

• 웹 서버가 추가되더라도, 위에서와 달리 웹 서버의 IP, 방화벽 등에 관심을 안 가져도 됨

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

  • 카프카는 하나의 토픽에 여러 프로듀서 또는 컨슈머들이 접근 가능한 구조
  • 하나의 프로듀서가 하나 또는 여러개의 토픽으로 메시지를 보낼 수 있음
  • 컨슈머 또한 여러개의 토픽에서 메시지를 가져올 수 있음

• 위와 같은 멀티 기능은 데이터 분석 및 처리 프로세스에서 하나의 데이터를 다양한 용도로 사용하는 요구가 많아짐에 따라 대응하기 위한 용도

• 디스크에 메시지 저장 (매우 중요한 기능)

  • 카프카가 기존의 메시징 시스템과 가장 다른 특징 중 하나가 디스크에 메시지를 저장하고 유지(일정 기간 : 설정 파일로 설정 가능)
  • 일반적인 메시징 시스템들은 컨슈머가 메시지를 읽어가면 큐에서 바로 메시지를 삭제하는 반면, 카프카는 정해져ㅑ 있는 보관 주기 동안 메시지를 디스크에 저장
  • 트래픽이 일시적으로 폭주해 컨슈머 처리가 늦어지더라도, 디스크에 데이터가 있기에 손실 없이 컨슈밍 가능
  • 멀티 컨슈머도 카프카에 메시지들이 디스크로 저장되어 있기에 가능한 기능

• 확장성

  • 보통 카프카 클러스터 내 브로커는 홀수개로 지정함
  • 확장 작업은 카프카 서비스의 중단 없이 온라인 상태에서 작업 가능
  • 최초 카프카 클러스터 구성 시 적은 수로 시작하더라도, 이후 트래픽 및 사용량 증가로 확장하는 작업이 간단

• 높은 성능

  • 내부적으로 분산 처리, 배치 처리 등 다양한 기법 사용

카프카 용어 정리

• 카프카 : 카프카 클러스터를 의미함
• 브로커 : 카프카 애플리케이션이 설치되어 있는 서버 또는 노드를 의미
• 토픽 : 프로듀서와 컨슈머들이 카프카로 보낸 자신들의 메시지를 구분하기 위한 네임으로 사용, 많은 수의 프로듀서, 컨슈머들이 동일한 카프카를 이용하게 된다면, 메시지들이 서로 뒤섞여 원하는 메시지를 얻기 어렵기에, 토픽이라는 이름으로 구분하여 사용
• 파티션 : 병렬처리가 가능하도록 토픽을 나눌 수 있고, 많은 양의 메시지 처리를 위해 파티션의 수를 늘릴 수 있다.
• 프로듀서 : 메시지를 생산하여 브로커의 토픽 이름으로 보내는 서버 또는 애플리케이션
• 컨슈머 : 브로커의 토픽 이름으로 저장된 메시지를 가져가는 서버 또는 애플리케이션

그 뒤 내용은 뒤 챕터에서 자세히 설명될 예정이고, 중요하지 않은 내용으로 보여 생략