Andreas

Q: Step apa yang dilakukan untuk dapat membuat sebuah sistem yang sebelumnya lambat menjadi cepat? Apakah ada tips dan triknya?

A: (Sebagai contoh saja) Untuk melakukan migrasi dari Database ukuran Terabyte ke tempat lain yang tidak dalam 1 segmen yang sama. Harus dipindahkan melalui jaringan yg cukup jauh. Untuk pemindahan data yang cukup jauh tersebut perlu memperhatikan latency serta kemampuan mengambil data dan meletakkan data kemudian (pull and push). Walaupun bandwidth yang dimiliki cukup besar dan karena memiliki latency, hal tersebut tidak bisa dipakai (mekanisme standard) secara maksimal. (Dalam konteks ini) Maka dari itu harus menggunakan parallel connection. Setelah menggunakan parallel connection, (pengambilan data) di dump ke koneksi yg baru (yang parallel). Namun, perlu dilakukan antisipasi terhadap latency dengan mekanisme parallel connection.
(Masih banyak tip and trik yang dapat digali, dengan lebih memahami arsitektur teknologi, dari fungsi, keuntungan maupun kerugiannya, maka kita akan lebih bersahabat dengan teknologi tersebut, dan akan lebih mampu meng-”eksploitasi” kegunaannya pada tingkat yang lebih maksimal)

Andreas

Q: Saya tidak bisa Go, C, yang saya tahu hanya PHP ataupun yang lainnya. Apakah teknologi tersebut masih cocok untuk diterapkan performance tinggi dan bagaimana hasilnya?

A: PHP dapat bersifat multithread, tentunya bukan PHP nya yang multithread namun Apachenya. Karena PHP menjadi modul dari Apachenya, sehingga dapat ikut serta multithread. Dengan menggunakan kemampuan multithread Apache, kita bisa dapatkan PHP yang lebih cepat. Dalam proses yang umum, bilamana tidak bisa melakukan multithread dapat disiasati dengan menggunakan multiproses. Namun misalkan dari Scratch ingin membuat sebuah sistem yang handal dan powerfull, saya sarankan tetap menggunakan Go. Karena Go lebih convenient, lebih simple seperti C, dan mudah seperti C++. Kalau Python, Python merupakan interpreter tidak di-compile, sehingga Python tidak dapat membangun thread murni. Bilamana Python digabungkan dengan C, akan menjadi obstacle. Karena tidak bisa meningkatkan performa dan tidak dapat memanfaatkan kemampuan thread dari performa yang besar supaya dapat digunakan bersama-sama. Jika ingin membuat aplikasi dengan performa yang tinggi, sebaiknya menggunakan multithread. Karena context-switching cost nya lebih rendah dan saat sharing resources dapat berjalan lebih cepat.

Budi Hertanto

Q: Dengan perkembangan teknologi khususnya di sisi endpoint (laptop/PC) seperti spesifikasi prosesor, memory dan storage (SSD) yang besar & cepat apakah cukup relevan mengembangkan aplikasi 2-tier atau masih lebih baik mengandalkan aplikasi 3-tier dimana proses masih dilakukan di "middle-tier"? 3-tier ada aplikasi server (middle-tier) antara sisi end-point dengan database server, seperti melakukan kalkulasi ataupun proses logik lainnya, jadi user/endpoint mengirim request ke aplikasi server, aplikasi server kemudian memproses dan mengambil data dari DB server. sementara pada 2-tier seluruh proses kalkulasi tersebut langsung dilakukan di endpoint. 2-tier yang saya maksud seperti misalnya memakai JNLP (Java Network Launch Protocol) di java itu 3-tier, sementara yang 2-tier memakai java2se. keduanya sama-sama akan tampil seperti desktop application di sisi user, tetapi bedanya JNLP ada middle-tier sementara java2se ini cuma 2-tier.

A: Secara sederhana endpoint, web based, desktop application merupakan suatu konteks yang umum dimana aplikasi itu di provide. Baik melalui Internet maupun intranet/lokal net dengan tujuan agar aplikasi memiliki security level yang lebih baik. Dari konteks security, kita tetap membutuhkan web based applications sebagai akses kontrol dan accountability-nya. Penggunaan internet based/web based application dinilai lebih nyaman dibandingkan penggunaan desktop applications.
Java J2SE adalah desktop application dan JNLP adalah desktop application look alike. Tapi sebenarnya lewat network. Kurang lebih sama dengan model endpoint-end user, application, dan database. Menurut hemat kami, maintenance-ability nya agak sedikit menyulitkan. Kita lebih prefer semuanya go to web application. Karena dalam konteks aplikasi bisnis kita tidak melihat kebutuhan adanya computing (power yang besar) di level user. Security dan accountability merupakan hal yang utama daripada harus menciptakan sebuah aplikasi yang memanfaatkan computing power dari segi desktop. Tentunya ini dari sudut pandang bisnis applications.
Kita melihat bahwa terdapat keuntungan dari menggunakan multi 3-tier, dimana kita tidak perlu membuat bisnis logic yang ada di end user. Karena kontrol akan sepenuhnya ada di aplikasi, sehingga perusahaan dapat (meng-)kendali lebih baik terhadap penggunaan aplikasi atau datanya yang mana sedapat mungkin kita tidak meletakkan data di sisi end user.

Andre

Q: Sore Pak, semoga sehat selalu, mau bertanya, tadi sempat dijelaskan soal race condition. Yang dimaksud dengan race condition itu kondisi yang bagaimana ya Pak? Dan bagaimana mitigasinya dalam konteks database? Terimakasih

A: Race condition adalah sebuah konteks (akses bersama namun) lock tidak digunakan. Dalam konteks IT, race condition merupakan kondisi yang tidak dapat dipahami apa hasilnya. Maka, supaya tidak ada race condition (maka) harus ada lock.
Contohnya, ada sebuah variabel A yang akan diakses oleh 3 proses. Supaya tidak ada race condition harus ada lock di antara variabel A dengan 3 proses yang akan masuk, agar proses yang masuk dapat dilakukan satu persatu (bergantian). Kita ibaratkan nilai variabel A adalah 10, kemudian diproses ke-1 ditambah 5, proses ke-2 dikurangi 3, dan proses ke-3 dikurangi 4. Maka berapa hasil A bilamana semua proses masuk bersamaan tanpa Lock? Tidak ada yang tahu pasti hasilnya. Sehingga race condition yang terjadi dapat melanggar integrity data yang ada.

Marvel Elvano

Q: Selamat sore Pak Julyanto, materi yang sangat menarik sekali terkait perancangan sistem bertransaksi tinggi. Pertanyaan saya: Apakah cocok jika kita terapkan microservice architecture untuk mendesain sebuah sistem bertransaksi tinggi?

A: Sangat cocok. microservice architecture merupakan sebuah model architecture yang mudah di scale-up. Namun bilamana membutuhkan latency yang rendah, kita perlu mempertimbangkan apakah microservice nya masih eligible untuk mendeliver sistem transaksi yang latencynya cukup rendah ataukah karena adanya modularity yang perlu di layer dan seterusnya. Sehingga menyebabkan munculnya latency yang lebih tinggi dari monolitik architecture yang dapat menimbulkan down side dari sisi aplikasi itu sendiri. Memang tidak semua dapat menggunakan microservice. Tantangan menggunakan microservice adalah mampu untuk di scale-up dengan sangat baik, namun down side nya memiliki potensial munculnya latency yang tidak dibutuhkan.

Marvel Elvano

Q: Apa saja yang kita perlu perhatikan ketika kita merancang sistem agar dapat menangani concurrency yang tinggi? selain dari peningkatan hardware.

A: Untuk concurrency tinggi yang mesti diperhatikan adalah algoritma yang mengakses resource yang di sharing. Untuk menghindari race condition pada resource yang di sharing, maka diperlukan lock. Lock ini sebetulnya adalah sebuah downside. Resource yang di share ini, sedapat mungkin bisa dibuat tidak diakses secara bersamaan oleh banyak resources. Itu adalah algoritma yang harus dikembangkan. Atau mungkin kita perlu ubah design architecture nya, supaya menghindari atau mengurangi potensi adanya resources yang di share. Karena resources yang di share artinya Lock. Ada sebuah konteks dimana resources dapat di share tanpa Lock, karena resources tersebut bersifat read only. Ada beberapa teknik-teknik, contohnya memahami kapan kita harus menggunakan Map, Array, atau Linked list. Kalau bisa tidak perlu menggunakan linked list. Ketika harus go menggunakan linked list, itu menandakan bahwa sistem memiliki problem yang cukup memusingkan. Dengan menggunakan array, kita tidak membutuhkan lock. Karena disetiap proses yang ada, masing-masing dapat mengakses membernya sendiri. Tidak di lock menjadi satu, namun secara independently mengakses member dari array tanpa harus menggunakan lock. Jadi data dikumpulkan dalam sebuah array, lalu diakses secara concurrency oleh berbagai thread dan independently satu dengan lainnya. Karena tidak adanya potensial race condition, maka tidak membutuhkan pembuatan lock-in.

Anonymous Attendee

Q: Mohon izin Pak terkait sistem transaksi tinggi, umumnya kita harus memilih dua di antara tiga, yakni consistency, availability, dan partition tolerance (sesuai teorema CAP). Berdasarkan pengalaman Bapak, konfigurasi apa yang harus kita pilih bergantung use casenya Pak?

A: Use case apa yang dimaksud? Supaya dapat disampaikan apa konfigurasinya dan suggestion nya. Karena ada banyak sekali kebutuhan, tergantung dari pilihan CAP yang dipilih. Hanya bisa memilih 2 diantara 3 hal tersebut, tidak bisa menggunakan semuanya. Jika ketiganya, akan disebut trilema issue. Kalau berbicara aplikasi bisnis, maka availability adalah yang terpenting. Karena bagaimanapun harus dapat available dan konsisten. Untuk use case di Perbankan, perlu mengedepankan consistency dan availability sehingga tidak ada satu kondisi dimana data hilang ataupun bermasalah. Untuk memperjelas, consistency adalah bagaimana kita memastikan bahwa data yang ada pada setiap instance database tidak berbeda. Sedangkan, availability adalah bagaimana kita mendesain sistem terdistribusi sehingga apabila ada instance yang gagal atau mati, kita tetap dapat mengakses data.
CAP Theorem digunakan sebagai dasar pertimbangan untuk membangun distributed system, termasuk di dalamnya load balancing (clustering) maupun cluster of HA Nodes (Patroni), ini adalah salah satu pendekatan yang bisa digunakan, namun tidak melulu hanya CAP Theorem. Sebagai elaborasi jawaban diatas, maunya tentu availability dan consistency tetap terjaga, meski ada network partitioning, jadi presentasi dan approach yang disampaikan sebetulnya adalah beyond CAP, nanti pada saat implementasi sesuai dengan tingkat kebutuhan bisnisnya barulah kita pertimbangkan CAP, mana yang akan dipilih secara spesifik dan bagaimana mitigasinya (dalam konteks implementasi). Desain sistem yang dibahas sebelumnya, belum mendalam sampai dengan mitigasi dari pertimbangan teorema CAP tersebut.

Anonymous Attendee

Q: Ijin bertanya Pak, bagaimana menjaga database tetap optimal dan dapat bekerja dengan baik dalam beberapa tahun kedepan. Hal-hal apa saja yang perlu dimaintain?

A: Tentunya harus melakukan beberapa hal terkait pada konteks high performance transaction system. Karena adanya transaksi maka ada growth, harus memiliki data yang cukup untuk mengetahui sebesar apa growth yang akan muncul dari sistem yang kita miliki. Bagaimana mengantisipasinya? Apakah cukup dengan meningkatkan physical resources yang ada? Apakah perlu melakukan partitioning? Atau mungkin perlu melakukan clustering?
Biasanya sebelum deploy, akan ada capacity planning dan ada target dari management. Kalau dari management, menggunakan KPI bisnis, sementara tim Teknis menggunakan KPI teknis, dari capacity planning yang kita hitung, tentunya dengan melakukan proses stress test. Ada 2 hal yang harus di access, dari sisi databasenya dan aplikasinya. Untuk database cukup melakukan stress test, kemudian 1 cycle test sehingga kita memiliki data untuk melakukan ekstrapolasi untuk mencapai perhitungan kapasitas planning sampai dengan 5 tahun kedepan. Saya kira lebih susah lagi adalah aplikasi. Bagaimana aplikasi behave, sementara bug nya belum diketahui, belum mature?. Kalau untuk aplikasi, kami sarankan untuk melakukan audit dengan konteks performance. Sebenarnya yang paling susah itu dari sisi aplikasi bukan sisi database. Untuk database sudah ada banyak sekali best practice mitigation nya, yang terkadang terhambat di struktur data aplikasi yang tidak mendukung scalability. Intinya adalah menghitung capacity planning, melakukan assessment, melihat growth- nya, dan sebagainya.

Aleandro Sitanggang

Q: Selain lebih efisien, apalagi ya Pak keunggulan yang didapat jika kita menggunakan micro service architecture dalam merancang sebuah sistem bertransaksi tinggi?

A: Kita tidak menyatakan microservices lebih efisien daripada monolitik. Tergantung konteksnya, baik dari sisi SDLC, design, maupun ekspektasi dari pihak management. Ketika ditengah-tengah penggunaannya, menginginkan perubahan dalam aplikasinya, maka bagi para pengguna monolitik akan merasakan kerepotan. Sedangkan bagi pengguna microservices akan menjadi lebih efisien (mudah, terutama) kalau untuk kebutuhan dengan road map yang belum pasti. Namun untuk kebutuhan road map yang sudah jelas seperti kebutuhan korporasi, tidak diharuskan menggunakan microservices.
Keunggulannya (microservice architecture) adalah kemudahan dalam mengikuti perubahan jaman, yang sangat cocok untuk para startup. Sebetulnya tidak hanya berbicara microservices architecture saja, namun juga bagaimana kita mendesain dan membreakdown masalah tersebut agar tetap scalable. Secara umum design microservices architecture itu fleksibel, dan scalable yang lebih baik (daripada monolithic) walaupun ada downside nya namun itu kecil.

Marvel Elvano

Q: Menyambung kepada pertanyaan soal concurrency dan locking tersebut, jika kita berbicara juga mengenai potensi adanya context switching, seberapa jumlah maximum thread yang optimalnya bisa kita spawn dalam sebuah aplikasi, semisal saya memiliki processor dengan 64 core? misalnya saya spawn worker thread yang tinggi untuk menangani concurrency yang tinggi tersebut. Apakah dengan jumlah thread yang tinggi akan membuat aplikasi saya lebih optimal? atau malah menjadi tidak optimal?

A: Di dalam prosesor ada 64 core, dengan percore nya 2 HT (Hardware Thread). Di OS ada banyak sekali thread yang disebut OS Thread. Tidak ada yang bisa memastikan perbandingan yang sesuai antara hardware thread dengan software thread. Ketika sebuah software thread bekerja, maka akan mengunci 1 hardware thread. Jadi concurrency aktif hanya bisa 128 in the same time. Tidak bisa memastikan tergantung efisiensi thread dalam menggunakan CPU. Kalau context switching-nya ada di OS, maka OS harus diperhitungkan cost nya. Jadi, ada berapa thread yang dapat kita kembangkan dari 64 core? Jawabannya adalah seberapa kita memiliki software thread yang efisien. Umumnya bisnis applications sangat ringan dalam mengkonsumsi CPU resources kecuali database. Yang di dalam database ada indexing, sorting, searching, dan sebagainya yang sangat membutuhkan kemampuan komputasi, kalkulasi, perbandingan data, dan sebagainya. Untuk aplikasi bisnis umumnya thread hanya melakukan memory manipulations tidak melakukan (banyak) komputasi. 1 hardware thread dapat menangani puluhan bahkan ratusan software thread. Tergantung kompleksitas dari software thread dalam memproses data. Kalau banyak sekali memory manipulations nya, maka 1:100 pun masuk akal. Namun kalau software thread nya melakukan kalkulasi semua, maka akan terpakailah semua. Tidak bisa digunakan banyak-banyak. Maksimal hanya sebesar hardware thread yang tersedia, jika OS nya efisien. Selaras dengan OS Linux yang efisien dan preferable, karena kemampuan konteks switchingnya sudah sangat mature dibandingkan unix lainnya.

Nanang - PT. Adyagraha

Q: Bagaimana sistem transaksi kinerja tinggi dapat mempengaruhi perkembangan bisnis global saat ini?

A: Siapa yang cepat dalam memiliki sistem IT yang efisien, dia yang akan menang dalam persaingan. Contohnya perusahaan ekspedisi, kita tidak lagi berbicara tentang quality of services dari layanan yang sudah matang dalam pengantaran barang. Semakin dia memanfaatkan teknologi, maka semakin cepat. Dengan kita memanfaatkan sistem kinerja tinggi, maka kita akan menang dalam persaingan global.

Nanang - PT. Adyagraha

Q: Strategi apa yang harus dilakukan dalam proses pengembangan sistem transaksi kinerja tinggi?

A: Harus ada kepastian bahwa memang dibutuhkan suatu sistem yang berperforma tinggi. Karena membuat sistem transaksi kinerja tinggi seperti membuat internet banking dan lain-lain akan membutuhkan investasi yang besar. Kemudian diperlukan strategi mencapainya, yang tidak kalah pentingnya adalah capacity planning, hingga security nya juga diperhatikan. Ada beberapa hal dari mulai business decision, capacity planning, design architecture yang matang, implementasi, strategi, security, dan termasuk juga scalability nantinya. Bilamana yang dimaksud adalah strategi teknis, jawaban dibawah ini semoga dapat melengkapi.
Secara teknis, untuk membuat sistem transaksi kinerja tinggi harus memperhatikan modularity dari proses bisnis yang didefinisikan, karena dengan dibuat lebih modular maka dapat dilakukan proses pelaksanaan pekerjaan dengan memanfaatkan komputasi parallel, baik dengan menggunakan multiprocess maupun multithread.
Setelah modularity untuk mencapai parallelism, maka perlu diperhatikan koordinasi dan komunikasi antara modul (thread/process) tersebut, dalam hal ini berarti message passing, sinkronisasi, dan koordinasi. Pelajari teknologi apa yang didukung oleh framework yang akan dipakai, diatas sudah kita sampaikan beberapa hal utama yang harus diperhatikan: Load, Latency and Lock.

Nanang - PT. Adyagraha

Q: Apa saja langkah-langkah dalam membangun sistem transaksi kinerja tinggi? dan Apa tahapan saat perancangan sistem transaksi kinerja tinggi?

A: Langkah-langkahnya adalah:

1. Management Goal; Jika manajemen sudah commit, selanjutnya memiliki budget yang akan dibelanjakan untuk membangun sistem transaksi kinerja tinggi tersebut.
2. Capacity Planning; Cara kita mengatur rencana (bisnis) kedepannya. Capacity Planning baru bisa ditentukan jika prototyping sudah dibuat. (karena setelah adanya working model dari aplikasi yang dibangun, barulah dapat dilakukan stress test, dan hasil stress test tersebut menjadi dasar perhitungan perencanaan kapasitas) Dengan memiliki rencana bisnis yang matang, maka kita dapat menentukan investasi kedepannya berdasarkan hasil perhitungan kapasitas tersebut.
3. Design Architecture; Dalam membangun sistem transaksi kinerja tinggi, (umumnya memiliki sifat) sistem yang saling mengunci satu sama lain. Ketika kita membangun dalam bentuk microservices namun didalam modulnya, harus mampu melaksanakan (koordinasi) sistem yang baik dan resource yang digunakan harus mampu dimodularisasi. Tidak asal menggunakan microservices arsitektur tanpa memiliki desain arsitektur utama
4. Implementasi dan Operasionalnya; Pertimbangan prosedur implementasi dan cara pengoperasian sistem tersebut, termasuk prosedur eskalasinya.

Mempertimbangkan kembali maksud pertanyaan diatas, bilamana yang dimaksud mengenai tata cara perancangan sistem transaksi kinerja tinggi, sebetulnya sudah dijelaskan pada materi yang disampaikan, yaitu menggunakan multiproses dan/atau multithreading, dimana perlu juga menggunakan lock bilamana ada resource yang di-share diantara proses tersebut. Tidak lupa mengingatkan untuk memperhatikan latency yang mungkin muncul karena adanya proses decouple antara proses satu dengan proses lainnya.
Bilamana yang dimaksud adalah perancangan arsitektur sistem yang mendukung transaksi kinerja tinggi, tentunya hal ini sangat tergantung pada model bisnis dari aplikasi yang akan dibangun, tidak ada jawaban yang pas untuk model bisnis yang belum diketahui.

Ade Kristo

Q: Pak, seberapa sederhana dan ramah Sistem Transaksi Kinerja Tinggi ini bagi pengguna?

A: Kita tidak berbicara mengenai user interface. Bagaimana nanti sistem transaksi transaksi kinerja tinggi dapat dipakai oleh user itu menjadi scope dari bagaimana user interface. Saat ini kita berdiskusi pada sisi backend yang tidak relate langsung kepada user interface. Untuk memberikan insight kepada para programmer/developer/sistem analis supaya aplikasi yang dikembangkan dapat compile dengan microservices architecture atau mungkin dengan monolitik architecture. Dan mampu memiliki scalability yang tinggi agar mencapai performa tinggi dengan memaksimalkan resource yang ada. Sehingga sistem tersebut dapat kita sebut sebagai sistem transaksi berkinerja tinggi.