Chapter 01. 카프카 개요

DevSprout / Practice-Kafka-Dev-To-Production

✉️ 실전 카프카 개발부터 운영까지 스터디

3 stars 0 forks source link

도입사례

유럽 전역 최대 온라인 패션몰 잘란도(Zalando)

규모가 점점 커지자 내부적으로 데이터를 다루는 데에 온갖 요구사항이 생김

요구사항을 근본적으로 해결하기 위해 컨슈머 방향으로 전달되는 이벤트 드리븐(Event-driven) 시스템으로 전환을 결정

컨슈머들은 자신의 요구사항에 따라 데이터를 처리하거나 구독할 수 있게됨

하지만, 인바운드 데이터와 아웃바운드 데이터가 동일해야함. 데이터를 컨슈밍할 때 데이터가 불일치하거나 누락되면 신뢰성을 잃게됨 ⇒ 이를 위해서 데이터 검증작업이 추가로 이루어지게하였는데, 검증에 대한 피로도를 가중시킴

해결방안으로 API와 PostgreSQL을 연결하는 CRUD 구성 후 DB 업데이트 완료 후 이벤트를 발생시키도록 구성

데이터 오차는 없었지만 동기화 방식에서 문제가 발생
여러 네트워크를 이용하는 환경에서는 데이터 변경이 동기화가 어려움
데이터를 동시에 수정하면서 정확하게 순서를 보장하기 어려움
클라이언트 요구사항을 효율적으로 지원하기 어려움
대량의 배치 전송을 위한 클라이언트를 지원하기 어려움

위 문제점들을 해결하고자 비동기 방식의 대표 스트리밍 플랫폼, 카프카를 도입

빠른 데이터 수집이 가능한 처리량(Throughput)
이벤트 처리 순서 보장
적어도 한 번(at least once) 전송 방식
자연스러운 백프레셔 핸들링 - pull 방식
강력한 파티셔닝
로그 컴팩션

트위터 또한 처음에는 카프카를 사용했으나 기능 부족으로 인해 인하우스 메시지 시스템을 구축함

하지만, 시간이 지나면서 카프카가 충분히 견고하고 성숙해지자 트위터가 다시 카프카를 사용함

비용 절감 효과가 있음 (자체 메시지 시스템보다 성능이 좋음)
강력한 커뮤니티

카프카 주요 특징

높은 처리량(Throughput)과 낮은 지연시간(Latency)

다른 메시지 시스템들과 비교했을 때 높은 처리량 + 적당히 빠른 지연시간

높은 확장성 - 확장이 쉬움

고가용성 - 리플리케이션을 통해 지연없는 메시지 처리 가능

내구성 - 메시지 acknowledge를 추가해서 모든 메시지가 제대로 전송 및 저장되는지 보장

개발편의성 - 프로듀서와 컨슈머가 완벽하게 분리되어 동작 (의존성 X)

운영 및 관리 편의성

요약

Kafka는 링크드인에서 근무하던 제이 크렙스, 준 라오, 네하 나크헤데가 링크드인 내부 이슈들을 해결하기 위해 2010년에 개발
- 데이터 파이프라인 확장의 어려움
- 이기종 간의 호환성
- 고성능 기반의 실시간 데이터 처리의 어려움
- 등
2011년에 Apache 오픈소스로 공개
2014년에 Confluent를 설립함
- 이후로 굳건히 이벤트 스트리밍 플랫폼으로서 자리를 굳힘
- 굉장히 안정적인 애플리케이션
- 크고 작은 신기능들이 발 빠르게 추가
본 챕터에서는 잘란도와 트위터에서 카프카를 도입한 사례에 대해 다룬다
잘란도
- 회사의 규모가 커지고 사업도 다각화되면서 내부적으로도 데이터에 대한 온갖 요구사항(?)이 불거짐
- (대략 A부서에서는 a,b,c 데이터를 달라고 하고, B부서에서는 d,e,f 데이터를 달라고 하고,... 이런 느낌인가..?)
- 이벤트 드리븐으로 해결하고자 함
  - 느슨한 결합
- 이벤트 드리븐을 도입하면서 고려해야했던 것들
- 인바운드 데이터와 아웃바운드 데이터가 일치하는가
- 변경 순서를 정확하게 보장해줄 수 있는가
- 이벤트 전달이 효율적으로 이루어지는가
- Apache Kafka를 도입한 이유
- 높은 처리량 - 한 자리수 ms 만에 전송 - 메시지 압축, 페이지 캐시, 배치 전송, readahead 등 이용
- 순서 보장 - Partition 이용
- At Least Once 전송 방식 - Producer - Acks 이용
- 강력한 파티셔닝 (수평 확장, 병렬처리)
- 자연스러운 백프레셔 핸들링
- 로그 컴팩션 - 스냅샷, 효율적인 저장공간 운영
트위터
- 처음엔 Kafka 0.7 버전 사용하다가, Event Bus로 전환했음
- 많은 I/O 오퍼레이션에서의 문제 발생
- 내구성 문제
- 리플리케이션 미구현
- 나중에 다시 Apache Kafka로 전환
- 빠른 응답속도
- 높은 처리량 -> 하드웨어 감축, 60~70% 리소스 절감 효과
  - Event Bus
  - blocking fsync()
  - Apache Kafka
  - non-blocking fsync()
  - zero-copy
- 강력한 커뮤니티
  - 사실상 실시간 메시징 시스템의 업계 표준
  - 다양한 오류 보고 / 해결법
  - 개발자 채용 용이
- Exactly Once 전송 방식 - Producer - Acks, Transaction 이용, Consumer - isolation.level 이용
- Pub/Sub 모델 -> 수평 확장 용이, 느슨한 결합
- 고가용성 - Replication 이용, 기존 메시징 시스템과 달리 log를 디스크에 저장
넷플릭스 - 데이터 파이프라인
우버 - 데이터 통합

1,2장 요약

이벤트 드리븐에 대해서 잘 몰랐는데, 1챕터를 읽으면서 감을 잡을 수 있었다.

이벤트 드리븐에서 중요한 부분은 순서 보장과 인바운드 데이터와 아웃바운드 데이터의 일치!

인바운드 데이터와 아웃바운드 데이터의 일치는 결국, 다른 부서에서 사용할 데이터도 일관성 있게 전송되어야한다는 것을 의미하는 것 같다.

또한 API를 기반으로 발생하는 이벤트들의 순서가 제대로 보장되어야하는데 여기에 대한 부분도 카프카로 해결할 수 있다고 한다.

카프카는 아래와 같은 것들을 할 수 있다.

순서 보장
적어도 한 번 전송 보장 (at least once)
자연스러운 백프레셔 핸들링 ( 클라이언트가 pull 방식으로 동작하므로, 프로듀서가 메시지를 얼마를 쓰는지와 관계 없이 클라이언트는 자기만의 속도로 요청 처리가 가능하다. )
강력한 파티셔닝
로그 컴팩션, 프로듀서와 컨슈머의 완벽한 분리 + 비동기 방식으로 인한 병목현상 파악 용이, 모니터링을 위한 매트릭의 제공

카프카의 컨슈머 동작 방식

원글

카프카의 컨슈머는 max.poll.records 값 만큼 레코드를 읽어간다. ( polling 방식임 )

이걸 매 번 브로커에 요청하지 않고, 큐에서 가져간다.

큐에는 max.partition.fetch.bytes 만큼 저장이 되어있음.

만약 큐가 비어있다면? 브로커에 요청한다.

max.poll.interval.ms동안 poll 응답이 없으면 컨슈머 코디네이터에서 해당 컨슈머를 그룹에서 제거한다. ( 그리고 해당 파티션은 리밸런싱이 일어난다 )

https://github.com/apache/kafka/blob/b7f20be809c47202ace4b54e69be5428012df1a9/clients/src/main/java/org/apache/kafka/clients/consumer/internals/ConsumerCoordinator.java#L508

DevSprout / Practice-Kafka-Dev-To-Production