-
Notifications
You must be signed in to change notification settings - Fork 0
MicroService Message Queue(Kafka)
Message Queue 란 메시지 기반의 미들웨어로 메시지를 이용하여 여러 어플리케이션, 시스템, 서비스 들을 연결해주는 솔루션 입니다. MOM(Message Oriented Middleware) 를 구현한 솔루션으로 비동기 메시지를 사용하는 서비스들 사이에서 데이터를 교환해주는 역할을 합니다. Producer(Sender) 가 메시지를 큐에 전송하면 Consumer(Receiver) 가 처리하는 방식으로, Producer 와 Consumer 에 message 프레세스가 추가되는 것이 특징입니다. MQ 를 사용하여 비동기로 요청을 처리하고 Queue 에 저장하여 Conumer 에게 병목을 줄여줄 수 있습니다.
아파치 프로젝트 애플리케이션 이름입니다. 클러스터 구성이 가능하며, 카프카 클러스터라고 부릅니다.
카프카는 기본적으로 메시징 서버로 동작합니다. 메시지라고 불리는 데이터 단위를 보내는 측(퍼블리셔 publish 또는 프로듀서 producer 라고 함) 에서 카프카에 토픽이라는 각각의 메시지 저장소에 데이터를 저장하면, 가져가는 측(서비스크라이버 subscriber 또는 컨슈머 conumer 라고 함) 이 원하는 토픽에서 데이터를 가져가게 되어 있습니다. 중앙에 메시징 시스템 서버를 두고 이렇게 메시지를 보내고 publish 받는 subscribe 형태의 통신을 펍/섭 pub/sub 이라고 합니다.
펍/섭(pub/sub) 은 비동기 메시징 전송 방식으로서, 발신자의 메시지에는 수신자가 정해져 있지 않은 상태로 발행(상태) publish 합니다. 구독(subscribe)을 신청한 수신자 만이 정해진 메시지를 받을 수 있습니다. 또한, 수신자는 발신자 정보가 없어도 원하는 메시지만을 수신할 수 있습니다.
모니터링, 로그 분석 시스템 등이 웹, 앱, 데이터베이스, 파일 서버를 관리하면 추가 작업 및 일대일로 통신하고 있던 모니터링 서버에 문제가 생겨 응답이 늦어지는 경우가 발생하면, 연쇄작용 서버로 문제가 생기거나, 지연 등의 이슈가 발생할 수 있습니다. 펍/섭 방식인 카프카를 중앙에 놓으면 각각 서비스들의 상태들은 모니터링이나, 분석 시스템의 상태 유무와 관계없이 카프카로 메시지를 보내는 역할만 하게 되고, 마찬가지로 모니터링이나 분석 시스템들도 서비스 서버들의 상태 유무와 관계 없이 카프카에 저장되어 있는 메시지만 가지고 오면 됩니다.
- Kafka Broker : 카프카 애플리케이션이 설치되어 있는 서버 또는 노드를 말합니다.
- 브로커(Broker) : 카프카 애플리케이션이 설치되어 있는 서버 또는 노드를 말합니다.
- 토픽(Topic) : 프로듀서와 컨슈머들이 카프카로 보낸 자신들의 메시지를 구분하기 위한 네임으로 사용합니다. 많은 수의 프로듀서, 컨슈머들이 동일한 카프카를 이용하게 된다면, 메시지들이 서로 섞여 각자 원하는 메시지를 얻기가 어렵게 됩니다. 그래서 토픽이라는 이름으로 구분하여 사용하게 됩니다.
- 파티션(Partition) : 병렬 처리가 가능하도록 토픽을 나눌 수 있고, 많은 양의 메시지 처리를 위해 파티션의 수를 늘려줄 수 있습니다.
- 프로듀서(Producer) : 메시지를 생산하여 브로커의 토픽 이름으로 보내는 서버 또는 애플리케이션 등을 말합니다.
- 컨슈머(Consumer) : 브로커의 토픽 이름으로 저장된 메시지를 가져가는 서버 또는 애플리케이션 등을 말합니다.
Consumer Group 란?? 컨슈머 인스턴스들을 대표하는 그룹 Conumer Instance 란?? 하나의 프로세스 또는 하나의 서버라고 할 수 있습니다. Offset 란?? 파티션 안에 데이터 위치를 유니크한 숫자로 표시한 것을 offset 이라고, 컨슈머는 자신의 어디까지 데이터를 가져갔는지 offset 을 이용해서 관리를 합니다. https://www.popit.kr/kafka-consumer-group/
- Key
- Value
[ 카프카 핵심 가이드 - 파티션 개수의 산정 방법 ]
- 단위 시간당 토픽의 데이터 처리량(throughtput)은? 예를 들어, 초당 100KB 또는 1GB 를 예상하는가?
- 한 파티션의 데이터를 읽을 때 목표로 하는 최대 처리량은? 파티션 하나는 항상 한 컨슈머가 소비한다.(컨슈머 그룹을 사용하지 않을 때도 컨슈머는 항상 해당 파티션의 모든 메시지를 읽어야 하기 떄문이다.) 따라서 만일 처리 속도가 느린 컨슈머가 파티션을 읽어서 그 데이터를 데이터베이스에 쓸 때 데이터를 쓰는 스레드마다 초당 50MB까지만 처리할 수 있다면 파티션을 소비하는 최대 처리량이 초당 50MB 로 제한된다는 것을 알아두자
- 하나의 파티션에 데이터를 생성하는 프로듀서당 최대 처리량도 컨슈머와 같은 방법으로 산정할 수 있다. 그러나 대게 프로듀서는 컨슈머보다 훨씬 빠르게 처리되므로 처리량을 조사하지 않아도 무방하다.
- 키(Key)를 사용해서 파티션에 메시지를 쓰는 경우에는 향후에 파티션을 추가할 때 개수 산정이 어려울 수 있다. 따라서 현재보다는 향후에 예상되는 사용 방법을 기준으로 처리량을 추신하자.
- 브로커마다 파티션 개수와 디스크 용량 및 네트워크 처리 속도를 고려하자.
- 파티션 개수를 너무 많이 고려하지 말자. 왜냐하면 각 파티션은 브로커의 메모리와 그 외 다른 자원을 사용하므로 리더 선정에 더 많은 시간이 소요되기 때문이다.