Kafka 기초 다지기

출처 : 카프카 핵심 가이드 (O’Reilly)

목차

1. 카프카 훑어보기
2. 범용 메시지 큐와 비교하기
3. 카프카 프로듀서 : 카프카에 메시지 쓰기
4. 카프카 컨슈머 : 중요 개념
5. 카프카 컨슈머 : 카프카에서 데이터 읽기
6. 스키마 레지스트리
7. 카프카 내부 메커니즘
8. 신뢰성 있는 데이터 전달

9. 데이터 파이프라인 구축하기

   • 데이터 파이프라인 구축 시 고려사항
   • 카프카 커넥트와 프로듀서 컨슈머
   • 카프카 커넥트 실행하기
   • 구성 요소
   • 대안

• confluent 예제
• schema registry 예제

데이터 파이프라인 구축하기

1. 데이터 파이프라인 구축 시 고려사항

1) 데이터 파이프라인 (data pipeline) 이란?

• 서로 다른 여러 시스템 간의 데이터 이동/흐름

• 효율적으로 구축하면 → 서로 다른 시스템 간의 데이터 전달과 통합을 효율적으로!

• 카프카를 사용한 파이프라인

  1. Kafka가 두 개의 엔드포인트 중 하나가 되는 경우
  2. Kafka를 중개 역할로 사용하는 경우

• [TIP] : 데이터 통합 문제에 직면했을 때, 당장 필요한 엔드포인트만 생각하지 말고 더 큰 관점을 고려하자

  • 단기적인 데이터 통합에만 치중하면 복잡하고 유지보수 비용만 많이 드는 결과를 초래한다.

2) 적시성

• 하루에 한 번 대량으로 데이터를 받는 배치 처리 시스템도 있고,

• 데이터 생성 즉시 수 밀리초 안에 받아야 하는 실시간 처리 시스템도 있다.

• 확장성과 신뢰성이 있는! 스토리지를 갖춘! 스트리밍 데이터 플랫폼인 Kafka는!

  • 실시간 파이프라인부터 시간 단위의 배치 파이프라인까지 모든 것을 지원하는 거대한 버퍼가 될 수 있다.
  • 데이터 쓰기와 읽기가 분리되어 있기 때문!

3) 신뢰성

• 단일 장애점 (Single Point Of Failure, SPOF) : 한 부분에 발생한 장애가 모든 시스템에 영향을 미치는 것

  → 신뢰성을 높이기 위해선 SPOF를 피하고, 모든 종류의 장애 발생 시 신속하고 자동화된 복구를 해줘야 한다!

• 데이터 전달 보장

  • 최소 한 번 (at-least-one)

    • 데이터를 보내는 소스 시스템으로부터 대상 시스템까지 하나도 빠짐없이 데이터가 전달 → 유실 X
    • 재전송으로 인해 중복 데이터가 생길 수 있음
    • Kafka는 자체적으로 ‘최소 한 번’ 데이터 전달을 제공한다.

  • 정확히 한 번 (exactly-once)

    • 데이터를 보내는 소스 시스템으로부터 대상 시스템까지 모든 데이터가 전달 → 유실 X
    • 데이터의 중복도 생기지 X

4) 처리량

• 매우 높은 처리량 (throughput)을 갖도록 확장될 수 있어야 하고, 불시에 처리량이 증가해도 조정할 수 있어야 한다!
• Kafka는 데이터를 쓰는 프로듀서와 읽는 컨슈머 간의 버퍼 역할을 한다.
  • 컨슈머의 처리량을 프로듀서의 처리량과 연관시키지 않아도 된다.
  • 프로듀서의 처리량이 컨슈머의 처리량을 초과하면, 프로듀서가 쓴 데이터는 컨슈머가 읽을 수 있을 때까지 보존
• 파이프라인의 프로듀서든 컨슈머든 어느 쪽으로든 동적으로 확장하기 쉽다.
• 카프카 커넥트 API를 사용하면 다중 스레드를 사용한 병행 처리도 가능하다

5) 데이터 형식

• 데이터 파이프라인에서, 서로 다른 데이터 형식을 조화시키는 것은 매우 중요하다!

  Ex) Kafka에서 Avro로 쓴 메시지를 Elasticsearch에는 JSON으로 써줘야 한다.

• Kafka 자체와 커넥트 API는 데이터 형식에 구애받지 않는다.

  • 프로듀서와 컨슈머는 다양한 직렬처리기를 사용한다.
  • 카프카 커넥트는 데이터 형식과 스키마를 포함하는 메모리 객체들을 가진다.
    • 변환기를 사용해 어떤 형식으로도 데이터를 저장할 수 있게 해준다.

• 많은 소스 (source)와 싱크 (sink)는 데이터 구조를 나타내는 스키마 (schema)를 갖는다.

  → 소스로부터 데이터와 함께 스키마를 읽어 저장한 후, 호환성을 검사하거나 싱크 데이터의 스키마를 변경할 수 있음!

  • 소스 : 데이터를 제공하는 쪽
  • 싱크 : 데이터를 전달 받는 쪽

• 범용적인 데이터 파이프라인을 제공하는 통합 프레임워크에서는 다양한 소스의 싱크와 서로 다른 동작에 따른 차이점도 처리할 수 있어야 한다!

6) 변환

• ETL (추출-변환-적재, Extract-Tranform-Load)

  1. 서로 다른 소스 시스템에서 데이터를 가져와서 (추출)
  2. 적절한 형식이나 구조로 변환한 후 (변환)
  3. 다른 시스템으로 저장 (적재) 하는 것!
  • 특징
    • 데이터를 파이프라인에서 변환해줘야 한다.
    • Pros : 파이프라인에서 데이터를 보존할 필요 없이 변환한 후 전달만 하면 되므로 시간, 스토리지를 절약한다
    • Cons : 데이터를 받아 처리하는 아랫단의 앱의 유연성이 떨어진다

• ELT (추출-적재-변환, Extract-Load-Transform)

  • 대상 시스템에 전달되는 데이터가 가능한 한 소스 데이터와 유사하게 되도록 하기 위해

    • 데이터 파이프라인에는 최소하의 변환만 수행한다!

  • 대상 시스템에서는 원시 (raw) 데이터를 받게 되고, 모든 변환도 수행한다.

  • 특징

    • Pros : 대상 시스템에게 최대한의 유용성 제공 → 가공되지 않는 모든 데이터 사용
    • Cons : 대상 시스템의 CPU와 스토리지가 부담된다.

7) 보안 및 장애 처리

• 파이프라인을 거쳐 가는 데이터가 암호화되는 걸까?
• 파이프라인을 수정할 수 있도록 허용된 사람은 누구인가?
• 접근이 제어된 시스템에서 데이터를 파이프라인으로 I/O할 때, 인증 기능을 올바르게 쓰는가?

→ Kafka는 암호화된 데이터 전송을 허용하고,

→ SASL (Simple Authentication and Security Layer) 인증을 지원한다!

• 모든 데이터가 항상 완전할 것으로 생각하면 안된다!
• 잘못된 데이터가 파이프라인으로 유입되는 것을 방지해야 하고,
• 분석될 수 없는 데이터를 복구해야 한다.

9) 결합과 민첩성

• 데이터를 제공하는 소스와 데이터를 받아 사용하는 대상을 분리하는 것은 굉장히 중요하지만… 결함이 생길 수 있다.
• 임기응변식 파이프라인 : 데이터 파이프라인의 역할을 수행하는 커스텀 앱들이 특정 엔드포인트와 강하게 결합
  • Ex. Logstash 로 로그 데이터를 Elasticsearch에…
• 메타데이터 유실 : 데이터 파이프라인이 스키마 메타데이터를 보존하지 않고 스키마 진화를 허용하지 않으면…
  • 소스 시스템과 대상 시스템 간 강한 결합이 생겨버린다!
• 과도한 처리 : 파이프라인에서 너무 많은 처리를 하면 후속 시스템에 결속되는 점들이 많아진다.
  • Ex. 어떤 필드를 보존할지, 데이터 집계를 어떻게 할지 등등 …
  • 가능한 한 원시 데이터의 형태로 많이 보존하고, 후속 앱이 스스로 결정할 수 있게 해주자.

2. 카프카 커넥트와 프로듀서 컨슈머

1) 둘 중 하나를 선택해야 할 때

• 프로듀서와 컨슈머는 Kafka 애플리케이션에 포함되는 클라이언트이다.

  • 애플리케이션에서 Kafka에 데이터를 쓰거나 읽을 수 있게 해준다.
  • 그럼 언제?
    1. Kafka 클라이언트 애플리케이션을 연결하기 원하는 외부 애플리케이션 코드를 변경할 수 있을 때
    2. Kafka에 데이터를 쓰거나 읽기를 원할 때

• 카프카 커넥트는?

  1. 코드를 작성하지 않았고, 변경도 할 수 없는 모든 외부 시스템에 Kafka를 연결할 때

     Ex. 각종 DB, 아마존 S3, 하둡 HDFS, Elasticsearch …

  2. 외부 시스템의 데이터를 읽어 Kafka로 쓰거나, Kafka에서 데이터를 읽어 외부 시스템에 쓸 때 사용!

3. 카프카 커넥트 실행하기

1) 실행 방법

• 카프카 커넥트와 커넥트 API는 Kafka에 포함되어 배포된다.

• 속성 파일을 전달해 시작 스크립트를 실행시킨다.

  # bin/connect-distributed.sh config/connect-distributed.properties

2) 커넥트 작업 프로세스의 핵심 속성

• bootstrap.servers : 커넥트와 함께 동작하는 Kafka 브로커의 리스트
• group.id : 같은 그룹 ID를 갖는 모든 커넥트 작업 프로세스는 같은 커넥트 클러스터의 일부가 된다
• key.converter, value.converter : 커넥트를 Kafka에 저장된 여러 형식의 데이터를 처리할 수 있다
  • Kafka에 저장되는 메시지의 Key와 Value 부분에 대한 컨버터를 설정한다.
  • Ex. JSONConverter, AvroConverter …
• key.converter.schemas.enable=true (Value도 동일)
• key.converter.schema.registry.url (Value도 동일)
  • 스키마가 존재하는 경우 포함 여부와 스키마 레지스트리의 위치를 설정해줄 수 있다.

4. 카프카 커넥트의 구성 요소

1) 커넥터

• 커넥터에서 얼마나 많은 태스크가 실행되어야 하는지 결정한다.
• 데이터 복사 작업을 각 태스트에 어떻게 분담할지 결정한다.
• 작업 프로세스로부터 태스크의 구성 정보를 얻는다.

2) 태스크

• 카프카의 데이터를 실제로 입출력하는 책임을 가진다.
• 소스 태스크 : 외부 시스템의 데이터를 읽어 레코드들의 리스트를 반환
• 싱크 태스크 : 작업 프로세스를 통해 카프카의 레코드들을 받아 외부 시스템에 씀

3) 작업 프로세스

• 커넥터와 태스크를 실행하는 컨테이너 (container) 프로세스

• 커넥터와 커넥터의 구성을 정의하는 HTTP 요청을 처리하는 책임을 가진다!

• 커넥터 구성을 저장하고, 커넥터와 태스크를 시작시킨다.

• 차이점

  • 커넥터와 태스크는 데이터 통합의 ‘이동되는 데이터’ 부분만 처리한다.
  • 반면, 작업 프로세스는 REST API, 구성 관리, 신뢰성, 가용성, 확장성, 부하 분산 등 모든 작업을 처리한다…

4) 컨버터

• 커넥트 API에는 데이터 객체와 객체의 구조를 나타내는 스키마 모두를 갖는 데이터 API가 포함된다.
• 소스 커넥터: 소스 시스템으로부터 데이터를 읽어서 한 쌍의 스키마 값을 생성한다.
• 싱크 커넥터 : 한 쌍의 스키마 값을 읽어 해당 스키마를 사용해 값을 분석하고 대상 시스템에 쓴다.
• 컨버터는 작업 프로세스를 구성할 때 선택하며, Kafka에 데이터를 저장하기 위해 사용된다.
• 종류 : Avro, JSON, String

5) 오프셋 관리

• 작업 프로세스가 커넥터를 위해 수행하는 편의 서비스 중 하나…

• 커넥터는 자신이 이미 처리했던 데이터가 어떤 것인지 알아야 한다.

  • 소스 커넥터의 return 값에는 논리 소스 파티션과 소스 오프셋이 포함된다.

  → 커넥터가 다시 시작되거나 중단될 때, 최근에 저장하던 데서부터 재개할 수 있게 된다.

5. 카프카 커넥트의 대안

1) 다른 데이터스토어의 프레임워크

• Kafka가 굳이 중심이 아닐 경우에는…
• Hadoop이나 Elasticsearch 같은 시스템에는 나름의 데이터 처리 (수집, 통합, 전달) 도구를 가지고 있다.
  • Hadoop의 Flume, Elasticsearch의 Logstash나 Beats
• Kafka가 아키텍처의 핵심 부분이라면 카프카 커넥트 API를, 그게 아니면 제공하는 거 갖다 쓰는게 좋다고 함!

2) GUI 기반의 ETL 도구들

• Infomatica, Talend, Pentaho, Apache NiFi, StreamSets …
• Cons : 이런 애들은 필요 이상의 복잡성을 갖는 경우가 많다.

3) 스트림 프로세싱 프레임워크

• 대부분 스트림 프로세싱 프레임워크에서는 Kafka의 데이터를 읽어 다른 대상 시스템에 쓸 수 있다.
• 이럴 경우에는 데이터 통합도 같은 프레임워크를 사용하는 게 좋다.
• Pros : 스트림 프로세싱 워크플로에서 레이어를 하나 줄일 수 있다
• Cons : 유실이나 손상된 데이터와 같은 문제를 해결하기 어려워진다.