[Kafka] 카프카 시작하기 2

현재 작성 중인 KAFKA 시리즈는 [카프카 핵심 가이드] 책을 보고 정리한 글임을 밝힙니다.

 

1.2 카프카 입문

아파치 카프카

• 카프카란
  • 비즈니스가 확장됨에 따라 함께 확장되는, 일반화된 유형의 데이터를 발행하고 구독할 수 있는 중앙 집중화된 시스템이 필요해져서 고안된 메시지 pub/sub 시스템임
  • '분산 커밋 로그' 혹은 '분산 스트리밍 플랫폼'이라고 불리기도 함
• 파일시스템이나 데이터베이스 커밋 로그와의 비교
  • 파일시스템이나 데이터베이스 커밋 로그
    • 모든 트랜잭션 기록을 지속성 있게 보존함으로써 시스템의 상태를 일관성 있게 복구할 수 있도록 고안됨
  • 카프카
    • 이와 유사하게, 카프카에 저장된 데이터는 순서를 유지한 채로 지속성 있게 보관되며, 읽을 수 있음
    • 확장시 성능을 향샹시키고 실패가 발생하더라도 데이터 사용에는 문제가 없도록 시스템 안에서 데이터를 분산시켜 저장할 수 있음

 

1.2.1 메시지와 배치

• 카프카에서 데이터
  • 단위: 메시지
    • 데이터베이스와의 비교
      • 데이터베이스
        • row나 record와 비슷해 보일 수 있음 (row나 record는 특정한 형식이나 의미가 있음)
      • 카프카
        • 단순히 바이트의 배열일 뿐 특정한 형식이나 의미가 없음
    • 메시지 저장 
      • 단위: 배치(batch)
      • 배치란?
        • 같은 토픽의 파티션에 쓰여지는 메시지들의 집합
        • 메시지를 배치 단위로 모아서 쓰면 오버헤드를 줄일 수 있음
          • but, 지연과 처리량 사이에 트레이드오프를 발생시킴
            • 배치 크기가 커질수록 시간당 처리되는 메시지의 수는 늘어나지만, 각각의 메시지가 전달되는 데 걸리는 시간은 늘어남
            • 따라서 배치는 더 효율적인 데이터 전송과 저장을 위해 약간의 처리 능력을 들여서 압축되는 경우가 많음
  • 특징: 키(key)
    • 키라 불리는 메타데이터 포함 가능
    • 키 역시 메시지와 마찬가지로 카프카 입장에서 특별한 의미가 없는 바이트 배열임
    • 메시지를 저장할 파티션을 결정하기 위해 사용됨
      
      • 가장 간단한 방법
        • 키값에서 일정한 해시값을 생성한 뒤 이 값을 토픽의 파티션 수로 나눴을 때 나오는 나머지 값에 해당하는 파티션에 메시지를 저장하는 것
        • 이렇게 하면 같은 키값을 가진 메시지는 파티션 수가 변하지 않는 한 항상 같은 파티션에 저장됨

 

1.2.2 스키마

• 필요성
  
  • 카프카 입장에서 메시지는 단순한 바이트 배열일 뿐이지만, 내용을 이해하기 쉽도록 일정한 구조(혹은 스키마)를 부여하는 것이 권장됨
  • 일관적인 데이터 형식이 중요
    • 메시지 쓰기와 읽기 작업을 분리할 수 있도록 해주기 때문
      • 이 작업들이 서로 결합되어 있다면 우선 메시지를 구독하는 애플리케이션들 먼저 구버전과 신버전 형식을 동시에 함께 지원할 수 있도록 업데이트되어야 함
      • 그 다음에야 메시지를 발행하는 애플리케이션이 신버전 형식을 사용하도록 업데이트 될 수 있음
      • 잘 정의된 스키마를 공유 저장소에 저장함으로써 카프카는 두 버전 형식을 동시에 지원하도록 하는 작업 없이도 메시지 처리 가능
• 메시지 스키마
  • JSON(JavaScript Object Notation) XML(eXtensible Markup Language)
    • 장점: 쓰기 쉽고 사람이 알아볼 수 있음
    • 단점: 타입 처리 기능이나 스키마 버전 간의 호환성 유지 기능이 떨어짐
  • 아파치 에이브로(Apache Avro)
    • 에이브로는 조밀한 직렬화 형식을 제공
    • 메시지 본체와 스키마를 분리하기 때문에 스키마가 변경되더라도 코드를 생성할 필요가 없음
    • 강력한 데이터 타이핑(typing)과 스키마 변경에 따른 상위 호환성, 하위 호환성을 지원함

 

1.2.3 토픽과 파티션

• 토픽(topic)
  
  • 카프카에 저장되는 메시지는 토픽 단위로 분류됨
  • 토픽과 비슷한 개념
    • 데이터베이스의 테이블
    • 파일시스템의 폴더
  • 토픽과 파티션
    • 토픽은 여러 개의 파티션으로 나뉨
• 파이션(partition)
  • 파티션이란
    • 커밋 로그의 관점: 하나의 로그에 해당
    • 카프카가 데이터 중복과 확장성을 제공하는 방법
      • 각 파티션이 서로 다른 서버에 저장될 수 있기 때문에 하나의 토픽이 여러 개의 서버로 수평적으로 확장되어 하나의 서버의 용량을 넘어가는 성능을 보여줄 수 있음
  • 특징
    • append-only
      • 파티션에 메시지가 쓰여질 때는 추가만 가능
    • 순서대로 읽힘
      • 읽을 때는 맨 앞부터 제일 끝까지의 순서로 읽힘
    • 일반적으로 순서 보장 X
      • 대개 토픽에 여러 개의 파티션이 있는 만큼 토픽 안의 메시지 전체에 대해 순서는 보장되지 않음
      • 예외
        • 단일 파티션 안에서만 순서 보장
    • 복제 가능
      • 서로 다른 서버들이 동일한 파티션의 복제본을 저장하고 있기 때문에 서버 중 하나에 장애가 발생한다고 해서 읽거나 쓸 수 없는 상황이 벌어지지는 않음

여러 개의 파티션을 갖는 토픽

• 스트림(stream): 메시지의 집합
  • 스트림이란
    • 대부분의 경우 스트림은 (파티션 개수와 상관없이) 하나의 토픽에 저장된 데이터로 간주
    • 프로듀서(producer)로부터 컨슈머(consumer)로의 하나의 데이터 흐름을 나타냄
  • 스트림 처리(stream processing)
    • 메시지의 집합을 스트림이라는 용어로 부르는 것은 카프카 스트림즈(Kafka Streams), 아파치 삼자(Apache Samza), 아파치 스톰(Apache Storm)과 같은 프레임워크에서 메시지를 실시간으로 처리하는 것처럼 스트림 처리에 대한 논의를 진행할 때 가장 일반적인 것
    • 이러한 방식의 처리는 데이터를 시간이 흐른 뒤 한꺼번에 대량으로 처리하는 하둡과 같은 오프라인 프레임워크과 대비됨

 

1.2.4 프로듀서와 컨슈머

• 카프카 클라이언트
  • 프로듀서(발행자, 작성자)
    • 새로운 메시지 생성
    • 프로듀서와 메시지
      • 메시지가 토픽에 쓰여지는 기본규칙
        • 메시지는 특정한 토픽에 쓰여짐
      • 일반적으로 프로듀서는 메시지를 쓸 때 토픽에 속한 파티션들 사이에 고르게 나눠서 쓰도록 되어 있음
      • 하지만 프로듀서가 특정한 파티션을 지정해서 메시지를 쓰기도 함
        • 방법1: 메시지 키와 파티셔너
          • 메시지 키(key)와 키값의 해시를 특정 파티션으로 대응시켜 주는 파티셔너(partitioner)를 사용해서 구현
          • 동일한 키 값을 가진 모든 메시지는 같은 파티션에 저장됨
        • 방법2: 커스텀 파티셔너
          • 메시지를 파티션으로 대응시켜 주는 규칙을 가진 커스텀 파티셔너 사용 가능
  • 컨슈머(구독자, 독자)
    • 메시지 읽음
    • 컨슈머와 메시지
      • 1개 이상의 토픽을 구독해서 여기에 저장된 메시지들을 각 파티션에 쓰여진 순서대로 읽어옴
      • 메시지의 오프셋(offset)을 기록함으로써 어느 메시지까지 읽었는지에 대한 정보 유지
        • 오프셋(offset)
          • 지속적으로 증가하는 정수값
          • 카프카가 메시지를 저장할 때 각각의 메시지에 부여해주는 또 다른 메타데이터
          • 주어진 파티션의 각 메시지는 고유한 오프셋을 가짐
            • 뒤에 오는 메시지가 앞의 메시지보다 더 큰 오프셋을 가짐
            • 파티션별로 다음 번에 사용 가능한 오프셋 값을 저장(대체로 카프카 자체에 저장됨)
              • 읽기 작업을 저장했다가 다시 시작하더라도 마지막으로 읽었던 메시지의 바로 다음 메시지부터 읽을 수 있음
    • 컨슈머 그룹(consumer group)
      • 컨슈머와의 관계
        • 컨슈머는 컨슈머 그룹의 일원으로서 작동
        • 컨슈머 그룹은 토픽에 저장된 데이터를 읽어오기 위해 협업하는 하나 이상의 컨슈머로 이루어짐
        • 컨슈머 그룹은 각 파티션이 하나의 컨슈머에 의해서만 읽히도록 함
      • 특징
        • 대량의 메시지를 갖는 토픽들을 읽기 위해 컨슈머들을 수평 확장할 수 있음
        • 컨슈머 중 하나에 장애가 발생하더라도 그룹 안의 다른 컨슈머들이 장애가 발생한 컨슈머가 읽고 있던 파티션을 재할당받은 뒤 이어서 데이터를 읽어올 수 있음
      • 소유권(ownership)
        • 컨슈머에서 파티션으로의 대응 관계는 컨슈머의 파티션 소유권이라고 부름
        • 예)
          • 컨슈머가 하나의 파티션만 읽어서 처리할 수도 있고
          • 두 개의 파티션을 읽어서 처리할 수도 있음

토픽을 읽는 컨슈머 그룹

 

• 고급 클라이언트 API도 있음
  • 고급 클라이언트들은 프로듀서와 컨슈머를 기본적인 요소로서 사용하며 좀 더 고차원적인 기능을 제공함
  •  종류
    • 카프카 커넥트(Kafka Connect) API
      • 데이터 통합에 사용됨
    • 카프카 스트림즈(Kafka Streams)
      • 스트림 처리에 사용됨

 

1.2.5 브로커와 클러스터

• 브로커
  • 브로커란
    • 하나의 카프카 서버
  • 역할
    • 프로듀서로부터 메시지를 전달받아 오프셋을 할당한 뒤 디스크 저장소에 쓰는 역할
    • 컨슈머의 파티션 읽기(fetch) 요청을 처리하고 발행된 메시지를 보내는 역할
  • 특징
    • 하나의 브로커는 초당 수천 개의 파티션과 수백만 개의 메시지를 쉽게 처리할 수 있음
    • 클러스터의 일부로서 작동하도록 설계됨
• 클러스터
  • 하나의 클러스터 안에 여러 개의 브로커가 포함될 수 있음
  • 그 중 하나의 브로커가 클러스터 컨트롤러의 역할 담당
    
    • 컨트롤러
      • 선정 방식
        • 컨트롤러는 클러스터 안의 현재 작동 중인 브로커 중 하나가 자동으로 선정됨
      • 역할
        • 파티션을 브로커에 할당
        • 장애가 발생한 브로커를 모니터링
  • 파티션과의 관계
    • 리더와 팔로워
      • 파티션 리더(partition leader)
        • 파티션은 클러스터 안의 브로커 중 하나가 담당 -> 이 브로커를 파티션 리더라고 부름
      • 파티션 팔로워(partition follower)
        • 복제된 파티션이 여러 브로커에 할당되는 것
          • 복제 기능: 파티션의 메시지를 중복 저장함으로써 리더 브로커에 장애가 발생했을 때 팔로워 중 하나가 리더 역할을 이어받을 수 있도록 함
    • 특징
      • 모든 프로듀서는 리더 브로커에 메시지를 발행해야 함
      • 컨슈머는 리더나 팔로워 중 하나로부터 데이터를 읽어올 수 있음

 

+ 추가

• 보존 기능
  • 보존 기능이란
    • 아파치 카프카의 핵심 기능 중 하나
    • 일정 기간 동안 메시지를 지속성 있게 보관하는 기능
    • 보존 설정은 어떤 시점에 있어서건 사용 가능한 최소한의 데이터 양을 정의함
  • 카프카 브로커와의 관계
    • 카프카 브로커는 토픽에 대해 기본적인 보존 설정이 되어 있음
      • 각각의 토픽에는 메시지가 필요한 정도까지만 저장되도록 보존 설정을 잡아줄 수 있음
      • 토픽에는 로그 압착(log compaction) 기능을 설정할 수도 있음
        • 같은 키를 갖는 메시지 중 가장 최신의 것만 보존됨
        • 마지막 변경값만이 중요한 체인지로그(change log) 형태의 데이터에 사용하면 좋음
    • 특정 기간 동안 메시지를 보존하거나 파티션의 크기가 특정 사이즈에 도달할 때까지 데이터를 보존함
    • 한도값에 도달하면 메시지는 만료되어 삭제됨

 

1.2.6 다중 클러스터

아직 이해는 잘 안됨 -> 9장에서 더 공부해봐야 이해될 듯함

• 다중 클러스터
  • 필요성
    • 다수의 클러스터를 운용하는 것이 더 나은 경우가 있음
  • 장점
    • 데이터 유형별 분리
    • 보안 요구사항을 충족시키기 위한 격리
    • 재해 복구(disaster recovery)를 대비한 다중 데이터센터
      • 카프카가 다수의 데이터센터에서 운용될 때는 데이터센터 간에 메시지를 복제해 줄 필요가 있음
      • 양쪽 데이터센터 모두에서 사용자 활동 정보를 사용할 수 있음
      • 카프카 클러스터의 복제 메커니즘은 다중 클러스터 사이에서가 아닌 하나의 클러스터 안에서만 작동하도록 설계됨
  • 미러메이커(MirrorMaker)
    • 데이터를 다른 클러스터로 복제하는 데 사용되는 툴
    • 미러메이커도 큐로 연결된 카프카 컨슈머와 프로듀서에 불과함
    • 하나의 카프카 클러스터에서 메시지를 읽어와서 다른 클러스터에 씀