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 Redha 1 , Renny Puspita Sari 2 , Syahru Rahmayuda 3 1,2,3 Jurusan Sistem Informasi, Fakultas MIPA Universitas Tanjungpura Jalan Prof Dr. H. Hadari Nawawi Pontianak Telp./Fax.:(0561) 577963 e-mail: 1 fiqrisyahredha27@student.untan.ac.id, 2 rennysari@sisfo.untan.ac.id,
3 yudarahma@sisfo.untan.ac.id

## 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
Title of manuscript is short and clear, implies research results (First Author)
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
Title of manuscript is short and clear, implies research results (First Author)
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
Fiqri , et., al [ Perbandingan Performa Web Services yang Dibangun Menggunakan Arsitektur Monolithic \dan Microservices pada Sistem Point of Sales ]
Title of manuscript is short and clear, implies research results (First Author)
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
Title of manuscript is short and clear, implies research results (First Author)
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
Title of manuscript is short and clear, implies research results (First Author)
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
Title of manuscript is short and clear, implies research results (First Author)
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
Title of manuscript is short and clear, implies research results (First Author)
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.