Apach Kafka and MQTT

Overview and Comparison

Kafka와 MQTT가 Connected Vehicles, Mobility Service, Smart City와 같은 산업에서 어떻게 쓰일지 다루는 내용이다. 주로 Kafka와 MQTT가 가진 각각의 장단점에 대해 분석한다. 여기서 제시하는 예시는 아래와 같은 각기 다른 구조를 사용한다.

• Lightweight Edge Scenario : Edge단에서 컴퓨팅 파워를 분산해주는 기술 구조에서, 좀 더 경량화된 Edge를 사용한다는 시나리오이다.
• Hybrid Integrations : Application, Data, Files와 같은 요소들을 Cloud와 On-Premises 시스템이 혼합된 환경이다.
• Serverless Cloud Solutions : 서버를 관리할 필요 없이 개발자들이 Application을 빌드하고 실행할 수 있는 Cloud Solution이다.

Gatner라는 미국의 정보기술 연구 및 자문 회사에서, enterprise-generated data가 지금은 10%정도 기존 data center 혹은 cloud 중심에서 벗어나 외부에서 생성되고 프로세싱 되지만, 2025년에 이르면 75%가 Decentralized된다고 한다. 해당 관점에서 MQTT와 Kafka의 조합은 타당하다고 말한다.

이를 이해하기 위해, Kafka와 MQTT의 장단점과 구조에 대해서 알아보아야한다.

Kafka & MQTT

• MQTT : Pub/Sub 기반 Messaging Protocol

  • Open Standard기술 -> 로열티를 지불할 필요가 없다.
  • 많은 오픈소스와 솔루션에서 MQTT의 다른 버전을 구현하고 있다.
  • MQTT는 IoT UseCase를 위해 만들어졌으며 심지어 열악한 장치과 네트워크 상태 또한 포함하는 Use Cases도 지원한다.
  • Data Integration과 Data Processing을 위해 만들어지지는 않았다.

• Kafka : Pub/Sub 기반 분산 데이터 스트리밍 플랫폼

  • MQTT와 비교해서, IoT Platform을 위한 것은 아니다. 그러면 무엇을 위해 만들어졌을까?

    1. Event Streaming Platform
    2. 산업 전반에 걸친 다양한 use case를 위한 Event-Driven Architecture의 기반으로 사용된다.

  • Messaging, Storage, Data Integration, Stram Process을

    • Scalable : Workload가 증가할 시 부하를 감당할 수 있을만한 Resource Capacity를 가지고 있는가?
      • 예상치를 충분히 감당할만한 Resource를 가지고 있는가?
    • Reliable : 신뢰성 있고
    • Elastic : 막대한 양의 Resource 용량에 대해 순간적으로 할당하거나 해제하는 능력
      • 고무줄처럼 탄력있게 리소스를 엄청 할당, 해제하는가?

    사용할 수 있도록 kafka가 제공한다.

MQTT의 장단점

장점

• Lightweight : 최소한의 전력과 패킷량으로 통신하는 프로토콜
• Connectivity가 빈약하고, Latency가 큰 시나리오를 가정하고 만들어졌다.
• High Scalability, High Availability (MQTT Broker로 가능하다.)
• ISO Standard이며, 가장 인기있는 IoT protocol
• (Edge, Data Center, Public Cloud)와 같은 모든 Infrastructures에서 배포 가능하다.

단점

• Pub/Sub Messaging만 가능하다. Streaming Processing안됨, Data Integration안됨
• Asynchronous Processing(Clients가 오랫동안 Offline일 수 있다. )
• Event의 Reprocessing이 없다.

Kafka의 장단점

장점

• Pub/Sub Messaging, Streaming Processing, Data Integration -> 가능하다. (MQTT는 Pub/Sub만 가능하다.)
• High Througput, Large Scale, High Availability
• Producer와 Consumer의 Decoupling을 위한 Long Term Storage and Buffering
• Event의 Reprocessing
• (Edge, Data Center, Public Cloud)와 같은 모든 Infrastructures에서 배포 가능하다.

단점

• 1만개의 Connections을 위해 built되지는 않았다.
• Stable network와 Good Infrastructure이 필요하다.
• IoT Specific한 특징이 없다.
  • No keep alive : 지속적인 연결이 안된다.

선택의 방법

• MQTT의 경우
  • Network가 좋지 않을대,
  • Clients가 1만 이상일때
  • 가벼운 Push-based messaging solution이 필요할때
• Kafka의 경우
  • Powerfule한 Event Streaming Platform이 필요할때

IoT의 경우, 2가지의 경우를 결합한다.

결합 예시

Predictive Maintenance with 100,000 Connected Cars

• 십만개의 Connected Cars의 유지보수 시기를 예측해주는 서비스이다.
• 출처 : https://github.com/kaiwaehner/hivemq-mqtt-tensorflow-kafka-realtime-iot-machine-learning-training-inference

결론

• Kafka와 MQTT의 결합은 IoT Use Cases에 적용하기 위한 최고의 선택이다.
• 이후 포스팅을 통해 Connected Vehicles, Manufacturing, Mobility Services, Smart City에서 어떻게 Kafka MQTT 조합을 사용했는지 알아보자.

출처 : https://www.kai-waehner.de/blog/2021/03/15/apache-kafka-mqtt-sparkplug-iot-blog-series-part-1-of-5-overview-comparison/