- Insinyur sistem terdistribusi dalam banyak kasus belajar melalui luka yang timbul dari kesalahan di lapangan
- Tulisan ini dibuat agar para insinyur baru tidak perlu mengalami luka-luka tersebut
Sistem terdistribusi sering gagal
- Tidak seperti bidang rekayasa perangkat lunak lainnya, sistem terdistribusi memiliki kemungkinan gagal yang tinggi. Terutama kemungkinan kegagalan parsial yang tinggi.
- Insinyur sistem yang belum pernah bekerja di komputasi terdistribusi sering mengusulkan ide seperti "tinggal kirim write ke dua sistem" atau "cukup retry write sampai berhasil"
- Sistem jaringan gagal lebih sering daripada satu mesin tunggal, dan kegagalan seperti ini cenderung bersifat parsial
- Salah satu write bisa berhasil dan yang lain gagal, jadi bagaimana kini mendapatkan pandangan data yang konsisten? Kegagalan parsial seperti ini jauh lebih sulit untuk ditalar
- Masalah seperti switch yang down, leader yang "menghilang" karena garbage collection, atau socket write yang tampak berhasil padahal sebenarnya gagal bisa terjadi. Membaca dari memori lokal jauh lebih andal daripada membaca melalui beberapa switch
- Kita harus "merancang dengan asumsi kegagalan akan terjadi"
Menulis sistem terdistribusi yang tangguh membutuhkan biaya lebih besar
- Untuk membuat solusi terdistribusi yang tangguh, biayanya lebih besar daripada solusi satu mesin.
- Virtual machine dan teknologi cloud memang membuat rekayasa sistem terdistribusi lebih murah, tetapi tetap membutuhkan biaya besar.
- Simulasi berguna, tetapi tidak bisa menyelesaikan semua masalah yang muncul di lingkungan terdistribusi nyata.
Sistem terdistribusi open source yang tangguh itu langka
- Biaya menjalankan banyak mesin dalam jangka panjang menjadi beban bagi komunitas open source.
- Orang yang menulis kode open source sebagai hobi kekurangan sumber daya finansial untuk mengeksplorasi atau menyelesaikan banyak masalah dalam sistem terdistribusi.
- Sebagian masalah memang diselesaikan oleh para insinyur di perusahaan, tetapi prioritas mereka tidak selalu sejalan.
Koordinasi sangat sulit. Hindari koordinasi sebisa mungkin
- Inti dari skalabilitas horizontal adalah independensi. Komunikasi dan konsensus antar mesin harus diminimalkan.
- Setiap kali dua mesin harus menyepakati sesuatu, implementasi layanan menjadi lebih sulit.
- Algoritma Paxos sangat sulit diimplementasikan.
Jika masalah bisa dimuat ke memori, mungkin itu masalah sepele
- Bagi insinyur sistem terdistribusi, masalah yang terbatas pada satu mesin dianggap mudah.
- Jika data berada beberapa switch jauhnya, memproses data dengan cepat menjadi lebih sulit.
"Lambat" adalah masalah yang paling sulit
- "Lambat" bisa berarti satu atau lebih sistem yang menjalankan permintaan pengguna berjalan lambat.
- Kegagalan parsial tidak terlihat di grafik, dan sampai masalahnya menjadi jelas, sering sulit mendapatkan sumber daya yang dibutuhkan untuk menyelesaikannya.
Backpressure harus diimplementasikan di seluruh sistem
- Backpressure berarti sistem penyedia memberi sinyal kegagalan ke sistem peminta, dan sistem peminta tahu bagaimana menangani kegagalan tersebut.
- Tanpa mekanisme backpressure, sangat mungkin terjadi kegagalan berantai atau kehilangan pesan yang tidak disengaja.
Kita harus mencari cara agar sistem tetap tersedia sebagian
- Ini berarti kemampuan untuk tetap mengembalikan sebagian hasil meskipun sebagian sistem gagal.
- Misalnya, sistem pencarian akan mengembalikan hasil yang sudah terkumpul jika tidak dapat mengambil semua dokumen dalam waktu tertentu.
Metrik adalah satu-satunya cara untuk benar-benar menyelesaikan pekerjaan
- Mengekspos metrik adalah satu-satunya cara untuk memahami bagaimana sistem benar-benar bekerja.
- File log memang berguna, tetapi sering kali berbohong. Log keberhasilan pada kebanyakan kasus bersifat duplikatif sehingga tidak dicatat.
Gunakan persentil, bukan rata-rata
- Persentil lebih akurat dan lebih berguna daripada rata-rata. Rata-rata sering mendorong keputusan yang salah.
Kita harus belajar memperkirakan kapasitas
- Mengetahui berapa banyak mesin yang dibutuhkan untuk menyelesaikan pekerjaan itu penting.
- Misalnya, sering perlu melakukan perhitungan kasar di atas kertas seperti menghitung berapa banyak ID tweet yang bisa disimpan di memori.
Feature flag adalah cara untuk melakukan rollout infrastruktur
- Feature flag adalah cara umum untuk me-rollout fitur baru ke dalam sistem.
- Dengan feature flag, kita bisa membangun kepercayaan diri terhadap proyek dan mengurangi biaya kegagalan.
Pilih ruang ID dengan bijak
- Ruang ID dalam sistem membentuk struktur sistem tersebut.
- Misalnya, ID tweet pada Twitter API hanyalah angka 64-bit sederhana, tidak terikat dengan data lain.
Manfaatkan data locality
- Menjaga pemrosesan dan caching data tetap dekat dengan penyimpanan persisten akan lebih efisien.
- Jaringan mengalami lebih banyak kegagalan dan latensi daripada pointer dereference dan fread(3).
Menulis kembali data cache ke penyimpanan persisten adalah hal buruk
- Banyak sistem mengalami masalah ini. Terutama pada sistem yang dirancang oleh orang dengan pengalaman sistem terdistribusi yang minim.
Komputer bisa melakukan lebih banyak hal daripada yang Anda kira
- Ada banyak informasi keliru tentang kemampuan komputer dari praktisi yang kurang berpengalaman.
- Web server modern dapat menangani ribuan permintaan dalam beberapa ratus milidetik.
Gunakan teorema CAP untuk mengkritik sistem
- Teorema CAP bukan sesuatu yang digunakan untuk membangun sistem. Namun, ini berguna untuk mengkritik desain sistem terdistribusi.
Ekstrak layanan
- Layanan berarti sistem terdistribusi yang mencakup logika tingkat lebih tinggi daripada sistem penyimpanan.
- Mengekstrak layanan bisa diterapkan lebih cepat dan lebih mudah daripada membuat library.
Ringkasan GN⁺
- Rekayasa sistem terdistribusi berbeda dari bidang rekayasa perangkat lunak lain karena kemungkinan kegagalan yang tinggi dan adanya kegagalan parsial.
- Menulis sistem terdistribusi yang tangguh membutuhkan biaya lebih besar dan jarang terlihat di komunitas open source.
- Penting untuk memahami dan mengimplementasikan konsep seperti koordinasi, data locality, backpressure, dan ketersediaan parsial.
- Dengan menggunakan metrik dan persentil, feature flag, serta pemilihan ruang ID yang tepat, efisiensi dan stabilitas sistem dapat ditingkatkan.
- Gunakan teorema CAP untuk mengkritik sistem, dan ekstrak layanan saat diperlukan.
1 komentar
Komentar Hacker News
Prinsip CALM (Consistency as Logical Monotonicity) lebih mudah dipahami daripada CAP dan merupakan hasil yang lebih mendasar
Pengiriman tepat satu kali tidak mungkin; harus memilih salah satu antara pengiriman paling banyak satu kali atau paling sedikit satu kali
Artikel yang bagus. Ini tulisan dari 8 tahun lalu, tetapi masih banyak isinya yang tetap relevan
Tautan diskusi lama:
Penjelasannya praktis dan realistis. Tidak ada kata-kata tren seperti "microservices"
Saat bekerja di Lookout, Jeff Hodges mempresentasikan esai ini
Pernah bekerja dengan penulis artikel ini
Banyak hal telah berubah sejak 2013