Fakultas Ilmu Komputer
Universitas Brawijaya
2902
Analisis Performa
Load
Balancing Pada
Broker
MQTT
Menggunakan
Algoritma Round Robin
Kevin Charlie1, Rakhmadhany Primananda2, Mahendra Data3
Program Studi Teknik Informatika, Fakultas Ilmu Komputer, Universitas Brawijaya Email: 1kevin27ch@student.ub.ac.id, 2rakhmadhany@ub.ac.id, 3mahendra.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 1host menggunakan virtualisasi. Terdapat 4 virtualdevices, 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.
Katakunci: 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 1.007 seconds when traffic is low and 1.005, 2.791, 4.593, and 2.005 seconds when traffic is high. Finally, the broker's message distribution takes about 0.362, 0.687, 0.891, 1.199, and 1.622 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
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 biasadisebut broker.
Mosquitto adalah message broker yang open source dan sudah mengimplementasikan MQTT
versi 3.1 dan 3.1.1 (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 roundrobin, 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
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
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.
4.2.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 3.
4.3.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 1200. Dimana 300
pada pengujian dengan keterangan “no load
balancer”, beban setiap broker adalah 100
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.
4.4.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.
4.5.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.
4.6.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
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.
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.
4.8.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
balancer mendistribusikan client tersebut ke
broker lain. Dimana kecepatannya sebesar 1.007 detik untuk hampir semua percobaan.
Tabel 1 Waktu rekoneksi ketika brokeridle
Tabel 2 merupakan tabel data yang menunjukkan waktu yang dibutuhkan untuk rekoneksi ketika semua broker sedang sibuk, sehingga ddapatkan hasil yang variatif.
Tabel 2 Wakturekoneksiketika broker sibuk
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
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., 2016. BeaQoS: Load balancing and deadline management of queues in an OpenFlow SDN switch. Computer Networks, 106, pp.161–170.
Dhall, R., & Solanki, V.J., 2017. An IoT Based Predictive Connected Car Maintenance Approach. International Journal of Interactive Multimedia and Artificial Intelligence, Vol 4.
Evans, D., 2011. White paper: the Internet of Things, how the next evolution of the Internet is changing everything. Cisco Internet Business Solutions Group (IBSG).
Ellrod, C., 2010. Load balancing –Round robin. [Online]. Bisa diakses pada https://www.citrix.com/blogs/2010/09/03/ load-balancing-round-robin/. Terakhir akses pada 30 Desember 2017.
Evans, D, 2011. 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., 2016. Internet of Things Cloud: Architecture and Implementation. IEEE Communications Magazine, Vol :54, pp.32-39.
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), 1568-1577.
Tang, K. et al., 2013. Design and Implementation of Push Notification System Based on the MQTT Protocol. International Conference on Information Science and Computer Applications. Issue date Oktober 2013.
