Rancang Bangun IOT Cloud Platform Berbasis Protokol Komunikasi MQTT

Transkripsi

1 Jurnal Pengembangan Teknologi Informasi dan Ilmu Komputer e-issn: X Vol. 2, No. 2, Februari 2018, hlm Rancang Bangun IOT Cloud Platform Berbasis Protokol Komunikasi MQTT Moh. Wildan Habibi 1, dhitya Bhawiyuga 2, chmad Basuki 3 Program Studi Teknik Informatika, 1 mohwildannhabibi@gmail.com, 2 bhawiyuga@ub.ac.id, 3 abazh@ub.ac.id bstrak Internet of Things (IoT) merujuk pada suatu jaringan yang menghubungkan berbagai perangkat dalam dunia fisik dengan berbagai protokol berbeda. Namun, terdapat keterbatasan dalam hal komputasi dan penyimpanan karena perangkat IoT hanya menggunakan komponen penyimpanan dan komputasi yang terbatas. Sedangkan cloud adalah lingkungan virtual yang umumnya memiliki kapasitas komputasi dan penyimpanan yang sangat besar. Dengan mengintegrasikan cloud dengan IoT, perangkat IoT diharuskan untuk mengalihkan proses komputasi dan penyimpanan menuju cloud, sehingga cloud dapat menyelesaikan keterbatasan pada perangkat IoT. Terdapat dua masalah utama dari integrasi tersebut, yaitu heterogenitas dan keamanan. Heterogenitas yaitu banyaknya ragam perangkat yang dapat berkomunikasi dengan cloud, sehingga perlu digunakan protokol komunikasi tertentu agar semua perangkat dapat terhubung dengan cloud. Keamanan sendiri merujuk pada validitas perangkat IoT yang mengirimkan data. Dari penjelasan sebelumnya, maka penelitian ini membuat sebuah rancang bangun IoT cloud platform menggunakan protokol komunikasi MQTT untuk menyelesaikan masalah heterogenitas. Sedangkan untuk memastikan validitas dari perangkat IoT yang mengirimkan data, dibangun sebuah mekanisme manajemen perangkat IoT, autentikasi, dan otorisasi. Hasil pengujian performa menunjukkan, sistem yang dibangun mampu menangani publisher hingga 250 publisher dalam tiap detik. Kata kunci: IoT, cloud, platform, mqtt,, authorization. bstract Internet of Things (IoT) referring to a network that linking various device in the physical world with a variety of different protocols. However, there are limitations in terms of computing and storage because IoT device only use minimum computational and storage components. While cloud is a virtual environment that generally has a big capacity of computing and storage. By integrating cloud and IoT, it is necessary to divert IoT device s computational process and storage towards cloud, so that cloud can resolve the limitations on the IoT device. There are two main issues in the integration, heterogeneity and security. Heterogeneity refers to number range of devices that can communicate with the cloud, so it is necessary to use specific communication protocol so that all devices can be connected to the cloud. Security refers to the validity of the IoT devices that can transmit data to the cloud. From the previous explanation, then this research makes an architecture of IoT cloud platform that use MQTT communication protocol to resolve the problem of heterogeneity. Whereas to ensure the validity of IoT devices that can transmit data, constructed a mechanism to manage IoT device,, and authorization. The performance test results showed, built systems capable of handling the publisher up to 250 publishers in each second. Keywords: IoT, cloud, platform, mqtt,, authorization. 1. PENDHULUN Internet of Things (IoT), merujuk pada suatu jaringan yang menghubungkan berbagai perangkat dalam dunia fisik dengan berbagai protokol berbeda (Guoqiang, nming, Chao, & nxu, 2013). Penerapan IoT menjadikan aktivitas dalam berbagai bidang dapat saling terhubung melalui Internet, serta menjadi lebih mudah dan efisien. Contohnya seperti, seorang petani dapat mengetahui suhu dan kelembapan lahannya dari tempat yang lain, karena Fakultas Ilmu Komputer Universitas Brawijaya 479

2 Jurnal Pengembangan Teknologi Informasi dan Ilmu Komputer 480 perangkat IoT yang tersebar pada lahan tersebut saling berbagi informasi dan dapat diakses melalui Internet. Things atau perangkat dalam IoT, merupakan perangkat fisik yang memiliki identitas, atribut, karakteristik tertentu, dan dapat berkomunikasi antara satu dengan yang lain. Namun, terdapat keterbatasan dalam hal komputasi dan penyimpanan karena hanya menggunakan komponen penyimpanan dan komputasi yang terbatas (Botta, Donato, Persico, & Pescape, 2016). Sebagai contoh, perangkat IoT tidak dapat menyimpan berbagai data yang telah dihimpun hingga bertahuntahun, atau perangkat IoT tidak dapat melakukan komputasi kompleks. Dengan keterbatasan tersebut, salah satu solusi yang dapat diberikan yaitu mengalihkan proses komputasi dan penyimpanan ke sistem yang lain, contohnya cloud computing platform. Zhang et al (2010) menyebutkan bahwa cloud adalah kumpulan objek computing resources yang dapat dikonfigurasi secara tepat dan diakses dari mana saja, serta resources-nya dapat ditambahkan atau dikurangi dengan cepat dan mudah. Penelitian tersebut juga menyebutkan karakteristik dari sebuah cloud, diantaranya adalah cloud secara virtual memiliki kemampuan yang tidak terbatas dalam hal penyimpanan dan komputasi. Hal itu mengisyaratkan bahwa cloud memiliki teknologi yang mampu menjawab tantangan pada perangkat IoT. Jika cloud digunakan sebagai solusi terhadap tantangan IoT, maka terdapat beberapa potensi masalah yang perlu diselesaikan (Botta, Donato, Persico, & Pescape, 2016). Secara umum, terdapat dua masalah utama dari integrasi tersebut, yaitu heterogenitas dan keamanan. Heteroginitas yaitu banyaknya ragam perangkat yang dapat berkomunikasi dengan cloud, sehingga diperlukan suatu standar komunikasi sehingga semua perangkat dapat berkomunikasi dengan cloud. Keamanan sendiri merujuk pada validitas perangkat IoT yang mengirimkan data. Oleh karena itu, diperlukan suatu mekanisme kerja yang dapat mengidentifikasi suatu perangkat dan memeriksa valid tidaknya perangkat IoT yang mengirimkan data. Dari pembahasan sebelumnya, maka penelitian ini membuat sebuah rancang bangun IoT cloud platform, sebagai alternatif yang mampu mendukung komunikasi berbagai perangkat IoT dan menjamin validitas dari perangkat yang mengirimkan data. Untuk menyelesaikan masalah heteroginitas pada integrasi IoT dan cloud, perangkat IoT cloud platform ini menggunakan protokol komunikasi MQTT. Protokol MQTT digunakan karena keandalan dalam pengiriman paket, dan penggunaan bandwidth yang kecil. Menurut OSIS (2015), MQTT memiliki karakteristik yang mendukung pada kemampuan yang dimiliki oleh perangkat IoT, yaitu dapat bekerja pada low power, dan menggunakan bandwidth yang kecil. Sedangkan untuk memastikan validitas dari perangkat IoT yang mengirimkan data, peneliti akan membangun sebuah mekanisme manajemen perangkat IoT,, dan authorization. 2. RSITEKTUR KOMUNIKSI PUBLISH/SUBSCRIBE 2.1. Pengertian Prinsip dari model komunikasi publish / subscribe yaitu beberapa komponen yang menginginkan sejumlah informasi yang sesuai dengan topik mereka inginkan dengan cara mendaftarkan topik apa yang diinginkan. Proses mendaftarkan topik ini disebut dengan subscribe. Sedangkan kumpulan komponen yang menginginkan informasi tersebut disebut sebagai subscriber. Komponen lain membuat atau memberikan informasi terkait dengan yang diinginkan oleh subscriber dengan cara melakukan publish informasi. Komponen itu disebut sebagai publisher. Sedangkan entitas yang bertugas untuk memastikan bahwa suatu paket informasi dapat terkirim dari publisher menuju subscriber disebut sebagai. Broker bertugas untuk mengkoordinasi keinginan akan informasi dari para subscriber, dan subscriber biasanya secara eksplisit akan melakukan kontak dengan untuk melakukan subscribe (Hunkeler, Truong, & Clark, 2015). Gambar 1. Model Komunikasi Topic-Based Publish/Subscribe 2.2. MQTT (Message Queue Telemetry Transport) MQTT merupakan singkatan dari Message

3 Jurnal Pengembangan Teknologi Informasi dan Ilmu Komputer 481 Queue Telemetry Transport. Ini merupakan protokol komunikasi publish/subscribe topicbased yang sangat sederhana dan ringan, yang didesain untuk alat yang memiliki kemampuan terbatas, bandwidth yang rendah, latency yang tinggi atau jaringan yang kurang dapat diandalkan. Prinsip dari desain ini adalah untuk meminimalkan penggunaan bandwidth jaringan dan kebutuhan sumber daya pada perangkat serta pada waktu yang sama juga berusaha untuk memastikan keandalan dan kepastian dari pengiriman data. Prinsip yang ada ini juga memunculkan beberapa ide protokol mengenai machine-to-machine (M2M) atau IoT yang menginginkan perangkat di dunia untuk saling terhubung, dan untuk aplikasi mobile dimana bandwidth dan daya baterai pada keadaan yang cukup (MQTT, 2016). 3. REKYS KEBUTUHN Rekayasa kebutuhan untuk menganalisis beberapa kebutuhan yang diperlukan pada penelitian ini. Rekayasa kebutuhan pada penelitian ini dijelaskan sebagai berikut: 3.1. nalisis Kebutuhan Pengguna Kebutuhan pengguna pada penelitian ini yaitu node sensor dapat melakukan pengiriman data sensor menuju. Pada sisi web app, akan ditampilkan data - data yang telah diterima dari node sensor dalam bentuk tabel nalisis Kebutuhan Sistem Kebutuhan sistem IoT cloud platform yang dibangun pada penelitian ini dijelaskan sebagai berikut: a. Node sensor dapat memperoleh data dari sensor yang dimiliki oleh node sensor tersebut, b. Node sensor dapat mengirimkan data menuju menggunakan protokol MQTT, c. Broker dapat menerima koneksi yang dibuat oleh publisher (node sensor) dan subscriber, serta dapat menerima data yang dikirim oleh node sensor. Broker melakukan proses terhadap setiap koneksi yang akan dibangun oleh publisher dan subscriber, serta melakukan proses authorization pada setiap data yang akan diterima oleh dan data yang akan diteruskan dari ke subscriber. Jika lolos tahap tersebut, maka data akan di teruskan ke subscriber, d. Subscriber dapat menerima data dari dan dapat mengolah data - data yang telah diperoleh sebelumnya untuk dimasukkan ke dalam database atau tidak, e. Web app dapat menampilkan data - data yang telah dikumpulkan pada database. Web app dapat melakukan Create, Read, Update, dan Delete pada database yang digunakan. 4. PERNCNGN SISTEM 4.1. Gambaran Umum Sistem Gambar 2. lur Komunikasi Data Sistem Secara umum terlihat bahwa konsep komunikasi yang digunakan merupakan konsep komunikasi arsitektur umum dari publish subscribe MQTT. Protokol MQTT memiliki sebagai pusat pertukaran informasi antara publisher dan subscriber atau istilah lain dikenal sebagai MQTT server. Publisher yaitu node sensor mengirimkan informasi data sensor yang telah didapat menuju dengan melakukan inisialisasi topik. Dimana topik digunakan sebagai alamat tujuan yang dikirimkan melalui dari publisher sehingga tidak semua dapat menerima informasi tersebut jika tidak mengetahui topik yang digunakan. Sedangkan subscriber untuk mendapatkan pesan dari publisher, subscriber harus melakukan request atau subscribe topik yang sama dengan topik yang dikirimkan publisher jika ingin mendapatkan informasi yang telah dipublish oleh publisher sebelumnya. Kemudian membalas informasi subscriber dengan menyesuaikan identitas topik yang sama antara publisher dan subscriber, dan jika topik sama, maka akan meneruskan data yang diperoleh dari publisher.

4 Jurnal Pengembangan Teknologi Informasi dan Ilmu Komputer lur Kerja Penanganan Publisher sama. Node sensor membangun koneksi dengan Publisher node sensor publish data berupa data yang didapat dari sensor menuju menggunakan topik tertentu Broker mendeteksi koneksi baru, meneruskan ke auth server untuk check Respon diterima, dan diteruskan ke publisher Broker mendeteksi permintaan publish, meneruskan ke auth server untuk check authorization Respon diterima, dan menerima publish data sensor sesuai topik dari publisher uth server mendeteksi permintaan check, melakukan proses dan memberikan respon uth server mendeteksi permintaan check authorization, melakukan proses dan memberikan respon Gambar 3. lur Kerja Penanganan Publisher Pada Gambar 3 ditunjukkan bahwa proses operasi pada sistem dimulai pada dimulai dari node sensor yang akan melakukan publish data maka diharuskan untuk membangun koneksi terlebih dahulu. Broker mendeteksi adanya permintaan koneksi dari publisher tersebut, maka data koneksi yang dikirimkan oleh publisiher akan diambil dan dikirim menuju auth server untuk dilakukan check. uth server menerima permintaan tersebut, kemudian memproses menggunakan data yang dikirim oleh, apakah publisher tersebut dapat melakukan koneksi. Hasil dari check tersebut dijadikan respon oleh auth server, kemudian dikirimkan kembali menuju, dan mengirim ke publisher. Jika respon yang diterima oleh publisher yaitu mengijinkan untuk melakukan koneksi terhadap, maka tahap selanjutnya publisher akan melakukan publish data dengan topik yang telah ditentukan oleh publisher. Permintaan melakukan publish data akan dikirimkan terlebih dahulu oleh publisher menuju, dan akan mengirim data publish tersebut ke auth server untuk dilakukan check authorization. Pada auth server melakukan check authorization dan hasil dari pemeriksaan tersebut akan bertindak sebagai respon dari auth server kepada. Broker menerima respon dari auth server tentang check authorization, jika respon tersebut bernilai positif, maka data publish akan disimpan sementara oleh yang nantinya jika ada subscriber dengan topik yang sama melakukan subscribe, maka data tersebut akan diteruskan menuju subscriber tersebut. Jika respon tersebut bernilai negatif, maka tidak akan menyimpan data publish tersbut dan tidak akan meneruskannya menuju subscriber meskipun dengan topik yang 4.3. lur Kerja Penanganan Subscriber Subscriber membangun koneksi dengan Subscriber melakukan subscribe topik menuju Data sensor diterima subscriber, dan dimasukkan ke dalam database Broker mendeteksi koneksi baru, meneruskan ke auth server untuk check Respon diterima, dan diteruskan ke subscriber Broker mendeteksi permintaan subscribe, meneruskan ke auth server untuk check authorization Respon diterima, dan meneruskan publish data sensor sesuai topik dari publisher kepada subscriber uth server mendeteksi permintaan check, melakukan proses dan memberikan respon uth server mendeteksi permintaan check authorization, melakukan proses dan memberikan respon Gambar 4. lur Kerja Penanganan Subscriber Pada Gambar 4 ditunjukkan bahwa proses operasi pada sistem dimulai pada dimulai dari subscriber yang akan melakukan susbscribe pada topik tertentu maka diharuskan untuk membangun koneksi terlebih dahulu. Broker mendeteksi adanya permintaan koneksi dari subscriber tersebut, maka data koneksi yang dikirimkan oleh subscriber akan diambil dan dikirim menuju auth server untuk dilakukan check. uth server menerima permintaan tersebut, kemudian memproses menggunakan data yang dikirim oleh, apakah subscriber tersebut dapat melakukan koneksi. Hasil dari check tersebut dijadikan respon oleh auth server, kemudian dikirimkan kembali menuju, dan mengirim ke publisher. Jika respon yang diterima oleh subscriber yaitu mengijinkan untuk melakukan koneksi terhadap, maka tahap selanjutnya subscriber akan melakukan subscriber pada topik yang telah ditentukan oleh subscriber. Permintaan melakukan subscribe pada topik tertentu akan dikirimkan terlebih dahulu oleh subscriber menuju Perancangan Skema Database Pada perancangan skema database ini akan digambarkan skema database yang akan digunakan. Database menggunakan MongoDB, yang merupakan sistem basis data berbasis document-oriented, dimana data direpresentasikan dalam dokumen-dokumen BSON (Binary JSON).

5 Jurnal Pengembangan Teknologi Informasi dan Ilmu Komputer 483 _id: <ObjectId1> username: <string> password: <string> <string> firstname: <string> is_admin: <int> _id: <ObjectId2> user: <ObjectId1> label: <string> secretkeyl: <string> subsperday: <int> subsperdayremain: <int> is_public: <int> _id: <ObjectId3> Label: <string> _id: <ObjectId4> node: <ObjectId2> sensor: <ObjectId3> data: <int> timestamp: <ISODate> Gambar 5. Skema Database MongoDB yang Digunakan Pada Gambar 5, terdapat 3 koleksi atau dapat dianggap seperti tabel jika pada database relasional. Koleksi tersebut terdiri dari User, Nodes, dan Subscriptions. Setiap koleksi memiliki field yang menjadi acuan dalam mengisi koleksi tersbut. Isi dari sebuah koleksi adalah dokumen atau dapat dianggap seperti record jika pada database relasional. Koleksi User berguna untuk menyimpan data yang berhubungan dengan user atau pengguna yang memiliki hak untuk berkontribusi pada sistem. Koleksi Nodes berguna untuk menyimpan data yang berhubungan dengan mikrokontroler yang digunakan sebagai node sensor. Koleksi Sensors sedikit berbeda dengan koleksi yang lain, karena koleksi ini berada didalam sebuah koleksi, yaitu koleksi Nodes. Koleksi Sensors berguna untuk menyimpan data yang berhubungan dengan sensor yang yang dimiliki atau digunakan oleh mikrokontroler. Koleksi Subscriptions berguna untuk menyimpan data - data yang telah dikirimkan oleh node sensor. Keseluruhan koleksi tersebut akan saling berhubungan antara satu dengan yang lain melalui field _id yang digunakan oleh koleksi yang lain Perancangan uth Server uth Server bertugas untuk melakukan pemeriksaan mengenai koneksi yang akan dilakukan pada. Pemeriksaan tersebut meliputi, superuser, dan authorization. Start Menunggu check request dari da check request dari Check Check superuser Check authorization Melakukan check pada database Melakukan check user superuser pada database Melakukan check authorization pada database plikasi berhenti Memberikan respond ke Gambar 6. lur Kerja uth Server Pada Gambar 6, menggambarkan End flowchart algoritma dari uth Server. Jika uth Server berjalan, maka akan selalu dalam kondisi siap digunakan jika tidak ada check request dari. Jika terdapat request, maka tindak lanjut dari setiap permintaan akan berbeda di dalam prosesnya, namun semua akan berakhir dengan memberikan respon ke Perancangan Broker Broker bertugas untuk menerima publish data dari publisher dengan topik tertentu, kemudian meneruskan publish data ke subscriber yang melakukan subscribe dengan topik yang sama. Start Menunggu permintaan koneksi Koneksi dengan Publisher Koneksi dengan Subscriber B Koneksi terbangun Publisher publish data Menerima publish data dari publisher sesuai dengan topik yang digunakan Koneksi tetap berjalan End Koneksi terbangun da publish data terbaru Meneruskan publish data sesuai dengan topik yang di subscribe Koneksi tetap berjalan Gambar 7. lur Kerja Broker Pada Gambar 7, menggambarkan flowchart algoritma dari sebagai MQTT Server. Diawali dengan menjalankan fungsi MQTT Broker, kemudian jika ada publish data terbaru dari publisher, maka akan diterima dan disimpan oleh. Ketika subscriber melakukan subscribe pada topik yang sama dengan publisher, maka data publish yang telah diterima oleh akan diteruskan ke subscriber Perancangan Subscriber Subscriber bertugas untuk menerima seluruh publish data yang sudah diperiksa oleh, serta memasukkannya ke database. Pada Gambar 8, menggambarkan flowchart algoritma dari subscriber. Diawali dengan koneksi dengan. Broker akan melakukan pemeriksaan dari setiap koneksi yang akan dibangun. Setelah terkoneksi, maka subscriber akan siap untuk menerima publish data. Jika terdapat publish data yang diterima, maka subscriber akan memeriksa data payload apakah sudah memenuhi parameter yang sudah ada pada perancangan publisher. B

6 Jurnal Pengembangan Teknologi Informasi dan Ilmu Komputer 484 Start Membangun koneksi dengan Berhasil terkoneksi dengan Subscribe topic yang digunakan Menerima data terbaru dari topik yang disubscribe Koneksi terputus plikasi berhenti End Mendapatkan data payload terbaru Memeriksa kesamaan data payload dengan skema database Data payload Sesuai dengan skema database Data payload dimasukkan ke database Gambar 8. lur Kerja Subscriber Data payload tidak dimasukkan ke database Jika sudah sesuai, maka subscriber akan mencocokkan dengan database yang digunakan. Jika sesuai, maka publish data tersebut akan disimpan pada database. 5. HSIL PENGUJIN PERFORM Pengujian performa pertama yaitu pengujian delay yang terjadi saat pengiriman data oleh publisher hingga diterima subscriber tanpa melakukan input pada database. Pengujian dilakukan dengan menggunakan variasi publisher sebanyak 100, 250, dan 500 publisher yang mengakses dalam waktu yang sama. Hasil pengujian dapat dilihat pada Tabel 1 berikut: Tabel 1. Hasil Pengujian Waktu Delay Delay verage verage verage Publisher Delay (ms) Publisher Delay (ms) Publisher Delay (ms) , , , , , , , , , , , ,882 Dari hasil pengujian pada Tabel 1, waktu delay yang terjadi juga berbanding lurus dengan jumlah publisher yang melakukan publish data. Waktu delay yang terjadi saat pengiriman data oleh publisher sebanyak 100 dan 250 publisher, memiliki waktu delay di bawah 1000 ms. Sedangkan pada pengujian dengan jumlah publisher sebanyak 500, menunjukkan waktu delay di atas 1000ms, sehingga hasil tersebut dapat dikatakan lebih buruk jika dibandingkan dengan hasil dengan jumlah publisher di bawah 500 publisher. Dari penjelasan tesebut dapat disimpulkan, sistem dapat menangani jumlah publisher sebanyak < 500 publisher dalam satu waktu. Berikutnya yaitu pengujian jumlah publisher yang dapat ditangani tiap detik. Pengujian dilakukan dengan menggunakan variasi publisher sebanyak 100, 250, dan 500 publisher yang mengakses dalam waktu yang sama. Hasil pengujian dapat dilihat pada Tabel 2 berikut: Tabel 2. Hasil Pengujian Tingkat Skalabilitas Scalability Publisher Responded Success rate % Responded < 1 s % % % % % % % % 187 Dari Tabel 2, dapat dilihat hasil pengujian yang telah dilakukan, menunjukkan bahwa sistem mampu untuk menangani jumlah publisher hingga sebanyak 500 publisher, dengan tingkat kesuksesan sebesar 99%. Disamping itu, dari hasil pengujian menunjukkan, dengan pengujian sebanyak 500 publisher, rata-rata jumlah publisher yang tertangani di bawah 1 detik berjumlah 187 publisher. 6. KESIMPULN Berdasarkan hasil perancangan, implementasi, dan pengujian yang telah dilakukan sebelumnya, maka penulis mendapatkan kesimpulan sebagai berikut: 1. Mekanisme manajemen perangkat IoT,, dan authorization dapat dilakukan dengan membangun sebuah auth server berbasis protokol HTTP. uth Server merupakan komponen yang bertugas untuk memeriksa koneksi yang akan dilakukan ke dan data yang akan melewatinya. Pemeriksaan tersebut meliputi, superuser, dan authorization. uthentication bertujuan

7 Jurnal Pengembangan Teknologi Informasi dan Ilmu Komputer 485 untuk memastikan validitas dari perangkat IoT yang mengirimkan data. Superuser bertujuan untuk memastikan validitas dari subscriber. Sedangkan authorization bertujuan untuk memastikan validitas dari topik yang digunakan oleh perangkat IoT saat mengirimkan data. 2. IoT cloud platform dibangun menggunakan protokol MQTT yang berpola publishsubscribe dengan arsitektur end-to-cloud. Dalam hal ini, end yang dimaksud merupakan perangkat IoT (node sensor) yang berada pada lapangan, bertindak sebagai publisher yang mengirimkan data yang telah diperoleh. Pada sisi lain, cloud yang dimaksud merupakan sistem IoT cloud platform yang terdiri dari subscriber, database,, serta auth server. Cloud bertindak sebagai storage dan juga penerima data yang dikirim oleh node sensor. Script publisher dan subscriber dikembangkan menggunakan Python dengan bantuan modul paho-mqtt. 3. Proses pengolahan data dimulai dari proses pengiriman data yang telah berhasil melalui proses dan authorization. Setelah tahap tersebut, maka data akan diterima pada sisi subscriber. Subscriber memeriksa skema payload data tersebut, dan jika sesuai dengan skema database, maka data akan dimasukkan ke database berbasis MongoDB. 4. Dari hasil pengujian performa, didapatkan beberapa kesimpulan yaitu: a. Delay yang terjadi saat pengiriman berbanding lurus dengan jumlah publisher yang melakukan koneksi. Sehingga dengan lebih sedikitnya jumlah publisher yang melakukan publish data dalam satu waktu, maka waktu delay akan semakin kecil. b. Sistem dapat berperforma lebih baik pada tingkat jumlah publisher hingga 250 publisher, karena dengan hasil pengujian delay, menunjukkan rata-rata waktu delay yang terjadi memiliki hasil di bawah 1000 ms dibandingkan dengan tingkat jumlah publisher 500 publisher yang memiliki rata-rata waktu delay di atas 1000ms. c. Tingkat skalabilitas yang dimiliki oleh sistem untuk menangani jumlah publisher dalam satu detik, rata-rata publisher yang tertangani dalam waktu satu detik mencapai 191 publisher pada variasi jumlah publisher sebanyak 250 publisher dengan tingkat kesuksesan 100%, dan 187 publisher pada variasi jumlah publisher sebanyak 500 publisher dengan tingkat kesuksesan 99%. d. Dari kesimpulan poin a dan b, dapat ditarik kesimpulan baru, bahwa sistem dapat menangani publisher dengan rentang jumlah publisher sebanyak 0 hingga DFTR PUSTK Botta,., Donato, W. d., Persico, V., & Pescape,. (2016). Integration of Cloud Computing and Internet of Things: Survey. Future Generation Computer Systems, Guoqiang, S., nming, C., Chao, Z., & nxu, Z. (2013). Design and Implementation of a Smart IoT Gateway IEEE International Confrence on Green Computing and Communications and IEEE Cyber, Physical and Social Computing, Hunkeler, U., Truong, H. L., & Clark,. S. (2015). Publish/Subscribe Protocol For Wireless Sensor Network. IEEE. MQTT. (2016). Frequently sked Question. Diakses 8 Oktober, 2016, dari Zhang, Q., Cheng, L., & Boutaba, R. (2010). Cloud computing: state-of-the-art and research challenges. J Internet Serv ppl, I, 7-18.