1. Kafka 도입 사례

Event-Driven System의 핵심

- Inbound Data와 Outbound Data가 일치해야 함

Event-Driven System을 구축하는 프레임워크 중 하나인 Kafka를 사용하는 목적은 받은 데이터를 잘 전달하는 데에 있다. 그러므로 데이터 전달 시 추가적인 변형이나 손실이 없게끔 Data가 잘 전달되어야만 한다.

Event-Driven System의 초기 도입 사례는 Kafka가 아닌 API와 PostgreSQL로 연결하는 CRUD 타입으로 구성하고, DB 업데이트 이후 아웃바운드 이벤트가 생성되도록 구성된 것이다. 이 같은 경우 다양한 문제가 발생한다.

- 여러 네트워크를 이용하는 환경에서 모든 데이터 변경에 대한 올바른 전달 보장 문제

- 동일 데이터를 동시에 수정하면서 정확히 순서를 보장하는 문제와 수정된 이벤트들을 정확한 순서대로 아웃바운드 전송하는 문제

- 다양한 클라이언트들의 요구사항을 효율적으로 지원이 어려움

- 빠른 전송을 위한 클라이언트 또는 대량의 배치 전송을 위한 클라이언트 지원에 어려움

위 방식은 동기 방식이었고, 이러한 문제들을 해결하기 위해 도입한 것이 비동기 방식, 즉 Kafka다.

Kafka는 다음의 특징을 갖는다

• 높은 처리량
  • Http 기반 전달 이벤트도 한자릿수의 ms 단위로 처리 가능
• 순서 보장
  • 엔티티 간의 유효성 검사나 동시 수정 같은 무수한 복잡성 제거로 간결한 구조 생성
• At least once 전송 방식
  • 멱등성(idempotent) : 동일 작업을 여러 번 수행하더라도 결과가 달라지지 않는다
  • 메시지 손실에 대한 걱정 없음
• 강력한 파티셔닝
  • 논리적으로 토픽을 여러 개로 나눌 . 수있음
  • 각 파티션들을 다른 파티션들과 관계없이 처리가 가능해 효과적인 수평 확장
• 자연스러운 백프레셔 핸들링
  • kafka client는 pull 방식으로 동작 : 자기 자신의 속도로 데이터를 처리할 수 있음
  • push : Broker가 보내주는 속도에 의존
  • 복잡한 피드백, 제한의 요구사항이 사라져 매우 간단하고 편리하게 클라이언트 구현 가능
• 로그 컴팩션
  • 스냅샷 역할 가능
  • 새로운 애플리케이션이 나중에 메시지를 읽어가는 방식도 전혀 문제가 되지 않음

Kafka는 데이터 처리 간소화라는 장점뿐 아니라, 기업의 성장과 방향성에도 영향을 줄 만큼 강력하며 중요한 플랫폼이다.

Twitter의 경우, 사용자가 글을 작성했을 때 그 사용자를 팔로우하는 다른 사용자들에게 메시지가 즉시 전달되어야 했다. 또한 속보를 빠르게 노출해야 하고, 관련 광고를 사용자들에게 제공해야 하며, 많은 실시간 사용 사례들을 다뤄야 한다. 이러한 상황에서 Twitter의 데이터 엔지니어링 팀은 Pub/Sub 모델을 지원하는 kafka를 도입함으로써 빠른 응답시간과 높은 처리량을 보장하는 고가용성 시스템을 구축할 수 있었다.

카프카 도입 이전 사용했던 이벤트 버스의 경우, 서빙 레이어와 스토리지 레이어가 분리되어 추가적인 홉(홉이 많아지면 데이터베이스 I/O 작업량이 증가한다)이 필요하였다. 이렇게 되면 fsync()를 하는 동안 블로킹을 하게 되어 시간이 오래 소요된다. 반면 Kafka는 하나의 프로세스에서 스토리지와 요청을 모두 처리할 수 있었기에, OS에 의존해 fsync()를 처리하고 제로 카피를 사용해 이벤트 버스에 비해 하드웨어 사용량을 줄일 수 있었다.

이와같이 Kafka는 빠른 응답시간과 높은 처리량을 바탕으로 실시간 메시징 시스템의 업계 표준으로 자리매김 하였다.

Kafka의 주요 특징

1. 높은 처리량과 낮은 지연시간

Bookeeper 기반 스토리지 이용 펄사 메시징 시스템, RabbitMQ 시스템에 비해 높은 처리량을 바탕으로 낮은 지연시간까지 제공한다.

2. 높은 확장성

Kafka는 손쉬운 확장이 가능하도록 잘 설계된 애플리케이션이다.

3. 고가용성

2013년 클러스터 내 리플리케이션 기능을 추가하면서 고가용성이 확보되었는데, 카프카는 고가용성을 갖추면서도 지연없는 빠른 메시지 처리 기능을 유지한다.

4. 내구성 강화 용이

프로듀서는 카프카로 메시지 전송 시 프로듀서의 acks 옵션을 조정하여 메시지의 내구성을 강화한다. 강력한 메시지의 내구성을 원한다면 acks=all로 사용할 수 있으며(이렇게 할 경우 카프카로 전송되는 모든 메시지는 안전한 저장소인 카프카의 로컬 디스크에 저장된다). 전통적인 메시징 시스템의 경우 Queue 기반이어서, 컨슈머가 메시지를 가져감과 동시에 저장소에서 메시지가 삭제되곤 하였다. 반면 Kafka는 컨슈머가 메시지를 가져가더라도 메시지는 삭제되지 않고 지정된 설정 시간 또는 로그의 크기만큼 로컬 디스크에 보관되어, 코드 버그나 장애가 발생하더라도 과거의 메시지들을 불러와 재처리가 가능하다. 

메시지 또한 브로커 두 세 대에 걸쳐 저장되기 때문에, 브로커 한 대가 종료되더라도 다른 브로커의 로컬 디스크에 저장된 내용을 바탕으로 복구할 수 있었다.

5. 개발 편의성

카프카는 메시지 전송 역할을 하는 프로듀서와 메시지를 가져오는 역할을 하는 컨슈머가 완벽하게 분리되어 동작하고 서로 영향을 주지도, 받지도 않는다. 이러한 구성에 따라 프로듀싱을 원하는 개발자는 프로듀서만 개발하면 되고 컨슈밍을 원하는 개발자는 컨슈머만 개발해 사용하면 된다. 프로듀서와 컨슈머를 동시에 사용할 때는 워크로드 또는 구현하고자 하는 요구사항에 따라 프로듀서와 컨슈머에서 제공하는 옵션을 잘 활용해야 한다.

스터디 활동 중에서 문제가 Upbit API를 소켓을 받아 Spark로 정제해서 DB로 적재하는 프로세스를 구현하고 있는데, 지금 소켓과 pyspark(웹소켓 통신 프로토콜 지원하지 않음)의 통신 프로토콜 요구 사항이 달라 문제가 있는데, 사이에 Kafka를 집어넣으려는 시도를 하고 있다.

프로듀서와 컨슈머의 내부 동작을 잘 이해하고 사용한다면 옵션 활용, 트러블슈팅 및 장애 대응에도 대비할 수 있다.

6. 운영 및 관리 편의성