수많은 이벤트를 처리할 수 있는 분산 이벤트 스트리밍 플랫폼으로 2011년 Linked in에서 만들고 오픈소스로 제공한 이후 이벤트 스트리밍 플랫폼으로 빠르게 발전하는 중이다. 대부분 Event Hub 또는 Messaging Queue로만 사용하고 있지만, Kafka 이외의 ksqlDB, schema registry, connector 등을 함께 사용하여 데이터 플랫폼으로 사용할 수 있다.
한 눈에 봐도 아키텍처가 매우 복잡하다.. 위와 같은 아키텍처에서는 시스템을 확장하는 것이 매우 어렵다. 시스템간의 의존성이 복잡하여 만약 한 시스템에서 장애가 발생하더라도 여러 시스템에 영향이 가며 이는 장애를 복구하는데 있어서도 매우 큰 걸림돌이 된다. 이외에도 많은 단점들을 내포하고 있다.
Kafka를 사용한 아키텍처가 이전의 아키텍처에 비해 훨신 간단해 보인다. 간단히 살펴보면 Pub/Sub 구조로 분리되었기 때문에 데이터를 보내는 쪽(Producer)와 데이터를 받는 쪽(Consumer)의 역할이 분리되어있다. 또한 시스템간의 의존성이 낮아져서 확장하기에 유리하다. 위의 아키텍처에서는 데이터를 End-to-End로 받았기 때문에 하나의 솔루션을 추가하더라도 연결 작업을 해야할 솔루션들 또한 많아지는데, Kafka를 사용함으로써 추가하는 솔루션은 Kafka만 연동하면 되는 간단한 구조로 바뀌었다.
Kafka 이외에 Kafka Connect, Kafka Streams, ksqlDB, Schema Resgistry 등을 사용하여 Kafka를 보다 더 효율적이고 유용하게 사용할수 있다. 이러한 애플리케이션 또는 프레임워크가 없었다면 모두 개발을 통해서 kafka를 사용해야 했을텐데 덕분에 개발을 최소화 하여 사용할 수가 있다.
Kafka는 Linked in에서 이벤트 스트림 처리를 위해 개발되었고 2011년에 Apache Software Foundation에 기부되어 오픈소스화 되었다. 바로 2012년에 Apache Incubator 과정을 벗어나 Top-Level 프로젝트가 될 정도로 빠르게 발전했다. Kafka를 창시한 Jay Kreps는 핵심 멤버들과 함께 Kafka 개발에 집중하기 위해 2014년에 Confluent라는 회사를 창업했고 2021년 6월에는 IPO를 통해 Nasdaq에 상장했다.
스타트업이나 전문 개발자가 있는 기업의 경우에는 오픈소스의 Apache Kafka를 사용하여 필요한 부분은 개발할 수 있겠지만, 말이 쉽지 어느 정도 숙련된 개발자가 필요하며 운영 과정에 있어서도 분명 시행착오를 겪을 수밖에 없다. 이런저런 이유로 오픈소스에 대해 부담을 느끼는 기업들은 라이센스를 통해 어느 정도 수준을 보장받고 싶어하기도 하고 개발과정보다 운영에만 더 집중하고 싶으면 솔루션화 된 애플리케이션을 구매하여 사용하고 싶어할수도 있다. Confluent는 Kafka와 관련 애플리케이션을 유료화 하여 SaaS 형태로 제공을 하고 오픈소스 이외의 자체 개발한 애플리케이션을 제공한다.(대표적으로 Confleutn Control Center) 유료화해서인지 Confluent의 Kafka는 오픈소스의 Kafka보다 더 최적화하여 개발하였다고도 한다.
필요에 따라 오픈소스의 Kafka를 사용하며 개발하던가 유료 라이센스를 구매하여 Confluent가 제공하는 Confluent Platform을 사용하면 될것 같다.
부디 타 회사처럼 Apache License를 갑자기 변경하는 일은 없었으면 좋겠다..
앞으로는 Kafka의 주요 개념 및 더 디테일한 내용에 대해 포스팅해보겠다.
Docker-Compose로 Confluent Kafka 와 C3(Confluent Control Center) 설치 (0) | 2022.10.10 |
---|---|
Kafka의 주요 요소 개념 정리 (0) | 2022.01.16 |
댓글 영역