참조
Getting Started
카프카에 대한 기본적인 소개, 사용 사례, 퀵스타트 가이드
godekdls.github.io
1.1 Introduction
What is event streaming?
이벤트 스트리밍은 데이터베이스, 센서, 모바일 기기, 클라우드 서비스, 소프트웨어 어플리케이션같은 이벤트 소스에서 데이터를 실시간으로 이벤트 스트림 형식으로 잡아내는 관행이다. 이런 이벤트 스트림은 나중에 조회해갈 수 있게 안전한 곳에 저장하고, 실시간 이벤트 스트림에 즉시 반응하거나 모아서 처리할 수도 있다. 필요에 따라 이벤트 스트림을 다른 기술로 라우팅하기도 한다. 이벤트 스트리밍은 이처럼 데이터의 지속적인 플로우를 이어주며, 덕분에 데이터를 끊김 없이 해석해 적시에 적절한 정보를 필요한 곳에 제공할 수 있다.
Apache Kafka is an event streaming platform. What does that mean?
카프키는 세 가지 핵심 기능을 갖추고 있기 때문에, 현장에서 검증된 단일 솔루션을 통해 원하는 사례를 이벤트 스트리밍 end-to-end로 구현할 수 있다:
1. 이벤트 스트림을 발행(write)하고 구독(read)하며, 다른 시스템에 있는 데이터를 끊임 없이 import/export 할 수 있다.
2. 이벤트 스트림을 원하는 기간 동안 안전하고 신뢰할 수 있는 곳에 저장한다.
3. 이벤트 발생 즉시 스트림을 처리하거나 모아서 처리한다.
게다가 이 모든 기능은 분산 서비스가 가능하고, 확장성 또한 뛰어나며, 탄력적이고 내결함성이 있는 안전한 방식으로 제공된다. 카프카는 베어 메탈 하드웨어, 가상 머신, 컨테이너에 배포할 수 있으며, 클라우드나 온 프레미스 환경에도 배포할 수 있다. 카프카 환경을 직접 관리해도 되고, 다양한 벤더가 제공하는 완전 관리형 서비스를 사용해도 좋다.
내결함성 : 시스템의 일부 구성 요소가 작동하지 않더라도 계속 작동할 수 있는 기능을 말합니다.
How does Kafka work in a nutshell?
in a nutshell : 간단히 말해서
카프카는 고성능 TCP 네트워크 프로토콜로 통신하는 서버와 클라이언트로 구성된 분산 시스템이다.
서버 : 카프카는 서버 하나 이상을 가진 클러스터로 실행하며, 각 서버는 여러 데이터센터나 클라우드 지역에 걸쳐있을 수 있다. 일부 서버는 브로커라고 일컫는 스토리지 레이어를 구성한다. 또 다른 서버는 카프카 커넥트를 실행해 데이터를 끊임 없이 이벤트 스트림으로 import/export 하는 식으로, 카프카를 다른 카프카 클러스터나 관계형 데이터베이스 등의 기존 시스템과 통합한다. 서비스 운영에 필수적인 유스 케이스를 구현할 수 있도록 카프카 클러스터는 뛰어난 확장성과 내결함성을 제공한다: 서버 중 하나에 장애가 발생하면 다른 서버에서 이어받아, 데이터 유실없이 지속적인 운영을 보장한다.
클라이언트 : 카프카 클라이언트로는 네트워크 문제나 장비 장애가 발생하더라도 내결함성을 유지하면서, 대규모 이벤트 스트림을 읽고, 쓰고 처리하는 분산 어플리케이션과 마이크로 서비스를 만들 수 있다.
Main Concepts and Terminology
이벤트는 "무언가가 발생했다"는 사실을 기록한다. 이 문서에서는 레코드 혹은 메세지라고도 부른다. 카프카에서 데이터를 읽거나 쓸 땐 이벤트 형식으로 진행하게 된다. 개념적으로 이벤트는 키, 값, 타임스탬프를 가지고 있으며, 옵션으로 메타데이터 헤더도 있을 수 있다. 다음은 이벤트의 예시다:
- 이벤트 키 : "Alice"
- 이벤트 값 : "Made a payment of $200 to Bod"
- 이벤트 타임스탬프 : "Jun. 25, 2020 at 2:06 p.m."
프로듀서는 카프카에 이벤트를 발행(write)하는 클라이언트 어플리케이션을 뜻하며, 컨슈머는 이 이벤트를 구독(read and process) 하는 어플리케이션을 뜻한다. 카프카에서 프로듀서와 컨슈머는 완전히 분리되어 있으며, 각자는 서로의 세부 구현을 알 필요 없이 독립적으로 동작한다. 프로듀서와 컨슈머를 분리한 것은 카프카에서 잘 알려진 높은 확장성을 달성해준 핵심 설계 요소다. 예를 들어 프로듀서는 컨슈머를 기다려야 할 필요가 전혀 없다. 카프카는 이벤트를 정확히 한 번만 처리하는 등의 여러가지 시맨틱스를 보장한다.
이벤트는 토픽으로 구성돼 안전하게 저장된다. 매우 단순하게 설명하면, 토픽은 파일 시스템의 폴더와 유사하며, 이벤트는 이 폴더 안에 있는 파일이라고 볼 수 있다. 예제 토픽 이름은 "payments"가 될 수 있다. 카프카의 토픽은 언제나 멀티 프로듀서와 멀티 컨슈머가 접근할 수 있다: 단일 토픽에 이벤트를 작성하는 프로듀서가 0, 1, 또는 그 이상 있을 수 있으며, 이 이벤트를 구독하는 컨슈머도 0, 1, 또는 그 이상일 수 있다. 토픽의 이벤트는 필요한 만큼 재차 읽어갈 수 있다 ㅡ 기존 메세징 시스템과 달리 이벤트를 컨슘한 후 삭제하지 않는다. 대신 토픽별 설정으로 카프카가 이벤트를 보존할 기간을 정의하고, 오래된 이벤트를 폐기한다. 사실상 카프카의 성능은 데이터 크기가 크더라도 일정하므로 장기간 데이터를 저장해도 전혀 문제 없다.
토픽은 파티셔닝된다. 즉, 토픽은 서로 다른 카프카 브로커에 있는 여러 "버킷"으로 분산된다. 이렇게 데이터를 분산해 저장하는 것은 확장성을 위해서다. 덕분에 클라이언트 어플리케이션은 동시에 여러 브로커에서 데이터를 읽고 쓸 수 있다. 토픽에 새 이벤트를 발행하면 실제로는 토픽의 파티션 중 하나에 추가된다. 이벤트 키(고객 ID나 차량 ID 등)가 동일한 이벤트는 같은 파티션에 기록되며, 카프카에선 하나의 토픽-파티션을 컨슘하는 모든 컨슈머는 항상 기록한 순서와 정확히 같은 순서로 해당 파티션 이벤트를 읽어간다는 걸 보장한다.
내결함성, 고가용성 있는 데이터를 만들기 위해 모든 토픽은 복제할 수 있으며, 지리적으로 분산시키거나 데이터센터에 걸쳐서도 가능하다. 따라서 혹시 모를 문제를 대비하거나 브로커 유지 관리 등을 위해, 항상 데이터 복제본을 가진 멀티 브로커가 존재하게 된다. 보통 프로덕션 환경에선 replication factor를 3으로 설정한다. 이렇게 하면 항상 데이터 복제본이 3개 존재하게 된다. 데이터 복제는 토픽-파티션 레벨에서 이루어진다.
1.2 Use Cases
Messaging
카프카는 다른 전통적인 메세지 브로커를 대체할 수 있다. 메세지 브로커는 다양한 목적으로 활용한다 (데이터 처리 로직을 프로듀서와 분리하거나, 처리되지 않은 메세지를 버퍼에 담는 등). 카프카를 다른 메세징 시스템과 비교해보면, 보통 더 나은 처리량을 보여주고, 파티셔닝 기능이 내장되어 있으며, 복제와 내결함성을 제공하므로 대규모 메세지 처리 어플리케이션의 솔루션으로 적합하다.
경험상 메세징 시스템은 비교적 처리량이 낮더라도, 보통 end-to-end 지연 시간이 짧아야 하며, 카프카가 보장하는 강력한 내구성이 필요하곤 하다.
이 도메인에서 카프카 역할은 ActiveMQ나 RabbitMQ같은 전통적인 메세징 시스템과 유사하다.
Website Activity Tracking
원래 카프카의 유스 케이스는 사용자의 활동을 추적하는 파이프라인을, 실시간 publish-subscribe 피드 셋으로 재구성하는 것이었다. 다시 말해, 사이트 활동(페이지 조회, 검색 등 사용자가 취할 수 있는 활동)은 활동 타입마다 그에 해당하는 하나의 중앙 토픽으로 발행된다. 실시간 처리, 실시간 모니터링, 오프라인 처리와 보고를 위해 하둡이나 다른 오프라인 데이터 웨어하우스 시스템에 로드하는 등 다양한 유스 케이스에 따라 이 피드를 구독할 수 있다.
각 사용자가 페이지를 조회할 때마다 방대한 활동 메세지가 만들어지기 때문에, 사용자 활동을 추적할 땐 보통 대용량 데이터를 생성하게 된다.
Metrics
카프카는 운영 모니터링 데이터에서도 자주 활용한다. 여기에는 분산 어플리케이션의 통계 데이터를 집계해, 운영 데이터의 중앙 집중식 피드를 구성하는 것도 포함된다.
Log Aggregation
많은 곳에서 로그 집계 솔루션 대신 카프카를 사용하고 있다. 로그 집계는 보통 서버에서 물리적인 로그 파일을 수집해서, 향후에 로그를 처리할 수 있게 중앙 저장소(파일 서버나 HDFS)에 저장하는 것을 말한다. 카프카는 파일의 상세 정보를 추상화하며, 로그나 이벤트 데이터를 메세지 스트림으로 더 깔끔하게 추상화해준다. 이를 통해 처리 지연 시간을 줄일 수 있으며, 더 쉽게 멀티 데이터 소스와 분산 데이터 컨슈밍을 지원할 수 있다. 카프카를 Scribe나 Flume같은 로그 중심 시스템과 비교해보면, 똑같이 좋은 성능을 보여주며, 복제로 인한 더 강력한 내구성과, 훨씬 낮은 end-to-end 지연 시간을 제공한다.
Stream Processing
많은 사용자들이 카프카 토픽에서 원본 입력 데이터를 컨슘해, 새 토픽으로 집계, 보강, 변환해서 추가 컨슈밍이나 후속 처리를 진행하는 멀티 스텝으로 구성된 파이프라인으로 데이터를 처리하고 있다. 예를 들어, 뉴스 기사 추천을 위한 처리 파이프라인은 RSS 피드에서 기사 컨텐츠를 크롤링해 "articles" 토픽에 발행할 수 있다. 후속 처리 단계에선 이 컨텐츠를 정규화하거나 중복을 제거해 정리된 기사 컨텐츠를 새 토픽에 발행할 수 있다. 최종 처리 단계에선 이 컨텐츠를 사용자에게 추천하는 식으로 말이다. 이런 데이터 처리 파이프라인은 각 토픽을 기반으로 실시간 데이터 플로우 그래프를 생성한다. 0.10.0.0부터 아파치 카프카는 카프카 스트림즈라는 가볍지만 강력한 스트림 처리 라이브러리를 제공하므로 앞에서 설명한 방식대로 데이터를 처리할 수 있다. 카프카 스트림즈 외에도 이를 대체할 수 있는 오픈 소스 스트림 처리 툴로는 Apache Storm, Apache Samza가 있다.
Event Sourcing
이벤트 소싱은 상태 변경을 시간 순서에 따라 레코드 시퀀스로 기록하는 어플리케이션 설계 방식이다. 카프카에는 매우 큰 로그 데이터도 저장할 수 있기 때문에, 이벤트 소싱 스타일로 구축한 어플리케이션에서 사용하기 적합한 백엔드 시스템이다.
Commit Log
카프카는 분산 시스템에서 외부 로그를 커밋하는 용도로 사용할 수 있다. 로그는 노드 간에 데이터를 복제하는 데 활용할 수 있으며, 실패한 노드가 데이터를 복구할 수 있도록 재동기화 메커니즘 역할을 수행해준다. 카프카의 로그 컴팩션 기능도 유용하다. 이 유스 케이스에서 카프카는 Apache BookKeeper 프로젝트와 유사하다.
1.3 Quick Start
생략
1.4 Ecosystem
생략
'개발' 카테고리의 다른 글
| Kafka를 이용해 '실시간' 데이터 처리가 가능한가? (0) | 2022.12.11 |
|---|---|
| 2. Apis - 요약 (0) | 2022.12.04 |
| [제네릭] <T extends A> 와 <? extends A> 의 차이점은 무엇일까? (0) | 2022.03.06 |
| [열거 타입] Enum 공부하다 생긴 의문점 2가지 (0) | 2022.03.02 |
| [제네릭] 타입 안전 이종 컨테이너.. 이거 어디에 사용할까? (0) | 2022.02.21 |