Object Storage

Penyimpanan bergaya S3, siklus hidup objek, dan model biayanya.

Daftar isi

Object storage adalah model penyimpanan yang mengelola data sebagai objek, yaitu berkas beserta metadata dan pengenal uniknya, yang disimpan dalam wadah bernama bucket dan diakses melalui API HTTP. Topik ini membahas karakteristik model tersebut, aturan siklus hidup (lifecycle) objek, dan perhitungan biaya bulanan yang menyertainya. Setelah membacanya, batas kelayakan object storage untuk sebuah beban kerja dapat ditentukan dengan lebih tepat.

Karakteristik object storage dan bucket#

Setiap objek terdiri atas tiga bagian, yaitu data itu sendiri, metadata berupa pasangan kunci-nilai seperti tipe konten dan waktu pembuatan, serta pengenal unik yang disebut object key. Bucket menyatukan objek-objek itu dalam satu ruang nama datar. Tidak ada hierarki direktori yang sesungguhnya, karena nama seperti arsip/2026/laporan.pdf hanyalah sebuah kunci panjang, bukan jalur berkas sungguhan.

Perbedaan paling menentukan dengan sistem berkas biasa terletak pada cara pembaruannya. Objek ditulis utuh dan tidak mendukung pengubahan parsial, sehingga mengganti satu karakter di tengah arsip berarti menulis ulang seluruh objek. Tidak pula ada penguncian berkas untuk pembacaan dan penulisan serentak. Sebagai gantinya, object storage dirancang untuk durabilitas, yaitu kemampuan bertahan terhadap kehilangan data, dengan cara mereplikasi objek atau menyimpannya sebagai erasure coding di banyak perangkat.

Model ini cocok untuk cadangan berkala, arsip media, lampiran aplikasi, dan data mentah analitik, yaitu beban kerja yang menulis sekali dan membaca berulang. Sebaliknya, beban kerja yang mengubah baris data terus-menerus lebih tepat diserahkan kepada basis data, karena object storage tidak menyediakan pembaruan parsial maupun transaksi.

Dua fitur turunannya sering dipakai dalam desain. Versi objek (versioning) menyimpan setiap penulisan sebagai versi baru di bawah kunci yang sama, sehingga objek yang tertimpa keliru masih dapat dipulihkan. URL bertanda tangan (presigned URL) memberi klien hak akses terbatas pada satu objek dalam jangka waktu tertentu, sehingga trafik unduh dan unggah dapat mengalir langsung ke object storage tanpa melewati aplikasi.

Siklus hidup dan kelas penyimpanan#

Kelas penyimpanan (storage class) menentukan tarif dan jangkauan akses sebuah objek, dan aturan lifecycle memindahkan objek antarkelas secara otomatis. Aturan tersebut dinyatakan sebagai kebijakan pada bucket, misalnya pindahkan ke kelas jarang diakses setelah 30 hari dan ke kelas arsip setelah 90 hari, atau hapus objek log yang berumur lebih dari satu tahun. Perpindahan ini berjalan tanpa perubahan kode aplikasi karena kunci objeknya tidak berubah.

Tabel berikut membandingkan tiga kelas yang lazim dipakai dalam diskusi arsitektur, dengan nama generik dan bukan nama produk tertentu.

KelasPola akses yang cocokBiaya penyimpananBiaya pengambilan
hotsering, kapan puntertinggitidak ada
warmjarang, harian hingga bulananmenengahkecil
coldhampir tidak pernahterendahmenonjol

Kelas dingin menurunkan tarif penyimpanan dengan cara membuat pengambilan lebih mahal dan lebih lambat, sehingga hanya menguntungkan bagi data yang benar-benar jarang dibaca. Apabila sebuah arsip ternyata diakses setiap minggu, biaya pengambilannya dapat melampaui penghematan tarifnya.

Menghitung model biaya#

Biaya object storage terdiri atas tiga komponen, yaitu penyimpanan per GB per bulan, permintaan (request) yang dihitung per seribu operasi, dan biaya pengambilan pada kelas dingin. Komponen kedua dan ketiga mudah terlewat karena jauh lebih kecil daripada komponen pertama, tetapi tetap tumbuh seiring trafik. Program berikut menghitung biaya bulanan satu arsip cadangan berukuran 2000 GB yang terbagi ke tiga kelas, dengan tarif contoh netral yang mudah dihitung ulang.

python biaya-object-storage.py
"""Menghitung biaya bulanan penyimpanan objek untuk satu arsip cadangan.

Semua tarif berikut adalah angka contoh netral dalam USD yang mudah
dihitung ulang, bukan daftar harga penyedia tertentu.
"""

# (kelas, kapasitas GB, tarif per GB per bulan)
KELAS = [
    ("hot", 500, 0.03),
    ("warm", 1000, 0.012),
    ("cold", 500, 0.004),
]

TARIF_PUT_PER_RIBU = 0.005    # permintaan penulisan
TARIF_GET_PER_RIBU = 0.0004   # permintaan pembacaan
JUMLAH_PUT = 200_000
JUMLAH_GET = 5_000_000
TARIF_AMBIL_COLD_PER_GB = 0.02
GB_COLD_DIAMBIL = 60

total_kapasitas = 0
total_biaya = 0.0
print(f"{'kelas':<6} {'GB':>6} {'USD/GB':>8} {'biaya USD':>10}")
for nama, gb, tarif in KELAS:
    biaya = gb * tarif
    total_kapasitas += gb
    total_biaya += biaya
    print(f"{nama:<6} {gb:>6} {tarif:>8.3f} {biaya:>10.2f}")

biaya_put = JUMLAH_PUT / 1000 * TARIF_PUT_PER_RIBU
biaya_get = JUMLAH_GET / 1000 * TARIF_GET_PER_RIBU
biaya_ambil = GB_COLD_DIAMBIL * TARIF_AMBIL_COLD_PER_GB
total_biaya += biaya_put + biaya_get + biaya_ambil

print(f"kapasitas total     : {total_kapasitas} GB")
print(f"biaya PUT           : {biaya_put:.2f} USD")
print(f"biaya GET           : {biaya_get:.2f} USD")
print(f"biaya ambil (cold)  : {biaya_ambil:.2f} USD")
print(f"total bulanan       : {total_biaya:.2f} USD")
text Keluaran
kelas      GB   USD/GB  biaya USD
hot       500    0.030      15.00
warm     1000    0.012      12.00
cold      500    0.004       2.00
kapasitas total     : 2000 GB
biaya PUT           : 1.00 USD
biaya GET           : 2.00 USD
biaya ambil (cold)  : 1.20 USD
total bulanan       : 33.20 USD

Keluaran memperlihatkan bahwa penyimpanan menyerap 29,00 dari 33,20 USD, sedangkan lima juta permintaan GET hanya menambah 2,00 USD. Angka ini menunjukkan urutan keputusan yang benar, yaitu pilih kelas penyimpanan lebih dahulu, baru kemudian optimalkan jumlah permintaan. Skrip yang sama dapat dipakai untuk menguji skenario lain, misalnya memindahkan seluruh kelas warm ke cold, lalu membandingkan penghematan penyimpanannya dengan tambahan biaya pengambilan yang mungkin timbul.

Kesalahan umum#

  • Memperlakukan object storage seperti sistem berkas. Memperbarui berkas kecil berkali-kali berarti menulis ulang objek utuh berulang kali, sehingga jumlah PUT dan biayanya naik cepat. Perbaikannya adalah mengumpulkan perubahan secara lokal, lalu menulis objek baru dengan kunci berversi.
  • Menyimpan beban kerja yang butuh pembaruan baris dan transaksi. Kebutuhan itu adalah tugas basis data, dan memaksakannya ke object storage hanya menghasilkan lapisan tambahan yang rapuh.
  • Menghitung pemulihan tanpa biaya pengambilan. Skenario pemulihan bencana pada kelas cold mengambil banyak GB sekaligus, sehingga tarif pengambilannya harus masuk ke dalam perhitungan, bukan hanya tarif penyimpanan bulanannya.

Ringkasan#

  • Object storage menyimpan data sebagai objek berisi data, metadata, dan object key di dalam bucket, dengan akses melalui API HTTP dan tanpa pembaruan parsial.
  • Aturan lifecycle memindahkan objek antarkelas penyimpanan berdasarkan umur atau pola aksesnya, sehingga tarif turun untuk data yang makin jarang dibaca.
  • Biaya bulanan dirangkai dari penyimpanan, permintaan, dan pengambilan kelas dingin, dan skenario biaya sebaiknya selalu dihitung dengan skrip sebelum keputusan diambil.

Referensi#