Kafka.00 카프카 개요 본문
카프카? 그게 뭔데!
카프카는 실시간으로 스트리밍 데이터를 처리하는데 최적화된 분산 데이터 스토어입니다.
즉, 연속적으로 생성되는 수 많은 데이터(스트리밍 데이터) 를 효과적으로 처리하는데 특화되어 있습니다.
스트리밍 데이터? 그거 API로 계속 쏘면 되는거 아니야? 라고 생각할 수 있겠지만, 현실은 그렇지 않습니다.
대규모 서비스에서는 매초마다 수천, 수만건의 이벤트가 발생하며, 이런 데이터를 안정적으로 처리하려면 이것을 위해 설계된 특별한 아키텍처가 필요합니다.
일반적인 API 통신으로는 아래와 같은 문제를 해결하기 어렵습니다.
- 고가용성 - 서버가 다운된다면? 서버 다운을 모르고 쏜 데이터들은 유실될 것이고, DB에 들어가지 못한 데이터들은 손실될 것입니다.
- 처리 지연 - API 수신 서버의 처리 능력을 초과하는 요청이 있는 경우, 장애가 발 생 할 수 있습니다.
- 확장성 - 데이터 양이 급증하면 서버가 감당하지 못할 것 입니다. 인스턴스를 빨리 붙인다고 하더라도, 빠른 확장이 어렵습니다.
- 다중 컨슈머 - 발생한 이벤트를 다양한 서버에 전송해야 한다면? 이벤트 발생 주체는 API를 여러번 쏘아야 하는 번잡함이 있습니다.
- 순서 보장 - spring boot 기준 특수한 처리를 하지 않는 이상, 발생한 이벤트를 순서대로 받는다는 보장이 없습니다.
- 이벤트 재사용 - API 통신은 한 번 처리한 데이터를 다시 처리하기 어렵습니다.
- 처리 보장 - API 통신은 다양한 수준의 처리 보장을 제공할 수 없습니다. 즉, 데이터를 보내는 쪽과 받는 쪽의 데이터 처리 여부에 대해 결정할 수 없습니다.
일반적인 API에서 발생하는 문제를 카프카에서는 어떻게 해결할 수 있을까요?
고가용성 (High Availability)
카프카는 장애 발생 시 자동으로 복구하는 기능과 데이터를 여러 브로커에 복제하여 저장하는 분산 시스템입니다. 이를 통해 일부 서버에 장애가 발생하더라도 시스템 전체가 계속 작동하고 데이터 손실을 방지합니다.
처리 지연 문제 (Backpressure)
카프카는 컨슈머가 폴링 방식으로 자신의 처리 능력에 맞게 이벤트를 가져갈 수 있습니다. 이로 인해 컨슈머 시스템이 과부하되는 것을 방지하고, 처리 능력에 맞춰 안정적으로 데이터를 소비할 수 있습니다.
확장성 (Scalability)
카프카는 분산 시스템으로 설계되어 브로커(서버)를 쉽게 추가할 수 있습니다. 또한 파티션이라는 개념을 통해 하나의 토픽을 여러 브로커에 분산시켜 병렬 처리가 가능합니다. 데이터 양이 증가하면 브로커와 파티션 수를 늘려 선형적으로 확장할 수 있습니다.
다중 컨슈머 (Multiple Consumers)
카프카는 발행-구독(pub-sub) 모델을 지원하므로, 프로듀서는 메시지를 한 번만 카프카에 전송하면 됩니다. 여러 컨슈머 그룹이 동일한 토픽을 구독하여 같은 데이터를 독립적으로 가져가 처리할 수 있습니다. 이를 통해 하나의 이벤트를 여러 시스템에서 각자의 목적에 맞게 활용할 수 있습니다.
순서 보장 (Order Guarantee)
카프카는 파티션 내에서 메시지의 순서를 엄격하게 보장합니다. 같은 키를 가진 메시지는 항상 같은 파티션으로 라우팅되기 때문에, 특정 엔티티(사용자 ID, 주문 ID 등)와 관련된 이벤트들은 발생 순서대로 처리될 수 있습니다.
이벤트 재사용 (Event Replay)
카프카는 메시지(레코드)를 설정된 기간 동안 보관합니다. 이를 통해 필요할 때 과거 데이터를 다시 처리할 수 있어 시스템 복구나 새로운 분석 시스템 도입 시 유용합니다.
처리 보장 (Processing Guarantees)
카프카는 '적어도 한 번(at-least-once)', '최대 한 번(at-most-once)', '정확히 한 번(exactly-once)' 과 같은 다양한 수준의 처리 보장을 제공합니다. 이를 통해 비즈니스 요구사항에 맞는 메시지 전달 신뢰성을 선택할 수 있습니다.
카프카의 단순한 개요!
이렇게 좋은점만 있어 보이는 카프카.
어떻게 생겼는지 보고, 카프카에서 사용되는 단어들을 알아봅시다.
Zookeeper
카프카의 정상 동작을 보장하기 위한 메타데이터를 관리하는 코디네이터 입니다.
풀-네임은 Apache Zookeeper 이고, 원래 분산 시스템의 코디네이션 서비스로 만들어졌습니다.
다수의 노드에서 작업이 수행되는 분산 처리 어플리케이션의 경우, 단일 어플리케이션보다 고려해야 할 요소가 많겠죠??
각 노드가 살아있는지, 죽었는지, 처리가 잘 되고 있는지 등등, 이런 것 들을 관리하기 위한 분산 시스템 코디네이션 서비스 입니다.
kafka 또한 kafka cluster 내부에서 다양한 broker들이 동작하고 있는 분산 시스템이라 이것들을 관리할 수 있는 서비스로서 주키퍼를 사용하고 있습니다.
Producer
이벤트를 만들어 내는 생산자(Producer)입니다.
데이터를 만들어서 kafka에 데이터를 넣어주는 모든 것을 프로듀서 라고 지칭합니다.
토픽을 지정하여 데이터를 넣습니다. 원하는 경우 파티션도 특정하여 특정 파티션에 순서대로 데이터가 쌓이게 할 수도 있습니다.
이벤트를 Publish (발행) 하는 주체 이기도 합니다.
Consumer
이벤트를 처리하는 소비자(Consumer)입니다.
Kafka에 쌓여있는 데이터를 polling 하여 데이터를 가져가고, 처리합니다.
토픽을 지정하여 해당 토픽에 있는 데이터를 가져옵니다.
이렇게 특정 토픽에 쌓이는 이벤트를 기다리고 있다가 가져온다고 하여 구독(Subscription) 한다! 라고 합니다.
pub-sub 구조 입니다!
Kafka Cluster
카프카 브로커를 모아놓은 클러스터 입니다.
Broker
카프카를 설치한 서버이자 노드 라고 생각할 수 있습니다.
Topic
주제 입니다.
프로듀서는 이벤트를 발행할 때 특정 Topic (주제)로 이벤트를 publish 합니다.
컨슈머는 subscribe 하고 있는 Topic에 이벤트가 있으면 가져옵니다.
Partition
토픽 하나를 여러 개로 나누어 병렬 처리가 가능하게 만든 것 입니다. 이렇게 하나를 여러 개로 나누어 분산 처리도 가능하고, 나뉜 파티션 수만큼 컨슈머를 연결 할 수 있습니다.
리플리케이션을 사용하여 파티션을 다른 브로커에 복제하여 한개의 브로커가 종료되더라도 데이터 유실을 방지할 수 있습니다.
Record
파티션에 쌓이는 데이터의 단위 입니다.
Key-Value 값으로 구성됩니다.
Offset
파티션 별로 레코드가 저장되는 위치 입니다.
순차적으로 증가하는 64bit 정수입니다.
각 파티션별로 고유한 오프셋을 가지고 있으며, 오프셋을 통해 메세지의 순서를 보장하고, 컨슈머에서는 마지막으로 읽은 레코드의 위치를 알 수 있습니다.
여기까지가 간단하게 카프카를 소개하는 글 이였습니다.
데이터의 흐름으로 보자면
- 프로듀서가 A 토픽으로 데이터를 전송한다.
- A 토픽을 구독하던 컨슈머는 A 토픽를 폴링 한다.
- A 토픽에 새로운 데이터가 들어오는 경우, 컨슈머는 데이터를 가져간다!
로 보면 쉬울 것 같습니다.
reference
- 실전 카프카 개발부터 운영까지 (고승범 저)
'Backend' 카테고리의 다른 글
| Lambda@Edge를 사용한 이미지 리사이징 적용기 (0) | 2025.02.25 |
|---|---|
| Intellij 에서 Springboot 시작하기 (0) | 2023.01.15 |
