💡 [데브원영] 아파치 카프카 for beginner 강의를 통한 학습 기록

1. Kafka가 무엇인가?

• 카프카가 나오기 전에는 Target Application이 증가하여 "데이터 전송 라인이 많아져, 배포와 장애에 배포하기 어렵다".
• 데이터 전송시 "프로토콜 파편화"가 심해져서 추후 데이터 포맷 내부의 변경사항이 발생하면 "유지보수하기 어렵다."

• 이러한 복잡함들을 해결하기 위해서, LinkedIn애서 개발한 파이프라인, 스트리밍 분석, 데이터 통합 및 미션 크리티컬 애플리케이션을 위해 설계된 "고성능 분산 이벤트 스트리밍 플랫폼"이다.
• "Pub-Sub 모델의 메시지 큐 형태"로 동작하며 "분산환경(ex.MSA)에 특화"되어 있다.

2. Kafka의 장점 & 사용이유

⭐️⭐️⭐️ 고가용성 (fault tolerant) ⭐️⭐️⭐️

• 서버에 문제가 생기거나, 갑자기 랙(전원)이 내려간다던가 하는 상황에서 "데이터를 손실없이 복구 가능"
• 낮은 지연(delay) & 높은 처리량(Throughput)으로 많은 데이터 처리 가능

3. Kafka의 특징

• 카프카는 "Source Application"과 "Target Application" 사이의 "커플링 (다른 서비스에 의존)"을 약화시키기 위해서 나왔다.
• Source Application은 카프카에 데이터 전송 , Target Application은 카프카에서 데이터를 가져온다.
• Source Application의 예시에는 "클릭로그", "결제로그" / Target Application은 "로그적재", "로그처리"가 있다.
• Source Application는 카프카에 거의 대부분의 데이터 타입의 데이터(json, tsv, avro등등)를 전송 가능한다.

• 카프카는 각종 데이터를 담는 "Topic"이라는 "큐(Queue)"와 같은 개념이 존재한다.
• "Topic"에 데이터를 넣는 것은 "Kafka Producer"가 하고, "Topic"에서 데이터를 가져오는 것은 "Kafka Consumer"가 한다.
• Producer와 Consumer 모두 라이브러리로 구현되어 있다.

4. Kafka의 Topic

💡 AMQP(Advanced Message Queuing Protocol)란?

Message Queue를 기반 시스템들 간의 효율적으로 메세지를 교환하는 프로토콜
Producer -> Exchange -> Queue -> Consumer
대표적으로 "RabbitMQ"가 존재한다.
(카프카는 AMQP와는 다른 프로토콜을 사용한다.)

1) Kafka Topic이란?

• Kafka는 Queue와 같이 데이터를 저장하는 "Topic"이 존재한다.
• Topic은 DB의 테이블이나 파일시스템의 폴더와 유사하다.
• Topic은 "이름"을 가질 수 있고, 각 목적에 맞춰서 이름을 지으면 유지보수에 효과적이다.

2) Kafka Topic 내부

2-1) 파티션이 1개인 경우

• 하나의 Topic은 여러개의 "partition(파티션)"으로 구성될 수 있으며, 파티션에 데이터가 0번 인덱스부터 차곡차곡 쌓인다.
• Kafka Consumer는 파티션에서 "가장 오래된 데이터"부터 가져간다.
• Kafka Consumer가 데이터를 모두 가져가면 다른 데이터가 들어올 떄까지 기다린다.

• Consumer가 데이터(record)를 가져가도 데이터는 삭제되지 않고, 그대로 남는다.
• 새로운 컨슈머도 기존 컨슈머와 동일하게 인덱스가 0인 가장 오래된 데이터부터 가져간다.
• 컨슈머끼리 "컨슈머 그룹이 다르고", "auto.offset.reset=earliest"라는 설정이 존재해야 한다.
• 이렇게 하면 동일 데이터에 대해서 여러번 사용할 수 있다. (ex. 클릭로그 분석 및 시각화를 위한 es저장, 클릭로그 백업을 위한 hadoop 저장)

2-2) 파티션이 2개 이상인 경우

💡 Round Robin 이란?

우선순위 없이 시간 순서대로 할당하는 스케쥴링 프로세스

• 파티션이 여러 개일 경우, 키 값이 "Null"이면 "Round Robin"방식으로 시간 순서대로 할당
• 피티션이 여러 개일 경우, 키 값이 존재한다면, 키의 해시(hash)값에 맞는 파티션에 할당
• 파티션은 계속해서 늘릴 수 있지만, "파티션을 줄이는 것은 불가능한다."
• 파티션을 늘리면, 컨슈머의 갯수를 늘려서 "데이터 처리를 분산"할 수 있다.

2-3) 파티션의 데이터(record)가 삭제되는 시기

• 파티션의 데이터는 "레코드가 저장되는 최대시간, 최대크기"를 지정할 수 있다.
• 이 옵션에 맞추서 파티션의 데이터가 삭제된다.

5. Kafka의 Producer

💡 Kafka Producer란?

데이터를 카프카의 Topic에 생성(전송)하는 주체

Producer의 역할

• Topic에 해당하는 메시지를 생성
• 특정 Topic으로 데이터를 publish(전송)
• 처리 실패/재시도 (broker로 전송시 ACK 사용)

6. 카프카 Broker & Replication & ISR

💡 카프카 Broker란?

카프카가 설치되어 있는 서버 단위

• 카프카 Broker는 카프카가 설치되어 있는 서로 다른 서버를 말한다.
• 카프카 Broker는 "3개 이상의 브로커"를 구성하여 사용하도록 권장된다.

💡 카프카 Replication이란?

파티션의 복제를 의미

• 카프카 Replication은 카프카 topic 내부의 파티션의 복제를 의미한다.
• "replication: 1" 이라면, 파티션은 "원본 1개"만 존재한다.
• "replication: 2" 이라면, 파티션은 "원본 1개 복제본 1개"가 존재한다.
• "replication: 1" 이라면, 파티션은 "원본 1개 복제본 2개"가 존재한다.
• Replication의 갯수는 Broker의 갯수를 넘을 수 없다. (ex. replication수 : 4 , Broker수:3 => X )

1) Leader & Follower Partition

역할

• 원본 파티션은 "Leader partition" 이라고 부른다.
• 복제된 나머지 파티션은 "Follower partition" 이라고 부른다.
• Leader Partition은 Producer가 Topic으로 데이터를 전달할 때, 전달받는 주체
• Follower Partition은 Leader partition의 복제본

작동 원리 (Ack)

• Procuder의 Ack을 통해서 고가용성을 유지한다.
• Ack은 "0,1,all" 이 존재한다.

<Ack이 0인 경우>

• ACk이 0일 경우에는 Procuder가 데이터를 Topic에 전송하고, 응답값은 받지 않아 데이터가 Leader Partition에 잘 전송되었는지, Follower Partition에 잘 복제되었는지 모른다.
  => 속도는 빠르지만, 데이터 유실 가능성이 있다.
  

<Ack이 1인 경우>

• Ack이 1인 경우에는 Producer가 전송한 데이터를 Leader partition이 잘 받았는지 응답값을 받는다.
• 하지만 Leader Partition에서 문제가 생겨서 다른 Follower Partititon에 복제할때, 잘 복제되었는지는 알지 못한다.
• 만약 복제하기 전에 Leader partition에 문제가 생기면 역시 데이터가 유실될 수 있다.

<Ack이 all인 경우>

• Ack이 All인 경우에는 Producer에서 보낸 데이터가 Leader Partition에 잘 전송되었는지, Follower Partition에 잘 복제가 되었는지 응답값을 받는다.
  => 데이터 손실은 없지만, 속도가 매우 느리다.

2) Replication을 사용하는 이유

• partition의 "고가용성" 을 위해서 사용된다.
• 파티션의 고가용이란?
  => 데이터의 손실 없이 지속적으로 사용할 수 있도록 하는 복제 메커니즘과 장애 복구 기능
• Replication이 1개라면, 1개의 Broker가 사용할 수 없게 되면, 해당 파티션을 더이상 복구할 수 없다.
• Replication이 2개라면, 1개의 Broker가 사용할 수 없게 되어도, Replication된 파티션(Follower partition) 을 사용할 수 있기 때문에 복구가 가능하다.
  => Follower partition이 Leader partition 역할을 계승한다.

3) Replication의 갯수

• Replication의 갯수가 많을수록 좋아지는 것은 아니다.
• Replication의 갯수가 많아지면, Broker의 리소스 사용량도 증가한다.
• 카프카에 들어오는 데이터량 과 저장시간(retention date) 을 잘 조절하여서 Replication 갯수를 정해야한다.
• 3개 이상의 Broker를 사용할 경우 3개의 Replication 사용을 권장한다.

💡 Kafka ISR이란?

Leader partition이랑 Follower partition을 모두 합친 것

• 카프카의 Leader Partition과 Follower Partition을 모두 합친 것을 "ISR"이라고도 한다.

7. 카프카 파티셔너

💡 카프카 파티셔너란?

Procuder가 보내는 데이터를 Broker의 어떤 partition에 넣어줄지 정해주는 역할을 해주는 것

• 파티셔너는 Procuder로부터 전달받은 데이터를 특정 조건에 따라 토픽의 어떤 partition에 넣어줄 지 결정한다.
• Procuder를 사용할 때 partitioner를 따로 설정하지 않으면 **UniformStickyPartitioner"로 설정된다.

UniformStiockyPartitioner 사용 경우

1) 메세지 키가 없는 경우

• RoundRobin으로 파티션에 들어가게 된다.
• Producer에서 데이터를 보낼떼, 배치로 모을 수 있는 최대한의 레코드를 모아서 한번에 파티션으로 보낸다.
• 이런 배치단위로 데이터를 보낼 때 파티션에 RoundRobin 방식으로 넣게 된다. (파티션에 적절히 분배)

2) 메세지 키가 있는 경우

• 메세지 키를 가지는 레코드는 파티셔너에 의해 "특정한 해쉬값"으로 생성된다.
• 이 해쉬값을 기준으로 어느 파티션에 들어가는지 결정된다.
• 동일한 키를 가진 레코드들은 항상 동일한 파티션으로 순서대로 들어간다.
  => 순서를 지켜서 데이터를 처리할 수 있다.
• Ex) hash("서울") = 파티션 #0 / hash("부산") = 파티션 #1

커스텀 Partitioner 사용 경우

• Partitioner 인터페이스를 사용하여 커스텀 Partitioner를 만들 수 있다.
• 메세지 키 or 메세지 값 or 토픽 이름에 따라 어느 파티션에 데이터를 전송할 것인지 정할 수 있다.
• ex) VIP에게 더 많은 파티션을 할당하고, 데이터를 처리를 더 빠르게 하기 위해서 사용되기도 한다.

8. 카프카 컨슈머 Lag

💡 카프카 컨슈머 Lag이란?

Topic의 가장 최신 데이터의 오프셋과 Consumer의 오프셋의 차이
Producer가 마지막으로 넣은 offset 과 컨슈머가 마지막으로 읽은 Offset의 차이

1) 파티션이 1개인 경우

• 파티션에 데이터가 하나하나씩 들어갈 때, 각 데이터에 붙는 번호(인덱스)를 "오프셋(offset)" 이라고 한다.
• Consumer lag은 "Producer가 마지막으로 넣은 offset"과 "컨슈머가 마지막으로 읽은 Offset"의 차이이다.
• Producer가 데이터를 넣는 속도가 Consumer가 데이터를 받아가는 속도보다 빠르면 발생한다.
• lag의 숫자로 Producer와 Consumer의 상태를 유추 가능하다. (주로 Consumer의 상태)
  => consumer가 성능이 안나오거나, 비정상적인 동작을 하게 되면 lag이 발생하므로, 모니터링을 통해 상태 관리

2) 파티션이 여러개인 경우

• 실제 토픽에는 여러개의 파티션이 존재하기 때문에, lag도 여러개가 존재할 수 있다.
• 한 개의 Topic과 컨슈머 그룹에 대한 lag이 여러개 존재할 때, 그중 높은 숫자의 lag를 "records-lag-max"라고 한다.

9. 오픈소스 Burrow (카프카 Consumer lag 모니터링)

💡 Burrow

링크드인에서 제작한 아파치 카프카용 컨슈머 lag 를 체크하기 위한 api 서비스

Consumer lag를 모니터링 하는 2가지 방법

1) Kafka Consumer 객체를 통해 lag 정보 추출 (Kafka-client 라이브러리 사용) - 권장 X

=> lag 실시간 모니터링 가능

• 데이터를 ElasticSearch 나 InfluxDB와 같은 저장소에 넣은 후, Grafana 대시보드를 통해 확인 가능
• But, Consumer 단위에서 lag를 모니터링 하는 것은 매우 "위험하고, 운영요소가 많이"든다.
  => 컨슈머 로직단에서 lag를 수집하는 것은 컨슈머 상태에 dependency가 걸린다.
  => 컨슈머가 비정상적으로 종료되면 더이상 lag 정보를 수집할 수 없다.
  => 컨슈머가 개발될 때마다, 해당 컨슈머의 lag 정보를 특정 저장소에 저장할 수 있도록 로직을 짜야한다.
  

2) Burrow 라이브러리 사용( Linkedin 제공 )

• Opensource로 Golang으로 작성되었다.
• Consumer lag의 모니터링을 도와주는 독립적인 application

특징

1) 멀티 카프카 클러스터 지원

• Burrow application이 1개여도, 여러 개의 카프카 클러스터들에 붙은 컨슈머의 lag를 모니터링 할 수 있다.

2) Sliding Window를 통한 Consumer의 status 확인

• Burrow는 Sliding Window를 통해서 Consumer의 상태를 "WARNING", "OK", "ERROR"로 나타낸다.
• 데이터 량이 일시적으로 많아져서 offset이 증가하고 있으면 "WARNING"으로 정의된다.
• 데이터 량이 많아지는데 Consumer가 데이터를 가지고 가지 않으며느 "ERROR"로 정의하여, 컨슈머의 문제 여부를 알 수 있다.

3) HTTP api 제공

• 가장 범용적인 HTTP api를 제공한다.
• HTTP api를 호출하여 response 받은 데이터를 시계열DB와 같은 곳에 저장하는 application을 만들어 활용할 수 있다.

10. RabbitMQ vs Redis Queue vs Kafka

💡 메세징 플랫폼

메세지 브로커 vs 이벤트 브로커
메세지 브로커는 이벤트 브로커로의 역할 X
이벤트 브로커는 메세지 브로커로의 역할 O

1) 메시지 브로커 - Redis Queue, RabbitMQ

• 대규모 메시지 기반 미들웨어 아키텍처에서 사용됨
  => 미들웨어: 서비스하는 어플리케이션들의 아키텍처를 효율적으로 연결하는 요소들로 작동하는 소프트웨어
  (메시지 플랫폼, 인증 플랫폼, 데이터 베이스)
• 메세지 브로커에 있는 Queue에 Producer와 Consumer가 데이터를 주고 받는 네트워크를 맺는 용도
• 메세지를 받아 처리 후, 즉시 or 짧은 시간 내에 삭제되는 구조

2) 이벤트 브로커 - Kafka, 키네시스(AWS)

• 서비스에서 나오는 이벤트를 이벤트 브로커의 Queue에 저장한다.
• 이벤트(메시지)를 보관하는 장부를 1개만 가지고, 인덱슬르 통해 개별 액세스를 관리한다.
• 업무상 필요한 시간동안 데이터(레코드)를 보관할 수 있다. (삭제 X)
• 이점
  => 딱 1번 일어난 이벤트 데이터를 브로커에 저장 (단일 진실 공급원으로 사용)
  => 장애 발생시 장애가 발생한 지점으로 부터 재처리 가능
  => 많은 양의 스트림 데이터를 효과적으로 처리 가능
  => MSA에서 많이 활용됨