Kafka 란

전준엽님의 블로그를 보고 저의 생각정리 용으로 적었습니다.

출처 : https://galid1.tistory.com/793

Kafka - Kafka란? (Kafka의 구조와, 주요개념)

Kafka란?

---

1. pub-sub 모델의 메시지 큐
   
   
2. 실시간으로 기록 스트림을 게시, 구독, 저장 및 처리할 수 있는 분산 데이터 스트리밍 플랫폼

 

 

사용 이유

---

대용량 데이터를 다룰 때 지연시간을 줄일 수 있기 때문

 

 

어디에 사용?

---

Apache Kafka는 초당 수백만 개의 데이터 포인트를 처리할 수 있으므로 빅데이터 과제에 적합

 

• IT 운영
  데이터에 빠르게 액세스하여 처리해야하는 경우

 

• IoT(사물 인터넷)
  다양한 센서가 들어간 기계의 경우 다양한 센서가 생성하는 대규모 데이터를 처리할 때

 

• 인터넷 쇼핑
  인터넷 쇼핑에 있는 좋아요, 페이지 클릭, 검색, 주문, 장바구니 등의 데이터를 처리할 수 있기 때문

 

그 외 다양한 곳에서 사용 할 수 있다.

 

구성요소

---

Event

- Kafka에서 Producer와 Consumer가 데이터를 주고 받는 단위.

 

Producer

- Producer는 Kafka에 이벤트를 게시하는 클라이언트 어플리케이션을 의미.

 

Consumer

- Consumer는 Producer가 발행한 이벤트가 쌓이는 곳인 Topic을 구독 하고 이로부터 얻어낸 이벤트를 처리하는 클라이언트 어플리케이션

Topic

- 이벤트가 쌓이는 곳. Producer는 Topic에 이벤트를 게시. Consumer는 Topic으로 부터 이벤트를 가져와 처리.

 

Partition

Topic은 여러 Broker에 분산되어 저장되며, 이렇게 분산된 Topic을 Partition이라고 한다. Producer가 게시하는 이벤트의 key 값에 따라 어느 partition에 저장될지 달라진다. 같은 키를 가지는 이벤트는 같은 partition에 저장된다.

 

kafka는 Topic의 Partition에 지정된 Consumer가 항상 동일한 순서로 Partition의 이벤트를 읽을 것을 보장한다.

 

Kafka의 주요 개념

---

Producer 와 Consumer의 분리

pub-sub 이란?

게시자와 구독자 라는 의미로 게시자는 게시만, 구독자는 게시물이 있는 곳을 구독하여 가져가는 역할만 한다.

 

이렇게 되면 둘의 관계는 전혀 없으므로 결합도가 낮아진다.

 

kafka도 마찬가지로 Producer는 Broker의 Topic에 메시지를 게시, Consumer는 Broker의 특정 Topic에서 메시지를 가져와 처리만 하면되기 때문에 높은 확장성을 가진다.

 

1. Pull 모델

Kafka의 Consumer는 Pull 모델을 기반으로 메시지를 처리. Broker가 Consumer에게 메시지를 전달하는 것이 아닌, Consumer가 필요할 때 Broker로부터 메시지를 가져와 처리하는 형태.

 

장점

1. 속도를 고려하지 않아도 됨.

 

Consumer가 처리가능한 때에 메시지를 가져와 처리하기 대문에 다양한 소비자를 다루기가 쉽고 속도를 고려하지 않아도 된다.

 

2. 지연없이 일괄처리를 통해 성능향상 도모.

 

Partition의 한칸은 로그라고 하며 메시지는 로그에 순차적으로 쌓인다. 그리고 쌓인 이 메시지의 상대적인 위치를 offset이라고 하는데 Consumer의 poll()은 이전에 기억한(commit) offset이 존재한다면 그 다음 offset의 메시지를 읽어들이기 때문에 불필요한 지연 없이 최적의 일괄처리가 가능.

 

단점

 

Broker가 메시지를 Consumer에게 전달할 때마다 Consumer 가 수신했다고 기록하면, Consumer가 메시지 처리를 실패하면 해당 메시지가 손실이 된다.

 

이로 인해, Broker는 메시지가 소비되었음을 기록하기 위해, Consumer의 승인을 기다린다. 하지만 이러한 경우에는 다른 문제점이 발생한다.

 

Consumer가 메시지를 성공적으로 처리하고 승인을 보내기전에 Broker가 실패 했다고 판단하고 다시 메시지를 보내면 중복으로 메시지를 처리하게 된다.

 

따라서 설계를 할때 특수한 상황에 메시지를 여러번 받아서 처리하더라도 한번 처리한 것과 같은 결과를 가지도록 설계를 해야한다.

 

2. Consumer Group

하나의 Topic을 구독하는 Consumer들을 그룹화 할 수 있다. 이렇게 그룹화 하는 이유는 가용성 때문이다.

 

하나의 Topic을 처리하는 Consumer가 하나인 경우보다 여러개인 경우가 가용성이 증가.

 

하나의 Topic을 구독하는 Consumer 가 Partition의 메시지를 처리 불가 상태가 되면 Kafka는 메시지 처리 순서를 보장하기 때문에 해당 Partition의 메시지를 처리할 수 없는 상태가 되버린다. 이때문에 Consumer Group이 필요하다.

 

 

Rebalance

 

해당 Partition을 담당하던 Consumer가 처리불가 상태가 된다면 , Partition과 Consumer를 재조정하여, 남은 Consumer Group 내의 Consumer 들이 Partition을 적절히 나누어 처리한다. (Redis의 Replication 등 과 비슷하다...)

 

Consumer Group에서 Consumer들은 offset 정보를 공유하고 있으므로 특정 Consumer가 처리 불가 상태가 되면 해당 Consumer가 처리한 마지막 offset 이후 부터 처리를 이어서 할 수 있다.

 

Consumer Group 과 Partition

 

Consumer Group 내의 Consumer 들은 각기 다른 Partition에 연결되어야 한다.

 

Consumer의 메시지 처리 순서를 보장하기 위해서 이다. Group이 하나의 Partition을 바라보고 있는 것은 안된다. 

이러한 제약이 있는 이유는 카프카는 토픽 수준에서의 순서보장은 지원하지 않기 때문이다.

 

카프카 프로듀서가 첫 번째 메시지를 1번 파티션에 전송하고, 두 번째 메시지를 3번 파티션에 전송했다고 하자.

 

1번 파티션과 2번 파티션을 소비하는 컨슈머가 같지 않을 수 있기 때문에 나중에 전송된 두 번째 메시지가 먼저 컨슈머에 의해 소비될 수 있다. 

 

 

Consumer 확장

 

Consumer Group 에서 Consumer 들은 Partition과 1:1 매칭이 되어야한다.

 

하지만 Consumer의 성능이 부족해 Consumer를 확장한다고 했을 때 Partition 2개와 Consumer 2개는 1:1 매칭이 되었지만 나머지 1개의 Consumer는 남아있게 된다.

 

그렇게 되면 새로 추가한 Consumer는 아무것도 안하는 상태가 된다.

 

그렇게 되면 Consumer 의 성능을 늘리기 위해 Consumer를 추가했는데 성능은 이전과 달라진게 없는 상황이 된다.

 

그러므로 Consumer Group에서 Consumer를 추가할 때 반드시 Partition도 같이 추가해줘야한다.