Jurnal Teknik Informatika dan Sistem Informasi ISSN 2407-4322
Vol. 10, No. 1, Maret 2023, Hal. 406-420 E- ISSN 2503-2933 406
Perbandingan Performa Web Services Yang Dibangun Menggunakan Arsitektur Monolithic Dan Microservices
Pada Sistem Point of Sales
Fiqri Syah Redha1, Renny Puspita Sari2, Syahru Rahmayuda3
1,2,3
Jurusan Sistem Informasi, Fakultas MIPA Universitas Tanjungpura Jalan Prof Dr. H. Hadari Nawawi Pontianak
Telp./Fax.:(0561) 577963
e-mail: 1[email protected], 2[email protected],
Abstrak
Dalam pengembangan perangkat lunak terdapat banyak jenis arsitektur yang dapat diguankan. Dua di antaranya adalah arsitektur monolithic dan microservices. Banyak pertimbangan yang harus diperhatikan saat memilih arsitektur perangkat lunak. Pada penelitian ini kedua arsitektur perangkat lunak yaitu monolithic dan microservices dibandingkan pada pengembangan sistem POS NekoToko. Web services dari sistem tersebut dikembangkan menggunakan kedua arsitektur tersebut dan diuji performanya melalui load testing. Pengujian dilakukan dengan tiga skenario berbeda; monolithic menggunakan host Linux, monolithic menggunakan Docker, dan microservices menggunakan Docker. Parameter yang diamati yaitu penggunaan CPU, penggunaan memory, response time, dan throughput.
Dari hasil load testing menggunakan Locust dengan 100 user, response time dan throughput dari arsitektur monolithic yaitu 421 milidetik dan 230,5 rps. Sedangkan pada arsitektur microservices, response time dan throughput yaitu 415 milidetik dan 233,8 rps. Penggunaan CPU dan memory pada arsitektur microservices (skenario 3) rata-rata 22% dan 1.135 MB lebih besar daripada penggunaan CPU arsitektur monolithic (skenario 1). Oleh karena itu arsitektur monolithic dipilih untuk sistem POS NekoToko dikarenakan dengan sumber daya yang digunakan lebih kecil dapat memberikan performa yang sama dengan microservices yang menggunakan sumber daya yang lebih besar.
Kata kunci: arsitektur perangkat lunak, monolithic, microservices, load testing, point of sale
Abstract
In software development there are many types of architecture that can be used. Two of them are monolithic architecture and microservices. Many considerations must be taken into account when choosing a software architecture. In this study, the two software architectures, namely monolithic and microservices, were compared to the development of the NekoToko POS system. The web services of the system were developed using these two architectures and tested for their performance through load testing. Tests were carried out with three different scenarios; monolithic uses Linux hosts, monolithic uses Docker, and microservices uses Docker. Parameters observed are CPU usage, memory usage, response time, and throughput.
From the results of load testing using Locust with 100 users, the response time and throughput of the monolithic architecture are 421 milliseconds and 230.5 rps. While in the microservices architecture, the response time and throughput are 415 milliseconds and 233.8 rps. CPU and memory usage in microservices architecture (scenario 3) is on average 22% and 1,135 MB is
407
Jatisi ISSN 2407-4322 Vol. 10, No. 1, Maret 2023, Hal. 406-420 E-ISSN 2503-2933
greater than CPU usage in monolithic architecture (scenario 1). Therefore, the monolithic architecture was chosen for the NekoToko POS system because with smaller resources it can provide the same performance as microservices that use larger resources.
Keywords: software architecture, monolithic, microservices, load testing, point of sale
1. PENDAHULUAN
ada mulanya pengguna internet hanya menjadi penikmat konten yang dibuat oleh pembuat situs web. Konten disediakan dalam bentuk statis sehingga semua pengunjung situs mendapatkan konten yang sama. Namun seiring berkembangnya serta bertambahnya jumlah pengguna internet, pada tahun 2004 terjadi perubahan yang besar pada internet. Saat itu mulai bermunculan situs-situs media sosial, komunitas virtual, dan blog yang memungkinkan pengguna terdaftar membuat konten mereka sendiri. Satu dari banyak karakteristik internet pada saat itu adalah pengunjung situs web dapat melakukan pendaftaran dan membuat akun yang memungkinkan untuk mempublikasikan artikel, tulisan, foto, video, dan lain sebagainya. Era itu dikenal fase kedua dari revolusi internet atau disebut dengan Web 2.0 [1].
Berkembangnya internet menjadi Web 2.0 memunculkan aplikasi-aplikasi berbasis web yang sangat populer di antaranya Facebook dan YouTube. Kedua situs tersebut kini memiliki miliaran pengguna dari seluruh dunia dan menghasilkan ribuan jam konten setiap hari. Situs- situs besar seperti Facebook dan YouTube tentunya memiliki tantangan dalam menangani jumlah pengguna sebesar itu. Pemilihan arsitektur perangkat lunak yang tepat dapat membuat kedua situs tersebut berkembang menjadi aplikasi web yang menangani jutaan pengunjung setiap harinya. Dalam rekayasa perangkat lunak, terdapat berbagai macam arsitektur yang dapat digunakan untuk membangun aplikasi dari skala kecil maupun skala besar seperti Facebook dan YouTube. Beberapa yang terkenal seperti monolithic, microservices, event-driven, service- oriented, dan client- server [2, 3].
Pemilihan arsitektur yang tepat merupakan pertimbangan yang dilakukan saat ingin mengembangkan perangkat lunak. Misalnya, ketika baru pertama kali mengembangkan aplikasi, pengembang memilih arsitektur monolithic. Seiring berjalannya waktu, pengguna aplikasi tersebut meningkat sehingga aplikasi perlu dimodifikasi untuk dapat menangani banyak pengguna dalam waktu yang bersamaan. Aplikasi yang dikembangkan dengan arsitektur monolithic hanya dapat diskalakan secara horizonal yaitu menjalankan banyak aplikasi tersebut dan diatur oleh load-balancer. Selain itu, ketika ingin mengubah satu komponen dari aplikasi yang menggunakan arsitektur monolithic, maka seluruh aplikasi perlu di-deploy ulang [4].
Arsitektur microservices dapat menjadi solusi terhadap permasalahan yang dimiliki oleh arsitektur monolithic. Dengan arsitektur microservices, aplikasi dapat dibagi dalam service- service atau aplikasi kecil yang memiliki tanggung jawab masing-masing yang saling terhubung satu sama lain sehingga menjadi satu aplikasi utuh serta dapat di-deploy secara independen.
Untuk mencapai kemampuan tersebut, setiap service pada arsitektur microservices memiliki model data yang jelas sehingga setiap service dapat bertanggung jawab mengerjakan tugasnya masing-masing [5].
Tentu saja tidak semua aplikasi cocok dibangun menggunakan arsitektur microservices, begitu juga sebaliknya. Penentuan arsitektur di awal pengembangan aplikasi akan mempengaruhi kinerja aplikasi kedepannya sehingga penentuan arsitektur di awal pengembangan sangatlah penting. Oleh karena itu perlu dilakukan perbandingan antara kedua arsitektur tersebut untuk melihat seberapa besar perbedaan performanya pada studi kasus tertentu.
P
Jatisi ISSN 2407-4322
Vol. 10, No. 1, Maret 2023, Hal. 406-420 E- ISSN 2503-2933 408
Beberapa penelitian yang relevan telah dilakukan dengan menghasilkan kesimpulan yang berbeda. Seperti pada penelitian [6] yang melakukan 3 skenario pengujian menggunakan JMeter pada sistem yang dibangun menggunakan Spring Boot dan Angular yaitu load testing, concurrency testing, dan endurance testing. Parameter yang diamati yaitu response time dan throughput. Dari penelitian tersebut disimpulkan performa dari arsitektur monolithic dan microservices sama namun arsitektur monolithic memiliki performa yang lebih baik jika pengguna sistem sedikit. Microservices lebih unggul dalam hal response time dan request yang lebih kecil. Pada pengujian kedua yaitu concurrency testing, arsitektur microservices memiliki performa yang lebih baik dibandingkan monolithic dalam hal kemampuan request yang dapat ditangani setiap detik. Pada skenario ke-3 yaitu endurance testing, Consul service discovery memiliki performa yang lebih baik dibandingkan Eureka service discovery.Pada penelitian lain yang menggunakan metode experimental design yang terdiri dari desain dan implementasi aplikasi, skenario pengujian performa, pengumpulan data, dan evaluasi menggunakan model matematika, menyimpulkan arsitektur microservices yang menggunakan containers lebih efisien. Penggunaan perangkat keras, biaya yang lebih sedikit, dan produktivitas yang tinggi didapatkan ketika menggunakan arsitektur microservices [7]. Pada penelitian lain juga menyimpulkan aristektur microservices lebih efisien ketika bekerja dengan jumlah permintaan klien yang tinggi, sedangkan pada arsitektur monolithic lebih efisien ketika jumlah permintaan klien atau jaringan yang sedikit [8]. Pada penelitian ini akan dilakukan perbandingan performa antara arsitektur monolithic dan microservices pada web services atau back-end dari point of sale NekoToko yang akan dibangun kembali menggunakan kedua arsitektur tersebut dengan framework NestJS dan database PostgreSQL sehingga dapat menentukan arsitektur yang lebih tepat pada studi kasus ini.
2. METODE PENELITIAN
Penelitian ini menggunakan kerangka kerja IS Research yang dikemukakan oleh Alan Hevner. Kerangka kerja ini digunakan sebagai panduan dalam menyusun dan mengevaluasi penelitian di bidang sistem informasi [9]. Kerangka kerja IS Research terdiri dari 3 komponen yaitu Environment, IS Research, dan Knowledge Base. Environment menjelaskan stakeholder yang terlibat pada penelitian ini, IS Research menjabarkan tahapan dalam pengembangan sistem, dan Knowledge Base menjabarkan kumpulan dasar pengetahuan yang digunakan pada penelitian ini. Kerangka kerja IS Research penelitian ini dapat dilihat pada Gambar 1.
409
Jatisi ISSN 2407-4322 Vol. 10, No. 1, Maret 2023, Hal. 406-420 E-ISSN 2503-2933
Gambar 1. Kerangka Kerja IS Research
Penelitian ini dilakukan pada coffee shop Narkopika dengan tujuan untuk membangun kembali web service (back-end) dari point of sales NekoToko serta membandingkan performa arsitektur web services yang digunakan pada point of sales tersebut. Knowledge Base atau basis pengetahuan yang digunakan terdiri dari pengembangan perangkat lunak, arsitektur perangkat lunak, monolithic, microservices, dan point of sales. Basis pengetahuan ini menjadi dasar ilmu dalam penelitian ini.
2.1. Pengujian Performa Sistem
Pengujian yang dilakukan adalah load testing. Load testing merupakan bentuk pengujian non-fungsional perangkat lunak untuk mengevaluasi kinerja dari perangkat lunak saat aplikasi digunakan oleh banyak pengguna dalam waktu yang bersamaan. Pengujian ini bertujuan untuk melihat seberapa baik aplikasi menangani permintaan yang banyak secara bersamaan agar dapat diperhitungkan seberapa mampu aplikasi dalam menangani kasus tersebut ketika aplikasi sudah digunakan oleh pengguna [10, 11].
Pada penelitian ini, sistem atau web services diuji dan dibandingkan performanya dengan di-deploy menggunakan virtual machine Linux. Pengujian performa web services menggunakan open-source software yaitu Locust dan New Relic yang berfungsi sebagai pencatatan dan pengukuran. Pengujian web services dilakukan dalam tiga skenario yaitu monolithic menggunakan host Linux, monolithic menggunakan Docker containers, dan microservices menggunakan Docker containers. Pengujian sistem menggunakan compute engine dari Google Cloud Platform. Diagram alur pengujian yang dilakukan pada saat pengujian web services dapat dilihat pada Gambar 2.
Jatisi ISSN 2407-4322
Vol. 10, No. 1, Maret 2023, Hal. 406-420 E- ISSN 2503-2933 410
Gambar 2. Alur Pengujian 2.1.1. Parameter Pengujian
Kriteria atau parameter yang diujikan adalah sebagai berikut.
1) Penggunaan CPU
Penggunaan CPU mengacu pada persentase penggunaan CPU yang diukur saat sistem melakukan sebuah operasi. Pada penelitian ini penggunaan CPU diukur ketika web services diuji dengan permintaan jaringan dalam jumlah besar. Pengukuran penggunaan CPU menggunakan persentase penggunaan CPU oleh sistem.
2) Penggunaan Memory
Penggunaan memory atau RAM mengacu pada penggunaan RAM yang diukur saat sistem memproses sebuah operasi. Pada penelitian ini penggunaan memory diukur ketika web services diuji dengan permintaan jaringan dalam jumlah besar. Pengukuran penggunaan RAM menggunakan satuan megabyte.
3) Response Time
Response time adalah waktu yang dibutuhkan sistem untuk menanggapi permintaan dari sistem lain sampai proses tersebut selesai. Misalnya pada pengujian di penelitian ini, response time diukur ketika web services menerima permintaan jaringan melalui sebuah endpoint API sampai berhasil mengembalikan response. Pengukuran response time dilakukan menggunakan satuan milidetik (ms).
4) Throughput
Throughput adalah jumlah proses atau transaksi yang dapat ditangani dalam satuan waktu.
Pada penelitian ini, web services diuji dengan jumlah transaksi yang banyak dan akan dihitung banyaknya transaksi yang berhasil per detik. Pengukuran throughput dilakukan menggunakan satuan jumlah respon per detik (rps).
2.1.2. Skenario Pengujian
Pengujian web services dilakukan dalam tiga skenario berbeda yaitu sebagai berikut.
1) Skenario monolithic menggunakan host Linux
Pada skenario ini, web service dengan arsitektur monolithic dijalankan secara langsung di atas host Linux menggunakan PM2 process manager. Sementara database menggunakan 1 kontainer Docker. Diagram pengujian dapat dilihat pada Gambar 3.
411
Jatisi ISSN 2407-4322 Vol. 10, No. 1, Maret 2023, Hal. 406-420 E-ISSN 2503-2933
Gambar 3. Skenario Monolithic Menggunakan Host Linux 2) Skenario monolithic menggunakan Docker
Pada skenario ini, web service dengan arsitektur monolithic dijalankan menggunakan Dockeryang terdiri dari tiga aplikasi Node.js yang diatur menggunakan Nginx load balancer.
Sementara database menggunakan 1 kontainer Docker. Diagram pengujian dapat dilihat pada Gambar 4.
Gambar 4. Skenario monolithic menggunakan Docker 3) Skenario Monolithic Menggunakan Docker
Pada skenario ini, web service dengan arsitektur microservices dijalankan menggunakan Docker yang terdiri dari tiga service atau aplikasi yang dihubungkan menggunakan Kong API Gateway. Setiap service memiliki instance database tersendiri yang berjalan menggunakan 1 kontainer Docker. Diagram pengujian dapat dilihat pada Gambar 5.
Jatisi ISSN 2407-4322
Vol. 10, No. 1, Maret 2023, Hal. 406-420 E- ISSN 2503-2933 412
Gambar 5. Skenario Microservices Menggunakan Docker
3. HASIL DAN PEMBAHASAN 3.1. Arsitektur Sistem
Web service atau back-end yang diuji pada penelitian ini dibangun menggunakan arsitektur monolithic dan microservices sebagai berikut.
3.1.1. Arsitektur Sistem Monolithic
Pada web service yang dibangun menggunakan arsitektur monolithic, database yang digunakanhanya satu dan web service dibangun dalam satu aplikasi utuh. Diagram arsitektur sistem monolithic dapat dilihat pada Gambar 6.
Gambar 6. Arsitektur Sistem Monolithic 3.1.2. Arsitektur Sistem Microservices
Pada web service yang dibangun menggunakan arsitektur microservices, web service dibangun dalam tiga service yang berbeda dan masing-masing service menggunakan database tersendiri. Kong digunakan sebagai API gateway dan RabbitMQ sebagai message broker.
Diagram arsitektur sistem microservices dapat dilihat pada Gambar 7.
413
Jatisi ISSN 2407-4322 Vol. 10, No. 1, Maret 2023, Hal. 406-420 E-ISSN 2503-2933
Gambar 7. Arsitektur Sistem Microservices 3.2. Hasil Pengujian
Pengujian performa web services arsitektur monolithic dan microservices dilakukan sebanyak 3 kali pada setiap skenario. Percobaan pertama menjalanakan Locust dengan 100 user dan spawn rate 20 user per detik. Percobaan kedua menjalankan Locust dengan 200 user dan spawn rate 40 user per detik. Percobaan ketiga menjalankan Locust dengan 400 user dan spawn rate 40 user per detik. Semua percobaan akan dijalankan selama 2 menit dan diambil rata-rata penggunaan CPU, penggunaan memory, response time, dan throughput selama waktu percobaan tersebut.
Selain menggunakan Locust, percobaan juga akan menggunakan platform New Relic dan New Relic infrastructure agent yang dipasang pada virtual machine yang menjalankan web services. Dengan New Relic infrastructure agent, virtual machine dapat dipantau statusnya seperti penggunaan CPU, penggunaan memory, penggunaan storage, dan lain sebagainya. Data penggunaan CPU dan memory pada pengujian ini diperoleh dari New Relic.
Setelah mempersiapkan pengujian dan menjalankan load testing sesuai dengan langkah yang sudah ditentukan dan dirancang maka hasil dari pengujian dapat dilihat sebagai berikut.
3.2.1. Skenario Monolithic Menggunakan Host Linux
Hasil pengujian 3 kali percobaan pada skenario ini dapat dilihat pada Tabel 1.
Tabel 1. Hasil Pengujian Skenario 1 Percobaan Jumlah
User
Spawn Rate
Jumlah Request
Response Time
(ms)
Throughput (rps)
1 100 20 27.643 421 230,5
2 200 40 28.069 832 233,8
3 400 40 28.240 1.613 235,5
Dari tabel tersebut dapat dilihat bahwa rata-rata throughput dari skenario pertama ini stabil dengan hasil sekitar 230-an rps. Kestabilan tersebut dapat dilihat pada grafik throughput dari percobaan pertama yang dihasilkan oleh Locust yang dapat dilihat pada Gambar 8
Jatisi ISSN 2407-4322
Vol. 10, No. 1, Maret 2023, Hal. 406-420 E- ISSN 2503-2933 414
Gambar 8. Grafik Throughput Percobaan Pertama Skenario 1
Dari grafik tersebut dapat dilihat bahwa fluktuasi sangat minim dan hampir keseluruhan waktu pengujian memiliki throughput yang sama. Hal yang sama juga terjadi pada response time skenario ini, yang dapat dilihat pada Gambar 9
Gambar 9. Grafik Response Time Percobaan Pertama Skenario 1
Dapat dilihat dari grafik tersebut response time dari skenario 1 ini sangat stabil dan dapat dikatakan tidak ada fluktuasi yang signifikan terjadi. Rata-rata response time masih di bawah 500 milidetik per 100 user.
3.2.2. Skenario Monolithic Menggunakan Docker
Hasil pengujian 3 kali percobaan pada skenario ini dapat dilihat pada Tabel 2 Tabel 2. Hasil Pengujian Skenario 2
Percobaan Jumlah User
Spawn Rate
Jumlah Request
Response Time
(ms)
Throughput (rps)
1 100 20 42.187 276 351,6
2 200 40 42.812 545 356,7
3 400 40 42.596 1.067 354,9
415
Jatisi ISSN 2407-4322 Vol. 10, No. 1, Maret 2023, Hal. 406-420 E-ISSN 2503-2933
Sama seperti pengujian skenario pertama, throughput dari skenario kedua ini juga stabil di kisaran 350-an rps pada ketiga percobaan. Namun, melihat dari grafik yang dihasilkan Locust, angka throughput menurun seiring berjalannya waktu pengujian. Hal tersebut dapat dilihat pada Gambar 10.Gambar 10. Grafik Throughput Percobaan Pertama Skenario 2
Angka throughput menurun seiring berjalannya waktu pengujian dikarenakan sumber daya virtual machine yang digunakan untuk menjalankan skenario kedua ini tidak mampu untuk menjalankan 3 instance web services monolithic secara bersamaan. Hal tersebut dapat dilihat dari grafik penggunaan CPU yang diperoleh dari New Relic pada Gambar 11
Gambar 11. Grafik Penggunaan CPU Percobaan Pertama Skenario 2
Jatisi ISSN 2407-4322
Vol. 10, No. 1, Maret 2023, Hal. 406-420 E- ISSN 2503-2933 416
Dari grafik tersebut dapat dilihat bahwa penggunaan CPU selama menajalankan pengujian berada di atas angka 90%. Seiring berjalannya waktu pengujian angka penggunaan CPU mendekati 100%. Tentunya hal ini berdampak pada jumlah request yang dapat ditangani web services.3.2.3. Skenario Microservices Menggunakan Docker
Hasil pengujian 3 kali percobaan pada skenario ini dapat dilihat pada Tabel 3 Tabel 3. Hasil Pengujian Skenario 3
Percobaan Jumlah User
Spawn Rate
Jumlah Request
Response Time
(ms)
Throughput (rps)
1 100 20 28.062 415 233,8
2 200 40 28.671 814 238,9
3 400 40 28.422 1.610 236,8
Hasil yang didapatkan dari pengujian ini tidak terdapat perbedaan yang signifikan dengan hasil pengujian pada skenario pertama. Throughput pada pengujian ini juga berkisar di angka 230-240 rps. Namun stabilitas throughput tidak seperti pada skenario pertama yang hampir datar grafiknya melainkan terdapat beberapa fluktuasi selama masa pengujian. Hal itu dapat dilihat pada Gambar 12
Gambar 12. Grafik Throughput Percobaan Ketiga Skenario 3
Dapat dilihat pada grafik tersebut terlebih pada grafik 5.13 bahwa terdapat beberapa fluktuasi pada throughput skenario ini. Rata-rata response time pada percobaan ketiga pun terdapat fluktuasi dan meningkat seiring berjalannya waktu pengujian. Grafik response time percobaan ketiga dapat dilihat pada Gambar 13
417
Jatisi ISSN 2407-4322 Vol. 10, No. 1, Maret 2023, Hal. 406-420 E-ISSN 2503-2933
Gambar 13. Grafik Response Time Percobaan Ketiga Skenario 3 3.2.4. Penggunaan CPU dan Memory
Data hasil penggunaan CPU dan penggunaan memory diperoleh dari New Relic. Data ini diambil menggunakan NRQL (New Relic Query Language) pada halaman Query builder dengan memasukkan timestamp pengujian dimulai dan timestamp pengujian selesai. Waktu mulai pengujian sampai pengujian selesai menyesuaikan dengan waktu pada pengujian menggunakan Locust. Setelah menjalankan query tersebut pada setiap percobaan pengujian maka diperoleh hasil yang dapat dilihat pada Tabel 4.
Tabel 4. Penggunaan CPU dan Memory Skenario Percobaan Penggunaan
CPU (%)
Penggunaan Memory
(MB) 1
1 59,9 1.178
2 62 1.217
3 62,8 1.267
2
1 88,2 3.919
2 88,9 4.031
3 88,9 4.070
3
1 82,6 2.024
2 83,6 2.458
3 85,7 2.585
Dari Tabel 4, semua percobaan pengujian pada skenario pertama memiliki rata-rata penggunaan CPU dan memory paling rendah di antara keseluruhan pengujian. Hal ini tentu saja dikarenakan hanya 1 instance web services dan database PostgreSQL yang berjalan. Skenario kedua memiliki rata-rata penggunaan memory 3 kali lipat lebih banyak daripada pengujian pada skenario 1. Namun melihat dari hasil throughput pengujian, throughput dari skenario 2 ini tidak sampai 2 kali lipat lebih besar daripada skenario 1.
Pada skenario 3, penggunaan CPU hampir setara dengan pengujian skenario 2. Rata-rata penggunaan memory 2 kali lipat lebih besar daripada skenario 1. Hal ini dikarenakan pada skenario ini 3 instance database PostgreSQL, 1 instance RabbitMQ, dan 1 instance Kong API Gateway berjalan pada saat pengujian. Meskipun menjalankan 3 database, 1 message broker, dan 1 API gateway, penggunaan memory jauh lebih sedikit dibandingkan skenario 2.
Jatisi ISSN 2407-4322
Vol. 10, No. 1, Maret 2023, Hal. 406-420 E- ISSN 2503-2933 418
3.3. Kesimpulan Pengujian
Dari hasil pengujian yang telah dilakukan diperoleh bahwa response time dari setiap percobaan skenario 1 dan skenario 3 menghasilkan angka yang tidak berbeda cukup jauh yaitu di angka 400-an, 800-an, dan 1.600-an milidetik. Skenario 2 menghasilkan response time yang jauh lebih kecil yaitu di angka 276, 545, dan 1.067 milidetik. Menjalankan lebih dari 1 instance web service seperti pada skenario 2 dapat menghasilkan angka response time yang lebih kecil.
Perbedaan tersebut dapat dilihat pada Gambar 14 yang menunjukkan response time dari percobaan ketiga dari semua skenario.
Gambar 14. Response Time Semua Skenario
Throughput pada setiap percobaan skenario 1 dan skenario 3 menghasilkan angka yang hampir sama yaitu di 230-an request per second. Dapat dilihat juga jumlah request yang berhasil dipenuhi berkisar di angka 28.000-an, kecuali pada percobaan pertama skenario 1 yang memberikan hasil 27.643 rps. Melihat dari hasil tersebut dapat disimpulkan bahwa throughput dari arsitektur monolithic dan microservices memberikan performa yang sama melihat throughput dari skenario 1 dan skenario 3. Perbedaan tersebut dapat dilihat pada Gambar 15 yang menunjukkan throughput dari percobaan ketiga semua skenario.
Gambar 15. Throughput Semua Skenario
419
Jatisi ISSN 2407-4322 Vol. 10, No. 1, Maret 2023, Hal. 406-420 E-ISSN 2503-2933
Terdapat perbedaan yang cukup besar pada penggunaan CPU dari ketiga skenario. Pada ketiga percobaan skenario 1, penggunaan CPU berkisar di angka 60-an % yaitu 59,9%, 62%, dan 62,8 %. Pada ketiga percobaan skenario 2, penggunaan CPU berada di angka 88% yaitu 88,2% pada percobaan pertama dan 88,9% pada percobaan kedua dan ketiga. Skenario 3 memberikan angka penggunaan CPU yang lebih kecil dari skenario 2 namun tetap menggunakan CPU lebih besar dibandingkan skenario 1 yaitu di angka 82,6%, 83,6%, dan 85,7% dari setiap percobaan.Penggunaan memory dari ketiga skenario juga memberikan perbedaan seperti pada penggunaan CPU. Pada ketiga percobaan skenario 1, penggunaan memory berkisar antara 1.100-an sampai 1.200-an MB yaitu 1.178 MB, 1.217 MB, dan 1.267 MB pada setiap percobaan. Skenario 2 menghasilkan angka penggunaan memory yang jauh lebih tinggi dari skenario 1 dan lebih dari 3 kali lipat penggunaan memory pada skenario 1 yaitu 3.919 MB, 4.031 MB, dan 4.070 MB. Penggunaan memory dari setiap percobaan skenario 3 yaitu 2.024 MB, 2.458 MB, dan 2.585 MB.
4. KESIMPULAN
Dari semua hasil pengujian tersebut, tidak terdapat perbedaan yang signifikan pada performa response time dan throughput dari arsitektur monolithic dan microservices pada pengujian skenario 1 dan 3 yaitu di angka 400-an, 800-an, dan 1.600-an milidetik untuk response time dan 230-an rps untuk throughput. Meskipun memberikan performa yang sama pada response time dan throughput, penggunaan CPU dan memory dari arsitektur monolithic dan microservices pada skenario 1 dan 3 terdapat perbedaan. Penggunaan CPU dan memory pada arsitektur microservices (skenario 3) rata-rata 22% dan 1.135 MB lebih besar daripada penggunaan CPU arsitektur monolithic (skenario 1).
Menjalankan 3 instance web services yang berarsitektur monolithic secara bersamaan dengan load balancer pada skenario 2 pun tidak memberikan throughput 2 sampai 3 kali lipat dari skenario 1. Pada percobaan pertama skenario 1, throughput yang dihasilkan adalah 230,5 rps, sedangkan pada percobaan pertama skenario 2 adalah 351,6 rps. Dari angka throughput tersebut, skenario 2 hanya mampu menghasilkan 1,5 kali jumlah rps dari skenario 1 meskipun menjalankan 3 instance web services secara bersamaan.
5. SARAN
Saran untuk penelitian selanjutnya yaitu melakukan perbandingan dengan skala yang lebih besar seperti pada web service yang menggunakan arsitektur microservices yang terdiri dari puluhan service. Selain itu dapat memanfaatkan kelebihan arsitektur microservices misalnya dengan menggunakan database yang berbeda pada setiap service dan menjalankan setiap service dan instance database tersebut pada mesin yang berbeda. Selain itu dapat juga memanfaatkan fitur auto-scaling pada layanan cloud ke setiap service sehingga ketika service tersebut menangani permintaan yang banyak, service tersebut dapat diskalakan dengan membuat replika service tersebut pada mesin yang berbeda. Untuk mendapatkan perbedaan yang lebih akurat dapat menggunakan perhitungan menggunakan model matematika.
Jatisi ISSN 2407-4322
Vol. 10, No. 1, Maret 2023, Hal. 406-420 E- ISSN 2503-2933 420
DAFTAR PUSTAKA
[1] Murugesan, S. 2007. Understanding Web 2.0. IT Professional, 9, 34–41.
[2] Gruhn, V., & Striemer, R. (Ed.). 2018. The Essence of Software Engineering. Cham:
Springer International Publishing.
[3] Jaiswal, M. 2019. Software Architecture and Software Design. International Research Journal of Engineering and Technology (IRJET), 06, 2452–2454.
[4] Ponce Mella, F., Márquez, G., & Astudillo, H. 2019, September 10. Migrating from monolithic architecture to microservices: A Rapid Review. International Conference of the Chilean Computer Science Society, SCCC 2019.
[5] Shadija, D., Rezai, M., & Hill, R. 2017. Towards An Understanding of Microservices.
2017 23rd International Conference on Automation and Computing (ICAC), 1–6.
Huddersfield, United Kingdom: IEEE.
[6] Al-Debagy, O., & Martinek, P. 2018. A Comparative Review of Microservices and Monolithic Architectures. 2018 IEEE 18th International Symposium on Computational Intelligence and Informatics (CINTI), 000149–000154. Budapest, Hungary: IEEE.
[7] Tapia Leon, F., Mora, M., Fuertes, W., Aules, H., Flores, E., & Toulkeridis, T. 2020.
From Monolithic Systems to Microservices: A Comparative Study of Performance.
Applied Sciences, 10, 5797.
[8] Gos, K., & Zabierowski, W. 2020. The Comparison of Microservice and Monolithic Architecture (hlm. 153). 2020 IEEE XVIth International Conference on the Perspective Technologies and Methods in MEMS Design (MEMSTECH).
[9] Puspita Sari, R., Rusi, I., & Febriyanto, F. 2021. Penerapan Metode Weighted Product pada Sistem Penentuan Dosen Pembimbing dan Penguji Skripsi. Jurnal Teknik Informatika Dan Sistem Informasi, 8, 1429–1441.
[10] Pradeep, S., & Sharma, Dr. Y. 2019, Februari 1. A Pragmatic Evaluation of Stress and Performance Testing Technologies for Web Based Applications. 399–403.
[11] Shrivastava, S., & Sb, P. 2020. Comprehensive Review of Load Testing Tools.
International Research Journal of Engineering and Technology (IRJET), 07, 3392–3395.