Back to IF4031 Arsitektur Aplikasi Terdistribusi
Pola Pengelolaan Data dan Ketahanan (Resiliency)
Questions/Cues
Mengapa data jadi tantangan di microservice?
Apa itu pola Database per Service?
Bagaimana menangani transaksi lintas service?
Apa itu Saga Pattern?
Apa itu compensating transaction?
Apa itu pola CQRS?
Mengapa ketahanan (resiliency) penting?
Apa itu Circuit Breaker Pattern?
Bagaimana cara menguji ketahanan?
Apa itu Simian Army dari Netflix?
Reference Points
06-IF4031-05e-2024-Microservice.pdf (hlm. 20-28)
07-IF4031-Microservices.pdf (hlm. 62-65, 71-73)
Pola Database: Mengelola Data Terdistribusi
Dalam arsitektur microservice, setiap layanan harus menjadi pemilik tunggal dari datanya dan hanya dapat diakses melalui API layanan tersebut. Ini mencegah ketergantungan erat (tight coupling) di level database.
1. Database per Service Ini adalah pola fundamental. Setiap microservice mengelola databasenya sendiri. Database ini bisa berupa skema terpisah, atau bahkan server database yang sepenuhnya terpisah. Keuntungannya adalah isolasi total: perubahan skema di satu layanan tidak akan memengaruhi layanan lain. Ini juga memungkinkan setiap layanan memilih jenis database yang paling sesuai untuk kebutuhannya (misalnya, database relasional untuk layanan Order, dan database NoSQL untuk Product Catalog).
Tantangan: Bagaimana cara menjalankan query yang menggabungkan data dari beberapa layanan? Bagaimana cara menangani transaksi yang harus mencakup beberapa layanan?
2. Saga Pattern
Saga adalah pola untuk mengelola konsistensi data lintas microservice tanpa menggunakan transaksi terdistribusi tradisional (yang sangat kompleks dan mengunci sistem). Saga adalah urutan transaksi lokal. Setiap transaksi lokal memperbarui database di dalam satu layanan dan memicu transaksi lokal berikutnya di layanan lain.
Jika semua transaksi berhasil: Saga selesai dan data menjadi konsisten.
Jika satu transaksi gagal: Saga akan menjalankan compensating transactions (transaksi kompensasi) untuk membatalkan atau mengompensasi pekerjaan yang telah dilakukan oleh transaksi-transaksi sebelumnya. Transaksi kompensasi adalah operasi yang secara bisnis membatalkan dampak dari langkah sebelumnya (misalnya, mengembalikan dana, membatalkan pesanan).
3. Command Query Responsibility Segregation (CQRS)
CQRS adalah pola yang memisahkan operasi tulis (Commands) dan operasi baca (Queries).
Command: Bertujuan untuk mengubah state sistem (misalnya,
CreateOrder). Perintah ini dikirim ke model tulis dan database tulis.Query: Bertujuan untuk membaca state sistem tanpa mengubahnya (misalnya, GetOrderHistory). Kueri ini dikirim ke model baca dan database baca, yang sering kali dioptimalkan khusus untuk pembacaan cepat (misalnya, melalui denormalisasi).
Pola ini sangat berguna di microservices karena memungkinkan database baca untuk mengagregasi data dari beberapa layanan, sehingga mempermudah query yang kompleks tanpa melanggar prinsip Database per Service.
Pola Ketahanan (Resiliency): Merancang untuk Kegagalan
Dalam sistem terdistribusi, kegagalan (layanan tidak tersedia, latensi jaringan tinggi) adalah hal yang tak terhindarkan. Arsitektur harus dirancang untuk menangani kegagalan ini dengan anggun.
1. Circuit Breaker Pattern
Pola ini mencegah aplikasi berulang kali mencoba melakukan operasi yang kemungkinan besar akan gagal, sehingga tidak membuang sumber daya dan memperburuk masalah.
Analogi: Seperti sekring listrik di rumah.
Cara Kerja:
Closed: Status normal. Permintaan diizinkan melewati ke layanan dependen. Jika jumlah kegagalan melebihi ambang batas, breaker akan “trip” dan beralih ke status Open.
Open: Permintaan langsung gagal tanpa mencoba memanggil layanan dependen. Breaker akan mengembalikan error atau fallback (misalnya, data dari cache). Setelah periode timeout, breaker beralih ke status Half-Open.
Half-Open: Sejumlah kecil permintaan percobaan diizinkan lewat. Jika berhasil, breaker kembali ke Closed. Jika gagal, ia kembali ke Open.
2. Menguji Ketahanan: The Simian Army
Netflix mempopulerkan konsep Chaos Engineering, yaitu secara sengaja menyuntikkan kegagalan ke dalam sistem produksi untuk menguji ketahanannya. Simian Army adalah sekumpulan tools untuk melakukan ini:
Chaos Monkey: Secara acak mematikan instance virtual machine atau container untuk memastikan layanan dapat bertahan dari kegagalan instance.
Latency Monkey: Menambahkan latensi buatan pada komunikasi jaringan untuk menguji apakah sistem dapat menangani degradasi performa.
Chaos Gorilla: Mensimulasikan kegagalan seluruh Availability Zone di AWS.
Pengelolaan data dalam microservices mengandalkan pola Database per Service untuk memastikan isolasi, dengan tantangan konsistensi data lintas layanan yang diatasi oleh Saga Pattern melalui transaksi lokal dan kompensasi. Di sisi lain, ketahanan sistem terdistribusi dicapai dengan merancang untuk kegagalan menggunakan pola seperti Circuit Breaker untuk mencegah kegagalan beruntun (cascading failures), serta secara proaktif menguji ketahanan sistem terhadap kondisi kacau melalui praktik Chaos Engineering seperti yang dipelopori oleh Netflix dengan Simian Army.**
Additional Information
Implementasi Saga: Koreografi vs. Orkestrasi
Ada dua cara utama untuk mengkoordinasikan saga:
Choreography (Koreografi): Setiap layanan mempublikasikan event ketika menyelesaikan transaksi lokalnya. Layanan lain yang tertarik akan “mendengarkan” event tersebut dan menjalankan transaksi lokal mereka sendiri. Tidak ada titik kontrol pusat. Ini lebih sederhana dan loosely coupled, tetapi sulit untuk melacak alur kerja saga secara keseluruhan.
Orchestration (Orkestrasi): Ada sebuah layanan orchestrator pusat yang bertanggung jawab untuk memberi tahu setiap partisipan saga apa yang harus dilakukan dan kapan. Orchestrator memanggil layanan secara sekuensial melalui command. Ini lebih mudah dipahami dan dimonitor, tetapi menciptakan ketergantungan pada orchestrator dan berisiko menjadi titik kegagalan tunggal (single point of failure).
Implementasi Teknis Circuit Breaker (Hystrix)
Hystrix (sekarang dalam mode maintenance, tetapi konsepnya abadi) adalah library dari Netflix yang mempopulerkan pola ini. Fitur utamanya meliputi:
Bulkheading: Setiap dependensi diisolasi dalam thread pool-nya sendiri. Jika sebuah layanan menjadi lambat, hanya thread pool untuk layanan itu yang akan jenuh, sementara panggilan ke layanan lain tidak terpengaruh.
Fallbacks: Menyediakan logika alternatif yang akan dieksekusi ketika sebuah panggilan gagal, timeout, atau sirkuit dalam keadaan open. Ini bisa berupa data cache, nilai default, atau pesan error yang ramah pengguna.
Real-time Monitoring: Menyediakan dashboard untuk memvisualisasikan kesehatan setiap koneksi, status circuit breaker, dan latensi secara real-time.