Trade-off Distributed Systems

Sepanjang section ini kita memperlengkapi diri: membagi data dengan partitioning, menjaga salinan dengan replication, berkoordinasi dengan leader election, menjaga transaksi dengan 2PC atau saga, dan mempercepat kerja dengan paralelisme. Setiap mekanisme menyelesaikan satu masalah sekaligus membuka masalah baru — konsensus menambah latensi, replikasi menambah biaya penyimpanan, paralelisme menambah mode kegagalan. Distributed systems bukan soal memilih teknologi termaju, melainkan memilih kelemahan yang paling bisa kita tanggung. Bab penutup ini merangkum kerangka trade-off-nya: CAP dan PACELC sebagai peta konsistensi, biaya replikasi sebagai anggaran, dan matriks keputusan untuk mengetahui kapan tidak perlu mendistribusikan sama sekali.

CAP Theorem: Peta Konsistensi vs Ketersediaan #

Jaringan akan terputus — itu satu-satunya asumsi yang boleh kita andalkan. CAP theorem menyatakan: saat partition terjadi, sistem hanya bisa memilih konsistensi (menolak permintaan yang tidak bisa dijawab dengan data mutakhir) atau ketersediaan (tetap melayani dengan data yang berpotensi usang).

Pilihan tersebut berlaku per operasi, bukan untuk seluruh produk.

Contoh konkret: saat partition memisahkan sebagian node dari leader, sistem yang memilih konsistensi menolak tulisan dari node terisolasi; sistem yang memilih ketersediaan tetap menerima lalu merekonsiliasi konflik setelah jaringan pulih — konflik yang kadang harus diselesaikan manual. Label CP dan AP juga sering dipakai terlalu kasar: satu sistem bisa memilih konsistensi untuk penulisan metadata sekaligus ketersediaan untuk pembacaan statistik. Martin Kleppmann merinci jebakan pelabelan ini pada tulisan Please stop calling databases CP or AP .

PACELC memperluas peta tersebut: bila tidak ada partition (else), pilihan berpindah ke latensi vs konsistensi — misalnya replication sinkron menjaga konsistensi dengan menaikkan latensi tulis, sedangkan asinkron sebaliknya, seperti dibahas pada Chapter Replication.

Anggaran Biaya Replikasi #

Trade-off juga berbentuk angka. Skrip berikut menghitung biaya penyimpanan dan peluang kehilangan data untuk beberapa pilihan replication factor, dengan asumsi ilustratif peluang gagal 2% per node per tahun.

"""Simulasi biaya replication factor: penyimpanan vs peluang kehilangan data."""

UKURAN_TB = 100       # volume data mentah
PELUANG_GAGAL = 0.02  # peluang satu node gagal dalam satu tahun (ilustrasi)

print(f"Data mentah {UKURAN_TB} TB, peluang gagal per node {PELUANG_GAGAL:.0%}/tahun")
print()
print(f"{'R':>2} {'penyimpanan':>12} {'semua replika gagal':>20} {'quorum tulis':>13}")
for r in (1, 2, 3, 5):
    penyimpanan = r * UKURAN_TB
    semua_gagal = PELUANG_GAGAL ** r
    quorum = r // 2 + 1  # majority quorum
    print(f"{r:>2} {penyimpanan:>9} TB {semua_gagal:>20.2e} {quorum:>10d}/{r}")

Output yang Dihasilkan:

Data mentah 100 TB, peluang gagal per node 2%/tahun

 R  penyimpanan  semua replika gagal  quorum tulis
 1       100 TB             2.00e-02          1/1
 2       200 TB             4.00e-04          2/2
 3       300 TB             8.00e-06          2/3
 5       500 TB             3.20e-09          3/5

Biaya penyimpanan tumbuh linear, tetapi peluang kehilangan data menyusut eksponensial — inilah alasan R=3 menjadi default lazim. Mari kita telaah baris-baris kode di atas:

1. Baris 3-4 (UKURAN_TB dan PELUANG_GAGAL): parameter simulasi — volume data dan peluang gagal per node per tahun; keduanya angka ilustratif yang mudah diganti sesuai perangkat keras sebenarnya.
2. Baris 11 (semua_gagal): peluang seluruh replika hilang dihitung sebagai PELUANG_GAGAL ** r, karena data baru benar-benar hilang bila setiap replikanya gagal bersamaan.
3. Baris 12 (quorum): majority quorum r // 2 + 1 menentukan jumlah ack minimum agar tulisan sah — dengan R=3, tulisan tetap sah selama 2 dari 3 node menjawab.

Matriks Keputusan Mekanisme #

Rangkuman seluruh section: setiap mekanisme punya masalah spesifik dan harga spesifik.

Cara membacanya: pilih mekanisme dari kolom kiri hanya setelah masalah di tengah benar-benar terjadi, lalu anggarkan kolom kanan sejak awal — bukan setelah insiden pertama.

Kapan Tidak Perlu Mendistribusikan #

Distribusi menggandakan mode kegagalan dan beban operasional: monitoring, deployment, dan debugging semuanya melintasi batas mesin. Kesalahan yang dulu bisa dilacak dari satu log kini tersebar di banyak log dengan jam yang belum tentu sinkron. Sebelum mendistribusikan, periksa dulu tabel berikut.

Diagram tersebut dibaca dari atas: keputusan mendistribusikan selalu dimulai dari bukti kapasitas, bukan dari tren teknologi. Bila jawaban pertama “belum melebihi satu mesin”, solusi termurah dan paling tahan galat adalah memperkuat mesin yang ada.

Sebelum melanjutkan ke section berikutnya, empat pertanyaan ini layak dijawab untuk sistem kita sendiri:

• Berapa volume dan beban kerja sekarang, dan kapan keduanya melebihi satu mesin?
• Operasi mana yang boleh longgar konsistensinya, dan mana yang wajib ketat?
• Berapa anggaran penyimpanan dan latensi yang sanggup dibayar untuk setiap jaminan?
• Siapa yang menjaga klaster dan merespons insiden di luar jam kerja?

Dengan peta trade-off ini, kita siap masuk ke section Pemrosesan Data Skala Besar: menerapkan konsep-konsep tersebut di atas kerangka kerja nyata seperti Spark, mulai dari estimasi kebutuhan memori sampai tuning eksekusi.