Analisis Performa Load Balancing Pada Broker MQTT Menggunakan Algoritma Round Robin

  

Vol. 2, No. 9, September 2018, hlm. 2902-2908 http://j-ptiik.ub.ac.id

_{1 2 3} Kevin Charlie , Rakhmadhany Primananda , Mahendra Data

  Program Studi Teknik Informatika, Fakultas Ilmu Komputer, Universitas Brawijaya _{1 2 3} Email: kevin27ch@student.ub.ac.id, rakhmadhany@ub.ac.id, 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 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

  dimana semua devices saling terkoneksi. IoT 1. secara sederhana dapat didefinisikan sebagai

   PENDAHULUAN

  kondisi ketika things atau objek terkoneksi ke

  Internet of Things merupakan suatu konsep

  internet lebih banyak dibandingkan jumlah

  Fakultas Ilmu Komputer Universitas Brawijaya

2902 manusia (Evans, 2011). Protokol MQTT merupakan salah satu protokol yang digunakan untuk komunikasi antar devices IoT. Protokol

  MQTT merupakan protokol yang open, simple,

  server dengan spesifikasi yang sama dan beban load yang sama (Ardy et al. 2017). Pada

  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

  penelitian ini spesifikasi server yang digunakan adalah sama, sehingga algoritma round robin cocok untuk kondisi ini.

  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).

  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

  Salah satu aplikasi load balancer adalah

  Mosquitto bisa lebih merata. Load balancer

  ringan, dan protokol yang mudah diimplementasikan untuk messaging. Sehingga karakteristik ini membuat MQTT ideal untuk klien dengan lingkungan dimana bandwith

  versi 3.1 dan 3.1.1 (mosquitto.org). Mosquitto mendukung bridge, yaitu mekanisme agar setiap

  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

  broker bisa saling terhubung dan bertukar pesan. Mosquitto tidak memiliki mekanisme untuk

  Untuk mendistribusikan load yang ada, maka load balancer diperlukan untuk mendistribusikan beban sehingga beban broker

  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).

  2. METODOLOGI

  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.

  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

  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

  untuk menghandle request dari sisi client subscriber dan publisher untuk diarahkan ke broker sesuai dengan algoritma round robin yang digunakan.

  load balancer

  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.

• – 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.

  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.

  Kemudian dilanjutkan dengan perancangan arsitektur jaringan dan rancangan pengujian yang akan dilaksanakan pada penelitian ini untuk mengetahui kemampuan dari arsitektur jaringan yang dirancang.

  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

3. PERANCANGAN

  balancer ketika dihadapkan pada jumlah request yang sama, utilisasi CPU ketika menangani

  subscriber menggunakan dan tidak

  4.2. Pengujian untuk mengetahui resource CPU Usage Broker ketika melakukan sinkronisasi pesan Gambar 4 merupakan CPU usage broker 1.

  Pengujian dilakukan dengan jumlah client sebesar 300, 600, 900, dan 1200. Dimana 300 pada pengujian dengan keterangan “no load

  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

  broker 2 dan 125 pesan ke broker 3.

  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

  resource yang cukup signifikan, penyebabnya

  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

  Gambar 4 Grafik Utilisasi CPU Broker 1

  tersebut ke broker lainnya karena broker lain dalam kondisi tidak aktif.

  publisher tanpa harus mengirimkan lagi pesan

  Ketika hanya 1 broker yang aktif, Broker hanya membuat koneksi dan menerima pesan

  pesan.

  menggunakan load balancer, kemudian selisih waktu ketika broker mengirimkan pesan ke

  broker 1 untuk mengirimkan pesan tersebut ke broker lainnya untuk melakukan sinkronisasi

  waktu untuk untuk memproses setiap pesan yang masuk. Semakin banyak pesan yang masuk, maka semakin besar waktu yang diperlukan oleh

  CPU usage di broker 1. Broker 1 memerlukan

  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

  4. PENGUJIAN & ANALISIS 4.1. Pengujian waktu untuk melakukan penyebaran pesan antar broker menggunakan bridge Gambar 3 Grafik Waktu Sinkronisasi

  client dapat kembali terhubung ke sistem.

  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

  subscribe dan publish secara simultan.

  menggunakan load balancer, terakhir adalah nilai CPU usage Broker ketika menangani

  subscriber melalui load balancer dan tidak

  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

  4.5. Pengujian untuk mengetahui selisih waktu publish ketika menggunakan load balancer.

  client juga berhasil memberikan penuruan CPU usage dengan pola grafik yang hampir sama

  sukses melakukan load balancing, dimana beban kerja didistribusikan ke broker lain yang aktif. Untuk percobaan dengan 200, 300, dan 400

  broker lainnya aktif, yang artinya load balancer

  terjadi penurunan utilisasi resource CPU ketika

  1 menangani 100 client subscriber, dimana

  yang pada awalnya melakukan koneksi secara langsung ke broker 1. CPU usage ketika broker

  300, dan 400 client subscriber, kemudian broker

  Pengujian ini dilakukan dengan 100, 200,

  4.6. Pengujian untuk mengetahui resource CPU Broker dalam menangani banyak client secara pararel dalam melakukan proses publish - subscribe

  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.

  publish membutuhkan proses yang lebih singkat

  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

  Gambar 7 Diagram selisih waktu publish

  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.

  pemrosesan ketika paket diterima oleh load

  balancer, paket yang diterima dan dikirimkan

  lebih tinggi dikarenakan ketika melalui load

  balancer , CPU usage setiap broker menjadi

  Kemudian total client tersebut juga dilakukan ketika menggunakan load balancer sehingga pengujian menjadi adil. Gambar 6 menunjukkan bahwa ketika menggunakan load

  Gambar 6 Grafik Utilisasi CPU

  client) .

  diberikan 100, 200, 300, dan 400 subscriber Sehingga ketika 3 broker dijalankan, maka akan ada 300, 400, 900, dan 1200 (jumlah broker x

  load balancer dan tidak menggunakan load balancer dengan pengujian dimana setiap broker

  Dari pengujian yang dilakukan untuk mengetahui CPU Usage ketika menggunakan

  4.4. Pengujian untuk mengetahui resource CPU Broker saat menangani subscriber ketika tidak menggunakan dan menggunakan load balancer.

  broker , tentu hasilnya akan lebih cepat karena waktu proses di load balancer tidak ada.

  melakukan koneksi secara langsung dengan

  balancer . Sedangkan ketika subscriber

  seperti yang ditunjukkan gambar 8. jika dibandingkan dengan beban awal ketika hanya ada 1 broker aktif. Sedangkan untuk mekanisme rekoneksi ketika terjadi kegagalan di

  balancer

  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

  balancer melakukan modifikasi paket sehingga

  merata. Selain itu didapatkan hasil jika load

  broker yang ada. Selain itu algoritma round robin mampu mendistribusikan load secara

  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

  5. KESIMPULAN

  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.

  Tabel 2 Waktu rekoneksi ketika broker sibuk

  Tabel 2 merupakan tabel data yang menunjukkan waktu yang dibutuhkan untuk rekoneksi ketika semua broker sedang sibuk, sehingga ddapatkan hasil yang variatif.

  Tabel 1 Waktu rekoneksi ketika broker idle

  broker lain. Dimana kecepatannya sebesar 1.007 detik untuk hampir semua percobaan.

  mendistribusikan client tersebut ke

• – benar data yang dikirimkan oleh publisher .

salah satu broker, waktu yang dibutuhkan sebesar 1,007 detik ketika CPU Broker sedang

  Tabel 1 merupakan tabel data yang menunjukkan waktu yang dibutuhkan untuk melakukan rekoneksi ketika broker yang terhubung mengalami kegagalan sehingga load

  Gambar 8 Grafik Utilisasi CPU Broker 1

  4.8. Pengujian rekoneksi ketika broker yang tersambung mengalami kegagalan

  Berdasarkan pengujain ini, terbukti bahwa data yang dikirimkan oleh broker merupakan benar

  Gambar 12 Subscriber menerima pesan

  Subscriber menerima pesan dari publisher pada gambar 12.

  Gambar 11 Publisher melakukan publish pesan

  pesan dengan topik broker 1 yang ditandai dengan kotak merah pada gambar 11.

  Gambar 10 Subscriber melakukan subscription Publisher dengan client_id 1 mengirimkan

  4.7. Pengujian integritas data Subscriber dengan client_id A berlangganan topik broker1 sesuai dengan gambar 10.

  Gambar 9 Diagram Utilisasi CPU semua devices

  perbedaan CPU Usage dari setiap broker tidak berbeda jauh dan cenderung rata dan stabil.

  server sama. Dari gambar 9 bisa dilihat juga

  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

  broker dan 60% ketika menggunakan 3 broker

  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.

  IEEE International Conference on Broadband Network and Multimedia Technology (IC- BNMT). pp. 212

  Service Capability Interaction Management. In 2010 3rd

  Zha, J. et al., 2010. Research on load balance of

  Design and Implementation of Push Notification System Based on the MQTT Protocol. International Conference on Information Science and Computer Applications . Issue date Oktober 2013.

  Tang, K. et al., 2013.

• –217.

6. DAFTAR PUSTAKA Ardy, L., Bhawiyuga, A., & Yahya, W. (2017).

  [Online]. Bisa diakses pada Terakhir akses pada 30 Desember 2017.

  Internet Business Solutions Group (IBSG). Ellrod, C., 2010. Load balancing – Round robin.

  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.

  Things, how the next evolution of the Internet is changing everything . Cisco

  Evans, D., 2011. White paper: the Internet of

  Predictive Connected Car Maintenance Approach. International Journal of Interactive Multimedia and Artificial Intelligence, Vol 4.

  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

  Implementasi Load balancer Berdasarkan Server Status Pada Arsitektur Software Defined Network (SDN).

  Evans, D, 2011. White paper: the Internet of