Kafka 파헤치기 (1) – 개념편

Event 를 다루거나, 확장성있는 구조를 갖추기 위해서, 혹은 Pub/Sub 의 Message Queue 로 Kafka를 많이 사용한다.
많이 사용되는 Kafka에 대해 깊게 고민해보고 하나씩 파헤쳐보며 Kafka 에 대해 제대로 공부하고 잘 사용해보자.

Kafka 개념 파악하기

Kafka는 Event 파이프라인, 스트리밍 등을 위해 설계된 고성능 분산 이벤트 스트리밍 플랫폼이다.
Pub-Sub 모델의 Message Queue 형태로 동작하며 분산환경에 특화되어 주로 대량의 이벤트 스트림 데이터를 처리하고 여러 시스템 간에 데이터를 신속하게 전송하는 데 사용된다.
Kafka를 이해하기 위해 Kafka 에서 사용되는 여러 용어들과 작동원리에 대해 먼저 살펴보자.

Topic 과 Partition

Topic 은 Message Queue 이름 이라고 대입해서 생각하면 편하다.
Kafka는 Pub / Sub 모델이기 때문에 메시지를 범주별로 분류하는 논리적인 이름이 필요하다.( 예를 들면, user-registration 이라는 토픽은 유저가 회원가입 하는것과 관련된 메시지가 입력됨을 알 수 있다. ) 그 역할을 하는것이 바로 Topic 이다. 특정 Topic 을 구독하면 해당 Topic 에 메시지가 발행될 때 Kafka를 통해 메시지를 구독할 수 있다.
한 Topic 을 구독하는 Consumer 가 여럿 일 수 있기 때문에 각 Topic에 대해 여러 소비자가 독립적으로 메시지를 읽을 수 있다.

Partition은 Topic을 실제로 나누는 단위를 말한다. Topic은 하나 이상의 Partition으로 구성될 수 있고, 각 Partition은 Topic 내에서 메시지를 물리적으로 저장( 이 저장된 메시지들을 Segment 라고 한다. )하는 컨테이너를 말한다. 이 파티션의 개수는 처음 지정한 값 보다 늘릴 수는 있지만, 줄일수는 없다. Partition은 순서가 있는 로그 구조를 갖고, 각 메시지는 해당 Partition 내에서 유일한 Offset 을 가진다. ( 같은 파티션 내에서 순서를 보장해준다. )
여기서 추가적으로 알아야할 정보가 있는데, Partition 에는 LeaderFollower 라는 개념( Replication )이 존재한다.

Leader Partition 은 반드시 1개 이상 존재하는 Partition 으로, 실제 Producer & Consumer 와 통신을 담당하는 중요한 역할을 하는 Partition 을 말한다. 실제로 읽기와 쓰기를 담당하는 중요한 파티션이다.
Follower Partition 은 리더 파티션으로 전달된 데이터를 복제하여 복제된 데이터를 저장하는 파티션을 말한다. 안정성을 위한 Partition 이라고 생각하면 된다. 이 Follower Partition 이 많으면 리더 파티션이 속해있는 브로커에 장애가 발생하더라도, 복제 데이터를 갖고 있는 Follower들 중 하나가 Leader가 되어 장애에 대응할 수 있다.

이 Follower Partition 을 설정하는것이 Replication factor 라는 부분인데, 이 Replication factor 의 숫자 만큼 Follower 가 늘어나는 것이다.

출처 : https://jack-vanlightly.com/blog/2018/9/2/rabbitmq-vs-kafka-part-6-fault-tolerance-and-high-availability-with-kafka

예를 들어, topic1 이라는 이름을 가진 Topic 에 Partition 이 4개, Replication factor 가 3라면 최소한 브로커는 3( Replication Factor 개수만큼은 최소 필요하다. )개가 필요하고 Leader Partition은 총 4개가 되고, Follower Partition 8개 ( 4개 파티션 *2 Follower )가 된다.
이런 특징 때문에, 윗 예제에서 Broker( 카프카 서버, 후술한다 ) 2 와 Broker 3 에 장애가 발생하더라도, Broker 1에 있는 Follower 들이 전부 Leader 로 변경되며 정상적으로 전달할 수 있다.

추가적으로, Follower 라고 전부다 Leader 가 될 수 있는건 아니다. ISR( In-Sync Replica, 리더의 정보를 문제없이 복사하고 있는 파티션들의 그룹을 말한다. ) Group 에 속해 있는 Follower 만이 Leader 가 될 자격이 있다. 장애는 Leader 가 아닌 Follower 에서도 발생될 수 있다. 만약 Follower 에서 장애가 발생하여 제대로 Leader 의 정보를 복제하지 못했다면, 차후 Leader 가 되면 문제가 되기 때문에 이런 경우에는 ISR 그룹에서 추방된다.

Leader는 만약 특정 Follower가 특정 주기의 시간만큼 복제요청을 진행하지 않는다면 Replication 동작에 문제가 발생했다고 판단하고 ISR 그룹에서 추방하게 된다. 차후에 추방된 Follower가 다시 정상적으로 작동하고 리더 복제본과 동기화할 수 있는 상태가 되면, Kafka는 해당 복제본을 다시 ISR 그룹에 추가해준다. 이때 Follower는 리더의 현재 데이터를 동기화하게 된다.

Broker

Broker 는 카프카 서버와 1:1로 대응되는 것이라고 생각하면 된다. 브로커 내부에 메시지를 전달하기 위한 Partition들이 생성되고, 각 Partition 들이 보관하는 데이터를 저장하고, 장애 대응해주는 역할을 한다. 이 Broker 들 중, 특별한 Broker 가 2가지 있다. ControllerCoordinator 라고 한다. 이 특별한 브로커들은 여러 브로커들중 하나가 추가적으로 이 역할을 수행하게 된다.

Controller는 처음 가장 먼저 생성된 Broker 가 담당하게 되며, Controller는 클러스터의 전반적인 메타데이터와 브로커 상태를 관리한다. 어떤 Partition 이 Follower 가 되고, Leader 가 될 지를 결정하고, ISR Group 을 관리하고, Leader 가 다운되었을 경우 Follower 를 Leader 로 승격시키는 일도 담당한다.
또한, Broker 가 추가 & 제거되거나, Partition 이 추가적으로 늘어나거나 할 경우에도 브로커의 부하를 조정하고, 특정 파티션을 이동시키는 Cluster Rebalancing 작업을 담당한다. 이 과정을 통해 클러스터의 부하를 균등하게 분산하고, 클러스터의 안정성과 성능을 보장한다.

Coordinator에는 소비자 그룹을 관리하는 Group Coordinator 와 트랜잭션을 관리하는 Transaction Coordinator 가 있다.

Group Coordinator 는 Consumer Group의 상태를 체크하며 관리하는 Coordinator이다. Consumer Group 내의 소비자가 장애가 발생하여 매칭된 파티션의 데이터를 구독할 수 없는 경우, 장애가 발생한 Consumer에게 매칭된 파티션을 정상 동작하는 다른 Consumer에게 매칭해준다. 또한, Consumer Group 에 새로운 Consumer 가 추가 & 삭제되었을 경우나 해당 Consumer Group이 구독하는 Topic 이 추가되거나 할 때 Consumer 를 적절한 Partition 과 매칭해주는 역할을 담당한다. 이러한 일련의 과정을 Consumer Rebalancing 이라고 부른다.

Transaction Coordinator 는 Producer 의 메시지 전송에 대한 Transaction 처리를 위한 Coordinator 이다. 프로듀서에 의해 전송된 메시지를 관리하고, 커밋 또는 중단 등을 표시하는 역할을 한다.

ZooKeeper

주키퍼는 카프카 Cluster에 관한 메타데이터( 환경 설정 등 )를 통합 관리하는 시스템이다. 클러스터를 구성하는 브로커들끼리 공유되는 데이터를 유지하고, 조율하는데 사용되나, 현재는 Raft 가 Production Ready 가 되어서 기본으로 됨에 따라 Zookeeper 가 없이도 동작한다.

이렇게 카프카에서 주로 사용되는 개념들에 대해 알아보았다. 다음 편에서는 리밸런싱에 대한 자세한 접근과 몇가지 개념, 그리고 사용 예제들을 알아보자.

Leave a Comment