카프카(Kafka)를 사용하는 이유
누구나 모놀로식 아키텍처로 개발을 해온 사람이라면 피해갈 수 없는 문제가 있다. 바로 커플링(Coupling)이다. 무수히 많은 로직들이 엉켜 결국 유지보수하는데 많은 시간을 소비해본 경험이 있을 것이다.
카프카를 이용해 DDD패턴으로 설계하면 이와 같은 문제를 해결할 수 있다.
카프카
카프카를 사용하는 주된 목적은 커플링을 줄이기위해 발신자와 수신자를 서로 의존하지 않는 상태로 서비스 아키텍처를 가져가기 위해 사용된다.
기존에는 하나의 소스 시스템에 여러 타겟 시스템이 붙어 수신해야했다. 이 때문에 타겟 시스템별 데이터 수신 차이가 발생했다. 이를 극복하기 위해 소스 시스템을 늘리면 구조가 복잡해지고 각 시스템들 사이의 데이터 포맷과 처리방식이 달라 확장 및 소비에 어려움이 있었다. 이런 문제를 깔끔하게 해결해주는 것이 바로 카프카이다.
카프카는 메시지 큐를 사용하는데 그 중에서도 Pub/Sub 방식으로 토픽이라 부르는 하나의 메시지 통로를 사용하여 메시지를 '발행' 하고 정책에 의해 구독중엔 메시지를 '소비'한다.
따라서 각각의 다른 기능들에 의존하지 않게되고 자신의 정책에 따라 필요한 메시지만 수신해 처리하고 다른 처리가 필요한 경우 다시 이벤트를 새로 발행하기만 하면된다.
카프카의 특징
- 메시지를 파일 시스템으로 저장해 메시지 유실 우려가 적다.
- 소비자가 정책에 의해 처리할 수 있는 메시지만 가져온다.
- 대량의 데이터를 높은 처리량과 낮은 지연 시간으로 처리할 수 있는 기능을 제공한다.
카프카의 구성
카프카는 필수로 주키퍼(zookeeper)와 같은 분산 애플리케이션 코디네이터가 필요하다. 카프카를 클러스터로 구성할 때 각각의 서버를 브로커(Broker)라고 하는데 이러한 코디네이터가 브로커들을 관리한다. 브로커들은 각각 토픽 파티션을 가지며 항상 3개 이상의 브로커로 운영된다.
카프카는 이벤트를 생성하는 생성자(Producer) 이벤트를 소비하는 소비자(Consumer)가 있다. 이 중 소비자(Consumer)는 여러 소비자들이 하나로 묶여 소비자 그룹(Consumer Group)을 형성한다. 이러한 소비자 그룹이 메시지를 소비할 때 Pub된 메시지를 어디까지 소비했는지에 대한 위치를 Offset이라고 한다. 만약 소비자 서버가 죽었다면 Offset을 통해 서버가 다시 살아났을때 다음 메시지를 수신할 곳을 체크할 수 있다.
카프카에서 메시지가 이동하는 통로는 Topic이라고 한다. 하나의 카프카에서 여러개의 메시지가 발행되고 소비될 때 이러한 Topic을 이용하여 원하는 메시지를 찾을 수 있다. 이러한 토픽을 분산처리하는 단위인 Partition이 있다. Partition을 이용하면 하나의 토픽에 병렬처리를 할 수 있는데 한번 Partition을 늘리면 줄일 수 없기 때문에 파티션을 늘릴때는 신중히 늘려야 한다.
또한 카프카는 Key값을 설정하지 않는다면 메시지를 라운드-로빈(Round-robin) 방식으로 Partition들에게 분배하기 때문에 순서가 보장되야 하는 메시지는 꼭 Key값을 지정해 주어야 한다.
Partition 0, Partition1 이 있다고 가정해보자 주문 이벤트가 발생한 후 주문 취소 이벤트가 발생했다. 만약 Key값을 지정하지 않는다면 두 이벤트가 다른 Partition으로 들어가 처리 순서가 뒤바뀔 수 있다. 즉, 주문 취소가 먼저 처리될 수 있다는 뜻이다.
카프카 스케일링
카프카를 스케일링할 때 권고사항은 다음과 같다.
1. 모든 브로커 리소스 사용률이 현저히 높으면 새로운 브로커를 추가한다.
2. 메시지의 병목현상이 발생할 경우 해당 토픽의 파티션을 증가한다.
- 파티션이 많을 수록 파일 핸들러가 증가 → 적절하게 사용해야한다.
- 파티션은 증가되면 줄이는 방법이 없다.
- 컨슈머 그룹내의 컨슈머 개수와 동등한 파티션 개수 설정 권고된다.
3. Message Lagging이 높을 경우 처리하는 컨슈머를 증가한다.
- 컨슈머 그룹별로 그룹 코디네이터가 각 컨슈머 그룹을 관리한다.
- 컨슈머 수가 변경되면 그룹내에서 소유권 이관작업이 발생 → 리밸런싱 된다.
- 컨슈머는 폴링(poling)하거나 커밋할 때 Heartbeat 메시지를 그룹 코디네이터에게 전달한다.
- 그룹 코디네이터가 일정기간 컨슈머의 하트비트를 받지 못하면 해당 컨슈머를 장애로 판단하고 리밸런싱 수행한다.