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 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 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 secara sederhana dapat didefinisikan sebagai kondisi ketika things atau objek terkoneksi ke internet lebih banyak dibandingkan jumlah
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 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 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
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
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 client. Dari gambar 5, terlihat ketika
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 usage dengan pola grafik yang hampir sama
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 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
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
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.
Zha, J. et al., 2010. Research on load balance of
Service Capability Interaction Management. In 2010 3rd IEEE International Conference on Broadband Network and Multimedia Technology (IC-BNMT). pp. 212–217.
