Implementasi Metode Multi Criteria Decision Making Menggunakan Analytic Hierarchy Process Pada Docker Container Untuk Optimasi Sumber Daya Server - ITS Repository

  TUGAS AKHIR - KI141502

  IMPLEMENTASI METODE MULTI CRITERIA DECISION MAKING MENGGUNAKAN ANALYTIC HIERARCHY PROCESS PADA DOCKER CONTAINER UNTUK OPTIMASI SUMBER DAYA SERVER

  I DEWA PUTU ARDI NUSAWAN NRP 5113100096 Dosen Pembimbing I Royyana M. Ijtihadie, S.Kom., M.Kom., Ph.D Dosen Pembimbing II Bagus Jati Santoso, S.Kom., Ph.D JURUSAN TEKNIK INFORMATIKA Fakultas Teknologi Informasi Institut Teknologi Sepuluh Nopember Surabaya, 2017

  (Halaman ini sengaja dikosongkan) TUGAS AKHIR - KI141502

  IMPLEMENTASI METODE MULTI CRITERIA DECISION MAKING MENGGUNAKAN ANALYTIC HIERARCHY PROCESS PADA DOCKER CONTAINER UNTUK OPTIMASI SUMBER DAYA SERVER

  I DEWA PUTU ARDI NUSAWAN NRP 5113100096 Dosen Pembimbing I Royyana M. Ijtihadie, S.Kom., M.Kom., Ph.D Dosen Pembimbing II Bagus Jati Santoso, S.Kom., Ph.D JURUSAN TEKNIK INFORMATIKA Fakultas Teknologi Informasi Institut Teknologi Sepuluh Nopember Surabaya, 2017

  (Halaman ini sengaja dikosongkan) UNDERGRADUATE THESIS - KI141502

  IMPLEMENTATION OF MULTI CRITERIA DECISION MAKING METHOD USING ANALYTIC HIERARCHY PROCESS ON DOCKER CONTAINER TO OPTIMIZE SERVER RESOURCES

  I DEWA PUTU ARDI NUSAWAN NRP 5113100096 Supervisor I Royyana M. Ijtihadie, S.Kom., M.Kom., Ph.D Supervisor II Bagus Jati Santoso, S.Kom., Ph.D Department of INFORMATICS Faculty of Information Technology Institut Teknologi Sepuluh Nopember Surabaya, 2017

  (Halaman ini sengaja dikosongkan)

  

LEMBAR PENGESAHAN

  IMPLEMENTASI

  METODE MULTI CRITERIA DECISION

  

MAKING MENGGUNAKAN ANALYTIC HIERARCHY

PROCESS

  PADA DOCKER CONTAINER UNTUK

  

OPTIMASI SUMBER DAYA SERVER

TUGAS

  AKHIR Diajukan Guna Memenuhi Salah Satu Syarat

  Memperoleh Gelar Sarjana Komputer pada Bidang Studi Komputasi Berbasis Jaringan

  Program Studi S1 Jurusan Teknik Informatika Fakultas Teknologi Informasi

  Institut Teknologi Sepuluh Nopember Oleh :

  I DEWA PUTU ARDI NUSAWAN

NRP: 5113100096

  Disetujui oleh Dosen Pembimbing Tugas Akhir : Royyana M. Ijtihadie, S.Kom., M.Kom., Ph.D ........................ NIP: 197708242006041001 (Pembimbing 1) Bagus Jati Santoso, S.Kom., Ph.D ......................... NIP: 051100116 (Pembimbing 2)

  

SURABAYA

Juli 2017

  (Halaman ini sengaja dikosongkan)

  

IMPLEMENTASI METODE MULTI CRITERIA DECISION

MAKING

  MENGGUNAKAN ANALYTIC HIERARCHY

  

PROCESS PADA DOCKER CONTAINER UNTUK

OPTIMASI

  SUMBER DAYA SERVER

  Nama : I DEWA PUTU ARDI NUSAWAN NRP

  : 5113100096

  Jurusan

  : Teknik Informatika FTIf

  Pembimbing

  I : Royyana M. Ijtihadie, S.Kom.,

  M.Kom., Ph.D Pembimbing

  II : Bagus Jati Santoso, S.Kom., Ph.D

  

Abstrak

  Saat ini di era cloud computing, membuat kebutuhan akses data ke server semakin meningkat. Dibutuhkan teknologi untuk mengoptimalkan resource yang tepat pada server agar dapat bekerja optimal. Penggunaan docker container semakin meningkat seiring dengan kebutuhan akan optimasi tersebut.

  docker

  container merupakan pilihan yang tepat sebagai pengganti Virtual Machine. Pada container, programmer dapat fokus pada pengengembangan aplikasi, serta dapat dipastikan bahwa aplikasi akan dapat berjalan pada host apapun. container menggunakan sumber daya server, dan setiap docker yang

• – dijalankan pada server memakai sumber daya yang berbeda beda tergantung dari berbagai faktor. Namun, container akan tetap berjalan walaupun tidak sedang dipakai. Untuk memaksimalkan sumber daya yang ada, diperlukan analisisa yang tepat untuk mematikan container yang sedang tidak digunakan. Berbagai parameter dapat dipakai sebagai acuan, seperti CPU yang digunakan, memori, dan waktu. Metode Multi

  

Criteria Decision Making (MCDM) dapat membantu

  menentukan pilihan terbaik yang diperlukan. Dalam tugas akhir ini, akan menggunakan salah satu metode MCDM yang sering dipakai, yaitu Analytic Hierarchy Process (AHP). Prosedur AHP telah diimplementasikan pada Decision Support System (DSS), termasuk data mining dan machine learning, serta banyak aplikasi lainnya. Dengan menggunakan metode perhitungan AHP, dapat ditentukan container yang memiliki prioritas rendah hingga tinggi. Setelah ditentukan, maka container dengan prioritas rendah dapat dimatikan, sehingga sumber daya server dapat digunakan oleh container lain yang membutuhkan sumber daya lebih.

  Kata-Kunci : Docker, Container, MCDM, AHP

  

IMPLEMENTATION OF MULTI CRITERIA DECISION

MAKING

  METHOD USING ANALYTIC HIERARCHY

  

PROCESS ON DOCKER CONTAINER TO OPTIMIZE

SERVER

  RESOURCES

  Name : I DEWA PUTU ARDI NUSAWAN NRP

  : 5113100096

  Major : Informatics FTIf Supervisor

  I : Royyana M. Ijtihadie, S.Kom.,

  M.Kom.,

  Ph.D

  Supervisor

  II : Bagus Jati Santoso, S.Kom., Ph.D

  

Abstract

  The era of cloud computing increases the need for data access to the server. It takes technology to optimize the right resources on the server in order to work optimally. The use of docker container increases along with the need for such optimization. Docker Container is the right choice as a substitute for Virtual Machine. In using Docker Container, programmers can focus on the development of the application, and it is certain that the application will be able to run on any host. The docker container uses resources from the server, and each docker that runs on the server uses different resources depending on various factors. However, the container will still run even when not in use. To maximize the available resources, proper analysis is needed to turn off the unused containers. Various parameters can be used as a reference, such as CPU use, memory, and the last accessed time. The Multi Criteria Decision Making (MCDM) method can help determine the best options needed. The algorithm used in this final project is the Analytic Hierarchy Process (AHP), as one of the commonly used algorithm in MCDM method. The AHP procedure has been implemented on the Decision Support System (DSS), including data mining and machine learning, as well as in many other applications [1]. The use of AHP calculation method can determine the low or high priority of the container. Once specified, the low priority container can be turned off, so the server resources can be used by other containers that require more resources.

  Keywords

  : Docker, Container, MCDM, AHP Segala puji bagi Ida Sang Hyang Widhi Wasa, yang telah melimpahkan rahmat dan karunia-Nya sehingga penulis dapat menyelesaikan Tugas Akhir yang berjudul Implementasi

  Metode

  Multi Criteria Decision Making Menggunakan

  

Analytic Hierarchy Process pada Docker Container untuk

Optimasi Sumber Daya Server. Pengerjaan Tugas Akhir ini

merupakan suatu kesempatan yang sangat baik bagi penulis.

  Dengan pengerjaan Tugas Akhir ini, penulis bisa belajar lebih banyak untuk memperdalam dan meningkatkan apa yang telah didapatkan penulis selama menempuh perkuliahan di Teknik Informatika ITS. Dengan Tugas Akhir ini penulis juga dapat menghasilkan suatu implementasi dari apa yang telah penulis pelajari. Selesainya Tugas Akhir ini tidak lepas dari bantuan dan dukungan beberapa pihak. Sehingga pada kesempatan ini penulis mengucapkan syukur dan terima kasih kepada:

  1. Ida Sang Hyang Widhi Wasa atas anugerahnya yang tidak terkira kepada penulis.

  2. Bapak Royyana Muslim Ijtihadie, S.Kom, M.Kom, PhD selaku pembimbing I yang telah membantu, membimbing, dan memotivasi penulis mulai dari pengerjaan proposal hingga terselesaikannya Tugas Akhir ini.

  3. Bapak Bagus Jati Santoso, S.Kom., Ph.D selaku pembimbing II yang juga telah membantu, membimbing, dan memotivasi penulis mulai dari pengerjaan proposal hingga terselesaikannya Tugas Akhir ini.

  4. Darlis Herumurti, S.Kom., M.Kom., selaku Kepala Jurusan Teknik Informatika ITS pada masa pengerjaan Tugas Akhir, Bapak Radityo Anggoro, S.Kom., M.Sc., selaku koordinator TA, dan segenap dosen Teknik Informatika yang telah memberikan ilmu dan pengalamannya.

  5. Teman-teman Administrator LP, yakni Razi, Dewangga, Agha, Rona, Sani, Ine, Gideon, Udin, dan yang bersedia direpotkan, merepotkan dan menemani penulis dalam masa pengerjaan tugas akhir ini.

  6. Teman - teman PPDB Surabaya 2016 serta PPDB Jawa Timur 2017 yang senantiasaa begadang bareng di lab badak dan lt4.

  7. Widya Pramesti yang telah bersedia membantu menerjemahkan buku ini :)

  8. Serta semua pihak yang telah turut membantu penulis dalam menyelesaikan Tugas Akhir ini.

  Penulis menyadari bahwa Tugas Akhir ini masih memiliki banyak kekurangan. Sehingga dengan kerendahan hati, penulis mengharapkan kritik dan saran dari pembaca untuk perbaikan ke depannya.

  Surabaya, Juli 2017

  I Dewa Putu Ardi Nusawan

  ABSTRAK vii ABSTRACT ix

  2.1 Analytical Hierarchy Proses (AHP) . . . . . . . . 5

  2.3 Python . . . . . . . . . . . . . . . . . . . . . . . . 14

  2.2.2 Docker Container . . . . . . . . . . . . . 13

  2.2.1 Docker Images . . . . . . . . . . . . . . . 13

  2.2 Docker . . . . . . . . . . . . . . . . . . . . . . . 13

  2.1.6 Tahap akhir adalah membuat matriks vektor eigen untuk X, Y dan Z . . . . . . 12

  2.1.5 Penilaian Setiap Pilihan Untuk Fleksibilitas 11

  2.1.4 Penilaian Setiap Pilihan Untuk Keandalan (Reliability) . . . . . . . . . . . . . . . . 11

  2.1.3 Penilaian Setiap Pilihan Untuk Operabilitas 11

  7

  2.1.1 Prinsip dasar AHP . . . . . . . . . . . . . 5 2.1.2 Kasus Penggunaan . . . . . . . . . . . . .

  II LANDASAN TEORI 5

  

KATA PENGANTAR xi

DAFTAR

  3 BAB

  3 1.5 Manfaat . . . . . . . . . . . . . . . . . . . . . . .

  2 1.4 Tujuan . . . . . . . . . . . . . . . . . . . . . . . .

  2 1.3 Batasan Masalah . . . . . . . . . . . . . . . . . .

  1 1.2 Rumusan Masalah . . . . . . . . . . . . . . . . .

  1 1.1 Latar Belakang . . . . . . . . . . . . . . . . . . .

  I PENDAHULUAN

  xix BAB

  GAMBAR

  xiii

DAFTAR TABEL xvii

DAFTAR

  ISI

  2.4 Flask . . . . . . . . . . . . . . . . . . . . . . . . 15

  2.5 MySQL . . . . . . . . . . . . . . . . . . . . . . . 16

  2.6 Multi Criteria Decision Making (MCDM) . . . . 17

  BAB

  19 III DESAIN DAN PERANCANGAN

  3.1 Kasus Penggunaan . . . . . . . . . . . . . . . . . 19

  3.2 Arsitektur Sistem . . . . . . . . . . . . . . . . . . 21

  3.2.1 Desain Umum Sistem . . . . . . . . . . . 21

  3.2.2 Perancangan Penyimpanan Data Sumber Daya Container dan Hasil AHP . . . . . . 23

  3.2.3 Perancangan Middleware . . . . . . . . . 23

  3.2.4 Desain Perhitungan AHP . . . . . . . . . 25

  3.2.5 Desain Dasbor . . . . . . . . . . . . . . . 28

  BAB

  31 IV IMPLEMENTASI

  4.1 Lingkungan Implementasi . . . . . . . . . . . . . 31

  4.2 Implementasi Penyimpanan Data . . . . . . . . . 31

  4.2.1 Menjalankan Database MySQL . . . . . . 32

  4.2.2 Skema penyimpanan data log Docker

  Container pada MySQL . . . . . . . . . . 32

  4.2.3 Skema Penyimpanan Data Log Server Pada MySQL . . . . . . . . . . . . . . . . 33

  4.2.4 Skema Penyimpanan Hasil AHP Pada MySQL . . . . . . . . . . . . . . . . . . . 34

  4.2.5 Skema Penyimpanan Container Yang Aktif 36

  4.3 Implementasi Docker Compose . . . . . . . . . . 36

  4.3.1 Menjalankan Docker Compose . . . . . . 36

  4.3.2 Pembangunan Docker Compose Untuk Moodle . . . . . . . . . . . . . . . . . . . 37

  4.3.3 Menjalankan Docker Compose Sebagai Layanan Moodle . . . . . . . . . . . . . . 38

  4.4 Implementasi Middleware . . . . . . . . . . . . . 38

  4.4.1 Implementasi Mengalihkan Permintaan

  Course ke Container Yang Tepat . . . . . 38

  4.4.2 Implementasi Pengambilan Data Penggunaan Server . . . . . . . . . . . . 40

  5.2 Skenario Uji Coba . . . . . . . . . . . . . . . . . 59

  PUSTAKA

  DAFTAR

  6.2 Saran . . . . . . . . . . . . . . . . . . . . . . . . 85

  6.1 Kesimpulan . . . . . . . . . . . . . . . . . . . . . 85

  85

  VI PENUTUP

  BAB

  5.3.3 Uji Performa . . . . . . . . . . . . . . . . 76

  5.3.2 Uji Perangkat Komputer Dapat Melakukan Pehitungan AHP Untuk Menentukan Container Mana Yang Akan Dimatikan . . . . . . . . . . . . . . . . . 71

  5.3.1 Uji Fungsionalitas . . . . . . . . . . . . . 65

  5.3 Hasil Uji Coba dan Evaluasi . . . . . . . . . . . . 65

  5.2.2 Skenario Uji Performa . . . . . . . . . . . 65

  5.2.1 Skenario Uji Fungsionalitas . . . . . . . . 59

  5.1 Lingkungan Uji Coba . . . . . . . . . . . . . . . . 59

  4.4.3 Implementasi Background Scheduler Untuk Menjalankan

  59

  V PENGUJIAN DAN EVALUASI

  BAB

  4.5 Implementasi Dasbor . . . . . . . . . . . . . . . . 56

  4.4.7 Implementasi Perhitungan AHP . . . . . . 46

  4.4.6 Implementasi Pengambilan Data CPU Pada Container Moodle . . . . . . . . . . 44

  4.4.5 Implementasi Pengambilan Data Memory Pada Container Moodle . . . . . . . . . . 43

  Time Access Pada Container Moodle . . . 41

  4.4.4 Implementasi Pengambilan Data Last

  Process . . . . . . . . . . . . 41

  Background

  pada

  Middleware

  87

  BAB A INSTALASI PERANGKAT LUNAK

  89

  1.1 Instalasi Lingkungan Docker . . . . . . . . . . . . 89

  1.2 Instalasi Docker Compose . . . . . . . . . . . . . 90

  1.3 Instalasi Pustaka Python . . . . . . . . . . . . . . 90

  1.4 Instalasi MySQL . . . . . . . . . . . . . . . . . . 91

  1.5 Pemasangan Kerangka Kerja VueJS . . . . . . . . 93

  BAB B KODE SUMBER

  95 BIODATA PENULIS 107

  2.1 Scala Rating Saaty[1] . . . . . . . . . . . . . . . . 6

  2.2 Menyusun Matrik Diagonal Bernilai 1[1] . . . . . 8

  2.3 Memasukkan Bobot Tahap 1[1] . . . . . . . . . . 8

  2.4 Memasukkan Bobot Tahap 2[1] . . . . . . . . . . 9 2.5 Mengembangkan Bobot untuk Kriteria[1] . . . . .

  9

  2.6 Rating Setiap Mesin Untuk Harga (expense)[1] . . 10

  2.7 Eigenvector (0.480, 0.406, 0.114)[1] . . . . . . . . 11

  2.8 Eigenvector (0.077, 0.231, 0.692)[1] . . . . . . . 11

  2.9 Eigenvector (0.066, 0.615, 0.319)[1] . . . . . . . 11

  2.10 Eigenvector 0.232, 0.402, 0.061, 0.305)[1] . . . . 12

  3.1 Daftar Kode Kasus Penggunaan . . . . . . . . . . 20

  3.2 Daftar Skala Prioritas pada AHP . . . . . . . . . . 26

  4.1 Tabel stats . . . . . . . . . . . . . . . . . . . . . . 32

  4.2 Tabel server-stats . . . . . . . . . . . . . . . . . . 33

  4.3 Tabel server-stats . . . . . . . . . . . . . . . . . . 34

  4.4 Tabel containers . . . . . . . . . . . . . . . . . . 36

  4.5 Tabel stats di database . . . . . . . . . . . . . . . 47

  4.6 Comparison Matrix . . . . . . . . . . . . . . . . . 48

  4.7 Pengaturan Prioritas Kriteria Dengan Perbandingan Berpasangan . . . . . . . . . . . . . 48

  4.8 Rating Setiap Container Untuk Memory (RAM) . 49

  4.9 Rating Setiap Container Untuk Memory (RAM) . 50

  4.10 Rating Setiap Container Untuk Memory (RAM) . 50

  4.11 Rating Setiap Container Untuk CPU . . . . . . . 51

  4.12 Rating Setiap Container Untuk CPU . . . . . . . 52

  4.13 Rating Setiap Container Untuk CPU . . . . . . . 52

  4.14 Rating Setiap Container Untuk LTA . . . . . . . . 53

  4.15 Rating Setiap Container Untuk LTA . . . . . . . . 53

  4.16 Rating Setiap Container Untuk LTA . . . . . . . . 54

  4.17 Skor Akhir . . . . . . . . . . . . . . . . . . . . . 55

  5.1 Skenario Uji Fungsionalitas Aplikasi Dasbor . . . 60

  5.2 Skenario Uji Fungsionalitas Mendapatkan Data

  Docker

  Container . . . . . . . . . . . . . . . . . . 61

  5.2 Skenario Uji Fungsionalitas Mendapatkan Data

  Docker

  Container . . . . . . . . . . . . . . . . . . 62

  5.2 Skenario Uji Fungsionalitas Mendapatkan Data

  Docker

  Container . . . . . . . . . . . . . . . . . . 63

  5.3 Skenario Uji Coba Sistem Dapat Melakukan Perhitungan AHP . . . . . . . . . . . . . . . . . . 64

  5.4 Mematikan Container . . . . . . . . . . . . . . . 64

  5.5 Mematikan Container . . . . . . . . . . . . . . . 66

  5.6 Uji Fungsionalitas Mendapatkan Data Docker

  Container . . . . . . . . . . . . . . . . . . . . . . 68

  5.6 Uji Fungsionalitas Mendapatkan Data Docker

  Container . . . . . . . . . . . . . . . . . . . . . . 69

  5.6 Uji Fungsionalitas Mendapatkan Data Docker

  Container . . . . . . . . . . . . . . . . . . . . . . 70

  5.7 Uji Coba Sistem Dapat Melakukan Perhitungan AHP . . . . . . . . . . . . . . . . . . . . . . . . . 75

  5.8 Jumlah Akses Pengguna dan Durasi . . . . . . . . 76

  5.9 Jumlah Akses Pengguna dan Durasi . . . . . . . . 76

  5.9 Jumlah Akses Pengguna dan Durasi . . . . . . . . 77

  5.10 Jumlah Akses Pengguna dan Durasi . . . . . . . . 79

  5.11 Jumlah Akses Pengguna dan Durasi . . . . . . . . 81

  2.1 Visualisasi perbedaan container dengan virtual machine . . . . . . . . . . . . . . . . . . . . . . . 14

  2.2 Contoh kriteria dan alternatif beberapa keputusan pembuatan keputusan[2] . . . . . . . . . . . . . . 18

  3.1 Diagram Kasus Penggunaan . . . . . . . . . . . . 19

  3.2 Desain Umum Sistem . . . . . . . . . . . . . . . 22

  3.3 Desain Middleware . . . . . . . . . . . . . . . . . 24

  3.4 Hirarki AHP . . . . . . . . . . . . . . . . . . . . 27

  3.5 Desain Antar Muka Dasbor . . . . . . . . . . . . 29

  4.1 Pengaturan Prioritas Kriteria Dengan Perbandingan Berpasangan . . . . . . . . . . . . . 49

  4.2 Snapshot Pemilihan Keputusan dari AHP . . . . . 56

  4.3 Dasbor Penggunaan Resource Server . . . . . . . 57

  5.1 Dasbor Penggunaan Resource Server . . . . . . . 66

  containers

  5.2 Tabel . . . . . . . . . . . . . . . . . 67

  5.3 Database Penggunaa Resource Server . . . . . . . 68

  5.4 Perhitungan Rating Setiap Container Untuk

  Memory (RAM) Pada Middleware . . . . . . . . . 71

  5.5 Perhitungan Rating Setiap Container Untuk CPU Pada Middleware . . . . . . . . . . . . . . . . . . 72

  5.6 Perhitungan Rating Setiap Container Untuk LTA Pada Middleware . . . . . . . . . . . . . . . . . . 73

  5.7 Database Penggunaa Resource Server . . . . . . . 73

  5.8 Console Log Menghitung AHP . . . . . . . . . . 73

  5.9 JMeter Mengakses Setiap Container Yang Tersedia 74

  5.10 Tabel result Awal . . . . . . . . . . . . . . . . . 75

  result

  5.11 Tabel Akhir . . . . . . . . . . . . . . . . 75

  5.12 Hasil Uji Coba dengan AHP Selama 2 Jam . . . . 77

  5.13 Hasil Uji Coba dengan AHP Selama 6 Jam . . . . 77

  5.14 Hasil Uji Coba dengan AHP Selama 1 Hari . . . 78

  5.15 Hasil Uji Coba dengan AHP Selama 2 Jam . . . . 79

  5.16 Hasil Uji Coba dengan AHP Selama 6 Jam . . . . 79

  5.17 Hasil Uji Coba dengan AHP Selama 1 Hari . . . . 80

  5.18 Hasil Uji Coba dengan AHP Selama 2 Jam . . . . 81

  5.19 Hasil Uji Coba dengan AHP Selama 6 Jam . . . . 81

  5.20 Hasil Uji Coba dengan AHP Selama 1 Hari . . . . 82

  5.21 Hasil Uji Coba tanpa AHP Selama 2 Jam . . . . . 82

  5.22 Hasil Uji Coba tanpa AHP Selama 6 Jam . . . . . 83

  5.23 Hasil Uji Coba tanpa AHP Selama 1 Hari . . . . 83

  

PENDAHULUAN

  Pada bab ini akan dipaparkan mengenai garis besar Tugas Akhir yang meliputi latar belakang, tujuan, rumusan dan batasan permasalahan, metodologi pembuatan Tugas Akhir, dan sistematika penulisan.

1.1 Latar Belakang

  Saat ini di era cloud computing, membuat kebutuhan akses data ke server semakin meningkat. Dibutuhkan teknologi untuk mengoptimalkan resource yang tepat pada server agar dapat bekerja optimal. Penggunaan container semakin meningkat

  Docker seiring dengan kebutuhan akan optimasi tersebut.

Container merupakan pilihan yang tepat sebagai pengganti

  virtual machine. Container adalah sebuah image yang ringan, bisa berdiri sendiri, paket executable dari perangkat lunak yang mencakup semua yang diperlukan untuk menjalankan program didalamnya, yakni: kode, runtime, berbagai tools yang diperlukan oleh sistem, library sistem, dan berbagai pengaturan lainnya. Tersedia pada masing - masing aplikasi yang berbasiskan Linux dan Windows, software yang ter-container akan dapat berjalan dengan environment yang sama. Container mengisolasi program dari keadaannya diluar container, sebagai contohnya adalah perbedaan environment antara development dan staging dan membantu mengurangi konflik diantara team yang menjalankan software pada infrastruktur yang sama[3].

  Pada container , programmer dapat fokus pada pengengembangan aplikasi, serta dapat dipastikan bahwa aplikasi akan dapat berjalan pada host apapun. Container menggunakan sumber daya server, dan setiap Docker yang

• – dijalankan pada server memakai sumber daya yang berbeda beda tergantung dari berbagai faktor.

  Namun, container akan tetap berjalan walaupun tidak sedang dipakai. Untuk memaksimalkan resource yang ada, diperlukan analisisa yang tepat untuk mematikan container yang sedang tidak digunakan. Berbagai parameter dapat dipakai sebagai acuan, seperti CPU yang digunakan, memori, dan waktu. Metode Multi Criteria Decision Making (MCDM) dapat membantu menentukan pilihan terbaik yang diperlukan.

  Dalam tugas akhir ini, akan menggunakan salah satu metode MCDM yang sering dipakai, yaitu Analytic Hierarchy Process

  

(AHP) . Prosedur AHP telah diimplementasikan pada Decision

Support System (DSS), termasuk data mining dan machine

learning , serta banyak aplikasi lainnya. Dengan menggunakan

  metode perhitungan AHP, dapat ditentukan container yang memiliki prioritas rendah hingga tinggi. Setelah ditentukan, maka container dengan prioritas rendah dapat dimatikan, sehingga sumber daya server dapat digunakan oleh container lain yang membutuhkan sumber daya lebih.

  1.2 Rumusan Masalah

  Rumusan masalah yang diangkat dalam tugas akhir ini adalah sebagai berikut :

  1. Bagaimana menerapkan skema MCDM dengan AHP untuk mengoptimalkan penggunaan sumber daya server?

  2. Bagaimana penggunaan sumber daya server apakah terjadi pengoptimalan jika menggunakan metode pengambilan keputusan AHP dibandingkan dengan sistem yang berjalan tanpa pengoptimalan?

  1.3 Batasan Masalah

  Dari permasalahan yang telah diuraikan di atas, terdapat beberapa batasan masalah pada tugas akhir ini, yaitu:

  1. Menggunakan Docker Container.

  2. Menggunakan bahasa pemrograman Python sebagai Middleware .

  3. Pengujian dilakukan menggunakan jaringan lokal Teknik Informatika FTIf ITS.

  4. Menggunakan metode AHP untuk menentukan container yang harus dihentikan.

  5. Hanya melakukan optimasi pada satu server fisik.

  1.4 Tujuan

  Tujuan dari pengerjaan Tugas Akhir ini adalah dapat menerapkan skema MCDM dengan metode AHP untuk mengoptimalkan sumber daya server.

  1.5 Manfaat

  Manfaat dari hasil pembuatan tugas akhir ini adalah dapat mengoptimalkan sumber daya server (RAM, CPU) agar lebih optimal dan efisien dalam menjalankan banyak docker container.

  (Halaman

  ini sengaja dikosongkan)

  LANDASAN

  TEORI

2.1 Analytical Hierarchy Proses (AHP)

  Analytic Hierarchy Process (AHP) diciptakan oleh Saaty (1980) dan sering disebut, secara eponim sebagai metode Saaty.

  Metode ini populer dan banyak digunakan, terutama dalam analisis militer, meskipada saat itu terbatas pada masalah militer. Sebenarnya, dalam bukunya Saaty menggambarkan berbagai aplikasi penggunaan metode AHP mulai dari pilihan sekolah untuk anaknya, hingga perencanaan sistem transportasi untuk Negara Sudan[1].

  AHP menangani masalah seperti berikut: Terdapat berbagai pilihan pembeliannya: biaya(expense), E; Operabilitas, O; Kehandalan(reliability), R; Kemampuan beradaptasi untuk kegunaan lain, dan F; fleksibilitas. Produsen yang bersaing dengan peralatan tersebut telah menawarkan tiga pilihan, X, Y dan Z. Insinyur perusahaan telah melihat opsi ini dan memutuskan bahwa X murah dan mudah dioperasikan namun tidak terlalu dapat diandalkan. Dan tidak bisa dengan mudah disesuaikan dengan kegunaan lain. Y agak lebih mahal, cukup mudah dioperasikan, sangat bisa diandalkan tapi tidak terlalu mudah beradaptasi. Akhirnya, Z sangat mahal, tidak mudah dioperasikan, sedikit kurang dapat diandalkan dibanding Y namun diklaim oleh pabrikan untuk memiliki berbagai macam kegunaan alternatif[1].

  Masing-masing X, Y dan Z akan memenuhi persyaratan perusahaan untuk memperluas jangkauan sehingga yang, secara keseluruhan, paling sesuai dengan kebutuhan perusahaan ini?[1]

2.1.1 Prinsip dasar AHP

  AHP dan teknik perhitungannya secara singkat adalah membuat matriks yang mengekspresikan nilai relatif dari sekumpulan atribut. Misalnya, apa kepentingan relatif pengelolaan perusahaan biaya peralatan ini dibandingkan dengan kemudahan pengoperasiannya? Mereka diminta untuk memilih apakah biaya jauh lebih penting, lebih penting, sama pentingnya, dan seterusnya menjadi sangat tidak penting, daripada pengoperasian. Masing-masing penilaian ini diberi nomor dalam skala. Skala yang umum (diadaptasi dari Saaty) digunakan dapat dilihat pada tabel 2.1:

  

Tabel 2.1: Scala Rating Saaty[1]

Definisi Penjelasan

Tingkat kepentingan

  1 Sama Dua faktor berkontribusi pentingnya sama terhadap tujuan

  3 Agak lebih Pengalaman dan penting penilaian sedikit lebih menguntungkan dibanding yang lain

  5 Jauh lebih Pengalaman dan penting penilaian sangat mendukung satu dari lainnya

  7 Sangat jauh Pengalaman dan lebih penting penilaian sangat mendukung satu dari lainnya. Pentingnya dalam ditunjukkan praktek

  9 Benar-benar Bukti yang mendukung lebih penting satu dari yang lain adalah kemungkinan tertinggi

  2, 4, 6, 8 Nilai Ketika kompromi intermediate diperlukan

  Asumsi dasar, tapi sangat masuk akal adalah bahwa jika atribut A benar-benar lebih penting daripada atribut B dan diberi nilai 9, maka B harus benar-benar kurang penting daripada A dan bernilai 1/9.

  Perbandingan berpasangan ini dilakukan untuk semua faktor yang harus dipertimbangkan, biasanya tidak lebih dari 7, dan matriksnya selesai. Matriks adalah bentuk yang sangat khusus yang mendukung perhitungan yang kemudian terjadi (Saaty adalah seorang matematikawan yang sangat terhormat).

  Langkah selanjutnya adalah perhitungan daftar bobot relatif, kepentingan, atau nilai, faktor-faktor, seperti biaya dan pengoperasian yang relevan dengan masalah yang dimaksud (secara teknis daftar ini disebut vektor eigen). Jika, mungkin, biaya sangat jauh lebih penting daripada operabilitas, maka pada interpretasi sederhana, peralatan yang lebih murah yang lebih digunakan.

  Vektor eigen pertama memberi kepentingan relatif yang melekat pada persyaratan, seperti biaya dan keandalan namun mesin yang berbeda mempunyai biaya dan keandalan yang berbeda pula. Dengan demikian, matriks selanjutnya dapat dikembangkan untuk menunjukkan bagaimana X, Y dan Z masing-masing memenuhi kebutuhan perusahaan. Langkah terakhir adalah menggunakan perhitungan matriks standar untuk menghasilkan keseluruhan vektor dengan memberikan jawaban yang kita cari, yaitu manfaat relatif X, Y dan Z dibandingkan secara vis-à-vis(France, face to face) untuk menemukan pilihan terbaik yang sesuai dengan persyaratan perusahaan[1].

2.1.2 Kasus Penggunaan

2.1.2.1 Menyusun Matriks Perbandingan

  Pertama, diberikan matriks awal untuk perbandingan karena setiap faktor sama pentingnya dengan dirinya sendiri. 2.2: E O R F E 1 O

  1 R

  1 F

  1 Tabel 2.2: Menyusun Matrik Diagonal Bernilai 1[1] Perusahaan memutuskan bahwa O, operabilitas, sedikit lebih penting daripada biaya (expense). Diberi nilai 3 pada kolom O,

  E dan 1/3 di E, O. Mereka juga memutuskan bahwa biaya jauh lebih penting daripada keandalan (reliability), memberikan 5 di E, R dan 1/5 di R, E, seperti yang ditunjukkan pada tabel 2.3.

  E O R F E 1 1/3 5 O 3

  1 R 1/5

  1 F

  1 Tabel 2.3: Memasukkan Bobot Tahap 1[1] Perusahaan juga menilai bahwa operabilitas, O, jauh lebih penting daripada keandalan (R) maka diberi nilai 5 pada kolom

  O, R dan penilaian yang sama dibuat mengenai kepentingan relatif F dengan R. Ini membentuk matriks yang disebut dengan

  E O R F E 1 1/3 5

  1 O 3

  1

  5

  1 R 1/5 1/5 1 1/5 F

  1

  1

  5

  1 Tabel

  2.4: Memasukkan Bobot Tahap 2[1] th

  Maka setelah dihitung nilai akar ke-n dan eigen vectornya, didapatkanlah seperti tabel 2.5:

  th n root of

  E O R F Eigenvector product of values E 1 1/3 5 1 1.133368103 0.23149916

  1.967989671 O

  3

  1

  5 1 0.40197704 R 1/5 1/5 1 1/5 0.299069756 0.0610873

  1.495348781 F

  1

  1

  5 1 0.3054365 Totals 4.895776312 1.000

  

Tabel 2.5: Mengembangkan Bobot untuk Kriteria[1]

  Eigenvector yang akan di sebut Relative Value Vector (RVV), dihitung dengan metode standar didapatkan (0.232, 0.402, 0.061, 0.305). Keempat bilangan ini merupakan nilai relatif E, O, R dan

  F, dimana yang paling besar 0.402, sedangkan 0,305 menunjukkan bahwa mereka menyukai gagasan fleksibilitas; Dua angka yang tersisa menunjukkan bahwa mereka tidak terlalu khawatir dengan biaya dan tidak tertarik pada keandalan. Kelihatannya aneh untuk tidak tertarik pada keandalan tapi RVV menangkap semua faktor implisit dalam konteks keputusan. Mungkin, dalam kasus ini, mesin hanya akan digunakan sesekali sehingga akan ada banyak waktu untuk perbaikan jika dibutuhkan.

  Sekarang beralih ke tiga mesin potensial, X, Y dan Z. Kita sekarang memerlukan empat set perbandingan berpasangan tapi kali ini dalam hal seberapa baik X, Y dan Z tampil dalam empat kriteria yakni E, O, R dan F.

2.1.2.2 Penilaian Setiap Pilihan untuk Harga (Expense)

  X Y Z X 1

  5

  9 Y 1/5 1

  3 Z 1/9 1/3 1

  Tabel 2.6: Rating Setiap Mesin Untuk Harga (expense)[1]

  Ini berarti bahwa X jauh lebih baik daripada Y dalam hal biaya dan terlebih lagi untuk Z. Angka biaya sebenarnya dapat digunakan namun akan mengubah nilai matriks ini, yang relatif terhadap faktor penilaian kualitatif lainnya. Vektor eigen untuk matriks ini adalah (0,751, 0,188, 0,071), sama seperti yang diharapkan, dan CR adalah 0,072, sehingga penilaiannya dapat diterima konsisten.

  Tiga matriks berikutnya masing-masing merupakan penilaian dari manfaat relatif X, Y dan Z sehubungan dengan kemampuan pengoperasian, keandalan dan fleksibilitas (hanya untuk mengingatkan Anda, X murah dan mudah dioperasikan namun tidak terlalu dapat diandalkan dan tidak dapat dengan mudah disesuaikan dengan penggunaan, lain halnya dengan Y agak lebih mahal, cukup mudah dioperasikan, sangat andal namun tidak terlalu mudah beradaptasi. Akhirnya, Z sangat mahal, tidak mudah dioperasikan, sedikit kurang dapat diandalkan dibanding Y namun diklaim memiliki jangkauan yang luas. Penggunaan

  2.1.3 Penilaian Setiap Pilihan Untuk Operabilitas

  3

  Tabel 2.9: Eigenvector (0.066, 0.615, 0.319)[1]

  2 Z 5 1/2 1

  1

  X Y Z X 1 1/9 1/5 Y 9

  2.1.5 Penilaian Setiap Pilihan Untuk Fleksibilitas

  1 Tabel 2.8: Eigenvector (0.077, 0.231, 0.692)[1]

  X Y Z X 1 1/3 1/9 Y 3 1 1/3 Z 9

  X Y Z X 1

  

2.1.4 Penilaian Setiap Pilihan Untuk Keandalan (Reliability)

  

Tabel 2.7: Eigenvector (0.480, 0.406, 0.114)[1]

  3 Z 1/5 1/3 1

  1

  5 Y 1

  1

  Alasan bahwa nilai Y lebih baik daripada Z pada kriteria ini adalah bahwa perusahaan tersebut tidak benar-benar mempercayai klaim pabrikan untuk Z. AHP menangani pendapat

  

2.1.6 Tahap akhir adalah membuat matriks vektor eigen

untuk X, Y dan Z

  E O R F X 0.751 0.480 0.077 0.066 Y 0.178 0.406 0.231 0.615 Z 0.071 0.114 0.692 0.319

  

Tabel 2.10: Eigenvector 0.232, 0.402, 0.061, 0.305)[1]

  Matriks ini, yang kita sebut Option Performance Matriks

  

(OPM) , merangkum kemampuan masing-masing dari tiga mesin

  dalam hal apa yang diinginkan perusahaan. Didapatkan hasil X jauh lebih baik daripada Y dan Z dalam hal biaya; X sedikit lebih baik dari Y dalam hal pengoperasian, bagaimanapun, X adalah nilai terbatas dalam hal keandalan dan fleksibilitas. Berbagai pilihan tersebut berhubungan dengan seperangkat kriteria yang dipilih oleh hipotetis ini. Bagi perusahaan lain yang keandalannya lebih penting dan ingin mengurangi biaya, ketiga mesin mungkin bisa mencetak skor yang sangat berbeda.

  Langkah terakhir adalah memperhitungkan penilaian perusahaan mengenai kepentingan relatif E, O, R dan F. Bagi perusahaan yang lebih mementingkan fleksibilitas, Y akan ideal. Jika keandalan, maka mesin Z adalah pilihan pertama. Nilai

  

Relatif Value Vector adalah: 0.232, 0.402, 0.061, 0.305. Lalu

  dilakukan perhitungan mengalikan OPM dengan RVV untuk mendapatkan vektor kemampuan masing-masing mesin ini untuk memenuhi kebutuhan perusahaan. Maka didapatkan hasil: 0,392, 0,406, 0,204; dan bisa disebut vektor Value For Money (VFM). Dalam matriks aljabar, OPM * RVV = VFM atau:

performance*requirement = value for money.

  Tiga angka dalam VFM adalah hasil akhir perhitungan. buruk dalam hal kemampuannya memenuhi kebutuhan perusahaan daripada Y pada 0,406. Z berada jauh di belakang pada 0,204 dan agak buruk dalam memenuhi persyaratan perusahaan dalam kasus ilustratif ini[1].

2.2 Docker

  Docker[3] adalah sebuah aplikasi yang bersifat open source yang berfungsi sebagai wadah atau container untuk mengepak atau memasukkan sebuah perangkat lunak secara lengkap beserta semua hal lainnya yang dibutuhkan oleh perangkat lunak tersebut agar dapat berfungsi.

  2.2.1 Docker Images

  Docker images[4] adalah sebuah blueprint atau dasar dari aplikasi berbasis Docker yang bersifat read-only. Blueprint ini sebenarnya adalah sebuah sistem operasi atau sistem operasi yang telah dipasang berbagai aplikasi dan pustaka pendukung. Docker images berfungsi untuk membuat Docker container, yang mana dengan menggunakan satu Docker image dapat dibuat banyak Docker container. Dengan menggunkaan Docker image, permasalah yang dikenal dengan

  ”dependency hell”, dimana sulitnya untuk melengkapi dependensi sebuah aplikasi, dapat diselesaikan karena semua kebutuhan aplikasi sudah berada di dalamnya.

  2.2.2 Docker Container

  Docker container[4] bisa dikatakan sebagai sebuah folder, dimana docker container ini dibuat dengan menggunakan docker container. Setiap docker container dijalankan maka akan terbentuk layer tepat di atas docker images. Contohnya saat container dari image Ubuntu tersebut dengan nama “Ubuntuku”. Kemudian lakukan pemasangan sebuah perangkat lunak, misalnya nginx, maka secara otomatis container Ubuntuku akan berada di atas layer image Ubuntu. Docker container ke depannya dapat dibangun sehingga akan menghasilkan sebuah docker images, dan docker images yang dihasilkan dari docker container ini dapat digunakan kembali untuk membuat docker container yang baru.

  Gambar 2.1: Visualisasi perbedaan container dengan virtual machine

  Pada virtual machine mencakup aplikasi, library dan binary, serta seluruh guest OS, dimana bisa mencapai puluhan GB data.

  container

  Sedangkan terdapat aplikasi dan semua pendukungnya, tetapi membagi kernel dengan container lainnya, menjalankan aplikasi yang terisolasi pada host operating system.

  

container Docker tidak terikat dengan infrastruktur tertentu:

  mereka dapat dijalankan pada komputer manapun, pada infrastuktur apapun, dan di cloud.

2.3 Python

  Python[5] adalah bahasa pemrograman interpretatif memiliki tingkat keterbacaan yang baik. Python diklaim sebagai bahasa yang menggabungkan kapabilitas, kemampuan, dengan sintaksis kode yang sangat jelas, dan dilengkapi dengan fungsionalitas pustaka standar yang besar serta komprehensif. Python mendukung beragam paradigma pemrograman, seperti pemrograman berorientasi objek, pemrograman imperatif, dan pemrograman fungsional. Python dapat digunakan untuk berbagai keperluan pengembangan perangkat lunak dan dapat berjalan di berbagai platform sistem operasi.