Apache Kafka에 대하여

Kafka 는 RabbbitMQ, ActiveMQ와 같은 전통적인 Message Queue 방식과 비교 했을 때 처리량, 처리속도, 가용성, 확장성이 월등하게 앞선다.

이러한 장점 때문에 IT 서비스 회사들은 Kafka 도입을 적극적으로 추진하고 있다. 하지만 Kafka 를 잘 모르고 그냥 남들이 다 해서 도입을 하게 되면 오히려 안쓰는게 좋은 선택일 수도 있다.

필자의 회사에서도 Kafka 를 도입하고 있는데 더 명확한 개념을 학습하기 위해 이렇게 정리를 한다.

 

Apache Kafka 는 대용량 실시간 데이터 스트리밍을 처리하기 위한 분산형 메시징 플랫폼 이면서 마이크로서비스 아키텍쳐 (Micro Service Architecture) 내에서도 활용되는 오픈소스이다.

Apache Kafka는 LinkedIn에서 처음 개발되어 현재는 Apache 재단에서 관리되고 있다. LinkedIn 에서는 방대한 양의 데이터를 실시간으로 처리하는 과정에서 어려움을 겪었고 이 문제를 해결하기 위해 중앙화 된 메시지와 데이터의 흐름을 관리하는 구조를 가져가기 위해 만들어진 것이 Kafka 이다.

LinkedIn이 Kafka 를 사용 하기 전 내부 시스템 구조를 보면 매우 복잡한 구조 이면서 개별적인 연결을 하는 구조였기 때문에 확장 에도 어려움이 분명 존재했다.

LinkedIn 의 과거 시스템 구조를 도식화 된 그림으로 한번 보자

https://www.confluent.io/blog/event-streaming-platform-1/

https://www.confluent.io/blog/event-streaming-platform-1/

첫번째 사진이 과거 구조이고 두번째 사진은 kafka가 적용되어 kafka가 중앙에서 메시지와 다양한 데이터 흐름을 가져가는 구조로 변경되었다.

kafka 가 도입 되면서 확실히 간결해진 모습을 볼 수 있다.

이제 kafka의 기본적인 개념에 대해서 한번 보자.

https://data-flair.training/blogs/kafka-architecture/

위 사진은 Kafka의 구조를 보여준다.

Kafka Cluster

여러 대의 분산된 Kafka 서버를 네트워크로 연결하여 하나의 서버처럼 동작하게 만드는 개념을 Server Clustering 이라고 한다. 여러대의 Kafka 서버를 클러스터로 묶게 되면 특정 서버에서 장애가 발생해도 다른 서버에서 외부 요청을 처리 할 수 있기 때문에 서비스 전체의 가용성이 올라가게 된다.

Kafka broker

broker 는 Kafka 의 서버를 말한다. broker 는 producer 부터 메시지를 수신하고 Offeset 을 지정한 후 해당 메시지를 디스크에 저장하게 된다. 그리고 컨슈머가 파티션 읽기를 요청하면 그 요청에 대해 디스크에 수록된 데이터를 전송하여 응답한다.

Kafka Broker 는 Kafka Cluster 의 일부 구성원으로 동작된다. 여러 개의 broker 가 하나의 Kafka Cluster 에 포함될 수 있고, 이 중 하나는 컨트롤러 역할을 한다. 컨트롤러는 Broker 들이 정상적으로 동작 하는지 모니터링하고 Broker 에게 담당 파티션을 할당 해준다.

Topic

Kafka의 메시지는 Topic으로 분류가 된다. 하나의 Topic은 여러개의 파티션으로 구성될 수 있다. 메시지는 파티션에 앞에서부터 뒤로 추가 되는 형태로만 기록되고 맨 앞부터 차례대로 메시지가 읽힌다.

Partitio

파티션은 Topic을 여러 파티션으로 나눠서 병렬 처리가 가능하도록 한다. 여기서 각 파티션은 서로 다른 서버에 메시지가 분산되어 요청 될 수 있다. 이 말은 즉 하나의 토픽이 여러 서버에 걸쳐 수평적으로 확장이 가능 하단 뜻이다. 이러한 이유는 Kafka에서 메시지 처리 순서가 Topic이 아닌 파티션 별로 관리가 되기 때문이다.

고로 단일 서버로 처리할 때 보다 훨씬 더 높은 성능을 가질수 있다.

Message

Kafka 에서 데이터의 기본 단위이다. 메시지는 바이트(byte) 배열의 데이터로 간주한다. 바이트 배열로 간주하기 때문에 데이터의 형태는 제약 없이 자유롭게 저장이 가능하고 메시지를 받는 입장에서는 변환하여 사용해야 한다.

메시지는 파티션에 기록된다. 메시지가 어떤 파티션에 기록 할 파티션을 결정하기 위해 메시지에 담긴 key값을 해시 처리하고, 그 값과 일치하는 파티션에 메시지를 기록한다. 여기서 key값을 해시 처리 하는 기능을 해시 파티셔너라고 한다. 고로 같은 키 값을 가진 메시지는 같은 파티션에 저장된다는 의미이다. 만약 키값이 없는 상태 (null)로 넘어가게 되면 Kafka 내부의 기본 파티셔너가 라운드로빈 (Round robin) 방식으로 파티션에 기록되는 메시지 개수의 균형을 맞추게 된다.

Producer

프로듀서는 새로운 메시지를 특정 토픽에 생성 하는 역할을 한다. 프로듀서는 기본적으로 어떤 파티션에 기록 될지는 관여하지 않는다. 어떤 파티션에 기록 될지 결정 하는 것은 위에서 말한 파티셔너의 역할이다.

Consumer

컨슈머는 하나 이상의 토픽을 구독하면서 메시지가 생성된 순서대로 읽는다. 여기서 메시지는 파티션 단위 Offset 을 통해 어디까지 읽었는지 알수있다. 오프셋은 Commit Offset과 Current Offset이 있다. Commit Offset은 컨슈머로 부터 “여기까지 작업을 했다"를 확인 하는 역할을 한다. Current Offset은 컨슈머가 어디까지 읽었는지를 나타내는 오프셋이다.

이러한 오프셋의 기능 덕분에 컨슈머가 읽기를 중단 했다가 다시 시작하더라도 완료된 그 다음 메시지부터 읽을수 있다.