[데브원영]아파치 카프카 for beginners 정리

• 아파치 카프카는 대용량, 대규모 메세지 데이터를 빠르게 처리하도록 개발된 메시징 플랫폼이다. 
• 큐 역할을 하며, 고가용성으로 서버가 이슈가 생기거나 갑작스러운 전원이 내려가는 상황에서도 데이터를 손실없이 복구할 수 있다.

 

 

 

기존 문제점

---

카프카 개발 전 링크드인의 데이터 처리 시스템

• 기존 링크드인의 데이터 처리 시스템은 각 파이프라인이 파편화되고 시스템 복잡도가 높아 새로운 시스템을 확장하기 어려운 상황이였음
• 기존 메시징 큐 시스템인 ActiveMQ를 사용했지만, 링크드인의 수많은 트래픽과 데이터를 처리하기에는 한계가 있었음
• 결론적으로 배포와 장애대응, 유지보수의 어려움이 있었다.
• 이로 인해 새로운 시스템의 개발 필요성이 높아졌고, 링크드인의 몇몇 개발자가 다음과 같은 목표를 가지고 새로운 시스템을 개발
  • 프로듀서와 컨슈머의 분리
  • 메시징 시스템과 같이 영구 메시지 데이터를 여러 컨슈머에게 허용
  • 높은 처리량을 위한 메시지 최적화
  • 데이터가 증가함에 따라 스케일아웃이 가능한 시스템

 

 

 

해결

---

카프카 개발 후 링크드인의 데이터 처리 시스템 

• 카프카를 적용함으로써 모든 이벤트/데이터의 흐름을 중앙에서 관리할 수 있게 되었다.
• 서비스 아키텍처가 기존에 비해 관리하기 심플해졌다.
  
  

출처: 인프런 - [데브원영]아파치 카프카 for beginners

• 아파치 카프카는 Source Application 과 Target Application 의 커플링을 약하게 하기 위해 나왔다.
• 예를들어 Source Application 은 쇼핑몰의 클릭로그, 은행의 결제로그를 보내면 Target Application 은 로그적재, 로그처리 등을 한다.
• Source Application 에서 보낼수 있는 데이터 포맷은 거의 제한이 없으며 여러 포맷을 지원한다.
• 카프카에는 각종 데이터를 담는 토픽이라는 개념이 있는데 쉽게 말해 큐라 생각하면 된다.
• 큐에 데이터를 넣는 역할은 프로듀서가 하고, 큐에서 데이터를 가져가는 역할은 컨슈머가 한다.
• 프로듀서와 컨슈머는 라이브러리로 되어있어서 애플리케이션에서 구현가능하다. 

 

카프카는 큐 역할을 하고 있으며,고가용성으로 서버가 이슈가 생기거나 갑작스럽게 전원이 내려간다거나 하는 상황에서도 데이터를 손실없이 복구할 수 있다. 또한 카프카는 낮은 지연(latency)과 높은 처리량(Throughput)을 통해서 아주 효과적으로 데이터를 아주 많이 처리할 수 있다.

 

 

 

카프카 토픽이란?

---

출처: 인프런 - [데브원영]아파치 카프카 for beginners

카프카에는 다양한 데이터가 들어갈 수 있는데 데이터가 들어가는 공간을 토픽이라고 부른다.

이 카프카 토픽은 일반적인 ActiveMQ 와는 다르게 동작한다.

• 카프카에서는 토픽을 여러개 생성할 수 있다.
• DB 테이블이나 파일시스템의 폴더와 유사한 성질을 가지고 있다.
• 토픽에 프로듀서가 데이터를 넣게되고 컨슈머는 데이터를 가져가게 된다.
• 토픽은 목적에 따라 이름을 명시할 수 있다. 무슨 데이터를 담는지 명확하게 명시하여야 유지보수가 용이해진다.

 

 

 

1) 토픽 내부

출처: 인프런 - [데브원영]아파치 카프카 for beginners

• 하나의 토픽은 여러개의 파티션으로 구성될 수 있다.
• 첫번째 파티션 번호는 0번부터 시작한다.
• 파티션은 큐와 같이 데이터가 파티션 끝에서부터 쌓이게 된다.
• click_log 토픽에 카프카 컨슈머가 붙게되면 데이터를 가장 오래된 순서대로 가져가게 된다.
• 더 이상 데이터가 들어오지 않으면 컨슈머는 또 다른 데이터가 들어올 때 까지 기다린다.
• 컨슈머가 토픽 내부의 파티션에서 데이터를 가져가더라도 데이터는 삭제되지 않고 파티션에 그대로 남는다.
• 데이터는 새로운 컨슈머가 붙었을때 다시 0번부터 가져가 사용할 수 있다.
• 다만, 컨슈머 그룹이 달라야하고 auto.offset.reset = earliest 이여야 한다.

이처럼 사용할 경우 동일 데이터에 대해서 두번 처리할 수 있는데 이는 카프카를 사용하는 중요한 이유이다.

 

 

 

2) 토픽에 파티션이 2개 이상인 경우

출처: 인프런 - [데브원영]아파치 카프카 for beginners

데이터 [7] 이 토픽에 들어가야하는데 파티션이 2개 이상이면 어느 파티션에 들어가야할까?

프로듀서가 데이터를 보낼때 키를 지정할 수 있다.

• 키가 null 이고 기본 파티션을 사용할 경우 라운드 로빈(Round robin)으로 할당한다.
• 키가 있고 기본 파티션을 사용할 경우 키의 해시 값을 구하고 특정 파티션에 할당한다.

 

 

 

3) 파티션을 늘릴 경우

출처: 인프런 - [데브원영]아파치 카프카 for beginners

파티션을 늘리는것은 아주 조심해야한다. 늘리는 것은 가능하지만 줄일수는 없다.

 

• 왜 파티션을 늘리는 것일까?
  • 파티션을 늘리면 컨슈머의 개수를 늘려서 데이터처리를 분산시킬 수 있다.

• 이렇게 데이터가 늘어나면 파티션의 데이터는 언제 삭제가 될까?
  • 삭제되는 타이밍은 옵션에 따라 다르다.
  • 레코드가 저장되는 최대 시간과 크기를 지정할 수 있다.
  • 이를 지정하면 일정한 기간 혹은 용량동안 데이터를 저장할 수 있게되고 적절하게 데이터가 삭제될 수 있도록 설정 할 수 있다.

 

 

 

프로듀서의 파티셔너

출처: 인프런 - [데브원영]아파치 카프카 for beginners

• 파티셔너는 카프카 프로듀서의 중요개념 중 하나이다.
• 파티셔너를 알면 파티션을 효과적으로 쓸 수 있다.
• 프로듀서가 데이터를 보내면 무조건 파티셔너를 통해 브로커로 데이터가 전송된다.
• 파티셔너는 데이터를 토픽에 어떤 파티션에 넣을지 결정하는 역할을 한다.
• 레코드에 포함된 메세지 키 또는 메세지 값에 따라서 파티션의 위치가 결정된다.
• 프로듀서를 사용할 때 파티션을 따로 설정하지 않으면 UniformStickyPartitioner 로 설정이 된다.
• 이 파티셔너는 메세지 키가 있을때와 없을때 다르게 동작한다.
  
  
  

출처: 인프런 - [데브원영]아파치 카프카 for beginners

메세지 키를 가진 레코드는 파티셔너에 의해서 특정한 해시값이 생성되는데 이 해시값을 기준으로 어느 파티션에 들어갈지 정해지게 된다.

출처: 인프런 - [데브원영]아파치 카프카 for beginners

토픽에 파티션이 2개가 있는 경우를 가정해보자. 파티셔너의 해시로직에 의해서 서울은 파티션 0번, 부산은 파티션 1번, 울산은 파티션 0번으로 들어갈 수 있다. 동일한 메세지 키를 가진 레코드는 동일한 해시값을 만들기 때문에 항상 동일한 파티션에 들어가는 것을 보장한다.

이렇게 동일한 메세지 키를 가진 레코드들은 동일한 파티션에 들어가기 때문에 순서를 지켜서 데이터를 처리할 수 있다는 장점이 있다.

 

예를들어, 서울의 온도를 기록하는 레코드를 파티션에 넣는다고 가정할 수 있는데 메세지 키에 "서울" 이라는 String 값을 넣고 레코드를 지속적으로 보낸다면 항상 동일한 파티션에 데이터가 순서대로 들어가기 때문에 컨슈머는 서울이라는 레코드를 순서를 지켜서 데이터를 처리할 수 있게 된다. 파티션 한개 내부에서는 큐처럼 동작하기 때문에 순서를 지킬 수 있는것이다.

 

• 메세지 키가 없는 경우
  • 메세지 키가 없는 레코드는 라운드 로빈으로 파티션에 들어가게 된다.
  • 전통적인 라운드 로빈 방식과는 조금 다르게 동작한다.
  • UniformStickyPartitioner 는 프로듀서에서 배치로 모을 수 있는 최대한의 레코드들을 모아서 파티션으로 데이터를 보내게된다.
  • 이렇게 배치단위로 데이터를 보낼때 파티션에 라운드로빈 방식으로 데이터를 넣게되는데 쉽게 말해 메세지 키가 없는 레코드들은 파티션에 적절히 분배된다고 생각하면 된다.
• 기본 파티셔너만 사용 가능할까?

그렇지 않다. 직접 개발한 파티셔너도 프로듀서에서 설정할 수 있다. 카프카에서는 커스텀 파티셔너를 만들 수 있도록 Partitioner 인터페이스를 제공하고 있다. Partitioner 인터페이스를 사용해서 커스텀 파티셔너 클래스를 만들면 메세지 키 또는 메세지 값 또는 토픽 이름 에 따라서 어느 파티션에 데이터를 보낼 것인지 정할 수 있다.

• 언제 커스텀 파티셔너를 사용하는 것일까?

예를들면, VIP 고객을 위해서 데이터 처리를 빠르게 하는 로직을 생각해볼 수 있다. VIP 고객의 데이터를 조금 더 빠르게 처리해주고 싶다면 파티셔너를 통해서 처리량을 더 늘릴 수도 있다. 기본적으로 10개의 파티션이 있다고 가정할 때 커스텀 파티셔너를 만들어서 8개 파티션에는 VIP 고객의 데이터 , 2개의 파티션에는 일반 고객의 데이터를 넣어서 데이터 처리량을 VIP 고객을 위해서 몰아주는 형태로 개발 할 수도 있다. 이것은 마치 AMQP 기반 메세징 시스템같은 곳에서 우리가 우선순위 큐를 만드는 것과 약간 비슷하다고 봐도 된다.

 

 

 

카프카 lag

---

카프카를 운영함에 있어서 아주 중요한 모니터링 지표중 하나이다.

카프카 lag이 존재하는 이유를 알려면 카프카 토픽과 파티션, 컨슈머와 프로듀서 그리고 오프셋에 대해서 모두 알아야 한다.

 

출처: 인프런 - [데브원영]아파치 카프카 for beginners

카프카 프로듀서는 토픽의 파티션에 데이터를 넣게된다. 파티션에 데이터가 들어가게되면 각 데이터는 오프셋이라고하는 숫자가 붙게된다. 만약, 파티션이 한개라고 가정했을시 토픽에 프로듀서가 데이터를 넣을 경우 0부터 차례대로 숫자가 매겨지게 된다. 프로듀서는 계속해서 데이터를 넣게되고, 컨슈머는 계속해서 데이터를 가져가게 된다.

• 만약 프로듀서가 데이터를 넣어주는 속도가 컨슈머가 가져가는 속도보다 빠르면 어떻게 될까?
  • 첫번째, 프로듀서가 넣은 데이터의 오프셋
  • 두번째, 컨슈머가 가져간 데이터의 오프셋
• 이 두개의 오프셋 간의 차이가 발생하게 된다.
• 이것이 Consumer lag 이다.
• lag 은 적을수도 있고 많을 수도 있다.
• 이 lag의 숫자를 통해 현재 해당 토픽에 대해 파이프라인으로 연계되어 있는 프로듀서와 컨슈머의 상태에 대해 유추가 가능하다.
• 주로 컨슈머의 상태에 대해 볼때 사용한다.
  
  
  

출처: 인프런 - [데브원영]아파치 카프카 for beginners

• lag 은 각 파티션의 오프셋 기준으로 프로듀서가 넣은 데이터의 오프셋과 컨슈머가 가져가는 데이터의 오프셋의 차이를 기반으로 한다.
• 그렇기 때문에 토픽에 여러 파티션이 존재할 경우 lag 은 여러개가 존재 할 수 있다.
• 만약, 컨슈머 그룹이 1개이고 파티션이 2개인 토픽에서 데이터를 가져간다면 lag 은 2개가 측정 될 수 있다.
• 이렇게 한개의 토픽과 컨슈머 그룹에 대한 lag이 여러개 존재할 수 있을때 그 중 높은 숫자의 lag을 records-lag-max 라고 부른다.
• 현업에서는 컨슈머 입장으로 많이 개발을 할수록 lag에 대해 많은 모니터링 경험이 있을 수 있다.
• 컨슈머가 성능이 안나오거나 비정상동작을 하게되면 lag이 필연적으로 발생하기 때문에 주의깊게 살펴볼 필요가 생긴다.

 

• lag 은 두가지만 알면된다.
  • lag 은 프로듀서의 오프셋과 컨슈머의 오프셋간의 차이이다.
  • lag 은 여러개가 존재할 수 있다.

 

 

 

끝으로

---

• 3개 이상의 카프카 브로커로 이루어진 클러스터를 구축하고 사용해야지만 정말 카프카를 써봤다고 할 수 있다.
• 카프카의 고가용성의 핵심은 3개 이상의 카프카 브로커로 이루어진 클러스터에서 진가를 발휘하기 된다.
• 아파치 카프카를 설치하기 위해서는 2가지 애플리케이션이 필요한데 첫번째는 주키퍼이고 두번째는 카프카이다.
• 이렇게 만든 카프카 클러스터는 3개의 브로커로 이루어져 있기 때문에 고가용성을 만족한다고 볼 수 있다. 

 

 

 

참고자료

---

[무료] [데브원영]아파치 카프카 for beginners - 인프런 | 강의

Apache Kafka(아파치 카프카)란 무엇인가?