RANCANG BANGUN LAYANAN PLATFORM AS A SERVICE...

TUGAS AKHIR - KI141502

RANCANG BANGUN LAYANAN PLATFORM AS A SERVICE(PAAS) UNTUK MENDUKUNG SISTEM MULTI-TENANCY PE-NGEMBANGAN APLIKASI BERBASIS KOMPUTASI AWAN

PUTU WIRAMASWARA WIDYANRP 5111 100 012

Dosen Pembimbing 1Royyana Muslim Ijtihadie, S.Kom, M.Kom, Ph.D.

Dosen Pembimbing 2Baskoro Adi Pratomo, S.Kom, M.Kom

JURUSAN TEKNIK INFORMATIKAFakultas Teknologi InformasiInstitut Teknologi Sepuluh NopemberSurabaya, 2015

UNDERGRADUATE THESES - KI141502

DESIGN AND IMPLEMENTATION OF PLATFORM AS A SERVI-CE TO SERVE A MULTI-TENANCY APPLICATION PLATFORMBASED ON CLOUD COMPUTING

PUTU WIRAMASWARA WIDYANRP 5111 100 012

Supervisor 1Royyana Muslim Ijtihadie, S.Kom, M.Kom, Ph.D.

Supervisor 2Baskoro Adi Pratomo, S.Kom, M.Kom

INFORMATICS DEPARTMENTFaculty of Information TechnologyInstitut Teknologi Sepuluh NopemberSurabaya, 2015

RANCANG BANGUN LAYANAN PLATFORM AS A SERVICE (PAAS) UNTUK MENDUKUNG SISTEM MULTI-TENANCY PENGEMBANGAN APLIKASI

BERBASIS KOMPUTASI AW AN

TUGASAKHIR Diajukan Guna Memenuhi Salah Satu Syarat

Memperoleh Gelar Sarjana Komputer pad a

Bidang Studi Arsitektur dan Jaringan Komputer Program Studi S-1 Jurusan Teknik Informatika

Fakultas Teknologi Informasi Institut Teknologi Sepuluh Nopember

Oleh: Putu Wiramaswara Widya

NRP: 5111 100 012

Disetujui o1eh Dosen Pembimbing Tugas Akhlr :

Baskoro Adi Pratomo, S.Kom, M . . rrP: 198702182014041001

SURABAYA JANUARI 2015

vii

ix

RANCANGBANGUNLAYANAN PLATFORMASA SERVI-CE (PAAS)UNTUKMENDUKUNGSISTEMMULTI-TENANCYPENGEMBANGANAPLIKASIBERBASISKOMPUTASIAW-AN

Nama : PUTU WIRAMASWARA WIDYANRP : 5111 100 012Jurusan : Teknik Informatika FTIf-ITSPembimbing I : Royyana Muslim Ijtihadie, S.Kom, M.Kom, Ph.D.Pembimbing II : Baskoro Adi Pratomo, S.Kom, M.Kom

Abstract Layanan hosting aplikasi atau sering disebut Applica-tion Hosting / Web Hosting merupakan layanan yang jamak ter-sedia di Indonesia. Layanan ini memberikan wadah bagi siapapununtuk menempatakan aplikasi Web mereka beserta basis datanyadi jaringan Internet tanpa perlu menyediakan sendiri infrastrukturInternet terdedikasi. Layanan ini memiliki berbagai macam bentuk.Salah satu yang paling banyak tersedia di Indonesia adalah SharedWeb Hosting yang menyediakan layanan yang sangat murah. Pa-da jenis layanan ini, penyewa hanya diberikan satu buah platformyang sama dengan aplikasi yang disimpan bersamaan pada satubuah server sehingga memungkinkan adanya bottleneck. Selain itu,terdapat jenis layanan lain yaitu Virtual Private Server (VPS) yangmenyediakan kendali penuh pada sistem melalui teknik yang dise-but virtualisasi namun dengan konfigurasi yang sangat kompleks.

Saat ini terdapat jenis layanan hosting baru yang disebut de-ngan Cloud Web Hosting. Layanan ini mengadopsi prinsip kompu-tasi awan yaitu berupa Platform-as-a-Service (PaaS) yang menye-diakan jasa platform bagi pengembang Web untuk menempatkanaplikasi mereka di Internet. Layanan ini menawarkan fitur untuktransparansi akses, multi-platform, skalabilitas, reliabilitas, keter-bukaan API dan kemudahan pengguna. Namun, layanan ini saatmasih sangat jarang terutama di Indonesia yang masih menggu-nakan platform yang sama dengan Shared Web Hosting.

x

Pada tugas akhir ini, dilakukan perancangan dan implementa-si sistem hosting atau pengembangan aplikasi yang mendukung ba-nyak tenant/penyewa (Multi-Tenancy), mendukung banyak platformdan mendukung tiga prinsip komputasi awan yaitu self-service, re-source pooling dan metered service. Sistem ini mengadopsi bebe-rapa fitur yang ada di Cloud Web Hosting modern sehingga bisadibangun oleh pihak ketiga dengan mudah.

KataKunci:HostingAplikasi, Platform-as-a-Service,Multi-Tenancy, Komputasi Awan

xi

DESIGN AND IMPLEMENTATION OF PLATFORM AS ASERVICE TO SERVE AMULTI-TENANCY APPLICATIONPLATFORM BASED ON CLOUD COMPUTING

Name : PUTU WIRAMASWARA WIDYANRP : 5111 100 012Major : Informatics Department Faculty of IT - ITSSupervisor I : Royyana Muslim Ijtihadie, S.Kom, M.Kom, Ph.D.Supervisor II : Baskoro Adi Pratomo, S.Kom, M.Kom

AbstractApplication hosting services or usually known as web hosting is

one of the most commonly available Internet services in Indonesia.This services provide anyone an ability to host their own applicationand its database. There are many forms of application hosting se-rvice. The one that abudantly available in Indonesia is shared webhosting that provide a single homogenous platform to serve a nume-rous number of web application or database inside a single machi-ne. The bottom line is that this services have a potential bottleneckissue due to its shared nature. In addition, there is another formof web hosting which provides its tenant an ability to take controlover its operating system yet it has a complex configuration whichknown as Virtual Private Server.

The third form of web hosting, which gaining its momentum re-cently, is cloud-based web hosting. It adopts many characteristicsand principles from cloud computing technology, that mainly ba-sed on Platform-as-a-Service service model. Furthermore, it pro-vides some interesting features such as access transparancy, multi-platform, scalability, reliability, open API access and usability interms of its interface. However, the service providers of this modelis scarce. Even in Indonesia itself, there are few hosting serviceswhich labeled as "cloud hosting service" despite still continuing touse shared web hosting-based platform.

This final project/theses assignment aims to build a small appli-

xii

cation development and hosting Platform-as-a-service with multi-platform ability and some other features to fullfil three characteris-tics of cloud computing: self-service, resource pooling and meteredservice. The objective is to create an easy to build and cheap appli-cation hosting service with its feature based from the limitation oftraditional cPanel based service and common feature available inthe modern cloud hosting.

Keywords:ApplicationHosting, Platform-as-a-Service,Multi-Tenancy, Cloud Computing

KATA PENGANTAR

Om SwastyastuPuji syukur penulis haturkan kepada Ida Sang Hyang Widhi

Wasa, Tuhan Yang Maha Esa karena atas asungkertha wara nugra-ha beliau, penulis dapat menyelesaikan sebuah penugasan TugasAkhir untuk gelar Sarjana Komputer penulis dengan judul "Ran-cangBangunLayananPlatformas a Service (PAAS) untukMen-dukung Sistem Multi-Tenancy Pengembangan Aplikasi Berba-sis Komputasi Awan".

Tugas Akhir ini dibuat berdasarkan pengalaman penulis dalammelakukan pengembangan aplikasi Web selama masa kuliah meng-gunakan Node.js. Sampai saat ini, masih belum ada layanan WebHostingmurah yangmenawarkan segala fleksibilitas komputasi aw-an seperti layaknya layanan Heroku atau OpenShift. Diharapkan de-ngan terselesaikannya Tugas Akhir ini, akan ada peluang yang ter-buka bagi pengusaha di Indonesia untuk mengembangkan layananjenis ini sehingga pengembangan aplikasi Web bisa lebih heterogendengan berbagai adanya dukungan banyak platform.

Tidak lupa penulis sampaikan terima kasih dengan segala rasapenghormataan seluas-luasnya kepada beberapa pihak yang telahmembantu dalammenyelesaikan TugasAkhir ini selama sekitar tigabulan :

• Kedua orang tua penulis, saudara dan kerabat dekat yang se-lalu khawatir dengan keadaan penulis dan selalu mendoakankelancaran pengerjaan Tugas Akhir ini.

• Bapak Royyana Muslim Ijtihadie, S.Kom, M.Kom, Ph.D. se-laku pembimbing I yang selalu menuntun dan membimbingpenulis dalam pelaksanaan konsep pengerjaan Tugas Akhirini.

• Bapak Baskoro Adi Pratomo, S.Kom, M.Kom selalu pem-bimbing II yang berkenan memberikan evaluasi terhadap per-kembangan pengerjaan Tugas Akhir ini.

• Ibu Dr. Eng. Nanik Suciati, S.Kom, M.Kom selaku Ketua Ju-

xiii

xiv

rusan Teknik Informatika ITS yang telahmemberi teladan ba-ik kepada mahasiswa-mahasiswi beliau se-Jurusan.

• Ibu Isye Arieshanti, S.Kom, M.Phil, selaku Ketua ProgramStudi S1 Teknik Informatika yang telah meluangkan segenapwaktunya untuk mengatur berjalannya perkuliahan di jurusanTeknik Informatika ITS.

• Bapak Radityo Anggoro, S.Kom, M.Sc selaku koordinatorTugas Akhir yang telah meluangkan waktunya untuk kelan-caran pelaksanaan Tugas Akhir di jurusan.

• Ibu Prof. Handayani Tjandrasa selaku dosen wali dan pembi-bing akademik penulis selama menempuh masa perkuliahan.

• Teman-teman Administrator di Laboratorium Arsitektur danJaringan Komputer (AJK) yang telah memberi suasana yanghangat dan akrab selama pengerjaan TAyaitu Samihd, Uyung,Vivi, Harum, Surya, Agus, Adi Pur, Evaria, Romen, Nisa, Sa-iful, Wicak dan Zaza.

• Seluruh staf pengajar dan administrasi jurusan Teknik Infor-matika ITS yang telah memberikan segala tenaganya untukmemajukan perkembangan Jurusan.

• Teman-teman satu jurusan Teknik Informatika ITS angkatan2010, 2011, 2012 dan 2013 yang tidak bisa penulis sebutkansatu persatu namanya.

• Teman-teman perkumpulan Kelompok Linux arek Suroboyo(KLAS) yang selalu mengadakan cangkruan di setiap bulan-nya.

• Teman-teman komunitas BlankOn Linux di Internet yang su-dah memberi banyak ilmu baru mengenai pengembangan Li-nux dan teknologi jaringan.

• Serta berbagai pihak yang tidak bisa penulis sebutkan satu persatu namanya.

Penulis menyadari bahwasanya Tugas Akhir ini masih jauh da-ri sempurna. Penulis mengharapkan saran dan kritik yang memba-ngun untuk lebih menyempurnakan penelitian ini kedepannya.

xv

Terima Kasih.Om Santhi Santhi Santhi Om

Surabaya, 22 Desember 2014Putu Wiramaswara Widya

DAFTAR ISI

SAMPUL i

LEMBAR PENGESAHAN vii

ABSTRAK ix

ABSTRACT xi

KATA PENGANTAR xiii

DAFTAR ISI xvii

DAFTAR TABEL xxi

DAFTAR GAMBAR xxiii

1 PENDAHULUAN 11.1 Latar Belakang . . . . . . . . . . . . . . . . . . . 11.2 Rumusan Masalah . . . . . . . . . . . . . . . . . . 31.3 Batasan Masalah . . . . . . . . . . . . . . . . . . 31.4 Tujuan . . . . . . . . . . . . . . . . . . . . . . . . 31.5 Manfaat . . . . . . . . . . . . . . . . . . . . . . . 31.6 Metodologi . . . . . . . . . . . . . . . . . . . . . 41.7 Sistematika Laporan . . . . . . . . . . . . . . . . 4

2 LANDASAN TEORI 72.1 Web Hosting . . . . . . . . . . . . . . . . . . . . 72.2 Komputasi Awan . . . . . . . . . . . . . . . . . . 8

2.2.1 Karakteristik . . . . . . . . . . . . . . . . 92.2.2 Model Layanan . . . . . . . . . . . . . . . 9

2.3 Node.js . . . . . . . . . . . . . . . . . . . . . . . 102.4 MEAN Framework . . . . . . . . . . . . . . . . . 122.5 Docker . . . . . . . . . . . . . . . . . . . . . . . . 13

xvii

xviii

2.6 HAProxy . . . . . . . . . . . . . . . . . . . . . . 15

3 DESAIN DAN PERANCANGAN 173.1 Kasus Penggunaan . . . . . . . . . . . . . . . . . 173.2 Deskripsi Fitur . . . . . . . . . . . . . . . . . . . 19

3.2.1 Fitur untuk Penyewa . . . . . . . . . . . . 203.2.2 Fitur untuk Administrator . . . . . . . . . 20

3.3 Arsitektur Sistem . . . . . . . . . . . . . . . . . . 203.3.1 Desain Umum Sistem . . . . . . . . . . . 203.3.2 Desain Rinci Manager . . . . . . . . . . . 213.3.3 Desain Rinci Load Balancer . . . . . . . . 253.3.4 Desain Rinci Node . . . . . . . . . . . . . 27

4 IMPLEMENTASI 334.1 Lingkungan Implementasi . . . . . . . . . . . . . 334.2 Rincian Implementasi Manager . . . . . . . . . . . 33

4.2.1 Backend Manager . . . . . . . . . . . . . 344.2.2 Frontend Manager . . . . . . . . . . . . . 47

4.3 Rincian Implementasi Load Balancer . . . . . . . . 554.3.1 Kakas Panggil . . . . . . . . . . . . . . . 55

4.4 Rincian Implementasi Node . . . . . . . . . . . . 554.4.1 Citra Cakram Docker . . . . . . . . . . . . 554.4.2 Kakas Panggil Node . . . . . . . . . . . . 58

5 PENGUJIAN DAN EVALUASI 615.1 Lingkungan Uji Coba . . . . . . . . . . . . . . . . 615.2 Skenario Uji Coba . . . . . . . . . . . . . . . . . . 63

5.2.1 Uji Unit Fungsionalitas . . . . . . . . . . . 635.2.2 Uji Kapasitas . . . . . . . . . . . . . . . . 685.2.3 Uji Performa . . . . . . . . . . . . . . . . 685.2.4 Aplikasi Contoh . . . . . . . . . . . . . . 695.2.5 Basis Data Contoh . . . . . . . . . . . . . 69

5.3 Hasil Uji Coba dan Evaluasi . . . . . . . . . . . . 695.3.1 Uji Unit Fungsionalitas . . . . . . . . . . . 70

xix

5.3.2 Uji Kapasitas dan Performa . . . . . . . . 755.3.3 Implementasi Prinsip Komputasi Awan . . 87

6 PENUTUP 936.1 Kesimpulan . . . . . . . . . . . . . . . . . . . . . 936.2 Saran . . . . . . . . . . . . . . . . . . . . . . . . 94

DAFTAR PUSTAKA 95

A PERBANDINGANLAYANANCLOUDWEBHOSTING 97

B TANGKAPAN LAYAR PANEL 101B.1 Antarmuka Admin . . . . . . . . . . . . . . . . . 101B.2 Antarmuka Penyewa . . . . . . . . . . . . . . . . 102

BIODATA PENULIS 107

DAFTAR GAMBAR

2.1 Ilustrasi Tiga Model Layanan Komputasi Awan . . 112.2 Contoh Kode ServerWeb SederhanaMenggunakan

Node.js . . . . . . . . . . . . . . . . . . . . . . . 122.3 Arsitektur Dasar dari Docker . . . . . . . . . . . . 142.4 Ilustrasi PenggunaanHAProxy sebagai Penyeimbang

Muat di Belakang Firewall . . . . . . . . . . . . . 15

3.1 Diagram Kasus Penggunaan Sistem . . . . . . . . 193.2 Desain Sistem Secara Umum . . . . . . . . . . . . 213.3 Desain Arsitektur pada Manager . . . . . . . . . . 223.4 Peta Situs Panel Admin pada Frontend Manager . . 243.5 Peta Situs Panel Penyewa pada Frontend Manager . 263.6 Desain Arsitektur pada Load Balancer . . . . . . . 273.7 Diagram Interaksi Proses Akses contoh.com yang

Dijalankan di Sistem oleh Pengakses. . . . . . . . 283.8 Desain Arsitektur setiap Node . . . . . . . . . . . 29

5.1 Toplogi Jaringan dalam Pengujian . . . . . . . . . 615.2 Tangkapan Layar jasmine-node dalam Melakukan

Uji Unit pengendali /apps . . . . . . . . . . . . . 745.3 Tangkapan Layar jasmine-node dalam Melakukan

Uji Unit Pengendali /dbs . . . . . . . . . . . . . . 745.4 Keadaan Node dan Load Balancer SEBELUM Uji

Kapasitas Percobaan Pertama Dilakukan (Kompu-ter dalam Keadaan Baru Dihidupkan) . . . . . . . 76

5.5 Keadaan Node dan Load Balancer SETELAH UjiKapasitas Percobaan Pertama Dilakukan . . . . . . 76

5.6 Keadaan Node dan Load Balancer Ketika SedangUji Performa . . . . . . . . . . . . . . . . . . . . 86

5.7 Antarmuka untuk Scaling atau Peningkatan Kapa-sitas Aplikasi pada Sistem Terimplementasi. . . . . 88

xxiii

xxiv

5.8 Hasil dari Perintah docker ps yang Menampilk-an Daftar Kontainer Docker yang Berjalan untukMengakomodir Banyaknya Aplikasi dan Basis Da-ta pada Suatu Node . . . . . . . . . . . . . . . . . 90

5.9 Antarmuka Pemantauan SebuahAplikasi SecaraUmum,Dapat Dilihat PenggunaanMemori dan Cakram Pe-nyimpanan pada Berjalannya Aplikasi Bersangkutan 91

5.10 Antarmuka Pemantauan Rangkuman Akses HTTPpada Aplikasi . . . . . . . . . . . . . . . . . . . . 92

5.11 Antarmuka Pemantauan Penggunaan PenyeimbangMuat pada Aplikasi (melalui antarmuka stats dariHAProxy) . . . . . . . . . . . . . . . . . . . . . . 92

B.1 Antarmuka Daftar Penagihan dari Penyewa . . . . 101B.2 Antarmuka Kelola Daftar Node dan Load Balancer 101B.3 Antarmuka Pemantauan Keadaan Node Secara Umum102B.4 Antarmuka Dasbor Pengguna . . . . . . . . . . . . 102B.5 Antarmuka Pemesanan Aplikasi/Basis Data Baru . 103B.6 Antarmuka Pemesanan PeningkatanKapasitas Apli-

kasi/Basis Data . . . . . . . . . . . . . . . . . . . 103B.7 Antarmuka Pengaturan Aplikasi . . . . . . . . . . 104B.8 Antarmuka Pengaturan Basis Data . . . . . . . . . 104B.9 Antarmuka Pemantauan Aplikasi . . . . . . . . . . 105B.10 Antarmuka Pemantauan Basis Data . . . . . . . . . 105B.11 Antarmuka Pemantauan Unggahan Aplikasi mela-

lui Git . . . . . . . . . . . . . . . . . . . . . . . . 106B.12 Antarmuka Pengelolaan Basis DataMelalui Konsol

MySQL . . . . . . . . . . . . . . . . . . . . . . . 106

DAFTAR TABEL

3.1 Daftar Kasus Penggunaan Sistem . . . . . . . . . . 173.2 Daftar Rute REST API pada Backend . . . . . . . 223.3 Rute pada Frontend Manager . . . . . . . . . . . . 25

4.1 Implementasi Pengendali /auth . . . . . . . . . . 344.2 Implementasi Pengendali /users . . . . . . . . . 354.3 Implementasi Pengendali /apps . . . . . . . . . . 374.4 Daftar Operasi pada Aplikasi . . . . . . . . . . . . 394.5 Implementasi Pengendali /dbs . . . . . . . . . . . 424.6 Daftar Operasi pada Basis Data . . . . . . . . . . . 444.7 Implementasi Pengendali /nodes . . . . . . . . . 454.8 Implementasi Pengendali /billing . . . . . . . . 464.9 Implementasi Peta Situs padaAntarmuka Panel Admi-

nistrator . . . . . . . . . . . . . . . . . . . . . . . 484.10 Implementasi Peta Situs pada Antarmuka Panel Pe-

nyewa . . . . . . . . . . . . . . . . . . . . . . . . 504.11 Implementasi Kakas Panggil pada Load Balancer . 554.12 Rincian Implementasi Citra Cakram Docker pada

Node . . . . . . . . . . . . . . . . . . . . . . . . . 564.13 Implementasi Kakas Panggil pada Node . . . . . . 58

5.1 Implementasi Uji Unit . . . . . . . . . . . . . . . 645.2 Hasil Eksekusi Uji Unit Fungsionalitas . . . . . . . 705.3 Daftar Aplikasi pada Uji Kapasitas Dengan Hasil

Uji Performa . . . . . . . . . . . . . . . . . . . . 77

A.1 Layanan yang Dipasarkan sebagai CloudWeb Hos-ting di Indonesia . . . . . . . . . . . . . . . . . . 97

A.2 Perbandingan Fitur antara Cloud Hosting berbasiscPanel dengan Layanan OpenShift dan Heroku . . 98

xxi

BAB 1

PENDAHULUAN

1.1 Latar BelakangLayanan hosting dan pengembangan aplikasi dalam bentuk Webatau sering disebut dengan Web hosting merupakan layanan yangjamak tersedia di Indonesia. Layanan ini memberikan wadah ba-gi individu, organisasi atau perusahaan besar agar bisa meletakkanaplikasi buatan mereka beserta basis datanya di Internet tanpa perludipersulit dengan penyediaan koneksi Internet terdedikasi. Umum-nya, aplikasi yang diletakkan berupa situs halaman portal,Web blog,sistem informasi skala kecil hingga besar.

Web Hosting memiliki berbagai macam jenis berdasarkan la-yanan yang diberikan [1], kemudahan yang disediakan serta teknikpenempatan (host) aplikasinya. Salah satu jenis yang paling umumadalah Shared Web Hosting menggunakan perangkat lunak berna-ma cPanel. Pada jenis ini, aplikasi dari banyak pengguna disimpandalam satu mesin server yang sama dan setiap aplikasi bisa diaksesmelalui nama domain yang ditentukan. Konsekuensi dari penyim-panan pada server yang sama adalah adanya kemungkinan bottle-neck baik dari sisi pemrosesan, memori dan jaringan. Selain itu,Shared Web Hosting hanya menyediakan satu platform yang samasehingga tidak cocok digunakan untuk aplikasi Web yang menggu-nakan platform bahasa pemrograman yang berbeda.

Jenis Hosting selanjutnya adalah virtual private server atauVPS.Layanan ini menawarkan kendali penuh dari sisi pengguna sehinggamereka dapatmengontrol apa saja layanan yang tersedia pada serverkarena VPS memberikan kendali sistem operasi secara penuh me-lalui teknik yang disebut dengan virtualisasi. VPS tersedia dalamberbagai macam jenis layanan berdasarkan jumlah sumber daya pe-nyimpanan memori, jaringan serta kemampuan pemrosesan. Selainitu, kebanyakan layanan penyediaVPS saat ini jugamemberikan ke-mampuan peningkatan kapasitas dan fitur pemantauan. Kelemah-an dari VPS adalah kerumitannya dalam konfigurasi karena semua

1

2

konfigurasi dilakukan manual oleh pengguna atau penyewa.

Selain Shared Web Hosting dan VPS, saat ini terdapat jenisweb hosting yang mulai populer yaitu CloudWeb Hosting. Layananini mengadopsi prinsip komputasi awan yaitu berupa Platform as aService (PaaS) yang menyediakan jasa platform bagi pengembangWeb untuk menempatkan aplikasi mereka di Internet. Layanan inimemberikan fitur tambahan yang menjadi karakteristik komputa-si awan: transparansi akses, multi-platform, skalabilitas, reliabili-tas, keterbukaan akses API dan kemudahan penggunaan. Contohlayanan semacam ini adalah Microsoft Azure, Heroku, OpenShift,Google Apps Engine. Sayangnya, layanan ini masih sangat jarangada terutama di Indonesia. Kebanyakan layanan yang dipasarkan se-bagai Cloud Web Hosting di Indonesia (dijelaskan pada tabel A.1pada lampiran) masih menggunakan panel kontrol berbasis cPanelyang memiliki fitur terbatas dan hanya didesain untuk shared webhosting. Pihak ketiga kesulitan menawarkan layanan serupa karenabelum ada perangkat lunak PaaS yang didesain khusus untuk ke-butuhan hosting banyak penyewa (multi-tenant) (perbandingan fi-tur antara hosting cPanel dengan Cloud Web Hosting lainnya di-jelaskan pada tabel A.2 pada lampiran). Kebanyakan aplikasi PaaSOpen Source seperti OpenShift Origin dan CloudFoundry masih di-fokuskan untuk kebutuhan private cloud.

Pada Tugas Akhir ini, dilakukan perancangan perangkat lunakdan sistem jaringan PaaS yang dikhususkan untuk membangun la-yanan pengembangan dan hosting aplikasi berbasis komputasi aw-an. Sistem ini mengadopsi beberapa prinsip komputasi awan me-nurut definisi NIST [9] yaitu: self-service, resource pooling danmeasured service. Sistem ini juga mengambil beberapa fitur yangada pada layanan Cloud Web Hosting seperti OpenShift dan He-roku serta mengadopsi beberapa unsur yang ada pada shared webhosting tradisional seperti sistem penagihan yang sederhana sertakemudahan untuk dibangun oleh pihak ketiga yang ingin memba-ngun layanan sejenis.

3

1.2 Rumusan MasalahBerikut beberapa hal yang menjadi rumusan masalah dalam TugasAkhir ini:

• Bagaimana membangun sistem Platform-as-a-Service (PaaS)yang dirancang untuk penyedia jasa layanan hosting aplikasi?

• Bagaimana prinsip on-demand self-service, resource poolingdan measured service dalam komputasi awan diterapkan didalam perangkat lunak PaaS yang dirancang?

1.3 Batasan MasalahBatasan masalah pada Tugas Akhir ini adalah sebagai berikut:

• Sistem yang dibangun mengadopsi sifat komputasi awan di-batasi pada: self-service, resource pooling dan measured se-rvice.

• Sistem dibatasi untuk kebutuhan hosting aplikasi, eksekusiaplikasi pada Web (HTTP) serta basis data.

• Platform bahasa pemrograman yang didukung dibatasi pada:Node.js, PHP, Python dan Ruby. Sementara basis data diba-tasi pada MySQL.

• Modul pembagi muat hanya akan diberlakukan pada aplikasiWeb. Sementara basis data hanya dapat berjalan pada satunode saja.

1.4 TujuanTujuan dari Tugas Akhir ini adalah menghasilkan sistem dan per-angkat lunak Platform-as-a-Service untuk kebutuhan pengembang-an dan hosting aplikasi pada Web yang mendukung beberapa sifatkomputasi awan.

1.5 ManfaatManfaat yang diberikan dengan pembuatan Tugas Akhir ini adalahmemberikan peluang kepada pihak penyedia jasa layanan web hos-ting agar dapat menggunakan perangkat luaran untuk membangunlayanan web hosting yang berbasis komputasi awan.

4

1.6 MetodologiLangkah danmetode yang dilakukan untukmengerjakan TugasAkhirini dijelaskan sebagai berikut.

• Penyusunan Proposal Tugas AkhirPenyusunan proposal Tugas Akhir dilaksanakan untuk me-rumuskan masalah serta melakukan penetapan desain dasarsistem yang akan dikembangkan dalam pelaksanaan TugasAkhir ini.

• Studi LiteraturUntuk membantu proses pengerjaan Tugas Akhir, diperlukanstudi lebih lanjutmengenai penggunaan komponen-komponenterkait dengan sistem yang akan dibangun.

• Desain dan PerancanganDalam rangkamemerinci lebih jauhmengenai bagaimaname-manfaatkan komponen-komponen sistem untuk membangunsistem secara utuh, diperlukan proses desain dan perancang-an dari sistem. Hasil analisis dan desain kemudian ditetapkanmenjadi rancangan dasar implementasi sistem.

• Implementasi SistemHasil analisis dan desain kemudian diimplementasikan mela-lui komponen-komponen perangkat lunak pendukung.

• Uji Coba dan EvaluasiUntuk mengukur kemampuan sistem untuk menangani peng-guna dari segi fungsionalitas dan performa, dilakukan prosesuji coba dan evaluasi untuk mengetahui sejauh mana sistemdapat berjalan sesuai dengan yang diharapkan dan sejauh ma-na prinsip dari komputasi awan dapat diimplementasikan didalam sistem.

1.7 Sistematika LaporanBuku Tugas Akhir ini terdiri dari beberapa bab yang dijelaskan se-bagai berikut:

• Bab 1. Pendahuluan. Bab ini berisikan latar belakang, ru-musan masalah, tujuan, manfaat, metodologi dan sistematika

5

penulisan yang digunakan sebagai dasar penyusunan TugasAkhir.

• Bab 2. Tinjauan Pustaka. Bab ini berisikan teori penunjangyang berhubungan dengan Tugas Akhir.

• Bab 3. Desain dan Perancangan. Bab ini membahas desaindasar dari sistem dan perangkat lunak yang akan dirancangsebagai bagian dari pengerjaan Tugas Akhir.

• Bab 4. Implementasi. Bab ini membahas hasil implementasidari rancangan sistem beserta tekniknya.

• Bab 5. Uji Coba danEvaluasi. Bab ini membahasmengenaiteknik uji coba dan hasil keluaransnya sebagai bahan evaluasiterhadap hasil Tugas Akhir.

• Bab 6. Penutup. Bab ini berisi kesimpulan dari hasil uji cobaserta saran untuk pengembangan Tugas Akhir selanjutnya.

6

Halaman ini sengaja dikosongkan

BAB 2

LANDASAN TEORI

2.1 Web HostingWeb Hosting merupakan jasa penyewaan ruang dan koneksi untukkeperluan menempatkan suatu aplikasi atau halaman Web di Inter-net. Layanan ini memberikan kesempatan kepada pihak ketiga yangtidak memiliki koneksi Internet terdedikasi (dengan IP publik) un-tukmenempatkan situsWebmerekamelalui server yang disediakanoleh pihak Web Hosting.

Web Hosting memiliki beberapa jenis berdasarkan metode pe-nempatan berkas Web dan fasilitas yang diberikannya [1]:

• Shared Hosting, merupakan jenis web hosting yang palingumum. Pada shared hosting, situs Web setiap pelanggan di-letakkan secara bersamaan pada satu server sehingga semuapelanggannya hanya perlu menanggung operasional satu se-rver tersebut. Kekurangan utama dari shared hosting adalahadanya perebutan sumber daya yang dilakukan jika satu si-tus Web diakses lebih banyak daripada yang lainnya. Namunkelebihannya, harga yang ditawarkan jauh lebihmurah diban-dingkan hosting lainnya.

• Reseller Hosting, merupakan perangkat shared web hostingyang bisa dijual ke orang lain yang membutuhkan.

• Grid/CloudHosting, merupakan jenisweb hosting baru yangmemungkinkan penggunaan beberapa server untuk digabungmenjadi sebuah server besar. Penggunaannya adalah ketikakemampuan sumber daya yang dibutuhkan lebih banyak, ma-ka hanya perlu penambahan sumber daya dan komputer untukbergabung ke jaringan sebelumnya. Umumnya, cloud hostingmenggunakan skema pasca-bayar yaitu membayar sesuai de-ngan penggunaan sumber daya.

• Virtual Private Server (VPS)merupakan jenis hosting yangmemberikan fasilitas pengendalian dan akses sistem operasiserver secara penuh. Walaupun VPS menggunakan teknik

7

8

virtualisasi untuk membagi sumber daya satu server, namunpembagian sumber dayanya terjamin sehingga tidak terjadirebutan sumber daya akibat ketimpangan akses.

• Dedicated Server merupakan jenis hosting yang memberik-an satu unit server utuh secara fisik dan memberikan aksespenuh kepada pelanggannya.

• Colocation merupakan jenis hosting yang hanya memberik-an perangkat dan ruang bagi pelanggannya untuk membuatpusat data sendiri. Pelanggan diwajibkanmenggunakan kom-puter mereka sendiri dan layanan hanya menyediakan listrik,pendinginan, keamanan fisik, dan koneksi Internet.

• Self Servicemerupakan layanan hosting yang disediakan sen-diri oleh pelanggannya tanpa memerlukan layanan web hos-ting lain. Pelanggan hanya membutuhkan koneksi Internetterdedikasi dan bertanggungjawab untuk segala kebutuhan sum-ber daya lainnya.

2.2 Komputasi AwanKomputasi awan atau cloud computing menurut definisi dari NIST(National Institute of Standard Technology) merupakan model yangmemberikan akses segala macam (ubiquitous), yang nyaman danakses jaringan sesuai kebutuhan pada kumpulan sumber daya kom-putasi yang dapat dikonfigurasi (baik dari sisi jaringan, server, pe-nyimpanan, aplikasi dan layanannya) sehingga bisa ditetapkan se-cara cepat dengan usaha manajemen seminimal mungkin. [9]

Komputasi awan meliputi komputasi, perangkat lunak, aksesdata dan layanan penyimpanan yang tidak memerlukan pengetahu-an pengguna akhir (end-user) terhadap lokasi fisik dan konfiguasidari sistem yang diberikan pada layanan. Komputasi awan juga me-rupakan tren dunia teknologi informasi saat ini yang memindahkanproses komputasi yang awalnya dari komputer desktop atau PC keperangkat pusat data yang besar. [8]

Tujuan utama dari komputasi awan adalah untukmembuat peng-gunaan sumber daya terdistribusi menjadi lebih baik dengan meng-

9

ombinasikannya agar menjadi luaran yang besar serta mampu me-mecahkan komputasi skala besar. Komputasi awan secara spesifikberhubungan dengan teknologi virtualisasi, skalabilitas, kemampu-an inter-operasi, kualitas layanan dan model pelayanan.

2.2.1 KarakteristikBerikut adalah beberapa karakteristik umumyang terdapat pada kom-putasi awan menurut definisi dari NIST [9]:

• On-Demand Self Service, pelanggan atau penyewa dapat me-netapkan kemampuan komputasinya tanpa perlu interaksi se-cara manual.

• Broad Network Access yaitu kemampuan yang tersedia padajaringan yang dapat diakses melalui media apapun baik thin-client maupun thick-client.

• Resource Pooling yaitu kemampuan untuk menyatukan sum-ber daya komputasi dari penyedia layanan untuk diberikan kebanyak pelanggan atau penyewa dengan sumber daya fisikmaupun virtual yang secara dinamis diberikan atau dilepassesuai kebutuhan pelanggan. Dalam hal ini, pelanggan tidakmemiliki pengetahuan dan kontrol mengenai dimana sebenar-nya suatu sumber daya ditempatkan secara fisik.

• Rapid Elasticity yaitu kemampuan sumber daya yang secaraelastis bisa ditetapkan atau dilepaskan.

• Measured Service yaitu memberikan kontrol otomatis untukmengoptimasi sumber daya dengan meningkatkan pengukur-an pada layanan (seperti penyimpanan, pemrosesan dan lebarpita jaringan)

2.2.2 Model LayananSecara umum, terdapat tiga model layanan yang umumnya dita-warkan pada komputasi awan [9]:

• Infrastructure as a Service (IaaS)memberikan layanan kepa-da pelanggan untuk menetapkan penyimpanan, jaringan dansumber daya komputer utama lainnya dimana pelanggan da-

10

pat menjalankan perangkat lunak apa saja didalamnya danmelakukan kendali terhadap sistem operasi, penyimpanan danaplikasi yang disebarkannya.

• Platform as a Service (PaaS)memberikan layanan kepada pe-langgan untuk menyebarkan (deploy) aplikasi kepada peng-guna lainnya melalui bahasa pemrograman, pustaka, layan-an dan kakas yang didukung oleh penyedia. Pelanggan tidakperlu mengontrol infrastruktur di bawahnya seperti jaringan,server, sistem operasi dan media penyimpanan namun memi-liki kendali terhadap aplikasi yang mereka kembangkan.

• Software as a Service (SaaS)memberikan layanan kepada pe-langgan untuk menggunakan perangkat lunak aplikasi padainfrastruktur komputasi awan. Aplikasi bisa diakses dari ber-bagai macam klien, baik melalui antarmuka thick-client se-perti aplikasi desktop maupun thin-client seperti perambanWeb.

Ketiga layanan tersebut digambarkan pada Gambar 2.1

2.3 Node.jsNode.js merupakan kerangka kerja lisensi terbuka dan lintas pla-tform berbasis Javascript yang digunakan untuk membangun apli-kasi sisi server dan jaringan. Kerangka kerja ini dibuat pertamakali oleh Ryan Dahl pada tahun 2009 pada situs Web http://nodejs.org. Pada awalnya, Javascript hanya merupakan bahasapemrograman yang digunakan dan berjalan pada peramban Web.Penggunaan Javascript untuk kebutuhan aplikasi server kemudiandikembangkan melalui Node.js sehingga pengembang bisa menulisprogram aplikasi Web mereka cukup dalam satu bahasa. [10]

Node.js menggunakan mesin Javascript Google V8 seperti yangjuga digunakan oleh Google Chrome. Selain itu Node.js juga mem-berikan kemampuan kepada pengembang untuk membangun apli-kasi jaringan yang cepat dan scalable menggunakan pola pemro-graman berbasis event-driven dan non-blocking I/O sehingga bisamembuat aplikasi menjadi ringan, cepat dan efisien untuk aplika-

http://nodejs.org

http://nodejs.org

11

Gambar 2.1: Ilustrasi Tiga Model Layanan Komputasi Awan

si yang bersifat waktu nyata dan intensif data. [11] Contoh kodeprogram untuk membuat server Web sederhana bisa dilihat padagambar 2.2

Node.js mengadopsi konsep pemrograman berbasis event di-bandingkan menggunakan thread untuk mengelola banyaknya ma-sukan dari I/O seperti pada aplikasi jaringan yang menerima ba-nyak klien. Untuk menggunakan event, pemrogrammenuliskan ko-de yang akan dieksekusi ketika suatu event terjadi misalnya ketikaada permintaan koneksi dari klien atau ketika data dari basis data si-ap untuk dikirimkan ke klien. Ketika event terjadi, sistem notifikasi

12

var http = require('http');http.createServer(function (req, res) {

res.writeHead(200, {'Content-Type': 'text/plain'});res.end('Hello World\n');

}).listen(1337, '127.0.0.1');console.log('Server running at http://127.0.0.1:1337/');

Gambar 2.2: Contoh Kode Server Web Sederhana MenggunakanNode.js

akan memberitahu kepada aplikasi untuk mengelola event tersebut.Konsep event berlanjut pada penggunaan teknik yang disebut

Asynchronous I/O. Pada teknik ini, program tidak akan terblokiratau dihentikan sementara jika melakukan suatu operasi I/O, me-lainkan program akan tetap berlanjut. Ketika operasi I/O berhasildilakukan, program akan kembali melakukan operasi semestinyaterhadap I/O tersebut. Hal ini sangat berguna pada aplikasi yangsangat berat dalam melakukan proses I/O seperti operasi basis dataatau berkas. [12]

2.4 MEAN FrameworkMEAN Framework atau MEAN Stack merupakan kerangka kerjapemrograman yang terdiri dari komponen berikut [13]:

• MongoDB sebagai perangkat server basis data tanpa SQLberbasis dokumen JSON sebagai alternatif dari basis data ber-basis SQL yang sudah umum digunakan pada aplikasi bisnis.

• Express.js merupakan kerangka kerja pengembangan aplikasiWeb berbasis Javascript dari sisi server.

• Angular.js merupakan kerangka kerja pengembangan aplika-si Javascript dari sisi klien.

• Node.js merupakan kerangka kerja pemrograman yang mem-bawahi komponen Express.js.

13

Kombinasi kerangka kerja pemrograman ini menjadi alternatifdari kombinasi sebelumnya (LAMP, Linux Apache MySQL, PHP)yang sebelumnya sudahmendominasi. Berbeda dengan LAMPyangmasih menekankan pada aplikasi Web HTTP request sederhana,MEAN fokus ke penggunaan Javascript berbasis AJAX untuk me-nambah interaktivitas antara klien dan server sehingga pertukar-an data dapat dilakukan secara efisien dan tanpa perlu perpindah-an anatara halaman. Semua kombinasi perangkat lunak di dalamMEAN menggunakan bahasa pemrograman yang sama, yaitu Java-script, sehingga lebih sederhana dari sisi pemrogram.

2.5 DockerDocker merupakan kerangka kerja virtualisasi berbasis sistem ope-rasi Linux 64-bit. Berbeda dengan perangkat lunak virtualisasi la-innya yang melakukan virtualisasi mesin secara penuh, Docker me-lakukan virtualisasi di atas kernel yang berjalan pada sistem opera-si dibawahnya sehingga hanya menggunakan sumber daya memoriyang sangat kecil dan dapat berjalan dengan cepat. Docker dikem-bangkan oleh perusahaan Docker.inc dan dilisensikan dibawah li-sensi Apache 2.0.

Docker menggunakan istilah container untuk setiap mesin vir-tual yang berjalan. Setiap container akan diisolasi satu sama lainterhadap sistem operasi utama sehingga tidak akan saling meng-anggu. Berbeda dengan virtualisasi berbasis container lainnya se-perti OpenVZ, Docker menawarkan kakas yang mempermudah pa-ra pengembang untuk melakukan pengelolaan container yang di-jalankan di dalam sistem mereka. Docker juga menawarkan si-tus yang dapat digunakan oleh pengembang untuk mendapatkan ci-tra atau image dari container yang sudah siap pakai pada https://registry.hub.docker.com. [14] Selain itu, pengguna jugadapat membangun citra mereka sendiri menggunakan API yang su-dah disediakan.

Docker berjalan dengan konsep klien dan server. Pada sisi se-rver, berjalan sebuah Docker Daemon yang akan mengelola jalan-

https://registry.hub.docker.com

https://registry.hub.docker.com

14

nya setiap container yang ada di dalam server. Docker menggunak-an sistem berkas AUFS untuk mengelola berkas pada setiap conta-iner dan menggunakan LXC untuk mengatur jalannya container.Arsitektur dasar dari Docker dapat dilihat pada Gambar 2.3

Gambar 2.3: Arsitektur Dasar dari Docker

Docker dan virtualisasi tingkat sistem operasi pada umumnyamerupakan salah satu komponen utama dari suatu sistem PaaS ka-rena adanya kebutuhan khusus pada aplikasi yang berjalan di bawahPaaS seperti: isolasi aplikasi, pengurangan overhead dari performajika dibandingkan dengan mesin virtual hypervisor, dukungan ber-bagai platform dan bahasa pemrograman, dan perpindahan posisi

15

aplikasi dari satu mesin dan mesin lain dengan mudah. [15]

2.6 HAProxyHAProxy merupaka perangkat lunak bebas dan terbuka untuk kebu-tuhan penyeimbanganmuat yangmembutuhkan ketersediaan serveryang tinggi. Perangkat lunak ini mendukung pembagianmuat untukakses HTTPmaupun yang berbasis socket TCP. Perangkat lunak inidiklaim sebagai standar de-facto untuk aplikasi load balancer di sis-tem operasi Linux maupun pada platform berbasis komputasi awan[16]. Ilustrasi penggunaan HAProxy dapat dilihat pada Gambar 2.4.

Gambar 2.4: Ilustrasi Penggunaan HAProxy sebagai PenyeimbangMuat di Belakang Firewall

16


BAB 3

DESAIN DAN PERANCANGAN

Pada bab ini dibahas mengenai analisis, perancangan dan imple-mentasi dari sistem.

3.1 Kasus PenggunaanGambar 3.1 menampilkan kasus penggunaan sistem secara umumdengan penjelasan tertera pada Tabel 3.1

Tabel 3.1: Daftar Kasus Penggunaan Sistem

No Nama Aktor DeskripsiUC01 Mendaftarkan

PenyewaNon Penggu-na

Calon penyewa yang ber-minat untuk menggunak-an sistem diwajibkan ut-nuk mendaftarkan sebuahakun ke sistem terlebih da-hulu

UC02 MengajukanAplika-si/Basis DataBaru

Penyewa Aplikasi dan basis datayang ingin dibuat terlebihdahulu diajukan oleh pe-nyewa. Kemudian penye-wa akan diberi kesempat-an untuk melakukan pem-bayaran atas tagihan da-ri pengajuan tersebut danAdmin menyetujuinya.

UC03 MengajukanPeningkatan(scaling)Aplika-si/BasisData

Penyewa Jika aplikasi dan basis da-ta ingin ditingkatkan ka-pasitasnya oleh penyewa,maka penyewa perlu me-lakukan pengajuan pening-katan tersebut.

17

18

No Nama Aktor DeskripsiUC04 Pengaturan

Aplika-si/BasisData

Penyewa Aplikasi dan basis datayang sudah berjalan dapatdiatur oleh pengguna. Pe-ngaturan meliputi: namadomain dan jalan tidaknyainstance aplikasi.

UC05 MonitorAplika-si/BasisData

Penyewa Aplikasi dan basis datayang sudah berjalan da-pat dimonitor oleh peng-guna. Monitor meliputipenggunaan sumber dayadiska, memori, rangkumanlog akses dan rangkumanlog sistem secara umum.

UC06 Unggah DataAplikasi

Penyewa Data berkas aplikasi da-pat diunggah oleh penye-wa pemilik aplikasi mela-lui antarmuka berbasis Git.

UC07 Kelola BasisData

Penyewa Basis data dapat dimanipu-lasi melalui akses konsoldari aplikasi basis data

UC08 Kelola Nodedan Load Ba-lancer

Admin Semua data Node dan Lo-ad Balancer yang ada disistem dikelola oleh adminsistem.

UC09 Setujuidan ProsesPenagihan

Admin Pengajuan dan penambah-an (scaling) aplikasi danbasis data disetujui olehadmin untuk kemudian di-aktivasi.

19

No Nama Aktor DeskripsiUC10 Monitor No-

de dan LoadBalancer

Admin Monitor Node dan LoadBalancer yang terdaftar se-cara umum seperti peng-gunaan diska, memori danpembacaan berkas log pen-ting

Gambar 3.1: Diagram Kasus Penggunaan Sistem

3.2 Deskripsi FiturSecara umum, fitur sistem dibagi menjadi dua: fitur untuk penyewadan fitur untuk administrator.

20

3.2.1 Fitur untuk PenyewaBerikut adalah fitur yang tersedia untuk penyewa yang sudah ter-daftar pada sistem:

• Mengajukan aplikasiWeb baru denganmemilih jenis kerang-ka kerja, kapasitas ruang diska dan jumlah Node yang digu-nakan.

• Mengajukan basis data baru dengan jenis MySQL berdasark-an kapasitas diska.

• Scale-Out untuk menambah Node atau kapasitas diska dariaplikasi Web secara mandiri.

• Mengelola berkas aplikasi Web melalui antarmuka Git.• Mengelola basis data berbasis shell MySQL.• Menjalankan dan menghentikan aplikasi yang sedang berjal-an.

• Memonitor jalannya aplikasi berupa log pesan debug dan logakses.

• Mengubah nama domain aplikasi untuk DNS Server.

3.2.2 Fitur untuk AdministratorBerikut adalah fitur yang disediakan untuk Administrator:

• Melakukan verifikasi penagihan yang diajukan oleh penggu-na dan aktivasi pesanan dan proses scaling.

• Memonitor keadaan di setiap Node.• Mendata dan mencatat semua Node dan Load Balancer yangterpasang.

3.3 Arsitektur SistemPada sub-bab ini, dibahas mengenai tahap analisis dan kebutuhanbisnis dan desain dari sistem yang akan dibangun.

3.3.1 Desain Umum SistemSistem dibangun dalam beberapa komponen umumyang terkait satusama lain, yaitu:

• Manager sebagai antarmuka pengendali jalannya PaaS dari

21

sisi klien penyewa maupun administrator.• LoadBalancer atau penyeimbangmuat sebagai titik awal ke-tika pengguna umum mengakses aplikasi atau halaman Webyang dimiliki oleh penyewa. Komponen ini akan menyeim-bangkan beban akses dari suatu aplikasi Web.

• Node sebagai server yang menyimpan seluruh aplikasi Webdan basis data serta menjalankannya. Aplikasi dapat disimp-an secara redundan di beberapa Node sekaligus untuk me-ningkatkan kemampuan Load Balancer.

Gambar 3.2 menampilkan diagram arsitektur hubungan antarakomponen.

Gambar 3.2: Desain Sistem Secara Umum

3.3.2 Desain Rinci ManagerManager memberikan antarmuka Web kepada administrator mau-pun penyewa untuk mengelola aplikasi yang disimpan di dalam sis-tem. Aksi yang dilakukan oleh pengguna dikomunikasikan ke No-de maupun Load Balancer. Data terkait penyewa dan aplikasinyaseperti daftar pengguna, daftar tagihan (billing), aplikasi Web danbasis data yang tersimpan disimpan dalam basis data berbasis Mo-

22

ngoDB.Manager dibuat dengan konsep separation of concern yang ter-

diri dari Backend berupa REST API dan Frontend berupa aplikasiWeb. Penggunaan konsep ini untuk mempermudah pengembanganklien dalam bentuk lain jika diperlukan. Diagram arsitektur Mana-ger tertera pada Gambar 3.3.

Gambar 3.3: Desain Arsitektur pada Manager

3.3.2.1 Backend ManagerBagian Backend Manager dibuat menggunakan platform Node.jsdan Express.jsi pada sisi server. Tabel 3.2 menjelaskan daftar ruteakses REST API yang ada pada Backend. Ada tiga jenis rute padaAPI ini: rute yang bisa diakses tanpa autentikasi, rute yang bisadiakses oleh penyewa dan rute yang hanya bisa diakses oleh admin.

Tabel 3.2: Daftar Rute REST API pada Backend

No Rute Metode Hak Ak-ses

Aksi

1 /auth/request POST Tidak ada Mendapatkan tokenberdasarkan kre-densial pengguna

23


Aksi

2 /auth/verify POST Tidak ada Melakukan veri-fikasi keabsahantoken

3 /users GET,POST,PUT,DELETE

Admin Melakukan manipu-lasi data penggunapenyewa

4 /apps GET,POST,PUT,DELETE

Admin Melakukan manipu-lasi data aplikasi

5 /apps/app-id/operation

POST Penyewa Melakukan sua-tu operasi padaaplikasi tertentu

6 /dbs GET,POST,PUT,DELETE

Admin Melakukan manipu-lasi data basis data

7 /dbs/db-id/operation

POST Penyewa Melakukan suatuoperasi pada basisdata tertentu

8 /nodes GET,POST,PUT,DELETE

Admin Melakukan manipu-lasi data Node danLoad Balancer

9 /nodes/node-id/operation

POST Admn Melakukan suatuoperasi pada nodetertentu

24


Aksi

10 /billings GET,POST,PUT,DELETE

AdmindanPenyewa

Melakukan mani-pulasi data tagihanatau billing daripenyewa

11 /billings/billing-id/extract

GET Admin Membaca spesifi-kasi pesanan untukdiproses ke rute lain

Proses autentikasi dilakukan dengan melakukan permintaan to-ken pada rute /auth/request. Tokenisasi diimplementasikan berda-sarkan standar JSON Web Token (http://jwt.io).

3.3.2.2 Frontend ManagerBagian FrontendManager dibuat menggunakan platform yang samadengan yang digunakan oleh Backend. Hanya saja, akses ke Fron-tend dapat dilakukan melalui peramban Web biasa. Aplikasi Webdibuat menggunakan pustaka Angular.JS (https://angularjs.org). Tabel 3.3 menjelaskan rute HTTP yang ada pada FrontendManager.

Peta situs untuk halaman panel manager pada admin terdapatpada Gambar 3.4, semetara pada sisi pengguna atau penyewa terda-pat pada Gambar 3.5.

Gambar 3.4: Peta Situs Panel Admin pada Frontend Manager

http://jwt.io

https://angularjs.org

https://angularjs.org

25

Tabel 3.3: Rute pada Frontend Manager


Aksi

1 /login GET,POST

Tidak ada Menampilkan ha-laman login danmemrosesnya

2 /admin GET Admin Menampilkan panelmanager untukadmin

3 /user GET Penyewa Menampilkan panelmanager untuk pe-nyewa

4 /proxy POST Semua Melakuan pemang-gilan HTTP keREST API

3.3.3 Desain Rinci Load BalancerLoad Balancer dibuat untuk mendukung tranparansi akses aplikasiWeb maupun basis data tanpa perlu mengekspos pada Node manadata aplikasi atau basis data tersebut disimpan. Diagram arsitek-tur dari Load Balancer tertera pada Gambar 3.6 dan proses diagramcontoh proses akses aplikasi dan basis data oleh klien tertera padaGambar 3.7.

Data Node disimpan untuk setiap aplikasi Web maupun basisdata yang tersimpan. Jumlah Node di setiap aplikasi dibuat tergan-tung dari jumlah Node aplikasi Web bersangkutan. Data ini jugadisimpan terlebih dahulu disimpan pada Manager untuk menjaminkonsistensi pengaturan.

Konfigurasi HAProxy terletak pada berkas /etc/haproxy/haproxy.cfg.Secara umumuntuk setiap aplikasi, perlu ada dua bagian pengaturanyang harus diatur:

• HAProxyFrontendmengatur nama domain dari aplikasi dan

26

Gambar 3.5: Peta Situs Panel Penyewa pada Frontend Manager

bagaimana HAProxy mengatur koneksi ke domain tersebut.HAProxy menggunakan header HTTP 1.1 bernama "Host"untuk membedakan akses dari satu domain ke domain lain-nya yang memiliki aplikasi berbeda.

• HAProxy Backend mengatur di Node mana dan port berapaaplikasi akan dikoneksikan setelah permintaan dari Frontenddiproses dan bagaimana teknik load balancing yang akan di-lakukan.

27

Gambar 3.6: Desain Arsitektur pada Load Balancer

3.3.3.1 Skrip PanggilUntuk membantu Manager melakukan manipulasi data Load Ba-lancer sesuai dengan kebutuhan, diperlukan beberapa skrip panggilyang ditempatkan di Load Balancer sebagai berikut:

• register-Frontend skrip untuk melakukan pendaftaran Fron-tend baru pada suatu aplikasi.

• register-Backend skrip untuk melakukan pendaftaran Bac-kend baru pada suatu aplikasi.

• unregister-Frontend skrip untukmelakukan penghapusan da-ta Frontend yang sudah ada.

• unregister-Backend skrip untukmelakukan penghapusan da-ta Backend yang sudah ada.

• reload-proxy skrip untuk melakukan restart pada HAProxyuntuk menerapkan pengaturan yang sudah ada.

3.3.4 Desain Rinci NodeNode merupakan tempat dimana aplikasi Web dan basis data se-benarnya ditempatkan. Node tidak terekspos oleh jaringan luar danhanya bisa diakses melalui jaringan internal melalui Load Balancer.Satu aplikasi Web dapat disimpan pada satu atau beberapa Nodedan dapat ditambah/dikurang melalui proses scaling oleh pelangg-an. Namun untuk basis data (berbasis MySQL), hanya ada satu No-de saja untuk satu server basis data dikarenakan proses sinkroni-

28

Gambar 3.7: Diagram Interaksi Proses Akses contoh.com yang Di-jalankan di Sistem oleh Pengakses.

sasi/replikasi master-master masih belum bisa diaplikasikan secaratransparan [17]. Semua data mengenai Node, dan aplikasi Web /basis data yang ter-hosting pada suatu Node disimpan pada basisdata Hosting Manager. Diagram arsitektur untuk Node tertera padaGambar 3.8.

Untuk menyimpan beberapa aplikasi dan basis data Web padasatu Node yang sama, setiap Node dibuatkan akun pengguna berba-sis PAM (Pluggable Authentication Modules) untuk setiap aplikasiatau basis data. Akun pengguna ini kemudian diatur dengan kuotaruang diska tertentu sesuai dengan yang diinginkan oleh penyewa.

Jika aplikasi yang sama disimpan dalam beberapa Node yangberbeda pada kasus aplikasi yang menggunakan lebih dari satu No-de, akan ada dua jenis klasifikasi Node: sebuah Root Node yangmenyipan data master utama aplikasi dan Slave Node yang akan

29

Gambar 3.8: Desain Arsitektur setiap Node

mengikuti data aplikasi dari Root Node. Penyewa dapat mengung-gah data aplikasi (berupa kode tereksekusi) melalui Git ke Root No-de dari aplikasi bersangkutan. Kemudian ketika aplikasi dijalankan,semua Slave Node akan melakukan sinkronisasi data aplikasi dariRoot Node.

3.3.4.1 Citra Docker pada NodeAplikasi atau basis data kemudian dijalankan ke dalam sebuah con-tainer berbasis Docker menggunakan citra yang sesuai dengan pla-tform bahasa pemrograman atau basis data bersangkutan. Pada ran-cangan tugas akhir ini, terdapat beberapa citra Docker yang dibuat:

• nodejs-nodemon citra untuk container aplikasi berbasis No-de.js. Terdiri dari server NGINX sebagai Frontend, Node.jsversi 0.10 danNodemon (github.com/remy/nodemon) un-tuk eksekutor aplikasinya.

• php55-fpm citra untuk container aplikasi berbasis PHP 5.5menggunakan mesin FastCGI berbasis FPM dan server NGI-NX sebagai Frontend. Terdapat aplikasi composer (http://getcomposer.org) untuk manajemen paket PHP.

• python27-gunicorn citra untuk container aplikasi berbasisPython versi 2.7 dengan mesin FastCGI berbasis Gunicorn(http://gunicorn.org) dan server FrontendNGINX.Con-tainer dijalankan dengan virtualenv (http://virtualenv.

github.com/remy/nodemon

http://getcomposer.org

http://getcomposer.org

http://gunicorn.org

http://virtualenv.readthedocs.org

30

readthedocs.org) agar pengguna bisamemasang paket Pythontambahan yang diperlukan tanpa perlu memanipulasi isi citra.

• ruby19-thin citra untuk container aplikasi berbasis Ruby 1.9denganmesin FastCGI berbasis Thin (code.macournoyer.com/thin/).

• mysql-single citra untuk container MySQL 5.5. Hanya ber-jalan satu Node untuk satu instance data.

3.3.4.2 Skrip PanggilUntuk mengelola aplikasi dan basis data yang disimpan pada setiapNode, maka dibuat beberapa skrip panggil berbasis CLI yang bisadipanggil olehManager ketika melakukan aksi dari operasi yang di-terima oleh admin atau penyewa. Berikut adalah daftar skrip pang-gil yang dibuat:

• create-app skrip untukmembuat aplikasi baru pada Root No-de. Skrip ini tidak perlu dipanggil pada Slave Node.

• start-app skrip untuk menjalankan suatu aplikasi pada suatuNode melalui container Docker. Skrip dipanggil untuk setiapNode yang memiliki aplikasi bersangkutan.

• stop-app skrip untuk menghentikan suatu aplikasi pada suatuNode.

• status-app skrip untukmelihat status berjalannya aplikasi pa-da suatu Node

• log-app skrip untuk melihat data berkas log pada suatu apli-kasi melalui container Docker

• create-db skrip untuk membuat basis data baru.• start-db skrip untuk menjalankan suatu basis data pada suatuNode melalui container Docker. Skrip dipanggil untuk setiapNode yang memiliki basis data bersangkutan.

• stop-db skrip untuk menghentikan suatu basis data pada su-atu Node.

• status-db skrip untuk melihat status berjalannya basis datapada suatu Node

• log-db skrip untuk melihat data berkas log pada suatu basis



code.macournoyer.com/thin/

code.macournoyer.com/thin/

31

data melalui container Docker• status-node skrip untukmelihat status suatuNode secara umum.• log-node skrip untuk membaca berkas log pada Node.

32


BAB 4

IMPLEMENTASI

Bab ini membahas implementasi perancangan sistem PaaS secararinci. Pembahasan dilakukan untuk setiap komponen yang sudahdijelaskan pada bab sebelumnya yaitu: Manager, LoadBalancer danNode.

4.1 Lingkungan ImplementasiLingkungan Implementasi dan pengembangan dilakukan menggu-nakan komputer PC dengan spesifikasi Intel(R) Core(TM) i3 de-ngan memori 8GB. Perangkat lunak yang digunakan dalam prosespengembangan antara lain:

• Sistem operasi Ubuntu Linux 14.04.1 LTS.• Desktop xfce.• Editor teks vim.• git 1.9.1 untuk pengelolaan versi kode program.• Node.js 0.10 untuk kerangka kerja pemrograman.• Docker 1.2.0 untuk uji coba citra cakram (disk images) Doc-ker.

• Paket TEXlive untuk penulisan buku tugas akhir.• Peramban webMozilla Firefox.

4.2 Rincian Implementasi ManagerSeperti yang sudah dijelaskan pada subbab 3.3.2, komponen Mana-ger terdiri dari dua bagian: Backend dan Frontend. Berikut adalahpenjelasan rincian implementasi dari masing-masing bagian.

33

344.2.1 Backend ManagerImplementasi Backend manager dibagi berdasarkan rute REST API yang sudah dijelaskan pada Tabel3.2. Setiap rute dasar dibuat dalam pengendali / controller terpisah.

4.2.1.1 Pengendali /authUntuk mengatur hak akses pada setiap rute, sistem mengimplementasikan penggunaan token yang wa-jib dimasukkan oleh pengguna ketika mengakses rute tertentu yang membutuhkan hak akses khusus.Proses untuk mendapatkan token pertama kali dan memerifikasi token dilakukan melalui pengenda-li /auth. Pengendali ini terdiri dari dua sub-rute: rute /auth/request untuk proses meminta to-ken, rute /auth/verify untuk verifikasi keabsahan token. Implementasi dari kedua sub-rute dapatdilihat pada Tabel 4.1. Proses pembuatan dan verifikasi token menggunakan pustaka jsonwebtoken(github.com/auth0/node-jsonwebtoken) pada Node.js.

Tabel 4.1: Implementasi Pengendali /auth

No Rute HakAkses Masukan Luaran Langkah Proses

1 POST/request

-Username,Passwo-rd

Token,Role

1. Jika Username dan Password ter-daftar

• Berikan token dan role

Keterangan: T: Hak Akses Penyewa, A: Hak Akses Admin, (1) Data Tunggal, (n) Data Jamak

github.com/auth0/node-jsonwebtoken

35


2 POST/verify

- Token,Role

Boolean(1)

1. Jika Token valid dengan Role yangbenar

• Kembalikan TRUE


4.2.1.2 Pengendali /usersPengendali ini berfungsi untuk melakukan manipulasi data pengguna penyewa. Rute pengendali /usersdapat diakses melalui metode GET, POST dan PUT sesuai yang dijelaskan pada Tabel 4.2.

Tabel 4.2: Implementasi Pengendali /users


1 GET / A -Datapenyewa(n)

1. Kembalikan data semua penyewa


36


2 GET /use-rId

A -Datapenyewa(1)

1. Kembalikan data penyewa userId

3 POST / ADatapenyewa(1)

Datapenyewa(1)

1. Lakukan pembuatan penyewa baru2. Kembalikan data penyewa yang su-

dah diberi userId

4 PUT /use-rId

ADatapenyewa(1)

Datapenyewa(1)

1. Ubah data penyewa sesuai yang di-minta

2. Kembalikan data penyewa hasil pe-ngubahan


4.2.1.3 Pengendali /appsPengendali ini berfungsi untuk melakukan manipulasi data aplikasi dari setiap penyewa. Tabel 4.3 men-jelaskan implementasi sub-rute dari pengendali rute /apps.

Pengendali ini memiliki rute khusus bernama POST /apps/app-id/operasi yang memiliki ber-bagai fungsi untuk melakukan operasi pada aplikasi. Daftar operasi dapat dilihat pada Tabel 4.4.

37

Tabel 4.3: Implementasi Pengendali /apps


1 GET / T-A - Data apli-kasi (n)

1. Apakah pengguna T atau A?• Jika T maka kembalikan data aplikasimilik T

• Jika A maka kembalikan semua dataaplikasi

2 GET /ap-pId

T-A - Data apli-kasi (1)

1. Apakah pengguna T atau A?• Jika T maka kembalikan data aplikasiappId jika memang milik T tersebut.

• Jika A maka kembalikan data aplikasiappId


38


3 POST / A Data apli-kasi (1)

Data apli-kasi (1)

1. Cari Node yang masih bisa diisi untuk apli-kasi baru sesuai jumlah Node yang diminta

2. Jika tersedia cukup jumlah Node• Lakukan pembuatan aplikasi baru• Panggil skrip create-app pada RootNode.

• Kembalikan data aplikasi yang sudahdiberi appId

4 PUT /appId A Data apli-kasi (1)

Data apli-kasi (1)

1. Ubah data aplikasi sesuai yang diminta2. Jika perlu melakukan pengubahan pada Ro-

ot Node• Panggil skrip modify-app pada RootNode.

3. Kembalikan data aplikasi hasil pengubahanKeterangan: T: Hak Akses Penyewa, A: Hak Akses Admin, (1) Data Tunggal, (n) Data Jamak

39


5POST /ap-pId /ope-ration

T Operasi - Penjelasan operasi pada aplikasi dapat dilihatpada Tabel 4.4

6 DELETE/appId

A - -1. Hapus data aplikasi2. Panggil skrip remove-app pada Root Node

dan Slave Node.Keterangan: T: Hak Akses Penyewa, A: Hak Akses Admin, (1) Data Tunggal, (n) Data Jamak

Tabel 4.4: Daftar Operasi pada Aplikasi

No Operasi Masukan Langkah Proses

1 start Menjalankan aplikasi padasemua Node

1. Untuk setiap Node yang menyimpan aplika-si tersebut

• Panggil skrip start-app.

40No Operasi Masukan Langkah Proses

2 stop Menghentikan aplikasi pa-da semua Node


• Panggil skrip stop-app.

3 statusAllNodeMengetahui status jalan-nya aplikasi pada semuaNode


• Panggil skrip status-app.• Kembalikan hasil pemanggilannya.

4 statusRootNode

Mengetahui status jalan-nya aplikasi pada Root No-de beserta penggunaan pe-nyimpanan dan status re-pository Git didalamnya.

1. Panggil skrip status-app pada Root No-de.

2. Kembalikan hasil pemanggilannya.

5 readLog Membaca berkas log seca-ra raw dari aplikasi.

1. Panggil skrip log-app untuk setiap Node.2. Kembalikan hasil pemanggilannya.

41


6 accessReportMengambil data access.logpada aplikasi untuk setiapNode.


• Panggil skrip log-app untuk berkasaccess.log.

• Kombinasikan hasilnya jadi satu.2. Analisa dan kembalikan hasilnya dalam

bentuk laporan HTML.

7 reloadLoad-Balancer

Memuat ulang data aplika-si pada load balancer agarbisa diakses.

1. Panggil skrip unregister-Backend padaload balancer.

2. Panggil skrip unregister-Frontend pa-da load balancer.

3. Panggil skrip register-Backend pada lo-ad balancer.

4. Panggil skrip register-Frontend padaload balancer.

4.2.1.4 Pengendali /dbsPengendali ini berfungsi untuk melakukan manipulasi data basis data dari setiap penyewa. Tabel 4.5menunjukan teknik implementasinya.

42Sama seperti /apps, pengendali ini juga memiliki rute khusus operasi yang daftarnya dapat dilihatpada Tabel 4.6.

Tabel 4.5: Implementasi Pengendali /dbs


1 GET / T-A -Databasis data(n)

1. Apakah pengguna T atau A?• Jika T maka kembalikan data basis da-ta milik T

• Jika A maka kembalikan semua databasis data

2 GET /dbId T-A -Databasis data(1)

1. Apakah pengguna T atau A?• Jika T maka kembalikan data basis da-ta dbId jika memang milik T tersebut.

• Jika Amaka kembalikan data basis da-ta dbId


43


3 POST / ADatabasis data(1)

Databasis data(1)

1. Lakukan pembuatan basis data baru2. Panggil skrip create-db pada Root Node.3. Kembalikan data basis data yang sudah di-

beri dbId

4 PUT /dbId ADatabasis data(1)

Databasis data(1)

1. Ubah data basis data sesuai yang diminta2. Jika perlu melakukan pengubahan pada Ro-

ot Node• Panggil skrip modify-db pada RootNode.

3. Kembalikan data basis data hasil pengubah-an

5POST /dbId/opera-tion

T Operasi - Penjelasan operasi pada basis data dapat dili-hat pada Tabel 4.6


44


6 DELETE/dbId

A - -1. Hapus data basis data2. Panggil skrip remove-db pada Root Node.


Tabel 4.6: Daftar Operasi pada Basis Data


1 start Menjalankan basis data pa-da Node 1. Panggil skrip start-db pada Node

2 stop Menghentikan basis data 1. Panggil skrip stop-db pada Node

3 status Mengetahui status jalan-nya basis data

1. Panggil skrip status-db.2. Kembalikan hasil pemanggilannya.

4 readLog Membaca berkas log seca-ra raw dari basis data.

1. Panggil skrip log-db2. Kembalikan hasil pemanggilannya.

45

4.2.1.5 Pengendali /nodesPengendali ini digunakan untuk memanipulasi data Node dan load balancer yang terdaftar pada sistem.Penjelasan implementasi pengendali terdapat pada tabel 4.7.

Tabel 4.7: Implementasi Pengendali /nodes


1 GET / A - Data No-de (n) 1. Kembalikan data semua Node

2 GET /node-Id

A - Data No-des (1) 1. Kembalikan data Node nodeId

3 POST / A Data No-de (1)

Data No-de (1)

1. Lakukan pembuatan Node baru2. Kembalikan data Node yang sudah diberi

nodeId

4 PUT /node-Id

A Data No-de (1)

Datanodes (1)

1. Ubah data Node sesuai yang diminta2. Kembalikan data Node hasil pengubahan


46


5 GET /node-Id/status

A -Data sta-tus Node(1)

1. Panggil kakas hoster-status-node pada No-de bersangkutan.

2. Kembalikan hasilnya ke klien

6GET /no-deId /log/logFile

A - Berkaslog

1. Panggil kakas hoster-log-node pada Nodebersangkutan.

2. Kembalikan hasilnya ke klienKeterangan: T: Hak Akses Penyewa, A: Hak Akses Admin, (1) Data Tunggal, (n) Data Jamak

4.2.1.6 Pengendali /billingsPengendali ini digunakan untuk memanipulasi data billing atau tagihan pemesanan yang dikirimkan olehpengguna dan yang terdaftar pada sistem. Penjelasan implementasi pengendali terdapat pada Tabel 4.8.

Tabel 4.8: Implementasi Pengendali /billing


1 GET / A - Databilling (n) 1. Kembalikan data semua billing


47


2 GET /node-Id

A - Databilling (1) 1. Kembalikan data billing nodeId

3GET /node-Id /extra-ct

A -DaftarOperasi(n)

1. Ambil data billing nodeId2. Kembalikan daftar operasi untuk menerapk-

an billing tersebut.

4 POST / T Databilling (1)

Databilling (1)

1. Lakukan pembuatan billing baru2. Kembalikan data billing yang sudah diberi

nodeId

5 PUT /node-Id

A Databilling (1)

Databilling (1)

1. Ubah data billing sesuai yang diminta2. Kembalikan data billing hasil pengubahan


4.2.2 Frontend ManagerFrontend Manager dibuat dalam entitas server Web terpisah dengan Backend. Bagian Frontend hanyamenghubungkan antarmuka pengguna (baik penyewa maupun administrator) dengan REST API padaBackend. Terdapat dua rute akses http pada Frontend, yaitu: halaman antarmuka aplikasi pada rute/admin (Antarmuka Administrator) dan /user (Antarmuka Penyewa) diatur melalui pengendali sisiklien menggunakan pustaka AngularJS. Sub-bab ini membahas mengenai implementasi peta situs dan

48pengendali pada antarmuka aplikasi.

4.2.2.1 Antarmuka AdministratorTabel 4.9menjelaskanmengenai implementasi peta situs (dari gambar 3.4) dari halaman antarmuka admi-nistrator pada Frontend dengan rute /admin serta keterkaitannya dengan halaman pada peta situs dankasus penggunaan (use case) yang diimplementasikan. Setiap implementasi memiliki sub-rute yang di-implementasikan menggunakan AngularJS. Akses ke halaman spesifik dapat dilakukan melalui akses ke/admin/#sub-rute melalui peramban Web klien.

Tabel 4.9: Implementasi Peta Situs pada Antarmuka Panel Administrator

No Halaman Sub-rute UseCase

NamaPengen-dali

Operasi

1 Ax / - dashboard -

2 A1 /billing UC09 billing

getBilling: Ambil data billing.setujuiBilling: Tandai billing sebagai disetu-jui.hapusBilling: Batalkan dan hapus billing.prosesBilling: Lakukan operasi untuk me-nerapkan billing (melalui rute Backend /bi-llings/billingId/extract).

49


NamaPengen-dali

Operasi

3 A2 / UC08 nodes

getNodes: Ambil data Node dan load balan-cer.addNode: Membuat Node atau load balancerbaru.editNode: Menyunting Node atau load balan-cer yang sudah ada.

4 A3 / UC10 monitor

getNodes: Ambil data Node dan load balan-cer.getNodesStatus: Ambil data rincian status pa-da Node atau load balancer tersebut.downloadLog: Ambil berkas log dari suatuNode atau load balancer.

4.2.2.2 Antarmuka PenyewaTabel 4.10 menjelaskan mengenai implementasi halaman antarmuka panel penyewa pada Frontend.

50Tabel 4.10: Implementasi Peta Situs pada Antarmuka Panel Penyewa


NamaPengen-dali

Operasi

1 Tx, T1,T2 / - dashboard -

2 T1a /apps/appId/scale

UC09 scaleAppscalculatePrice: menghitung harga scaling.sendBilling: mengirimkan data billing melaluirute Backend POST /billings.

3 T1c /apps/appId/upload

UC06 upload-Apps

getAppStatus: mengambil data keadaan ber-jalannya aplikasi. Digunakan untuk mengecekjumlah Node yang menjalankan aplikasi.

4 T3 /billing/order/app

UC01 billing-OrderApp

calculatePrice: menghitung harga pemesananaplikasi.sendBilling: mengirimkan data billing melaluirute Backend POST /billings.

51


NamaPengen-dali

Operasi

5 T1b /apps/appId/configure

UC04 configure-Apps

getAppData: mengambil data aplikasi yang di-atur.startApp: menjalankan aplikasi. Panggil ope-rasi start melalui rute Backend.stopApp: menghentikan aplikasi. Panggil ope-rasi stop melalui rute Backend.getAppStatus: mengambil data keadaan ber-jalannya aplikasi. Digunakan untuk mengecekjumlah Node yang menjalankan aplikasi.reloadLoadBalancer: memuat ulang load ba-lancer untuk aplikasi yang diatur. Panggil ope-rasi reloadLoadBalancer melalui rute Bac-kend.applyConfiguration: menerapkan pengaturanpada aplikasi.

52


NamaPengen-dali

Operasi

6 T1d /apps/appId/monitor

UC05 monitor-Apps

getAppData: mengambil data aplikasi yang di-atur.getNodeStatus: mengambil data keadaan ber-jalannya aplikasi. Digunakan untuk mengecekjumlah Node yang menjalankan aplikasi.downloadLog: membaca data log pada aplika-si.webServerReport: membaca rangkuman ak-ses (berkas log access.log) pada aplikasi.

7 T2a /dbs/dbId/scale

UC09 scaleDbscalculatePrice: menghitung harga scaling.sendBilling: mengirimkan data billing melaluirute Backend POST /billings.

8 T2c /dbs/dbId/console

UC06 upload-Dbs

sendCommand: mengirimkan perintah padakonsol basis data yang sedang berjalan.

53


NamaPengen-dali

Operasi

9 T2b /dbs/dbId/configure

UC04 configure-Dbs

getDbData: mengambil data basis data yangdiatur.startDb: menjalankan basis data. Panggil ope-rasi start melalui rute Backend.stopDb: menghentikan basis data. Panggiloperasi stop melalui rute Backend.getDbStatus: mengambil data keadaan berja-lannya basis data. Digunakan untuk mengecekjumlah Node yang menjalankan basis data.applyConfiguration: menerapkan pengaturanpada basis data.

10 T2d /dbs/dbId/monitor

UC05 monitor-Dbs

getDbData: mengambil data basis data yangdiatur.getNodeStatus: mengambil data keadaan ber-jalannya basis data. Digunakan untuk menge-cek jumlah Node yang menjalankan basis data.downloadLog: membaca data log pada basisdata.

54


NamaPengen-dali

Operasi

11 T4 /billing/order/db

UC01 billing-OrderDb

calculatePrice: menghitung harga pemesananbasis data.sendBilling: mengirimkan data billing melaluirute Backend POST /billings.

12 T5 /billing/history

UC01 billing-History

getBillings: mengambil data billing yang dimi-liki oleh pengguna.

55

4.3 Rincian Implementasi Load BalancerSubbab ini menjelaskan rincian implementasi sistem pada sisi loadbalancer.

4.3.1 Kakas PanggilTabel 4.11 menjelaskan implementasi kakas panggil pada load ba-lancer.

Tabel 4.11: Implementasi Kakas Panggil pada Load Balancer

No Kakas Argumen Proses

1 register-frontend

appId, do-mainName

Daftarkan appId sebagaifrontend pada berkas konfi-gurasi HAProxy dengan namadomain domainName.

2 register-backend

appId, ip-Node, port

Daftarkan alamat ipNo-de:port sebagai peer dariaplikasi appId pada konfigu-rasi HAProxy.

3 unregister-frontend appId

Menghapus definisi frontenduntuk aplikasi appId padakonfigurasi HAProxy

4 unregister-backend appId

Menghapus definisi backenduntuk aplikasi appId padakonfigurasi HAProxy

5 reload-proxy -

Memuat ulang HAProxy danmenerapkan konfigurasi ter-baru

4.4 Rincian Implementasi NodeSubbab inimenjelaskan rincian implementasi sistem pada sisi Node.

4.4.1 Citra Cakram DockerTabel 4.12 menjelaskan rincian citra cakram Docker yang dibangunbeserta aplikasi yang ada di dalamnya. Setiap citra cakram memi-

56

liki aturan khusus dalam proses penempatan berkas aplikasi untukmempermudah penyewa menempatkan berkas aplikasi agar sesuaidan bisa dijalankan.

Tabel 4.12: Rincian Implementasi Citra Cakram Docker pada Node

No Nama Layanan Penempatan Aplikasi

1 nodejs-nodemon

1. Nginx2. Node.js dan

npm3. Nodemon

Aplikasi utama harus ber-ada pada berkas app.jsdan berjalan pada port3000. Paket yang dibu-tuhkan didefinisikan padaberkas package.jsonuntuk kemudian dipa-sangkan pada saat prosesstart aplikasi.

2 php55-fpm

1. Nginx2. PHP 5.53. Modul php5-

fpm4. Composer

Aplikasi utama harusberada pada berkasindex.php. Paketyang dibutuhkan dide-finisikan pada berkascomposer.json untukkemudian dipasangkanpada saat proses startaplikasi menggunakancomposer

57

No Nama Layanan Penempatan Aplikasi

3 python27-gunicorn

1. Nginx2. Python 2.73. virtualenv4. Gunicorn

Nama pustaka utamaWSGI didefinisikanpada berkas gunicorn-args.txt. Paket yangdibutuhkan didefinisikanpada berkas require-ments.txt menggunakanformat pip. Paket akandipasang melalui virtu-alenv pada saat aplikasipertama kali dijalankan.

4 ruby19-thin

1. Nginx2. Ruby 1.93. Thin4. Bundle

Paket yang dibutuhkandidefinisikan pada berkasGemfile untuk dipasangmenggunakan perintahgem install pada saatmenjalankan aplikasipertama kalinya. Berkasconfig.ru akan menjadititik awal dari aplikasidan harus memuat mo-dul Bundler agar dapatmemuat paket yang di-letakkan pada direktorivendor/bundle.

5 mysql-single 1. MySQL 5.5 Bukan Citra untuk Aplikasi

Hampir semua komponen yang ada di dalam setiap citra cakrammenggunakan pengaturan bawaan dari upstream (pengaturan yangdisediakan oleh Ubuntu), kecuali pada pengaturan serverWeb ngi-nx yang diatur agar hanya memiliki satu worker (bawaannya ada

58

empat) dan MySQL yang menggunakanMyISAM agar menghematmemori.

4.4.2 Kakas Panggil NodeTabel 4.13 menjelaskan implementasi kakas panggil pada Node.

Tabel 4.13: Implementasi Kakas Panggil pada Node


1 start-app

appId,appType,memor-yLimit,rootNode

1. Apakah rootNode didefini-sikan?

• Jika iya, ambil data apli-kasi melalui git cloneatau git pull dari rootnode.

2. Jalankan aplikasi dari dataaplikasi melalui perintah doc-ker run dengan jenis citra se-suai appType

2 stop-app appId

1. Hentikan aplikasi dari dataaplikasi melalui perintah doc-ker rm.

3 create-app

appId, quo-ta

1. Buat direktori home untuk pe-nempatan aplikasi.

2. Atur quota pada direktori ter-sebut dengan perintah setqu-ota.

3. Buat direktori Git pertama pa-da aplikasi menggunakan per-intah git --bare init.

4 remove-app appId 1. Hapus direktori home dari

aplikasi beserta datanya.

59


5 status-app

appId, is-RootNode

1. Ambil data status aplikasi me-lalui perintah docker ins-pect.

2. Jika isRootNode di-set• Ambil data penggunaankuota diska menggunak-an perintah du.

• Ambil data status logGit melalui perintah gitlog.

6 log-app

appId, lo-gFile

1. Ambil berkas logFile mela-lui direktori log aplikasi yangsedang berjalan.

7 start-db

dbId,dbType, me-moryLimit

1. Jalankan basis data dari da-ta basis data melalui perintahdocker run dengan jenis ci-tra sesuai dbType

8 stop-db dbId

1. Hentikan basis data dari da-ta basis data melalui perintahdocker rm.

9 create-db dbId, quota

1. Buat direktori home untuk pe-nempatan basis data.

2. Atur quota pada direktori ter-sebut dengan perintah setqu-ota.

10 remove-db dbId 1. Hapus direktori home dari ba-

sis data beserta datanya.

60


11 status-db

dbId, isRo-otNode

1. Ambil data status basis da-ta melalui perintah dockerinspect.

2. Jika isRootNode di-set• Ambil data penggunaankuota diska menggunak-an perintah du.

12 log-db

dbId, lo-gFile

1. Ambil berkas logFile me-lalui direktori log basis datayang sedang berjalan.

BAB 5

PENGUJIAN DAN EVALUASI

5.1 Lingkungan Uji CobaLingkungan untuk pengujianmenggunakan lima komputer yang ter-diri dari: satu Manager, satu Load Balancer, tiga Node dan tigakomputer penguji. Manager terletak pada komputer sama yang di-gunakan pada implementasi, sementara Load Balancer dan tiga No-de berjalan di bawah VirtualBox versi 4.3 pada komputer tersebut.Sementara itu, tiga komputer penguji merupakan komputer fisikdi luar komputer yang dilakukan dalam proses implementasi. 5.1menggambarkan topologi jaringan dari masing-masing komputeryang digunakan dalam tahap pengujian.

Proses pengujian dilakukan di Laboratorium Arsitektur dan Ja-ringan Komputer (IF-307), Lantai tiga Gedung Teknik Informatika,ITS.

Gambar 5.1: Toplogi Jaringan dalam Pengujian

Spesifikasi perangkat lunak dan perangkat keras pada masing-masing komputer adalah sebagai berikut:

• Node– Perangkat Keras

* Virtualisasi VirtualBox 4.3

61

62

* Prosesor 2x CPU komputer Host* RAM 1024 MB* Hard Disk 8 GB

– Perangkat Lunak* Ubuntu Linux 14.04 LTS* Node.js 0.10* Docker 1.4.0* Git 1.8* OpenSSH

• Load Balancer– Perangkat Keras

* Virtualisasi VirtualBox 4.3* Prosesor 2x CPU komputer Host* RAM 256 MB* Hard Disk 8 GB

– Perangkat Lunak* Ubuntu Linux 14.04 LTS* Node.js 0.10* HAProxy* OpenSSH

• Penguji– Perangkat Keras

* Komputer Fisik* Prosesor Intel Pentium* RAM 2 GB* Hard Disk 250 GB

– Perangkat Lunak* Ubuntu Linux 14.04 LTS* Apache Benchmark* OpenSSH

Untuk menyambungkan seluruh komputer, dilakukan pengatur-an alamat IP sebagai berikut:

• Manager pada 192.168.56.1 (dan 10.151.36.39 jika diakses

63

dari luar).• Load Balancer pada 192.168.56.11 (dan 10.151.36.75 jika di-aksed dari luar).

• Node 1 pada 192.168.56.101.• Node 2 pada 192.168.56.102.• Node 3 pada 192.168.56.103.• Komputer Penguji 1 pada 10.151.36.27• Komputer Penguji 2 pada 10.151.36.34• Komputer Penguji 3 pada 10.151.36.40

5.2 Skenario Uji CobaSkenario uji coba dilakukan dalam beberapa tahap uji coba:

• Uji Unit Fungsionalitas digunakan untuk menguji berjalan-nya fungsionalitas REST API pada BackendManager apakahsesuai dengan yang diharapkan).

• Uji Kapasitas dilakukan untuk menguji berapa banyak apli-kasi dan basis data dari penyewa yang dapat dilayani oleh sis-tem pada spesifikasi pengujian di atas. Pengujian dilakukandengan membuat banyak aplikasi dan basis data dengan jenisplatform, jumlah node yang ditentukan secara acak.

• Uji Performa dilakukan untuk menguji bagaimana kecepat-an akses dari setiap aplikasi denganmelakukan simulasi aksesHTTP. Pengujian dilakukan dengan melakukan benchmarkpada aplikasi yang dibangun pada uji kapasitas.

Karena sifat acak yang ada pada uji kapasitas dan keterbatasan jum-lah Node yang disediakan, maka pengujian kapasitas serta performadilakukan sebanyak lima kali untuk bisa melihat lebih lanjut meng-enai korelasi antara pemilihan jenis platform, jumlah memori danjumlah Node dengan performa akses aplikasi bersangkutan.

5.2.1 Uji Unit FungsionalitasUji unit dilakukan dengan melakukan uji coba request HTTP keREST API pada Backend Manager untuk beberapa pengendali da-sar pada Backend dan meninjau apakah nilai yang dikembalikan se-

64

suai dengan yang diharapkan . Tabel 5.1 menunjukkan rancangansetiap aksi uji unit dan hasil atau nilai yang diharapkan. Implemen-tasi uji unit dibuat menggunakan pustaka jasmine-node (https://github.com/mhevery/jasmine-node) berbasis Javascript.

Tabel 5.1: Implementasi Uji Unit

No Pengendali Uji Coba Hasil Harapan

1 /authMengambil token untukakun administrator

Token didapatk-an

Mengambil data /usersmelalui token untuk admi-nistrator

Tidak ada peno-lakan token

Mengambil data /usersmelalui token yang salah

Ada penolakantoken

Mengambil token untukakun pengguna biasa /penyewa

Token didapatk-an

Mengambil data /usersmelalui token untuk peng-guna

Ada penolakantoken

2 /usersMendaftarkan penggunake sistem

Mendapatkanidentitas peng-guna

Mendapatkan token daripengguna baru

Token didapatk-an

Dapat melihat datapengguna melalui rute/users/userId

Data didapatkan

Dapat mengubah kata san-di -

Dapat mendapatkan tokendari pengguna dengan katasandi baru

Token didapatk-an

https://github.com/mhevery/jasmine-node

https://github.com/mhevery/jasmine-node

65


3 /appsMelakukan login sebagaipengguna

Mendapatkantoken pengguna

Melakukan pemesananaplikasi baru ke billing(dengan 1 Node, RAM64 MB, ruang cakram 50MB)

Mendapatkanidentitas billing

Melakukan login sebagaiadmin

Mendapatkantoken admin

Menyetujui pemesananaplikasi baru -

Mendapatkan extractdari billing

Mendapatkandata extract

Melakukan operasiextract untuk membuataplikasi baru

Mendapatkanidentitas aplikasidan alamat cloneGIT

Mendapatkan status apli-kasi sebelum dijalankan

Mendapatkanstatus aplikasibelum berjalan

Melakukan git clonepada alamat gitAddress Tidak ada galat

Melakukan pengisian dataaplikasi, lalu git com-mit dan git push ke ro-ot-Node

Tidak ada galat

Menjalankan aplikasi Tidak ada galat

Mendapatkan status apli-kasi setelah dijalankan

Mendapatkanstatus aplikasiberjalan padasatu Node

66

No Pengendali Uji Coba Hasil HarapanMelakukan operasi relo-adLoadBalancer padaaplikasi

Tidak ada galat

Menghentikan aplikasi Tidak ada galatMelakukan pemesananmeningkatkan aplikasi kebilling (ditingkatkan ketiga Node, RAM 128 MB,ruang cakram 200 MB)

MendapatkanbillingId

Menyetujui pemesanan pe-ningkatan aplikasi -


Mendapatkanextract

Melakukan operasiextract untuk mening-katkan aplikasi

Komponen yangditingkatkan su-dah diterapkan

Menjalankan aplikasi de-ngan tiga Node Tidak ada galat


Mendapatkanstatus aplikasiberjalan padatiga Node

4 /dbsMelakukan login sebagaipengguna

Mendapatkantoken pengguna

Melakukan pemesanan ba-sis data baru ke billing (de-ngan RAM 64 MB, ruangcakram 100 MB)

Mendapatkanidentitas billing

Melakukan login sebagaiadmin


Menyetujui pemesanan ba-sis data baru -

67

No Pengendali Uji Coba Hasil HarapanMendapatkan extractdari billing

Mendapatkanextract

Melakukan operasiextract untuk membuatbasis data baru

Mendapatkanidentitas basisdata

Mendapatkan status basisdata sebelum dijalankan

Mendapatkanstatus basis databelum berjalan

Menjalankan basis data Tidak ada galatMengisi data contoh padabasis data Tidak ada galat

Mendapatkan status basisdata setelah dijalankan

Mendapatkanstatus basis databerjalan

Menghentikan basis data Tidak ada galatMelakukan pemesananmeningkatkan basis datake billing (ditingkatkanke RAM 128 MB, ruangcakram 200 MB)

MendapatkanbillingId

Menyetujui pemesanan pe-ningkatan basis data -


Mendapatkanextract

Melakukan operasiextract untuk mening-katkan basis data

Komponen yangditingkatkan su-dah diterapkan

Menjalankan basis data Tidak ada galat


Mendapatkanstatus basis databerjalan

68


5 /nodesMelakukan login sebagaiadministrator


Melakukan penambahanNode

MendapatkannodeId

Mengubah data pada Node Data terubah

5.2.2 Uji KapasitasUji kapasitas dilakukan secara otomatis menggunakan skrip. Beri-kut adalah langkah-langkah dalam proses pengujian ini untuk setiappercobaannya:

1. Membuat lima akun penyewa secara acak2. Pada akun penyewa tersebut, dilakukan pembuatan aplikasi

atau basis data (atau kombinasi keduanya) baru dengan jum-lah Node (khusus aplikasi), jumlah platform (ada empat pilih-an),dan jumlah memori (antara 64 MB, 96 MB atau 128 MB)secara acak. Jumlah ruang penyimpanan ditetapkan menjadi128 MB.

3. Jika pembuatan berhasil, ulang langkah pertama. Jika pembu-atan gagal karena ketidak cukupan jumlah Node dan jumlahNode dari aplikasi tersebut berjumlah satu, akhiri pengujian.

Setiap entitas aplikasi dan basis data akan diberi sebuah datacontoh yang sudah disiapkan sebelumnya. Setelah pengujian ber-langsung, dilakukan proses merangkum daftar aplikasi yang berjal-an pada setiap Node untuk kemudian diuji pada uji performa.

5.2.3 Uji PerformaUji performa dilakukan pada aplikasi yang sudah ditambahkan me-lalui uji kapasitas pada setiap percobaan. Perangkat lunak yangdigunakan dalam pengujian adalah Apache Benchmark (http://httpd.apache.org/docs/2.2/programs/ab.html).

Pengujian dilakukan secara bersamaan untuk semua aplikasi danbasis data yang dibuat dalam satu percobaan. Metode benchmarkdilakukan melalui empat komputer penguji dengan mengirimkan

http://httpd.apache.org/docs/2.2/programs/ab.html

http://httpd.apache.org/docs/2.2/programs/ab.html

69

akses permintaan HTTP sebanyak 500 kali dalam 50 socket secarabersamaan. Hasil pengujian di setiap komputer uji diolah menjadisatu untuk kemudian dilaporkan dalam bentuk tabel.

5.2.4 Aplikasi ContohTerdapat dua jenis aplikasi contoh yang dibuat untuk kebutuhan pe-ngujian performa:

• Dengan Basis Data, merupakan aplikasi contoh yang terhu-bung dengan suatu server MySQL yang berbeda antara satusama lain.

• Tanpa Basis Data, merupakan aplikasi contoh yang hanyamembaca data JSON yang terletak di berkas server.

Pembedaan antara kedua jenis tersebut dimaksudkan karena pem-batasan kemampuan penyewaan MySQL yang hanya maksimumterdiri dari satu Node sementara perlu adanya pengujian performamurni aplikasi jika hanya dijalankan pada lebih dari satu Node.

Aplikasi contoh hanya melayani satu rute GET dan menampilk-an data berupa JSON tanpa menggunakan templat HTML atau CSS.

5.2.5 Basis Data ContohBasis data contoh terdiri dari sebuah basis data MySQL yang ber-isikan sebuah tabel (bernama test) yang berisikan tiga kolom se-bagai berikut:

• Kolom id berisi nomor yang diisi otomatis oleh MySQL.• Kolom val berisi sebuah kalimat acak yang diambil dari Lo-rem Ipsum.

• Kolom description berisi sebuah paragraf acak yang di-ambil dari Lorem Ipsum.

5.3 Hasil Uji Coba dan EvaluasiBerikut dijelaskan mengenai hasil pengujian yang dilakukan padatiga skenario pengujian yang telah ditentukan.

70

5.3.1 Uji Unit FungsionalitasHasil uji unit fungsionalitas dijelaskan pada tabel 5.2 berikut. Con-toh tangkapan layar dari hasil uji unit pengendali /apps dan /dbsdapat dilihat pada 5.2 dan 5.3.

Tabel 5.2: Hasil Eksekusi Uji Unit Fungsionalitas

No Pengendali Uji Coba Hasil

1 /authMengambil token untukakun administrator Sukses - 17 ms

Mengambil data /usersmelalui token untuk admi-nistrator

Sukses - 13 ms

Mengambil data /usersmelalui token yang salah Sukses - 12 ms

Mengambil token untukakun pengguna biasa /penyewa

Sukses - 85 ms

Mengambil data /usersmelalui token untuk peng-guna

Sukses - 11 ms

2 /usersMendaftarkan penggunake sistem Sukses - 104 ms

Mendapatkan token daripengguna baru Sukses - 84 ms

Dapat melihat datapengguna melalui rute/users/userId

Sukses - 13 ms

Dapat mengubah kata san-di Sukses - 82 ms

Dapat mendapatkan tokendari pengguna dengan katasandi baru

Sukses - 83 ms

71

No Pengendali Uji Coba Hasil

3 /appsMelakukan login sebagaipengguna Sukses - 150 ms

Melakukan pemesananaplikasi baru ke billing(dengan 1 node, RAM64 MB, ruang cakram 50MB)

Sukses - 36 ms

Melakukan login sebagaiadmin Sukses - 12 ms

Menyetujui pemesananaplikasi baru Sukses - 13 ms

Mendapatkan extractdari billing Sukses - 12 ms

Melakukan operasiextract untuk membuataplikasi baru

Sukses - 917 ms

Mendapatkan status apli-kasi sebelum dijalankan Sukses - 526 ms

Melakukan git clonepada alamat gitAddress Sukses - 494 ms

Melakukan pengisian dataaplikasi, lalu git commitdan git push ke root no-de

Sukses - 1.000ms

Menjalankan aplikasi Sukses - 905 msMendapatkan status apli-kasi setelah dijalankan Sukses - 945 ms

Melakukan operasi relo-adLoadBalancer padaaplikasi

Sukses - 2.361ms

Menghentikan aplikasi Sukses - 1.263ms

72

No Pengendali Uji Coba HasilMelakukan pemesananmeningkatkan aplikasi kebilling (ditingkatkan ke3 node, RAM 128 MB,ruang cakram 200 MB)

Sukses - 12 ms

Menyetujui pemesanan pe-ningkatan aplikasi Sukses - 11 ms


Melakukan operasiextract untuk mening-katkan aplikasi

Sukses - 3.546ms

Menjalankan aplikasi de-ngan 3 node

Sukses - 1.740ms


Sukses - 4.763ms

4 /dbsMelakukan login sebagaipengguna Sukses - 124 ms

Melakukan pemesanan ba-sis data baru ke billing (de-ngan RAM 64 MB, ruangcakram 100 MB)

Sukses - 34 ms

Melakukan login sebagaiadmin Sukses - 11 ms

Menyetujui pemesanan ba-sis data baru Sukses - 12 ms


Melakukan operasiextract untuk membuatbasis data baru

Sukses - 664 ms

73

No Pengendali Uji Coba HasilMendapatkan status basisdata sebelum dijalankan Sukses - 449 ms

Menjalankan basis data Sukses - 10.893ms

Mengisi data contoh padabasis data Sukses - 745 ms


Sukses - 1.103ms

Menghentikan basis data Sukses - 630 msMelakukan pemesananmeningkatkan basis datake billing (ditingkatkanke RAM 128 MB, ruangcakram 200 MB)

Sukses - 21 ms

Menyetujui pemesanan pe-ningkatan basis data Sukses - 13 ms


Melakukan operasiextract untuk mening-katkan basis data

Sukses - 483 ms

Menjalankan basis data Sukses - 10.903ms

Mendapatkan status basisdata setelah dijalankan Sukses - 481 ms

5 /nodesMelakukan login sebagaiadmin Sukses - 56 ms

Melakukan penambahannode Sukses - 18 ms

Mengubah data pada node Sukses - 13 ms

Pada hasil uji coba fungsionalitas tersebut, didapatkan bahwa

74

Gambar 5.2: Tangkapan Layar jasmine-node dalamMelakukanUjiUnit pengendali /apps

Gambar 5.3: Tangkapan Layar jasmine-node dalamMelakukanUjiUnit Pengendali /dbs

75

Backend pada Manager sudah mengimplementasikan keseluruhanfungsionalitas dengan baik sesuai dengan yang diharapkan. Sebagi-an besar aksi yang dilakukan pada Backend dapat dilakukan denganwaktu dibawah 100 ms.

Namun, ada beberapa aksi yang memerlukan waktu hingga be-berapa detik terutama pada aksi yang membutuhkan pemanggilanskrip panggil pada node atau load balaner seperti pada pembuatanaplikasi/basis data, memulai aplikasi/basis data, memroses opera-si reloadLoadBalancer, dan beberapa aksi lainnya. Lamanyaakses pada rute ini bergantung pada kecepatan dari masing-masingnode untuk memproses aksi tersebut.

5.3.2 Uji Kapasitas dan PerformaUji kapasitas pada setiap kali percobaan rata-rata berlangsung seki-tar 8 - 15 menit. Sebelum pengujian dilakukan (dalam keadaan No-de baru dalam keadaan dihidupkan), masing-masing Node menggu-nakan memori sebanyak 50 MB dan penggunaan CPU yang cende-rung idle 0%. Sementara setelah pengujian dilakukan, penggunaanmemori RAM rata-rata mencapai 650 - 800 MB dengan pengguna-an CPU yang sekitar 10 - 15% pada masing-masing Node. Contohtampilan aplikasi htop sebelum dan sesudah uji pecobaan satu da-pat dilihat pada 5.4 dan 5.5. Sementara ketika uji performa berlang-sung, Node dan Load Balancer mengalami peningkatan penggunaanCPU mencapai 100% seperti pada Gambar 5.6.

Rata-rata jumlah aplikasi yang dapat tertampung pada setiappercobaan adalah sebanyak 15-20 aplikasi dengan jumlah Node danpenggunaan memori masing-masing aplikasi yang sangat bervari-asi. Daftar aplikasi dan hasil uji performa pada setiap percobaandapat dilihat pada tabel 5.3.

76

Gambar 5.4: Keadaan Node dan Load Balancer SEBELUMUji Ka-pasitas Percobaan Pertama Dilakukan (Komputer dalam KeadaanBaru Dihidupkan)

Gambar 5.5: Keadaan Node dan Load Balancer SETELAH Uji Ka-pasitas Percobaan Pertama Dilakukan

77

Tabel 5.3: Daftar Aplikasi pada Uji Kapasitas Dengan Hasil Uji Performa

No Nama Platform Node MemApp DB MemDb Uji Performa (Akses HTTP)

Sukses Halaman/s Keter-sediaan

Percobaan ke-1

1 benton php55-fpm 1 64 MB Tidak - 536 30 36%

2 dayton python27-gunicorn 1 96 MB Tidak - 756 31 50%

3 braulio python27-gunicorn 1 96 MB Ya 96 MB 616 33 41%

4 junius php55-fpm 1 128 MB Tidak - 580 30 39%

5 denis nodejs-nodemon 1 128 MB Tidak - 573 31 38%

6 romaine python27-gunicorn 3 64 MB Ya 64 MB 1499 36 100%

7 brett python27-gunicorn 2 64 MB Ya 64 MB 1131 30 75%

78



8 monserrat nodejs-nodemon 2 96 MB Ya 64 MB 593 30 40%

9 liliana nodejs-nodemon 2 128 MB Tidak - 1349 31 90%

10 ezequiel ruby19-thin 2 96 MB Ya 128 MB 1195 33 80%

11 brice python27-gunicorn 2 96 MB Tidak - 914 47 61%

12 paula python27-gunicorn 1 128 MB Tidak - 792 30 53%

13 stevie ruby19-thin 1 64 MB Ya 128 MB 685 30 46%

14 paris php55-fpm 1 96 MB Ya 64 MB 493 30 33%

Percobaan ke-2

15 marjory ruby19-thin 1 128 MB Tidak - 1490 30 99%

79



16 laurence python27-gunicorn 1 96 MB Tidak - 778 30 52%

17 tito php55-fpm 1 96 MB Tidak - 577 30 38%

18 joany python27-gunicorn 1 64 MB Tidak - 990 30 66%

19 norbert python27-gunicorn 2 96 MB Ya 128 MB 1500 30 100%

20 buster ruby19-thin 3 128 MB Tidak - 1500 39 100%

21 terrill python27-gunicorn 3 96 MB Ya 64 MB 1499 38 100%

22 jordane ruby19-thin 2 96 MB Ya 128 MB 1500 33 100%

23 earl python27-gunicorn 2 128 MB Tidak - 1500 34 100%

24 bertha php55-fpm 2 96 MB Ya 96 MB 824 30 55%

80



25 fanny python27-gunicorn 1 64 MB Ya 128 MB 758 30 51%

26 adriel nodejs-nodemon 1 128 MB Tidak - 701 30 47%

Percobaan ke-3

27 santino python27-gunicorn 1 64 MB Tidak - 1207 15 80%

28 corine python27-gunicorn 1 96 MB Tidak - 1033 17 69%

29 zander python27-gunicorn 1 128 MB Ya 96 MB 1500 18 100%

30 nickolas python27-gunicorn 1 64 MB Ya 64 MB 1500 18 100%

31 lesley python27-gunicorn 1 128 MB Tidak - 788 18 53%

32 linwood php55-fpm 1 128 MB Tidak - 1500 18 100%

81



33 kylie python27-gunicorn 1 64 MB Tidak - 1500 18 100%

34 aditya ruby19-thin 1 128 MB Tidak - 1500 18 100%

35 elliot nodejs-nodemon 2 128 MB Ya 128 MB 228 23 15%

36 alba php55-fpm 2 96 MB Ya 96 MB 95 18 6%

37 elody ruby19-thin 2 128 MB Ya 96 MB 1500 18 100%

38 kay ruby19-thin 2 64 MB Ya 128 MB 1500 18 100%

39 vince ruby19-thin 1 64 MB Tidak - 1239 18 83%

40 bethany ruby19-thin 1 128 MB Ya 64 MB 743 18 50%

41 demarco php55-fpm 1 64 MB Ya 64 MB 559 17 37%

82



Percobaan ke-4

42 charley python27-gunicorn 1 96 MB Ya 64 MB 691 27 46%

43 yasmine python27-gunicorn 1 64 MB Tidak - 741 30 49%

44 ethan nodejs-nodemon 1 96 MB Ya 96 MB 338 27 23%

45 cullen php55-fpm 1 64 MB Tidak - 542 27 36%

46 caesar python27-gunicorn 1 128 MB Tidak - 678 29 45%

47 jovani python27-gunicorn 3 64 MB Tidak - 1500 33 100%

48 gordon python27-gunicorn 2 96 MB Tidak - 1438 29 96%

49 charlie nodejs-nodemon 2 96 MB Tidak - 1273 28 85%

83



50 marquise php55-fpm 1 64 MB Tidak - 513 27 34%

51 camylle python27-gunicorn 3 64 MB Ya 128 MB 1000 26 67%

52 lavon nodejs-nodemon 1 64 MB Tidak - 761 27 51%

53 dusty python27-gunicorn 2 96 MB Tidak - 852 21 57%

54 katelyn php55-fpm 1 96 MB Tidak - 578 27 39%

55 myrl nodejs-nodemon 2 96 MB Ya 64 MB 294 24 20%

56 charles php55-fpm 1 128 MB Tidak - 380 19 25%

57 vena ruby19-thin 1 96 MB Tidak - 841 18 56%

58 joe nodejs-nodemon 1 96 MB Tidak - 494 19 33%

84



59 vanessa ruby19-thin 1 64 MB Ya 64 MB 653 19 44%

Percobaan ke-5

60 cole nodejs-nodemon 1 128 MB Tidak - 621 42 41%

61 keyshawn nodejs-nodemon 1 96 MB Ya 64 MB 231 51 15%

62 queenie python27-gunicorn 1 96 MB Tidak - 785 38 52%

63 randi php55-fpm 2 128 MB Tidak - 1061 42 71%

64 peter python27-gunicorn 1 128 MB Ya 128 MB 758 39 51%

65 elliott ruby19-thin 3 64 MB Ya 96 MB 1499 51 100%

66 emilia ruby19-thin 3 128 MB Tidak - 1500 63 100%

85



67 darrion ruby19-thin 1 128 MB Tidak - 897 40 60%

68 hiram nodejs-nodemon 2 96 MB Ya 128 MB 409 39 27%

69 brice ruby19-thin 1 64 MB Ya 96 MB 724 39 48%

70 tod ruby19-thin 1 128 MB Ya 96 MB 736 35 49%

71 elza php55-fpm 1 64 MB Ya 64 MB 235 57 16%

72 electa ruby19-thin 1 96 MB Ya 64 MB 750 36 50%

86

Gambar 5.6: Keadaan Node dan Load Balancer Ketika Sedang UjiPerforma

Sebagai informasi, akses "Sukses" dihitung dari jumlah permin-taan HTTP yang menghasilkan respons 200 (berhasil tanpa galat).Sementara ketersediaan atau availability dihitung berdasarkan per-sentase "Sukses" terhadap jumlah semua permintaan HTTP ke apli-kasi (500 x 3 penguji = 1500 permintaan).

Secara umum, performa akses pada aplikasi yangmemiliki jum-lah Node lebih banyak cenderung lebih baik. Beberapa aplikasibisa mendapatkan indeks ketersediaan hingga 90% - 100%. Na-mun demikian, faktor platform juga menentukan bagaimana perfor-ma aplikasi dapat berjalan. Beberapa platform seperti php55-fpmdan nodejs-nodemon cenderung memiliki ketersediaan lebih ren-

87

dah karena pengaturan bawaan dari kedua platform tersebut mung-kin belum mengakomodasi sistem aplikasi Web berperforma tinggiyang bisa berjalan pada lingkungan Docker.

Aplikasi yang menggunakan basis data MySQL cenderung me-miliki ketersediaan yang lebih rendah dibandingkan aplikasi tanpabasis data. Hal ini memang sesuai eksepektasi karena keterbatasankemampuan MySQL yang hanya bisa berjalan pada satu Node padalingkungan sistem untuk saat ini. Namun demikian, ada beberapaaplikasi dengan basis data yang mampu mendapatkan ketersediaanmelebihi 60% terutama pada aplikasi yang memiliki jumlah Nodelebih dari satu.

Kecepatan akses halaman dalam satuan halaman per detik (ha-laman/s) cenderung bervariasi untuk setiap percobaan. Pada satupercobaan, kecepatan akses ada di kisaran (40 - 60) sedangkan pa-da percobaan lain, kecepatan tidak ada yang mencapai lebih dari30 halaman/s. Kemungkinan penyebab dari adanya variasi kece-patan adalah karena pengujian dilakukan menggunakan komputerfisik terpisah sehingga kemungkinan ada pengaruh keadaan jaring-an (misalnya penumpukan paket pada switch atau router) pada saatuji coba dijalankan.

5.3.3 Implementasi Prinsip Komputasi AwanPada sub-bab berikut, dijelaskanmengenai bagaimana beberapa prin-sip komputasi awan yang dipaparkan dalam rumusan masalah dapatdiimplementasi di dalam sistem.

5.3.3.1 On-Demand Self-ServicePrinsipOn-Demand Self-Service yang menurut definisi NIST me-mungkinkan pelanggan atau penyewa dapat menetapkan kemampu-an komputasinya tanpa perlu interaksi manusia ke penyedia layan-an, diimplementasikan pada sistem melalui adanya panel kontroldari sisi administrator dan penyewa agar mereka dapat mengaturdan mengelola aplikasi dan basis data beserta penggunaan sumberdaya yang digunakannya. Panel kontrol di sisi Manager dapat ber-

88

komunikasi secara otomatis ke setiap Node dan Load Balancer se-suai permintaan yang ada dari sisi pengguna.

Namun demikian, fitur penagihan atau billing yang ada pada sis-tem terimplementasi masih bersifat tradisional yang membutuhkanperan serta administrator untuk menyetujui setiap pesanan (wala-upun admin tidak perlu melakukan banyak hal untuk menyiapkansistem) serta peran penyewa memerlukan inisiasi terlebih dahuluketika aplikasi atau basis data mereka perlu ditingkatkan kemam-puannya (melalui antarmuka seperti pada Gambar 5.7).

Gambar 5.7: Antarmuka untuk Scaling atau Peningkatan KapasitasAplikasi pada Sistem Terimplementasi.

Penagihan adalah salah satu bagian sistem yang bisa dikem-bangkan lebih lanjut sehingga benar-benar bebas dari interakasi ma-nusia, misalnya dengan menggunakan konsep pembayaran berbasis

89

kredit atau poin yang bisa ditagihkan setiap kali aplikasi dan basisdata miliki penyewa membutuhkan kemampuan sistem lebih lanjut.Jika sistem akan dikembangkan ke arah tersebut, maka perlu ada-nya komponen evaluator yang bisa menilai apakah suatu aplikasidari penyewa perlu ditingkatkan kapasitasnya ketika terjadi bebanakses, dan kemudian dapat melakukan pengaturan scaling secaraotomatis seperti pada prinsip Rapid elasticity.

5.3.3.2 Resource-PoolingKonsep Resource-Pooling pada sistem dapat terlihat dari kemam-puan sistem untuk menjalankan banyak aplikasi dan basis data padasejumlah Node yang disediakan. Penggunaan Docker untuk mela-kukan virtualisasi di setiap aplikasi memungkinkan banyak prosesaplikasi berjalan pada sistem dengan menggunakan kernel yang sa-ma, namun dengan tetap menjaga transparansi sistem antara satusama lain. Gambar 5.8 memperlihatkan banyaknya proses di da-lam Docker yang untuk semua aplikasi dan basis data pada sebuahNode.

Banyaknya aplikasi di dalam Node tidak serta merta membuatperforma salah satu atau beberapa aplikasi menjadi turun. Sesuaidengan hasil uji performa yang mendapatkan beberapa aplikasi bi-sa tersedia 100% selama di-benchmark bersamaan dengan aplika-si lainnya. Walaupun demikian, perlu adanya tinjauan lebih lanjutmengenai konfigurasi citra cakramDocker dengan pengaturan yangsesuai agar aplikasi dan basis data yang berjalan memiliki indeksketersediaan semaksimal mungkin.

5.3.3.3 Measured ServiceSifat layanan terukur pada sistem dapat dilihat dari adanya pene-kanan pada pengaturan kapasitas jumlah Node, jumlah memori danjumlah penggunakan cakram penyimpanan pada setiap aplikasi ataubasis data yang ada pada penyewa. Sistem memiliki fitur untuk me-lakukan pemantauan terhadap penggunaan ketiga komponen terse-but serta fitur untuk memantau penggunaan aplikasi Web itu sendi-

90

Gambar 5.8: Hasil dari Perintah docker ps yang MenampilkanDaftar Kontainer Docker yang Berjalan untuk Mengakomodir Ba-nyaknya Aplikasi dan Basis Data pada Suatu Node

91

ri dalam bentuk laporan (seperti pada Gambar 5.9, 5.10 dan 5.11)yang dapat memberikan pengetahuan kepada pelanggan mengenaibagaimana aplikasi mereka diakses oleh klien.

Gambar 5.9: Antarmuka Pemantauan Sebuah Aplikasi SecaraUmum, Dapat Dilihat Penggunaan Memori dan Cakram Penyim-panan pada Berjalannya Aplikasi Bersangkutan

92

Gambar 5.10: Antarmuka Pemantauan Rangkuman Akses HTTPpada Aplikasi

Gambar 5.11: Antarmuka Pemantauan Penggunaan PenyeimbangMuat pada Aplikasi (melalui antarmuka stats dari HAProxy)

BAB 6

PENUTUP

Bab ini membahas kesimpulan yang dapat diambil dari tujuan pem-buatan sistem dan hubungannya terhadap hasil uji coba yang telahdilakukan. Selain itu, terdapat beberapa saran yang bisa dijadik-an acuan untuk melakukan pengembangan dan penelitian terhadapsistem lebih lanjut.

6.1 KesimpulanDari proses perancangan, implementasi dan pengujian yang dila-kukan terhadap sistem, dapat diambil beberapa kesimpulan sebagaiberikut :

1. Sistem Platform-as-a-Service untuk kebutuhan pengembang-an aplikasi dan Web hosting berbasis multi-tenancy dapat di-implementasikan menggunakan berbagai kombinasi kerang-ka kerja yaitu pemrograman berbasis Node.js dan virtualisa-si berbasis Docker. Sistem telah dikembangkan sesuai fituryang dirancang meliputi dukunganmulti-platform, dukunganuntuk peningkatan atau scaling sumber daya komputasi ser-ta fitur pemantauan terhadap berjalannya aplikasi atau basisdata dari masing-masing penyewa atau tenant. Fitur terse-but telah teruji menggunakan ujit unit fungsionalitas serta ujikapasitas dan performa.

2. Rata-rata jumlah aplikasi yang dapat tertampung pada konfi-gurasi tiga Node dengan masing-masing memori 1 GB adalahsekitar 12 - 18 aplikasi tergantung dari konfigurasi aplika-si. Secara umum, aplikasi dengan jumlah Node lebih banyakmemiliki ketersediaan paling tinggi hingga 100%, sementaraaplikasi dengan basis data memiliki kecenderungan keterse-diaan yang lebih rendah daripada aplikasi yang tidak terko-neksi basis data sama sekali.

3. Prinsip komputasi awan yaitu self-service, resource-poolingdan measured service dapat diimplementasikan dengan baik

93

94

pada sistem melalui sistem layanan pengelolaan Load Balan-cer dan Node secara otomatis, sistem pembagian manajemensumber daya melalui virtualisasi berbasis Docker dan pengu-kuran layanan berbasis jumlah Node, jumlah memori RAMdan jumlah ruang cakram penyimpanan untuk setiap aplikasidan basis data yang dimiliki oleh penyewa.

6.2 SaranBerikut adalah beberapa saran-saran yang diberikan untuk pengem-bangan lebih lanjut :

• Perlu adanya penelitian lebih lanjut dari sisi ekonomi meng-enai adanya layanan semacam ini apakah dapat diaplikasikandalam dunia nyata.

• Penggunaan Docker untuk menjalankan proses server Webdan basis data perlu diteliti lebih lanjut dalam hal konfigurasiyang cocok sehingga bisa menjalankan aplikasi Web penggu-na dengan efisien dan handal.

• Perlu adanya penelitian lebih lanjut mengenai penggunaanbasis data dengan sistem multi-node sehingga bisa memak-simalkan luaran kecepatan akses basis data pada sistem ini.

• Perlu adanya peningkatan pada sistem penagihan secara oto-matis misalnya dengan mekanisme poin dan kredit sehinggaproses yang membutuhkan otorisasi biaya seperti scaling danpembuatan aplikasi baru dapat dilakukan secara otomatis tan-pa memerlukan persetujuan dari administrator.

DAFTAR PUSTAKA

[1] Gregory Go, 7 types of Web Hosting, [Online],http://onlinebusiness.about.com/od/webhosting/tp/web-hosting-types.htm, diakses tanggal 18 Septem-ber 2014

[2] DewaWeb, Cloud Hosting for Personal, [Online], http://www.dewaweb.com/cloud-hosting-for-personal/, di-akses tanggal 22 September 2014

[3] DeDoHo, Cloud Hosting, [Online], https://www.dedoho.pw/hosting/cloud-hosting/, diakses tanggal 22 Septem-ber 2014

[4] Cloud Kilat, Kilat Hosting, [Online], http://www.cloudkilat.com/harga/kilat-hosting, diakses tanggal22 September 2014

[5] OpenShift Developer, OpenShift's Features, [Onli-ne], https://developers.openshift.com/en/overview-platform-features.html, diakses tanggal 22September 2014

[6] Heroku, Heroku's Features, [Online], https://www.heroku.com/features, diakses tanggal 22 September 2014

[7] cPanel, Full feature list, [Online], http://cpanel.net/cpanel-whm/full-feature-list/, diakses tanggal 22September 2014

[8] Yashpalsinh Jadeja, Kirit Modi, Cloud Computing - Con-cepts, Architecture and Challenges, 2012 International Con-frence on Computing, Electronics and Electrical Technologies[ICCEET], published by IEEE, pp 887-880, 2012

95

http://onlinebusiness.about.com/od/webhosting/tp/web-hosting-types.htm

http://onlinebusiness.about.com/od/webhosting/tp/web-hosting-types.htm

http://www.dewaweb.com/cloud-hosting-for-personal/

http://www.dewaweb.com/cloud-hosting-for-personal/

https://www.dedoho.pw/hosting/cloud-hosting/

https://www.dedoho.pw/hosting/cloud-hosting/

http://www.cloudkilat.com/harga/kilat-hosting

http://www.cloudkilat.com/harga/kilat-hosting

https://developers.openshift.com/en/overview-platform-features.html

https://developers.openshift.com/en/overview-platform-features.html

https://www.heroku.com/features

https://www.heroku.com/features

http://cpanel.net/cpanel-whm/full-feature-list/

http://cpanel.net/cpanel-whm/full-feature-list/

96

[9] National Institute of Standards and Technology, TheNIST Definition of Cloud Computing, [Online],http://csrc.nist.gov/publications/nistpubs/800-145/SP800-145.pdf, diakses tanggal 22 September2014.

[10] Guillermo Rauch, Smashing Node.js: JavaScript Ever-ywhere, Wiley, First Edition, 2012

[11] Joyent, inc. node.js, [Online], http://www.nodejs.org/,Diakses tanggal 2 Desember 2014

[12] Stefan Tilkov, Steve Vinoski, Node.js: Using JavaScript toBuild High-Perfomace Network Programs, IEEE ComputerSociety Issue 06, Nov-Dec 2010, pp 80-83, 2010

[13] Scott Davis, Mastering MEAN: Introducing to MEANStack, [Online], http://www.ibm.com/developerworks/library/wa-mean1/index.html, diakses tanggal 21 De-sember 2014

[14] James Turnbull,TheDockerBook:Containerization is a thenew Virtualization, version 1.3.2, James Turnbull, 2014

[15] Rajdeep Dua, A Reddy Raja, Dharmesh Kakadia, Virtualiza-tion vs Containerization to support PaaS, 2014 IEEE Inter-national Confrence on Cloud Engineering, pp 610-614, 2014

[16] HAProxy, HAProxy Description, [Online], http://www.haproxy.org/#desc, diakses tanggal 15 Desember 2014.

[17] AdamWigins, Heroku SQL Database Don't Scale, [Online],http://adam.herokuapp.com/past/2009/7/6/sql_databases_dont_scale/, diakses tanggal 18 September2014.

http://csrc.nist.gov/publications/nistpubs/800-145/SP800-145.pdf

http://csrc.nist.gov/publications/nistpubs/800-145/SP800-145.pdf

http://www.nodejs.org/

http://www.ibm.com/developerworks/library/wa-mean1/index.html

http://www.ibm.com/developerworks/library/wa-mean1/index.html

http://www.haproxy.org/#desc

http://www.haproxy.org/#desc

http://adam.herokuapp.com/past/2009/7/6/sql_databases_dont_scale/

http://adam.herokuapp.com/past/2009/7/6/sql_databases_dont_scale/

LAMPIRAN A

PERBANDINGAN LAYANAN CLOUDWEB HOSTING

Pada lampiran berikut, dijelaskanmengenai perbandingan antara la-yanan yang menamakan dirinya sebagai cloud web hosting di In-donesia yang semuanya berbasis cPanel pada tabel A.1 sementaraperbandingan fitur layanan cloud hosting di luar negeri antara yangberbasis cPanel, Heroku dan OpenShift pada tabel A.2.

Tabel A.1: Layanan yang Dipasarkan sebagai Cloud Web Hostingdi Indonesia

No Nama URL Panel Fitur1 Dewa Web

[2]http://dewaweb.com

cPanel Unlimited Bandwi-dth,CloudFare CDN,Sumberdaya terga-ransi,Autobackup

2 DeDoHo [3] http://dedoho.pw

cPanel Unlimited Bandwi-dth,CloudFare CDN,Autobackup

3 CloudKilat[4]

http://cloudkilat.com

cPanel Unlimited Bandwi-dth,CloudFare CDN

97

http://dewaweb.com

http://dewaweb.com

http://dewaweb.com

http://dedoho.pw

http://dedoho.pw




98

Tabel A.2: Perbandingan Fitur antara Cloud Hosting berbasis cPa-nel dengan Layanan OpenShift dan Heroku

No Fitur cPanel-based [7]

OpenShift[5]

Heroku [6]

1 Kemampuanscaling

Menghubungiadmin, tidakmulti-node

Otomatissesuai trafikatau ma-nual olehpengguna

Manual olehpengguna

2 DukunganPHP

Ada, keba-nyakan tidakmenyediakanvariasi versi

Ada, bisamemilihversi

Ada, bisamemilihversi

3 DukunganNode.js

Tidak ada Ada Ada

4 DukunganRuby

Tidak ada Ada Ada

5 DukunganPython

Tidak ada Ada Ada

6 Basis DataMySQL

Ada, satuserver dibagibanyak basisdata

Ada, satuserver untuksatu aplikasi

Ada, satuserver untuksatu aplikasi

7 Basis DataMongoDB

Tidak ada Ada Ada

8 Akses Ber-kas Aplikasi

File manager/ FTP

Git Git/Mercurial

9 DukunganWebsockets

Tidak ada Ada Ada

99

No Fitur cPanel-based [7]

OpenShift[5]

Heroku [6]

10 Sistem pena-gihan

Bayardiawal,tergantunkapasitas

Gratis, Bro-nze, Silver

Sesuai ke-mampuanresource(dyno)

11 Biaya Mulai Rp.10.000 perbulan

Paket bronzemulai 0 USD

Mulai 34.50USD per bul-an

12 MembangunLayananSerupa

Bisa denganbayar lisensi

OpenShiftOrigin, na-mun untukkebutuhanprivate cloudbukan webhosting

Tidak Bisa

100


LAMPIRAN B

TANGKAPAN LAYAR PANEL

Pada lampiran berikut, ditampilkan mengenai tangkapan layar apli-kasi frontendManager yang diaksesmelalui aplikasi perambanWeb.

B.1 Antarmuka Admin

Gambar B.1: Antarmuka Daftar Penagihan dari Penyewa

Gambar B.2: Antarmuka Kelola Daftar Node dan Load Balancer

101

102

Gambar B.3: Antarmuka PemantauanKeadaanNode Secara Umum

B.2 Antarmuka Penyewa

Gambar B.4: Antarmuka Dasbor Pengguna

103

Gambar B.5: Antarmuka Pemesanan Aplikasi/Basis Data Baru

Gambar B.6: Antarmuka Pemesanan Peningkatan Kapasitas Apli-kasi/Basis Data

104

Gambar B.7: Antarmuka Pengaturan Aplikasi

Gambar B.8: Antarmuka Pengaturan Basis Data

105

Gambar B.9: Antarmuka Pemantauan Aplikasi

Gambar B.10: Antarmuka Pemantauan Basis Data

106

Gambar B.11: Antarmuka Pemantauan Unggahan Aplikasi melaluiGit

Gambar B.12: Antarmuka Pengelolaan Basis Data Melalui KonsolMySQL

BIODATA PENULIS

Putu Wiramaswara Widya, biasa dipang-gil Wira lahir di Denpasar tanggal 28 Sep-tember 1993. Merupakan anak sulung daridua bersaudara, penulis menyelesaikan ham-pir 17 tahun masa hidupnya di KabupatenKlungkung, Provinsi Bali. Sejak kecil, penu-lis sudah memiliki ketertarikan dalam bidangkomputer terutama dalam bidang sistem ope-rasi berbasis Linux dan jaringan komputer.Penulis pernah membantu melakukan pem-buatan program berbasis Visual Basic 6.0 pa-

da saat masih mengenyam pendidikan di Sekolah Dasar (SD) danmelakukan instalasi sistem operasi Mandrakelinux 10.0 pada ta-hun 2004. Penulis aktif dalam organisasi daring sejak tahun 2007melalui berbagai milis seperti id-ubuntu, id-slackware danBlankOn-Dev. Pada masa Sekolah Menengah Atas, penulis sem-pat menjadi pengembang distribusi Linux lokal BlankOn Linux(http://blankonlinux.or.id) dan menjadi penanggungjawabpengembangan sistem metode input dan fonta pintar Unicode untukaksara Bali. Penulis pernah meraih medali emas pada ajang Olim-piade Penelitian Siswa Indonesa (OPSI) 2010 dalam bidang sainsterapan. Saat ini, penulis masih terus berkecimpung di bidang pe-ngembangan dan penggunaan Linux serta perangkat lunak sumberterbuka (Free Open Source Software, FOSS) dan sedang menda-lami berbagai kerangka kerja bahasa pemrograman untuk pengem-bangan aplikasi Web dan jaringan seperti Python dan Node.js. Pe-nulis memiliki blog pada alamat http://wirama.web.id/blog(dalam bahasa Inggris) dan dapat dihubungi melalui surel di [email protected] atau [email protected].

107

http://blankonlinux.or.id

http://wirama.web.id/blog

RANCANG BANGUN LAYANAN PLATFORM AS A SERVICE...

Documents

Transcript of RANCANG BANGUN LAYANAN PLATFORM AS A SERVICE...