코딩마을방범대
아파치 카프카(Apache Kafka) 본문
우선 메시지 큐와 관련된 용어들을 함께 알아본 뒤에 카프카에 대해 알아볼 것이다!
메시지 지향 미들웨어(MOM; Message Oriented Middleware)
- 응용 소프트웨어 간의 비동기적 데이터 통신을 위한 소프트웨어
- 메시지 백업 기능을 유지함으로써 지속성을 제공하여 네트워크 연결을 유지할 필요가 없음(보관)
- 미들웨어 계층 자신이 직접 메시지 라우팅을 수행하기 때문에, 하나의 메시지를 여러 수신자에게 배포가 가능함(라우팅)
- 송수신 측 요구에 따라 전달하는 메시지를 변환할 수 있음(변환)
메시지 브로커와 이벤트 브로커
메시지 브로커(Message Broker)
- Producer 가 생산한 메세지를 메세지 큐에 저장하고, 저장된 메세지를 Consumer가 가져갈 수 있도록 함
- Consumer 가 메세지 큐에서 데이터를 가져가게 되면 짧은 시간 내에 메세지 큐에서 삭제되는 특징이 있음
이벤트 브로커(Event Broker)
- 이벤트 브로커는 메시지 브로커의 역할을 할 수 있지만, 메시지 브로커는 이벤트 브로커 기능을 하지 못함
- 메시지 브로커와 다르게 Consumer 가 소비한 데이터를 필요한 경우 다시 소비할 수 있음
메시지 큐(Message Queue, MQ)
- 메시지 지향 미들웨어(MOM : Message Oriented Middleware)를 구현한 시스템
- 프로그램(프로세스) 간의 비동기적 데이터 통신을 위한 기술
| 용어 | 설명 |
| Producer | 정보를 제공하는 자 |
| Consumer | 정보를 제공받아서 사용하려는 자 |
| Queue | Producer의 데이터를 임시 저장 및 Consumer에 제공하는 곳 |
단점
- 도구들이 아직 개발 중
- Message 수정을 위한 비용이 필요함
- topic selection에 제한적임
- 압축/압축 해제에서 성능 저하 발생
장점
- 비동기: 임시 저장소(queue)가 있기 때문에 작업 보류 가능
- 낮은 결합도: 애플리케이션과 분리 가능
- 확장성: 다수의 프로세스들이 큐에 메시지를 보낼 수 있음
- 탄력성: consumer 서비스가 다운되더라도 애플리케이션이 중단되지 않고 메시지가 지속적으로 MQ에 남아있음
- 보장성: MQ에 들어간다면 메시지가 consumer 서비스에게 전달된다는 보장을 제공
- 과잉: 실패할 경우 재실행 가능
1. 비동기 (Asynchronous)
메시지 큐가 없을 경우 Producer는 Consumer에게 직접 메시지를 발송해야 한다. (End-To-End 통신)
이 때문에 해당 과정이 완료되기 전까지는 다른 메세지 전달 과정이 이루어지지 못한다.
이럴 경우 동기(Synchronous) 방식을 사용하게 되는데, 전송속도가 빠르고 전송 결과를 신속하게 알 수 있는 장점이 있는 반면에, 대용량 트래픽이 발생하는 서버에서 이러한 방식은 매우 비효율적이다.
이를 해결하기 위해 메세지큐를 중간에 배치한다면 Producer 는 메세지를 Consumer 에게 바로 보내지 않고 Queue 에 메세지를 넣어 관리하기 때문에, 비동기적으로 메시지 처리가 가능하다.
2. 낮은 결합도(Decoupling)
메세지큐를 통해 하나의 서비스를 구성하는 애플리케이션끼리의 결합도를 낮출 수 있다.
결합도가 낮을 경우 확장성,유연성,효율적인 유지 보수,장애 전파 방지 등의 장점이 있다.
3. 탄력성(Resilience)
시스템이 예기치 않은 상황 또는 장애에 대응하고 유연하게 대처할 수 있는 능력을 의미한다.
메시지큐를 통해 Producer 프로세스는 Consumer 프로세스가 다운되어 있어도 메세지를 정상적으로 발행할 수 있고,
Consumer 는 Producer 프로세스가 다운되어 있어도 정상적으로 수신할 수 있다.
4. 과잉(Redundancy)
작업을 메세지로 메세지 큐에 넣어두면 일정 장애 기간동안 송신된 메세지는 큐에 남아있어 추후 장애 복구 시 정상적으로 재시도 및 복구가 가능하다.
5. 신뢰성(Guarantees)
송신된 메세지의 안전하고 확실한 전달을 의미한다.
6. 확장성(Scalable)
기존 메시지 큐를 이용한 통신에서 부하가 증가하거나 클라이언트의 동시다발적인 요청이 증가할 때,
메세지 큐에 Producer 와 Consumer 을 추가함으로 비교적 간단하고 쉽게 확장을 할 수 있다.
카프카(Kafka)
- 파이프라인, 스트리밍 분석, 데이터 통합 및 미션 크리티컬 애플리케이션을 위해 설계된 고성능 분산 이벤트 스트리밍 플랫폼
- Pub-Sub 모델의 메시지 큐 형태로 동작하며 분산환경에 특화되어 있음
- 데이터를 생성하는 어플리케이션과 데이터를 소비하는 어플리케이션 간의 중재자 역할을 함으로써 데이터의 전송 제어, 처리, 관리 역할을 함
Kafka의 기본 구성 Cluster요소
| 구성 요소 | 설명 |
| Cluster | 여러 대의 컴퓨터들이 연결되어 하나의 시스템처럼 동작하는 컴퓨터들의 집합 |
| Producer | - 메시지를 만들어서 카프카 클러스터에 전송 - 메시지 전송 시 Batch 처리가 가능 - key값을 지정하여 특정 파티션으로만 전송 가능 - 전송 acks값을 설정하여 효율성을 높일 수 있음 (ACKS=0 -> 매우 빠르게 전송. 파티션 리더가 받았는 지 알 수 없다. ACKS=1 -> 파티션 리더가 받았는지 확인. 기본값 ACKS=ALL -> 파티션 리더 뿐만 아니라 팔로워까지 메시지를 받았는 지 확인) |
| Consumer | - 카프카 클러스터에서 메시지를 읽어서 처리 - 한 개의 컨슈머는 여러 개의 토픽을 처리할 수 있음 - 메시지를 소비하여도 메시지를 삭제하지는 않음 (Kafka delete policy에 의해 삭제) - 한 개 파티션은 같은 컨슈머그룹의 여러 개의 컨슈머에서 연결할 수 없음 |
| Broker | - 생산자와 소비자와의 중재자 역할을 하는 역할 - Kafka Cluster 내부에 존재하며, 서버 내부에 메시지를 저장하고 관리하는 역할을 수행 |
| Topic | - 보내는 메시지를 구분하기 위한 카테고리화 - 한 개의 토픽은 한 개 이상의 파티션으로 구성됨 |
| Partition | - 분산 처리를 위해 사용됨 - 파티션 내부에서 각 메시지는 offset(고유 번호)로 구분됨 - 파티션이 많을 수록 처리량이 좋지만 장애 복구 시간이 늘어남 - 파티션이 여러개라면 Kafka 클러스터가 라운드 로빈 방식으로 분배해서 분산처리되기 때문에 순서 보장 X - 한 번 늘린 파티션은 절대 줄일 수 없기 때문에 작업 전 충분한 검토 필요(최소한의 파티션으로 운영하고 사용량에 따라 늘리는 것을 권장) |
| Offset | - 컨슈머에서 메세지를 어디까지 읽었는지 저장하는 값 - 컨슈머 그룹의 컨슈머들은 각각의 파티션에 자신이 가져간 메시지의 위치 정보(offset) 을 기록 - 컨슈머 장애 발생 후 다시 살아나도, 전에 마지막으로 읽었던 위치에서부터 다시 읽어들일 수 있음 |
컨슈머 그룹이 존재하는 이유?
consumer의 묶음을 consumer group이라고 한.
컨슈머 그룹은 하나의 topic에 대한 책임을 갖고 있다.
즉, 어떤 consumer가 down된다면, 파티션 재조정(리밸런싱)을 통해 다른 컨슈머가 해당 파티션의 sub을 맡아서 한다.
offset 정보를 그룹간에 공유하고 있기 때문에 down 되기 전 마지막으로 읽었던 메세지 위치부터 시작한다.
참고사이트
[서버] 메세지 큐(Message Queue) 을 알아보자