Apache Kafka (with Chat GPT)

요즘 MicroService Architecture (이하 MSA) 에 관심이 생겨서 이것저것 알아보던 중에 Kafka라는 서비스를 알게되었습니다. 

 

쉽게 얘기하면 각각 떨어져있는 서비스들 사이에서 메시지를 주고받을 수 있도록 하는 서비스입니다. 

 

기존 카프카가 없을 때 메시지를 보내려면 위와 같이 모든 컴포넌트가 메시지를 쏴줘야 하는 문제가 있었습니다. (딱봐도 문제가 있게 생겼습니다) 이렇게 데이터를 보내게 되면 데이터 복잡성이 증가하겠죠. 

 

하지만 카프카가 도입되면서 메시지를 보내는쪽 (Publisher) 과 메시지를 받는쪽 (Subscriber) 을 나누고 카프카를 통해 메시지를 주고받으면서 조금 더 편하게 데이터를 주고 받을 수 있게 되었습니다. 

 

이번 포스팅에선 메시지 브로커 (메시지 큐잉 서비스) 가 뭔지, 카프카란 대략적으로 어떤 것을 말하는 것인지, 카프카와 비슷한 서비스는 뭐가 있는지, 그리고 이후에 동기 비동기 네트워킹을 채택하고 있는 다양한 서비스들을 알아봅니다. 

 

※ GPT야 이것좀 알려줘 카테고리는 원래 제가 작성하는 주제 (자바, 스프링, CS, 알고리즘) 와 다른 하지만 평소에 궁금했던 내용을 작성합니다. GPT가 답변한 내용은 ~이다 체로, 제가 작성한 부분은 ~습니다 체로 작성됩니다. 

 

 

0. 메시지 브로커란? (메시지 큐잉 서비스)

메시지 브로커 서비스는 메시지의 교환을 용이하게 함으로써 분산 시스템이나 컴포넌트들 사이에서 커뮤니케이션을 가능하게 하는 미들웨어의 타입 중 하나이다. 메시지 브로커 서비스의 목적은 메시지의 생산자와 소비자를 서로 타이트하게 coupled 되는 것 없이 독립적으로 작동하게 되면서 decoupling 하는 것이다. 

 

여기서 잠깐! decoupling이 뭐야?

decoupling (이하 디커플링) 이란 소프트웨어 시스템의 서로 다른 컴포넌트들이나 서브시스템들 사이의 의존성을 줄이는 방법이라고 할 수 있습니다. 

 

디커플링은 전형적으로 깨끗한 인터페이스나 컴포넌트들 사이에서 깔끔한 커뮤니케이션 프로토콜을 정의하거나, 컴포넌트들 사이에서 직접적인 의존성을 최소화함으로써 달성할 수 있습니다. 

 

디커플링의 목적은 시스템간 영향을 주는 것 없이 새로운 컴포넌트를 추가하거나 교체하거나 변경하기 더 쉽게 만듦으로써 유연하게, 유지하기 쉽게, 확장성있게 향상시키는 것입니다. 

 

디커플링은 또한 시스템 장애에 대한 리스크를 줄여주는데 그 이유는 하나의 컴포넌트에서의 장애가 다른 컴포넌트들로 전파되는 것이 적기 때문입니다. 

 

디커플링은 흔히 소프트웨어 아키텍처 설계에서 주로 사용됩니다. microservice와 같은 곳에서 주로 사용되는데 그곳에서 각각의 서비스들은 잘 정의된 인터페이스를 통해 다른 서비스와 독립적으로 커뮤니케이션하거나 동작하도록 설계됩니다. 

 

디커플링은 또한 Object-Oriented Programming (OOP) 같은 소프트웨어 엔지니어링 분야에서 사용되기도 합니다. OOP에서 캡슐화 원리에 의해 정보를 숨기는 것이 클래스 사이의 의존성을 줄이기위해 사용됩니다. 

 

 

다시 메시지 브로커로 돌아와서 메시지 브로커 서비스에서 메시지들은 보내는 사람 (sender) 에 의해 생산되고 브로커에 의해 받게 된다. 브로커는 또한 메시지 전송이나 필터링, 라우팅, 그리고 보안같은 특징들을 제공할 수 있다. 

 

메시지 브로커 서비스는 다양한 방법으로 구현될 수 있는데 예를 들어서 소프트웨어 컴포넌트를 혼자 내버려 둠으로써 설계할 수도 있고, 애플리케이션 안에 embedded 한 라이브러리를 만들 수도 있고, vendor에 의해 제공되는 클라우드 베이스의 서비스로도 구현할 수 있다. 

 

메시지 브로커 서비스는 흔히 MSA나 event-driven 시스템들이나, 데이터 프로세싱 시스템같은 컴포넌트들 사이에서 비동기 커뮤니케이션을 요구하는 분산시스템에서 사용된다. 

 

메시지의 생산자와 소비자를 디커플링 함으로써 메시지 브로커 서비스는 시스템을 더 유연하게, 신뢰성있게, 확장성있게 설계할 수 있다. 

 

 

1. 카프카란?

Apache Kafka는 실시간 데이터 파이프라인을 설계하거나 애플리케이션을 스트리밍 하기 위해 사용되는 오픈소스 분산 스트리밍 플랫폼이다. 

 

카프카는 큰 볼륨의 데이터를 핸들링하거나 낮은 레이턴시의 프로세싱을 제공하거나, 데이터 스트림을 전달하기 위해 설계되었다. 카프카의 아키텍처는 서버나 브로커의 클러스터를 통해 쪼개진 분산 커밋 로그에 기반하고 있다. 

 

생산자는 카프카 클러스터에 데이터를 입력하고, 소비자는 클러에터에서 데이터를 읽는다. 카프카는 message retention, pub/sub messaging, stream processing과 같은 특징들을 제공한다. 

 

카프카는 이벤트 프로세싱이나 로그 통합, 메시징 서비스와 같은 실시간 데이터 스트리밍 애플리케이션을 설계하는데 탁월한 선택이 될 수 있다. 

 

 

2. 카프카와 바슷한 서비스

• RabbitMQ : RabbitMQ는 Advanced Message Queuing Protocol (AMQP) 이나 Streaming Text Oriented Messaging Protocol (STOMP), Message Queuing Telemetry Transport (MQTT) 와 같은 다양한 메시징 프로토콜을 지원하는 분산된 오픈소스 메시지 브로커이다. (무료)
• Azure Event Hubs : 초당 수백만개의 이벤트를 핸들링할 수 있거나 파티셔닝, 자동적으로 확장하는 것과 같은 특징을 제공하는 마이크로소프트 에저 (Azure) 에 의해 제공된 실시간 데이터 스트리밍 플랫폼이다. (유료)
• Google Cloud Pub/Sub : 애클리케이션 사이에서 확장성있고 지속가능한 메시징을 위해 설계된 Google Cloud Platform (GCP) 에 의해 제공되는 메시징 서비스이다. (유료)
• AWS Kinesis : 확장에 있어서 실시간 데이터 프로세싱을 위해 설계된 AWS에 의해 제공되는 실시간 데이터 스트리밍 플랫폼이다. 키네시스는 스트리밍 프로세싱, 실시간 분석, 다른 AWS 서비스들과 통합과 같은 특징들을 제공한다. (유료)
• Apache Pulsar : 높은 수율, 낮은 레이턴시 데이터 스트리밍을 핸들링하기위해 설계된 오픈소스 분산 pub/sub 메시징 서비스이다. Pulsar는 geo-replication, multi-tenancy, 유연한 데이터 retention 정책들과 같은 특징들을 제공한다. (무료)

 

3. 동기 네트워킹, 비동기 네트워킹

Kafka와 같은 메시지 큐잉 서비스에는 동기 네트워킹, 비동기 네트워킹으로 돌아가는 서비스들로 나눠져있습니다. 이번 섹션에서는 동기 네트워킹과 비동기 네트워킹의 특징과 차이에 대해서 서술합니다. 

 

• 제어의 흐름 (Flow of Control) : 동기 네트워킹에서는 제어의 흐름이 클라이언트에 의해 지시된다. 클라이언트가 요청을 보내면 다음 일을 진행하기 전에 응답을 기다려야한다. 반대로 비동기 네트워킹에선 제어의 흐름이 클라이언트에 의해 지시되지 않는다. 클라이언트는 요청을 보내면 응답을 기다릴 동안 다른 일을 진행할 수 있다. (제어의 흐름이 클라이언트에 의해 지시된다는 의미는 아마도 클라이언트를 통해 제어되는 것인지 아닌지를 말하는 듯 합니다. (Blocking / Non Blocking))
• 성능 : 비동기 네트워킹은 잠재적으로 더 좋은 성능을 제공할 수 잇는데 그 이유는 비동기 네트워킹이 클라이언트의 blocking 없이 동시에 진행될 수 있는 많은 요청을 수행할 수 있기 때문이다. 이러한 것은 특히 네트워크 레이턴시가 높은 상황에서 이익이 될 수 있다. 혹은 레이턴시가 높은 곳에서 클라이언트가 큰 볼륨의 요청을 진행하기 위해 필요한 상황에서 주로 사용될 수 있다. 
• 복잡성 : 비동기 네트워킹은 동기 네트워킹보다 훨씬 더 복잡하다. 왜냐하면 비동기 네트워킹이 콜백을 관리하기 위한 추가적인 로직을 요구하고 비동기 실행 동안 일어날 수 있는 에러를 핸들링하기위한 추가적인 로직을 요구하기 때문이다. 반면에 동기 네트워킹은 이해하기 더 쉽고 관리하기 더 쉬운 선형적인 제어의 흐름을 포함하고 있기 때문에 더 쉽다. 
• 확장성 : 비동기 네트워킹은 전형적으로 동기 네트워킹보다 더 확장성이 뛰어난데 그 이유는 클라이언트의 blocking 없이 다수의 요청을 동시에 수행하는 것을 허락하기 때문이다. 이러한 상황은 네트워크의 전반적인 성능을 향상시킬 수 있다. 

 

4. 메시지 큐잉 서비스 중 동기 서비스인 것과 비동기 서비스인 것

• Asynchronous Message Broker Service
  • Apache Kafka
  • RabbitMQ
  • Apache Pulsar
• Synchronous Message Broker Service
  
  • ActiveMQ
  • Google Cloud Pub/Sub
  • AWS Simple Queue Service (SQS)

 

 

5. 동기 비동기를 선택했을 때의 장단점

• 비동기 메시징 장점
  
  • 확장성 : 비동기 메시지 브로커들은 큰 볼륨의 데이터를 핸들링하기 위해 설계되었고 수평적으로 추가적인 로드를 핸들링하기 위한 확장을 할 수 있다. 
  • 장애 대응 (fault tolerance) : 비동기 메시지 브로커들은 전형적으로 데이터 레플리케이션이나 자동적으로 failover (장애가 발생했을 때 자동적으로 시스템이 파악하는 것 혹은 서버가 내려가는 것) 하는 거소가 같은 특징을 가지고 장애를 대응하기 위해 설계되었다. 이러한 특징은 장애가 난 상황에서 데이터를 잃어버리지 않는 것을 보장해줄 수 있다. 
  • 디커플링 (Decoupling) : 비동기 메시지 브로커는 소비자나 생산자를 독립적으로 실행하는 것을 도와주면서 데이터의 소비자나 생산자를 디커를링하는 방법을 제공한다. 디커플링은 시스템을 유연하게 향상시킬 수 있고 컴포넌트 (요소) 간에 의존성을 줄여줄 수 있다. 
  • 성능 : 비동기 메시지 브로커는 데이터를 처리하는 것에 대해 특히 데이터의 생산자나 소비자가 많은 경우 높은 성능을 제공해줄 수 있다. 
• 비동기 메시징 단점
  • 복잠성 : 비동기 메시지 브로커는 동기 메시지 브로커에 비해 특히 많은 데이터 생산자나 소빚자가 있는 경우에 관리하거나 구축하는데 더 복잡할 수 있다. 
  • 레이턴시 : 비동기 메시지 브로커는 특히 데이터가 빠른 속도로 진행될 필요성이 있는 상황에서 추가적인 레이턴시를 야기할 수 있다.
  • 신뢰성 : 비동기 메시지 브로커는 요소들간 뎅터 통신을 위한 메시지 패싱 (message passing) 에 의존한다. 그리고 그것은 잠재적인 메시지 유실과 불일치를 야기할 수 있다. 

 

동기 메시징의 장단점은 비동기 메시징 장단점의 완전 반대입니다. 

 

 

마치며

여기까지 Chat GPT에게 Kafka에 대해서 전체적으로 물어봤습니다. MSA를 구현하기 위해 필요한 기술이라는 것만 알고 있었지 이렇게 자세하게는 잘 몰랐던 것 같습니다. 

 

아직 이 분야는 제가 몰라도 되는 부분이긴 하지만 평소에 MSA에 관심이 많았던 터라 이번 기회에 전반적인 내용에 대해서 공부하게 되었습니다. 

 

추후에 Kafka를 이용해 MSA를 구현해보는 실습을 꼭 해보고싶습니다. 그러기위해선 docker라던가 kubernetes와 같은 기술들도 잘 알아야겠죠. 

 

긴 글 읽어주셔서 감사합니다. 오늘도 즐거운 하루 보내세요~

 

 

출처

Chat GPT