Analisis Performa Load Balancing Pada Broker MQTT Menggunakan Algoritma Round Robin

Transkripsi

1 Jurnal Pengembangan Teknologi Informasi dan Ilmu Komputer e-issn: X Vol. 2, No. 9, September 2018, hlm Analisis Performa Load Balancing Pada Broker MQTT Menggunakan Algoritma Round Robin Kevin Charlie 1, Rakhmadhany Primananda 2, Mahendra Data 3 Program Studi Teknik Informatika, 1 kevin27ch@student.ub.ac.id, 2 rakhmadhany@ub.ac.id, 3 mahendra.data@ub.ac.id Abstrak MQTT adalah protokol komunikasi yang membutuhkan resource dan bandwidth yang kecil. MQTT menggunakan broker yang bertugas menghubungkan publisher dan subscriber. Broker MQTT, khususnya Mosquitto tidak memiliki mekanisme untuk mengatasi kegagalan yang disebabkan overload CPU maupun kerusakan device ketika hanya 1 broker yang digunakan. Sehingga, dibutuhkan load balancer dan beberapa broker. Pada penelitian ini, dilakukan analisis performa load balancer yang menggunakan algoritma round robin dalam mendistribusikan beban kerja broker MQTT. Penelitian dilakukan pada sebuah 1 host menggunakan virtualisasi. Terdapat 4 virtual devices, yaitu 3 broker dan 1 load balancer. Subscriber berlangganan topik dengan mengakses alamat load balancer. Pengujian dilakukan dengan menggunakan load balancer sebagai variabel pembeda untuk mengetahui dampak yang diberikan load balancer terhadap broker. Didapatkan hasil bahwa load balancer dengan algoritma round robin mampu mendistribusikan beban secara merata dengan kondisi semua client terkoneksi tanpa ada yang terputus dengan beban CPU 13,56%, 13,68%, dan 15,12% untuk setiap broker dengan request sebesar 400 client yang menerima 10 publish message. Kemudian sistem mampu melakukan reconnect ke broker lainnya dengan kecepatan 1,007 detik saat traffic sedang rendah dan 1,005, 2,791, 4,593, dan 2,005 detik ketika traffic sedang tinggi. Terakhir, distribusi pesan di broker memerlukan waktu sebesar hasil 0,362, 0,687, 0,891, 1,199, dan 1,622 detik untuk jumlah pesan publish sebesar 25, 50, 75, 100, dan 125. Kata kunci: load balancer, MQTT, round robin, publisher, subscriber, mosquitto, broker Abstract MQTT is a communication protocol that requires a small resource and bandwidth. MQTT uses a broker in charge of connecting publishers and subscribers. MQTT brokers, especially Mosquitto, do not have mechanisms to overcome failures caused by CPU overload or device damage when only one broker is used. Thus, it takes load balancer and some brokers. In this research, a load balancer performance analysis using round robin algorithm is used to distribute MQTT brokers workload. The study was conducted on a single host using virtualization. There are 4 virtual devices, namely 3 brokers and 1 load balancer. Subscriber subscribes to the topic by accessing the load balancer address. Testing is done by using load balancer as differentiator variable to know impact given load balancer to broker. The result shows that load balancer with round robin algorithm is able to distribute the load evenly with the condition of all connected clients without any interruption with 13.56%, 13.68% and 15.12% CPU load for each broker with request of 400 that receive 10 publish message for each client. Then the system is able to reconnect to other brokers with a speed of seconds when traffic is low and 1.005, 2.791, 4.593, and seconds when traffic is high. Finally, the broker's message distribution takes about 0.362, 0.687, 0.891, 1.199, and seconds for the number of publish messages of 25, 50, 75, 100, and 125. Keywords: load balancer, MQTT, round robin, publisher, subscriber, mosquitto, broker 1. PENDAHULUAN Internet of Things merupakan suatu konsep dimana semua devices saling terkoneksi. IoT secara sederhana dapat didefinisikan sebagai kondisi ketika things atau objek terkoneksi ke internet lebih banyak dibandingkan jumlah Fakultas Ilmu Komputer Universitas Brawijaya 2902

2 Jurnal Pengembangan Teknologi Informasi dan Ilmu Komputer 2903 manusia (Evans, 2011). Protokol MQTT merupakan salah satu protokol yang digunakan untuk komunikasi antar devices IoT. Protokol MQTT merupakan protokol yang open, simple, ringan, dan protokol yang mudah diimplementasikan untuk messaging. Sehingga karakteristik ini membuat MQTT ideal untuk klien dengan lingkungan dimana bandwith network dan device dengan kemampuan memori dan proses yang rendah (Dhall & Solanki, 2017). Protokol MQTT berjalan di atas TCP. MQTT menggunakan model Publish-Subscribe untuk komunikasi antara devices yang ada. Model Publish-Subscribe didesain agar mudah untuk diimplementasikan dan bersifat open (Dhall & Solanki, 2017). Dengan adanya Publish- Subscribe, seseorang tidak diharuskan menerima semua informasi yang ada, tetapi informasi yang sesuai dengan kebutuhannya tanpa mengganggu kerja utama sistem yang ada. MQTT menggunakan MQTT Server sebagai perantara antara Publisher dan Subscriber. Sehingga MQTT Server yang biasa disebut broker. Mosquitto adalah message broker yang open source dan sudah mengimplementasikan MQTT versi 3.1 dan (mosquitto.org). Mosquitto mendukung bridge, yaitu mekanisme agar setiap broker bisa saling terhubung dan bertukar pesan. Mosquitto tidak memiliki mekanisme untuk mengatasi kegagalan yang disebabkan oleh overload pada CPU dan kerusakan perangkat keras. Sehingga ketika kegagalan terjadi, maka semua client yang terhubung ke server tersebut kehilangan akses terhadap data yang dimiliki oleh server tersebut. Selain itu, untuk bisa mengirimkan pesan secara real time. Broker harus selalu terus menjaga koneksi TCP yang ada. Sehingga diperlukan penyetaraan load agar beban broker bisa berkurang. Sebuah jaringan yang memiliki distribusi load yang merata akan membantu optimasi terhadap resource yang tersedia untuk dapat memaksimalkan throughput, meminimalisasi response time, dan mencegah terjadinya overload pada jaringan (Zha et al. 2010). Untuk mendistribusikan load yang ada, maka load balancer diperlukan untuk mendistribusikan beban sehingga beban broker Mosquitto bisa lebih merata. Load balancer adalah device yang memiliki kemampuan untuk mendistribusikan traffic yang ada dan mengarahkan request ke server yang ada sesuai dengan algoritma yang diterapkan. Jadi dapat dikatakan bahwa load balancer memiliki fungsi utama untuk mencegah congestion serta memangkas delay yang tidak diperlukan (Boero et al. 2016). Salah satu aplikasi load balancer adalah HAProxy. HAProxy dapat melakukan distribusi beban kerja berdasarkan 2 jenis paket, yaitu paket HTTP dan paket TCP. Dengan adanya Load balancer, realibilitas dan ketersediaan suatu resource bisa lebih terjamin, karena ketika terjadi kegagalan pada salah satu broker, maka load balancer bisa mengarahkan traffic data ke broker lain yang masih bisa bekerja. Load balancer memiliki mekanisme balancing menggunakan algoritma round robin, algoritma round robin dipilih karena algoritma tersebut lebih efisien apabila diterapkan pada server dengan spesifikasi yang sama dan beban load yang sama (Ardy et al. 2017). Pada penelitian ini spesifikasi server yang digunakan adalah sama, sehingga algoritma round robin cocok untuk kondisi ini. Dari permasalahan ini, maka diperlukan analisis performa broker Mosquitto ketika yang memanfaatkan load balancer yang menggunakan algoritma round robin untuk mengetahui dampak yang diberikan oleh load balancer kepada performa broker dalam memproses request dari subscriber dan publisher. Untuk mengetahui performanya maka diperlukan skenario pengujian dengan melakukan proses publish dan subscribe yang berbeda beda pada setiap percobaannya. Cara kerja yang ditawarkan adalah publisher mengirimkan pesan melalui load balancer, kemudian load balancer meneruskan pesan tersebut ke broker sesuai algoritma balancing yang digunakan. Kemudian broker yang menerima pesan akan menyebarkan pesan tersebut ke broker lain yang terhubung sehingga semua broker akan menerima pesan publish yang sama. Subscriber melakukan subscribe melalui load balancer, dimana load balancer yang akan mengarahkan pesan subscribe ke broker sesuai dengan cara kerjaalgoritma round robin 2. METODOLOGI

3 Jurnal Pengembangan Teknologi Informasi dan Ilmu Komputer 2904 Gambar 1 Metodologi Penelitian Gambar 1 menunjukkan metodologi penelitian yang digunakan untuk menyelesaikan penelitian ini. Proses awal dimulai dengan identifikasi masalah yang didapatkan, kemudian dilakukan studi literatur untuk mendapatkan teori teori pendukung dalam penelitian, ketika sudah mendapatkan teori yang cukup maka dilakukan perancangan, dimana pada perancangan ini dilakukan analisis kebutuhan untuk mengetahui komponen - komponen dibutuhkan sistem. Kemudian dilanjutkan dengan perancangan arsitektur jaringan dan rancangan pengujian yang akan dilaksanakan pada penelitian ini untuk mengetahui kemampuan dari arsitektur jaringan yang dirancang. Setelah perancangan selesai dilakukan maka dilanjutkan dengan proses implementasi berdasarkan rancangan yang sudah dibuat. Pengujian dan analisis dilakukan untuk mendapatkan data untuk menjawab masalah yang didapatkan. Setelah semua pengujian dan analisis dilakukan, maka ditariklah suatu kesimpulan untuk menjawab masalah yang ada. 3. PERANCANGAN 3.1 PERANCANGAN SISTEM Sistem ini menggunakan metode distribusi pesan menggunakan model Publish-Subscribe yang berjalan menggunakan protokol komunikasi MQTT. Sistem ini akan berjalan di dalam 1 host. Dimana dalam 1 host terdapat 4 devices virtual yang berjalan menggunakan aplikasi VirtualBox. 4 devices ini terdiri dari 3 broker dan 1 load balancer. Pada penelitian ini semua broker akan terhubung menggunakan bridge dan bisa saling bertukar pesan dari publisher yang diterima oleh setiap broker. Sehingga setiap broker akan menerima pesan yang sama. Kemudian sistem ini menggunakan load balancer untuk menghandle request dari sisi client subscriber dan publisher untuk diarahkan ke broker sesuai dengan algoritma round robin yang digunakan. Gambar 2 merupakan arsitektur jaringan yang digunakan untuk proses implementasi dan pengujian. Semua broker saling terhubung dan saling membagikan informasi pesan publish. Kemudian ada load balancer yang bertugas untuk mendistribusikan subsriber dan publisher ke broker broker yang ada. Gambar 2 Topologi Jaringan 3.2 PERANCANGAN PENGUJIAN Pengujian dilakukan menggunakan script Python yang memanfaatkan multithreading dan library Paho MQTT. Dari perancangan pengujian ini maka akan bisa dicapai poin poin yang akan diukur. Semua pengujian dilakukan ketika broker menjalan mosquitto pada foreground. Karena dengan ini bisa dirasakan dampak penggunaan resource CPU yang ada dan juga bisa ditampilkan log yang ada secara real time. Parameter uji yang diukur adalah waktu yang dibutuhkan agar semua broker mendapatkan pesan yang sama, kemudian CPU usage ketika broker meneruskan pesan dari publisher untuk dikirimkan ke broker lainnya. Kemudian waktu yang dibutuhkan ketika sistem menggunakan dan tidak menggunakan load balancer ketika dihadapkan pada jumlah request

4 Jurnal Pengembangan Teknologi Informasi dan Ilmu Komputer 2905 yang sama, utilisasi CPU ketika menangani subscriber menggunakan dan tidak menggunakan load balancer, kemudian selisih waktu ketika broker mengirimkan pesan ke subscriber melalui load balancer dan tidak menggunakan load balancer, terakhir adalah nilai CPU usage Broker ketika menangani subscribe dan publish secara simultan. Kemudian selain parameter uji tersebut, ada juga pengujian untuk menjamin integritas data dan pengujian ketika terjadi kegagalan di broker untuk mengetahui waktu yang dibutuhkan agar client dapat kembali terhubung ke sistem. 4. PENGUJIAN & ANALISIS 4.1. Pengujian waktu untuk melakukan penyebaran pesan antar broker menggunakan bridge Gambar 3 Grafik Waktu Sinkronisasi Gambar 3 menunjukkan grafik waktu kecepatan broker menyebarkan pesan ke broker lain yang terhubung dengan bridge. Ketika hanya hanya 25 pesan yang dikirimkan, maka waktu yang dibutuhkan sebesar 0,362 detik. Ketika jumlah pesan ditambahkan, maka waktu yang diperlukan bertambah seperti pengujian dengan 50, 75, 100, dan 125 pesan. Dimana terjadi kenaikkan waktu. Hal ini dipengaruhi CPU usage di broker 1. Broker 1 memerlukan waktu untuk untuk memproses setiap pesan yang masuk. Semakin banyak pesan yang masuk, maka semakin besar waktu yang diperlukan oleh broker 1 untuk mengirimkan pesan tersebut ke broker lainnya untuk melakukan sinkronisasi pesan Pengujian untuk mengetahui resource CPU Usage Broker ketika melakukan sinkronisasi pesan Gambar 4 merupakan CPU usage broker 1. Ketika hanya 1 broker yang aktif, Broker hanya membuat koneksi dan menerima pesan publisher tanpa harus mengirimkan lagi pesan tersebut ke broker lainnya karena broker lain dalam kondisi tidak aktif. Gambar 4 Grafik Utilisasi CPU Broker 1 Pada percobaan dengan 2 broker yang aktif, yaitu broker 1 dan broker 2. Broker 1 mengalami kenaikkan CPU usage. Hal ini disebabkan karena broker 1, selain harus membuat koneksi dan menerima pesan dari publisher. Broker 1 juga harus membagikan pesan tersebut ke broker lain agar broker 2 menerima pesan publish yang sama seperti broker 1. Pada gambar 4, dengan percobaan 2 broker aktif yang ditunjukkan garis merah, terjadi kenaikkan CPU yang tidak signifikan. Akan tetapi pada garis hijau yang menandakan 3 broker aktif, terjadi kenaikkan resource yang cukup signifikan, penyebabnya adalah broker 1 selain menerima pesan, broker 1 juga harus mengirimkan pesan dalam jumlah yang sama sesuai dengan jumlah broker yang terhubung dengan bridge. Semisal pada pengujian dengan semua broker aktif dan jumlah pesan sebesar 125, maka berdasarkan arsitektur jaringan pada gambar 2. Broker 1 harus mengirimkan pesan sebanyak 125 pesan ke broker 2 dan 125 pesan ke broker Pengujian untuk mengetahui delay waktu yang dibutuhkan subscriber untuk melakukan koneksi ke broker ketika melalui load balancer Gambar 5 Perbandingan Waktu yang dibutuhkan untuk menangani subscriber Pengujian dilakukan dengan jumlah client sebesar 300, 600, 900, dan Dimana 300 pada pengujian dengan keterangan no load balancer, beban setiap broker adalah 100 client. Dari gambar 5, terlihat ketika

5 Jurnal Pengembangan Teknologi Informasi dan Ilmu Komputer 2906 menggunakan load balancer untuk membagikan beban yang ada, waktu request menjadi sedikit lebih lama, dimana selisih waktu antara ketika menggunakan load balancer dengan tidak menggunakan load balancer akan semakin jauh ketika jumlah subscriber yang ada semakin banyak. Hal dikarenakan pada saat menggunakan load balancer. Pesan dari subscriber mengalami waktu pemrosesan di load balancer. Sehingga dibutuhkan waktu pemrosesan ketika paket diterima oleh load balancer. Sedangkan ketika subscriber melakukan koneksi secara langsung dengan broker, tentu hasilnya akan lebih cepat karena waktu proses di load balancer tidak ada Pengujian untuk mengetahui resource CPU Broker saat menangani subscriber ketika tidak menggunakan dan menggunakan load balancer. Dari pengujian yang dilakukan untuk mengetahui CPU Usage ketika menggunakan load balancer dan tidak menggunakan load balancer dengan pengujian dimana setiap broker diberikan 100, 200, 300, dan 400 subscriber Sehingga ketika 3 broker dijalankan, maka akan ada 300, 400, 900, dan 1200 (jumlah broker x client). Gambar 6 Grafik Utilisasi CPU Kemudian total client tersebut juga dilakukan ketika menggunakan load balancer sehingga pengujian menjadi adil. Gambar 6 menunjukkan bahwa ketika menggunakan load balancer, CPU usage setiap broker menjadi lebih tinggi dikarenakan ketika melalui load balancer, paket yang diterima dan dikirimkan menjadi lebih besar jika dibandingkan dengan ketika subscriber melakukan secara koneksi langsung ke broker. Dengan bertambahnya besar paket, maka broker harus memproses paket dengan konsumi CPU yang lebih tinggi Pengujian untuk mengetahui selisih waktu publish ketika menggunakan load balancer. Gambar 7 Diagram selisih waktu publish Gambar 7 menunjukkan diagram batang yang menunjukkan lama waktu yang diperlukan agar pesan publish dapat sampai ke subscriber. Jumlah pesan publish yang digenerate adala sebear 100, 200, 300, dan 400 pesan. Didapatkan waktu dalam satuan detik dimana pada percobaan ini terdapat selisih waktu yang yang berbeda sangat tipis. Hal ini dikarenakan proses publish membutuhkan proses yang lebih singkat jika dibandingkan proses publish. Kemudian sama seperti pengujian 4.3, Ketika menggunakan load balancer, dibutuhkan waktu pemrosesan ketika pesan diterima load balancer sehingga waktu ketika publisher langsung mengirimkan pesan ke broker jauh lebih singkat Pengujian untuk mengetahui resource CPU Broker dalam menangani banyak client secara pararel dalam melakukan proses publish - subscribe Pengujian ini dilakukan dengan 100, 200, 300, dan 400 client subscriber, kemudian broker yang pada awalnya melakukan koneksi secara langsung ke broker 1. CPU usage ketika broker 1 menangani 100 client subscriber, dimana terjadi penurunan utilisasi resource CPU ketika broker lainnya aktif, yang artinya load balancer sukses melakukan load balancing, dimana beban kerja didistribusikan ke broker lain yang aktif. Untuk percobaan dengan 200, 300, dan 400 client juga berhasil memberikan penuruan CPU usage dengan pola grafik yang hampir sama seperti yang ditunjukkan gambar 8.

6 Jurnal Pengembangan Teknologi Informasi dan Ilmu Komputer 2907 Gambar 8 Grafik Utilisasi CPU Broker 1 Gambar 9 merupakan distribusi load pada setiap parameter pengujian, dimana didapatkan hasil bahwa algoritma round robin mampu mendistribusikan pesan secara adil dan merata ketika jenis beban yang diberikan dan spesifikasi server sama. Dari gambar 9 bisa dilihat juga perbedaan CPU Usage dari setiap broker tidak berbeda jauh dan cenderung rata dan stabil. balancer mendistribusikan client tersebut ke broker lain. Dimana kecepatannya sebesar detik untuk hampir semua percobaan. Tabel 1 Waktu rekoneksi ketika broker idle Tabel 2 merupakan tabel data yang menunjukkan waktu yang dibutuhkan untuk rekoneksi ketika semua broker sedang sibuk, sehingga ddapatkan hasil yang variatif. Tabel 2 Waktu rekoneksi ketika broker sibuk Gambar 9 Diagram Utilisasi CPU semua devices 4.7. Pengujian integritas data Subscriber dengan client_id A berlangganan topik broker1 sesuai dengan gambar 10. Gambar 10 Subscriber melakukan subscription Publisher dengan client_id 1 mengirimkan pesan dengan topik broker 1 yang ditandai dengan kotak merah pada gambar 11. Gambar 11 Publisher melakukan publish pesan Subscriber menerima pesan dari publisher pada gambar 12. Gambar 12 Subscriber menerima pesan Berdasarkan pengujain ini, terbukti bahwa data yang dikirimkan oleh broker merupakan benar benar data yang dikirimkan oleh publisher Pengujian rekoneksi ketika broker yang tersambung mengalami kegagalan Tabel 1 merupakan tabel data yang menunjukkan waktu yang dibutuhkan untuk melakukan rekoneksi ketika broker yang terhubung mengalami kegagalan sehingga load Kemudian pada tabel 2 juga ditunjukkan pada percobaan ke 4, dimana client gagal melakukan rekoneksi karena broker tujuannya sedang sibuk sehingga tidak bisa memproses paket yang dikirimkan oleh load balancer. 5. KESIMPULAN Penerapan load balancing untuk protokol komunikasi MQTT dapat dilakukan menggunakan HAProxy dengan memanfaatkan mode TCP yang ada di HAProxy. Sehingga digunakan load balancing pada layer 4 untuk melakukan load balancing untuk request yang berjalan pada protokol MQTT. Kemudian performa load balancing dalam mendistribusikan load tergantung pada jumlah broker yang ada. Selain itu algoritma round robin mampu mendistribusikan load secara merata. Selain itu didapatkan hasil jika load balancer melakukan modifikasi paket sehingga ukuran paket ketika menuju broker akan memiliki ukuran yang lebih besar jika dibandingkan ketika melakukan koneksi secara langsung. Pada penelitian ini, load balancer yang menggunakan algoritma round robin dapat mendistribusikan beban secara merata dengan kondisi semua client terkoneksi tanpa ada yang terputus dengan beban sebesar 13,56%, 13,68%, dan 15,12% pada untuk broker dengan request sebesar 400. Berhasil dilakukan penurunan beban kerja sekitar 40% ketika menggunakan 2 broker dan 60% ketika menggunakan 3 broker jika dibandingkan dengan beban awal ketika hanya ada 1 broker aktif. Sedangkan untuk mekanisme rekoneksi ketika terjadi kegagalan di

7 Jurnal Pengembangan Teknologi Informasi dan Ilmu Komputer 2908 salah satu broker, waktu yang dibutuhkan sebesar 1,007 detik ketika CPU Broker sedang idle, dan ketika CPU broker sedang tinggi. Waktu yang dibutuhkan lebih beragam dengan hasil 1,005, 2,791, 4,593, dan 2,005 detik. Pada penelitian masih terdapat kekurangan sehingga saran untuk peneliti selanjutnya adalah pengujian bisa dilakukan secara langsung pada hardware dan algoritma load balancing yang digunakan bisa melakukan pendistribusian berdasarkan CPU usage di setiap broker. 6. DAFTAR PUSTAKA Ardy, L., Bhawiyuga, A., & Yahya, W. (2017). Implementasi Load balancer Berdasarkan Server Status Pada Arsitektur Software Defined Network (SDN). Boero, L. et al., BeaQoS: Load balancing and deadline management of queues in an OpenFlow SDN switch. Computer Networks, 106, pp Dhall, R., & Solanki, V.J., An IoT Based Predictive Connected Car Maintenance Approach. International Journal of Interactive Multimedia and Artificial Intelligence, Vol 4. Evans, D., White paper: the Internet of Things, how the next evolution of the Internet is changing everything. Cisco Internet Business Solutions Group (IBSG). Ellrod, C., Load balancing Round robin. [Online]. Bisa diakses pada load-balancing-round-robin/. Terakhir akses pada 30 Desember Evans, D, White paper: the Internet of Things, how the next evolution of the Internet is changing everything, Cisco Internet Business Solutions Group (IBSG). Hou, L. et al., Internet of Things Cloud: Architecture and Implementation. IEEE Communications Magazine, Vol :54, pp Nugroho, A., Yahya, W., & Amron, K. (2017). Analisis Perbandingan Performa Algoritma Round Robin dan Least Connection untuk Load Balancing pada Software Defined Network. Jurnal Pengembangan Teknologi Informasi Dan Ilmu Komputer, 1(12), Tang, K. et al., Design and Implementation of Push Notification System Based on the MQTT Protocol. International Conference on Information Science and Computer Applications. Issue date Oktober Zha, J. et al., Research on load balance of Service Capability Interaction Management. In rd IEEE International Conference on Broadband Network and Multimedia Technology (IC- BNMT). pp