- 아파치 카프카는 대용량, 대규모 메세지 데이터를 빠르게 처리하도록 개발된 메시징 플랫폼이다.
- 큐 역할을 하며, 고가용성으로 서버가 이슈가 생기거나 갑작스러운 전원이 내려가는 상황에서도 데이터를 손실없이 복구할 수 있다.
기존 문제점
- 기존 링크드인의 데이터 처리 시스템은 각 파이프라인이 파편화되고 시스템 복잡도가 높아 새로운 시스템을 확장하기 어려운 상황이였음
- 기존 메시징 큐 시스템인 ActiveMQ를 사용했지만, 링크드인의 수많은 트래픽과 데이터를 처리하기에는 한계가 있었음
- 결론적으로 배포와 장애대응, 유지보수의 어려움이 있었다.
- 이로 인해 새로운 시스템의 개발 필요성이 높아졌고, 링크드인의 몇몇 개발자가 다음과 같은 목표를 가지고 새로운 시스템을 개발
- 프로듀서와 컨슈머의 분리
- 메시징 시스템과 같이 영구 메시지 데이터를 여러 컨슈머에게 허용
- 높은 처리량을 위한 메시지 최적화
- 데이터가 증가함에 따라 스케일아웃이 가능한 시스템
해결
- 카프카를 적용함으로써 모든 이벤트/데이터의 흐름을 중앙에서 관리할 수 있게 되었다.
- 서비스 아키텍처가 기존에 비해 관리하기 심플해졌다.
- 아파치 카프카는 Source Application 과 Target Application 의 커플링을 약하게 하기 위해 나왔다.
- 예를들어 Source Application 은 쇼핑몰의 클릭로그, 은행의 결제로그를 보내면 Target Application 은 로그적재, 로그처리 등을 한다.
- Source Application 에서 보낼수 있는 데이터 포맷은 거의 제한이 없으며 여러 포맷을 지원한다.
- 카프카에는 각종 데이터를 담는 토픽이라는 개념이 있는데 쉽게 말해 큐라 생각하면 된다.
- 큐에 데이터를 넣는 역할은 프로듀서가 하고, 큐에서 데이터를 가져가는 역할은 컨슈머가 한다.
- 프로듀서와 컨슈머는 라이브러리로 되어있어서 애플리케이션에서 구현가능하다.
카프카는 큐 역할을 하고 있으며,고가용성으로 서버가 이슈가 생기거나 갑작스럽게 전원이 내려간다거나 하는 상황에서도 데이터를 손실없이 복구할 수 있다. 또한 카프카는 낮은 지연(latency)과 높은 처리량(Throughput)을 통해서 아주 효과적으로 데이터를 아주 많이 처리할 수 있다.
카프카 토픽이란?
카프카에는 다양한 데이터가 들어갈 수 있는데 데이터가 들어가는 공간을 토픽이라고 부른다.
이 카프카 토픽은 일반적인 ActiveMQ 와는 다르게 동작한다.
- 카프카에서는 토픽을 여러개 생성할 수 있다.
- DB 테이블이나 파일시스템의 폴더와 유사한 성질을 가지고 있다.
- 토픽에 프로듀서가 데이터를 넣게되고 컨슈머는 데이터를 가져가게 된다.
- 토픽은 목적에 따라 이름을 명시할 수 있다. 무슨 데이터를 담는지 명확하게 명시하여야 유지보수가 용이해진다.
1) 토픽 내부
- 하나의 토픽은 여러개의 파티션으로 구성될 수 있다.
- 첫번째 파티션 번호는 0번부터 시작한다.
- 파티션은 큐와 같이 데이터가 파티션 끝에서부터 쌓이게 된다.
- click_log 토픽에 카프카 컨슈머가 붙게되면 데이터를 가장 오래된 순서대로 가져가게 된다.
- 더 이상 데이터가 들어오지 않으면 컨슈머는 또 다른 데이터가 들어올 때 까지 기다린다.
- 컨슈머가 토픽 내부의 파티션에서 데이터를 가져가더라도 데이터는 삭제되지 않고 파티션에 그대로 남는다.
- 데이터는 새로운 컨슈머가 붙었을때 다시 0번부터 가져가 사용할 수 있다.
- 다만, 컨슈머 그룹이 달라야하고 auto.offset.reset = earliest 이여야 한다.
이처럼 사용할 경우 동일 데이터에 대해서 두번 처리할 수 있는데 이는 카프카를 사용하는 중요한 이유이다.
2) 토픽에 파티션이 2개 이상인 경우
데이터 [7] 이 토픽에 들어가야하는데 파티션이 2개 이상이면 어느 파티션에 들어가야할까?
프로듀서가 데이터를 보낼때 키를 지정할 수 있다.
- 키가 null 이고 기본 파티션을 사용할 경우 라운드 로빈(Round robin)으로 할당한다.
- 키가 있고 기본 파티션을 사용할 경우 키의 해시 값을 구하고 특정 파티션에 할당한다.
3) 파티션을 늘릴 경우
파티션을 늘리는것은 아주 조심해야한다. 늘리는 것은 가능하지만 줄일수는 없다.
- 왜 파티션을 늘리는 것일까?
- 파티션을 늘리면 컨슈머의 개수를 늘려서 데이터처리를 분산시킬 수 있다.
- 이렇게 데이터가 늘어나면 파티션의 데이터는 언제 삭제가 될까?
- 삭제되는 타이밍은 옵션에 따라 다르다.
- 레코드가 저장되는 최대 시간과 크기를 지정할 수 있다.
- 이를 지정하면 일정한 기간 혹은 용량동안 데이터를 저장할 수 있게되고 적절하게 데이터가 삭제될 수 있도록 설정 할 수 있다.
프로듀서의 파티셔너
- 파티셔너는 카프카 프로듀서의 중요개념 중 하나이다.
- 파티셔너를 알면 파티션을 효과적으로 쓸 수 있다.
- 프로듀서가 데이터를 보내면 무조건 파티셔너를 통해 브로커로 데이터가 전송된다.
- 파티셔너는 데이터를 토픽에 어떤 파티션에 넣을지 결정하는 역할을 한다.
- 레코드에 포함된 메세지 키 또는 메세지 값에 따라서 파티션의 위치가 결정된다.
- 프로듀서를 사용할 때 파티션을 따로 설정하지 않으면 UniformStickyPartitioner 로 설정이 된다.
- 이 파티셔너는 메세지 키가 있을때와 없을때 다르게 동작한다.
메세지 키를 가진 레코드는 파티셔너에 의해서 특정한 해시값이 생성되는데 이 해시값을 기준으로 어느 파티션에 들어갈지 정해지게 된다.
토픽에 파티션이 2개가 있는 경우를 가정해보자. 파티셔너의 해시로직에 의해서 서울은 파티션 0번, 부산은 파티션 1번, 울산은 파티션 0번으로 들어갈 수 있다. 동일한 메세지 키를 가진 레코드는 동일한 해시값을 만들기 때문에 항상 동일한 파티션에 들어가는 것을 보장한다.
이렇게 동일한 메세지 키를 가진 레코드들은 동일한 파티션에 들어가기 때문에 순서를 지켜서 데이터를 처리할 수 있다는 장점이 있다.
예를들어, 서울의 온도를 기록하는 레코드를 파티션에 넣는다고 가정할 수 있는데 메세지 키에 "서울" 이라는 String 값을 넣고 레코드를 지속적으로 보낸다면 항상 동일한 파티션에 데이터가 순서대로 들어가기 때문에 컨슈머는 서울이라는 레코드를 순서를 지켜서 데이터를 처리할 수 있게 된다. 파티션 한개 내부에서는 큐처럼 동작하기 때문에 순서를 지킬 수 있는것이다.
- 메세지 키가 없는 경우
- 메세지 키가 없는 레코드는 라운드 로빈으로 파티션에 들어가게 된다.
- 전통적인 라운드 로빈 방식과는 조금 다르게 동작한다.
- UniformStickyPartitioner 는 프로듀서에서 배치로 모을 수 있는 최대한의 레코드들을 모아서 파티션으로 데이터를 보내게된다.
- 이렇게 배치단위로 데이터를 보낼때 파티션에 라운드로빈 방식으로 데이터를 넣게되는데 쉽게 말해 메세지 키가 없는 레코드들은 파티션에 적절히 분배된다고 생각하면 된다.
- 기본 파티셔너만 사용 가능할까?
그렇지 않다. 직접 개발한 파티셔너도 프로듀서에서 설정할 수 있다. 카프카에서는 커스텀 파티셔너를 만들 수 있도록 Partitioner 인터페이스를 제공하고 있다. Partitioner 인터페이스를 사용해서 커스텀 파티셔너 클래스를 만들면 메세지 키 또는 메세지 값 또는 토픽 이름 에 따라서 어느 파티션에 데이터를 보낼 것인지 정할 수 있다.
- 언제 커스텀 파티셔너를 사용하는 것일까?
예를들면, VIP 고객을 위해서 데이터 처리를 빠르게 하는 로직을 생각해볼 수 있다. VIP 고객의 데이터를 조금 더 빠르게 처리해주고 싶다면 파티셔너를 통해서 처리량을 더 늘릴 수도 있다. 기본적으로 10개의 파티션이 있다고 가정할 때 커스텀 파티셔너를 만들어서 8개 파티션에는 VIP 고객의 데이터 , 2개의 파티션에는 일반 고객의 데이터를 넣어서 데이터 처리량을 VIP 고객을 위해서 몰아주는 형태로 개발 할 수도 있다. 이것은 마치 AMQP 기반 메세징 시스템같은 곳에서 우리가 우선순위 큐를 만드는 것과 약간 비슷하다고 봐도 된다.
카프카 lag
카프카를 운영함에 있어서 아주 중요한 모니터링 지표중 하나이다.
카프카 lag이 존재하는 이유를 알려면 카프카 토픽과 파티션, 컨슈머와 프로듀서 그리고 오프셋에 대해서 모두 알아야 한다.
카프카 프로듀서는 토픽의 파티션에 데이터를 넣게된다. 파티션에 데이터가 들어가게되면 각 데이터는 오프셋이라고하는 숫자가 붙게된다. 만약, 파티션이 한개라고 가정했을시 토픽에 프로듀서가 데이터를 넣을 경우 0부터 차례대로 숫자가 매겨지게 된다. 프로듀서는 계속해서 데이터를 넣게되고, 컨슈머는 계속해서 데이터를 가져가게 된다.
- 만약 프로듀서가 데이터를 넣어주는 속도가 컨슈머가 가져가는 속도보다 빠르면 어떻게 될까?
- 첫번째, 프로듀서가 넣은 데이터의 오프셋
- 두번째, 컨슈머가 가져간 데이터의 오프셋
- 이 두개의 오프셋 간의 차이가 발생하게 된다.
- 이것이 Consumer lag 이다.
- lag 은 적을수도 있고 많을 수도 있다.
- 이 lag의 숫자를 통해 현재 해당 토픽에 대해 파이프라인으로 연계되어 있는 프로듀서와 컨슈머의 상태에 대해 유추가 가능하다.
- 주로 컨슈머의 상태에 대해 볼때 사용한다.
- lag 은 각 파티션의 오프셋 기준으로 프로듀서가 넣은 데이터의 오프셋과 컨슈머가 가져가는 데이터의 오프셋의 차이를 기반으로 한다.
- 그렇기 때문에 토픽에 여러 파티션이 존재할 경우 lag 은 여러개가 존재 할 수 있다.
- 만약, 컨슈머 그룹이 1개이고 파티션이 2개인 토픽에서 데이터를 가져간다면 lag 은 2개가 측정 될 수 있다.
- 이렇게 한개의 토픽과 컨슈머 그룹에 대한 lag이 여러개 존재할 수 있을때 그 중 높은 숫자의 lag을 records-lag-max 라고 부른다.
- 현업에서는 컨슈머 입장으로 많이 개발을 할수록 lag에 대해 많은 모니터링 경험이 있을 수 있다.
- 컨슈머가 성능이 안나오거나 비정상동작을 하게되면 lag이 필연적으로 발생하기 때문에 주의깊게 살펴볼 필요가 생긴다.
- lag 은 두가지만 알면된다.
- lag 은 프로듀서의 오프셋과 컨슈머의 오프셋간의 차이이다.
- lag 은 여러개가 존재할 수 있다.
끝으로
- 3개 이상의 카프카 브로커로 이루어진 클러스터를 구축하고 사용해야지만 정말 카프카를 써봤다고 할 수 있다.
- 카프카의 고가용성의 핵심은 3개 이상의 카프카 브로커로 이루어진 클러스터에서 진가를 발휘하기 된다.
- 아파치 카프카를 설치하기 위해서는 2가지 애플리케이션이 필요한데 첫번째는 주키퍼이고 두번째는 카프카이다.
- 이렇게 만든 카프카 클러스터는 3개의 브로커로 이루어져 있기 때문에 고가용성을 만족한다고 볼 수 있다.
참고자료
[무료] [데브원영]아파치 카프카 for beginners - 인프런 | 강의
아파치 카프카란 무엇일까? 아파치 카프카는 어떻게 동작할까? 아파치 카프카의 개념은 무엇이 있을까? 궁금하시다면 이 강의를 선택하세요😎, 안녕하세요, 데브원영입니다🖐 포춘 100대 기업
www.inflearn.com
Apache Kafka(아파치 카프카)란 무엇인가?
기존 링크드인의 데이터 처리 시스템은 각 파이프라인이 파편화되고 시스템 복잡도가 높아 새로운 시스템을 확장하기 어려운 상황이였음기존 메시징 큐 시스템인 ActiveMQ를 사용했지만, 링크드
velog.io