Kafka & Confluent

kafka : 데이터를 전송해주는 메시징 플랫폼. 동시에 데이터를 실시간으로 처리하는 플랫폼

• 분산 트랜잭션 로그로 구성된 확장 가능한 Pub/Sub 메시지 큐에 저장 기능이 포함된 것.
• pub/sub 데이터 모델
  
  
  • producer : kafka에 데이터를 입력하는 클라이언트
    • producer는 broker 중 하나의 topic만을 대상으로 데이터 입력
    • topic의 파티션에 메시지를 송신할 때 프로듀서의 메모리를 사용하여 버퍼처럼 모아서 송신함
    • 동일한 파티션에 보내기 위해서는? 메시지의 key-value 구조를 활용함. 동일한 key값을 가진 메시지를 동일한 id를 가진 파티션에 송신한다. 메시지 key를 지정하지 않는다면 메시지 송신은 Round-Robin 방식으로 수행됨
  • broker cluster : topic이라고 불리는 데이터 관리 유닛을 임의 개수만큼 호스팅하는 클러스터
    • partition : 브로커 상의 데이터를 읽고 쓰는 단위
    • 서버 인스턴스 하나당 하나의 데몬 프로세스로 동작. 여러 대의 클러스터로 구성함으로써 throughput 향상 및 scaling이 가능해짐
    • 브로커가 받은 데이터는 모두 디스크로 내보내져야 함(영속화) -> 디스크의 총 용량에 따라 데이터 보존 기간이 정해짐
  • consumer : kafka에서 데이터를 가져오는 클라이언트
    • consumer group : 컨슈머 하나는 하나의 consumer group에 속함.
      • 수신한 메시지는 consumer group 내의 하나의 consumer가 수신받으며, 이후 consumer 사이에서 분산되어 전달됨.
      • 메시지 매핑은 partition과 consumer group을 매핑하여 가능함.
      • 메시지 분산 수신을 위해서는 (파티션 수 > 컨슈머 그룹 내 컨슈머)가 되어야 하며, 만족되지 않을 경우 파티션이 할당되지 않은 consumer가 발생할 수 있음
        
    • 데이터를 가져올 topic을 지정한 후 해당 topic에서 데이터를 가져옴
    • 하나의 topic에 여러 개의 consumer가 각각 다른 목적으로 존재
    • topic에 입력된 데이터는 여러 consumer가 서로 다른 처리를 위해 여러 번 가져올 수 있음
  • message : kafka에서 다루는 데이터의 최소 단위. key-value를 가지며 메시지 전송시 파티셔닝에 이용됨
  • topic : 메시지를 종류별로 관리하는 스토리지. broker에 배치되어 관리된다. 단일 카프카 클러스터에서 여러 종류의 메시지를 중계함

kafka 요청 처리 방식

• kafka가 요청을 처리할 때 두 개의 스레드 레이어를 사용
  • 네트워크 스레드 : 클라이언트와의 이벤트 기반 비동기 I/O 처리를 수행
  • 요청 핸들러 스레드 : 네트워크 스레드가 가져온 요청을 내용을 처리해서 필요한 응답 객체를 네트워크 스레드에 반환

디스크 영속화

• 카프카는 디스크 영속화를 하면서도 높은 처리량을 제공
• 데이터를 받아들이면서 장기 보존을 목적으로 영속화
• 메시지를 잃지 않는 전달 보증으로 ACK와 Offset Commit 개념이 도입됨
  • ACK : 브로커가 메시지를 수신하였을 때 프로듀서에게 수신 완료했다는 응답
  • Offset Commit : 컨슈머가 브로커로부터 메시지를 받을 때 컨슈머가 어디까지 받았는지 관리
• 카프카만 가지고는 데이터 유통만 가능.
• 각종 애플리케이션을 붙이기 위한 커넥터, proxy, 실시간 테이블 처리을 위한 ksqlDB 등을 지원하는 Confluent
• Confluent는 Apache Kafka에 대한 commit의 80% 이상을 담당

Confluent

• Confluent는 Kafka의 창시자가 설립
• 설치형 서비스 및 SaaS 서비스 제공
• 실시간 모니터링 툴 제공

마이크로서비스

• 대표적인 것이 넷플릭스 아키텍처: 각 서비스간 연결이 중요하지만, 많아질수록 복잡해짐
  
• 이벤트 기반 마이크로서비스에서 중요한 것이 event bus인데, confluent가 해당 역할을 함
  

Reference

• Line에서 Kafka를 사용하는 방법
• Apache Kafka - 높은 처리량과 실시간으로 대량의 데이터를 취급하는 카프카
• Kafka Technical Overview

엘라스틱서치

• 엘라스틱서치는 검색 엔진인 Apache Lucene으로 구현한 RESTful API 기반의 검색 엔진
• 엘라스틱서치 내에 저장된 데이터를 Index라고 부르며, 각 인덱스는 한 개 이상의 샤드로 구성되어 있음
• 샤드는 Lucene 인덱스를 뜻하며, Lucene 인덱스는 엘라스틱서치 클러스터 내에서 인덱싱 및 데이터 조회를 위한 독립적인 검색엔진이다.

• 데이터를 샤드에 입력할 때, 엘라스틱서치는 주기적으로 디스크에 immuatable한 Lucene segment 형태로 저장하며, 이 작업 이후에 조회가 가능.
  • 이 작업을 리프레쉬(Refresh)라고 부름
  • 샤드는 한 개 이상의 segment로 구성
    
• segment 개수가 많아지면, 주기적으로 더 큰 segment로 병합된다. (Merge)
  • 모든 segment는 immutable하기 때문에, 병합되는 segment가 삭제되기 이전에, 새로운 segment를 생성.
  • 따라서 디스크 사용량에 변화가 생김. 병합 작업은 디스크 I/O 등 리소스에 민감하다.

단점

• 분산처리를 통해 실시간으로 처리하는 것으로 보이지만, 내부적으로 commit, flush 등의 작업을 거치므로 실시간은 아니다.
• 트랜잭션, Rollback을 지원하지 않음 (클러스터의 성능을 위해)
• 데이터의 업데이트를 지원하지 않음. 업데이트 명령이 오면 기존 문서를 삭제하고 새로운 문서 사용
  • 대신에 Immutable하다는 장점이 있다.
  • Segment가 Immutable한 이유는 캐싱 때문이다. Lucene은 읽기 속도를 높이기 위해 OS의 파일시스템 캐싱에 의존하고 있음. 빠른 액세스를 위해 hot segment를 메모리에 상주하게 유지시키는 식으로 작동한다. 참고

Reference

• https://www.elastic.co/kr/blog/how-many-shards-should-i-have-in-my-elasticsearch-cluster