BAB IV ANALISIS DAN PERANCANGAN

BAB IV
ANALISIS DAN PERANCANGAN
Bab ini akan membahas mengenai permasalahan yang terjadi pada aplikasi yang
menggunakan arsitektur 3 tier dan strategi penanganan masalahnya.
4.1 Identifikasi Masalah
Arsitektur 3 tier (Gambar IV-1) terdiri dari user interface tier (contoh: web server)
yang menangani masalah tampilan ke client, middle tier yang menangani logika
aplikasi, dan database tier yang menangani masalah persistensi data. Aplikasi jenis ini
mempunyai ciri distrukturkan sebagai gabungan dari komponen-komponen yang
mempunyai hubungan yang diletakkan di dalam suatu container oleh application
server. Berbagai macam service yang diperlukan oleh aplikasi seperti transaksi,
persistensi, keamanan, dan konkurensi disediakan melalui container. Dengan cara
tersebut, developer dapat menentukan service yang diperlukan oleh komponen secara
deklaratif tanpa harus mengubah kode komponen secara langsung.
Gambar IV-1 Arsitektur 3 tier
Arsitektur jenis ini juga mendukung konfigurasi yang fleksibel seperti partisi dan
clustering untuk meningkatkan performa dan skalabilitas. Pengunaan replikasi untuk
meningkatkan availabilitas juga dapat diterapkan pada setiap tier tergantung dari
kebutuhan aplikasi. Pada aplikasi yang menggunakan arsitektur tiga tier seperti
diilustrasikan pada gambar IV-1, interaksi antara client dengan web server dilakukan
melalui Internet. Infrastruktur yang mendukung interaksi ini tidak berada di bawah
kendali langsung dari penyedia layanan aplikasi yang umumnya hanya mengurusi web
IV-1
IV-2
tier dan tier berikutnya. Availabilitas dari layanan tersebut dapat ditingkatkan dengan
membuat setiap tier tereplikasi. Diantara tier-tier yang disebutkan di atas, middle tier
dan database tier merupakan komponen yang paling penting karena middle tier
merupakan tempat melakukan komputasi logika aplikasi serta database tier
merupakan tempat penyimpanan data persisten. Pada Bab I bagian latar belakang
telah dijelaskan mengenai replikasi di middle tier beserta alasan pemilihannya sebagai
fokus tugas akhir ini.
Satu konsep yang penting yang harus diperhatikan dalam melakukan replikasi adalah
suatu transaksi hanya dieksekusi sekali. Contohnya pada online shop dimana
pelanggan dapat melihat katalog, memilih item dan memasukkan ke shopping cart,
dan pada akhirnya memesan dan membayar dengan kartu kredit. Aktivitas tersebut
melibatkan data transaksional (stok, validasi kartu, data pelanggan) yang terletak di
berbagai database server. Dalam contoh tersebut, sistem harus menjamin transaksi
tersebut hanya dilakukan sekali (sifat atomik) walaupun terjadi kegagalan sistem.
Tanpa ada jaminan tersebut, pesanan pelanggan dapat terduplikasi atau dapat
kehilangan pesanan tanpa mengetahuinya.
Vendor dari application server di middle tier umumnya menyediakan solusi clustering
untuk meningkatkan performa (melalui load-balancing ) dan skalabilitas. Sistem yang
ter-cluster memungkinkan penggunaan banyak server untuk menangani banyak client
yang pada akhirnya akan meningkatkan throughput dari sistem. Permasalahan muncul
karena penanganan failover pada cluster system ini terbatas untuk jenis komputasi
yang stateless (request yang tidak memodifikasi state yang tersimpan di application
server) sedangkan mid-tier server juga membutuhkan penanganan failover untuk
komputasi yang stateful.
Meskipun masalah penanganan failover untuk komputasi yang stateful dapat diatasi
dengan replikasi komputasi di mid-tier, masalah lain muncul di sisi database tier yaitu
untuk sistem yang tereplikasi, jika terjadi kegagalan pada middle tier server, backup
dapat mengambil alih komputasi dan meneruskan transaksi yang gagal. Namun yang
menjadi masalah adalah saat terjadi kegagalan, semua transaksi yang aktif akan
dibatalkan oleh database server, meskipun client mungkin telah menerima hasil
IV-3
eksekusi request yang merupakan bagian dari transaksi yang batal tersebut. Saat
transaksi tersebut dieksekusi oleh backup mid-tier server, mungkin saja eksekusi
transaksi ini menghasilkan data yang berbeda dengan transaksi asalnya karena apabila
koneksi antara middle tier dengan DBMS terputus, semua lock pada data akan dilepas
sehingga ada kemungkinan client lain yang mempunyai prioritas yang lebih tinggi
untuk melakukan transaksi daripada backup server melakukan perubahan terhadap
data tersebut.
AS1
DBMS
AS1:
-Start Transaction
-Statement A
-Statement B
-Crash
AS2:
-Statement C
-Statement D
-Commit
AS2
Gambar IV-2 Skenario Permasalahan
Permasalahan yang dijelaskan di atas dapat disederhanakan ke dalam skenario sebagai
berikut.Seperti terlihat pada gambar IV-2 ,AS1 adalah Application Server pertama
yang menjadi master dan AS2 adalah Application Server kedua yang menjadi backup.
AS1 memulai transaksi, melakukan statement A dan B, kemudian crash. Reaksi
normal DBMS jika terjadi crash pada client adalah melepas lock pada data dan
rollback transaksi. Jika DBMS melakukan hal tersebut maka AS2 tidak dapat
meneruskan transaksi yang dimulai oleh AS1 dan tidak mendapatkan hasil yang
diinginkan.
4.2 Koneksi dan Transaksi pada JDBC
Subbab ini akan menjelaskan bagaimana penanganan koneksi dan transaksi pada
JDBC.
IV-4
4.2.1 Koneksi
API JDBC mendefinisikan interface Connection untuk merepresentasikan koneksi
terhadap suatu basis data. Ada dua mekanisme utama untuk koneksi terhadap basis
data yaitu menggunakan kelas DriverManager atau kelas DataSource.
Contoh
koneksi
jdbc
ke
database
MySQL
dengan
menggunakan
kelas
DriverManager:
String userName = "testuser";
String password = "testpass";
String url = "jdbc:mysql://localhost/test?user="
+ userName
+ "&password="
+ password;
Class.forName ("com.mysql.jdbc.Driver").newInstance ();
conn = DriverManager.getConnection (url);
Pada connection string di atas dapat ditambahkan parameter tambahan seperti
penambahan username dan password untuk otentifikasi.
4.2.2 Transaksi
JDBC tidak menangani secara langsung begin transaction. Agar suatu transaksi dapat
dilakukan, parameter autocommit harus di-set menjadi false dengan cara memanggil
method setAutoCommit(false) dari object connection. Untuk commit suatu transaksi
dipanggil method commit dari object connection sedangkan untuk rollback akan
dipanggil method rollback dari object connection.
Ada beberapa tingkat isolasi pada transaksi dalam kasus transaksi yang konkuren.
Kemungkinan interaksi di antara transaksi yang konkuren dapat dikategorikan sebagai
berikut:
-
dirty read dapat terjadi jika suatu transaksi diperbolehkan melihat perubahan
yang belum di-commit terhadap suatu data. Jika transaksi di-rollback, ada
kemungkinan transaksi yang membaca data tersebut mendapatkan data yang
salah.
-
Nonrepeatable read terjadi ketika:
a. Transaksi A membaca suatu row
b. Transaksi B merubah row yang dibaca oleh A
c. Transaksi A membaca row yang sama yang telah diubah oleh B
IV-5
-
Phantom read terjadi ketika:
a. Transaksi A membaca semua row yang memenuhi kondisi WHERE
b. Transaksi B menambahkan suatu row yang memenuhi kondisi WHERE
c. Transaksi A mengevaluasi ulang kondisi WHERE tersebut dan
mendapatkan row tambahan
Untuk tugas akhir ini tingkat isolasi yang akan digunakan adalah transaction
serializable yang mencegah terjadinya dirty read, nonrepeatable read maupun
phantom read.
4.3 Rancangan solusi
Untuk memudahkan penulisan,pada subbab ini penggunaan istilah client ditujukan
pada middle-tier server dan penggunaan istilah server ditujukan untuk database
server.
Dari identifikasi masalah pada subbab 4.1 dapat disimpulkan dua masalah penting
dalam melakukan replikasi di middle tier yaitu
-
tidak boleh terjadinya duplikasi dalam pengiriman request dari client ke server
-
kegagalan di middle tier tidak boleh menyebabkan database server
membatalkan transaksi yang sedang berlangsung.
Masalah pertama diasumsikan sudah ditangani di application server dan tidak
menjadi fokus dalam tugas akhir ini. Untuk menangani masalah kedua yang menjadi
fokus dalam tugas akhir ini, diperlukan solusi untuk pembentukan koneksi backup dan
solusi dalam penanganan failover. Pendekatan yang dipilih untuk memodelkan
replikasi di middle tier dan menangani masalah yang kedua adalah strategi primarybackup. Pemilihan strategi primary-backup disebabkan strategi ini merupakan yang
umum dan praktikal digunakan untuk memodelkan replikasi di middle tier [BUD93].
Alasan lainnya adalah karena proses yang terjadi di application server bersifat non
deterministik (input yang sama mungkin menghasilkan hasil yang berbeda) sehingga
tidak cocok apabila digunakan metode active replication yang mengharuskan server
yang bersifat deterministik[SCH90].
IV-6
4.3.1 Asumsi
Ada beberapa asumsi yang harus diberikan dalam pembuatan rancangan solusi:
1. Fail over di sisi client sudah ditangani (backup mengetahui primary crash,
mengetahui state terakhir primary dan meneruskan transaksi yang terputus)
2. Tidak ada duplikasi statement yang dikirimkan oleh client ke server (Exactly
Once Execution/Transaction).
4.3.2 Solusi Koneksi Backup
DBMS standar akan memperlakukan setiap koneksi sebagai koneksi yang unik dan
tidak berhubungan antara koneksi yang satu dengan koneksi yang lain. Agar suatu
client menjadi backup dari client utama (primary), maka client harus memberitahu
bahwa koneksi yang akan dibentuk merupakan backup dari koneksi utama. Ada
beberapa solusi untuk memberitahu server bahwa koneksi yang akan dibentuk adalah
koneksi backup.
Solusi pertama adalah menambahkan field baru pada client authentication packet
yang berisi id koneksi utama. Pada saat client utama melakukan koneksi ke server,
client utama akan menyimpan id koneksi sehingga sebelum client backup melakukan
koneksi ke server, client backup dapat meminta id koneksi utama dari client utama
yang diperlukan untuk melakukan koneksi ke server. Kelebihan dari solusi ini adalah
client backup bebas menentukan client mana yang menjadi primary-nya.
Kekurangannya adalah menambah overhead pembentukan koneksi karena ukuran
paket diperbesar dengan menambahkan field “id koneksi utama”, selain itu solusi ini
juga mengharuskan perubahan di JDBC driver.
Solusi kedua adalah menggunakan field “user” yang sudah tersedia pada client
authentication packet. Field “user” yang merupakan login name yang dimasukkan
ketika
client
melakukan
koneksi
ke
server
dapat
dimanfaatkan
dengan
mengasumsikan bahwa client pertama yang melakukan koneksi dengan nama user
tertentu menjadi client primary. Kemudian client lain yang melakukan koneksi
dengan nama user yang sama dengan client utama setelah client utama terbentuk akan
disebut sebagai client backup. Kelebihan dari solusi ini adalah tidak adanya
IV-7
penambahan ukuran paket serta lebih sederhana dari solusi yang pertama.
Kelemahannya adalah client backup harus menggunakan login name yang sama
dengan client utama.
Solusi kedua merupakan solusi yang dipilih karena tidak perlu mengubah protokol
dan ukuran paket pada saat handshaking. Selain itu solusi ini dipilih karena umumnya
master dan backup dari sistem yang tereplikasi tergabung dalam satu grup dan
mempunyai identitas unik yang hanya dimiliki oleh grup tersebut. Field “user” pada
client authentication packet dapat menjadi identitas unik dari suatu grup yang
tereplikasi.
4.3.2.1 Struktur Data
Untuk mengimplementasi solusi kedua pada subbab 4.4.2 diperlukan suatu struktur
data global (Gambar IV-3) yang menyimpan informasi mengenai nama grup dan
koneksi. Struktur data yang dipilih adalah struktur data multimap. Struktur data
multimap berbentuk seperti associative array yang berkait dimana key yang berisi
nama yang digunakan untuk login dan value-nya berupa linked list yang menyimpan
objek THD yang menyimpan informasi mengenai koneksi yang berasosiasi dengan
nama sebagai key.
IV-8
Key
Value1
Value2
Nama-1
THD(Master)
THD(Slave)
Nama-2
THD(Master)
Nama-3
Nama-n
Gambar IV-3 Struktur data Multimap
4.3.2.2 Rancangan Penanganan Koneksi
Gambar IV-4 Sequence Diagram penanganan koneksi
IV-9
Gambar IV-4 menjelaskan mengenai interaksi client, mysqld, dan objek THD ketika
terjadi permintaan koneksi baru oleh client. Langkah-langkah yang dilakukan ketika
client menginisiasi koneksi ke mysqld sampai server siap menerima query dari client
adalah sebagai berikut:
-
Client melakukan proses handshaking ke server (mysqld)
-
mysqld akan memanggil fungsi handle_connection_sockets yang memanggil
system call “accept” untuk membentuk koneksi TCP, kemudian menciptakan
thread baru dengan fungsi create_new_thread.
-
Thread baru tersebut memanggil fungsi handle_one_connection yang akan
menangani perintah dari client dan mengurus resource koneksi.
Dari langkah-langkah yang disebutkan di atas dapat disimpulkan bahwa setiap
koneksi akan ditangani oleh sebuah thread. Informasi di thread primary harus dapat
diakses oleh thread backup apabila client primary mengalami kegagalan. Agar
informasi di satu thread dapat diakses oleh thread lain, maka harus ada variabel
global yang dapat diakses secara bersama-sama. Struktur data multimap pada gambar
IV-3 akan digunakan sebagai variabel global yang diakses secara bersama-sama untuk
bertukar informasi. Prosedur Insert_THD merupakan prosedur yang ditambahkan
sebelum handle_one_connection dan berfungsi untuk mengisi key pada struktur data
multimap dengan parameter ”user” kemudian mengkopi objek THD untuk menjadi
value.
4.3.3 Rancangan Solusi Failover
Reaksi standar yang dilakukan MySQL server apabila mendeteksi terjadinya
pemutusan koneksi adalah membereskan semua informasi mengenai dari memory
kemudian mematikan thread yang mengurusi koneksi tersebut. Untuk mencegah suatu
transaksi dibatalkan, maka state transaksi tersebut harus tetap disimpan di dalam
memory walaupun thread tersebut berhenti sehingga thread lain yang menjadi backup
koneksi dapat melihat state tersebut dan melanjutkan koneksi.
Untuk mengimplementasikan solusi tersebut dibutuhkan suatu struktur yang
menyimpan informasi mengenai jumlah client primary yang ada serta jumlah backup
IV-10
dari primary yang bersangkutan sehingga apabila client utama crash, server dapat
mengetahui keberadaan backup dan tidak membereskan resource transaksi yang
tersimpan di memory. Struktur data yang digunakan untuk mengimplementasikan
solusi ini adalah struktur data multimap (Gambar IV-3). Informasi mengenai jumlah
client primary dapat dilihat dari jumlah key pada struktur data multimap sedangkan
keterkaitan antara primary dan backup dapat dilihat dari value multimap yang berupa
linked list, value pertama menyatakan primary dan value-value selanjutnya
menyatakan backup dari value pertama.
Gambar IV-5 Sequence Diagram Pemutusan Koneksi
Gambar IV-5 menjelaskan mengenai interaksi antara client dan objek THD. Kondisi
awalnya adalah client sudah terkoneksi ke server dan objek THD sudah terbentuk dan
siap berkomunikasi dengan client. Fungsi do_command merupakan fungsi yang
membuat thread dalam kondisi blocking dan siap menerima query dari client. Berikut
adalah langkah-langkah interaksi antara client dan THD dari client mengirimkan
IV-11
perintah; client crash sampai objek THD memutus koneksi dan membereskan
resource:
-
Objek THD siap menerima query dari client dengan memanggil method
Do_command()
-
Client mengirimkan perintah start transaction untuk memulai transaksi dan
mengirimkan statement A yang meminta perubahan pada tabel di basis data.
-
Objek THD akan memanggil fungsi Dispatch_command() yang akan
menjalankan query tersebut dan mengirimkan hasilnya kembali kepada client
dalam bentuk result set.
-
Setelah mengirimkan result set ke client, objek THD akan kembali memanggil
fungsi do_command() dan membuat thread kembali berada dalam kondisi
blocking dan siap menerima perintah selanjutnya dari client.
-
Client mengalami kegagalan (crash) setelah menerima result set kemudian
objek THD mendeteksi kegagalan tersebut dan akan memanggil fungsi
close_connection() yang akan membereskan koneksi TCP dan fungsi
end_thread() akan memanggil destruktor dari objek THD.
Fungsi transfer_state() ditambahkan sebelum fungsi close_connection() dan
end_thread() dipanggil. Fungsi tersebut bertujuan untuk mengecek keberadaan
koneksi backup dan apabila koneksi backup ditemukan maka akan dilakukan transfer
state . State yang ditransfer merupakan member dari objek THD pada tabel III-1.
Member-member yang ditransfer adalah kelompok lock, basis data, transaksi, dan
handler data.