Kafka 개념과 구성 요소에 대한 이해

관련 내용

[리눅스 인프라/Kafka] - [Spring]Kafka를 활용한 이메일 인증 기능 구현하기

개요와 목적

관련 내용 블로그 글에서는 Kafka를 사용해서, 두 스프링 서버가 데이터를 통신하는 방식에 대해서 알아보았다. 이번에는 프로젝트에서 사용한, Kafka가 무엇인지 이론적 내용을 알아보려 한다.

카프카, 메세지 큐란

카프카는 메세지 큐이다. 데이터를 보내는 소스 어플리케이션과 데이터를 받는 타겟 어플리케이션 사이에 위치하여, 데이터 통신을 원활하게 해준다. 중간에 카프카를 두어서, 데이터를 통신하는 장점으로는

첫 번째, 데이터를 통신하는 어플리케이션간의 결합을 느슨하게 만들어 준다. 다양한 소스, 타겟 어플리케이션을 직접적으로 연결하려면, 가 어플리케이션에 맞는 프로토콜 등 설정이 복잡해진다. 하지만, 카프카에 중간에만 두면 모든 어플리케이션을 카프카에 연결만 하면 데이터 통신을 할 수 있다.

두 번째는, 비동기 방식으로, 데이터를 Queue에 넣어 놓기 때문에, 처리를 나중에 처리할 수 있다는 여유도 생긴다.

세 번째는 메세지 큐를 가운데 둠으로서, 작업이 처리되는 것을 한눈에 파악할 수 있다.

카프카의 구성 요소와 특징

리플리케이션(replication-복제)(분산 처리)

카프카에 들어오는 데이터들을 메세지들을 복제해서 카프카 클러스터 내 여러 브로커로 보내는 작업이다. 리플리케이션을 하면, 하나의 브러커에 장애가 나도, 다른 브로커가 역할을 수행할 수 있어서 안정성이 높아진다. 3개의 리플리케이션을 유지하는 것이 안정성과 디스크 용량을 고려할 때 가장 좋은 선택이라고 한다.

주키퍼(Zookeeper)

분산 애플리케이션사용하게 되면, 분산 애플리케이션 관리를 위한 코디데이션 애플리케이션 역할이다. 카프카의 메타데이터(metadata) 관리 및 브로커의 정상 상태 점검(health check) 을 담당한다.

토픽(topic)

카프카는 메시지 피드들(데이터들을)을 토픽으로 구분하고, 각 토픽의 이름은 카프카 내에서 고유하다. 위 블로그 내용 spring과 연결된 kafka 사용법을 보면 토픽을 어떻게 사용하는 지 볼 수 있다.

파티션(partition)(병렬처리)

하나의 토픽을 병렬 처리 할 수 있게, 토픽이 처리 되는 공간을 여러 곳으로 늘린 것을 의미한다.아래 그림을 보면, 토픽 1보다, 토픽 2가 동시에 처리 될 수 있는 수가 많아 진다.

파티션의 수를 정할 때는, 컨슈머의 LAG를 모니터링 하면서 정한다. 컨슈머의 LAG란 프로듀서가 보낸 메세지 수 - 컨슈머가 가져간 메세지수이다. 프로듀서가 보낸 메세지수가 많이 남아 있으면 파티션을 생성해서, 메세지가 처리 되는 속도를 높일 수 있다.

세그먼트(segment)

프로듀서에 전송된 메세지는 토픽의 각 파티션에 저장되고, 메세지들은 세그먼트라는 로그 파일의 형태로 브로커의 로컬 디스크에 저장된다. 파티션마다 n개의 세그먼트 로그파일이 존재한다.

프로듀서(producer)

카프카로 메시지를 보내는 역할을 하는 클라이언트이다.

프로듀서가 메세지를 보낼 때, 특정 토픽과 밸류(메세지 내용)은 필수이고, 특정 파티션을 지정하기 위한 레코드의 파티션 과 특정 파티션에 레코드들을 정렬하기 위한 레코드의 키는 선택 사항이다.

컨슈머(consumer) ,컨슈머 그룹

카프카에서 메시지를 꺼내가는 역할을 하는 클라이언트이다. 컨슈머 그룹은 하나 이상의 컨슈머들이 모여 있는 그룹을 의미하고 컨슈머는 반드시 컨슈머 그룹에 속하게 된다. 컨슈머 그룹의 컨슈머는 토픽의 파티션과 일대일 매핑되어 메세지를 가져온다. 컨슈머 수보다 파티션 수가 많아지면, 컨슈머가 2개이상의 파티션의 메세지들을 처리하게 된다.

 

---

Reference

https://sugerent.tistory.com/644

https://coding-nyan.tistory.com/129

https://sugerent.tistory.com/644

https://zeroco.tistory.com/105