Kafka,카푸카 알아보기

Kafka는 무엇?
Kafka는 서버 클러스터 내에서 데이터 스트림을 레코드로 유지하는 방식으로 작동하는 브로커 기반 솔루션입니다.
Kafka 서버는 여러 데이터 센터에 분산되어 있을 수 있으며 여러 서버 인스턴스에 걸쳐 레코드 스트림(메시지)을 토픽으로 저장하여 데이터 지속성을 제공할 수 있습니다.
토픽은 레코드 또는 메시지를 키, 값 및 타임 스탬프로 구성된 일련의 튜플, 변경 불가능한 Python 객체 시퀀스로 저장합니다.

 

KAFKA의 주요 개념
Kafka는 오늘날 시장에서 가장 빠르게 성장하는 오픈 소스 메시징 솔루션 중 하나입니다. 이는 주로 분산 시스템에 우수한 로깅 메커니즘을 제공하는 아키텍처 기반 설계 패턴 때문입니다.

실시간 로그 스트리밍을 위해 특별히 제작된 Apache Kafka는 다음 사항을 필요로 하는 애플리케이션에 적합합니다:

• 서로 다른 구성 요소 간의 안정적인 데이터 교환
• 애플리케이션 요구 사항 변경에 따라 메시징 워크로드를 분할하는 기능
• 데이터 처리를 위한 실시간 스트리밍
• 데이터/메시지 재생에 대한 기본 지원

 

 

토픽: 토픽은 게시/구독 메시징에서 상당히 보편적인 개념입니다. Kafka 및 기타 메시징 솔루션에서 토픽은 지정된 데이터 스트림(일련의 레코드/메시지)에 대한 관심을 표시하는 데 사용되는 주소 지정 가능한 추상화입니다. 토픽은 게시 및 구독할 수 있으며 애플리케이션에서 주어진 데이터 스트림에 대한 관심을 표시하는 데 사용하는 추상화 계층입니다.

파티션 : Kafka에서 토픽은 파티션이라는 일련의 순서 대기열로 세분화될 수 있습니다. 이러한 파티션은 연속적으로 추가되어 순차적 커밋 로그를 형성합니다. Kafka 시스템에서 각 레코드/메시지에는 지정된 파티션의 메시지 또는 레코드를 식별하는 데 사용되는 오프셋이라는 순차 ID가 할당됩니다.

 

Offset: Partition의 레코드는 각각 offset이라 불리는, Partition내에서 고유한 레코드의 순서를 의미하는 식별자 정보를 갖고 있습니다.단일 Partition으로 구성하는 경우 메시지의 순서 보장이 되나, 여러 Partition으로 구성하는 경우에는 Partition간의 순서보장이 되지 않습니다.Producer는 파티션키를 사용하여 특정한 파티션에 메시지를 전달할 수 있습니다. 기본적으로 파티션키는 hashing함수를 사용해 전달되고 hashing 함수는 동일한 키를 갖는 모든 레코드들이 동일한 파티션에 저장되는 것을 보장합니다.

영속성: Kafka는 레코드/메시지가 게시될 때 지속적으로 유지하는 서버 클러스터를 유지 관리하여 작동합니다. Kafka 클러스터는 구성 가능한 보존 시간 제한을 사용하여 소비에 관계없이 주어진 레코드가 지속되는 기간을 결정합니다. 레코드/메시지가 보존 시간 제한 내에 있는 동안 레코드/메시지를 사용할 수 있습니다. 레코드/메시지가 이 보존 시간 제한을 초과하면 레코드/메시지가 삭제되고 공간이 확보됩니다.

토픽/파티션 확장 : Kafka는 서버 클러스터로 작동하기 때문에 주어진 토픽/파티션에서 각 서버에 부하를 공유하여 토픽/파티션을 확장할 수 있습니다. 이 부하 공유를 통해 Kafka 클러스터의 각 서버는 주어진 토픽/파티션에 대한 레코드/메시지의 배포 및 영속성을 처리할 수 있습니다. 개별 서버가 모든 배포 및 영속성을 처리하는 동안 모든 서버는 서버가 실패할 경우 내결함성과 고가용성을 제공하는 데이터를 복제합니다. 파티션은 파티션 리더로 선택된 한개 서버와 팔로워 역할을 하는 다른 모든 서버들로 분할됩니다. 파티션 리더 인 서버는 데이터의 모든 배포 및 영속성 (읽기/쓰기)을 처리하고 팔로워 서버는 내결함성을 위한 복제 서비스를 제공합니다.

프로듀서: Kafka에서 프로듀서 개념은 대부분의 메시징 시스템과 다르지 않습니다. 데이터(레코드/메시지) 프로듀서는 주어진 레코드/메시지가 게시되어야 하는 토픽(데이터 스트림)를 정의합니다. 파티션은 추가 확장성을 제공하는 데 사용되므로 프로듀서는 주어진 레코드/메시지가 게시되는 파티션도 정의할 수 있습니다. 프로듀서는 주어진 파티션을 정의할 필요가 없으며 파티션을 정의하지 않음으로써 토픽 파티션에서 순차 순환 대기 방식의 로드 밸런싱을 달성할 수 있습니다.
Producer는 파티션키를 사용하여 특정한 파티션에 메시지를 전달할 수 있습니다. 기본적으로 파티션키는 hashing함수를 사용해 전달되고 hashing 함수는 동일한 키를 갖는 모든 레코드들이 동일한 파티션에 저장되는 것을 보장합니다.

컨슈머: 대부분의 메시징 시스템과 마찬가지로 Kafka의 컨슈머는 레코드/메시지를 처리하는 엔터티입니다. 컨슈머는 개별 워크로드에서 독립적으로 작업하거나 지정된 워크로드에서 다른 컨슈머와 협력하여 작업하도록 구성할 수 있습니다(로드 밸런싱). 컨슈머는 컨슈머 그룹 이름을 기반으로 워크로드를 처리하는 방법을 관리합니다. 컨슈머 그룹 이름을 사용하면 컨슈머를 단일 프로세스 내, 여러 프로세스, 심지어 여러 시스템에 분산시킬 수 있습니다. 컨슈머 그룹 이름을 사용하여 컨슈머는 컨슈머 집합 전체에서 레코드/메시지 소비를 로드 밸런싱(동일한 컨슈머 그룹 이름을 가진 여러 컨슈머)하거나 토픽/파티션을 구독하는 각 컨슈머가 처리 메시지를 받도록 각 레코드/메시지를 고유하게 (고유한 컨슈머 그룹 이름을 가진 여러 컨슈머) 처리할 수 있습니다.

 

Kafka의 비즈니스 이점

원래 실시간 로그 처리를 위한 통신 계층 역할을하도록 설계되었기 때문에 자연스럽게 실시간 스트림 처리 애플리케이션에 어울립니다. 따라서 Kafka는 대량의 데이터를 실시간으로 배포할 수있는 통신 인프라를 활용하는 애플리케이션에 이상적으로 적합합니다.

원활한 메시징 및 스트리밍 기능 : 대용량 데이터를 처리할 때 메시징은 레거시 통신 모델에 비해 통신 및 확장성에 상당한 이점을 제공할 수 있습니다. 메시징 및 스트리밍 기능을 결합함으로써 Kafka는 실시간으로 레코드를 게시, 구독, 저장 및 처리하는 고유한 기능을 제공합니다.

데이터 재생을 위한 시간 기반 데이터 보존 : Kafka는 기본적으로 클러스터 전체의 디스크에 데이터를 지속적으로 저장하는 기능을 통해 내결함성에 대한 간단한 접근 방식을 허용합니다. 시간 기반 보존 기간을 기반으로 저장된 데이터를 회수하고 순차적 오프셋을 기반으로 데이터에 액세스하는 기능과 함께 Kafka는 클러스터 설정에서 데이터 저장 및 검색에 대한 강력한 접근 방식을 제공합니다.

스트림 처리를 위한 기본 접근 방식 : 데이터를 빠르고 효율적으로 이동할 수 있게 하는 것이 상호 연결성의 핵심입니다. Kafka는 데이터를 레코드, 메시지 또는 스트림으로 원활하게 이동할 수 있는 기반을 제공합니다. 데이터를 검사, 변환 및 활용하려면 데이터를 실시간으로 다른 위치로 이동할 수 있는 기능이 필요하며 Kafka는 실시간으로 데이터를 이동하고 저장하기위한 기본 접근 방식을 제공합니다.

기본 통합 지원 : 모든 것에 적용하는 것은 결코 좋은 접근 방식이 아니며 Kafka는 Connector API를 사용하여 기본 통합 지점을 제공함으로써 확장 및 성장할 수 있는 기본 기능을 제공합니다. Kafka Connector API를 사용하여 애플리케이션은 사전 구축된 커넥터 또는 오픈 소스 도구를 통해 타사 솔루션, 기타 메시징 시스템 및 레거시 애플리케이션과 통합하거나 애플리케이션 요구 사항에 따라 의도적으로 커넥터를 구축할 수 있습니다.

Kafka를 사용하기
Kafka는 실시간 메시지 배포에서 스트리밍 이벤트에 이르기까지 다양한 애플리케이션 유형에 사용되어 이벤트 기반 아키텍처를 강화할 수 있습니다. 예를 들어, 더 많은 자동화, 더 많은 추적, 제품 및 서비스의 더 빠른 제공을 제공하기 위해 이벤트 중심 아키텍처로 전환하는 제조 회사를 생각해보십시오. *End to End event 중심 아키텍쳐를 제공하는 데 필요한 많은 구성 요소가 있지만 커뮤니케이션은 이벤트 스트리밍 및 처리 방법의 기초입니다.

사용의 예

 

*End to End event 중심 아키텍쳐
이벤트 중심 아키텍처 (EDA)는 조직이 "이벤트" 또는 중요한 비즈니스 순간(거래, 사이트 방문, 장바구니 포기 등)을 감지하고 실시간으로 또는 준실시간으로 조치를 취할 수 있게 해주는 소프트웨어 설계 패턴입니다. 이 패턴은 서비스가 다음 작업으로 이동하기 전에 응답을 기다려야 하는 전통적인 "요청/응답" 아키텍처를 비교됩니다. 이벤트 중심 아키텍처의 흐름은 이벤트에 의해 실행되며 이벤트에 응답하거나 이벤트에 대한 응답으로 일부 작업을 수행하도록 설계됩니다.