[카프카인액션] 8장. 카프카 스토리지 | 아파치 볼륨 | 레드햇 데베지움 | 람다 아키텍처 | 카파 아키텍처

8장. 카프카 스토리지

8.1 데이터 저장기간 

• 현재 카프카 토픽 데이터의 기본 보존기간 제한은 7일이다. 
  • 로그 보존기간 제한을 비활성화하고 영원히 유지하려면 log.retention.bytes와 log.retention.ms를 모두 -1로 설정하면 데이터 삭제를 끌 수 있다. 

키	목적
log.retention.bytes	로그 삭제를 위한 최대 크기 임곗값(바이트 단위)
log.retention.ms	로그 삭제 전 유지 시간 (밀리초 단위)
log.retention.minutes	로그 삭제 전 유지 시간(분 단위). log.retention.ms가 함께 설정되어 있따면 log.retention.ms가 사용된다.
log.retention.hours	로그 삭제 전 유지 시간(시간 단위)가 log.retention.ms와 log.retention.minutes 중 어느 하나가 설정되어 있다면, log.retention.ms나 log.retention.minutes가 사용된다.

 

• 또 다른 옵션은 keyed 이벤트를 사용해 최신값에 대해 유사한 보존기간을 얻을 수 있는 방법이다. 
  • 컴팩션 정리 중에 여전히 데이터를 제거할 수 있지만 가장 최근의 keyed 메시지는 항상 로그에 있다. 
  • 이는 키가 현재 값에서 상태를 어떻게 변경했는지에 대한 모든 이벤트가 필요하지 않는 사용 사례에서 데이터를 유지할 수 있다. 
• 잠시 동안만 데이터 유지하고 싶지만, 브로커에 데이터 보관할 디스크 공간이 충분하지 않다면, 데이터를 카프카 외부로 이동하고 카프카 브로커에서 유지하지 않는 방식이다. 
  • 카프카에서 보존기간에 따라 데이터가 제거되기 전에 데이터를 다른 데이터베이스에 저장할 수 있따. 
  • HDFS(하둡 분산 파일시스템) 또는 이벤트 메시지를 클라우드 저장소 같은 곳에 업로드한다. 

 

8.2 데이터 이동 

카프카는 데이터 파이프라인에서 중요한 역할을 할 수 있다. 

8.2.1 원본 이벤트 유지 

• 원본 메시지가 있으면 실수로 변환 로직을 엉망으로 만든 경우에도 쉽게 돌아가서 다시 시작할 수 있다. 
• 현재 사용하지 않는 데이터가 나중에 사용될 수 있다는 장점이 있다.

 

8.2.2 배치 사고방식에서 벗어나기 

• 과거의 데이터 변환 프로세스에서 현재의 변화 중 하나는 지연 없이 데이터를 다양한 시스템으로 지속적으로 스트리밍할 수 있다는 것이다. 
• 데이터베이스를 실행하고 업데이트 하기 위해 야간 작업을 기다릴 필요가 없다.
• 집약적인 ETL 작업을 수행하기 위해 트래픽이 적은 야간 시간대를 기다릴 필요가 없다. 

 

8.3 도구 

8.3.1 아파치 볼륨 

• 빅데이터 작업 통해 카프카를 처음 접했다면 클러스터와 관련하여 플륨 Flume을 사용했을 가능성이 크다. 
• Flume은 데이터를 클러스터로 가져오는 더 쉬운 경로를 제공할 수 있으며 커스텀 코드보다 구성에 더 의존한다. 

• Flume 에이전트가 자체 프로세스로 노드에서 실행되는 방법의 예를 보여준다. 
• 해당 서버의 로컬 파일을 감시한 다음 사용자가 제공한 에이전트에 대한 구성을 사용해 데이터를 싱크로 보낸다.
• Flume 에이전트를 사용해 로그 파일(데이터 소스)을 카프카 토픽(데이터 싱크)에 통합하는 방식이다. 
• 변경사항은 kinaction_flumetopic 카프카 토픽에 배치된다. 
• 이 예시는 cat 명령을 디렉터리의 파일을 사용해 파일을 읽고 특정 카프카 토픽으로 보내는 것과 같다. 

[참고] Flume의 구성 이란 

Flume Agent는 flume.conf 같은 설정 파일에서 이 세 가지 요소의 조합을 정의합니다. 즉,
✔️ 어떤 파일을 감시할지 (Source)
✔️ 데이터를 어떻게 저장할지 (Channel)
✔️ 어디로 보낼지 (Sink)

 

이런 흐름을 설정하는 것이 "구성"이라고 한다. 

# Agent 이름 지정
agent.sources = fileSource
agent.channels = memoryChannel
agent.sinks = hdfsSink

# Source 설정 (로컬 파일 감시)
agent.sources.fileSource.type = spooldir
agent.sources.fileSource.spoolDir = /var/logs

# Channel 설정 (메모리 채널 사용)
agent.channels.memoryChannel.type = memory
agent.channels.memoryChannel.capacity = 1000
agent.channels.memoryChannel.transactionCapacity = 100

# Sink 설정 (HDFS로 저장)
agent.sinks.hdfsSink.type = hdfs
agent.sinks.hdfsSink.hdfs.path = hdfs://namenode/flume/logs
agent.sinks.hdfsSink.hdfs.fileType = DataStream

# Source와 Sink를 채널에 연결
agent.sources.fileSource.channels = memoryChannel
agent.sinks.hdfsSink.channel = memoryChannel

 

8.3.2 레드햇 데베지움

• 데이터베이스를 이벤트 스트림으로 전환되는데 도움이 되는 분산 플랫폼 
• 데베지움은 애플리케이션이 카프카에서 일반 클라이언트가 소비하는 이벤트를 기록하기 위해 카프카 커넥트와 커넥터를 사용한다. 

• 이 시나리오에서 개발자는 CLI를 사용하고 변경사항을 모니터링 중인 MySQL 데이터베이스 인스턴스에 대해 사용자를 삭제한다.
• 데베지움은 데이터베이스의 내부 로그에 기록된 이벤트를 감지하고 해당 이벤트는 커넥터 서비스를 통해 카프카로 전달된다. 
• 추가로, 카프카와 직접적인 관련은 없으나 CDC 같은 기술을 사용해 데이터의 이벤트 및 변경사항을 즉시 제공하여 데베지움의 전반적인 목표와 유사한 방식으로 도움을 줄 수 있다. 

 

[참고] 국내 기술블로그 사례 

CDC 너두 할 수 있어(feat. B2B 알림 서비스에 Kafka CDC 적용하기) | 우아한형제들 기술블로그

CDC 너두 할 수 있어(feat. B2B 알림 서비스에 Kafka CDC 적용하기) | 우아한형제들 기술블로그

데이터 싱크를 위한 MSK Connect 도입 (feat : CDC 뽀개기) | by bibi_papa | 펫프렌즈 기술블로그

데이터 싱크를 위한 MSK Connect 도입 (feat : CDC 뽀개기)

 

 

8.3. 3 데이터 보호 Security

• Secor는 2024년부터 진행된 핀터레스트의 프로젝트로 카프카 로그 데이터를 s3 및 구글 쿨라우드 스토리지를 포함한 다양한 스토리지 옵션에 유지하도록 돕는 것을 목표로 한다. 

• 데이터 백업을 위해 클러스터에 컨슈머를 추가한다. 
  • 다른 컨슈머를 방해하지 않고 카프카 보존기간이 로그에서 데이터를 제거한 후에도 손실되지 않도록 이벤트 사본을 가질 수 있다. 

 

8.3.4 데이터 저장을 위한 사용 사례의 예 

• 데이터를 2개의 서로 다른 영역으로 나누어 한 영역은 데이터가 카프카에 들어올 때 운영 용도로 그 데이터를 사용한다.
• 운영 데이터 operational data
  • 일상적인 작업에서 생성되는 이벤트 
    • 예를 들어, 웹사이트에서 상품을 주문하는 이벤트 
    • 구매 이벤트는 애플리케이션을 액션으로 트리거하고 대기 시간이 짧은 방식으로 작동한다. 
    • 실시간 애플리케이션에 대한 이 데이터의 가치는 주문이 완료되고 우편으로 발송될 때까지 며칠 동안 데이터를 유지하는 것을 보증해야 한다.
    • 이 기간이 지나면 분석 시스템에서 이 이벤트가 더 중요해질 수 있다. 
• 분석 데이터 analytical data
  • 동일한 운영 데이터를 기반으로 하지만 일반적으로 비즈니스 결정을 내리는데 더 많이 사용된다. 
  • 기존 시스템에서는 데이터 웨어하우스, 온라인 분석처리 시스템, 하둡과 같은 프로세스가 중요하다. 
    • 예를 들어, 판매 데이터에 대한 통찰력을 얻기 위해 다양한 시나리오에서 이벤트의 다양한 필드 조합을 사용해 해당 이벤트 데이터를 마이닝한다. 

 

8.4 카프카로 데이터를 다시 가져오기 

• 새로운 애플리케이션 로직 변경으로 인해 이전 데이터를 다시 처리해야 하는 경우 s3와 카프카 모두에서 읽기 위해 클라이언트를 생성하지 않고, 카프카커넥트와 같은 도구 사용해 s3에서 카프카로 해당 데이터를 다시 로드할 수 있다.

 

8.4.1 계층화된 스토리지 Tired Storage

• 컨플루언트 플랫폼 6.0.0 버전에는 계층화된 스토리지 tired storage 라는 최신 선택지가 있다. 
• 이 모델에서는 로컬 저장소는 여전히 브로커 그 자체이며, 원격 저장소는 오래되고 시간 구성 (confluent.tier.local.hostet.ms)에 의해 제어되는 데이터가 유지된다. 

 

8.5 카프카를 사용한 아키텍쳐 

MVC Model-View-Controller, P2P Peer-to-Peer, SOA Service-Oriented Architecture 와 같이 제품을 구축할 때 데이터를 이벤트로 보는 다양한 아키텍쳐 패턴이 있다. 

 

8.5.1 람다 아키텍쳐 

• 데이터의 실시간 뷰는 히스토리 뷰와 결합되어 최종 사용자에게 서비스를 제공한다. 
• 나단 미즈 Nathan Marz가 제임스 위렌 James Warren과 한께 쓴 [Big Data]라는 책에서 람다 아키텍처, 배치, 서빙, 스피드 레이어에 대해 설명한다. 

• 고객 주문 접수를 배치 및 실시간 방식으로 합쳐 전날의 고객 총계는 하루 동안 발생하는 주문과 통합되어 최종 사용자에게 결합된 데이터 뷰로 제공될 수 있다. 
  • 배치 Batch : 새 데이터가 데이터 저장소에 추가되면 배치 처리 계층은 이미 시스템에 있는 데이터 뷰를 계속해서 미리 계산한다.
  • 속도 Speed : 이 레이어는 최근 데이터에서 뷰를 생성한다는 점을 제외하면 배치 레이어와 개념이 유사하다.
  • 서빙 Serving : 이 레이어는 배치 뷰를 업데이트 할 때마다 소비자에게 보내는 뷰를 업데이트 한다. 
• 최종 사용자의 경우 람다 아키텍쳐는 서비스 레이어와 스피드 레이어의 데이터를 통합하여 모든 최근 및 과거 데이터의 전체 뷰로 요청에 응답한다. 
• 이 실시간 스트리밍 레이어는 카프카가 역할을 수행할 수 있는 가장 확실한 위치이지만 배치 레이어를 공급하는 데도 사용할 수 있다. 

 

8.5.2 카파 아키텍쳐 Kappa 

• 카프카의 공동 개발자인 제이 크렙스가 제안했다. 
• 필요할 때만 사용자 대면 데이터를 재생성하다. 그렇게 되면 이전 데이터와 새 데이터를 병합할 필요가 없다. 

• 이벤트가 카프카에서 소싱된 다음 카프카 스토림즈 또는 ksqlDB를 사용해 거의 실시간으로 모든 이벤트를 읽고 최종 사용자를 위한 뷰를 생성한다. 
• 최종 사용자 뷰를 만드는데 사용되는 스트리밍 로직만 있기 때문에 배치 레이어를 따로 관리할 필요가 없다. 

 

8.6 다중 클러스터 설정 

8.6.1 클러스터 추가를 통한 확장 

• 일반적으로 확장할 첫 번째 항목은 기존 클러스터 내부의 리소스인데, 브로커 수가 보통 첫번째 옵션이다. 
• 하지만, 넷플릭스의 멀티클러스터 전략은 카프카 클러스터 자체를 확장하는 방식이다. 
  • 브로커 수만 추가하는 대신, 클러스터 자체를 추가하여 확장한다. 
• CQRS Command Query Responsibility Segregation 과 유사하다. 
  • 데이터 읽기 부하와 데이터 쓰기 부하를 분리한다. 
  • 각 작업은 다른 작업을 제한하지 않고 독립적인 방식으로 확장할 수 있다. 

https://martinfowler.com/bliki/CQRS.html

bliki: CQRS

 

 

8.7 클라우드 및 컨테이너 기반 스토리지 옵션 

8.7.1 쿠버네티스 클러스터 

• 컨테이너화된 환경을 다룰 때 클라우드와 유사한 문제에 직면할 수 있다. 
  • 브로커에서 잘못 구성된 메모리 제한에 도달하여 데이터가 올바르게 기록되지 않으면 완전히 새로운 노드로 이동될 수 있다. 
• 데이터 손실을 허용하는 샌드백스에 있지 않은 경우 재시작, 실패, 이동하더라도 데이터가 유지되도록 퍼시스턴트 볼륨 클레임을 필요로 할 수 있다. 
• 브로커의 ID를 유지하기 위해 스테이트풀셋 API를 사용할 가능성이 놓다. 
• 클러스터를 정상 상태로 유지하려면 이러한 브로커는 실패, 재시작, 업그레이드 작업에서 브로커 관리 로그를 식별할 수 있는 기능이 필요하다. 

 

요약 

• 데이터 보존기간은 비즈니스 요구사항에 따라 결정돼야 한다. 결정에는 스토리지 비용과 시간 경과에 따른 데이터 증가율이 포함된다. 
• 크기와 시간은 데이터가 디스크에 보존되는 기간을 정의하기 위한 기본 매개변수다.
• 카프카 외부의 데이터 장기 저장은 장기간 보관해야 하는 데이터를 위한 옵션이다. 나중에 데이터를 클러스터로 생성하여 필요에 따라 데이터를 다시 가져올 수 있다. 
• 데이터를 신속하게 처리하고 데이터를 재생하는 카프카의 기능은 람다 및 카파 같은 아키텍쳐를 활성화 할 수 있다. 
• 클라우드 및 컨테이너 워크로드에는 종종 수명이 짧은 브로커 인스턴스가 포함된다. 지속해야 하는 데이터에는 새로 생성되거나 복구된 인스턴스가 모든 인스턴스에서 해당 데이터를 활용할 수 있도록 하기 위한 계획이 필요하다.