2025. 2. 16. 18:00ㆍ카테고리 없음
카프카, 왜 사용할까?
Kafka가 아닌 일반적인 형태의 네트워크 통신 - E2E 통신
End-to-End 통신은 시스템의 한쪽 끝에서 다른 쪽 끝까지 직접 데이터를 주고 받는 방식이다.
요청이 즉시 처리되므로 빠른 응답이 가능하고 구현이 비교적 간단하다는 특징이 있다.
그러나 서비스 간 강한 결합이 발생하여 시스템 확장성이 저하된다는 점, 요청이 몰리면 병목 현상이 발생할 수 있다는 단점이있다.
Kafka (Event Broker)
Pub-Sub 모델을 기반으로 비동기 메시지 큐를 활용하는 통신 방식이다.
- 비동기 방식으로, 데이터를 메시지 큐에 넣고 소비자가 나중에 가져가 처리한다.
- 브로커를 통해 간접적으로 메시지를 중간 저장소(토픽)에 보관 후 소비자가 가져간다.
- Producer와 Consumer가 독립적으로 운영될 수 있다.
위와 같은 특징으로 kafka는 종단 사이의 느슨한 결합이 가능하며, 데이터가 브로커에 저장되기 때문에 consumer에 장애가 발생해도 재처리가 가능하다. 또한 다수의 소비자가 같은 메시지를 받아 병렬 처리가 가능하다는 특징이 있다.
따라서 비동기 처리나 확장성을 고려하고자 할 때 kafka를 선택한다
메시지 큐 ( Message Queue, MQ)
메시지 지향 미들웨어 (MOM)
메세지 지향 미들웨어란 응용 소프트웨어 간의 비동기적 데이터 통신을 위한 소프트웨어이다.
즉, 비동기적 방식을 사용해서 process간의 데이터를 주고 받기 위한 시스템이다.
MOM은 메세지를 전달하는 과정에서 보관하거나 라우팅 및 변환할 수 있다는 장점을 가진다.
메세지의 백업 기능을 유지함으로써 지속성을 제공하며 이 덕분에 송수신 측은 동시에 네트워크 연결을 유지할 필요가 없다.
카프카 특징
kafka는 RabbitMQ와 같은 메시지 큐 시스템과 달리 인메모리가 아닌 디스크에 데이터를 저장한다. 이로 인해 데이터의 영속성을 가질 수 있다는 장점이 있다.
또한 Partitioning을 통해 대규모 트래픽을 분산처리 할 수 있다. Partitioning 기능의 또다른 이점으로는 데이터의 병렬처리가 가능하다는 것이다. 데이터의 병렬처리와 관련된 내용은 아래에서 다루도록 하겠다.
카프카 구조 및 동작 방식
Broker
실질적으로 데이터를 관리하는 역할. 특히나 Partition을 관리한다. Producer에게 제공받은 데이터를 토픽에 저장하고, Consumer에게 필요한 데이터를 제공한다. 데이터의 복제와 장애 조치 기능까지 수행한다.
Prodcer, Consumer은 kafka를 활용하는 별도의 웹앱이다. 그러나 Broker는 실질적으로 데이터를 분산 처리하는 실제적인 kafka 서버인것이다.
위의 그림처럼, broker는 kafka 내부 클러스터에 존재한다.
Zookeeper
카프카 형상 관리 시스템. kafka cluster의 일관성을 유지하는 역할을 수행한다.
Producer
데이터를 push 하는 서비스이다. 데이터를 push할 topic을 지정하고 데이터를 전송할 수 있다.
Consumer
broker(kafka server)가 consumer에게 데이터를 보내주는 형식이 아니다. consumer가 관심있는 topic을 지정하고, offset을 기준으로 data를 pull 해오는 구조이다. 즉, consumer가 subscribes한 topic에 대한 데이터만을 가져올 수 있는 것이다.
한 개의 컨슈머는 여러개의 topic을 지정할 수 있다.
Kafka의 데이터 병렬 처리
- 병렬 처리 : 다양한 컨슈머가 서로 다른 파티션에서 데이터를 동시에 읽을 수 있다.
- 순서 보장 : 하나의 파티션 내에서는 메시지의 순서가 보장되어, 순차적인 데이터 처리가 가능하다.
- 확장성 : 파티션을 여러 노드에 분산시켜 저장할 수 있어, 시스템의 확장성을 높일 수 있다.
Topic
- 이벤트를 분류하는 단위이다. 따라서 각각의 Producer와 Consumer는 각각의 관심사를 분리할 수 있다.
- 하나의 토픽은 여러개의 파티션을 가지고 있다. 이벤트가 토픽에 추가될 때 마다 append 형식으로 추가되며, 유니크한 offset을 할당 받아 메세지를 구분할 수 있도록 한다.
Partition
- Topic은 여러 Broker에 분산되어 저장되며, 이렇게 분산된 Topic을 partition이라고 한다.
- 파티션 내부에서 각 메세지는 offset(고유 번호)로 구분된다.
- 파티션이 많을 수록 처리량이 좋지만, 장애 복구 시간이 늘어난다.
- Topic 생성 시 partition이 갯수를 지정할 수 있다. 수정은 가능하나, 파티션의 갯수를 늘리는 것만 가능하다고 하니 점진적으로 늘려가는 것이 좋아 보인다.
Offset
- consumer에서 메시지를 어디까지 읽었는지 저장하는 값
- consumer 측에서 장애가 발생하여 다운되었다고 하더라도, 읽었던 위치에서 다시 읽어들일 수 있다.