이벤트 스트리밍 이란?
이벤트 스트리밍은 인간 몸의 중추신경의 디지털화 이다. 산업에서 소프트웨어 기반과 자동화가 점점 증가하고 사용자가 더많은 소프트웨어를 사용하는 '항상 켜져있는’ 세상을 위한 기술 기초이다.
기술적으로 말해서, 이벤트 스트리밍은 이벤트의 스트림의 형태에는 데이터베이스, 센서, 모바일 장치, 클라우드 서비스, 애플리케이션 소프트웨어와 같은 이벤트 소스에서 실시간으로 데이터 수집을 실행하는 것이다.
;나중에 검색할 수 있도록 이러한 이벤트 스트림을 계속해서 저장; 이벤트 스트림은 과거뿐만 아니라 실시간으로 조작,처리 및 대응한다; 그리고 필요에 따라 다른 대상 기술로 이벤트 스트림 라우팅; 그러므로 이벤트 스트리밍은 올바른 정보를 적절한 장소와 시간 위치에 있기 위해서 데이터의 연속적 흐름과 해석을 보장한다.
이벤트 스트리밍 사용할 수 있는 항목
이벤트 스트리밍은 수많은 산업 및 조직에 걸쳐 wide variety of use cases 에 적용된다. 여기엔 많은 예가 포함되어있다.
- 실시간 증권거래소, 은행, 보험과 같은 실시간 지불 과정과 금융거래에서
- 자동차 산업과 같은 자동차, 트럭, 함대, 배와 같은 것을 실시간 모니터하고 추적
- 공장같은데 안에서 IoT 장치 또는 장비에서 센서 데이터를 계속해서 수집하고 분석
- 소매와 같은 호텔이나 여행산업 그리고 모바일 애플리케이션에서 고객과 상호작용 또는 주문에 즉시 반응하거나 수집하기위해
- 병원 진료 중인 환자를 모니터링하고 응급 상황에서 적시에 치료를 받을 수 있도록 상태 변화를 예측하기 위해
- 회사의 여러 부서에 의해 생산한 데이터를 연결, 저장 그리고 사용할 수 있도록
- 데이터 플랫폼, 이벤트 기반 아키텍처 및 마이크로서비스를 위해 기반 역할 수행
Apache Kafka®는 이벤트 스트리밍 플랫폼인데 이게 의미하는 것은?
카프카는 세가지 핵심역량을 결합하여 battle-tested 단일 솔루션으로 엔드 투 엔트 이벤트 스트리밍 사용 사례 구현할 수 있다.
- 다른 시스템에서 지속적인 데이터 가져오거나, 내보내는 것 등 이벤트 스트림 발행(쓰기)와 구독(읽기)
- 원하는 만큼 지속적이고 안정적이게 이벤트 스트림 저장
- 과거에 발생했거나 현재 발생한 이벤트 스트림 처리
그리고 이모든 분산, 확장, 장애허용, secure manner 안에서 기능이 제공된다. 카프카는 bare-metal hardware, virtual machines, containers, on-premises , cloud 에서 배치될 수 있다. 카프카 환경을 사용자가 스스로 관리하는 것과 다양한 벤더사에서 제공되는 완전히 관리되는 서비스 사용하는 것 둘 중 선택할 수 있다.
Kafka는 어떻게 간결하게 작업하나?
카프카는 높은 성능의 TCP 네트워크 프로토콜을 통해 통신하는 서버와 클라이언트로 구성된 분산 시스템이다. 는 bare-metal hardware, virtual machines, containers, cloud 환경에서 구축될 수 있다.
Server : 카프카는 다수의 데이터센터 또는 클라우드에 걸쳐 있을 수 있는 하나 또는 그 이상의 서버의 클러스터 로서 실행한다. 이러한 서버중 일부는 브로커라 불리는 스토리지 계층을 형성한다. 다른 서버에서는 Kafka Connect를 실행하여 지속적으로 데이터를 가져오고 이벤트 스트림으로 내보내 다른 Kafka 클러스터와 같은 기존 시스템과 통합한다. mission-critical 유스케이스를 구현할 수 있도록 카프카 클러스터는 확장성이 뛰어나고 내결함성이 뛰어나다. : 서버 중 하나에 장애가 발생하면 다른 서버가 작업을 넘겨받아 데이터 손실 없이 지속적인 운영을 보장
Clients: 기계 결함이나 네트워크 문제의 경우에도 이벤트 스트림을 병렬, 스케일, 장애허용하는 방식으로 읽고 쓰고 처리할 수 있는 분산 애플리케이션 및 마이크로 서비스를 작성할 수 있다. 카프카는 몇몇 클라이언트와 함께 전송되는데, 카프카 커뮤니티가 제공하는 수십명의 클라이언트에 의해 증강된다: 클라이언트는 상위 수준의 Kafka Streams 라이브러리, Go, Python, C/C++ 및 REST와 다른 많은 프로그래밍 언어를 포함한 Java 및 Scala에서 사용할 수 있다.
주요 개념과 용어
이벤트는 세상이나 산업에서의 “무엇인가 일어난“ 사실을 기록한다. 문서에서는 이것을 레코드 또는 메세지라고 부른다. 카프카에서 데이터를 읽거나 쓸 때, 이벤트의 형식에서 해야한다. 개념적으로, 이벤트는 키, 값, 타임스탬프 그리고 선택적 메타데이터 헤더를 가지고 있다.
아래는 이벤트의 예시이다.****
- Event key: "Alice"
- Event value: "Made a payment of $200 to Bob"
- Event timestamp: "Jun. 25, 2020 at 2:06 p.m."
프로듀서는 카프카에 발행하는 클라이언트 애플리케이션이고, 컨슈머는 카프카에서 이러한 이벤트를 구독(읽거나 처리하는)한다. 카프카에서 프로듀서와 컨슈머는 완전히 분리되었고 서로 상호 호환되는데 이는 높은 확장성을 달성하기 위한 핵심 설계 요소로 카프카는 알려져 있다. 예를 들어서, 프로듀서는 컨슈머를 위해 기다려주지않는다. 카프카는 꼭 한번 씩 이벤트를 처리하는 기능과 같은 다양한 보장을 제공한다.
이벤트는 토픽에 지속적으로 저장되며 구성되어 있다. 매우 단순하게, 토픽은 파일시스템에서 폴더와 비슷하고, 이벤트는 폴더에서 파일이다. 예제 토픽 이름이 “payment“라 가정하자. 카프카에서 토픽은 항상 멀티 프로듀서와 멀티 구독자이다 : 토픽은 이벤트를 쓰는 0개, 1개, 또는 많은 프로듀서 뿐만 아니라 이러한 이벤트를 구독하는 0개 , 1개, 많은 컨슈머를 가진다. 토픽안의 이벤트는 필요한 만큼 자주 읽을 수 있다. 전통적인 메시징 시스템과 달리, 이벤트는 consumption 이후로 삭제되지 않는다. 대신에 어떻게 길게 카프카가 각 토픽 configuration 설정을 통해 이벤트를 유지하는지 정의할 수 있다, 후에 오래된 이벤트는 폐기될 것이다. 카프카의 성능은 데이터 크기에 관한 것과 함께 실질적으로 일정하고, 장기간 데이터 저장은 괜찮다.
토픽은 파티션으로 나뉘며, 다른 카프카 브로커에 위치한 수 많은“버켓“에 뿌려져 있다. 데이터의 분산된 위치 확장성에 매우 중요하다. 왜냐하면 클라이언트 애플리케이션이 동시에 많은 브로커에서 데이터를 읽기와 쓰기 모두 허용한다. 토픽을 발행하는 새로운 이벤트는 실제로 이 항목의 파티션 중 하나에 추가된다. 키와 함께 이벤트 키는 같은 파티션에 기록되며, 그리고 토픽 파티션이 주어진 어떠한 고객인 카프카 보장은 항상 정확히 쓰여진 순서대로 파티션의 이벤트를 읽을 것 이다.
설명 : 이 예제 토픽은 P1-P4로 4개의 파티션으로 나뉘어졌다. 두개의 다른 프로듀서 클라이언트는 발행하고 서로 독립적이로 토픽 파티션에 네트워크를 통해 이벤트 토픽에 기록함으로써 의해 새로운 이벤트 게시하고있다.
데이터의 내결함성과 고가용성을 높이기 위해, 지역이나 데이터 센터에서도 모든 토픽을 복제할 수 있으므로 문제가 발생할 경우를 대비해 데이터 복사본을 보유한 브로커를 유지 관리 등을 수행할 수 있다.
일반적인 production 설정은 replication 수는 3이다. 즉, 항상 데이터를 3개씩 복사를 하겠다는 것이다. 이러한 복제는 토픽-파티션 레벨에서 수행된다.
프라이머는 introduction을 위해서 충분해야한다. 문서의 설계 부분은 카프카의 다양한 개념을 자세하게 설명한다.
Kafka APIs
관리 및 관리 작업을 위한 명령줄 도구 외에도 카프카는 Java와 Scala로 쓰인 다섯 개 핵심 APIs를 가지고 있다 :
- Admin API - 토픽, 브로커, 다른 카프카 object를 관리하거나 검사
- Producer API - 하나 또는 그 이상의 카프카 토픽에 이벤트 스트림 발행
- Consumer API - 하나 또는 그 이상의 토픽을 구독하거나 생산된 이벤트 스트림 처리
- Kafka Streams API - 스트림 처리 애플리케이션과 마이크로 서비스 향상. 변형을 포함해서 이벤트 스트림 처리하는 높은 수준의 기능 제공하고 집계 및 조인, windowing, 이벤트 시간 기반 처리등과 같은 상태 저장 작업 수행. 한개 또는 그 이상의 결과물을 생산하기 위해서 입력값을 한개 또는 그 이상의 토픽에서 읽는다. 효율적이게 input 스트림을 output 스트림으로 변환하는 것
- Kafka Connect API to build and run reusable data import/export connectors that consume (read) or produce (write) streams of events from and to external systems and applications so they can integrate with Kafka. For example, a connector to a relational database like PostgreSQL might capture every change to a set of tables. However, in practice, you typically don't need to implement your own connectors because the Kafka community already provides hundreds of ready-to-use connectors.
- 재사용 가능한 데이터를 가져오거나 내보내는 케넉터를 빌드 및 실행
Where to go from here
- To get hands-on experience with Kafka, follow the Quickstart.
- To understand Kafka in more detail, read the Documentation. You also have your choice of Kafka books and academic papers.
- Browse through the Use Cases to learn how other users in our world-wide community are getting value out of Kafka.
- Join a local Kafka meetup group and watch talks from Kafka Summit, the main conference of the Kafka community.
참고 사항
https://kafka.apache.org/26/documentation.html#introduction
- 프로듀서 : 메시지 송신 API
- 예 ) Front-End
- 컨슈머 : 메시지 수신 API
- 예 ) 하둡, 데이터 웨어하우스, 다른 컨슈머, 실시간 모니터링
- 브로커 : 카프카의 서버, 한 대 이상의 클러스터로 구성할 수 있음
- 토픽 : 유사한 메시지들의 집합. 프로듀서는 메시지 전달할 토픽을 반드시 지정해야함
- 파티션 : 로드 밸런싱 목적으로 토픽을 논리적으로 분할 하는 것
- 리플리케이션 : Fault Tolerance를 위해 파티션 단위로 복제하는 것
- 주키퍼가 카프카 토픽 리더 선출함
- 주키퍼가 리더의 토픽을 기준으로 다른 토픽들 sync를 맞춰준다
- 파티션을 복제하여 가용성 높일 수 있음
- 브로커 1 의 토픽 A (리더) , 브로커 2 의 토픽 A , 브로커 3 의 토픽 A
- 토픽 A에서 실시간 이벤트 스트림 수집하다가 장애 낫을 경우?
- 다른 브로커의 토픽A를 리더로 선정하여 계속해서 일을 진행한다.
- 각 파티션된 토픽 A 3개는 같음.
- 카프카는 설정할 때 replicator? replication의 개수를 설정해줘야 브로커를 여러대 사용하고 토픽도 파티션으로 나눌 수 있다.
'Bigdata > 하둡 Architecture 번역' 카테고리의 다른 글
Hive Architecture (0) | 2022.05.17 |
---|---|
HBase Architecture (0) | 2022.05.17 |
Zookeeper Architecture (0) | 2022.05.17 |
YARN Architecture (0) | 2022.05.17 |
HDFS Architecture (0) | 2021.09.30 |