Durability vs Availability #

Dalam merancang infrastruktur penyimpanan data di cloud, kita sering kali menjumpai istilah durability (ketahanan data) dan availability (ketersediaan data). Meskipun kedua konsep ini terdengar serupa dan sering kali membingungkan bagi pengembang baru, keduanya mengukur parameter kinerja yang sangat berbeda dan dihitung secara independen. Durability menjawab pertanyaan: “Apakah data kita tetap ada dan tidak rusak dalam jangka panjang?”, sementara availability menjawab pertanyaan: “Apakah data kita dapat diakses secara instan saat kita membutuhkannya sekarang?”. Memahami perbedaan mendasar, metrik perhitungan, serta skenario perdagangan (trade-off) di antara keduanya sangat krusial agar kita dapat merancang sistem penyimpanan yang tangguh tanpa membuang-buang biaya operasional cloud secara sia-sia.

Durability: Mengukur Keberadaan Data #

Durability didefinisikan sebagai probabilitas bahwa data yang telah disimpan tidak akan hilang, terhapus, atau mengalami kerusakan (seperti korupsi data biner) dalam jangka waktu tertentu (biasanya dihitung per tahun). Durability berfokus penuh pada integritas fisik data.

Konsep “Eleven Nines” (11 Sembilan) #

Penyedia layanan cloud terkemuka umumnya menawarkan durability hingga 99,999999999% (biasa disebut sebagai eleven nines) untuk layanan object storage mereka. Untuk memahami seberapa tangguh angka matematis ini, mari kita asumsikan skenario berikut:

• Jika kita menyimpan 10.000.000 (10 juta) objek di dalam penyimpanan cloud.
• Dengan durability 99,999999999%, kemungkinan kehilangan secara fisik hanyalah 1 objek setiap 10.000 tahun.

Angka ini jauh melampaui kemampuan ketahanan media penyimpanan lokal atau server NAS tradisional yang dikelola sendiri di pusat data lokal.

Mekanisme Cloud Provider Mencapai Durability Tinggi #

Penyedia cloud tidak mengandalkan keajaiban fisik harddisk tunggal untuk mencapai tingkat ketahanan setinggi ini. Di belakang layar, mereka menerapkan beberapa lapisan teknologi canggih:

1. Replikasi Geografis Terdistribusi (Multi-AZ Replication): Setiap kali kita mengunggah objek, kontroler penyimpanan cloud secara otomatis menduplikasi berkas tersebut ke minimal tiga pusat data fisik yang berbeda (Availability Zones) yang terpisah sejauh puluhan kilometer di dalam satu region.
2. Erasure Coding: Teknik matematika canggih yang memecah satu berkas menjadi beberapa fragmen data ($N$) dan fragmen paritas ($M$). Fragmen-fragmen ini disebar ke puluhan disk fisik yang berbeda. Sistem tetap dapat menyusun kembali berkas asli secara utuh meskipun beberapa disk fisik mengalami kerusakan total secara bersamaan. Formula efisiensinya adalah: $$\text{Redundansi Overhead} = \frac{N + M}{N}$$ Dengan erasure coding, kita memperoleh durability setara replikasi 3x, namun dengan konsumsi ruang disk fisik yang jauh lebih hemat (hanya sekitar 1.2x hingga 1.5x dari ukuran file asli).
3. Active Scrubbing (Background Integrity Check): Sistem penyimpanan cloud secara konstan melakukan pemindaian berkas di latar belakang menggunakan algoritma hashing (seperti MD5 atau CRC32). Jika sistem mendeteksi terjadinya bit rot (kerusakan data biner akibat degradasi media magnetis disk), sistem akan otomatis menghapus fragmen yang rusak dan menyusun ulang fragmen sehat yang baru dari lokasi replika lainnya.

flowchart TD
    Upload["1. Client Upload File"] --> Controller["2. Storage Controller Layer"]
    Controller -->|"Proses Hashing & Hashing Checksum"| Verify["3. Validasi Integritas"]
    Verify -->|"Pecah dengan Erasure Coding (Data + Parity)"| Split["4. Fragmen Data"]
    Split -->|"Distribusikan"| AZ1["Storage Node AZ 1"]
    Split -->|"Distribusikan"| AZ2["Storage Node AZ 2"]
    Split -->|"Distribusikan"| AZ3["Storage Node AZ 3"]

Ancaman Nyata Terhadap Durability #

Meskipun infrastruktur cloud menjamin durability data dari kerusakan hardware, ada satu hal yang harus kita sadari: Provider cloud hanya menjamin ketahanan dari kegagalan infrastruktur mereka, bukan dari kesalahan kita.

• Kesalahan Pengguna (User Error): Jika kode aplikasi kita secara tidak sengaja menghapus sebuah berkas, atau jika akun cloud kita diretas oleh ransomware yang melakukan enkripsi massal, data tersebut akan hilang dari perspektif kita.
• Mitigasi: Kita wajib mengaktifkan fitur Object Versioning, WORM (Write Once Read Many / Object Lock), serta mengaktifkan otentikasi multi-faktor untuk penghapusan objek (MFA Delete) guna memproteksi durability data dari faktor non-infrastruktur.

Availability: Mengukur Aksesibilitas Layanan #

Berbeda dengan durability yang berfokus pada kelangsungan hidup data, Availability mengukur persentase waktu dalam satu tahun di mana sistem penyimpanan cloud aktif secara online dan siap menerima serta melayani permintaan operasi baca (read) dan tulis (write) kita dengan sukses.

SLA Availability dan Batas Downtime #

Availability dihitung berdasarkan Service Level Agreement (SLA) yang ditawarkan oleh penyedia layanan cloud. Untuk melihat seberapa signifikan perbedaan angka desimal di belakang koma, mari kita lihat tabel konversi persentase availability terhadap toleransi waktu mati (downtime) maksimal per tahun:

Jika sebuah layanan penyimpanan cloud menjanjikan availability SLA 99,9%, maka dalam kurun waktu satu tahun, jika total waktu layanan tersebut mati atau menolak request kita melebihi 8,7 jam, cloud provider biasanya akan memberikan kompensasi berupa pemotongan tagihan bulanan (service credit).

Mengapa Angka Availability Lebih Rendah dari Durability? #

Jika kita perhatikan, layanan object storage standard umumnya menawarkan durability sebesar 99,999999999% (11 sembilan), namun availability SLA-nya “hanya” berkisar di angka 99,99% (4 sembilan) atau 99,9% (3 sembilan).

Hal ini terjadi karena menjaga layanan agar selalu dapat diakses secara real-time di jaringan jauh lebih sulit daripada sekadar menyimpan data dengan aman di disk fisik. Availability sangat rentan terhadap gangguan jaringan internet, kegagalan sistem DNS, kegagalan update software pada API Gateway, pemadaman listrik pada switch router pusat data, maupun serangan DDoS (Distributed Denial of Service).

Hubungan dan Skenario Durability vs Availability #

Untuk memantapkan pemahaman kita tentang bagaimana kedua parameter ini bekerja secara terpisah, mari kita analisis matriks skenario berikut:

                  DURABILITY TINGGI
                  ┌───────────────────────────────┬───────────────────────────────┐
                  │ Skenario A:                   │ Skenario B:                   │
                  │ Durability Tinggi             │ Durability Tinggi             │
                  │ Availability Rendah           │ Availability Tinggi           │
                  │ (e.g., Glacier Archive /      │ (e.g., S3 Standard /          │
                  │  Network Partition Quorum)    │  Replicated Multi-AZ SSD)     │
AVAILABILITY ─────┼───────────────────────────────┼───────────────────────────────┼───── AVAILABILITY
   RENDAH         │ Skenario C:                   │ Skenario D:                   │    TINGGI
                  │ Durability Rendah             │ Durability Rendah             │
                  │ Availability Rendah           │ Availability Tinggi           │
                  │ (e.g., Single Local Disk      │ (e.g., In-Memory Cache Redis /│
                  │  tanpa backup & unstable net) │  RAID 0 Storage Node)         │
                  └───────────────────────────────┴───────────────────────────────┘
                                  DURABILITY RENDAH

Skenario A: Durability Tinggi, Availability Rendah (Data Aman, Tapi Susah Diakses) #

Ini adalah skenario yang sangat umum dalam optimasi biaya penyimpanan.

• Contoh 1: Cold Storage / Archive Tier (Glacier): Kita meletakkan berkas di tier ini. Data dijamin sangat aman tidak akan hilang karena disebar ke banyak AZ (Durability 11 Nines). Namun, jika kita ingin membaca berkas tersebut, kita harus mengirimkan permintaan restore terlebih dahulu dan menunggu selama 3 hingga 5 jam sebelum berkas dapat diunduh. Selama waktu tunggu tersebut, availability berkas tersebut bernilai 0% karena tidak bisa diakses secara instan.
• Contoh 2: Kegagalan Jaringan Transit (Network Partition): Misalkan kluster penyimpanan terdistribusi membutuhkan suara mayoritas (quorum 3 dari 5 node) untuk menyetujui sebuah penulisan berkas baru demi konsistensi data. Terjadi gangguan fiber optik sehingga 3 node terisolasi dari jaringan luar. Data pada 5 node tersebut tetap aman (durable), namun sistem terpaksa menolak seluruh request penulisan baru dari client untuk mencegah korupsi data (split-brain). Sistem menjadi tidak tersedia (not available) untuk sementara waktu sampai koneksi pulih.

Skenario D: Durability Rendah, Availability Tinggi (Cepat Diakses, Tapi Mudah Hilang) #

Skenario ini biasa kita gunakan untuk mempercepat kinerja pemrosesan aplikasi.

• Contoh 1: In-Memory Database (Redis tanpa Persistence): Seluruh data disimpan langsung di memori RAM server. Latensi operasi sangat cepat (sub-milidetik) dan siap melayani jutaan request per detik (Availability sangat tinggi). Namun, apabila server mengalami gangguan listrik mendadak atau dilakukan reboot, seluruh data di dalam memori akan lenyap seketika karena RAM bersifat volatil (Durability nol).
• Contoh 2: RAID 0 (Disk Striping tanpa Redundansi): Kita menggabungkan dua harddisk menjadi satu volume untuk melipatgandakan kecepatan baca/tulis data. Kecepatan transfer data sangat tinggi untuk melayani aplikasi (Availability tinggi). Namun, jika salah satu dari kedua disk tersebut mengalami kerusakan fisik kecil saja, seluruh data di dalam volume gabungan tersebut akan langsung rusak total dan tidak bisa diselamatkan lagi (Durability sangat rendah).

Pengaruh Terhadap Pilihan Tier Storage dan Biaya #

Memahami perbedaan ini membantu kita menghemat pengeluaran bulanan cloud secara signifikan dengan mencocokkan karakteristik data kita dengan tier storage yang tepat.

Perbandingan Kelas Penyimpanan Cloud (Object Storage Case Study) #

Analisis Kasus Pemilihan Tier #

1. Kasus 1: Penyimpanan Thumbnail Gambar Profil:
   • Karakteristik: Gambar profil harus selalu bisa diakses cepat oleh pengguna saat mereka membuka aplikasi (butuh availability tinggi). Namun, jika file gambar profil tersebut hilang secara tidak sengaja di cloud, kita masih bisa men-generate ulang thumbnail tersebut dari file gambar master asli yang kita simpan di sistem utama.
   • Tier Terbaik: One Zone-IA atau standard storage dengan replikasi minimal. Kita bisa menghemat biaya hingga 20% karena menurunkan toleransi durability untuk data yang tidak kritis.
2. Kasus 2: Berkas Backup Log Transaksi Finansial:
   • Karakteristik: Log ini wajib disimpan selama 7 tahun untuk mematuhi regulasi pajak negara. Berkas ini tidak boleh hilang satu byte pun (butuh durability ekstra tinggi). Namun, log ini hampir tidak pernah dibaca lagi kecuali jika ada audit resmi dari pemerintah (akses sangat jarang, tidak butuh availability instan).
   • Tier Terbaik: Archive Tier (Glacier Deep Archive). Biaya per GB per bulan sangat murah (hampir 90% lebih hemat dari standard tier), namun data tetap dijamin aman dengan 11 nines durability.

Konsistensi dan CAP Theorem: Dimensi Pelengkap #

Selain durability dan availability, ada dimensi ketiga yang sering dilupakan dalam sistem penyimpanan data terdistribusi di cloud, yaitu Consistency (Konsistensi data).

Dalam ilmu komputer, CAP Theorem menyatakan bahwa dalam sistem penyimpanan data terdistribusi yang terhubung lewat jaringan, ketika terjadi gangguan koneksi (Partition Tolerance / $P$), kita hanya dapat memilih salah satu dari dua jaminan berikut:

• Consistency ($C$): Setiap operasi baca dijamin mendapatkan data penulisan paling terbaru atau mengembalikan error jika data tidak konsisten di semua node.
• Availability ($A$): Setiap request dipastikan mendapatkan respons sukses tanpa jaminan bahwa respons tersebut berisi data paling terbaru.

flowchart TD
    Partition{"Network Partition terjadi?<br>(Koneksi antar node terputus)"}
    Partition -- Yes --> Choice{"Pilihan Arsitektur"}
    Choice -- "Pilih Consistency (CP)" --> CP["Tolak request jika node tidak sinkron<br>(Availability turun)"]
    Choice -- "Pilih Availability (AP)" --> AP["Serve data lama dari node terdekat<br>(Consistency turun)"]
    Partition -- No --> Normal["Sistem berjalan normal dengan C dan A sekaligus"]

Eventual Consistency vs Strong Consistency di Cloud #

• Eventual Consistency: Ketika kita memperbarui objek config.json di cloud, perubahan tersebut membutuhkan waktu beberapa milidetik hingga detik untuk mereplikasi ke seluruh pusat data fisik. Jika aplikasi kita membaca file tersebut sesaat setelah penulisan selesai, ada kemungkinan aplikasi kita akan menerima data versi lama (stale data). Model ini mengutamakan availability jaringan yang sangat tinggi.
• Strong Consistency: Sejak akhir tahun 2020, layanan penyimpanan seperti AWS S3 telah meningkatkan arsitektur mereka untuk mendukung strong read-after-write consistency secara bawaan tanpa tambahan biaya. Setelah penulisan objek baru (PUT) atau pembaruan objek lama (overwrite) sukses mendapat respons HTTP 200 OK, seluruh operasi baca (GET) berikutnya dari mana saja dipastikan akan langsung menerima versi data paling baru. Ini menyederhanakan logika pemrograman aplikasi kita karena kita tidak perlu lagi menulis kode penanganan waktu tunggu replikasi di tingkat aplikasi.

Ringkasan #

• Durability menjamin data tidak hilang secara fisik akibat kerusakan hardware infrastruktur cloud. Diukur dalam persentase ketahanan data (e.g., 99,999999999% / 11 sembilan).
• Availability menjamin data dapat diakses seketika di jaringan saat diklik atau diunduh oleh aplikasi. Diukur dalam persentase uptime pertahun sesuai SLA (e.g., 99,99%).
• Cold storage adalah contoh durability tinggi tapi availability rendah — data dijamin sangat aman tidak akan hilang, namun butuh proses pemulihan (restore) beberapa jam sebelum bisa dibaca.
• In-memory cache (Redis) adalah contoh availability tinggi tapi durability rendah — data dapat diakses super cepat dengan latensi sub-milidetik, namun akan hilang total saat server reboot.
• Provider cloud hanya bertanggung jawab atas durability infrastruktur mereka — kita wajib menjaga durability dari kesalahan internal aplikasi atau pengguna dengan mengaktifkan fitur versioning dan WORM (Object Lock).
• Gunakan CAP theorem untuk memahami kompromi — pilih arsitektur yang mengutamakan konsistensi data ($C$) atau ketersediaan jaringan ($A$) saat terjadi kendala jaringan terdistribusi.

← Sebelumnya: File Storage   Berikutnya: Lifecycle & Data Tiering →