Kafka Technical

Kafka 개요

Apache Kafka에 대한 학습한 내용을 정리하여, 블로그 내용을 시작하려 한다. 총 3개의 내용으로 정리할 예정이며, “1. Kafka 개요”, “2. Kafka 실전 코드”, “3. Kafka 사례” 내용으로 구성되었다.

  • Kafka 개요
  • Kafka 실전 코드
  • Kafka 사례

0. 톺아보기

Apache Kafka (이하 Kafka)는 분산서버 환경에서 대량의 데이터를 전달 처리하는 현재 최고의 시스템으로 자리 잡았다. Kafka 이전부터 유사한 수준에 있는 IBM MQ, Rabit MQ, Apache ActiveMQ 등 수많은 Message Queue 시스템과 비교하며, 왜 최고의 스펙을 갖춘 시스템이라 하는 이유와 기본적인 구조를 정리하고자 한다.

1. Kafka 필요 배경

과거에는 실제 필요한 데이터만 취급해서 처리하던 방식에서 모든 사용자의 이벤트를 처리하고자 하는 IT 트랜드에 따라 발생되는 데이터는 상당히 많은 양으로 증가하게 되었고, 이런 데이터는 시스템의 다양한 페러다임에 따라, 수용가능한 구조가 되었다.

물론, 몇년전을 생각한다면, 시스템 설계 패턴은 대부분 동작의 마무리 결과를 기록하는 형태라고 할 수 있다. 오더 정보 기록, 청구 정보 기록 등 시스템 기록에 남겨지는 트랜잭션 로그를 남기는 방식에 일부 필요한 사용자 로그를 부분적으로 이력으로 생성하는 방식을 의미한다.

그러나 현재에는 중국의 대인배라고 불리는 AliExpress를 예로, 물건을 구매하다가 취소를 하면, 이메일로 최근에 당신이 구매하려했다가 아직 진행하지 않았던 상품이다 라던지, 취소했던 물건이다 라고 잊을만 하면 알려주며 구매하지 않으려는 결심을 깨트리고 만다.

과거 방식으로 생각한다면, 쿠키 수준에서 무언가를 했겠구나 싶지만… 세상은 많이 변했다. 사용자가 발생하는 모든 웹로그는 마케팅 활용으로 사용하는 최고의 데이터가 되고 있으며, 이를 뒤받침 할 만큼 시스템도 크게 변화하고 눈돌리면 발전하고 있다는 것이다.

Kafka는 2011년에 LinkedIn(이하 링크드인)에서 시작하여, 웹사이트 활동 추적을 목적으로 개발되어, 웹에서 활동하는 모니터링과 서비스 개선에 활용하고 있다.

https://blog.linkedin.com/2011/01/11/open-source-linkedin-kafka
링크드인 공식 블로그

당시 링크드인에서는 Kafka 출범에 4가지를 목표로 하였다

  • 높은 처리량으로 실시간 처리
  • 임의의 타이밍에 데이터를 읽음
  • 다양한 제품과 시스템에 쉽게 연동
  • 메시지를 잃지 않음

당연한 것 같은 목표지만, kafka의 장점은 이 4가지를 모두 만족한다. 4가지를 모두 만족한다는 것은 이제부터 설명하겠지만, 최고 스펙. 종결자로써 정리된다.

vs Message Queue

Kafka 와 항상 비교되는 Message Queue 유형은 “IBM MQ”, “JMS(Java Messaging System)”, “Apache ActiveMQ”, “RabbitMQ” 등 수도 없이 많다. 각기 다른 장단이 있겠지만, 결론적으로 Message Queue 제품은 Queue 라는 저장공간에 대량 적재라는 개념으로는 가능하지 않다. 심지어 상대 시스템의 상태에 관계없이 계속 밀어 넣어 버리는 형태도 있다.

vs 로그 수집

실시간 로그 수집으로 Apache Flume이 있으나, Flume에서 메시지를 처리할 경우 필요한 개념인 ‘minute 파일’의 의미를 제대로 알기 어려웠고, 현재에는 Flume만 사용하는 형태보다는 Kafka와 같이 사용하는 방식도 있다. 필요한 시점에 Pull 하며, 데이터 스트림을 통한 가공 후 다시 사용하는 방식이다.

vs ETL

ETL(Extract, Transform, Load) 툴은 대량 데이터를 처리하는 방식에서는 파일 단위로 시스템 사이에 변환 처리를 실시하며 전달하는 방식이었으나, 링크드인의 목적에는 레코드 단위로 실시간 처리가 목적이기에 다소 다른 처리 패턴을 가진다. 또한 ETL 전달이 주요 목적이기 때문에 다양한 제품과의 연동 목적을 이루지는 않는다.

ETL(추출, 변환, 로드) 프로세스
https://docs.microsoft.com/ko-kr/azure/architecture/data-guide/relational-data/etl

종합 요약

요구사항Message Queue로그 수집 시스템ETL 툴Kaka 목표 여부
실시간(메시지 단위)OOX
(파일 묶음 전송)
O
확장 구성XOOO
영속화
(장기 불가)
X
(NFS, HDFS 연계 필요)
XO
다양한 접속OOO
전달 보증O
(트랜잭션O)

(트랜잭션X)
O
(전후 연계)
O
도서 : 실전 아파치 카프카 (사사키 도루)

2. Kafka 아키텍처

Kafka 개요

많은 용어가 등장하지만, Message Queue 기반에 조그만 경험이 있다면 매번 사용하던 용어 들이다. Broker와 Partition의 개념이 Kafka에서는 약간 특별한데, Broker는 Topic(Message 저장 스토리지)를 관리하는 Instance이다. Kubernetes 기반으로 운영한다면, StatefulSet이 되고, 일반적이라면 서버 1대의 동작 형태이다(WAS를 서버 1식에 1개만 띄우던 형식). Partition 역시 Topic 구성을 위한 분산 저장 방식이며, Producer, Consumer는 Topic과 통신한다.

https://docs.cloudera.com/documentation/kafka/1-2-x/topics/kafka.html
  • Producer
    • 데이터 생산자. 메시지를 보내는 어플리케이션
    • Producer API를 사용하여 직접 구현하거나, OSS(Open Source Software)가 다수 존재
      • Apache Log4J (Kafka Appender) – 로그 출력 유틸
      • Apache Fulme – 대량 로그 수집, 취합, 이동 목적 분산SW
      • Fluentd – 데이터 수집 SW
      • Logstash – 데이터 수집 엔진
  • Consumer
    • 메시지를 취득하는 어플리케이션
    • 일정 기간 데이터가 축적된 스토리지(Topic)에서 데이터 추출 및 실시간 처리를 위한 어플리케이션 또는 다수 OSS 존재.
      • Apache Spark – 빅데이터 처리 용도 Cluster 컴퓨팅 FW
      • Apache Samza – 스트림 처리 용도 준리얼타임 계산 FW
      • Apache Flink – 스트림 처리 용도 FW
      • Apache Flume
      • Fluentd
      • Logstash
  • Brocker
    • 데이터를 수신, 전달하는 서비스
    • 서버당 하나의 데몬 프로세스로 동작(Kubernetes에서는 Statefulsets 로 동작)
    • 복수 구성하여 Kafka Cluster 를 구성 함.
    • 수신, 전달 처리량 향상을 위한 Scale Out 가능.
  • Topic
    • 메시지를 종류별로 관리하는 스토리지. Brocker에 배치되어 관리.
    • Producer, Consumer는 Topic을 지정하여 메시지를 송수신 함.
  • Message
    • Kafka 데이터 최소 단위. Key, Value 구조로 전송되며, Key에 따라 파티셔닝 발생.
  • Zookeeper
    • 분산 처리를 위한 관리 도구. 분산 메시징의 Topic, Partition 등의 메타 데이터를 관리하기 위한 구성 요소로 기능.
  • Kafka Client
    • Topic 생성 및 Kafka Control을 위한 운영 조작 Client. Message 송수신 용도가 아니다.
  • Partition
    • Topic의 대량의 메시지 입출력을 지원하기 위해, 하나의 Topic에 대한 대규모 데이터 수신과 전달을 지원.
    • Partition을 Broker에 배치하는 설정 필요.
    • Topic을 통해서만 기본적으로 Producer, Consumer와 통신이 가능하나, 특별한 경우 Partition을 지정가능.
  • Consumer Group
    • 분산 스트림 처리를 고려하여, 여러 Consumer가 단일 Topic이나 여러 Partition에서 Message를 취득하는 방법으로 사용.
    • Consumer Group에서 Global ID를 공유하여, Consumer가 자신의 Consumer Group을 식별해, 읽어드릴 Partion을 분류하고 재시도를 제어 함.

Kafka Offset

Offset은 Partition에 저장된 Message에 대한 위치 정보를 표시한다. 다양한 Offset이 있는데, 아래와 같다.

  • Log End Offset : Partition의 입력의 마지막 위치
  • Current Offset : Consumer가 읽은 위치. Consumer 데이터 취득 후 업데이트
  • Commit Offset : Consumer가 Commit한 위치. Consumer의 Commit 요청으로 업데이트.
  • High Watermark : 복제 구조에서 언급될 내용이지만, Partition의 복제인 Replica가 이뤄진 Log End Offset을 표시한다. Log End Offset보단 작은 수이며, Consumer는 High Watermark 까지만 Current Offset이 도달할 수 있다.

전반적으로 Offset 개념을 보면, Producer에 의해 새로운 Message가 전달되면, Partition에 Log End Offset이 증가되고, Consumer가 읽어 가면 Current offset이 증가하며, Consumer가 읽은 데이터가 처리되어 Commit 요청이 오면 Commit Offset이 증가된다.

이미 눈치를 챈 사람도 있겠지만, Commit Offset을 어떻게 제어하는가로 전달보증을 확실히 제어 할 수 있다. Commit Offset을 Auto으로 설정할 수도 있지만, 이로 인해 중복 메시지 발생이라는 끔찍한 사태도 일어날 수 있다.

Message 송수신 처리

Kafka에서 Message 송수신 처리에는 3가지의 전달 보증 수준을 제공한다. (Kafka에서는 수신이란 표현보다, 전달이란 용어를 사용해야 올바르다고 생각하지만, 문맥상 송수신으로 표현한다.)

종류개요재전송 유무중복 삭제 유무비고
At Most Once1회 전달 시도XX메시지 중복되지 않지만, 상실가능.
At Least Once적어도 1회 전달OX메시지가 중복될수 있지만, 상실 되지 않음.
Exactly Once1회만 전달OO중복되지도 않고, 상실되지도 않는다.

Offset에서 설명했듯이 “At Least Once”에서는 Producer – Broker(Partition) 간에 발생한 Log End Offset에 대한 Producer는 ACK를 명확히 처리 한다는 기준으로 상실되지 않음을 보장한다. (복제 구조 방식에서 다시 언급되어야 하나, ACK가 반환되는 시점에 대해 설정이 가능하다.)

Producer – Broker(Partition) 송신 : At Least Once 구조

“Exactly Once”는 Broker(Partition) – Consumer 간에 발생한 Commit Offset 증가 요청인 Commit 요청으로 중복 전달 되지 않음을 보장한다.

Broker(Partition) – Consumer 전달 : Exactly Once 구조

3. Kafka 분산 구조

Kafka의 핵심 키워드인 대용량, 실시간 처리에는 지금까지의 정리 수준에 약간의 시스템 디자인이 더해져서 분산 환경에서 처리되는 Kafka Cluster의 완벽한 구조가 설명된다.

Partitioning

Partition은 Topic에 대한 대규모 데이터 수신과 전달을 지원하며, 여러 Broker에 나눠진 Partition에 어떻게 보낼지 결정하는 방법을 제공하고 있는데, 이것을 Partitioning 이라고 한다.

일단, 위에서 잠시 언급한 Kafka Message는 Key, Value 구조로 되어 있으며, Key를 사용하여 hash 값으로 송신하는 방식과, Key 지정없이 Round-Robin으로 송신하는 방식으로 사용한다.

Message key-value
hash partitioning 으로 key가 편향되는 경우

hash 방식으로 Partitioning 시에는 위와 같이 특정 Partition으로는 Message가 전달되지 않을 수 있다. Key의 선정이 중요할 수 있다. Client IP 또는 일련번호의 뒷자리 등 활용방법을 직접 구현할 수 있다.

hash와 round-robin 방식의 Partitioning

Partitioning으로 분할처리가 되면, 상황에 따라 시스템 전송 시점과 수신 시점에서 순서가 편향정도에 따라 바뀔수 있다. 이와 같은 경우에 순서 보증을 위해 Key에 의한 순서 보증은 hash 방식이 조금더 유리할 수 있다.

복제 구조

Kafka 장애에 대비하여, Partition에 문제가 발생 되었거나 Partition의 Broker가 Crash 되었을 경우를 대비하여, Partition은 복제(Replication) 구조를 가지고 있다.

1 Topic, 1 Partition, 3 Replica 설정. (일반적으로 1 Partition은 사용하지 않음. 이해 용도)

Partition은 Replica를 1개 이상 지정 가능하며, 1개의 Leader와 그 외에는 Follower로 설정한다. Follower는 Leader로 부터 복제를 유지하는 형태로 동작하고, Producer, Consumer와 데이터 교환은 Leader만 한다.

복제 상태를 유지하고 있는 Replica는 In-Sync Replica(ISR로 표기)로 분류하고, 모든 Replica가 ISR로 되어 있지 않으면, Under Replicated Partitions라고 한다. ISR은 복제 설정시에 최소 수를 설정(min.insync.replica) 가능한데, 전체 복제가 이뤄지지 않은 일부 장애가 발생했을 경우에 이를 허용하고 계속하는 것을 가능하게 할 수 있다.

복제 상세 구조

위 그림은 Partition 1에 Replica 3으로 설정되어 있다고 볼수 있다. 새로운 Offset인 High Watermark 개념은 복제가 완료된 Offset을 의미하는데, 첫번째 Follower의 Log End Offset이 6에 포인팅한 것으로 보아 최소 ISR 수는 2로 볼수 있다. 만약 High Wartermark가 3을 포인팅 한다면, 최소 ISR수는 1이라고 할 수 있다.

만약, Message “6,5,4” 취득 이후, Leader 와 첫번째 Follower에 장애가 발생된다면, 해당 메시지는 다시 취득할 수 없다. 이는 최소 ISR 수를 2로 해서 3건의 Replica 중에 1건의 장애만 보장하겠다는 수준을 받지 못한 것이라고 볼 수 있다. 반대로 장애가 발생되지 않는다면, 복제가 다 이뤄지는 시간 대비 빠른 성능을 보장받는 설정이라고 볼수 있다.

또한, Prducer는 Broker로 전달함에 있어서, ACK 설정이 가능한다.

ACK 설정설명
0Producer는 Message 송신 시 Ack를 기다리지 않고 다음 Message를 송신.
1Leader Replica에 Message가 전달되면 Ack 반환
all모든 ISR의 수만큼 복제되면 Ack 반환
최소 ISR 수 : 3, Ack : all 설정

Broker 장애 발생에도 최소 ISR 수 3 설정에 따라, 모든 Replica가 복제에 도달해야 하며, 이때에만 Ack 가 전달 되기 때문에 Producer는 송신이 불가하다. 시스템 처리 보다 데이터 보존과 보장에 집중한 설계라고 볼 수 있다.

최소 ISR 수 : 2, Ack : all 설정

Broker 장애 발생에도 최소 ISR 수 2 설정에 따라, Replica는 2개 완료되었고, Ack all은 조건에 만족한 것으로 응답되어 Producer는 지속적으로 처리를 수행한다. 단, Broker 장애가 하나 더 발생될 경우에는 손실 위험이 발생된다.

4. 정리

이번 포스팅에서 핵심은 Kafka를 가지고 다양한 설계방법에 맞는 형태로 어떻게 써야 하는가를 위한 정리 과정이다. 명확하게 시스템의 구조를 이해함으로써, 앞으로 요구되는 구성 방식에 잘못된 사용형태가 되지 않길 바라기 때문이다.

다음 포스팅에는 실제 Kafka 코드를 다루는 것으로 진행해 보고자 한다. Kafka 관련해서는 인터넷에 많은 자료가 있지만, 사실 버전에 따라 이해하는 과정에서 난독이 되어 힘이 들기도 했다. 그런 의미에서 가장 최근에 발행된 책이 진리인 것 같다.

댓글 남기기

이 사이트는 스팸을 줄이는 아키스밋을 사용합니다. 댓글이 어떻게 처리되는지 알아보십시오.

%d 블로거가 이것을 좋아합니다: