Apache Kafka 대 Apache Pulsar : 선택 방법

요즘에는 대규모로 확장 가능한 게시 / 구독 메시징이 Apache Kafka와 거의 동의어입니다. Apache Kafka는 처리를 위해 Apache Storm 또는 Apache Spark와 같은 것을 추가하든 Apache Kafka 자체에서 제공하는 처리 도구를 사용하든 관계없이 분산 스트리밍 응용 프로그램을위한 견고한 오픈 소스 선택지입니다. 그러나 Kafka는 마을에서 유일한 게임이 아닙니다.

야후와 현재 Apache Software Foundation 프로젝트가 개발 한 Apache Pulsar는 Apache Kafka가 수년 동안 착용 한 메시징의 왕관을 향해 가고 있습니다. Apache Pulsar는 개발자가 비교적 쉽게 Kafka에서 Pulsar로 전환 할 수있는 호환 가능한 API와 함께 많은 상황에서 Apache Kafka보다 빠른 처리량과 낮은 지연 시간의 잠재력을 제공합니다. 

유서 깊은 충실한 Apache Kafka와 신생 Apache Pulsar 중에서 어떻게 선택해야합니까? 핵심 오픈 소스 제품과 핵심 유지 관리자의 엔터프라이즈 에디션이 제공하는 내용을 살펴 보겠습니다.

Apache Kafka

LinkedIn에서 개발하고 2011 년에 오픈 소스로 출시 한 Apache Kafka는 광범위하게 퍼져 있으며 아키텍처에 서비스 버스 또는 게시 / 구독 시스템을 추가 할 때 많은 사람들이 기본 선택이되었습니다. Apache Kafka의 데뷔 이후 Kafka 에코 시스템은 상당히 성장하여 Apache Kafka 메시징에서 스키마를 적용하기위한 Scheme Registry, 데이터베이스와 같은 다른 데이터 소스에서 Kafka, 분산 스트림 처리를위한 Kafka Streams, 가장 최근에는 KSQL 로의 간편한 스트리밍을위한 Kafka Connect를 추가했습니다. Kafka 토픽에 대해 SQL과 유사한 쿼리를 수행합니다. (Kafka의 주제는 특정 채널의 이름입니다.)

지난 몇 년 동안 구축 된 많은 실시간 파이프 라인의 표준 사용 사례는 데이터를 Apache Kafka로 푸시 한 다음 Apache Storm 또는 Apache Spark와 같은 스트림 프로세서를 사용하여 데이터를 가져 와서 수행하고 처리 한 다음 게시하는 것이 었습니다. 다운 스트림 소비를 위해 다른 주제로 출력합니다. Kafka Streams 및 KSQL을 사용하면 언제든지 Apache Kafka 프로젝트를 떠나지 않고도 모든 데이터 파이프 라인 요구 사항을 처리 할 수 ​​있습니다. 물론 필요한 경우 외부 서비스를 사용하여 데이터를 처리 할 수 ​​있습니다.

Apache Kafka는 개발자의 관점에서 항상 매우 친절했지만 운영상 혼합 된 가방이었습니다. 소규모 클러스터를 시작하고 실행하는 것은 비교적 쉽지만 대규모 클러스터를 유지 관리하는 데 종종 문제가 발생합니다 (예 : Kafka 브로커 오류 후 리더 파티션 스와핑).

또한 MirrorMaker라는 유틸리티를 통해 멀티 테넌시를 지원하기 위해 취한 접근 방식은 SRE가 머리카락을 뽑아내는 확실한 방법이었습니다. 실제로 MirrorMaker는 Uber와 같은 회사가 데이터 센터 (uReplicator)간에 복제하기위한 자체 시스템을 만들었 기 때문에 이러한 문제로 간주됩니다. Confluent는 Apache Kafka의 엔터프라이즈 제품의 일부로 Confluent Replicator를 포함합니다. MirrorMaker 설정을 유지해야하는 사람이라고 말하면 Replicator가 오픈 소스 버전의 일부가 아니라는 것은 부끄러운 일입니다.

그러나 운영 측면에서 모든 것이 나쁜 소식은 아닙니다. 현재 Apache Kafka 1.x 시리즈에서는 클러스터 실행으로 인한 골칫거리를 줄이기 위해 많은 작업이 수행되었습니다. 최근에 시스템이 200,000 개 이상의 파티션으로 구성된 대규모 클러스터를보다 간소화 된 방식으로 실행할 수 있도록 몇 가지 변경 사항이 있으며 Kafka Connect에 "데드 레터"대기열을 추가하는 등의 개선으로 데이터 소스 및 싱크의 문제를 식별하고 복구 할 수 있습니다. 더 쉽습니다. 또한 2019 년에는 Kubernetes에서 Apache Kafka를 실행하는 프로덕션 수준의 지원이 나타날 가능성이 있습니다 (헬름 차트 및 Kubernetes 운영자를 통해).

2014 년에 Kafka의 원래 개발자 중 세 명 (Jun Rao, Jay Kreps 및 Neha Narkhede)이 Confluent를 설립했습니다. Confluent는 앞서 언급 한 Replicator, Control Center, 추가 보안 플러그인 및 일반적인 지원 및 전문 서비스 제공. Confluent에는 또한 클러스터를 직접 실행하는 작업 오버 헤드를 처리하지 않으려는 경우 Amazon Web Services 또는 Google Cloud Platform에서 실행되는 완전 관리 형 Confluent Platform 서비스 인 클라우드 제품인 Confluent Cloud가 있습니다.

AWS에 잠겨 있고 Amazon 서비스를 사용하는 경우 Amazon은 AWS 에코 시스템 내에서 완전 관리 형 Kafka 서비스 인 Kafka 용 Amazon Managed Streaming (MSK)의 공개 미리보기를 도입했습니다. (Amazon MSK Confluent와의 파트너십으로 제공 되지 않으므로 MSK를 실행하면 Confluent Platform의 모든 기능이 제공되지 않고 오픈 소스 Apache Kafka에서 제공되는 기능 만 제공됩니다.)

Apache Pulsar

기능이 중복되는 것처럼 보이는 프로젝트를 선택하는 Apache Software Foundation의 선호를 감안할 때 (Apache Apex, Apache Flink, Apache Heron, Apache Samza, Apache Spark 또는 Apache Storm을 방향성 비순환 그래프 데이터 처리 요구에 맞게 사용 하시겠습니까?) 메시징 요구 사항에 대한 신뢰할 수있는 옵션으로 Apache Kafka를 선택하기 전에 Apache Pulsar가 최상위 Apache 프로젝트가된다는 발표를 바로 지나쳐서 용서 받으십시오. 그러나 Apache Pulsar는 볼 가치가 있습니다.

Apache Pulsar는 야후에서 태어 났으며 당시 다른 오픈 소스 제품으로는 제공 할 수 없었던 조직의 요구 사항을 해결하기 위해 만들어졌습니다. 결과적으로 Pulsar는 지역 복제 및 다중 테넌시를 완벽하게 지원하여 수백만 개의 주제와 파티션을 처리하도록 처음부터 구축되었습니다.

내부적으로 Apache Pulsar는 스토리지 요구 사항을 유지하기 위해 Apache BookKeeper를 사용하지만 한 가지 비틀기가 있습니다. Apache Pulsar에는 상당히 큰 계층 형 스토리지라는 기능이 있습니다. 분산 로그 시스템의 문제 중 하나는 데이터가 가능한 한 오랫동안 로그 플랫폼에 남아 있기를 원하지만 디스크 드라이브의 크기가 무한하지 않다는 것입니다. 어떤 시점에서 이러한 메시지를 삭제하거나 다른 곳에 저장하기로 결정합니다.이 메시지는 나중에 필요할 경우 데이터 파이프 라인을 통해 잠재적으로 재생할 수 있습니다. 작동하지만 운영상 복잡 할 수 있습니다. Apache Pulsar는 Tiered Storage를 통해 이전 데이터를 Amazon S3, Google Cloud Storage 또는 Azure Blog Storage로 자동으로 이동할 수 있으며 여전히 투명한보기를 클라이언트에 다시 제공 할 수 있습니다.클라이언트는 모든 메시지가 로그에있는 것처럼 처음부터 읽을 수 있습니다.

Apache Kafka와 마찬가지로 Apache Pulsar는 데이터 처리를위한 에코 시스템을 성장 시켰습니다 (Apache Spark 및 Apache Storm 용 어댑터도 제공함). Pulsar IO는 소스 또는 싱크로 다른 데이터 시스템에 연결하기위한 Kafka Connect와 동일하며 Pulsar Functions는 데이터 처리 기능을 제공합니다. SQL 쿼리는 Facebook의 오픈 소스 Presto 엔진 용 어댑터를 사용하여 제공됩니다.

흥미로운 점은 Pulsar Functions 및 Pulsar IO가 잠재적으로 어디서나 실행될 수있는 별도의 프로세스가 아니라 표준 Pulsar 클러스터 내에서 실행된다는 것입니다. 이것은 유연성의 감소이지만 운영 관점에서 훨씬 더 간단하게 만듭니다. (클러스터 외부에서 기능을 실행하기 위해 남용 될 수있는 로컬 실행 모드가 있지만 문서는 "이렇게하지 마십시오!"라고 말하지 않습니다.)

Apache Pulsar는 또한 클러스터 내에서 기능을 실행하는 다양한 방법을 제공합니다. 이들은 별도의 프로세스, Docker 컨테이너 또는 브로커의 JVM 프로세스에서 실행되는 스레드로 실행될 수 있습니다. 이는 이미 프로덕션 환경에서 Kubernetes 또는 Mesosphere DC / OS를 지원하는 Apache Pulsar의 배포 모델과 관련이 있습니다. 알아 두어야 할 한 가지는 Pulsar Functions, Pulsar IO 및 SQL이 Apache Pulsar에 비교적 새로 추가 된 것이므로이를 사용하는 경우 몇 가지 날카로운 모서리를 기대할 수 있습니다.

제한된 Java 전용 Kafka 호환 API 래퍼도 있으므로 기존 Apache Kafka 애플리케이션을 Apache Pulsar 인프라에 통합 할 수 있습니다. 이는 프로덕션 솔루션보다 탐색 적 테스트 및 임시 마이그레이션 계획에 더 적합 할 수 있지만 가지고있는 것이 좋습니다!

Confluent와 유사한 방식으로 Yahoo의 Apache Pulsar 개발자 (Matteo Merli 및 Sijie Guo)는 Apache Heron (Karthik Ramasamy 및 Sanjeev Kulkarni)의 제작자와 함께 공동 창립자 인 Streamlio라는 분사 회사를 설립했습니다. . Streamlio의 엔터프라이즈 제품에는 비공개 소스 관리 콘솔과 함께 일반적인 상용 지원 및 전문 서비스 솔루션이 포함되지만 효율적이고 내구성있는 멀티 테넌시 지원과 같은 것들은 핵심 오픈 소스 제품의 일부입니다.

Apache Kafka 또는 Apache Pulsar?

Apache Kafka는 성숙하고 탄력적이며 전투 테스트를 거친 제품입니다. 거의 모든 인기 언어로 작성된 클라이언트와 Kafka Connect의 다양한 데이터 소스에 대해 지원되는 커넥터 호스트가 있습니다. Amazon과 Confluent에서 제공하는 관리 형 서비스를 통해 대규모 Kafka 클러스터를 쉽게 가동, 실행 및 유지 관리 할 수 ​​있습니다. 이전보다 훨씬 쉽습니다. 저는 새로운 프로젝트에서 Apache Kafka를 계속 사용하고 있으며 앞으로 몇 년 동안 그렇게 할 것입니다.

그러나 처음부터 다중 테넌트 또는 지역 복제가 필요한 메시징 시스템을 구축하거나 대용량 데이터 스토리지가 필요하고 어떻게 든 상관없이 모든 데이터를 쉽게 쿼리하고 처리해야하는 메시징 시스템을 구축하려는 경우 옛날에 나는 Apache Pulsar의 타이어를 걷어차는 것이 좋습니다. Apache Kafka가 어려움을 겪을 수있는 일부 사용 사례에 확실히 적합하며 분산 로그 플랫폼에서 필요한 핵심 기능 측면에서도 잘 작동합니다. 문서 및 Stack Overflow 질문에 대한 답변 측면에서 최첨단을 유지하는 데 신경 쓰지 않는다면 훨씬 좋습니다!