위 그림처럼 애플리케이션 끼리 연결하는 파이프라인 개수가 많아지면서 복잡도가 올라가고 코드 및 버전 관리 등의 이슈가 발생하게 됩니다. 시간이 지나면서 파편화된 데이터 파이프 라인은 서비스를 운영하는데 치명적일 것이기 때문에 이를 개선하기 위해서 등장하게 됩니다.
쉽게 말해서 아래 그림처럼 만들려고 탄생한게 카프카죠.
카프카의 용도
- 메세지 처리
- 사용자의 웹 사이트 활동 추적 파이프라인
- 애플리케이션의 통계 집계
- 시간순으로 발생하는 이벤트를 저장해 필요한 곳으로 보냄
카프카의 동작 방식과 원리
- 기본적으로 메시징 서버로 동작
- 메세징 시스템
- Producer, publisher : 데이터 단위를 보내는 부분
- Consumer, subscriber : 토픽이라는 메시지 저장소에 저장된 데이터를 가져가는 부분
- 중앙에 메세지 시스템 서버를 두고 메세지를 보내고(publish) 받는(subscribe) 형태의 통신을 펍/섭(Pub/Sub) 모델이라고 합니다
- 펍/섭(Pub/Sub)
- 발신자의 메세지엔 수신자가 정해져있지 않은 상태로 발행(publish)
- 구독(subscribe)을 신청한 수신자만 메세지를 받을 수 있음
- 일반적인 형태의 통신은 통신에 참여하는 개체끼리 모두 연결해야해서 확장성이 좋지 않습니다
- 펍섭은 확장성 Good, 데이터 유실 확률이 적음
- 그러나 메세징 시스템이 중간에 있어서 전달 속도가 빠르지 않음
- 전화기의 교환대의 원리와 살짝 유사한 느낌
우버에서 카프카를 아래와 같이 사용하고 있습니다.
제가 이 부분에서 궁금했던 것은 카프카가 RabbitMQ 또는 AWS SQS을 사용하는 것과 다른 점이 무엇이지 였습니다.
RabbitMQ
- 구성이 쉽다.
- 유연한 라우팅이 가능하면 관리 UI 가 편리하다.
- 제품 성숙도가 높다.
- 개방형 프로토콜을 위한 AMQP 를 구현 위해 개발
- 필요에 따라 동기/비동기식이 가능함
- 소비자중심의 설계
- 20k/sec 처리를 보장
Apache Kafka
- 구독방식의 비동기식 구성
- 고성능 고가용성
- 분산처리에 효과적으로 설계 됨.
- 생산자 중심의 설계
- 범용 메세징 시스템에서 제공되는 다양한 기능은 제공되지 않음.
- 100k/sec 처리를 보장
성능과 분산 처리를 위한 설계 등 대용량 트래픽이 발생한다면 카프카를 사용해야한다.
만약 분산을 할 정도가 아닌 경우 구성이 쉬운 RabbitMQ가 합리적인 선택일 수 있다는 이야기이다.
AWS SQS( Simple Queue Service)는
"확장성이 우수하고 사용하기 쉬우며 메시지 브로커를 설정할 필요가 없는 대기열 및 주제 서비스입니다. 이러한 서비스는 무제한에 가까운 확장성과 간편한 API를 활용할 수 있는 새로운 애플리케이션에 사용하면 좋습니다." 라고 AWS에서 설명하는데
간단히 하면 진짜 간단한 큐 서비스로 브로커 설정할 필요 없지 메시지를 생성하고 소비하는 것만 제공합니다.
그래서 간단한 대기열 서비스만 필요로 하는 것을 구축하려는 경우 이 서비스에 매우 적합하다고 합니다.
조금더 나아가 보면 (정보조사와 개인적인 생각을 짬뽕한 부분이라 한귀로 듣고 흘려주시면.....)
우아한 tech의 [우아콘2020] 배달의민족 마이크로서비스 여행기 영상을 보면 배민 시스템에서 AWS SNS + AWS SQS를 사용하고 있습니다.
여기서 드는 궁금증은
1. AWS SNS?
2. AWS SQS를 선택 한 이유
1
AWS 에서는
"게시자에서 구독자에게 메시지 전송을 제공하는 관리형 서비스입니다.생산자및소비자). 게시자는 구독자와 비동기적으로 통신하는topic이는 논리적 액세스 및 통신 채널입니다. 클라이언트는 SNS 주제를 구독하고 Amazon Kinesis Data Firehose SQS, AWS Lambda, HTTP, 이메일, 모바일 푸시 알림 및 SMS (모바일 문자 메시지) 와 같은 지원되는 엔드포인트 유형을 사용하여 게시된 메시지를 수신할 수 있습니다." 라고 하는데 결국 메시지를 구독서비스들에게 한꺼번에 메시지를 보내기 위한 서비스라고 이해하였습니다.
이를 통해서 구독자를 추가하거나 제거하는 부분을 AWS 콘솔에서 제어가능해서 코드로 제어하는 것보다 편하지않을까 생각하였습니다.
2
영상 후반부 내용을 바탕으로 궁예(예상)가 되어보자면
배민에서는 AWS 서비스 사용을 적극 권장하기 때문에 AWS 서비스간 연결하기 쉽다는 점과
ZERO-PAYLOAD 방식으로 최소한의 정보(ID 등)를 보내고 구독 서비스에서 API를 호출하여 정보를 가져오는 방식이었기 때문에 간단한 큐만 필요했기 때문이 아닐까 라고 생각하였습니다.
Reference
'Kafka' 카테고리의 다른 글
| 2. 실습용 카프카 브로커 설치 (0) | 2021.05.20 |
|---|---|
| Kafka 공부 시작 (0) | 2021.05.20 |