MQTT 기반 관리형 Push 메시징

한국 IBM 소프트웨어 사업부

지용득

MQTT 모바일 메시징 프로토콜

IBM이 개발한 모바일 용 양방향 통신 규약

보편성, 유연성 – 오픈되어 있고 어디서든 사용 가능

• www.mqtt.org에 스펙 및 클라이언트 라이브러리 공개

• 2012년 Eclipse 오픈소스 M2M Working Group 내 프로젝트 Paho와 OASIS에서 표준으로 채택되고 IBM의 Contribution

• 다양한 환경의 클라이언트 라이브러리 지원(Android, iOS... C/C++, Java, JS/Node.js, Object C, .Net, Delphi, Perl, PHP, Python...) & 오픈소스

• 모바일 기기와의 효율적 통신을 위한 양방향 Pub/Sub 메시징 패러다임

경량성, 신속성 – 최소화된 프로토콜 오버헤드

• 가장 작은 메시지 사이즈는 2 byte까지 가능: 가변 길이 MQTT 헤더 + 애플리케이션 Payload

• Payload 데이터에 중립적: 별도의 다른 애플리케이션 헤더 불필요

• 클라이언트 라이브러리: C 버전은 30Kb, Java 버전은 100Kb 내외, 제한된 리소스를 갖는 사물에서도 무리없이 동작

• 고성능 메시징: 모바일 기기에서 초당 천 단위의 메시지 교환 실현

MQTT 모바일 메시징 프로토콜

신뢰성 – 세 가지 메시징 신뢰성을 위한 QoS 레벨 제공

• 반드시 전달되어야 하는 중요 메시지에 대한 전달 보장 및 중복 방지

• 0 – 메시지가 최대 1번 전달, 유실 가능성 있음

• 1 – 메시지가 최소 1번 전달, 중복 전달 가능성 있음

• 2 – 메시지가 단 한 번, 정합성 있게 전달

안정성 – 연결을 잃었을 때 이를 보정하기 위한 자체 기능

• Last Will and Testament: 클라이언트가 불시에 연결을 잃을 경우 이벤트가 서버에서 발생, 서버 측에서 연결의 유실 여부를 인지

• Durable Subscription: 서버에 클라이언트의 구독(subscription) 정보 저장됨, 세션 종료 후 재접속 시에도 재작업 없이 Pub/Sub 유지

• Clean Session 기능: 연결 해제 후 다시 연결되었을 때의 이전 세션 유지/삭제 선택

Push 서버: IBM의 MQTT 모바일 메시징 서버 제품

소프트웨어

WebSphere MQTelemetry

어플라이언스

MessageSight

• 인스턴스 당 수십만 이상의 클라이언트 동시 연결 처리 • 초당 수천 이상의 메시지 송수신 • 메시지 당 매우 적은 리소스 사용 • WebSphere MQ를 통한 용이한 기간 업무 연계 • 명령/설정 한 번으로 N개의 클러스터 구성

• 모바일 메시징을 위해 처음부터 설계된 특정 목적 하드웨어 • 천만 단위의 동시 연결, 천만 단위의 초당 메시지 송수신 • 마이크로초 단위의 메시징 처리 능력 • 어플라이언스 특유의 비교할 수 없는 관리성과 확장성 • DMZ 구간에 최적화된 높은 보안성

공공 Push Notification 서비스와의 기능 비교

Google GCM Apple APNS MQTT

양방향 통신 불가: Push만 가능

불가: Push만 가능

지원: 양방향(Push/Push)

컨텐츠 텍스트: 최대 4KB

텍스트: 최대 256B

모든 데이터 유형 지원: 최대 256MB

서비스 수준 준수(SLA) QoS 전송시간(Latency)

미지원: 전송 보장/확인 메커니즘 미제공 일관적이지 않은 전송 시간

미지원: 가장 최근 메시지 한 건만 저장 일관적이지 않은 전송 시간

지원: 전송 보장/확인 메커니즘에 대한 전적인 조절/제어권 확보

보안 네트워크 구간에 대해서는 제공 Google 서버에서 평문화됨 이용자가 제어할 수 없음

네트워크 구간에 대해서는 제공 APNS 서버에서 평문화됨 이용자가 제어할 수 없음

서드파티 개입이 없으므로 고도의 보안성 확보: 양방향(서버/클라이언트) 인증, 구간 암호화

Pub/Sub 메시징 지원 미지원: Push 수신자들에 대해 개별적으로 송신해야 함, 최대 1K 수신자에 대한 동시 송신

미지원: Push 수신자들에 대해 개별적으로 송신해야 함, 최대 연결 당 2K 동시 송신

지원: 매우 많은 수(수십만, 수백만)의 동시 사용자에 대한 메시지 발행

지원 플랫폼 Android iOS, Mac OS X Android, iOS 등의 모바일 플랫폼과 대부분의 서버 플랫폼 및 개발 환경 지원

높은 마케팅 만족도를 위한 Rich Media Push 고지

SKTelecom 11:50

• 오늘날 모바일 사용자들은,

• 이미 기기 당 수십 개 이상의 앱 설치

• Push 경합: 많은 수의 Push 메시지가 경쟁적으로 송신되며 그 수는 증가세에 있음

• 사용자 중 상당수는 Push 메시지 자체를 스팸으로 보아 주목하지 않거나 수신을 거부

• 텍스트 기반의 공공 Push는 ‘고지’ 수준만이 가능

• Push 메시지들 간의 차별화가 어려워 낮은 주목도

• 이를 만회하기 위해 해당 앱의 홍보성 Push는 그 회수가 많아지는 경향이 관찰됨

• MQTT 등을 통한 커스텀 Push의 경우

• 자체 Agent를 통해 Rich Media(이미지, 애니메이션, 리치 텍스트 등) 송신 가능

• 잦은 송신에 대한 사용자의 거부감을 최소화하는 복합형/압축형 메시지 송신 가능

• 단순 홍보가 아닌 실제 서비스와의 연계가 더 긴밀하도록 하는 참여를 유도하는(Engaging) 서비스로 구성

Push 전송 보장 필요 영역

SKTelecom 11:50

2014년 2월 20일 09:00: 김아무개 고객님 계좌 123-456-789에서 2,500,000원이 인출되었습니다.

대구은행 금융 업무

이벤트 MQTT 서버 (Push 중재)

• 어떤 Push 메시지는 매우 중요:

• 중요한 금융 거래 상의 이벤트를 고객에게 알리고자 할 때

• 유료 서비스의 경우 또는 서비스 수준에 대한 합의에 의해 메시지의 전송을 보장하고자 할 때

• 일반적인 Public Push 서버들(GCM/APN)로는 이러한 고품질 서비스가 불가능:

• Google과 Apple은 이와 같은 메시징/서비스 퀄리티에 대한 품질 보증을 제공하지 않음

• 실제 Public Push 서버를 경유한 메시징 송신의 전달율은 90% 내외로 완전하지 못함

무선 네트워크 및 기기의 제약 및 문제로 인한

데이터 전송 취약 구간

메시지 전송 보장을 위한 프로토콜/서버 구현

메커니즘 반드시 전달되어야

하는 이벤트

양방향 통신 필요: Feedback + 응용 서비스 확대

SKTelecom 11:50

지금 상품 문의하기

SKTelecom 11:50

지금 상품 문의하기

고객님, 무엇을 도와드릴까요?

DGB 자유적금 금리가 어떻게 되나요?

이벤트

MQTT 서버 MQTT를 통한 클라이언트

방향의 Push 공지

동일 채널(MQTT)을 통한 양방향 통신

마케터/고객담당

• 단지 Push 방향만 아니라 양방향 통신이 동일한 채널에서 가능하게 되어 Push 메시지 이후 사용자/고객에 대한 유인성 및 사용자 참여도를 비약적으로 높일 수 있음

• 이를 위한 별도의 메시징 인프라가 아닌 공통의 메시징 솔루션을 통해 구성하게 되어 관리 효율성 증대 및 표준화에 용이

SKTelecom 1:50

MQTT Push 서버

Worklight 서버

GCM

APNS

예기치 않은 연결 탈락 시 서버 측에 이벤트 발생

상태 정보

SMS

퍼블릭 Push 송신

커스텀 Push를 활성화했는가?

커스텀 Push 연결

상태인가?

전송 후 회신이

있는가? 또는 성공/실패?

커스텀 Push 송신

퍼블릭 Push에 구독 중인가?

종료

SMS 송신

Push 메시지 전달을 최대로 하는

서버 측 스윗칭 구조

다양한 사용자의 선택에 대비할 수 있는 MQTT와 기존 퍼블릭 Push 서비스를 조합했을 때 가능한 관리형 Push 메시징 인프라의 구현 예시

관리형 Push(퍼블릭 Push 서비스와의 조합)

커스텀 Push는 연결 지향: 데이터/배터리 사용에 대한 고려 필요

SKTelecom 11:50

• GCM/APN 등의 퍼블릭 Push는 해당 모바일 OS를 대표하는 단일 에이전트/데몬이 해당 서버에 ‘상시’ 연결을 유지하여 Push 메시지를 받음:

• 배터리 소모량과 데이터 사용을 최소화하려는 목적

• 일반적인 커스텀 Push 역시 Push 방식이라면 이러한 형태로 에이전트/데몬이 상시 연결을 유지한 채로 동작해야 함

• Push 방식이 아닌 주기적인 Push를 흉내내기 위한 Pulling은 배터리와 데이터 소모가 매우 높음

• 따라서 커스텀 Push를 고려할 때 해당 프로토콜이 다음과 같이 모바일 환경에 최적화되어 있는지 확인 필요

• 매우 작은 프로토콜 오버헤드 발생(의미없는 데이터/배터리 소모 없어야 함)

• 메시지 송/수신 당 적은 데이터 및 배터리 사용률

• 모바일 네트워크 특유의 끊김과 불안정에 대비한 보정 기능이 프로토콜 수준으로 들어가 있어야 함

• 네트워크 불안정으로 연결이 끊긴 후에 재연결 시의 보정 기능이 프로토콜 수준에 구현되어 있어야 함

관리형 Push(퍼블릭 Push 서비스와의 조합)

Worklight 공공 Push 서비스

APN/GCM

Push Dispatcher

확장

분석/통계

구독/사용자 관리

Push 메시지 관리 인터페이스

SMS

Custom Push 엔진 MQTT 기반

모바일 앱

Worklight 클라이언트 통합

Push API

Custom Push 에이전트 - MQTT

메시지 발송 관리

피드백 관리

WebSphere MQ Telemetry 소프트웨어

MessageSight 어플라이언스

1

2

3 Push 이벤트

기간 업무

가용한 메시징 채널로 단계적 이행

IBM 대용량 모바일 메시징 솔루션

관리형 Push 송신 시스템 (구현)

결론: 차별화된 모바일 메시징

퍼블릭 Push는 모바일 영역의 경합으로 인해 효과가 감소 중

• 다수의 앱이 상존하는 현재의 모바일 환경 상 Push는 일상적이고 다소 남용되고 있음

• 환경적 제약으로 인해 앱/서비스의 수준이 햐향평준화되고 상호 차별화가 어려움

모바일에 최적화된 양방향 메시징 프로토콜 MQTT과 서버 구현 MQTelemetry

• 보편성, 유연성, 경량성, 신속성에 메시지 전달의 신뢰도와 보안성을 더한 MQTT를 Push에 적용할 것을 권장

• 양방향 메시징 MQTT를 활용하여 Push 서비스의 개선과 더불어 신규 서비스로의 확장을 꾀함

• 다수의 동시 클라이언트 연결을 관리하기 위한 높은 확장성의 서버 구현이 필요: MQTelemetry

• 사용자의 수용 여부와 관리 포인트의 증가에 대한 우려가 있으나 커스텀 Push를 통해 이를 개선하여 서비스의 질을 향상시킬 수 있음

• 단순 Push 방향뿐 아니라 양방향 메시징을 통해 서비스 플로우에 사용자의 참여를 유도

• 기존 퍼블릭 Push 중재와 조합하여 메시징 신뢰도가 높은 관리형 Push 인프라 구축

감사합니다 Q&A