2022. 12. 7. 13:04ㆍInfra/DevOps
학습동기
예전부터 알고도 있었고, if kakao에서 아파치 플링크와 함께 로그 분석에 사용했다고하여, 간단히 producer, broker, consumer 구성으로 엇비슷하게 로그를 파싱하여 분산 프로세스별로 토픽을 나눠 broker에 저장하고, 검증이 필요한 프로세스별로 필요한 로그만 comsumer가 소비하여 기능 검증을 위한 로직을 만들어 본 경험도 있습니다.
하지만 그때는 제가 개발한 범위에서 kafka까지 써가며 그렇게 해야되는가? 라는 물음이 있었습니다. 규모가 작은데 별도의 broker 인스턴스까지 띄워서 처리를 해야하나 하는 것이었고, 프로그램이 죽지 않는다면 하나의 어플리케이션 내에서도 멀티스레드와 이벤트 큐를 활용해서 충분히 구현히 가능하기 때문이라 판단했습니다.
그러나 최근 어느정도 규모가 되는 서비스 회사들 서류 준비 및 면접을 몇번 본바, 실무에서 EDA를 적용하면서 굉장히 kafka를 많이 쓰고 있었고, 잘 만들어진 바퀴와 같은 kafka가 있는데, 왜 굳이 허접한 바퀴를 만들듯 직접 구현을 하는지에 대한 역질문도 받았습니다. 그래서 이걸 알아야 겠다고 생각했습니다. 그리고 시스템 아키텍처 스터디를 진행하면서 분산 시스템에서는 아주 필수라는 느낌을 받았기에 예전 기록과 도서들을 읽으며 정리한 내용을 파트를 나눠 정리해보고자 합니다.
카프카 Official : 링크
카프카 다운로드 : 링크( 카프카 CLI 사용목적이라면 bin 파일 사용을 추천합니다. source 다운로드 시 gradle build를 진행하여야 하는데, 꽤나 시간이 걸립니다. )
참고자료
- 카프카 데이터 플랫폼 최강자
- 실전 아파치 카프카
- 최범균님 - 아파치 카프카 설명 유튜브
카프카 클러스터 구축 내용 보기
아파치 카프카란?
아파치 소프트웨어 재단이 스칼라로 개발한 오픈 소스 메시지 브로커 프로젝트 입니다. 카프카는 높은 처리량, 낮은 지연시간을 제공하는 것을 목표로 개발된 pub/sub 메시지 큐라고 정의할 수 있을 것 같습니다.
링크드인에서 개발이 되었는데, 2011년에 아파치 재단의 오픈소스화가 되었고, 2014년 카프카 개발과 유지관리에 집중하기위해 링크드인의 카프카 관련 개발자들이 컨플루언트라는 회사를 창립하고 현재까지 여기서 관리를 하고 있다고 합니다.
카프카는 크게 브로커(메시지 큐), 프로듀셔(publisher), 컨슈머(consumer)로 구성이 되어있습니다. 아래는 개략적인 내용을 하나의 도식으로 정리한 내용입니다. 세부적으로 아래 내용을 하나씩 정리해보겠습니다.
Broker(브로커)
카프카 브로커는 메시지 큐입니다. 아주 유연한 메시지 큐라고 할 수 있습니다. 카프카에 저장되는 데이터는 아래와 같은 모델을 따릅니다.
- 토픽 : 메시지를 주고 받을 수 있도록 논리적으로 묶은 개념
- 파티션 : 토픽을 구성하는 데이터 저장소로서 수평 확장이 가능한 물리적 단위
카프카 브로커는 성능과 고가용성을 보장하기 위해서 아래와 같은 특징을 가지고 있습니다.
- 성능 : 페이지 캐시, Zero Copy
- 고가용성 : 파티션 리플리케이션 + 리더/팔로워 구조
페이지 캐시는 말그대로 캐시를 사용해서 성능을 높인다는 맥락으로 이해하면 됩니다. 파티션에 대한 파일 IO를 실제 파일이나 물리적인 저장매체에 저장하는 것이 아닌 메모리에서 처리하는 방식을 채택하여 성능을 높인다고 합니다. 디스크에 저장을 안하는 것은 아닙니다. 다만 접근을 최소화하기 위해서 디스크에 저장은 하되, 한번 접근한 데이터는 캐시에 저장하여 성능을 높인다고 합니다. 그리고 Zero Copy를 채택하여 디스크 버퍼에서 네트워크 버퍼로 데이터를 직접 복사함으로서 application layer에서 객체간 데이터가 매핑되는 행위를 줄임으로서 성능을 높인다고 합니다.
메모리 캐시를 사용하게 되면 JVM heap 영역을 많이 사용하게 됩니다. (스칼라 기반이기에 JVM 사용) 이에 메모리 부족이 있을 수 있어 JVM 힙 메모리 튜닝을 권장한다고 합니다. ( default 1G -> 5G ) 또한 하나의 인스턴스에 카프카를 다른 애플리케이션과 함께 실행하는 것을 권장하지 않는다고 합니다.
그리고 고가용성을 보장하기 위해서 클러스터가 구성되어 있다면, 복제수(replication factor) 만큼 파티션의 복제본이 각 브로커에 생성을 하여 분산하는 구조를 사용합니다. 복수의 브로커는 리더와 팔로워로 구분되는데, 저는 DB의 mater slave라고 생각했습니다. 리더에 write가 발생하고 팔로워는 리더로 부터 데이터를 복제하여 저장합니다. 이 상태에서 리더가 장애발생 시 팔로워가 리더가 되어 신속하게 장애에 대응함으로서 고가용성을 보장한다고 합니다. 이 개념을 도서에서는 ISR(In Sync Replica)라고 합니다.
Producer(프로듀서)
카프카에서 프로듀서는 메시지를 생산해서 브로커의 토픽으로 메시지를 보내는 역할을 하는 애플리케이션이나 서버를 모두 프로듀서라고 부릅니다. 즉 데이터를 publishing하는 주체를 통칭한다고 볼 수 있습니다.
주요 기능은 각각의 메시지를 토픽 파티션에 매핑하고 파티션 리더에 요청을 보내는 것입니다. 통신을 담당하는 프로세스로서 동기방식. 비동기 방식으로 데이터를 전송할 수 있습니다.
- 동기방식 : Future 객체를 리턴 받아서 메시지가 잘 갔는지 확인하고 이어서 처리
- 비동기방식 : send 메소드를 콜백과 같이 호출하고 카프카 브로커에서 응답을 받으면 콜백을 하는 방식
한 가지 주요 특징은 배치 처리가 가능하다는 것입니다.
Consumer ( 컨슈머 )
컨슈머는 프로듀서와 반대로 토픽의 메시지를 가져와서 소비하는 역할의 애플리케이션, 서버를 총칭하는 것입니다. 컨슈머의 주요 기능은 특정 파티션을 관리하고 있는 파티션 리더에게 메시지 가져오기를 요청하는 것입니다. 그리고 가져온 메시지를 소비하는 것이 끝이 났다면 해당 메시지를 다 소비했다는 Commit을 해야하며, 장애 등으로 Consumer가 종료되는 경우 offset 부터 데이터를 읽어 오도록 되어 있습니다. Commit에 대한 부분은 내부 운영로직에 따라 정책을 여러가지로 변경할 수 있다고 생각합니다.
그리고 컨슈머는 컨슈머 그룹을 형성하여 데이터를 가져올 수 있습니다. 파티션 하나는 무조건 컨슈머 그룹에서 하나의 컨슈머와 매핑이 되어야 합니다. 이에 따라서 파티션 조정이 필요할 수 있습니다.
정리
기본적인 카프카의 개념들에 대해서만 정리를 해보았습니다. 카프카 클러스터를 간단하게 구축하였는데, 실제 consumer와 producer 어플리케이션 개발까지 함께하여 각종 옵션과 분산 처리 과정에 대한 테스트, 시나리오 등을 지속 공유할 수 있도록 하겠습니다.
참고자료
'Infra > DevOps' 카테고리의 다른 글
| [Kafka] Kafka Cluster Docker-compose로 구축하기 (0) | 2022.12.07 |
|---|---|
| [ERROR] kafka cluster 구성 후 --zookeeper 옵션 사용 시 에러 발생 (0) | 2022.12.07 |
| Docker Compose로 MySQL Replication 구축 (1) | 2022.11.25 |