[카프카, 데이터 플랫폼의 최강자] 1장. 카프카란 무엇인가

카프카란

• 카프카는 글로벌 SNS 기업인 LinkedIn에서 개발한 대용량, 대규모 메시지 처리 플랫폼
• 빅데이터 필수 도구
• 깃허브에서 많은 스타를 받았으며, 여러 IT 기업에서 데이터 파이프라인으로 활용 중

1.1.카프카 탄생 배경

• LinkedIn의 내부 이슈 해결하기 위해 탄생.

카프카를 이용한 링크드인의 데이터 처리 시스템
(출처: https://www.confluent.io/blog/event-streaming-platform-1/)

• 카프카 도입 이전의 단점들은 위와 같음
  • 실시간 트랜잭션(OLTP) 처리와 비동기 처리가 동시에 이뤄지고 있으며, 통홥된 전송 영역이 없어서 복잡도가 높음. 이를 위한 개선을 하려 해도 연관 시스템을 모두 확인하여 영향도를 확인해야 함.
    → 복잡하고 변경이 어렵고 장애에 취약.
  • 데이터 파이프라인 관리가 어려움. 기존에는 각 팀의 재량에 맡겨 왔으나, 통합 데이터 분석을 위한 연결을 하는 타이밍이 왔을 때는 수 많은 조정을 위한 노력이 필요해짐. 시스템 간의 데이터 치이가 발생해 데이터의 신뢰성도 훼손됨.
    → 파이프라인 간 연계가 어렵고, 데이터 신뢰성이 낮아지게됨.
• 카프카는 위 단점의 해결을 위해 제이 크랩 외 2인으로 구성된 팀에 의해 개발되어짐. 이 때 목표를 한 것은 다음과 같음.
  • 모든 시스템으로 데이터를 전송할 수 있어야 함.
  • 실시간 처리 가능
  • 확장에 용이
  • 프로듀서와 컨슈머의 분리
  • 메시징 시스템과 같이 영구 메시지 데이터를 여러 컨슈머에게 허용
  • 높은 처리량을 위한 메시지 최적화
  • 데이터 증가함에 따라 스케일 아웃이 가능한 시스템.

카프카를 이용한 링크드인의 데이터 처리 시스템
(출처: https://www.confluent.io/blog/event-streaming-platform-1/)

• 카프카 개발 후 도입한 이후에 변경된 시스템 구성은 위 사진과 같음
  • 사내에서 발생하는 모든 이벤트/데이터의 흐름을 중앙에서 카프카가 관리함.
  • Social Graph, Search, Key-Value Storage 등 기존에 서비스 하던 데이터 스토어는 그대로 서비스 되고 있으며, 그 외에 추가적으로 보안 관리, 실시간 분석, 스트림 처리를 위한 시스템이 추가되었음. 새로 추가된 시스템은 카프카가 신뢰성 높은 데이터 분석과 실시간 분석을 제공해주기 때문임.
  • 카프카를 중심으로 카프카가 제공하는 표준 포맷에 따라 여러 데이터 스토어가 통신하다보니 데이터 송수신부담이 없고 포맷별 처리 로직을 개발할 필요가 없어져 실제 중요한 비즈니스 로직에 집중할 수 있게 됨.

모든 시스템에서 사용할 수 있는 카프카의 지향점
(출처: https://www.confluent.io/blog/event-streaming-platform-1/)

• 카프카를 메시지 전달의 중앙 플랫폼을 두고 기업에서 필요한 모든 데이터 시스템 뿐만 아니라 MS, SaaS 서비스 등과 연결된 파이프라인을 만드는 것이 가능해짐.
• 카프카는 데이터 저장과 기록, 즉 쓰기(write)에 최적화된 소프트웨어 이므로 쓰기와 관련된 직업인 작가의 이름을 따서 짓게 되었음. 그 작가는 제이 크랩스가 좋아하는 작가인 프란츠 카프카(Franz Kafka).

프란츠 카프카(출처: https://ko.wikipedia.org/wiki/프란츠_카프카)

1.2. 카프카 동작과 원리

구성요소와 Pub-Sub Model

• 카프카는 메시징 시스템으로 동작
• 구성요소
  • Publisher( = Producer): 메시지 송신 측
  • Message: 데이터
  • Exchanger: 메시지를 적절한 큐에 분배하는 역할
  • Queue: 선입선출, 메시지(데이터 저장소)
  • Subscriber(= Consumer): 메시지 수신 측
• 중앙에 Messaging Server를 두고 메시지를 송/수신 하는 형태는 pub-sub model이라 함.

Pub-Sub model 특징

• publisher는 subscriber를 알 필요 없이 큐에 메시지 송신
• subscriber는 메시지 송신처를 알 필요 없이 큐에서 메시지 수신
• 이러한 특징 때문에 비동기로 메시지 송, 수신이 가능해지며 시스템 구성시 확장에 용이해짐

기존 메시지 시스템의 단점과 개선

• 성능이 떨어짐
• 메시지 교환 전달의 신뢰성 관리를 프로듀서와 컨슈머 쪽에 넘김
• 부하가 큰 교환기 기능 역시 컨슈머가 만들 수 있게
• 이를 통해 메시지 시스템 내 작업량을 줄여서 성능을 높임

카프카의 메시지 전달 순서

1. 프로듀서는 새로운 메시지를 카프카로 보냄
2. 프로듀서가 보낸 메시지는 카프카에 토픽에 도착해 저장
3. 컨슈머는 카프카 서버에 접속해 새로운 메시지를 가져감

1.3 카프카의 특징

프로듀서와 컨슈머의 분리

• PUB-SUB 모델 채택
• 시스템 구성이 단순해짐
• 확장에 용이

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

• 하나의 토픽에 여러 프로듀서와 컨슈머들이 접근 가능
• 하나의 프로듀서가 하나의 토픽에만 메시지를 보내는 것이 아니라 하나 또는 하나 이상의 토픽으로 메시지를 보냄
• 컨슈머 역시 하나 혹은 하나 이상의 토픽으로부터 메시지를 가져올 수 있음.

디스크에 메시지 저장

• 디스크에 메시지를 저장하고 유지
• 기존 여러 메시징 시스템은 메시지를 컨슈머가 읽어가면 삭제
• 대신, 카프카는 보관 주기를 두고 이를 넘어가면 삭제
• 디스크에 메시지가 저장됨에 따라 많은 트래픽으로 컨슈머의 처리가 다소 지연되더라도 손실 없이 메시지를 가져갈 수 있게 됨.

확장성

• 카프카의 브로커 서버는 서비스 중단 없이 1대부터 수십대로 쉽게 확장하는 것이 가능.

높은 성능

• 분산 처리, 배치 처리 등을 통해 고성능이 확보
• 링크드인은 1페타 바이트 이상의 데이터를 처리

(+) broker 에게 topic을 받아서 디스크에 적는다. => 굉장히 안정적이다.

disk를 쓰는데 빠른 이유 : page cache 를 이용해서 데이터를 모았다가 IO 하기 때문에