[발표자료]신뢰적인 MQTT 프로토콜에서 성능향상을 고려한 Publish Queue 기반 데이터 전송 기법
Download as PPTX, PDF0 likes2,144 views
MQTT 프로토콜은 저전력 대비 고성능으로 모바일 디바이스의 실시간 메시지 전송 시스템에 사용한다. 실시간 메시지 시스템을 구축하기 위해서는 신뢰적인 메시지 전송과 메시지간 순서 보장이 반드시 이루어져야 한다. 기존 연구에서는 MQTT 프로토콜의 QoS 2 레벨을 이용하여 메시지 순서를 보장하는 신뢰적인 메시지 시스템을 설계 및 구현하였으나, QoS 1 레벨보다 성능이 낮아진다. 따라서 본 논문에서는 MQTT 프로토콜의 QoS 1 레벨을 사용하고, Publish Queue를 이용하여 순서 보장과 함께 성능 향상을 고려한 메시지 전송 기법을 제안한다.
[발표자료]신뢰적인 MQTT 프로토콜에서 성능향상을 고려한 Publish Queue 기반 데이터 전송 기법
- 1. 신뢰적인 MQTT 프로토콜에서 성능향상을 고려한 Publish Queue 기반 데이터 전송 기법 한국방송통신대학교 대학원 정보과학과 16기 임광규 lahuman@knou.ac.kr
- 2. 개요 통신사 SMS(22원), LMS(33원) , MMS(110원) 메신져 앱 카카오톡, 텔레그램, 라인, 페이스북 (데이터 사용) • 모바일 환경에서의 메시지 전송 2
- 3. 관련 연구 + 메시지 전송 방식 + MQTT + 기존 연구 분석
- 4. • 폴링 (Polling) 메시지 전송 방식 Client Server 요청 요청 응답 응답 N초에 한번씩 요청 이벤트 요청 응답 …… 4 이벤트
- 5. 메시지 전송 방식 • 푸시(push) Client Server 등록 응답 응답 프로토콜 종류 XMPP, HTTP, MQTT, CoAP 등.. 5 이벤트 이벤트 이벤트 이벤트
- 6. MQTT • 특징 – 고정 길이 2바이트 헤더로 작음 – Publish/subscribe 기능 제공 – QoS 3 가지 단계 제공 – 보안 기능 • SSL 지원 / Broker 접속시 ID/PW 지정 가능 – Durable subscribe • 네트워크가 불안정한 상황에서 끊긴 후 재 접속 시 그 동안의 메시지를 재 전송 – Will • 클라이언트가 서버에 처음 접속 시 지정된 Topic과 Payload 전송 – Retain • 마지막으로 발송된 메시지를 MQTT 서버가 보관 6
- 7. MQTT Publish Publish Publish Broker Subscribe Subscribe Subscribe 등록 & 발행 등록 & 구독 • Publish – Subscribe 구조 7
- 8. MQTT • MQTT 에서는 QoS(Quailty of Service) 레벨을 0, 1, 2 의 세 단계로 정의 – QoS 0 한 번만 전달하고 전달 여부는 확인하지 않음 – QoS 1 적어도 한번 이상 전달하고 전달 여부 확인 – QoS 2 4단계의 핸드셰이킹(handshaking)을 통해 정확히 한번만 전달 8
- 9. MQTT • QoS 별 데이터 전송 Client Broker PUBLISH QoS 1 PUBACK PUBLISH QoS 0 PUBLISH QoS 2 PUBREC PUBREL PUBCOMP 9
- 10. 기존연구 분석 메시지 발행 클라이언트 메시지 브로커 서버 메시지 구독 클라이언트 메시지 구독 요청 순번 요청 순번 전송 순번 결합 메시지 생성 메시지 발행 메시지 푸쉬 메시지 순번 확인 메시지 처리 완료누락 메시지 순번 발견 시, 직전 메시지 재 요청 요청 메시지 처리 MQTT 프로토콜 기반의 신뢰적인 메시지 전송 시스템 설계 및 구현 – 황현천(2015) 특징 • MQTT를 이용한 신뢰적인 메시지 전송 시스템 구현 • 순번을 이용하여 메시지의 전송 순서 보장 개선안 • 순번에 대한 초기 통신 필요 • QoS 2 레벨을 이용 10
- 11. Pub Queue 기반 메시지 전송 기법 + MQTT 프로토콜 데이터 구조 + Pub Queue 생성과 메시지 흐름 + 메시지 전송 순서도
- 12. MQTT 프로토콜 데이터 구조 KEY MESSAGE Topic1/group1/user1 {“id”:currentmillis, “msg”:”hello”, sender":"user1"} Topic1/group2/# {“id”:currentmillis, “msg”:”hello” , sender":"user1"} Topic2/group1/user2 {“id”:currentmillis, “msg”:”hello” , sender":"user2"} Topic2/group2/# {“id”:currentmillis, “msg”:”hello” , sender":"user1"} - 데이터 구조는 Key/Value 형식 - id 값은 메시지가 Queue에 저장 될 때 생성하여 중복을 방지 - currentmillis는 1970년 1월 1일 00시(UTC기준) 을 기점으로 밀리초를 계속적으로 증가 시킨 값 12
- 13. Pub Queue 생성과 메시지 흐름 User1 User2 PUB/SUB 등록 Broker PUB Queue PUB Queue Pub Queue 과 deliveryComplete를 이용한 전송 보장 1. Queue 등록 2. Broker 전송 3. deleveryComplet 호출 시 다음 메시지 전송 Pub Sub deleveryComplete 13 PUB/SUB 등록
- 14. Pub Queue 생성과 메시지 흐름 Client Broker PUBLISH QoS 1 PUBACK PUBLISH QoS 2 PUBREC PUBREL PUBCOMP 메시지3 메시지1 메시지2 14
- 15. 메시지 전송 순서도 Pub Queue 생성 Broker 전송 전송 성공 Pub Queue 메시지 추출 Y N Pub Queue 전송 예정 메시지 존재 Y N 시 작 종 료 15
- 16. 시뮬레이션 + 실험 환경 + 실험 결과
- 17. 실험 환경 소프트웨어 환경 OS Windows 10 Message Broker Mosquitto MQTT Library Eclipse Paho Dev. Lenguage JAVA Message Size 26 bytes 하드웨어 환경 CPU Intel Core i3-4300 Memory 8 Gbyte 17
- 18. 실험 결과 0 5 10 15 20 25 1 회 2 회 3 회 4 회 5 회 QoS 2 Pub Queue 18
- 19. 결과 • MQTT 프로토콜에서 Publish Queue 기반 데이터 전송 장점 – 성능 2배 향상 – 네트워크 트래픽과 제한된 자원 이유로 QoS 2레벨 보다 QoS 1 레벨에서 안정적 메시지 전송 중요 – 대표적인 클라우드 서비스(AWS, AZURE, Google Cloud)에 서는 QoS 2 레벨 지원 않음 19
- 20. 감사합니다.
Editor's Notes
- #2: 안녕하세요 저는 방송통신 대학원 정보과학과 16기 임광규 입니다. 제가 발표하려는 논문 제목은 “신뢰적인 MQTT 프로토콜에서 성능향상을 고려한 Publish Queue 기반 데이터 전송 기법”입니다.
- #3: 모바일 기기는 인스턴스 메시지를 주고받는 주요 방법이되었습니다. 초기 메시지 전송은 통신사에서 제공하는 SMS, LMS, MMS로 건별 비용이 발생하고 상대방의 메시지 확인 여부를 알려 주지 않는 단점등이 있었습니다. 스마트 폰의 등장 이후, 데이터를 사용하는 메신져 앱이 활성화 되었고 비용이나, 메시지 확인 여부 등의 부가 기능을 제공하여 많은 사람들이 사용하고 있습니다. 그러나 독자적인 프로토콜로 구축된 메신저 애플리케이션은 확장성과 기능의 문제로 인해 표준 프로토콜 기반의 메시지 푸시 플랫폼으로 바뀌게 되었고, MQTT 프로토콜은 단순함과 편리함 덕분에 많은 응용프로그램에서 사용되고 있습니다.
- #4: 관련 연구로 메시지 전송방식과 MQTT, 그리고 기존 연구 분석이 있습니다.
- #5: 인터넷을 이용하여 메시지를 전송하는 방식에는 폴링(polling) 방식과 푸시(push) 방식이 있습니다. 폴링 방식은 모바일 디바이스에서 주기적으로 서버에 신규 메시지가 존재하는지를 확인하여 신규 메시지가 존재하면 모바일 기기로 수신합니다.. 이는 주기적으로 서버에 접속해야 하고, 불필요하게 네트워크 데이터를 낭비한다는 단점을 가지게 됩니다.
- #6: 푸시 방식은 서버에서 신규 데이터가 발생할 경우에 각 모바일 디바이스로 전송합니다. 이는 폴링 방식보다 저비용으로 구현할 수 있어 많은 메시지 전송 시스템에서 사용되는 방식입니다. 푸시 방식은 XMPP와 HTTP, MQTT 그리고 CoAP 등의 프로토콜을 이용한 메시지 전송 시스템에서 사용되고 있습니다.
- #7: MQTT 프로토콜은 1999년 IBM에서 발표한 메시지 푸시 프로토콜로 화면과 같은 특징이 있으며, 스마트폰과 같은 제한된 컴퓨팅 성능과 빈약한 네트워크 연결 환경에서 동작하도록 설계된 대용량 메시지 전달 프로토콜로 낮은 대여 폭과 긴 지연 시간에도 불구하고 신뢰적인 메시지를 전송하도록 설계되어있습니다. 또한 MQTT 프로토콜은 2013년 OASIS(Organization for the Advancement of Structured Information Standards)에서 사물 인터넷을 위한 메시지 프로토콜로 선정하였으며, 다양한 인스턴스 메신저에서 사용되고 있습니다..
- #8: MQTT 프로토콜은 경량의 메시지 전송 프로토콜로써 하나의 Broker서버와 두 종류의 클라이언트로 구성됩니다. Broker 서버는 특정 토픽에 대해 메시지를 발행하는 Publish와 구독하는 Subscribe 사이에 중계인으로서 역할을 하고, 특정 주제에 대해 다자간 채팅이나 메시지를 서로 공유하는 경우에 구독자는 구독(Sub)을 하고, 발행자는 발행(Pub)하는 구조입니다.
- #9: MQTT에서는 QoS 레벨을 0, 1, 2의 세 단계로 정의합니다. QoS 0: 한 번만 전달하고 전달 여부는 확인하지 않음 QoS 1: 적어도 한 번 이상 전달하고 전달 여부 확인 QoS 2: 4단계의 핸드 셰이킹(handshaking)을 통해 정확히 한 번만 전달(신뢰적) 발행자와 구독자 모두 QoS를 지정할 수 있으나 발행자가 지정한 최대 QoS 레벨이 우선시 됩니다.
- #10: QoS 레벨별 통신은 그림과 같습니다. QoS 1 레벨 이상에서만 MQTT에서 제공되는 deliveryComplete을 이용하여 메시지 전송 성공 여부가 확인 가능합니다. 하지만 QoS 1 레벨은 메시지가 한 번 이상을 전달될 수 있기 때문에 응용프로그램에서 메시지에 대한 중복에 대한 처리를 구현해야 합니다.
- #11: MQTT 프로토콜 기반의 신뢰적인 메시지 시스템 설계 및 구현에서는 QoS 2 레벨의 MQTT 프로토콜 기반으로 신뢰적인 메시지 전송 시스템을 설계하고 구현였습니다.. 순서도 그림과 같이 신뢰적인 메시지 전송 시스템에 대한 요구 사항을 단일 메시지의 전송 여부와 메시지 사이에 순번이 보장되어 메시지가 순차적으로 도착하고, 누락 메시지를 발견한 상황에 해당 메시지를 재요청하여 수신 받을 수 있도록 설계 하였으며. 신뢰적인 메시지 전송 시스템은 메시지를 전송할 때 순차적이며 긴 지연 시간 없이 메시지가 전송되는 것을 검증 하였습니다. 기존 연구의 최종 실험에서는 MQTT 프로토콜만을 사용했을 때보다 서버의 자원 사용이 증가하나, 폴링 방식보다는 저비용이며 메시지가 신뢰적으로 전송되는 것을 검증 하였습니다. 기존 연구의 순번에 대한 초기 통신과 QoS 2 레벨을 이용한 부분을 개선한, “Pub Queue 기반의 메시지 전송 기법”에 대하여 설명 드리겠습니다.
- #12: Pub Queue 기반의 메시지 전송 기법에서 사용되는 전송 메시지 구조와 메시지의 흐름, 순서에 대한 전체 설계를 설명 드리겠습니다.
- #13: 데이터 구조는 Key/Value 형식입니다. 기본적으로 특정키에 데이터를 저장하는 방식으로 되어으며, Key 데이터는 표와 같은 구조를 가지게 됩니다. Key는 MQTT에서 주제로 묶여 발행되는 토픽으로 /(슬러쉬)로 이루어진 계층 구조를 가지며, 메시지의 경우 JSON 형태를 띄우며, id 값으로 currentmillis 값을 사용하여 publish에서 Broker로, Broker에서 Subscribe으로 전송한 시간을 확인합니다.
- #14: User1과 User2에서 모바일 애플리케이션이 구동되면 메시지 전송을 위한 한 개의 Pub Queue를 생성하고, 사용자가 메시지 전송 시 Pub Queue에 저장을 합니다. 메시지의 전송 성공이 deliveryComplete를 통해 확인되면 다음 메시지를 전송합니다.
- #15: deliveryComplete 기능은 QoS 1 레벨이상일 경우만 사용이 가능하며, MQTT 프로토콜의 스펙에 따라 그림와 같이 QoS 1 레벨의 경우 PUBACK이 수신되면 deliveryComplete가 호출되고, QoS 2 레벨의 경우 PUBCOMP 가 수신되면 deliveryComplete가 호출됩니다. delieveryComplete를 이용해 Broker로 메시지 전송의 성공 시 다음 메시지를 Pub Queue에서 추출 하여 Broker로 전송합니다. Sub 클라이언트에서는 수신되는 메시지의 순서가 섞여서 데이터를 수신 할 경우가 발생할수 있습니다. 이때, 클라이언트에서 id 값인 currentmillis를 기준으로 수신된 메시지의 id가 기존 id 보다 작을 경우 해당 메시지의 위치를 기존 id 보다 상위에 표출하도록 순서 보정을 하여 화면에 출력해야 합니다.
- #16: Pub Queue 기반의 메시지 전송은 Pub Queue를 생성하고 메시지 유입이 되면 한 개의 메시지를 추출하여 Broker로 전송합니다. 이때 전송이 실패하게 되면 Broker에 추출한 메시지를 재전송한다. 전송에 성공할 경우 Pub Queue에 다음 메시지 존재 여부를 확인하고 존재할 경우 다음 메시지를 추출하고 전송하는 과정을 되풀이합니다. Broker에서는 id 값으로 중복 확인이 가능 합니다.
- #17: 시뮬레이션에 대한 설명입니다.
- #18: 실험 환경은 표와 같은 소프트웨어 환경과 하드웨어 환경으로 구성합니다. 하드웨어로는 Broker와 한 대와 클라이언트(Pub/Sub) 두 대로 구성하였습니다. 모든 메시지 크기는 동일하게 26 bytes이며 0001∼1000 까지 메시지 내에 순서를 가지고 있습니다.
- #19: 실험은 QoS 1레벨에서 Pub Queue 기반 메시지 전송 기법과 QoS 2 레벨의 성능을 비교합니다. QoS 1 레벨로 Pub Queue를 생성하고 Broker에 등록 후 메시지를 전송하는 테스트와 QoS 2 레벨로 Broker에 메시지를 전송하는 테스트를 1,000건의 메시지로 각 5회씩 진행하였습니다. 실험 결과에서는 그림과 같이 QoS 1 레벨의 Pub Queue를 사용한 결과가 QoS 2 레벨을 사용한 테스트 결과보다 약 2배의 성능 차이를 보였습니다. 또한 Pub Queue와 deliveryComplate를 이용하여 메시지를 전송 시 0001∼1000 까지 메시지 누락 없이 순서대로 Broker 도착을 확인하였습니다.
- #20: 기존 연구에서는 MQTT 프로토콜의 QoS 2 레벨을 이용하여 메시지 순서를 보장하는 신뢰적인 메시지 시스템을 설계 및 구현하였으나, QoS 1 레벨보다 성능이 낮아지는 문제점이 있었습니다.이를 해결하기 위해 본 논문에서는 MQTT 프로토콜의 QoS 1 레벨을 사용하고, Pub Queue를 이용하여 전송 보장과 함께 성능 향상을 고려한 메시지 전송 기법을 제안하였습니다. 성능이 최대 2배 이상 향상된 것을 성능 평가를 통해 확인하였으습니다. 서비스 운영에서는 네트워크 트래픽과 제한된 자원을 이유로 QoS 2 레벨보다 QoS 1 레벨에서 안정적으로 메시지를 전송하는 것이 중요합니다. 실제 예로 대표적인 클라우드 서비스인 AWS, AZURE, GOOGLE CLOUD에서는 MQTT 프로토콜의 QoS 2 레벨을 지원하지 않습니다.
- #21: 감사합니다.