i
Perbandingan Performa Implementasi Apache Thrift dan HTTP REST API sebagai Remote Procedure Call (RPC)
dalam Arsitektur Microservice di PT. XYZ
SKRIPSI
Oleh:
ZIDNI MUBAROK 109091000122
PROGRAM STUDI TEKNIK INFORMATIKA FAKULTAS SAINS DAN TEKNOLOGI
UNIVERSITAS ISLAM NEGERI SYARIF HIDAYATULLAH JAKARTA
ii Perbandingan Performa Implementasi Apache Thrift dan HTTP
REST API sebagai Remote Procedure Call (RPC) dalam Arsitektur Microservice di PT. XYZ
( Studi Kassus : PT. XYZ )
Skripsi
Sebagai Salah Satu Syarat untuk Memperoleh Gelar Sarjana Komputer
Fakultas Sains dan Teknologi
Universitas Islam Negeri Syarif Hidayatullah Jakarta
Oleh:
Zidni Mubarok 109091000122
PROGRAM STUDI TEKNIK INFORMATIKA FAKULTAS SAINS DAN TEKNOLOGI
UNIVERSITAS ISLAM NEGRI SYARIF HIDAYATULLAH JAKARTA 2017 M / 1438 H
iii
iv PERNYATAAN
DENGAN INI SAYA MENYATAKAN BAHWA SKRIPSI INI BENAR- BENAR HASIL KARYA SENDIRI YANG BELUM PERNAH DIAJUKAN SEBAGAI SKRIPSI ATAU KARYA ILMIAH PADA PERGURUAN TINGGI ATAU LEMBAGA MANAPUN.
Jakarta, Januari 2017
Zidni Mubarok 109091000122
v Zidni Mubarok – 10909100122, Perbandingan Performa Implementasi Apache Thrift dan HTTP REST API sebagai Remote Procedure Call (RPC) dalam
Arsitektur Microservice di PT. XYZ, Arini, MT, Hendra Bayu Suseno, M.Kom
ABSTRAKSI
PT. XYZ adalah sebuah perusahan yang bergerak dalam bidang teknologi finansial atau Fintech yang ternama yang memiliki misi untuk memberdayai industry e- commerce di Indonesia. Untuk mewujudkan visi itu Perusahaan ini selalu berusaha untuk memberikan pengalaman terbaik untuk para pengguna jasanya dengan cara memberikan performa dan reliabilitas yang terbaik pada platform yang mereka miliki. Untuk menyajikan pengalaman tersebut PT. XYZ mengimplementasikan arsitektur mircoservice pada sistem yang mereka kembangakan. Dengan arsitektur ini PT. XYZ bisa dengan mudah untuk memetakan domain masalah kedalam sebuah service yang dapat saling berinteraksi dengan lainya, maka dari itu fakor kelancaran komunikasi dalam proses interaksi antar service menjadi hal yang selalu diupayakan untuk dioptimalisasi. Protokol HTTP dengan implementasi REST API umumnya menjadi media komunikasi yang di terapkan didalam sistem PT. XYZ, namun protokol ini mengunakan format text yang memiliki ukuran relative lebih besar jika dibandingkan dengan format binary. Dengan fakta tersebut penulis melakukan penelitian untuk membandingkan performa implementasi HTTP REST API dengan Apache Thrift yang mengimplementasikan binary protocol. Dengan penelitian ini diharapkan bisa dijadikan sebagai referensi untuk PT. XYZ untuk memilih alternatif media komunikasi untuk diterapkan dalam arsitektur microservice.
Kata Kunci : HTTP, REST API, Apache Thrift, Microservice, text protocol, binary protocol, performance test
Daftar Pusaka : 26 (Tahun 1983 – Tahun 2016)
vi Kata Pengantar
Puji dan syukur penulis panjatkan kehadirat Allah SWT karena atas rahmat dan hidayah-Nya penulis dapat menyelesaikan penulisan skripsi ini.
Shalawat serta salam selalu kita haturkan kepada Nabi Besar Muhammad SAW, beserta keluarganya, para sahabatnya, dan para pengikutnya.
Skripsi ini berjudul “Perbandingan Performa Implementasi Apache Thrift dan HTTP REST API sebagai Remote Procedure Call (RPC) dalam Arsitektur Microservice di PT. XYZ”. Penyusunan skripsi ini bertujuan untuk memenuhi salah satu syarat dalam menyelesaikan pendidikan S1 Program Studi Teknik Informatika di Universitas Islam Negeri Syarif Hidayatullah Jakarta.
Pada kesempatan yang sangat berbahagia ini penulis ingin menyampaikan ucapan terima kasih yang sebesar-besarnya kepada pihak-pihak yang telah turut membantu dalam penyusunan laporan ini, yaitu :
1) Bapak Dr. Agus Salim, M.Sis, selaku Dekan Fakultas Sains dan Teknologi Universitas Islam Negeri Syarif Hidayatullah Jakarta
2) Ibu Arini, MT, dan Hendra Bayu Suseno, M.Kom, sebagai dosen pembimbing yang senantiasa meluangkan waktunya untuk membimbing dalam proses penulisan skripsi ini.
3) Seluruh Dosen Program Studi Teknik Informatika yang tidak mungkin penulis sebutkan namanya satu persatu.
4) Staff kayawan Fakultas Sains dan Teknologi dan Prodi.
5) Kakak-kakak, adik-adik serta keluarga besar yang selalu memberikan
vii 6) dukungannya kepada penulis.
7) Seluruh Mahasiswa Teknik Informatika angakatan 2009.
8) Dan pihak-pihak lainnya yang tidak dapat disebutkan satu per satu dan telah membantu kelancaran penulisan skripsi ini.
Penulis juga mengucapkan permohonan maaf kepada semua pihak yang terkait, apabila selama ini ada hal-hal yang kurang berkenan. Penulis berharap semoga skripsi ini dapat bermanfaat. Saran dan kritik untuk kesempurnaan skripsi ini sangat penulis harapkan.
Jakarta, Januari 2017
Zidni Mubarok 109091000122
viii Halaman Persembahan
And still, after all this time, the Sun has never said to the Earth, “You owe me.” . Look what happens with love like that, it lights up the sky.
Jalāl ad-Dīn Muhammad Rūmī
Karya ini kupersembahkan kepada :
9) Seorang anak laki-laki kecil dan Istri yang menjadi motivasi bagi ayahnya untuk selalu menjadi lebih baik.
10) Ayah, Ibu, dan Adik – Kakak serta keluarga yang selama ini telah mendukung.
11) Seorang pria yang selalu memberikan tumpangan tempat tinggal di kostanya.
12) Seorang pria yang tidak pernah menolak ketika dimintai bantuan setiap saat.
13) Seorang pria dengan kekritisan, Kegilaan & kejeniusannya dalam prosess penyusunan karya ini.
14) Teman – teman teknik informatika yang sudah menemani selama 7 tahun terakhir.
ix
Daftar Isi
halaman
Halaman Judul ………..……… i
Lembar Persetujuan Pembimbing………...ii
ABSTRAKSI ………..………..………... .v
Kata Pengantar …………..………. vi
Lembar Persembahan ….………vi
Daftar Isi ………...……….. .ix
BAB I Pendahuluan ...1
1.1. Latar Belakang ...1
1.2. Rumusan Masalah ...3
1.3. Batasan Masalah ...4
1.4. Tujuan dan Manfaat Penelitian ...5
1.4.1. Tujuan Penelitian ...5
1.4.2. Manfaat Penelitian ...5
1.5. Metodologi Penelitian ...5
1.5.1. Metode Pengumpulan data ...6
1.5.2. Metode Eksperimental ...6
1.6. Tahapan Penelitian ...7
1.7. Sistematika Penulisan ...8
BAB II Landasan Teori ...10
2.1. Komunikasi Data ...10
2.1.1. Pengertian Komunikasi Data ...10
2.1.2. Komponen Komunikasi Data ...11
2.1.3. Jenis Alur Komunikasi ...12
2.2. Hyper Text Transfer Protocol (HTTP) ...13
2.3. Remote Procedural Call (RPC) ...14
2.3.1. Contoh Syntax ...15
2.4. Metode Eksperimental ...16
2.4.1. Langkah-langkah Metode Eksperimental ...16
2.4.2. Jenis-jenis Metode Eksperimen ...17
2.5. Benchmarking ...18
2.6. Kinerja (Performance) ...19
2.7. Parameter yang akan diukur ...19
x
2.7.1. Transaction Throughput ...19
2.7.2. Response Time ...20
2.7.3. RSS Memory ...20
2.7.4. CPU Usage ...20
2.7.5. Data Throughput ...20
2.8. JMeter ...21
2.9. Ruby ...22
2.10. Node.js ...22
2.11. Apache Thrift ...23
2.12. Go ...24
2.13. Docker ...24
2.14. Datadog ...26
BAB III Metodologi Penelitian ...28
3.1. Metode Pengumpulan Data ...28
3.2. Metode Eksperimental ...29
3.2.1. Fase Perencanaan Eksperimen ...30
3.2.2. Fase Pelaksanaan Eksperimen ...31
3.3. Kerangka Penelitian ...32
BAB IV Pembahasan ...34
4.1. Fase Perencanaan Eksperimen ...34
4.1.1. Langkah-langkah Eksperimen ...34
4.1.2. Desain Eksperimen ...36
4.2. Fase Pelaksanaan Eksperimen ...36
4.2.1. Pengenalan Material yang Digunakan ...37
4.2.2. Pengamatan Performa Eksperimen ...40
4.2.3. Analisa, Intepretasi dan Generalisasi Hasil Eksperimen ...41
BAB V Kesimpulan dan Saran ...51
5.1. Kesimpulan ...51
5.2. Saran ...53
Daftar Pustaka ...54
1 BAB I
Pendahuluan
1.1. Latar Belakang
Pemanfaatan sebuah sistem aplikasi sangat mendukung proses bisnis perusahaan agar lebih efektif dan efisien untuk mencapai visi dan misi. Di satu sisi, proses bisnis akan selalu berubah sesuai dengan perkembangan dan permintaan pasar. Sehingga sistem aplikasi dituntut mampu berkembang mengimbangi tantangan bisnis yang dihadapi perusahaan dari waktu ke waktu. Untuk menjawab tantangan-tantangan dari permasalahan ini, pemilihan arsitektur sistem aplikasi dibutuhkan untuk mendukung proses bisnis yang berubah dengan cepat.
Perusahaan-perusahaan besar seperti Netflix, Ebay, dan AWS memilih pendekatan arsitektur microservice. Solusi ini dipilih karena arsitektur aplikasi microservice ini menggunakan desain yang memecah aplikasi berdasarkan fungsinya secara spesifik. Sehingga fokus penyelesaian domain masalah menjadi spesifik tanpa harus terganggu dengan mempertimbangkan domain masalah diluar lingkup tanggung jawab service itu sendiri. Dengan demikian, pengembang aplikasi yang bertanggung jawab akan service ini bisa fokus memberi solusi dengan kualitas yang lebih baik.
Pada pendekatan arsitektur microservices, suatu aplikasi yang besar terbagi menjadi beberapa service sehingga lebih mudah dikelola. Satu service adalah sebagian fungsionalitas dari sebuah aplikasi besar yang dipisahkan menjadi
2 satu aplikasi yang berdiri sendiri yang berkomunikasi dengan service lainnya melalui protokol atau media yang dibakukan dan sudah disepakati.
Arsitektur microservice juga diterapkan di PT. XYZ. Sebagai perusahaan yang bergerak di bidang payment gateway, penerapan arsitektur microservice dianggap mampu menjawab tantangan-tantangan dalam proses bisnis yang mereka hadapi. PT. XYZ memilah domain masalah yang mereka coba selesaikan dengan memfokuskan satu domain untuk menjadi tanggung jawab satu service yang berkomunikasi dengan service lain.
Media komunikasi untuk menghubungkan antara service satu dengan service lain menjadi sebuah perhatian saat menggunakan arsitektur microservice.
Dikarenakan media komunikasi menentukan performa dari keseluruhan sistem.
Semakin cepat request dan response yang diterima dari suatu service akan semakin lebih baik. Selain itu media komunikasi juga harus mendukung keaneka ragaman bahasa pemrograman.
PT. XYZ menggunakan media komunikasi HTTP API dimana semua request dan response yang dikirim antar service melalui jaringan menggunakan media teks. Pada kondisi ini, satu service akan berperan sebagai server, sedangkan service lain akan berperan sebagai client. Sebuah service yang berperan sebagai server bertanggung jawab memberikan response dari request client, sehingga service yang berperan sebagai server bertanggung jawab menyediakan API (Application Program Interface). Service yang berperan sebagai client harus melakukan request ke server sesuai API yang sudah ditetapkan.
3 Dalam implementasinya, media komunikasi menggunakan arsitektur HTTP API yang sudah diterapkan di Perusahaan XYZ memiliki kelemahan, diantaranya kontrak API-nya terpisah dari kode sumber sehingga membutuhkan dokumentasi detail tentang tata cara penggunaannya di luar kode sumber. Selain itu, protokol HTTP juga menggunakan format teks sebagai media komunikasinya, sehingga ukuran paket yang harus ditransfer melalui network lebih besar dibanding format media lain seperti binary. Ukuran paket yang besar membutuhkan bandwidth lebih besar dan processing time yang lebih lama dalam proses transfernya.
Media komunikasi Apache Thrift menawarkan fitur yang tidak ada pada HTTP API yaitu media komunikasi melalui binary. Dengan adanya komunikasi binary maka kecepatan paket data yang dikirim dan yang diterima antar service akan jauh lebih cepat meskipun paket data yang diproses dalam jumlah yang besar.
Selain itu, Apache Thrift juga menawarkan sebuah kontrak antar service di dalam microservice yang jauh lebih efisien.
Merujuk latar belakang yang telah dipaparkan, peneliti memilih judul:
“Perbandingan Performa Implementasi Apache Thrift dan HTTP REST API sebagai Remote Procedure Call (RPC) dalam Arsitektur Microservice di PT. XYZ”
1.2. Rumusan Masalah
Berdasarkan latar belakang yang telah dijabarkan pada sub-bab sebelum ini, dapat dirumuskan permasalahan penelitian adalah bagaimana mengetahui perbandingan performa sistem dan kinerja komputer pada implementasi Apache
4 Thrift dan HTTP REST API dalam arsitektur microservice dengan parameter- parameter yang diujikan.
1.3. Batasan Masalah
Untuk lebih memfokuskan penelitian ini. Maka diberikan pembatasan masalah pada beberapa bagian, yaitu:
1) Menggunakan bahasa pemrograman Ruby 2.2.4, NodeJS 4.4.7 dan, GO 1.6.3 2) Deployment tool untuk keperluan demo menggunakan Docker 1.12.1
3) Menggunakan framework Apache Thrift versi 0.9.3 untuk implementasi RPC 4) Performance Testing tool menggunakan Apache JMeter versi 3.0.0
5) Monitoring tool menggunakan service Datadog 6) Cloud Server menggunakan service DigitalOcean
7) Tidak membahas detail tentang service dalam PT. XYZ yang digunakan dalam penelitian ini.
8) Tidak membandingkan framework lain yang mengimplementasikan mekanisme RPC.
9) Parameter yang diujikan sebagai pembanding, yaitu: Response Time, RSS Memory, CPU Usage dan Data Throughput.
10) Semua service dalam penelitian ini menggunakan prototipe aplikasi yang berperan sebagai service sebenarnya pada PT. XYZ.
11) Masalah security di luar dari topik penelitian ini.
12) Penelitian tidak membahas detail mengenai arsitektur microservice.
13) Penelitian menggunakan metodologi eksperimental.
5 14) Pengumpulan data menggunakan metode wawancara, dan pencarian literatur
sejenis.
15) Pengujian (testing) aplikasi menggunakan metode black box.
16) Legalitas terkait dengan hukum yang berhubungan dengan UU ITE diluar topik penelitian ini.
1.4. Tujuan dan Manfaat Penelitian 1.4.1. Tujuan Penelitian
Tujuan penelitian adalah mengetahui perbandingan performa sistem dan kinerja antara Apache Thrift dan HTTP API untuk media komunikasi dalam arsitektur microservice di PT XYZ.
1.4.2. Manfaat Penelitian
Beberapa manfaat yang diharapkan muncul dari penelitian ini, antara lain:
1) Mengetahui protocol mana yang memiliki performa lebih baik untuk digunakan sebagai media komunikasi dalam arsitektur microservice.
2) Sebagai referensi untuk penelitian lain yang berkaitan dengan Apache Thrift dan HTTP API.
3) Sebagai rekomendasi kepada PT. XYZ yang ingin menggunakan Apache Thrift dalam arsitektur microservice yang sudah diimplementasikan.
1.5. Metodologi Penelitian
Dalam penelitian ini penulis menggunakan 2 (dua) metode. Yaitu, metode pengumpulan data dan metode pengembangan sistem.
6 1.5.1. Metode Pengumpulan data
Penulis membutuhkan data primer dan data sekunder dalam melakukan penelitian ini, metode-metode yang dilakukan untuk memperoleh data tersebut adalah sebagai berikut:
1) Primer
i) Wawancara 2) Sekunder
i) Studi Pustaka
1.5.2. Metode Eksperimental
Peneliti menggunakan metode eksperimental dalam penelitian ini. Metode ini digunakan untuk menyelidiki ada atau tidaknya pengaruh terhadap suatu populasi yang diberikan perlakuan-perlakuan tertentu. Tahapan dalam metode eksperimental yaitu:
1) Fase Perencanaan Eksperimen
Sebuah eksperimen yang akan dilakukan harus direncanakan sebaik-baiknya, sehingga ada garis pembatas nyata tentang apa yang akan dikerjakan dalam pelaksanaan eksperimen. Ada dua tahap dalam perencanaan eksperimen yaitu:
i) Langkah-langkah eksperimen
Ada tiga langkah penting dalam perencanaan eksperimen yaitu perumusan masalah dan tujuan penelitian, penggambaran dari eksperimen dan outline dari penganalisisan yang akan dikerjakan.
ii) Desain eksperimen
7 Desain eksperimen adalah langkah-langkah yang utuh dan berurutan yang dibuat lebih dahulu, sehingga keterangan yang ingin diperoleh dari
eksperimen akan mempunyai hubungan yang nyata dengan masalah penelitian.
2) Fase Pelaksanaan Eksperimen
Setelah tahap perencanaan dan pemilihan desain telah selesai, kemudian dilakukan tahap pelaksanaan eksperimen. Pada tahap ini ada beberapa langkah yang harus dilakukan yaitu, pengenalan terhadap material yang digunakan dalam eksperimen, pengamatan terhadap performa eksperimen dan analisis, interpretasi dan generalisasi dari penemuan-penemuan.
1.6. Tahapan Penelitian
Table I.1 Tahap dan Kegiatan Penelitian
No Kegiatan
Bulan
Mar Apr Mei Jun Jul Aug 1 Penulisan Proposal
2 Studi Kepustakaan 3 Pengumpulan Data
4 Pembuatan Perangkat Lunak 5 Pengujian Perangkat Lunak 6 Penulisan Laporan Akhir
8 1.7. Sistematika Penulisan
Dalam penyusunan penelitian ini, penulis menyajikan dalam lima bab pokok bahasan, di antaranya adalah:
BAB 1 PENDAHULUAN
Bab ini berisi pendahuluan yang terdiri dari latar belakang masalah, perumusan masalah, batasan masalah, tujuan dan manfaat penulisan, metodologi penelitian, dan sistematika penulisan.
BAB 2 LANDASAN TEORI
Pada bab ini penulis menguraikan teori yang dapat digunakan atau diterapkan dalam penulisan skripsi ini.
BAB 3 METODOLOGI PENELITIAN
Bab ini menguraikan tentang metodologi penelitian yang mencakup pengumpulan data dan tahapan dalam batasan pembuatan perangkat lunak dengan menguraikan proses perancangan dan implementasi perangkat lunak.
BAB 4 HASIL DAN PEMBAHASAN
Bab ini merupakan pengujian terhadap perangkat lunak yang sudah dibuat untuk mengetahui apakah perangkat lunak sudah berjalan dengan baik atau belum.
9
BAB 5 PENUTUP
Pada bab ini menyampaikan simpulan dari hasil penelitian yang telah dilakukan, serta saran-saran untuk pembuatan perangkat lunak yang lebih baik lagi
10 BAB II
Landasan Teori
2.1. Komunikasi Data
Komunikasi data merupakan kata serapan dari Bahasa Inggris, yaitu telecommunication dan data. Telecommunication yang termasuk di dalamnya telephony, telegraphy, dan television yang berarti komunikasi dengan suatu jarak tertentu (tele dalam bahasa yunani dengan arti jarak), sedangkan kata data mengacu pada informasi yang disajikan dalam bentuk apapun yang disepakati oleh pihak pembuat dan pihak pengguna (Forouzan, 2013).
2.1.1. Pengertian Komunikasi Data
Menurut Forouzan (2013), komunikasi data merupakan proses pertukaran informasi antar 2 (dua) perangkat melalui suatu media transmisi. Agar komunikasi data dapat terjadi, perangkat komunikasi harus menjadi bagian suatu sistem komunikasi yang terdiri dari kombinasi piranti baik perangkat keras maupun perangkat lunak. Efektifitas dalam komunikasi data tergantung pada 4 (empat) karakteristik dasar, yaitu:
1) Delivery
Sistem komunikasi data harus mengirimkan data ke tujuan yang benar. Data harus dapat (dan hanya dapat) diterima oleh alat atau pengguna yang dituju.
2) Accuracy
Sistem harus memberikan data yang akurat. Data yang dalam transmisinya diubah menjadi menjadi bentuk lain, harus dikembalikan hingga dapat dikenali supaya dapat digunakan.
11 3) Timeliness
Sistem harus mengirimkan data pada waktu yang tepat. Jika data yang disampaikan terlambat maka data tersebut menjadi tidak berguna.
4) Jitter
Jitter merupakan variasi dalam waktu kedatangan paket. Jitter terjadi saat pengiriman paket data mengalami penundaan dalam rentang waktu yang berbeda-beda. Sebagai contoh, asumsikan sekumpulan paket video dikirim setiap 30 mikrodetik. Jika beberapa paket diterima dalam 30 mikrodetik sedangkan beberapa paket lainnya diterima dalam 40 mikrodetik, maka kualitas video secara keseluruhan menjadi tidak merata.
2.1.2. Komponen Komunikasi Data
Menurut Forouzan (2013), ada 5 (lima) komponen yang dibutuhkan untuk melakukan komunikasi data, yakni pesan (message), pengirim (sender), penerima (receiver), media transmisi, dan protokol. Komponen-komponen tersebut akan berinteraksi dalam melakukan komunikasi data seperti gambar di bawah ini.
Gambar II.1 Komponen Komunikasi Data (Forouzan, 2013) 1) Pesan (Message)
Pesan adalah informasi (data) yang akan disampaikan. Contoh informasi yang populer pada saat ini antara lain berupa teks, gambar, audio, atau video.
2) Pengirim (Sender)
Pengirim adalah alat untuk mengirim data. Pengirim dapat berupa komputer, workstation, telepon, kamera video, dan lainnya.
3) Penerima (Receiver)
Penerima merupakan alat untuk menerima data pesan dari pengirim.
Perangkat penerima ini bisa berupa komputer, workstation, telepon, kamera video, dan lainnya.
12 4) Media Transmisi
Media transmisi merupakan jalur fisik yang digunakan dalam pengiriman pesan. Contoh dari media transmisi tersebut adalah beragam jenis kabel (kabel tembaga, kabel coaxial, fiber-optic) atau gelombang radio.
5) Protokol
Protokol adalah seperangkat aturan yang mengatur komunikasi data. Tiap protokol berisi kesepakatan yang dituruti oleh setiap perangkat komunikasi.
Tanpa protokol, dua perangkat dapat saling berhubungan tetapi tidak dapat melakukan komunikasi, seperti dua orang yang berdiskusi menggunakan bahasa yang berbeda.
2.1.3. Jenis Alur Komunikasi
Menurut Forouzan (2013), ada 3 (tiga) jenis alur dalam melakukan komunikasi. Jenis-jenis alur komunikasi tersebut, antara lain:
1) Simplex
Dalam mode alur komunikasi simplex, komunikasi yang terjadi hanya satu arah. Hanya satu dari dua perangkat yang menjadi pengirim pesan, sedangkan lawannya hanya berfungsi sebagai penerima. Mode simplex memungkinkan seluruh kapasitas saluran digunakan untuk mengirim data dalam satu arah.
Berikut ini adalah diagram alur komunikasi dengan mode simplex.
Gambar II.2 Alur komunikasi dengan mode simplex (Forouzan, 2013) 2) Half-Duplex
Dalam mode alur komunikasi half-duplex, komunikasi dapat terjadi dua arah.
Setiap perangkat dapat sekaligus menjadi penerima dan pengirim pesan, selama komunikasi tidak dilakukan secara bersamaan. Ketika suatu perangkat sedang melakukan pengiriman pesan perangkat lainnya hanya dapat berfungsi sebagai penerima, dan sebaliknya. Dalam mode alur komunikasi half-duplex, seluruh kapasitas saluran diambil alih oleh salah satu di antara dua perangkat yang sedang melakukan transmisi data. Berikut ini adalah diagram alur komunikasi dengan mode half-duplex.
13 Gambar II.3 Alur Komunikasi dengan mode Half-duplex (Forouzan, 2013)
3) Full-Duplex
Dalam mode alur komunikasi full-duplex atau sering juga disebut duplex, kedua perangkat dapat melakukan pengiriman dan penerimaan data secara bersamaan. Mode alur komunikasi full-duplex dapat dianalogikan seperti jalan dua arah dengan lalu lintas mengalir di kedua arah pada saat yang bersamaan. Berikut ini adalah diagram alur komunikasi dengan mode full-duplex.
Gambar II.4 Alur Komunikasi dengan mode Full-duplex (Forouzan, 2013)
2.2. Hyper Text Transfer Protocol (HTTP)
Menurut Tanenbaum (2011), HTTP adalah protokol yang digunakan oleh website dalam mengirim data dari server kepada client, atau sebaliknya, yang berjalan pada koneksi TCP yang spesifikasinya diatur dalam RFC 2616. Setiap melakukan request atau memberikan response, HTTP akan menyertakan headers yang berbentuk ASCII untuk memudahkan client atau server dalam memproses request atau response yang terjadi.
Menurut Tanenbaum (2011) ada beberapa unsur penting pada HTTP, antara lain:
1) Connections
14 Keuntungan menggunakan koneksi TCP pada protokol HTTP adalah browser dan server tidak perlu mempedulikan kecepatan, keandalan, dan keutuhan pesan karena TCP telah melakukan implementasi kontrol terhadap kecepatan, keandalan, dan keutuhan pesan yang dikirim maupun diterima.
2) Methods
Pada saat sebuah client melakukan HTTP request kepada web server, request tersebut dijadikan baris teks dalam format ASCII yang diawali suatu request method di bagian depannya.
3) Messages Headers
Messages header merupakan informasi tambahan yang dikirimkan pada saat client meminta suatu halaman web ke server, dan sebaliknya.
2.3. Remote Procedural Call (RPC)
Remote procedural call atau disingkat RPC berfungsi berdasarkan prinsip kerja protokol request-response yang lazimnya dilakukan tertutup oleh satu program di dalam satu komputer, namun dikembangkan sehingga dapat dilakukan oleh banyak program dan komputer yang terhubung ke suatu jaringan. Pada RPC, program yang melakukan request mengirimkan parameter melalui jaringan ke environment lain, yang kemudian mengembalikan hasil olahan ke environment si requester. Selama proses transfer berlangsung, tiap environment yang sedang mengirim parameter akan di-suspend, meski secara paralel tetap dapat mengeksekusi proses lain secara lokal (Birrel & Nelson, 1984).
Dalam ISO OSI (Open System Interconnection) Layer, implementasi RPC teletak pada lapiran ke-5 yaitu Session Layer, dimana pada lapisan ini didefinisikan bagaimana koneksi dapat dibuat, dipelihara, atau dihancurkan. Dan Selain itu, di level ini juga dilakukan resolusi nama.
Lebih jauh, menurut Birrell dan Nelson (1984), terdapat beberapa keuntungan pengaplikasian RPC, antara lain:
15 1) Memungkinkan penggunaan semantik yang lebih bersih dan sederhana,
sehingga mempermudah pendistribusian komputasi.
2) Meningkatkan efisiensi, karena prinsip prosedurnya yang sederhana memungkinkan komunikasi antar sistem terjadi lebih tangkas (rapid).
3) Memungkinkan generalisasi, karena penggunaan prosedur mendukung komunikasi dapat dilakukan antar algoritma yang mengatur beragam proses.
2.3.1. Contoh Syntax
Sesuai dengan RPC Language Specification yang dikutip dari docs.oracle.com berikut adalah spesifikasi untuk mendeklarasikan sebuah program dalam RPC
program-definition:
"program" program-ident "{"
version-list "}" "=" value;
version-list:
version ";"
version ";" version-list version:
"version" version-ident "{"
procedure-list "}" "=" value;
procedure-list:
procedure ";"
procedure ";" procedure-list procedure:
type-ident procedure-ident "(" type-ident ")" "=" value;
Adapun contoh deklarasi program sebenarnya adalah sebagai berikut:
/*
* time.x: Get or set the time. Time is represented as seconds * since 0:00, January 1, 1970.
*/
program TIMEPROG { version TIMEVERS {
unsigned int TIMEGET(void) = 1;
void TIMESET(unsigned) = 2;
} = 1;
} = 0x20000044;
16 2.4. Metode Eksperimental
Eksperimen atau percobaan, adalah pengamatan yang dilakukan di dalam lingkup suatu kondisi buatan (artificial condition) yang dibuat dan diatur oleh si pengamat. Dengan demikian, penelitian eksperimental adalah penelitian yang dilakukan dengan mengadakan manipulasi terhadap objek penelitian, serta adanya kontrol.
Tujuan dari penelitian eksperimental adalah menyelidiki ada atau tidaknya hubungan sebab akibat, serta besarnya hubungan sebab akibat tersebut, dengan cara memberikan perlakuan-perlakuan tertentu pada beberapa kelompok eksperimen dengan menyediakan kontrol untuk perbandingan (Nazir, 2005).
2.4.1. Langkah-langkah Metode Eksperimental
Ada 2 (dua) langkah dalam metode eksperimental, yaitu perencanaan eksperimen dan pelaksanaan eksperimen (Nazir, 2005).
1) Perencanaan Eksperimen
Sebuah eksperimen harus direncanakan sebaik-baiknya sehingga dalam pelaksanaannya sudah ada garis pembatas yang nyata tentang apa yang akan dikerjakan dan apa yang tidak dikerjakan. Menurut Nazir (2005), ada 2 (dua) hal yang harus dilakukan ketika melakukan perencanaan eksperimen:
i) Perumusan eksperimen
Ada 2 (dua) langkah penting yang harus dilakukan dalam perumusan eksperimen, yaitu:
a) Menetukan rumusan masalah serta pernyataan tentang eksperimen atau penelitian
17 b) Membentuk gambaran dari eksperimen yang akan dilakukan,
termasuk tentang skala eksperimen, jumlah dan jenis perlakuan, material yang akan digunakan, dan sebagainya.
ii) Perancangan eksperimen
Adalah langkah-langkah yang utuh dan berurutan yang dibuat terlebih dahulu sehingga keterangan yang diperoleh dari eksperimen akan mempunyai
hubungan yang nyata dengan masalah penelitian.
2) Pelaksanaan Eksperimen
Menurut Nazir (2005), Setelah perencanaan selesai dan desain yang cocok telah dipilih, selanjutnya adalah pelaksanaan eksperimen. Ada 3 (tiga) hal yang penting dalam pelaksanaan eksperimen, yaitu:
i) Pengenalan terhadap material yang digunakan dalam eksperimen.
ii) Pengamatan terhadap performance eksperimen harus dilakukan secara periodik sesuai dengan jadwal yang telah ditentukan.
iii) Setelah pengamatan selesai, maka dilakukan analisis, intepretasi serta generalisasi dari penemuan-penemuan. Dalam pembentukan analisis diperlukan pengelompokan data dalam tabel, pengolahan melalui komputasi maupun penggalian kausalitas menggunakan teknik-teknik statistik.
2.4.2. Jenis-jenis Metode Eksperimen
Menurut Nazir (2005), Ada 4 (empat) metode eksperimen, yaitu:
1) Eksperimen Absolut
Adalah percobaan untuk memperkirakan suatu set pengamatan dengan hasil pengamatan sebelumnya yang memiliki hasil terpercaya (highly reliable).
2) Eksperimen Perbandingan (Comparative Experiment)
Eksperimen yang dilakukan dengan melakukan perbandingan terhadap perlakuan-perlakuan serta pengaruh dari perlakuan-perlakuan tersebut terhadap satu permasalahan yang spesifik.
18 3) Eksperimen Sungguhan (True Experiment)
Eksperimen ini menyelidiki kemungkinan hubungan sebab-akibat melalui proyek sungguhan menggunakan dua kelompok obyek: kelompok perlakuan dan kelompok kontrol. Hasil dari tiap kelompok kemudian dibandingkan.
4) Eksperimen Semu
Penelitian yang dilakukan sedekat mungkin dengan eksperimen sungguhan.
Eksperimen ini dilakukan ketika kelompok kontrol tidak tersedia, kelompok kontrol tidak memungkinkan untuk diteliti, atau manipulasi atas variabel penelitian tidak dapat dilakukan.
2.5. Benchmarking
Dalam Bahasa Indonesia, benchmarking dapat diartikan sebagai patok duga. Ada berbagai definisi mengenai benchmarking, beberapa di antaranya:
1) Gregory H. Watson, mengartikan benchmarking sebagai: “... pencarian secara berkesinambungan dan penerapan secara nyata praktik-praktik yang lebih baik yang mengarah pada kinerja sebagai yang terbaik. “
2) IBM mengartikan benchmarking sebagai suatu proses terus-menerus untuk menganalisis tata cara terbaik di dunia dengan maksud menciptakan dan mencapai sasaran dan tujuan, dengan prestasi yang mendunia.
3) Benchmark adalah teknik pengujian atas suatu produk menggunakan tolok ukur yang berusaha dilampaui kinerjanya.
4) Dari ilmu komputer, benchmarking merupakan usaha melakukan pengujian sebuah komputer dengan cara menjalankan beberapa program, kumpulan program atau operasi lain yang bertujuan untuk mengetahui kinerja dari komputer tersebut. Benchmarking memungkinkan peneliti membandingkan
19 kinerja dari berbagai sub-sistem, meski setiap sub-sistem memiliki arsitektur berbeda.
2.6. Kinerja (Performance)
Kinerja (performance) mengacu pada pelayanan yang disediakan oleh orang atau mesin untuk siapapun yang memerlukannya. Suatu sistem pemroses informasi terbentuk dari sekumpulan komponen perangkat keras dan perangkat lunak yang memiliki kemampuan untuk mengolah data. Yang dapat didefinisikan sebagai kinerja dari sistem semacam ini, mencakup: bahasa pemrograman, kegunaannya (utility) dalam membantu perancangan dan pengembangan program, kegunaannya untuk pengolahan, fitur untuk memperbaiki kegagalan, dan sebagainya.
Kinerja (performance) terdiri dari indeks-indeks yang dapat mencerminkan beberapa aspek dasar seperti: kemudahan, kenyamanan, kestabilan, kecepatan, dan lainnya. Setiap indeks harus dapat dikuantifikasi supaya dapat dievaluasi. Agar indeks kinerja dapat dievaluasi, dia harus memiliki karakteristik- karakteristik sebagai berikut: dapat diukur, dapat dihitung, serta dapat diperkirakan.
2.7. Parameter yang akan diukur 2.7.1. Transaction Throughput
Menurut Ian Molyneaux dalam bukunya The Art of Application Performance Testing (2009), sebuah nilai yang berorientasi pada saat even terjadi dalam satu waktu, sebagai contoh berapa banyak jumlah request yang bisa ditangani oleh sebuah aplikasi dalam satu waktu.
20 2.7.2. Response Time
Masih menurut Ian Molyneaux dalam bukunya The Art of Application Performance Testing (2009), adalah jumlah waktu yang digunakan oleh sebuah sistem atau aplikasi untuk memberikan respon terhadap satu request pengguna, detailnya berapa lama waktu yang digunakan oleh system antara pengguna menginisiai request sampai pada respon nya di terima oleh pengguna itu sendiri.
2.7.3. RSS Memory
Menurut Florent Bruneau dalam tulisanya Understanding Process memory, RSS Memory Adalah jumlah memori fisik pada kernel yang dapat ditugaskan pada sebuah proses. Sebagai konsekuensi langsung. Singkatnya berapa banyak jumlah memory yang dikonsumsi pada sebuah process.
2.7.4. CPU Usage
Menurut Jeff Atwood dalam tulisan nya Understanding User and Kernel Mode (2008), CPU Usage umumnya direpresentasikan sebagai persentase sederhana berapa banyak waktu yang digunakan oleh CPU untuk melakukan tugas non-idle.
2.7.5. Data Throughput
Menurut Ian Molyneaux dalam bukunya The Art of Application Performance Testing (2009), adalah angka yang diperoleh dari aktifitas network, umumnya dalam performance testing memiliki target mencapai angka tertentu dalam satuan bytes per second, dengan memonitoring data throughput kita akan mengetahui apakah kita dapat mencapai angka yang sudah kita tentukan. Sering
21 kali penuruan dalam data throughput menjadi gejala awal dalam masalah kapasitas, dimana sistem tiddak sanggup menangani request yang sedang berlangsung.
2.8. JMeter
JMeter adalah aplikasi komputer yang dikembangkan oleh Stefano Mazzocchi untuk mengukur kinerja serta perilaku fungsional dari aplikasi lain.
Ketika mengembangkan JMeter, Mazzocchi bekerja di Apache Software Foundation, sehingga pada mulanya, JMeter hanya dapat digunakan untuk mengukur kinerja sistem Apache JServ. JMeter kemudian dikembangkan hingga dapat digunakan untuk mengukur beban server FTP, server database, serta Java Servlets berikut obyek-obyeknya (Halili, 2008).
Menurut Emily H. Halili dalam bukunya Apache JMeter (2008), karena cakupan JMeter yang luas, sifat distribusinya yang bebas (open-source), serta kapasitasnya untuk diekstensi sesuai kebutuhan melalui API-nya yang berbasis Java, JMeter tumbuh menjadi aplikasi tes yang paling banyak digunakan—saat buku tersebut ditulis.
Dalam pengoperasiannya, JMeter akan berperan sebagai klien dari aplikasi yang diuji. JMeter dapat digunakan untuk mengukur beban CPU, penggunaan memori, dan beban lainnya dalam konteks pengujian fungsional.
Implementasi JMeter akan lebih eektif ketika proses pengujian dilakukan dalam lingkup otomasi (automated-testing).
22 2.9. Ruby
Ruby adalah sebuah bahasa pemrograman full-stack berorientasi obyek (object-oriented scripting language) yang diciptakan oleh Yukihiro Matsumoto pada awal tahun 1990-an (Lenz, 2008). Sebagai bahasa berorientasi obyek, segala sesuatu yang dimanipulasi melalui Ruby adalah obyek, bahkan hingga mencakup definisi angka dan nilai true, false, dan nil (null dalam Ruby). Bahkan, setiap obyek dapat memanipulasi dirinya sendiri ketika ia dieksekusi (extendable) (Flannagan &
Matsumoto, 2008).
Dibanding bahasa pemrograman full-stack lain, Ruby memiliki beberapa keunggulan, antara lain: Adaptasinya yang mudah bagi kebanyakan developer yang sebelumnya menggunakan bahasa C maupun Java (Flannagan & Matsumoto, 2008), rentang produksinya yang pendek, kemampuan Ruby untuk beroperasi dalam hitungan baris yang lebih sedikit, kebutuhan perawatan jangka panjang yang minim, ditambah ketersediaan library pendukung untuk fungsi-fungsi tingkat lanjut sangat berlimpah (Tate, 2006).
2.10. Node.js
Node.js menurut Ryan Dahl, penciptanya, adalah alat yang ia bangun untuk “menciptakan cara mudah membangun program jaringan dengan tingkat skalabilitas tinggi (scalable).” Node.js, atau biasa disebut Node, adalah environment JavaScript yang dijalankan di server (server-side). Node merupakan pengembangan dari engine V8 yang dikembangkan oleh Google yang sebelumnya hanya dijalankan di browser (terutama Google Chrome), menjadi alat yang mampu mendukung proses panjang di server. (Tilkov & Vinoski, 2010).
23 Karena berbasis JavaScript, Node tidak mendukung multithreading, namun berfungsi sebagai I/O yang mengelola event asynchronous melalui callback.
Argumennya, menurut Tilkov dan Vinoski (2010), pemrosesan multithreading yang biasa dilakukan di tingkat server membutuhkan pengaturan yang rumit dan sering terjebak pada ketidakpastian karena pembagian kinerja didelegasikan ke OS.
Di sisi lain, pemrograman berbasis event memberikan kontrol lebih besar kepada developer untuk menentukan proses mana yang harus dijalankan terlebih dahulu.
Kemungkinan melakukan rentetan event secara asynchronous dengan Node, memperbesar efektivitas dan skalabilitas program di server.
2.11. Apache Thrift
Apache Thrift, atau Thrift, adalah framework yang memungkinkan remote procedural call (RPC) yang terjadi antar komponen piranti lunak untuk saling berkomunikasi meski masing-masingnya ditulis dalam bahasa yang berbeda. Thrift memiliki interface definition language (IDL) sekaligus generator kode yang mendukung sebagian besar bahasa pemrograman yang ada saat ini, seperti: C++, C#, Cocoa, D, Delphi, Erlang, Haskell, Java, OCaml, Perl, PHP, Python, Ruby, Smalltalk, dan sebagainya. Hal ini membuat cakupan kerja Thrift nyaris tidak terbatas (Kamburugamuve et al., 2013).
Kemampuan Thrift untuk mengabstraksi masing-masing bahasa pemrograman yang didukungnya untuk memanipulasi satu library yang sama, memungkinkan para developer untuk mendefinisikan tipe data dan interface keseluruhan service di dalam satu berkas yang netral (Slee et al., 2007). Dengan Thrift, tiap komponen dari aplikasi dapat dikembangkan secara mandiri
24 menggunakan bahasa pemrograman yang paling efektif untuk fungsinya sehingga keseluruhan environment dapat dikembangkan secara lebih efisien dan lebih mudah diskalakan.
2.12. Go
Go adalah bahasa pemrograman yang difokuskan untuk pengolahan sistem seperti server, database, library, browser, dan sejenisnya. Sifat Go yang telah terkompilasi dan memiliki sistem static-typing memperkecil kemungkinan terjadinya kesalahan dibanding bahasa pemrograman dynamic-typing. Selain itu, karena Go secara dinamis melakukan garbage collection, dealokasi memori menjadi lebih sederhana (Aigner & Baumgartner, 2010).
Beberapa keunggulan lain Go juga ditambahkan oleh Clark & McCabe (2004), antara lain: Go adalah bahasa yang menggunakan sistem strong-typing sehingga memperkecil kemungkinan terjadi kesalahan di environment produksi; Go juga multi-thread di tingkat internal maupun eksternal, e.g. memungkinkan beberapa program Go yang terpisah dan masing-masing memiliki beberapa thread untuk saling berkomunikasi secara transparan melalui network, atau beberapa thread di satu program Go untuk bersama-sama memanipulasi obyek dengan relasi dinamis.
2.13. Docker
Docker adalah aplikasi yang bekerja untuk mengotomasi proses deployment aplikasi ke kontainer virtual (Turnbull, 2014). Lebih lanjut, Turnbull (2014) berargumen bahwa Docker yang berfungsi sebagai layer kontrol tambahan
25 di atas kontainer virtual, akan mempermudah implementasi kontainer yang terkenal kompleks, sulit dikonfigurasi, dan membutuhkan usaha besar untuk manajemen dan otomasinya.
Dibandingkan dengan pendekatan virtualisasi lain yang lebih dahulu lazim digunakan seperti virtualisasi berbasis kontainer (container-based virtualization) atau hypervisor (hypervisor-based virtualization), Docker, menurut Thanh Bui (2015) memiliki beberapa keunggulan, antara lain: Pertama, Docker memiliki antarmuka (interface) yang mempermudah pembuatan dan pengaturan kontainer.
Kedua, developer dapat memasukkan banyak aplikasi ke dalam kontainer Docker yang dapat dioperasikan (hampir) di semua environment tanpa melakukan modifikasi. Ketiga, penggunaan Docker memungkinkan satu piranti keras diisi lebih banyak environment virtual. Dan terakhir, keempat, Docker dapat diintegrasikan dengan baik ke banyak alat-alat third-party sehingga menyederhanakan manajemen deployment. Perbedaan arsitektur Docker dengan arsitektur virtualisasi lain dapat dilihat pada grafik-grafik di bawah.
Gambar II.5 Arsitektur virtualisasi berbasis kontainer (Bui, 2015)
26 Gambar II.6 Arsitektur virtualisasi berbasis hypervisor (Bui, 2015)
Gambar II.7 Arsitektur Docker (Bui, 2015)
2.14. Datadog
Datadog adalah perangkat lunak yang berjalan pada sebuah host yang bertugas mengumpulkan data metrik dan event pada sebuah komputer dan mengirimkannya ke server datadog, sehingga memungkinkan penguna untuk melakukan pengukuran dan monitoring pada aplikasi (Datadog, Inc.).
Applikasi Datadog memiliki 3 parts fungsi yaitu:
5) Collector, bertugas sebagai melakukan pengecekan pada host secara berkala dan menyimpan metrics system seperti penggunaan CPU dan Memory
27 6) Dogstatsd, merupakan server statsd yang bertugas melakukan pengiriman
custom event yang telah di definisi oleh pengguna.
7) Forwarder, yang bertugas sebagai penerima data dari Collector dan Dogstatsd dan melakukan pengantrian untuk mengirimkan data ke datadog server.
28 BAB III
Metodologi Penelitian
Untuk memperoleh data dan informasi yang lengkap sebagai pendukung kebenaran materi uraian dan pembahasan skripsi ini, Penulis melakukan dua langkah penelitian. Langkah pertama adalah pengumpulan data, dilanjutkan dengan langkah kedua yaitu eksperimen. Berikut penjelasan lebih lanjut tentang langkah- langkah metode penelitian yang dilakukan oleh Penulis:
3.1. Metode Pengumpulan Data
Metode pengumpulan data merupakan tahapan proses penelitian dalam penelitian ini. Penulis membutuhkan data yang tepat agar penelitian berlangsung sesuai dengan perumusan masalah yang sudah ditentukan. Sebab itu sebelum memulai penulisan, Penulis melakukan riset atau penelitian terlebih dahulu untuk mendapatkan data serta informasi yang terkait. Data-data yang dibutuhkan oleh Penulis adalah sebagai berikut:
1) Data Primer
Data primer didapatkan melalui wawancara dan diskusi bersama pihak yang dapat memberikan informasi mengenai sistem yang akan dikembangkan oleh Penulis. Wawancara ini dilakukan langsung ke pihak PT. XYZ. Daftar pertanyaan yang diajukan dalam wawancara disajikan dalam Lampiran III.
2) Data Sekunder
Data sekunder adalah data pendukung yang berasal dari pihak yang tidak memiliki keterkaitan langsung dengan obyek yang dipelajari. Yang
dikategorikan sebagai data sekunder dalam penelitian ini dikumpulkan melalui kajian literatur dari berbagai jurnal, buku, dan artikel. Beberapa yang
dominan, antara lain:
29
No Judul Deskripsi
1 Implementing Remote Procedure Call
(Andrew D. Birrel dan Bruce Jay Nelson)
Xerox Palo Alto Research Center
Pemaparan Implementasi RPC pada Xerox Palo Alto Research Center untuk meningkatkan performa pada Server yang menangani banyak request. Jurnal ini merupakan yang pertama kali membahas RPC
2 Thrift: Scalable Cross- Language Services Implementation
(Mark Slee, Aditya Agarwal dan Marc Kwiatkowski)
Facebook, 156 University Ave, Palo Alto
Jurnal ini adalah official paper dari facebook pada saat itu ketika mempublikasikan Apache Thrift pertama kali. Didalamnya diuraikan detail dari tata cara penggunaan Apache Thrift dengan sangat medetail.
Performance Comparison of Data Serialization Schemes for ETSI ITS Car-to-X Communication Systems (Sebastian Bittl, Arturo A.
Gonzalez, Michael Spa ̈hn, and Wolf A. Heidrich)
Fraunhofer Institute for Embedded Systems and Communication Systems ESK, Munich, Germany
Membahas perbandingan performa skema serialization untuk sistem komunikasi pada Car-to-X ETSI ITS (Intelligent Transport Systems).
Membandingkan antara ASN.1, Google Protocol Buffers dan, Efficient XML Interchange format.
3.2. Metode Eksperimental
Metode eksperimental terdiri dari dua fase, yaitu: fase perencanaan eksperimen dan fase pelaksanaan eksperimen. Fase perencanaan eksperimen terdiri dari dua tahapan, yaitu: perancangan langkah-langkah eksperimen dan eksperimen itu sendiri. Sedangkan fase pelaksanaan eksperimen terdiri dari tiga bagian, yaitu:
pengenalan material yang digunakan, pengamatan performansi, dilanjutkan dengan analisis, interpretasi, dan generalisasi hasil eksperimen. Berikut penjabarannya.
30 3.2.1. Fase Perencanaan Eksperimen
Sub-bab ini akan menjabarkan dua fase yang ditempuh dalam melakukan perencanaan eksperimen, yaitu penentuan langkah-langkah eksperimen dan penentuan tahapan pelaksanaan eksperimen.
3.2.1.1. Langkah-langkah Eksperimen
Ada dua langkah yang diperlukan dalam melakukan perencanaan eksperimen, yaitu:
1) Perumusan masalah dan tujuan penelitian
Pada tahapan ini dilakukan perumusan masalah dan tujuan penelitian.
i) Perumusan Masalah
Pada tahap perumusan masalah, Penulis menentukan rumusan masalah yang akan dihadapi ketika berusaha melakukan perbandingan performansi antara implementasi Apache Thrift dan HTTP REST dalam arsitektur microservice di PT. XYZ.
ii) Tujuan Penelitian
Pada tahap ini, Penulis bermaksud untuk menemukan implementasi yang paling baik dalam komunikasi data di perusahaan. Hal ini dilakukan melalui usaha melakukan perbandingan performansi antara implementasi HTTP REST API (yang saat ini dilakukan di PT. XYZ) dengan Apache Thrift sebagai implementasi bandingannya.
2) Gambaran Eksperimen
Pada tahap ini dibuat penggambaran dari eksperimen yang dilakukan.
Gambaran dari penelitian ini mendefinisikan populasi dan perlakuan-
31 perlakuan yang diberikan untuk dapat menjelaskan peranan tiap perlakuan dalam mencapai tujuan penelitian ini.
i) Populasi
Menjelaskan beberapa populasi yang digunakan di penelitian ini.
ii) Perlakuan.
Pada tahap ini menjelaskan perlakuan apa saja yang diberikan pada penelitian ini.
3.2.1.2. Desain Eksperimen
Desain eksperimen pada penelitian adalah merencanakan eksperimen atau percobaan dalam penelitian ini, sehingga hasil yang diperoleh dari eksperimen penelitian ini dapat memecahkan rumusan masalah yang telah ditentukan.
3.2.2. Fase Pelaksanaan Eksperimen
Setelah fase perencanaan eksperimen ditentukan, penelitian berlanjut ke fase pelaksanaan eksperimen. Ada tiga langkah yang ditempuh di fase ini, yaitu:
fase pengenalan material yang digunakan, fase pengamatan performansi eksperimen, dan fase analisis, interpretasi dan generalisasi hasil eksperimen.
3.2.2.1. Pengenalan Material
Pada tahap ini dijelaskan material atau perangkat keras dan perangkat lunak apa saja yang digunakan dalam eksperimen ini.
32 3.2.2.2. Pengamatan Performa Eksperimen
Menuruti acuan yang diajukan oleh Roscoe (1975) dalam Uma Sekaran (1992), didefinisikan penentuan ukuran sampel untuk penelitian eksperimen yang sederhana antara 10 hingga 20 sampel. Pada tahap pengamatan ini dilakukan pengamatan perfomansi pada penelitian menggunakan alat-alat benchmarking untuk mendapatkan metrik perbandingan yang terkuantifikasi.
3.2.2.3. Analisis, Interpretasi dan Generalisasi Hasil Eksperimen
Merupakan tahap ketika hasil dari benchmarking yang didapat dari eksperimen dianalisis, sehingga dapat dilakukan interpretasi, untuk selanjutnya ditarik generalisasi dari temuan yang dianggap sebagai kebenaran yang dapat berlaku umum dari populasi eksperimen.
3.3. Kerangka Penelitian
Langkah-langkah dalam penelitian ini dapat dilihat dari penjelasan sebagai berikut:
1) Pengumpulan Data
Pengumpulan data dilakukan dengan cara sebagai berikut:
i) Melakukan studi pustaka melalui teori-teori dari bidang ilmu yang berkepentingan, melakukan studi literatur melalui penelitian-penelitian yang sama dan telah dilakukan sebelumnya.
ii) Melakukan wawancara dengan pihak PT. XYZ, wawancara ini bertujuan untuk menentukan parameter apa saja yang akan diukur dalam penelitian ini.
2) Perencanaan Eksperimen
33 Perencanaan eksperimen dilakukan dengan cara sebagai berikut:
i) Perumusan langkah-langkah eksperimen, yaitu usaha merumuskan masalah dan tujuan penelitian. Menggambarkan penelitian dengan menguraikan populasi, perlakuan-perlakuan yang diterapkan dan mengenalkan perangkat lunak yang digunakan dalam penelitian ini, serta Membuat outline dari penganalisisan hasil eksperimen.
ii) Perancangan eksperimen, yaitu usaha menjabarkan rancangan dari eksperimen di mana Penulis melakukan pengujian terhadap performansi dengan melakukan flood request ke sampel populasi.
3) Pelaksanaan Eksperimen
Pelaksanaan eksperimen dilakukan dengan cara sebagai berikut:
i) Pengenalan material yang digunakan.
ii) Pengamatan performa eksperimen. Hasil dari setiap pengujian yang dilakukan pada saat mengamati dan menganalisa performa dari software virtual machine dan didokumentasikan.
iii) Analisis, interpretasi dan generalisasi. Melakukan analisa hasil dari eksperimen tersebut supaya hasilnya dapat diinterpretasi dan digeneralisasi.
Gambar III.1 Kerangka Penelitian
34 BAB IV
Pembahasan
Pada bab ini akan dijelasan proses implementasi Apache Thrift dengan membuat prototipe sistem sederhana yang berperan sebagai system pada PT. XYZ dan juga akan diuraikan hasil pengukuran performa antara implementasi Apache Thrift dan HTTP REST API pada prototipe sistem tersebut.
4.1. Fase Perencanaan Eksperimen
Dalam fase perencanaan ini, ada dua hal utama yang harus menjadi perhatian yaitu langkah-langkah dan desain eksperimen.
4.1.1. Langkah-langkah Eksperimen
Ada tiga langkah yang dibutuhkan dalam melakukan perencanaan eksperimen yaitu perumusan masalah, tujuan penelitian dan gambaran dari eksperimen.
1) Perumusan Masalah dan Tujuan Penelitian i) Perumusan Masalah
Masalah sesuai yang telah di uraikan pada BAB I adalah bagaimana
mengukur performa implementasi antara Apache Thrift dan HTTP REST API dalam arsitektur microservice pada PT. XYZ.
ii) Tujuan Penelitian
35 Adapun tujuan dari penelitian ini adalah sebagai acuan informasi performa pada implementasi antara Apache Thrift dan HTTP REST API dengan
parameter – parameter yang diujikan mengunakan Performance benchmarking tool.
2) Gambaran Eksperimen i) Populasi
Populasi yang digunakan pada eksperimen ini sebanyak 1 populasi yang terdiri 2 system dengan asitektur microservice yang masing-masing
mengimplementasikan Apache Thrift dan HTTP REST API sebagai media komunikasi pada setiap service didalamnya, 1 Perfomance Benchmarking tool yaitu Apache JMeter dan 1 Cloud Monitoring tool menggunakan service dari datadog untuk memonitor kinerja computer pada masing-masing service.
Pemilihan Apache JMeter dan Datadog ini diperoleh dari hasil wawancara dengan pihak PT. XYZ
Pemilihan Perfomance benchmarking tool pada penelitian ini yaitu
kemudahan dalam pengoperasian dan pengelolaan hasil laporan serta, yang sudah familiar digunakan oleh pihak PT. XYZ, maka jatuhlah pilihan tersebut kepada Apache JMeter.
ii) Perlakuan
Perlakuan yang diterapkan pada penelitian ini adalah dengan meguji 2 sistem arsitektur micorservice yang masing-masing mengimplementasikan Apache Thrift dan HTTP REST API sebagai media komunikasi pada setiap service
36 didalamnya dengan parameter yang telah di tentukan, parameter yang
digunakan terbagi menjadi 2 kategori yaitu Performa Sistem dan Kinerja Komputer. Untuk Performa Sistem penulis memilih parameter Transaction Throughput dan Response Time sedangkan untuk Kinerja Komputer parameter yang dipilih adalah Resident Set Size (RSS) Memory, CPU Usage dan Data Throughput.
Seluruh kategori parameter akan diuji dengan melakukan sample request kepada system yang terinstall di cloud server pada DigitalOcean mengunakan JMeter melalui personal komputer, dan untuk hasil pelaporanya untuk
kategori performa system akan didapat langung dari Apache JMeter sedangkan hasil pelaporan untuk kategori Kinerja Komputer penulis
menggunakan hasil monitoring pada datadog pada saat pengujian dilakukan.
4.1.2. Desain Eksperimen
Pada tahap ini penulis mementukan gambaran atau desain eksperimen yang akan dilaksanakan. Desain eksperimen yang dimaksud adalah langkah – langkah yang utuh dan sistematis, sehinggan data yang ingin didapatkan dari eksperimen ini akan memiliki korelasi yang factual dengan rumusan masalah penelitian.
4.2. Fase Pelaksanaan Eksperimen
Setelah fase perencanaan eksperimen selesai, selanjutnya fase pelaksanaan eksperimen. disini akan diuraikan tiga langkah dalam fase pelaksanaan ini yaitu
37 fase pengenalan material yang digunakan, fase pengamatan performa eksperimen dan fase analisis, interpretasi dan generalisasi hasil eksperimen.
4.2.1. Pengenalan Material yang Digunakan
Tahap ini menjelaskan material atau perangkat keras dan perangkat lunak apa saja yang digunakan dalam eksperimen ini.
1) Perangkat Keras (Hardware)
Pada penelitian ini, penulis sejatinya tidak menggunakan perangkat fisik untuk server, namun menggunakan cloud server service dari DigitalOcean. Adapun spesifikasi dari virtual host untuk dijadikan sebagai server pada tiap system yang dibangun bisa diliat dari tabel dibawah:
Table IV.1 Hardware yang digunakan
Perangkat Satuan Parameter Keterangan
Cloud Server instance 2 RAM 8 GB
CPU 4 Core
Personal Computer 1 RAM 8 GB
CPU 4 Core
Processor 2.6 GHz Intel Core i5 2) Perangkat Lunak (Software)
Perangkat lunak yang digunakan dalam penelitian ini dapat dilihat pada tabel dibawah ini.
Table IV.2 Software yang digunakan
Perangkat Lunak Keterangan
Docker – Version 1.12.1 Infrastructure Manager
Ubuntu 16.04 Sistem Operasi
Apache JMeter – Version 3.0 Performance Benchmarking tool
Datadog Server monitoring tool
Prototipe sistem HTTP REST API Sistem PT. XYZ Prototipe system Apache Thrift Sistem PT. XYZ
38 4.2.1.1. Pengenalan Prototipe Sistem PT. XYZ
Pada penelitian ini penulis membuat prototipe sistem yang berperan sebagai sistem sebenernya pada PT. XYZ yang akan dijadikan objek dalam pengujian dengan parameter-parameter yang sudah di tentukan.
Prototipe sistem yang penulis buat hanya mengunakan 3 sample service yang ada dalam sistem PT. XYZ, adapun ketiga service tersebut adalah sebagai berikut:
1) Payment API
Service ini adalah pintu terdepan dari system PT. XYZ yang berkomunikasi dengan system pihak ketiga, dalam hal ini pihak ketiga yang dimaksud adalah system merchant dari PT. XYZ. Service ini berperan untuk menerima request berupa HTTP REST API request dalam format JSON, dan juga meneruskan informasi dalam transaction charge kepada system Bank mengunakan secure protocol.
Ketika menerima request dari system merchant untuk melakukan transaction charge, service ini akan berkomunikasi dengan 2 service yang ada dalam arsitektur microservice PT. XYZ, yaitu Merchant Portal Service dan
Notification Service. Pada prototipe service digunakan bahasa pemrograman Javascript (nodejs)
2) Merchant Portal Service
Service ini merupakan sumber penyimpanan informasi terkait data-data terkait dengan merchant dalam proses transaction charge seperti Bank MID
(Merchant ID ) dan Notification URL. Prototipe service ini menggunakan bahasa pemrograman Ruby.
3) Notification Service
Service ini berperan untuk melakukan pengiriman notifikasi kepada system merchant secara asynchronous memlalui job queue system. Pengiriman notifikasi ini berupa HTTP POST request kepada system merchant dengan URL yang sudah disimpan pada Merchant Portal Service. Penulis memilih basaha pemrograman Go pada prototipe service ini.
39 Gambar IV.1 Arsitektur prototipe PT. XYZ dengan HTTP REST API
Pada gambar 4.1 memperlihatkan prototipe sistem PT. XYZ dimana komunikasi antar service (kotak biru) menggunakan HTTP REST API. Arsitektur inilah yang menjadi implementasi saat ini pada PT. XYZ
40 Gambar IV.2 Arsitektur prototipe PT. XYZ dengan Apache Thrift
Dari Gambar 4.2, menggambarkan prototipe sistem dengan menggunakan implementasi Apache Thirft (panah hijau) sebagai media komunikasi antar service (kotak biru). Jika dibandingkan dengan Gambar 4.1 bisa dilihat perbedaannya hanya terletak pada komunikasi antar masing-masing service, pada perbedaan implementasi itulah yang akan dijadikan objek pengujian dalam penelitian ini.
4.2.2. Pengamatan Performa Eksperimen
Pengamatan performa dilakukan pada kedua prototipe sistem PT. XYZ yaitu dengan melakukan sample request kepada masing-masing system. Setiap request dilakukan secara bersamaan kepada kedua prototipe menggunakan Apache JMeter.
Untuk menguji performa pada masing-masing prototipe sistem, penulis melakukan pengujian dengan sample request secara concurrent kepada masing-
41 masing prototipe sistem. Untuk parameter yang masuk dalam kategori Performa Sistem dilakukan pengujian sebanyak 10 Kali, dimana pada setiap sesi pengujian jumlah concurrency ditambah sebanyak 20 concurrent dan sesi pertama dimulai dengan 20 concurrent, dengan pengujian ini akan diperoleh data untuk mengukur parameter Transaction Throughtput dan Response Time. Sedangkan untuk parameter yang termasuk dalam kategori Kinerja Komputer dilakukan pengujian sebanyak 1 kali dengan 50 concurrent dalam kurun waktu 1 jam, dengan pengujian ini akan didapati data untuk mengukur parameter RSS Memory, CPU Usage dan Data Throughput pada masing – masing prototipe sistem.
4.2.3. Analisa, Intepretasi dan Generalisasi Hasil Eksperimen
Setelah melakukan pengujian pada seluruh parameter yaitu Transaction Throughput, Response Time, RSS Memory, CPU Usage dan Data Throughput maka akan dilakukan intepretasi pada data yang didapatkan dari hasil pengujian tersebebut.
Pengujian Pertama dilakukan untuk mengukur parameter yang termasuk dalam kategori performa system yaitu Transaction Throughput dan Response Time.
Adapun hasilnya dapat dilihat pada tabel dan grafik dibawah ini.
Table IV.3 rata-rata nilai Transaction Throughput per 1 detik
CONCURENCY HTTP THRIFT
20 159.9 315.4
40 130 751.3
60 161 706.9
80 133.4 866.7
42
100 178.9 813.8
120 169.8 765.5
140 164.8 990.2
160 157 896.3
180 134.1 1090.4
200 119.8 1293.3
Average 150.87 848.98
Dari tabel 4.3, dapat dilihat nilai rata-rata Transaction Throughput hasil pengujian dalam satuan per 1 detik pada masing-masing prototipe sistem. Untuk prototipe sistem dengan HTTP REST API memiliki nilai 150.87 TPS dan untuk prototipe sistem dengan Apache Thrift memiliki nilai 848.98 TPS.
Gambar IV.3 Nilai Transaction Throughput per 1 detik
Gambar 4.3 memperlihatkan nilai Transaction Throughput pada kedua protipe system. Nilai Transaction Throughput dikatakan bagus jika nilainya lebih tinggi. Dari grafik pada gambar 4.3, kita dapat melihat bahwa prototipe system dengan Apache Thrift memiliki nilai yang lebih tinggi di banding dengan prototipe system dengan HTTP REST API.
43 Dari tabel 4.3 dan gambar 4.3, dapat disimpulkan bahwa pada parameter Transaction Throughput dalam satuan TPS (Transaction per Second), prototipe system dengan Apache Thrift memiliki nilai TPS yang significant lebih tinggi dibandingkan dengan prototipe system dengan HTTP REST API.
Table IV.4 nilai rata-rata response time dalam satuan milisecond
CONCURENCY HTTP THRIFT
20 49.6 27.2
40 163.8 37.1
60 66.3 231.3
80 296.1 75.4
100 328.8 113.1
120 505.7 200.2
140 542.4 158.9
160 656.1 251.7
180 756.5 195.3
200 780.9 117.9
Average 414.62 140.81
Dari tabel 4.4, dapat dilihat nilai rata-rata Response Time hasil pengujian dalam satuan millisecond pada masing-masing prototipe sistem. Untuk prototipe system dengan HTTP REST API memiliki nilai 414.62 ms dan untuk prototipe sistem dengan Apache Thrift memiliki nilai 414.62 ms
44 Gambar IV.4 Nilai Response Time dalam satuan millisecond
Gambar 4.4 memperlihatkan nilai Response Time pada kedua protipe system. Nilai Response Time dikatakan bagus jika nilainya lebih rendah. Dari grafik pada gambar 4.4, kita dapat melihat bahwa prototipe system dengan Apache Thrift memiliki nilai yang lebih rendah di banding dengan prototipe system dengan HTTP REST API.
Dari tabel 4.4 dan gambar 4.4, dapat disimpulkan bahwa pada parameter Response Time dalam satuan millisecond, prototipe system dengan Apache Thrift memiliki nilai yang significant lebih cepat dan stabil walaupun dengan penambahan jumlah concurrent dibandingkan dengan prototipe system dengan HTTP REST API.
Untuk pengujian kedua dilakukan untuk mengukur parameter yang termasuk dalam kategori kinerja computer yaitu RSS Memory, CPU Usage dan Data Throughput. Adapun hasilnya dapat dilihat pada dan grafik dibawah ini.
45 Gambar IV.5 Grafik RSS Memory
Pada gambar 4.5 memperlihatkan RSS Memory pada kedua protipe system, nilai RSS Memory dikatakan lebih bagus jika nilainya lebih rendah. Dari grafik pada gambar 4.5, kita dapat melihat bahwa prototipe system dengan Apache Thrift (warna ungu) memiliki nilai yang lebih rendah di banding dengan prototipe system dengan HTTP (warna biru).
Gambar IV.6 Most Intensive RSS Memory
Dari gambar 4.6, dapat dilihat nilai rata-rata RSS Memory hasil pengujian dalam satuan MiB (megabytes) pada masing-masing prototipe sistem. Untuk prototipe system dengan HTTP REST API memiliki nilai 128 MiB dan untuk prototipe sistem dengan Apache Thrift memiliki nilai 108 MiB
46 Dari gambar 4.5 dan 4.6, dapat disimpulkan bahwa pada parameter RSS Memory dalam satuan megabytes, prototipe system dengan Apache Thrift memiliki nilai yang lebih kecil dibandingkan dengan prototipe system dengan HTTP REST API.
Gambar IV.7 Grafik CPU Usage
Pada gambar 4.7 memperlihatkan CPU Usage pada kedua protipe system, nilai CPU Usage dikatakan lebih bagus jika nilainya lebih rendah. Dari grafik pada gambar 4.7, kita dapat melihat bahwa prototipe system dengan Apache Thrift (warna ungu) memiliki nilai persentase yang lebih rendah di banding dengan prototipe system dengan HTTP (warna biru).
