Enlarging System Design Cheat Sheet — Part 1 : SAGA and CAP theorema
Sudah lama tidak menulis hal teknis mengenai dunia software engineer, kali ini saya tertarik dengan postingan dari Rajiv Ranjan mengenai System Design Cheat Sheet yang saya baca di situs profesional media LinkedIn https://www.linkedin.com/feed/update/urn:li:activity:7220974000770822144?utm_source=share&utm_medium=member_desktop
Dalam postingan tersebut Rajiv Ranjan membuat dokumen slide mengenai System Design yang dirangkum dalam sebuat catatan kecil yang biasa disebut “cheat sheet”. Kenapa disebut “cheat sheet” karena catatan kecil tersebut sering kita gunakan untuk mencontek pada saat ujian :) materi yang dituliskan dirangkum sedemikian rupa sehingga hanya intisari atau poin pokoknya saja.
Oke, kita sudahi saja penjelasan tentang “cheat sheet” karena tulisan ini tidak membahas tentang cheat sheet, melainkan mengenai System Design.
Dalam System Design Cheat Sheet yang dibuat oleh Rajiv, terdapat 30 point yang beberapa diantaranya mungkin sudah kita gunakan dan beberapa yang lainnya mungkin belum. Kesemua point tersebut bisa kita gunakan untuk mendukung penyelesaian masalah pada pekerjaan kita.
30 point pada Design System Cheat Sheet sebagai berikut :
- Distributed transaction has to be handled
- High Availability and Consistency Trade-Off
- Decouple read & write for high performant system
- To build reliable & robust system
- Concurrency in distributed system
- Need coordination & synchronization in distributed system
- Detection failure in Distributed Systems
- Need ACID Compliant Database
- Have unstructured data & doesn’t require ACID properties
- If database need to be scaled
- High-Performing Database Queries Optimization
- If the system has a single point of failure
- For Fault-Tolerance and Durability
- To distribute network traffic to get high availability, performance, & throughput
- Over fetching & under fetching of data
- For a Low Latency or ReadHeavy System
- If we are dealing with a write-heavy system
- High performant search and query
- Static content delivery with enhanced Performance, Scalability & Security
- Better scalability and fault tolerance system
- If need to have bulk job processing
- Preventing from DOS Attacks
- Centralized entry point for managing and securing API requests
- Need real-time or streaming system
- Bi-directional and real-time communication between a client and server
- If data integrity need to be ensured
- Peer-peer communication, Decentralized Data Transfer and eventual consistency
- Efficient and scalable approach to data distribution in distributed systems
- Handling Large Data in Network Requests
- To handle traffic spikes ondemand
Cukup banyak, mari kita bahas satu persatu…
- Distributed transaction has to be handled
Dalam permasalahan design system khususnya pada sistem terdistribusi (distributed system), kadang kita ingin atau perlu menggunakan atau menghandle proses transaksi data yang mekanismenya juga terdistribusi (distributed transaction). Dalam proses ini kita bisa memikirkan penggunaan proses 2-phase commit (proses komit 2 fase) atau bisa juga menggunakan pola saga (saga pattern). Mari kita bahas satu persatu..
a. 2-Phase Commit
2-phase commit atau disingkat menjadi 2PC adalah protokol transaksi terdistribusi yang memastikan konsistensi dan integritas data di beberapa node dalam sistem terdistribusi. 2PC adalah jenis protokol commit terkecil (atom) atau disingkat ACP (Atomic Commit Protocol) yang umumnya digunakan untuk mengkoordinasikan dan menyinkronkan transaksi dalam basis data. 2PC memastikan bahwa ketika transaksi berakhir, semua perubahan pada semua sumber daya akan dikomit sepenuhnya atau dibatalkan tanpa efek samping apa pun.
Fase-fase dalam 2-Phase Commit terdiri dari:
1. Fase persiapan (Preparation Phase)
Node koordinator menerima permintaan transaksi dan mengirim pesan persiapan ke semua node partisipan. Pada fase ini terdapat proses yang memastikan bahwa semua pengelola sumber daya telah menyimpan pembaruan transaksi ke penyimpanan yang stabil. Koordinator juga meminta agar semua node partisipan lainnya bersiap untuk melakukan atau membatalkan transaksi.
2. Fase komitmen (Commit Phase)
Pada fase ini, tergantung respon dari node partisipan, koordinator mengirim pesan commit atau pembatalan (abort). Semua node kemudian melakukan commit atau pembatalan (abort) pada transaksi.
2PC menstandardisasi atomicity, consistency, isolation, dan durability yang disingkat ACID dari suatu transaksi data.
b. SAGA pattern
Oke, solusi lainnya dalam menghandle transaksi data pada sistem terdistribusi adalah dengan penerapan pola SAGA (SAGA pattern). Lalu apa itu SAGA pattern, apakah sebuah hewan mamalia, atau hewan berkaki seribu?
Saga adalah serangkaian transaksi lokal. Setiap transaksi lokal memperbarui basis data lokal menggunakan kerangka kerja transaksi ACID yang sudah kita bahas sebelumnya. Proses transaksi selanjutnya melakukan pengiriman sebuat event yang digunakan untuk memicu transaksi lokal berikutnya dalam Saga. Jika transaksi lokal gagal, maka Saga akan menjalankan serangkaian transaksi kompensasi atau biasa dikenal dengan rollback dimana yang dilakukan pada proses ini adalah membatalkan perubahan yang telah diselesaikan oleh transaksi lokal sebelumnya.
Saga pattern merupakan sebuah pendekatan transaksional asinkron yang pada akhirnya data yang tersimpan akan bersifat konsisten, saga pattern sesuai diimplementasikan pada aplikasi dengan arsitektur microservice, di mana transaksi terdistribusi dilakukan oleh serangkaian transaksi asinkron didalam setiap service.
Koordinasi pada saga pattern
Terdapat “dua cara” yang bisa dilakukan di dalam mengimplementasikan saga pattern, proses implementasi ini berdasarkan dari logika yang mengkoordinasikan service didalam saga. “Dua cara” tersebut adalah :
- Saga berbasis koreografi (Choreography based)
- Saga berbasis orkestrasi (Orchestration based)
Baik, mari kita bahas satu persatu..
b.1. Event Koreografi
Ciri khas implementasi saga pattern menggunakan koreografi event yaitu tidak adanya sistem terpusat, artinya setiap service dapat mengirimkan dan juga menerima sebuah event yang datang, terlepas apakah event tersebut diproses atau tidak.
Koreografi event pada saga pattern akan berakhir jika service terakhir yang terlibat dalam proses transaksi tidak melakukan pengiriman event apapun yang kepada service lain yang terlibat didalam saga pattern.
Pada koreografi event, proses pembatalan sebuah transaksi atau biasa disebut dengan proses rollback dilakukan dengan cara mengirimkan sebuah event yang berbeda dengan event yang digunakan pada proses pembuatan transaksi sebelumnya.
contoh koreografi event pada proses registrasi user wallet:
a. alur positif :
- CREATE_USER
- CREATE_WALLET
- INSERT_AMOUNT
b. alur negatif (failed) :
- REMOVE_WALLET
- REMOVE_USER
Keunggulan dan kekurangan koreografi event pada saga pattern
a. Keunggulan koreografi event
Desentralisasi kontrol: Koreografi menggunakan pendekatan terdesentralisasi yaitu setiap layanan bersifat otonom (berdiri sendiri) serta bertanggung jawab terhadap apa yang dikerjakan atau diproses. Implementasi koreografi event dapat meningkatkan skalabilitas dan toleransi terhadap kesalahan.
Tidak saling terikat (Loosely coupled) : Service yang tergabung dalam transaksi saling terkait akan tetapi tidak secara langsung, dikarenakan pada prosesnya terdapat lapisan komunikasi yang digunakan untuk mengirimkan sebuah event yang memisahkan antara satu service dengan service yang lain. Hal ini meningkatkan fleksibilitas, sehingga memungkinkan service untuk berkembang secara independen tanpa menyebabkan gangguan pada sistem.
Selaras dengan aplikasi tipe Event-Driven-Architecture: Implementasi koreografi event selaras dengan aplikasi tipikal Event-Driven-Architecture, yaitu setiap service dapat menerima serta bereaksi terhadap sebuah event dan memicu proses atau tindakan selanjutnya. Model ini sangat cocok digunakan pada sebuah sistem yang memerlukan pemrosesan dan respons realtime.
Sudah hukum alam bahwa setiap keunggulan akan selalu dibarengi oleh kekurangan, akan tidak adil bilamana tidak menuliskan kekurangan pada implementasi koreografi event.
b. Kekurangan koreografi event
Kompleksitas dalam koordinasi: Seiring dengan bertambahnya jumlah service, pengelolaan interaksi melalui koreografi dapat menjadi sangat rumit. Untuk memastikan semua service dapat menangani event yang relevan memerlukan perencanaan yang cermat.
Tantangan pada proses debugging dan monitoring: Seperti yang sudah kita ketahui bahwa koreografi event tidak mempunyai titik kontrol pusat sehingga proses penelusuran data serta proses diagnosis masalah dapat menjadi sulit. Proses logging dan monitoring yang efektif sangat penting untuk mempertahankan visibilitas ke dalam sistem.
Terdapat potensi keterikatan antar service: Meskipun implementasi koreografi event mendorong keterikatan secara tidak langsung antar service melalui lapisan komunikasi yang menghubungkan service, akan tetapi hal tersebut tidak menutup kemungkinan masih dapat menyebabkan keterikatan langsung antara satu service dengan service yang lain bilamana proses yang dilakukan oleh satu service sangat bergantung kepada satu service yang lain walaupun dipisahkan oleh lapisan komunikasi event.
Selain implementasi koreografi, ada juga implementasi orkestrasi. Selanjutnya kita akan bahas mengenai orkestrasi.
b.2. Orkestrasi Event
Salah satu hal yang jelas membedakan antara koreografi dan orkestrasi adalah bilamana koreografi tidak mempunyai kontrol artinya setiap service dapat berdiri sendiri (independent), maka orkestrasi adalah sebaliknya. Pada implementasi orkestrasi, sistem mempunyai sebuah service yang menjadi pengontrol atas service-service yang lainnya. Pada implementasi orkestrasi, orkestrator mengarahkan aliran event, memanggil service sesuai kebutuhan untuk mencapai proses bisnis.
Ketika terjadi masalah yang berujung pada terjadinya pembatalan transaksi, maka service yang mengalami kegagalan akan mengirimkan sebuah response event gagal yang selanjutnya akan diterima dan di proses oleh pusat kontrol atau orkestrator, selanjutnya orkestrator akan melakukan orkestrasi proses pembatalan kepada service-service terkait.
Keunggulan dan kekurangan orkestrasi event pada saga pattern
a. Keunggulan orkestrasi event
Kontrol Terpusat: Orkestrasi menyediakan satu titik kontrol yang menyederhanakan pengelolaan interaksi. Penerapan kontrol terpusat dapat memudahkan dalam penerapan serta pengelolaan proses bisnis.
Penyederhanaan penanganan kesalahan (error handling): Dengan orkestrasi terpusat, proses penanganan kesalahan (error handling) serta proses pengembalian transaksi atau disebut proses rollback menjadi lebih mudah. Pada implementasi orkestrasi, sebuah orkestrator dapat mengelola proses pengulangan (retry), pembatalan transaksi (rollback), serta alur proses alternatif.
Peningkatan visibilitas: Implementasi orkestrasi menawarkan visibilitas yang lebih baik pada keseluruhan aliran. Orkestrator dapat mencatat dan memantau setiap langkah proses yang dilakukan sehingga memungkinkan dalam memberikan informasi mengenai status dan kinerja sistem.
Seperti halnya koreografi, orkestrasi pun mempunyai kekurangan. Kekurangan yang ada pada implementasi koreografi yaitu :
Titik Kegagalan Tunggal (Single-Point of Failure): Setiap sistem mempunyai potensi atas kegagalan atau biasa disebut failure atau error. Kontrol terpusat pada implementasi orkestrasi merupakan perbedaan, keunggulan sekaligus kekurangan, hal ini dikarenakan kontrol pusat yang menjadi pusat pengontrol proses dapat menjadi salah satu titik kegagalan (failure point). Memastikan ketersediaan (availability) serta keandalan (reliability) kontrol pusat akan sangat penting sekali untuk mencegah terjadinya pemadaman di seluruh sistem.
Permasalahan Skalabilitas: Ketika skala sistem ditingkatkan, implementasi orkestrasi dapat menjadi tantangan tersendiri, dikarenakan kontrol yang terpusat setiap hambatan yang terjadi akan membatasi kinerja secara keseluruhan. Desain serta pengoptimalan yang cermat diperlukan untuk mempertahankan skalabilitas.
Keterikatan antara service dengan orkestrator: Keterikatan yang terjadi antara service dengan orkestrator akan menjadi lebih kuat (tightly coupled) meskipun dipisahkan dengan lapisan komunikasi, hal ini akan mengurangi otonomi dan fleksibilitasnya. Perubahan-perubahan yang terjadi pada orkestrasi dapat memengaruhi beberapa layanan, hal ini besar kemungkinan dikarenakan diperlukannya pembaruan yang terkoordinasi didalam sistem.
2. High Availability and Consistency Trade-Off
Slide kedua berbicara mengenai High Availability atau disingkat HA dan mengorbankan pada sisi konsistensi data. Dalam pemilihan tingkat ketersediaan yang tinggi dan mengorbankan sisi konsistensi data, kita bisa menggunakan teorema CAP, mari kita bahas satu-persatu dimulai dengan teorema CAP terlebih dahulu.
Mendesain sistem khususnya sistem terdistribusi merupakan tantangan yang menarik sekaligus berat. Hal ini memerlukan spekulasi dan dasar pemikiran yang cermat.
Teorema CAP adalah salah satu pengetahuan yang harus kita miliki ketika mendesain sistem terdistribusi atau secara lebih spesifik arsitektur microservices. Teorema CAP merupakan salah satu dasar landasan berfikir (dalil) atau pernyataan dalam ilmu komputer yang menjelaskan mengenai database yang terdistribusi.
Didalam teorema CAP dijelaskan bahwa pada sistem database yang terdistribusi tidak akan memiliki lebih dari dua kondisi yang diharapkan terpenuhi dari tiga kondisi berikut, yaitu konsistensi (consistency), ketersediaan (availability), dan toleransi partisi (partition tolerance). Sehingga, dari tiga properties tersebut akan didapat hanya dua kombinasi properties saja yang dapat dipenuhi. Contohnya, CA yang merupakan Consistency dan Availability, CP yang merupakan Consistency dan Partition Tolerance, dan AP yang merupakan Availability dan Partition Tolerance.
Mari kita bahas properties dari teorema CAP satu persatu.
- Availability
Ketersediaan atau dalam bahasa Inggris yaitu availability adalah ukuran dari kinerja sebuah sistem. Availability diukur menggunakan up-time. Sistem yang memiliki up time 90% akan memiliki availability yang lebih tinggi dari pada sistem yang memiliki uptime 80%. Akan tetapi pengertian availability pada teorema CAP agak berbeda sedikit. Pada teorema CAP availability mempunyai arti sebuah sistem atau semua node akan memberikan non error respon setiap waktu. Walau data tidak konsisten, apabila respon yang diberikan bukan respon galat (error), maka sistem akan dikatakan memiliki tingkat availability tinggi. Perlu diperhatikan bahwa respon ini mencakup baik itu respon pada operasi baca (read) maupun respon pada operasi tulis (write).
Tingkat availability sebuah sistem juga terkait dengan lama rentang waktu sebuah sistem memberikan respon atau dikenal dengan response time dalam bahasa Inggris atau bahasa teknis. Apabila response time sebuah sistem terlalu lama maka akan mengakibatkan klien yang mengakses sistem mengalami pengalaman yang kurang baik. Maka dari itu secara tidak langsung availability sistem memiliki ukuran response time yang tinggi dalam artian tidak memerlukan waktu lama dalam memberikan respon.
2. Consistency
Sebuah sistem database terdistribusi biasanya akan melakukan replikasi dari database ke dalam beberapa node. Konsistensi dicapai apabila kita mendapatkan semua data sama pada setiap node pada waktu yang sama. Dengan kata lain, setelah kita melakukan berbagai operasi write ke database kita akan mendapatkan data yang sama ketika melakukan operasi read pada setiap node yang kita akses.
Apabila terjadi perbedaan data maka kita menyebutkan sebagai sistem yang tidak konsisten atau in consistency system. Perlu diperhatikan bahwa konsistensi pada teorema CAP berbeda pengertiannya dengan arti konsistensi pada sistem monolith atau pada konsep ACID database transaksional.
3. Partition Tolerance
Pada sistem terdistribusi, komunikasi antar node dilakukan melalui komunikasi jaringan (network) baik itu menggunakan kabel (wired) ataupun tanpa kabel (wireless). Setiap jaringan dapat mengalami kegagalan baik akibat dari permasalahan fisik ataupun logical. Kegagalan atau permasalahan secara fisik adalah pemasalahan yang terjadi pada perangkat keras (hardware) jaringan, contoh kabel putus. Sedangkan kegagalan atau permasalahan secara logical adalah permasalah yang terjadi lebih kepada perangkat lunak (software), salah satu contohnya proses garbage collection, bug pada code, dan sebagainya.
Sistem dengan partition tolerance yang tinggi adalah suatu sistem yang masih dapat bekerja walaupun komunikasi antar node mengalami gangguan. Setiap node mengetahui terjadinya masalah, dan ketika jaringan komunikasi kembali normal, data yang ada pada setiap node akan disinkronisasi ulang. Perlu diperhatikan bahwa yang dimaksud bukan node yang mati tetapi komunikasi antar node yang terganggu.
Partisi toleransi ini merupakan hal yang paling penting pada sistem database terdistribusi. Sesuai dengan yang sebelumnya kita bahas bahwa dalam teorema CAP kita tidak bisa memilih kesemua properties, hanya 2 kombinasi properties saja yang artinya kita tinggal memilih mana yang akan kita pertahankan dan mana yang akan kita korbankan. Apa itu konsistensi atau availability tergantung kebutuhan dari sistem yang kita rancang.
Referensi :
