카프카 개요

1.도입사례

---

질란도

1. 도입배경
회사의 규모가 커지며 다양한 데이터 요구사항을 근본적으로 해결하기 위해 이벤트 드리븐 시스템으로의 전환 결정.

2. 동기 방식의 문제점
1) 모든 데이터 변경에 대한 올바른 전달 보장 문제
2) 동일한 데이터를 동시에 수정하면서 순서를 보장 해야하는 문제, 수정된 이벤트들을 순서대로 전송하는 문제
3) 다양한 클라이언트의 요구사항을 효율적으로 지원하기 어려운 문제
4) 빠른전송 또는 대량의 배치 전송을 위한 클라이언트를 지원하기 어려운 문제

이러한 문제들로 인해 비동기 방식의 대표 스트리밍 플랫폼인 카프카를 도입하게 된다.

3. 카프카 도입
- 동기 방식의 문제점 해결 방안
- 높은 처리량, 순서 보장, 적어도 한 번 전송, 강력한 파티셔닝, 자연스러운 백프레셔 핸들링, 로그 컴팩션의 기능

• 빠른 데이터 수집이 가능한 높은 처리량
• 순서 보장
  순서가 보장됨으로써 유효성 및 동시 수정같은 무수한 복작성등이 제거
• 적어도 한 번 전송방식
  누락없는 메세지 전송 가능, 중복 메세지는 멱등하게 처리하여 복잡한 트랙잭션 처리가 필요하지 않도록 한다.
• 자연스러운 백프레셔 핸들링
  카프카 클라이컨트는 풀(pull) 방식으로 동작
  풀 방식의 장점은 클라이언트의 속도로 데이터를 처리할 수 있다
  반 면 푸시(push) 방식은 브로커가 보내주는 속도에 의존해야 하는 한계가 있다
  카프카 클라이언트는 풀 방식으로 동작하여, 복잡한 피드백이나 요구사항이 사라져 간단하고 편리하게 구현가능하다
• 강력한 파티셔닝
  논리적으로 토픽을 여러개로 나눌 수 있다
  효과적인 수평확장 가능
• 그 외 여러가지 기능
  로그 컴팩션을 통해 스냅샷 역할 가능
  모니터링을 통해 문제 해결
  비동기 방식을 통해 병목현상 파악

---

트위터

1. 도입배경
이벤트버스와 카프카의 워크로드(안정적인 쓰기, 마지막 읽기, 따라잡기 읽기)와 일부 장애 시나리오 성틍테스트의 결과 카프카의 응답속도가 빠르기에 재도입 결정

2. 카프카 vs 이벤트버스

	카프카	이벤트 버스
BPS증가에 따른지연	거의 발생하지 않음	비례 하여 지연
처리방법	하나의 프로세스에서 스토리지와 요청을 모두 처리	서빙 레이어와 스토리지 레이어가 분리되어있어 추가적인 홉이 필요
fsync() 처리	OS에 의존해 백그라운드로 처리 및 제로카피 사용	fsync()를 하는 동안 블로킹
하드웨어 필요치	상대적으로 적은 하드웨어 필요	많은 하드웨어 필요