[kafka] Apache Kafka 구경하기 - (1)

June 28, 2021

📧📧📧📧📧📧📧📧

분산 시스템의 일반적인 문제중 하나는 여러 소스에서 지속적으로 유입되는 데이터를 처리하는 것이다. 서로 다른 소스에서 초당 수백개의 로그 항목을 수집해야 한다. 이 로그 집계 서비스의 기능은 이러한 로그를 공유 서버 스토리지에 저장하고 나중에 로그를 검색할 수 있도록 인덱스를 구축하는 것이다. 이 서비스의 몇가지 과제는 다음과 같다.

순간적으로 급증하는 메세지를 어떻게 처리할 것인가?
서비스가 초당 500개의 메세지를 처리할 수 있는 경우 초당 더 많은 수의 메세지를 수신하기 시작하면 어떻게 되는가?
로그 집계 서비스가 여러 인스턴스를 가지는 경우 인스턴스간 작업의 분배는 어떻게 할 것인가?
다양한 유형의 소스에서 메세지를 받으려면 어떻게 해야하는가?
로그 집계 서비스가 잠시 중단되거나 응답하지 않는 경우, 로그 메세지는 어떻게 처리되는가?

이러한 로그 생성/소비(produce, consume)하는 소스는 로그 집계 서비스에 로그 메세지를 보내기위해 공통 프로토콜 및 데이터 형식을 지정해야 한다. 이것은 로그 메세지의 생산자와 소비자 사이에 강력하게 결합된 아키텍쳐로 구성된다. 위의 시나리오를 효율적으로 관리하기 위해 분산 시스템은 메세징 시스템에 의존하게 된다.

메세징 시스템

메세징 시스템은 서비스, 응용, 프로세스 또는 서버간 데이터를 전송하는 역할을 한다. 이러한 시스템은 발신자와 수신자에 메세징을 전송하는 비동기 방식을 제공하여 분산 시스템의 여러 부분을 분리하는데 도움이 된다. 따라서 모든 생성자와 소비자는 데이터를 공유하는데 사용하는 메커니즘에 대해 걱정하지 않고 메세지에 집중할 수 있게된다.

메세지를 처리하기 위해서 두가지 일반적인 방법이 있다.

Queue

큐잉 모델에서는 메세지는 큐에 순차적으로 저장된다. 생산자는 메세지를 대기열 뒤쪽으로 푸쉬하고 소비자는 대기열의 앞쪽에서 메세지를 추출한다. 특정 메세지는 최대 한명의 소비자만 사용할 수 있다. 소비자가 메세지를 가져오면 큐에서 제거되어 다음 소비자가 다음 메세지를 받게 된다. 이것은 여러 소비자에게 메세지 처리를 배포하기위한 훌류한 모델이다. 그러나 이것은 또한 여러 소비자가 대기열에서 동일한 메세지를 읽을 수 없기 때문에 시스템을 제한한다.

발행-구독 모델에서는 메세지는 주제topic으로 나뉜다. 생산자는 해당 topic에 대해 메세징 시스템에 저장되는 topic에 메세지를 보낸다. 소비자는 topic을 구독하여 해당 topic에 게시된 모든 메세지를 수신한다. 큐잉 모델과 달리 발행-구독 모델에서는 여러 소비자가 동일한 메세지를 받을 수 있다. 두 소비자가 동일한 주제를 구독하면 해당 주제에 게시된 모든 메세지를 받게된다.

메세지를 저장하고 유지하는 메세징 시스템을 일반적으로 메세지 브로커라고 한다. 이것을 통해서 데이터 생산자와 소비자간 느슨한 결합을 제공한다.

메세지 브로커는 게시된 메세지를 대기열에 저장하고 소비자는 대기열에서 메세지를 읽는다. 따라서 생산자와 소비자를 동기화할 필요가 없다. 이런 느슨한 결합을 통해 생산자와 소비자는 서로 다른 속도로 메세지를 읽고 쓸 수 있다. 메세징 시스템의 메세지 저장 기능은 내결함성을 제공함으로 생선된 시간과 소비된 시간 사이에 메세지가 손실되지 않는다.

요약하자면 다음과 같은 이유로 메세지 시스템이 어플리케이션 스택에서 사용된다.

메세지 버퍼링 - 메세지 처리 이전에 버퍼링 메카니즘을 제공한다. 이를 통해 시스템은 처리 준비가 될 때가지 일시적으로 데이터를 저장하여 워크로드 급증을 안전하게 처리할 수 있다. 메세지 전송 보장 - 생성자가 메세지를 게시할 때 소비하는 응용프로그램이 메세지를 받을 수 없는 경우 메세지가 결국 배달될 것이라는 확신을 가지고 메세지를 게시할 수 있다. 추상화 제공 - 메세징 시스템은 메세지 소비자와 메세지를 생성하는 응용 프로그램 간 구조적 분리를 제공한다. 확장성 제공 - 많은 생산자가 여러 소비자에게 메세지를 전달할 수 있도록 유연하고 고도로 구성 가능한 아키텍쳐를 제공

Kafka란?

오픈소스 기반의 발행-구독 기반 메세징 시스템이다. 분산되고 내구성이 있으며 내결함성이 있어 설계 상 고도로 확장가능하다. 기본적으로 생산자라고 하는 애플리케이션에 대해서 메세지 스트림을 가져와 클러스터로 구성된 메세지 브로커로 저장하고 메세지를 처리하는 애플리케이션이 이러한 메세지를 수신할 수 있도록 하는 시스템이다.

Kafka는 2010경 LinkedIn에서 다양한 이벤트를 추적하기 위해 만들어졌다. 나중에 오픈소스가 되었고 아래와 같은 용도로 포괄적으로 사용하게 된다.

엄청난 양의 데이터를 안정적으로 저장 서로 다른 엔티티간 메세지 전송 처리량을 향상 실시간 데이터 스트리밍 높은 수준에서 kafka를 분산된 커밋로그라고 부를 수 있다. 커밋로그(WAL, 트랜잭션로그)는 일련의 레코드를 지속저긍로 저장할 수 있는 추가 전용 데이터 도구이다. 레코드는 항상 로그 끝에 추가되며 한번 추가되면 레코드를 삭제하거나 수정할 수 없다. 커밋 로그에서 읽기는 항상 왼족에서 오른쪽으로 발생한다. 카프카는 메세지를 디스크에 저장한다 모든 읽기 쓰기작업이 순차적으로 이루어지기 때문에, 디스크의 순차 읽기의 장점을 활용할 수 있다.

kafka 사용 사례

kafka는 빅데이터 수집 및 실시간 분석에 사용할 수 있다.

metric - kafka를 사용하여 모니터링 정보를 수집하고 집계할 수 있다. 분산 서비스는 다양한 운영 메트릭을 kafka 서버에 푸시할 수 있다. 그런 다음 이러한 메트릭을 kafka에서 가져와 집계된 통계를 생성할 수 있다. log aggregation - kafka를 사용하여 어러 소스에서 로그를 수집하고 여러 소비자가 표준 형식으로 사용할 수 있다. stream processing - 수집된 데이터가 여러 단계에서 처리되는 스트림 처리에 유리하다. 예를들어 특정 topic에서 소비된 원시데이터는 변환/집계되어 새로운 소비를 위해 새로운 topic으로 생성된다. commit log - kafka는 모든 분산시스템에 대한 외부 커밋로그로 사용할 수 있다. 분산 서비스는 트랜잭션을 kafka에 기록하여 무슨일이 일어나고 있는지 추적할 수 있다. 이 트랜잭션 데이터는 노드간 복제에 사용될 수 있으며 외부 시스템이 해당 분산 시스템이 장애가 발생한 경우 장애 복구에도 유용하다. website activity tracking - kafka의 원래 사용중 하나는 사용자 활동 추적 파이프라인을 구축하는 것이다. click-stream, 키워드 검색 등과 같은 사용자 활동은 kafka의 별도의 topic으로 저장된다. 이러한 주제는 실시간 처리 실시간 모니터링, 오프라인 처리 및 보고를 위해 hadoop 또는 데이터 하우징 시스템에 로드하는 등 다양한 사용 사례에 대한 구독에 사용할 수 있다. product suggestion - 고객이 구매에 관심을 가질만한 유사 제품을 제안하는 유사 상품 기능을 제공하는 amazon 같은 온라인 쇼핑 사이트는, 사용자 활동을 kafka에 기록할 수 있다. 그런다음 소비자 애플리케이션은 이러한 메세지를 읽고 실시간으로 고객에게 표시할 수 있는 관련 제품을 찾을 수 있다. 또는 모든 데이터가 kafka에 지속됨으로 시스템에서 수집한 유사 제품 정보에 대해 배치작업을 통해 고객을 위한 상품추천 메일을 전송할 수 있다.

Kafka 아키텍쳐 개요

Kafka 용어정리

브로커 Broker

Kafka서버는 브로커라고도 한다. 브로커는 생산자Publisher가 제공한 데이터를 안정적으로 저장하고 소비자Consumer에게 전달할 책임을 가지고 있다.

레코드 Records

Kafka의 레코드는 브로커에 저장되는 메세지/이벤트 이다. 본질적으로 Kafka를 통해 Producer에서 Consumer로 이동하는 데이터이다. 레코드는 다음과 같이 구성되어 있다.

{key, value, timestamp, metadata headers}

토픽Topics

Kafka는 메세지를 Topic이라는 범주로 나눈다. 간단히 말해 Topic은 DB의 테이블과 같고 레코드는 해당 테이블의 행과 같다.

Kafka가 Producer로 부터 받은 각 레코드는 토픽과 연결된다. Consumer는 해당 토픽에 대해 새 메세지가 추가될 때 알림을 받기 위해 Topic에 대해 구독할 수 있다. 토픽에는 메세지를 읽는 여러 Consumer가 있을 수 있다. Kafka 클러스터 안에서 Topic은 이름으로 식별되기 때문에 고유값을 가져야 한다. Topic 내의 메세지는 필요한 만큼 읽을 수 있다. 기존 메세지 시스템과 달리 메세지가 소비 후 삭제되지 않는다. 대신 Kafka는 메세지의 보관 기관 또는 설정한 스토리지 크기 만큼 메세지를 보관한다. Kafka의 성능은 데이터 크기와 관련하여 효과적으로 일정함으로 장기간 데이터를 완벽하게 관리한다.

생산자Producer

생산자는 Kafka에 레코드를 생산하는 어플리케이션을 의미한다.

소비자Consumer

소비자는 kafka 토픽을 구독(읽기처리)하는 어플리케이션이다. 소비자는 하나 이상의 토픽을 구독하고 브로커에서 데이털르 가져와 게시된 메세지를 소비한다. Kafka에서 생산자와 소비자는 완전히 분리되고 서로 신경쓰지 않는다. 이는 Kafka가 높은 확장성을 달성하기 위한 핵심 디자인 요소이다.

아키텍쳐 개요

높은 수준에서 생산자는 kafka 브로커에 메시지를 보내고 이러한 메세지는 소비자라고 하는 다른 애플리케이션에서 읽는다. 메세지는 주제에 저장되고 소비자는 주제를 구독하여 새 메세지를 받는다.

Kafka 클러스터

Kafka는 하나 이상의 서버로 구성되며, 그 서버 각각은 Kafka 브로커를 수행한다.

Zookeeper

Zookeeper는 분산 key-value 저장소로 설정이나 코디네이션 정보를 저장하기 위해서 사용된다. 이것은 읽기 연산에 특화되어 있다. Kafka는 Zookeeper를 통해서 kafka broker 간의 코디네이션을 수행한다. Zookeeper는 Kafka cluster 내의 메타 정보를 관리한다. 상세한 내용은 뒤에서 더 자세히 알아보자.