[Kafka - step 2] 카프카란? (What is Kafka?) (redis / pub-sub)

분산 시스템/Kafka

[Kafka - step 2] 카프카란? (What is Kafka?) (redis / pub-sub)

quokkalover 2022. 4. 3. 23:37

현재 카프카 정리 시리즈를 포스팅 하고 있다. 카프카 정리 시리즈에서 다루는 여러가지 주제가 궁금할 경우 본 글을 참고하길 바란다.

본 시리즈는 아파치 카프카 시리즈의 첫 번째 글로, 카프카가 무엇인지에 대해 간략하게 소개한다.

카프카란?

대용량, 대규모 메시지 데이터를 빠르게 처리하도록 개발된 분산 메시징 플랫폼이다.

기술적으로 표현하면 비동기 처리를 위한 메시징 큐의 한 종류이며, 프로듀서와 컨슈머가 있다.

비동기라는 단어에서 겁먹지 말고 우리가 흔히 사용하는 메일의 예시로 비동기 메시징 큐의 의미를 한번 이해해보자.

Mail : 비동기 메시징

우리가 일상적으로 사용하는 메일에서 보내는 사람은 받는 사람이 언제 메일을 받을지 모르는 상태에서도 메일 서버로 메시지(메일)를 보낼 수 있다. 보낸 메시지는 메일 서버에 저장되어 있고, 받는 사람은 자기가 원하는 시간에 언제든지 메일을 볼 수 있다.

Kafka : 비동기 메시징 큐

카프카도 이와 비슷하다. 프로듀서(메일을 보내는 사람)은 카프카(메일 서버)로 메시지를 보내게 되고, 해당 메시지는 카프카(메일 서버)에 저장되어 보관된다. 그리고 컨슈머(메일을 읽는 사람)은 저장되어 있는 메시지를 필요로할 때 가져갈 수 있다.

이처럼 Kafka는 위와 같은 비동기 처리 메시징 큐를 기반으로 동작하는 분산 스트리밍 플랫폼이다. 오픈소스로 개발됐으며, 링크드인에서 개발해 2011년 초 오픈소스로 공개되었다.

Kafka를 쓰는 이유

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

카프카는 매우 높은 처리량과 낮은 지연시간을 자랑한다.
다른 메시징 시스템들과 비교했을때, RabbitMQ가 응답 속도 면에서 가장 빠르고, 처리량이 가장 높은 것은 카프카지만, 처리량과 응답속도를 같이 비교했을 때는 카프카가 독보적이다.
카프카는 높은 처리량을 바탕으로 다양한 기업들의 요구사항을 만족시켜줄 뿐만 아니라 낮은 지연시간까지 제공한다.

높은 확장성

카프카는 손쉬운 확장이 가능하도록 잘 설계된 애플리케이션이다.
만약 기업의 비즈니스가 급속도로 성장하는 동중에 중앙 데이터 파이프라인을 담당하는 시스템의 성능 한계로 인해 더 이상 확장할 수 없다면, 이는 비즈니스의 성공을 가로막는 걸림돌이 된다.
카프카는 이러한 기업들의 요구사항들을 충족시켜줄 수 있도록 손쉽게 확장 가능하도록 설계되어 있다.

고가용성

카프카는 클러스터 내 리플리케이션 기능을 추가했고, 이를 통해 카프카 클러스터의 고가용성이 확보됐다.
카프카는 고가용성을 갖추면서도 매우 복잡한 리플리케이션 로직을 처리하는데도 불구하고 지연 없는 빠른 메시지 처리 기능을 유지하고자 한다.

내구성

카프카로 메시지를 전송할 때 프로듀서의 acks라는 옵션을 조정하여 메시지의 내구성을 강화할 수 있다. 카프카로 전송되는 모든 메시지는 안전한 저장소인 카프카의 로컬 디스크에 저장된다. 전통적인 메시징 시스템은 컨슈머가 메시지를 가져감과 동시에 저장소에서 메시지가 삭제된다. 반면 카프카는 컨슈머가 메시지를 가져가더라도 메시지는 삭제되지 않고 지정된 설정 시간 또는 로그의 크기만큼 로컬 디스크에 보관된다. 따라서 코드의 버그나 장애가 발생하더라도 과거의 메시지들을 불러와 재처리 할 수 있다.

개발 편의성

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

운영 및 관리 편의성

카프카는 중앙 메인 데이터 파이프라인 역할을 한다. 카프카는 한 시스템에서 중요한 역할을 하는 어플리케이션인 만큼 성능 확장을 위한 증설 작업이 쉽고 간단하고, 최신 버전이 릴리즈되는 경우 무중단으로 버전 업그레이드도 가능해야 하며, 버전 업그레이드 작업 역시 단순해지고 있다.
Kafka는 분산 시스템에서 동작하기 때문에 파이프라인 내 서버가 장애로 인해 종료됐다 하더라도 바로 복구시키기 때문에 안정성을 제공한다.

Kafka의 메시징 시스템 : pub - sub

Life back in 2010 : Point to Point Pipelines

기존 데이터 처리 시스템은 위 사진처럼 데이터를 보내는 센더와 데이터를 받아 처리하는 리시버와의 관계가 Point to Point 구조여서, 서비스의 규모가(특히 MSA) 커짐에 따라 센더 / 리시버들이 점점 증가하면서 복잡도가 증가했다.
이로 인해 파이프라인 관리가 어렵고, 데이터 연동의 복잡성이 증가했다
- 배포 / 장애대응 어려워짐
- 데이터 포맷의 변경사항이 생길 때마다 모든 서비스를 일일히 변경해주어야 함.
유지 보수 측면 뿐만 아니라 성능에도 치명적이게 되면서, 통합된 전송 영역이 필요해졌다.

After Kakfa : Publish - Subscribe Pipelines

Point to Point Pipeline의 문제를 극복하기 위해 링크드인에서는 카프카를 다음과 같은 목표를 가지고 새로운 시스템을 개발했다.

pub - sub 모델 : 프로듀서와 컨슈머의 분리
- 메시징 시스템과 같이 영구 메시지 데이터를 여러 컨슈머에게 허용
높은 처리량과 낮은 지연 시간
높은 확장성 (Scalability)
고가용성

쉽게 말해서 고가용성을 갖추면서도 지연 없는 빠른 메시지 처리 기능을 유지하고자 하는 등 위 목표를 최대한 모두 달성하기 위해 개발된 시스템이다.

따라서 카프카는 위와 같은 강력한 특성들을 적용함으로써 모든 이벤트 / 데이터의 흐름을 중앙에서 관리하하는 실시간 데이터 플랫폼 또는 이벤트 스트리밍 플랫폼이며, 분야를 막론하고 카프카 덕분에 서비스 아키텍처가 기존에 비해 관리하기가 심플해졌다.

또한 모든 서비스와 시스템 별로 Kafka 클러스터를 준비하지 않고, 하나의 클러스터를 사용하여 엔지니어링 자원을 전부 클러스터에 집중시켜서 클러스터의 신뢰성과 성능을 극대화하는 전략을 취할 수 있다.

Pub / Sub 모델이란?

Kafka는 publisher와 subscriber로 이루어진 비동기 메시징 전송 방식이다.

메시지라고 불리는 데이터 단위를 publisher(producer)에서 보내고 (수신처 ID 포함)
- 메시지를 일방적으로 보내는 입장이라 producer
특정 채널(kafka topic)에 메시지를 저장하면
subscriber(consumer)가 데이터를 수신한다.
- 메시지를 일방적으로 읽는 구독자는 consumer

뒤에 Kafka 구성요소에서 producer, consumer, 토픽이 무엇인지에 대해 더 상세히 다루도록 하겠다.

쉽게 말해서 발신자는 수신자가 정해져 있지 않은 상태로 메시지를 발행(Publish)하고, 구독을 신청한 수신자만이 정해진 메시지를 받는다.

즉 메시지를 1명의 사용자만 받는게 아니라 구독한 많은 메시지를 받을 수 있다.
컨슈머는 자신의 처리 능력만큼의 메시지만 broker로부터 가져오기 때문(pull 방식)에 최적의 성능을 낼 수 있다.

Kafka의 pub/sub 모델 장단점

Kafka의 장단점이 아닌 pub / sub 기준에서의 장단점임

장점

특정 개체가 수신 불능 되더라도 Kafka만 살아있다면 메시지가 유실되지 않음
Kafka로 연결되어 있기 때문에 확장성이 용이

단점

직접 통신하지 않기 때문에 메시지가 잘 전달되었는지 파악하기 힘듬 (이것도 이젠 어느정도 가능)
중간에 메시징 시스템을 거치기 때문에 매시지 전달 속도가 감소

Redis의 pub/sub 모델과의 비교

Kafka외에 대표적으로 pub/sub모델을 사용하는 예가 Redis다. Redis는 publisher가 channel에 메시지를 보내고 각 subscriber가 channel을 구독하는데, Redis의 모델과 Kafka의 모델의 차이는 Channel에 이벤트를 저장하지 않는다는 점이다. 만일 Channel에서 이벤트가 도착했을 때 채널의 Subscriber가 존재하지 않는다면, 이벤트는 사라진다.

Kafka와 Redis의 Pub / Sub Model을 간단하게 TV 예시로 비교해보자.

Redis의 채널 : 라이브 방송은 해당 채널을 시청 중 일때만 볼 수 있다.
Kafka의 토픽(채널) : 라이브 방송으로도 볼 수 있지만, 안봤다 하면 Kafka에서 방송을 저장해두고 있다 나중에 시청할 수 있다.

물론 그렇다고 해서 무조건 Kafka가 Redis보다 우위에 있는 것은 안디다. Redis에서의 pub / sub 모델에도 기능 상 창 여러가지 기능들이 있다.

Redis : 패턴에 맞는 채널 구독
Redis : Group 개념이 없어, 모든 Subscriber가 메시지를 모두 받아야 할 때
- Kakfa는 컨슈머 그룹내 컨슈머들 중에 한 서버만 메시지를 받음. (물론 group-id를 다르게 하면 Kafka 도 비슷하게 구현은 가능)