[Apache Kafka] Kafka 란?

https://ko.wikipedia.org/wiki/%EC%95%84%ED%8C%8C%EC%B9%98_%EC%B9%B4%ED%94%84%EC%B9%B4

Kafka란?

아파치 카프카(Apache Kafka)는 아파치 소프트웨어 재단이 스칼라로 개발한 오픈 소스 메시지 브로커 프로젝트이다. 이 프로젝트는 실시간 데이터 피드를 관리하기 위해 통일된, 높은 처리량, 낮은 지연시간을 지닌 플랫폼을 제공하는 것이 목표이다. 요컨대 분산 트랜잭션 로그로 구성된, 상당히 확장 가능한 pub/sub 메시지 큐로 정의할 수 있으며, 스트리밍 데이터를 처리하기 위한 기업 인프라를 위한 고부가 가치 기능이다.

디자인은 트랜잭션 로그에 많은 영향을 받았다

[위키백과, https://ko.wikipedia.org/wiki/%EC%95%84%ED%8C%8C%EC%B9%98_%EC%B9%B4%ED%94%84%EC%B9%B4]

 

Apache Kafka 공식페이지 

https://kafka.apache.org/

 

Kafka Github

https://github.com/apache/kafka

 

 

Apache KafKa(아파치 카프카)는 링크드인(LinkedIn)에서 개발한 분산 스트리밍 플랫폼이다. 시스템 또는 애플리케이션간에 데이터를 안정적으로 가져 오는 실시간 데이터 파이프 라인을 만들 때 주로 사용되는 오픈소스 솔루션이다.

카프카는 대용량의 실시간 로그처리에 특화되어 있는 솔루션이며 데이터를 유실없이 안전하게 전달하는 것이 주목적인 메세지 시스템에서 Fault-Tolerant한 안정적인 아키텍처와 빠른 퍼포먼스로 데이터를 처리할 수 있다

(필자는 제휴 API 개발에 사용한다.) 

 

https://kafka.apache.org/intro.html

Kafka 에는 5가지 핵심 API가 있다.

 

Producer API (생산자 API)

• 한개 이상의 카프카 주제에 레코드의 스트림을 Publish 할 수있는 응용 프로그램을 할 수 있습니다

Consumer API (소비자 API)

• 응용 프로그램이 한개 이상의 주제에 가입 그들에게 생산 기록의 스트림을 처리 할 수 있습니다

Streams API (스트림 API)

• 애플리케이션이 역할을 할 수 있도록 스트림 프로세서 효과적으로 출력 스트림의 입력 스트림을 변환하는 한개 이상의 항목에서 입력 스트림을 소비하는 하나 개 이상의 출력 항목을 출력 스트림을 생성한다.

Connector API (커넥터 API)

• 구축하고 재사용 생산자 또는 를 실행 할 수 있습니다 기존의 응용 프로그램이나 데이터를 시스템에 연결 카프카 주제 그. 예를 들어, 관계형 데이터베이스에 대한 커넥터는 테이블에 대한 모든 변경 사항을 캡처 할 수 있습니다.

Admin API (관리 API)

• 관리 및 주제, 브로커 및 기타 카프카 개체를 검사 허용한다.

 

https://kafka.apache.org/intro.html

Kafka가 제공하는 핵심 추상화를 통한 일련의 레코드 스트림이다.

Kafka의 Topic은 항상 다중 subscriber이다. 즉, Topic에 작성된 데이터를 subscribe하는 많은 consumers가 있을수 있다.

각 Topic에 대해 Kafka 클러스터는 위 그림과 같은 분할 로그를 유지관리 한다.

 

각 파티션은 구조화 된 커밋 로그에 지속적으로 추가되는 순서가 불변 인 순서의 레코드입니다. 파티션의 레코드에는 각각 파티션 내의 각 레코드를 고유하게 식별 하는 오프셋 이라는 순차적 ID 번호가 할당 됩니다.

Kafka 클러스터는 구성 가능한 보존 기간을 사용하여 Publish 여부에 관계없이 Publish 된 모든 레코드를 지속적으로 유지합니다. 예를 들어 보존 정책이 2 일로 설정되어 있으면 레코드가 Publish 된 후 이틀 동안 사용할 수 있으며 공간을 확보하기 위해 버려집니다. Kafka의 성능은 데이터 크기와 관련하여 사실상 일정하므로 오랫동안 데이터를 저장하는 것은 문제가되지 않습니다.

 

https://kafka.apache.org/intro.html

 

실제로, consumer별로 유지되는 유일한 메타 데이터는 로그에서 해당 consumer의 오프셋 또는 위치입니다. 이 오프셋은 consumer가 제어합니다. 일반적으로 consumer는 레코드를 읽을 때 오프셋을 선형으로 진행하지만 실제로 위치는 consumer가 제어하므로 원하는 순서대로 레코드를 사용할 수 있습니다. 예를 들어 consumer는 과거의 데이터를 재 처리하기 위해 이전 오프셋으로 재설정하거나 가장 최근의 레코드로 건너 뛰어 지금부터 소비 할 수 있습니다.

 

이러한 기능의 조합은 Kafka consumer가 매우 저렴하다는 것을 의미합니다. 클러스터 나 다른 consumer에게 큰 영향을주지 않고오고 갈 수 있습니다. 예를 들어, 명령 행 도구를 사용하여 기존 consumer가 소비하는 내용을 변경하지 않고 모든 주제의 내용을 "맞춤"할 수 있습니다.

로그의 파티션은 여러 가지 용도로 사용됩니다. 먼저, 단일 서버에 적합한 크기를 넘어서 로그를 확장 할 수 있습니다. 각 개별 파티션은 해당 파티션을 호스팅하는 서버에 맞아야하지만 주제에 많은 파티션이있을 수 있으므로 임의의 양의 데이터를 처리 할 수 ​​있습니다. 둘째, 그것들은 병렬 처리의 단위로 작동합니다.

 

 

Distribution

로그의 파티션은 각 서버가 데이터를 공유하고 파티션 공유를 요청하는 Kafka 클러스터의 서버로 분산됩니다. 각 파티션은 내결함성을 위해 구성 가능한 수의 서버에 복제됩니다.

각 파티션에는 "지도자"역할을하는 하나의 서버와 "추종자"역할을하는 0 개 이상의 서버가 있습니다. 리더는 파티션에 대한 모든 읽기 및 쓰기 요청을 처리하는 반면 팔로어는 리더를 수동으로 복제합니다. 리더가 실패하면 팔로워 중 하나가 자동으로 새로운 리더가됩니다. 각 서버는 일부 파티션의 리더 역할을하고 다른 파티션의 팔로워 역할을 수행하므로 클러스터 내에서로드 균형이 잘 조정됩니다.

 

Geo-Replication

Kafka MirrorMaker는 클러스터에 대한 지리적 복제 지원을 제공합니다. MirrorMaker를 사용하면 메시지가 여러 데이터 센터 또는 클라우드 지역에 복제됩니다. 백업 및 복구를 위해 능동 / 수동 시나리오에서이 기능을 사용할 수 있습니다. 또는 액티브 / 액티브 시나리오에서 데이터를 사용자에게 더 가깝게 배치하거나 데이터 지역 요구 사항을 지원합니다.

 

 

Producers

생산자는 원하는 주제에 데이터를 Publish합니다. 제작자는 주제 내에서 어떤 파티션에 할당 할 레코드를 선택할 책임이 있습니다. 이것은로드를 밸런싱하기 위해 라운드 로빈 방식으로 수행되거나 일부 의미 분할 기능 (레코드의 일부 키를 기준으로)에 따라 수행 될 수 있습니다. 분할 사용에 대한 추가 정보

Consumers

소비자는 소비자 그룹 이름으로 레이블 을 지정하고 주제에 Publish 된 각 레코드는 각 구독 소비자 그룹 내에서 하나의 소비자 인스턴스로 전달됩니다. 소비자 인스턴스는 별도의 프로세스 또는 별도의 시스템에있을 수 있습니다.

모든 소비자 인스턴스에 동일한 소비자 그룹이있는 경우 레코드는 소비자 인스턴스에 대해 효과적으로로드 밸런싱됩니다.

모든 소비자 인스턴스에 다른 소비자 그룹이있는 경우 각 레코드는 모든 소비자 프로세스에 브로드 캐스트됩니다

 

https://kafka.apache.org/intro.html#intro_distribution

 

두 개의 consumers 그룹이있는 네 개의 파티션 (P0-P3)을 호스팅하는 두 개의 서버 Kafka 클러스터. consumers 그룹 A에는 두 개의 consumers 인스턴스가 있고 그룹 B에는 네 개의 인스턴스가 있습니다.

  그러나 일반적으로 주제에 "logical subscriber"마다 하나씩 소수의 consumers 그룹이있는 것으로 나타났습니다. 각 그룹은 확장 성과 내결함성을 위해 여러 consumers 인스턴스로 구성됩니다. 이는 가입자가 단일 프로세스 대신 consumers 클러스터 인 publish-subscribe 의미론에 지나지 않습니다.

Kafka에서 소비가 구현되는 방식은 각 인스턴스가 특정 시점에서 파티션의 "(fair share) 공정한 공유"의 독점 consumers가되도록 consumers 인스턴스를 통해 로그의 파티션을 분할하는 것입니다. 그룹 구성원 자격 유지 프로세스는 Kafka 프로토콜에 의해 동적으로 처리됩니다. 새 인스턴스가 그룹에 가입하면 그룹의 다른 구성원에서 일부 파티션을 인계받습니다. 인스턴스가 종료되면 해당 파티션이 나머지 인스턴스에 배포됩니다.

Kafka 는 주제 내 다른 파티션 사이가 아니라 파티션 내의 레코드에 대해서만 총 순서를 제공합니다 . 키별로 데이터를 분할하는 기능과 결합 된 파티션 별 순서는 대부분의 응용 프로그램에 충분합니다. 그러나 레코드에 대한 총 주문이 필요한 경우 파티션이 하나 인 주제를 사용하여이를 달성 할 수 있지만 이는 consumers 그룹당 하나의 consumers 프로세스 만 의미합니다

 

 

메시징 시스템으로서의 Kafka

 

Kafka의 스트림 개념은 기존 엔터프라이즈 메시징 시스템과 어떻게 비교될까?

메시징에는 전통적으로 queuing 과 publish-subscribe 두 가지 모델 이 있습니다 . 큐에서 consumers의 pool은 서버에서 읽을 수 있으며 각 레코드는 그 중 하나로 이동합니다. publish-subscribe에서 레코드는 모든 consumers에게 broadcast됩니다. 이 두 모델은 각각 장단점이 있습니다. queuing의 장점은 여러 consumers 인스턴스에 걸쳐 데이터 처리를 분할하여 처리를 확장 할 수 있다는 것입니다. 불행하게도 queuing은 다중 가입자가 아닙니다. 한 번의 프로세스에서 사라진 데이터를 읽습니다. publish-subscribe을 사용하면 데이터를 여러 프로세스로 broadcast 할 수 있지만 모든 메시지가 모든 subscribe에게 전달되므로 처리를 확장 할 수있는 방법이 없습니다.

Kafka의 consumers 그룹 개념은이 두 개념을 일반화합니다. queuing 마찬가지로 consumers 그룹을 사용하면 프로세스 모음 (consumers 그룹의 구성원)에 대한 처리를 나눌 수 있습니다. publish-subscribe과 마찬가지로 Kafka를 사용하면 여러 consumers 그룹에게 메시지를 broadcast 할 수 있습니다.

Kafka 모델의 장점은 모든 주제에 이러한 속성이 모두 있으며 (처리를 확장 할 수 있고 다중 subscriber 임) 둘 중 하나를 선택할 필요가 없다는 것입니다.

Kafka는 기존 메시징 시스템보다 강력한 정확한 주문을 제공한다.

기존 queue는 서버에서 레코드를 순서대로 유지하며 여러 consumers가 queue에서 소비하는 경우 서버는 저장된 순서대로 레코드를 전달합니다. 그러나 서버는 레코드를 순서대로 전달하지만 레코드는 비동기 적으로 consumers에게 전달되므로 다른 consumers에게 순서가 맞지 않을 수 있습니다. 이는 병렬 consumers있을 경우 레코드 순서가 손실됨을 의미합니다. 메시징 시스템은 종종 하나의 프로세스 만 대기열에서 소비 할 수있는 "독점 consumers"라는 개념을 사용하여이 문제를 해결하지만 처리 과정에 병렬 처리가 없음을 의미합니다.

Kafka의 장점이다.. 주제 내에서 병렬 처리 (파티션)라는 개념을 가짐으로써 Kafka는 consumers 프로세스 풀에서 주문 보장과 로드 밸런싱을 모두 제공 할 수 있습니다. 이는 주제의 파티션을 consumers 그룹의 consumers에게 할당하여 각 파티션이 그룹의 정확히 하나의 consumers에 의해 소비되도록함으로써 달성됩니다. 이를 통해 consumers는 해당 파티션의 유일한 독자이며 데이터를 순서대로 사용합니다. 파티션이 많으므로 여전히 많은 consumers 인스턴스에 대한 로드 밸런싱을 유지합니다. 그러나 consumers 그룹에는 consumers보다 더 많은 consumers 인스턴스가 있을 수 없습니다.

 

 

2020/10/12 - [Delvelopment/Kafka] - [Kafka] Topic 메세지 보관주기 설정 (MSK)

2020/08/21 - [Delvelopment/Kafka] - MQ (Message queue)란?

2020/08/05 - [Delvelopment/Self-MSA구축기] - [Kafka Tool] KaDeck 이용해 Topic, Message생성하기.

2020/06/29 - [Delvelopment/Kafka] - [Spring Boot, kafka] 스프링 프로젝트에 kafka 리스너 적용기.

2020/06/29 - [Delvelopment/Kafka] - [MAC, Kafka] 맥에 Kafka 설치 하고 토픽생성. (Docker, homebrew, Apache)