[AWS] Kafka서비스란 무엇인가

 

1. Kafka란?

Kafka는 Pub-Sub 모델의 메시지 큐이다. 분산환경에 특화되어 있는 특징을 가지고 있다.

 

 

 

2. 구성 요소

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

Producer : Producer는 Kafka에 이벤트를 게시(Post)하는 클라이언트 어플리케이션을 의미한다.

Consumer : Consumer는 이러한 Topic을 구독하고 이로부터 얻어낸 이벤트를 처리하는 클라이언트 어플리케이션이다.

Topic : 이벤트가 쓰이는 곳이다. Producer는 이 Topic에 이벤트를 게시하고, Consumer는 Topic으로부터 이벤트를 가져와 처리한다.
Topic은 파일시스템의 폴더와 유사하며, 이벤트는 폴더안의 파일과 유사하다. Topic에 저장된 이벤트는 필요한 만큼 다시 읽을 수 있다.

Partition : Topic은 여러 Broker에 분산되어 저장되며, 이렇게 분산된 Topic을 Partition이라고 한다. 어떤 이벤트가 Partition에 저장될지는 이벤트의 Key(키)에 의해 정해지며, 같은 키를 가지는 이벤트는 항상 같은 Partition에 저장된다.
Kafka는 Topic의 Partition에 지정된 Consumer가 항상 정확히 동일한 순서로 Partition의 이벤트를 읽을것을 보장한다.

 

 

 

3.Kafka의 주요 개념

Producer와 Consumer의 분리

Kafka의 Producer와 Consumer는 완전 별개로 동작을 한다.
Producer는 Broker의 Topic에 메시지를 게시하기만 하면되며, Cosumer는 Broker의 특정 Topic에서 메시지를 가져와 처리를 하기만 한다.
이 덕분에 Kafka는 높은 확장성을 제공한다.
즉, Producer 또는 Consumer를 필요에 의해 스케일 인 아웃하기에 용이한 구조이다.
만약, Producer와 Consumer가 직접적으로 연관을 가지고 있다면, 확장 또는 축고기 이들을 모두 연결 또는 해제를 하기가 매우 번거럽고 어려웠을 것이다.

 

 

Push와 Pull 모델

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

이러한 형태는 아래와 같은 장점이 존재한다.

1. 다양한 소비자의 처리 형태와 속도를 고려하지 않아도 된다.
반대의 경우인 Push 모델에서는 Broker가 데이터 전송 속도를 제어하기 때문에, 다양한 스트림의 소비자를 다루기가 어렵지만, Pull 모델은 Consumer가 처리 가능한 때에 메시지를 가져와 처라하기 때문에 다양한 소비자를 다루기가 쉽다.

2. 불필요한 지연 없이 일괄 처리를 통해 성능 향상 도모.
Push 모델의 경우에는, 요청을 즉시 보내거나, 더 많은 메시지를 한번에 처리하도록 하기 위해 Buffering을 할 수 있다. 하지만 이런 경우, Consumer가 현재 메시지를 처리할 수 있음에도, 대기를 해야한다. 그렇다고 전송 지연시간을 최소로 변경하면, 한번에 하나의 메시지만을 보내도록 하는것과 같으므로 매우 비효율적이다. pull 모델의 경우, 마지막으로 처리된 메시지 이후의 메시지를 Consumer가 처리가능한 때에 모두 가져오기 때문에, 이 문제를 해결한다. 따라서 불필요한 지연 없이 최적의 일괄처리를 할 수 있다.

 

 

 

소비된 메시지 추적 (Commit과 Offset)

메세지는 지정된 Topic에 전달된다. Topic은 다시 여러 Partition으로 나뉠 수도 있다.
위 그림에서 각 파티션의 한칸한칸은 로그라고 칭한다.
또한 메시지는 로그에 순차적으로 append된다. 그리고 이 메시지의 상대적인 위치를 Offset이라고 칭한다.

메시징 시스템은 Broker에서 소비된 메시지에 대한 메타데이터를 유지한다. 즉, 메시지가 Consumer에게 전달되면 Broker는 이를 로컬에 기록하거나, 소비자의 승인을 기다린다.

 

 

Commit과 Offset

Consumer의 poll()은 이전에 Commit한 Offset이 존재하면, 해당 Offset 이후의 메시지를 읽어오게 된다. 또 읽어온 뒤, 마지막 Offset을 Commit한다. 이어서 poll()이 실행되면 방금전 Commit한 Offset 이후의 메시지를 읽어와 처리하게 된다.

메시지 소비중에는 다음과 같은 문제들이 발생할 수도 있다.

 

 

소비된 메시지 기록시점

Broker가 메시지를 네트워크를 통해 Consumer에게 전달할 때 마다 즉시, 소비 된 것으로 기록하면, Consumer가 메시지 처리를 실패하면 해당 메시지가 손실된다.

이로 인해서, Broker는 메시지가 소비되었음을 기록하기 위해서, Consumer의 승인을 기다린다. 하지만 이런식으로 메시지를 처리하게 되면 아래와 같은 문제점이 또 발생한다.

 

 

중복 메시지 전송과 멱등성

우선 Consumer가 메시지를 성공적으로 처리하고, 승인을 보내기전에 Broker가 실패하였다고 판단하고 다시 메시지를 보내게 되면, Consumer는 같은 메시지를 두번 처리하게 된다.

따라서, Consumer는 멱등성을 고려하여야 한다. 즉, 같은 메시지를 특수한 상황에 의해 여러번 받아서 여러번 처리하더라도, 한번 처리한것과 같은 결과를 가지도록 설계해야한다. 

 

 

Consumer Group

Consumer Group은 하나의 Topiuc을 구독하는 여러 Consumer 들의 모음이다. Topic을 구독하는 Consumer들을 Group화 하는 이유는 가용성 때문이다. 하나의 Topic을 처리하는 Consumer가 1개인 것보다 여러개라면 당연히 가용성은 증가할 것이다. 아래에서 설명드릴 내용이지만, Consumer Group의 각 Consumer들은 하나의 Topic의 각기 다른 Partition의 내용만을 처리할 수 있는데, 이를 통해서 Kafka는 메시지 처리 순서를 보장한다고 한다. 이 때문에, 특정 Partition을 처리하던, Consumer가 처리 불가 상태가 된다면, 해당 Partition의 메시지를 처리할 수 없는 상태가 되어 버린다. 이 때문에 Consumer Group이 필요하다.

 

 

Rebalance

Partition을 담당하던 Consumer가 처리불가 상태가 되어버리면, Partition과 Consumer를 재조정하여 남은 Consumer Group내의 Consumer 들이 Partition을 적절하게 나누어 처리하게 된다.

또한, Consumer Group 내에서 Consumer들간에 Offset 정보를 공유하고 있기 때문에, 특정 Consumer가 처리불가 상태가 되었을때, 해당 Consumer가 처리한 마지막 Offset이후 부터 처리를 이어서 할 수 있다.

이렇게 Partition을 나머지 Consumer들이 다시 나누어 처리하도록 하는 것을 Rebalance라고 하며, 이를 위해 Consumer Group이 필요하다.

 

 

Consumer Group과 Partition

무조건, Consumer Group내의 Consumer들은 모두 각기 다른 Partition에 연결되어야 한다. 이렇게 함으로서 Consumer의 메시지 처리 순서를 보장하게 된다. 즉, 위와 같은 그림의 형태로는 가능하지만,

이와 같은 형태로 구성은 불가능 하다.

 

 

 

Consumer 확장

 

Consumer의 성능이 부족해, Consumer를 확장한다고 했을때, Consumer Group내의 Consumer는 무조건 각기 다른 Partition에만 연결을 할 수 있다고 했다. 때문에, Consumer만을 확장하였고 이때, Partition보다 Consumer의 수가 많으면 당연히 새 Consumer는 놀게 된다.

따라서, Consumer를 확장할 때에는, Partition도 같이 늘려주어야 한다.

 

메시지 전달 컨셉

Kafka는 메시지 전달을 할때 보장하는 여러가지 방식이 있다.

* At most once(최대 한번)
메시지가 손실 될 수 있지만, 재전달은 하지 않는다.

* At least once(최소 한번)
메시지가 손실되지 않지만, 재전달이 일어난다.

* Exactly once(정확히 한번)
메시지는 정확히 한번 전달 된다.

 

 

 

Amazon MSK(Managed Streaming for Apache Kafka)는 AWS에서 제공하는 완전 관리형 Apache Kafka 서비스이다. 기존 on-premise에서 사용하던 혹은 EC2로 관리하던 Apache Kafka를 Saas 형태로 사용할수 있다. Apache Kafka의 특정 버전을 그대로 사용할 수 있기 때문에 Vanila Apache Kafka의 버전별 api spec을 따라서 사용할 수 있다.