Jurnal Pengembangan Teknologi Informasi dan Ilmu Komputer Vol. 2, No. 2, Februari 2018, hlm. 479-485
e-ISSN: 2548-964X http://j-ptiik.ub.ac.id
Rancang Bangun IOT Cloud Platform Berbasis Protokol Komunikasi MQTT Moh. Wildan Habibi1, Adhitya Bhawiyuga2, Achmad Basuki3 Program Studi Teknik Informatika, Fakultas Ilmu Komputer, Universitas Brawijaya Email:
[email protected],
[email protected],
[email protected] Abstrak 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, authentication, authorization. Abstract 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, authentication, 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, authentication, authorization. & Yanxu, 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
1. PENDAHULUAN Internet of Things (IoT), merujuk pada suatu jaringan yang menghubungkan berbagai perangkat dalam dunia fisik dengan berbagai protokol berbeda (Guoqiang, Yanming, Chao, Fakultas Ilmu Komputer Universitas Brawijaya
479
Jurnal Pengembangan Teknologi Informasi dan Ilmu Komputer
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 Fakultas Ilmu Komputer, Universitas Brawijaya
480
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 OASIS (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, authentication, dan authorization. 2. ARSITEKTUR KOMUNIKASI 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. Broker bertugas untuk mengkoordinasi keinginan akan informasi dari para subscriber, dan subscriber biasanya secara eksplisit akan melakukan kontak dengan broker 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
Jurnal Pengembangan Teknologi Informasi dan Ilmu Komputer
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).
481
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. PERANCANGAN SISTEM 4.1. Gambaran Umum Sistem
3. REKAYASA KEBUTUHAN Rekayasa kebutuhan untuk menganalisis beberapa kebutuhan yang diperlukan pada penelitian ini. Rekayasa kebutuhan pada penelitian ini dijelaskan sebagai berikut: 3.1. Analisis Kebutuhan Pengguna Kebutuhan pengguna pada penelitian ini yaitu node sensor dapat melakukan pengiriman data sensor menuju broker. Pada sisi web app, akan ditampilkan data - data yang telah diterima dari node sensor dalam bentuk tabel. 3.2. Analisis 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 broker 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 authentication terhadap setiap koneksi yang akan dibangun oleh publisher dan subscriber, serta melakukan proses authorization pada setiap data yang akan diterima oleh broker dan data yang akan diteruskan dari broker ke subscriber. Jika lolos tahap tersebut, maka data akan di teruskan ke subscriber, d. Subscriber dapat menerima data dari broker Fakultas Ilmu Komputer, Universitas Brawijaya
Gambar 2. Alur Komunikasi Data Sistem
Secara umum terlihat bahwa konsep komunikasi yang digunakan merupakan konsep komunikasi arsitektur umum dari publish subscribe MQTT. Protokol MQTT memiliki broker sebagai pusat pertukaran informasi antara publisher dan subscriber atau istilah lain broker dikenal sebagai MQTT server. Publisher yaitu node sensor mengirimkan informasi data sensor yang telah didapat menuju broker dengan melakukan inisialisasi topik. Dimana topik digunakan sebagai alamat tujuan yang dikirimkan melalui broker 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 broker membalas informasi subscriber dengan menyesuaikan identitas topik yang sama antara publisher dan subscriber, dan jika topik sama, maka broker akan meneruskan data yang diperoleh dari publisher.
Jurnal Pengembangan Teknologi Informasi dan Ilmu Komputer
4.2. Alur Kerja Penanganan Publisher Node sensor membangun koneksi dengan broker
Publisher node sensor publish data berupa data yang didapat dari sensor menuju broker menggunakan topik tertentu
Broker mendeteksi koneksi baru, meneruskan ke auth server untuk check authentication
Auth server mendeteksi permintaan check authentication, melakukan proses dan memberikan respon
Broker mendeteksi permintaan publish, meneruskan ke auth server untuk check authorization
sama. 4.3. Alur Kerja Penanganan Subscriber Subscriber membangun koneksi dengan broker
Respon diterima, dan diteruskan ke publisher
Auth server mendeteksi permintaan check authorization, melakukan proses dan memberikan respon
Subscriber melakukan subscribe topik menuju broker
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 authentication. Auth server menerima permintaan tersebut, kemudian memproses menggunakan data yang dikirim oleh broker, apakah publisher tersebut dapat melakukan koneksi. Hasil dari check authentication tersebut dijadikan respon oleh auth server, kemudian dikirimkan kembali menuju broker, dan broker mengirim ke publisher. Jika respon yang diterima oleh publisher yaitu mengijinkan untuk melakukan koneksi terhadap broker, 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 broker, dan broker 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. Broker menerima respon dari auth server tentang check authorization, jika respon tersebut bernilai positif, maka data publish akan disimpan sementara oleh broker 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 broker tidak akan menyimpan data publish tersbut dan tidak akan meneruskannya menuju subscriber meskipun dengan topik yang Fakultas Ilmu Komputer, Universitas Brawijaya
Broker mendeteksi koneksi baru, meneruskan ke auth server untuk check authentication
Data sensor diterima subscriber, dan dimasukkan ke dalam database
Auth server mendeteksi permintaan check authentication, melakukan proses dan memberikan respon
Respon diterima, dan diteruskan ke subscriber
Broker mendeteksi permintaan subscribe, meneruskan ke auth server untuk check authorization
Respon diterima, dan broker menerima publish data sensor sesuai topik dari publisher
Gambar 3. Alur Kerja Penanganan Publisher
482
Auth server mendeteksi permintaan check authorization, melakukan proses dan memberikan respon
Respon diterima, dan broker meneruskan publish data sensor sesuai topik dari publisher kepada subscriber
Gambar 4. Alur 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 authentication. Auth server menerima permintaan tersebut, kemudian memproses menggunakan data yang dikirim oleh broker, apakah subscriber tersebut dapat melakukan koneksi. Hasil dari check authentication tersebut dijadikan respon oleh auth server, kemudian dikirimkan kembali menuju broker, dan broker mengirim ke publisher. Jika respon yang diterima oleh subscriber yaitu mengijinkan untuk melakukan koneksi terhadap broker, 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 broker. 4.4. 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).
Jurnal Pengembangan Teknologi Informasi dan Ilmu Komputer
_id:
username: password: email: firstname: is_admin:
flowchart algoritma dari Auth Server. Jika Auth Server berjalan, maka akan selalu dalam kondisi siap digunakan jika tidak ada check request dari broker. Jika terdapat request, maka tindak lanjut dari setiap permintaan akan berbeda di dalam prosesnya, namun semua akan berakhir dengan memberikan respon ke broker.
_id: node: sensor: data: timestamp:
_id: user: label: secretkeyl: subsperday: subsperdayremain: is_public:
_id: Label:
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. 4.5. Perancangan Auth Server Auth Server bertugas untuk melakukan pemeriksaan mengenai koneksi yang akan dilakukan pada broker. Pemeriksaan tersebut meliputi authentication, superuser, dan authorization. Start Menunggu check request dari broker
Tidak
Tidak
Ada check request dari broker
Ya
Check authentication
Ya
Melakukan check authentication pada database
Aplikasi berhenti
Ya
End
Tidak
Check superuser
Ya
Melakukan check user superuser pada database
Ya
Melakukan check authorization pada database
Memberikan respond ke broker
Tidak
Check authorization
Gambar 6. Alur Kerja Auth Server
Pada
Gambar
6,
menggambarkan
Fakultas Ilmu Komputer, Universitas Brawijaya
483
4.6. 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
Ya
Tidak
A
Tidak
Koneksi dengan Subscriber
Ya
B
Ya
A
B
Koneksi terbangun
Koneksi terbangun
Publisher publish data
Ada publish data terbaru
Ya
Ya
Menerima publish data dari publisher sesuai dengan topik yang digunakan
Meneruskan publish data sesuai dengan topik yang di subscribe
Koneksi tetap berjalan
Koneksi tetap berjalan
Tidak
Tidak
Ya
Tidak
End
Gambar 7. Alur Kerja Broker
Pada Gambar 7, menggambarkan flowchart algoritma dari broker sebagai MQTT Server. Diawali dengan menjalankan fungsi MQTT Broker, kemudian jika ada publish data terbaru dari publisher, maka akan diterima dan disimpan oleh broker. Ketika subscriber melakukan subscribe pada topik yang sama dengan publisher, maka data publish yang telah diterima oleh broker akan diteruskan ke subscriber. 4.7. Perancangan Subscriber Subscriber bertugas untuk menerima seluruh publish data yang sudah diperiksa oleh broker, serta memasukkannya ke database. Pada Gambar 8, menggambarkan flowchart algoritma dari subscriber. Diawali dengan koneksi dengan broker. 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.
Jurnal Pengembangan Teknologi Informasi dan Ilmu Komputer A
Start
Mendapatkan data payload terbaru
Membangun koneksi dengan broker
Ya
Memeriksa kesamaan data payload dengan skema database
Berhasil terkoneksi dengan broker
Data payload Sesuai dengan skema database
Tidak
Subscribe topic yang digunakan
Tidak
Data payload tidak dimasukkan ke database
Ya
Data payload dimasukkan ke database Ya
Menerima data terbaru dari topik yang disubscribe
Ya
A
Tidak
Koneksi terputus
Tidak
Tidak
Aplikasi berhenti
Ya
End
Gambar 8. Alur Kerja Subscriber
Jika sudah sesuai, maka subscriber akan mencocokkan dengan database yang digunakan. Jika sesuai, maka publish data tersebut akan disimpan pada database. 5. HASIL PENGUJIAN PERFORMA 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 Average Average Average Publisher Delay (ms) Publisher Delay (ms) Publisher Delay (ms) 100 56,73 250 173,38 500 450,37 100 91,81 250 1021,92 500 5786,104 100 112,7 250 810,332 500 3495,172 100 87,08 250 668,544 500 3243,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 Fakultas Ilmu Komputer, Universitas Brawijaya
484
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 100 100 100% 100 100 100 100% 100 100 100 100% 100 100 100 100% 100 250 250 100% 250 250 250 100% 156 250 250 100% 167 250 250 100% 191 500 500 100% 451 500 493 99% 1 500 495 99% 109 500 496 99% 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. KESIMPULAN Berdasarkan hasil perancangan, implementasi, dan pengujian yang telah dilakukan sebelumnya, maka penulis mendapatkan kesimpulan sebagai berikut: 1. Mekanisme manajemen perangkat IoT, authentication, dan authorization dapat dilakukan dengan membangun sebuah auth server berbasis protokol HTTP. Auth Server merupakan komponen yang bertugas untuk memeriksa koneksi yang akan dilakukan ke broker dan data yang akan melewatinya. Pemeriksaan tersebut meliputi authentication, superuser, dan authorization. Authentication bertujuan
Jurnal Pengembangan Teknologi Informasi dan Ilmu Komputer
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, broker, 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 authentication 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
Fakultas Ilmu Komputer, Universitas Brawijaya
485
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 250. 7. DAFTAR PUSTAKA Botta, A., Donato, W. d., Persico, V., & Pescape, A. (2016). Integration of Cloud Computing and Internet of Things: A Survey. Future Generation Computer Systems, 684-700. Guoqiang, S., Yanming, C., Chao, Z., & Yanxu, Z. (2013). Design and Implementation of a Smart IoT Gateway. 2013 IEEE International Confrence on Green Computing and Communications and IEEE Cyber, Physical and Social Computing, 720-723. Hunkeler, U., Truong, H. L., & Clark, A. S. (2015). A Publish/Subscribe Protocol For Wireless Sensor Network. IEEE. MQTT. (2016). Frequently Asked Question. Diakses 8 Oktober, 2016, dari http://www.mqtt.org/faq Zhang, Q., Cheng, L., & Boutaba, R. (2010). Cloud computing: state-of-the-art and research challenges. J Internet Serv Appl, I, 7-18.
