08 카프카 스토리지

8.1 데이터 저장 기간

• 카프카 토픽 데이터의 기존 보존기간 제한은 7일이며, 이 제한은 시간이나 데이터 크기로 쉽게 구성할 수 있다.
• 브로커에 대한 보존기간의 주요 고려사항은 로그의 크기와 데이터가 존재하는 시간이다.
• 'log.retention.bytes'(로그 삭제를 위한 최대 크기 임댓값), log.retention.ms(로그 삭제 전 유지 시간) 등의 속성값이 있다.
• 로그 보존기간 제한을 비활성화하고 영원히 유지하려면, log.retention.bytes, log.retention.ms 값 모두 -1로 설정하면 데이터 삭제를 끌 수 있다.

8.2 데이터 이동

• 도구나 코드를 사용해 데이터를 원래 형식으로 가져오고 데이터를 변환한 다음 다른 테이블이나 데이터 저장소에 배치할 수 있다. 카프카는 이러한 데이터 파이프라인에서 중요한 역할을 할 수 있다.

8.2.1 원본 이벤트 유지

• 원본 메시지를 보관하며 토픽에 배치하기 전 형식을 지정하지 않는 이유는, 실수로 변환 로직을 엉망으로 만든 경우에도 쉽게 돌아가서 다시 시작할 수 있기 때문이다.
• 변형된 데이터에서 실수를 수정하는 방법을 찾는 대신, 원래 데이터로 돌아가서 다시 시작할 수 있다.

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

• 과거의 데이터 변환 프로세스에서 현재의 변화 중 하나는 지연 없이 데이터를 다양한 시스템으로 지속적으로 스트리밍할 수 있다

8.3 도구

• 데이터 이동은 카프카를 비롯한 많은 시스템의 핵심이다.
• 커넥트와 같은 오픈소스 카프카 및 먼플루언트 제품 또는 다른 도구들을 살펴보자.

8.3.1 아파치 플룸

• 플룸은 데이터를 클러스터로 가져오는 더 쉬운 경로를 제공할 수 있으며 커스텀 코드보다 구성에 더 의존한다.
• 플룸 에이전트는 해당 서버의 로컬 파일을 감시한 다음 사용자가 제공한 에이전트에 대한 구성을 사용해 데이터를 싱크로 보낸다.

8.3.2 레드햇 데베지움

• 데베지움은 데이터베이스를 이벤트 스트림으로 전환하는 데 도움이 되는 분산 플랫폼이라고 설명되어 있다.
• 데이터베이스 업데이트를 이벤트로 처리할 수 있다. (변경 데이터 캡처, CDC)
• 데베지움은 애플리케이션이 카프카에서 일반 클라이언트가 소비하는 이벤트를 기록하기 위해 커넥트와 커넥터를 사용한다.
• 아래 그림은 카프카 커넥트에 대해 데베지움을 커넥터로 등록한 경우의 예시이다.

8.3.3 보안

• Secor는 카프카 로그 데이터를 S3 및 구글 클라우드 스토리지를 포함한 다양한 스토리지 옵션에 유지하도록 돕는 것을 목표로 한다.
• Secor는 다른 어플리케이션솨 마찬가지로 카프카 클러스터의 컨슈머 역할을 한다.
• Secor는 자바 프로세스로 실행되며 특정 구성을 제공할 수 있다.

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

• 운영 데이터:
  • 일상적인 작업에서 생성되는 이벤트이다.
  • 예를 들어, 사이트에서 상품을 주문하는 이벤트를 생각할 수 있다.
  • 이러한 이벤트들은 애플리케이션을 액션으로 트리거하고 대기 시간이 짧은 방식으로 작동한다.
• 분석 데이터:
  • 동일한 운영 데이터를 기반으로 하지만 비즈니스 결정을 내리는 데 더 많이 사용된다.

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

• 새로운 애플리케이션 로직 변경으로 인해 이전 데이터를 다시 처리해야 하는 경우, 카프카 커넥트와 같은 도구를 사용해서 S3에서 카프카로 해당 데이터를 다시 로드할 수 있다.

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

빅데이터 아키텍처

8.5.1 람다 아키텍처

• 데이터의 실시간 뷰는 히스토리 뷰와 결합되어 최종 사용자에게 서비스를 제공한다.
• 최종 사용자의 경우 람다 아키텍처는 서비스 레이어와 스피드 레이어의 데이터를 통합하여 모든 최근 및 과거 데이터의 전체 뷰로 요청에 응답한다.
• 마즈의 'Big Data' 에 기술된 레이어
  • 배치: 새 데이터가 데이터 저장소에 추가되면 배치 처리 계층은 이미 시스템에 있는 데이터 뷰를 계속해서 미리 계산해둔다.
  • 속도: 최근 데이터에서 뷰를 생성한다는 점을 제외하면, 배치 레이어와 개념이 유사하다.
  • 서빙: 배치 뷰를 업데이트할 때마다 소비자에게 보내는 뷰를 업데이트 한다.

8.5.2 카파 아키텍처

• 중단 없이 사용자에게 영향을 미치는 시스템을 유지하려는 경우를 생각해보자.
• 람다 아키텍처와 기본 목표는 동일하지만, 모든 데이터가 스트림 처리 시스템을 사용하여 단일 경로를 따라 흐른다는 중요한 차이점이 있다.
• 모든 이벤트 처리가 입력 스트림에서 수행되고, 실시간 보기로 유지된다.

8.6 다중 클러스터 설정

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

• 브로커 수는 성장에 직접적인 영향을 주는 첫 번째 옵션이다.
• 넷플릭스의 멀티 클러스터 전략은 카프카 클러스터를 확장하는 새로운 방식이었다.
  • 이 설계는 CQRS라는 아이디어를 떠올리게 한다.
  • 마틴 파울러의 CQRS

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

8.7.1 쿠버네티스 클러스터

• 컨테이너화된 환경은 클라우드에서와 유사한 문제에 직면할 수 있다.
• 브로커에서 잘못 구성된 메모리 제한에 도달하여 데이터가 올바르게 기록되지 않으면 완전히 새로운 노드로 이동될 수 있음.
• 재시작, 실패, 이동하더라도 데이터가 유지되도록 브로커가 퍼시스턴트 볼륨 클레임을 필요로 할 수 있다.
  • 브로커 인스턴스 컨테이너가 변경될 수 있지만, 기존 영구 볼륨을 다시 요청할 수 있어야 한다.