Object Storage #

Object storage adalah model penyimpanan data yang paling identik dengan arsitektur cloud — dan merupakan jenis storage yang paling sering digunakan dalam sistem cloud-native modern. Berbeda dengan media penyimpanan tradisional yang menyajikan data dalam bentuk blok mentah (raw blocks) atau hierarki direktori folder (file system), object storage memperlakukan setiap file sebagai unit data mandiri yang disebut Object (Objek). Setiap objek disimpan dalam sebuah wadah besar terpusat yang disebut Bucket. Objek diakses dan dimodifikasi secara eksklusif menggunakan protokol berbasis API HTTP RESTful (seperti GET, PUT, dan DELETE). Dengan karakteristik penskalaan horizontal yang hampir tanpa batas, durabilitas yang ekstrem, serta biaya yang relatif sangat murah, object storage menjadi fondasi utama untuk berbagai beban kerja modern — mulai dari penampung data lake kecerdasan buatan, penyimpanan backup berkala, hingga distribusi konten media statis skala global.

Mekanisme Kerja: Flat Namespace & Struktur Objek #

Untuk memahami object storage secara mendalam, kita harus membuang jauh-jauh pemahaman mengenai struktur direktori folder tradisional. Di dalam filesystem lokal (seperti NTFS, ext4, atau APFS), sistem operasi memelihara indeks struktur pohon (directory tree) yang kompleks untuk melacak folder dan subfolder.

Sebaliknya, object storage beroperasi dalam model Flat Namespace (Ruang Nama Datar). Di dalam sebuah bucket, tidak ada folder fisik sama sekali. Seluruh objek disimpan secara berdampingan di satu tingkat penyimpanan yang sama.

Filesystem Tradisional (Hierarkis):
  /data/
    ├── users/
    │   ├── profile-123.jpg
    │   └── profile-456.jpg
    └── reports/
        └── 2024-q4.pdf
  
  Akses: Melalui path direktori bertingkat.
  Modifikasi: Bisa mengedit bagian tertentu dari file secara in-place (seek, write).

Object Storage (Flat Namespace):
  Bucket: my-app-storage
    ├── Key: "users/profile-123.jpg"    ← Karakter slash "/" hanya bagian dari 
    ├── Key: "users/profile-456.jpg"      nama (string key), bukan folder nyata.
    └── Key: "reports/2024-q4.pdf"
  
  Akses: HTTP API Request (GET/PUT/DELETE) ke URL endpoint objek.
  Modifikasi: Bersifat atomic/immutable. Tidak bisa edit sebagian file; file wajib di-upload ulang secara utuh.

Anatomi Objek #

Setiap objek yang kita unggah terdiri dari komponen terstruktur berikut:

• Data (Payload): Konten biner dari file itu sendiri (dapat berupa teks, gambar, video, atau binary backup).
• Key (Identifier): Nama string unik yang mengidentifikasi objek tersebut di dalam bucket.
• Metadata: Sepasang kunci-nilai (key-value pairs) yang menerangkan properti objek. Terdiri dari System Metadata (seperti Content-Type, Content-Length, Last-Modified, ETag) dan Custom User Metadata (seperti Author: Budi, Project: Alpha).
• Version ID: Token unik yang digunakan jika fitur pelacakan versi (Versioning) diaktifkan pada bucket.

Konsistensi Data: Eventual vs Strong Consistency #

Salah satu aspek teknis yang sempat membingungkan dalam penggunaan object storage adalah model konsistensi data (data consistency model). Di masa awal cloud (khususnya Amazon S3 sebelum Desember 2020), object storage menganut prinsip Eventual Consistency (Konsistensi Tertunda) untuk operasi pembaruan (overwrite) dan penghapusan (delete).

Skenario Eventual Consistency (Model Lama):
  1. Kita mengunggah berkas "logo.png" versi baru untuk menimpa versi lama.
  2. Ketika client melakukan request GET "logo.png" sesaat setelah proses upload selesai, 
     client tersebut mungkin masih menerima "logo.png" versi lama selama beberapa milidetik 
     hingga detik, sampai data baru berhasil bereplikasi ke seluruh server fisik cloud provider.

Pada Desember 2020, Amazon S3 secara resmi memperbarui arsitekturnya untuk menjamin Strong Read-After-Write Consistency secara penuh tanpa ada penurunan performa atau biaya tambahan. Provider cloud besar lainnya juga mengikuti standar ini.

• Dampak Modern: Sekarang, segera setelah kita menerima respon sukses HTTP 200 OK untuk operasi PUT atau DELETE, request GET berikutnya dari client mana pun di dunia dijamin akan langsung membaca data terbaru. Hal ini sangat menyederhanakan logika pemrograman aplikasi kita karena kita tidak perlu lagi menuliskan skrip polling lock untuk menunggu konsistensi data.

Optimasi Biaya dengan Storage Classes & Lifecycle Policies #

Salah satu keunggulan terbesar dari managed object storage adalah ketersediaan kelas penyimpanan (Storage Classes) yang berbeda berdasarkan frekuensi akses data. Ini memungkinkan perusahaan melakukan optimasi biaya secara signifikan.

Sebagai contoh, AWS S3 menyediakan beberapa kelas penyimpanan utama:

1. Standard: Didesain untuk data aktif yang diakses terus-menerus. Biaya storage paling mahal, tetapi tidak ada biaya retrieval (pengambilan data).
2. Infrequent Access (Standard-IA): Didesain untuk data yang jarang diakses (misal: sekali sebulan), tetapi membutuhkan akses instan saat diperlukan. Biaya storage lebih murah (~50% dari Standard), tetapi dikenakan biaya per GB saat data diunduh (retrieval fee).
3. Glacier Instant Retrieval: Didesain untuk arsip yang jarang diakses (beberapa kali setahun) tetapi membutuhkan waktu respons dalam milidetik.
4. Glacier Flexible Retrieval (Archive): Arsip berbiaya sangat rendah. Proses pengambilan data membutuhkan waktu mulai dari beberapa menit hingga jam.
5. Glacier Deep Archive: Kelas penyimpanan termurah di cloud. Didesain untuk penyimpanan data kepatuhan hukum (compliance) yang hanya diakses sekali dalam beberapa tahun. Proses pengambilan membutuhkan waktu hingga 12 jam.

Kebijakan Daur Hidup (Lifecycle Policies) #

Untuk menghindari pengelolaan pemindahan kelas data secara manual, kita dapat mengonfigurasi Lifecycle Policies Terautomasi yang diatur berdasarkan umur objek:

flowchart LR
    Upload["1. Objek Di-upload (v1.0)"] -->|"Setelah 30 Hari"| IA["2. Pindah ke Infrequent Access (Standard-IA)"]
    IA -->|"Setelah 90 Hari"| Glacier["3. Pindah ke Glacier Archive (Biaya Termurah)"]
    Glacier -->|"Setelah 365 Hari"| Delete["4. Hapus Objek Secara Permanen"]

Fitur Kepatuhan & Transaksi Skala Besar: Object Lock & Multipart Upload #

Untuk kebutuhan tata kelola data perusahaan (enterprise data governance) dan efisiensi pengiriman data berskala raksasa, object storage menyediakan dua fitur penting berikut:

1. Object Lock (Model WORM - Write Once, Read Many) #

Object Lock memungkinkan kita mencegah suatu objek dihapus atau ditimpa selama periode retensi tertentu.

• Jaminan Kepatuhan: Sekali fitur ini diaktifkan pada suatu objek dengan mode Compliance, tidak ada seorang pun (termasuk akun administrator root cloud kita) yang dapat menghapus objek tersebut hingga masa kedaluwarsa berakhir. Fitur ini sangat vital untuk mematuhi regulasi industri keuangan (seperti aturan SEC) dan bertindak sebagai tameng terkuat terhadap serangan ransomware yang mencoba menghapus file cadangan backup kita.

2. Multipart Upload #

Ketika kita harus mengunggah file yang sangat besar (biasanya di atas 100 MB hingga kapasitas maksimal 5 TB), mengunggah file tersebut dalam satu request HTTP tunggal sangatlah berisiko. Jika koneksi jaringan terputus di tengah jalan pada persentase 99%, kita harus mengulang pengunggahan dari nol.

• Mekanisme: Fitur Multipart Upload memecah file besar tersebut menjadi puluhan bagian kecil (parts) secara otomatis, mengunggah bagian-bagian tersebut secara paralel, dan menyatukannya kembali menjadi satu objek utuh di sisi cloud setelah seluruh bagian sukses diterima. Jika salah satu bagian gagal di tengah jalan, kita hanya perlu mengunggah ulang bagian yang rusak tersebut saja, menghemat waktu dan bandwidth.

flowchart TD
    File["File Besar (1 GB Video)"] --> Split["Pecah Menjadi 10 Bagian (100 MB/part)"]
    subgraph ParallelUpload["Parallel HTTP Upload (Part 1 - 10)"]
        Part1["Part 1"]
        Part2["Part 2"]
        Part3["Part 3"]
    end
    Split --> ParallelUpload
    ParallelUpload --> Assemble["Satukan Kembali di Bucket S3"]
    Assemble --> Object["Objek Utuh Mandiri"]

Fitur Keamanan: Bucket Policies dan Pre-signed URLs #

Keamanan data di object storage dikendalikan melalui sistem otorisasi yang sangat fleksibel dan berlapis:

1. Bucket Policies vs IAM Policies #

• IAM Policies: Kebijakan berbasis identitas (identity-based). Digunakan untuk mengatur apa saja yang boleh diakses oleh pengguna atau server (role) tertentu di dalam akun cloud kita.
• Bucket Policies: Kebijakan berbasis sumber daya (resource-based). Ditempelkan langsung pada bucket dan digunakan untuk mengatur akses secara makro — seperti mengizinkan akses unduh publik untuk aset website, atau membatasi agar bucket hanya bisa diakses dari dalam VPC CIDR tertentu.

2. Pre-signed URLs (Signed URLs) #

Dalam arsitektur aplikasi modern, kita sering kali dihadapkan pada skenario di mana pengguna perlu mengunduh file privat (seperti slip gaji PDF) atau mengunggah file besar (seperti video rekaman).

Jika seluruh file tersebut harus diunggah melewati server backend aplikasi kita, server backend akan mengalami kemacetan bandwidth dan CPU karena sibuk menjadi perantara transfer data. Solusi terbaik adalah menggunakan Pre-signed URLs:

sequenceDiagram
    participant User as Browser Client
    participant App as Backend App (Stateless)
    participant S3 as Object Storage (Private Bucket)
    
    User->>App: Minta akses upload file "video.mp4"
    Note over App: Validasi Otorisasi IAM &<br/>Buat Pre-signed URL dengan tanda tangan kriptografi
    App-->>User: Kirim Pre-signed URL (Valid 15 Menit)
    
    User->>S3: PUT /mybucket/video.mp4 (Langsung ke S3 dengan URL bertanda tangan)
    Note over S3: Verifikasi tanda tangan kriptografi<br/>& Terima file video
    S3-->>User: HTTP 200 OK (Upload Sukses)

Dengan pola ini, server backend aplikasi kita hanya bertugas melakukan pengecekan hak akses (authorization), menandatangani URL menggunakan kredensial privatnya secara kriptografis, dan mengembalikan URL sementara tersebut ke client. Client dapat langsung mengunggah file raksasa tersebut langsung ke bucket privat secara aman, membebaskan server backend dari beban transfer data.

Durability Tinggi & Replikasi Jaringan #

Managed object storage di cloud menawarkan tingkat Durability (ketahanan data terhadap kerusakan fisik) yang sangat ekstrem, umumnya mencapai 99,999999999% (11 Nines).

Apa makna matematis dari 11 Nines Durability? Jika kita menyimpan 10.000.000 (10 juta) file di dalam object storage, secara rata-rata kita hanya berisiko kehilangan 1 file saja setiap 10.000 tahun.

Tingkat ketahanan luar biasa ini dapat dicapai melalui teknologi berikut:

• Erasure Coding: Data file yang diunggah dipecah menjadi beberapa fragmen data dan fragmen paritas, lalu disebarkan ke puluhan disk fisik terpisah.
• Multi-AZ Replication: Secara otomatis menduplikasi data kita ke minimal 3 Availability Zone (AZ) yang terpisah secara fisik dalam satu region geografis yang sama. Jika satu data center hancur akibat bencana, data kita tetap utuh di data center lainnya.

Contoh Kode: Membuat Pre-signed URL untuk Upload & Download secara Aman #

Berikut adalah contoh implementasi backend menggunakan Node.js dengan SDK resmi AWS (v3) untuk menghasilkan Pre-signed URL bagi client untuk melakukan operasi PUT (mengunggah) dan GET (mengunduh) file privat secara aman:

// presigned-helper.js
const { S3Client, PutObjectCommand, GetObjectCommand } = require("@aws-sdk/client-s3");
const { getSignedUrl } = require("@aws-sdk/s3-request-presigner");

// ✓ BENAR: Inisialisasi S3 client dengan konfigurasi dari Environment Variables
const s3Client = new S3Client({
  region: process.env.AWS_REGION || "ap-southeast-1"
});

const BUCKET_NAME = process.env.MY_SECURE_BUCKET || "production-private-data";

/**
 * Membuat URL sementara untuk mengunggah file langsung ke S3
 * @param {string} objectKey Nama file tujuan di S3 (misal: 'invoices/user-123.pdf')
 * @param {string} contentType MIME type file (misal: 'application/pdf')
 * @returns {Promise<string>} Pre-signed URL untuk upload
 */
async function generateUploadUrl(objectKey, contentType) {
  try {
    const command = new PutObjectCommand({
      Bucket: BUCKET_NAME,
      Key: objectKey,
      ContentType: contentType
    });

    // Buat pre-signed URL yang kedaluwarsa dalam waktu 15 menit (900 detik)
    const url = await getSignedUrl(s3Client, command, { expiresIn: 900 });
    return url;
  } catch (error) {
    console.error("Gagal membuat upload pre-signed URL:", error);
    throw new Error("Gagal menginisiasi pengunggahan file.");
  }
}

/**
 * Membuat URL sementara untuk membaca/mengunduh file privat dari S3
 * @param {string} objectKey Nama file di S3
 * @returns {Promise<string>} Pre-signed URL untuk download
 */
async function generateDownloadUrl(objectKey) {
  try {
    const command = new GetObjectCommand({
      Bucket: BUCKET_NAME,
      Key: objectKey
    });

    // Buat pre-signed URL yang berlaku selama 30 menit (1800 detik)
    const url = await getSignedUrl(s3Client, command, { expiresIn: 1800 });
    return url;
  } catch (error) {
    console.error("Gagal membuat download pre-signed URL:", error);
    throw new Error("Gagal mengambil tautan unduh file.");
  }
}

module.exports = {
  generateUploadUrl,
  generateDownloadUrl
};

Ringkasan #

• Object storage menyimpan data secara flat namespace tanpa hierarki folder fisik, melainkan menggunakan pengenal string unik (Key).
• Strong consistency menjamin data langsung terbaca sesaat setelah operasi tulis sukses, menyederhanakan arsitektur aplikasi modern.
• Optimalkan biaya dengan memindahkan data yang jarang diakses ke kelas penyimpanan yang lebih murah (Standard-IA/Archive) secara otomatis via Lifecycle Policies.
• Gunakan Object Lock (WORM) untuk melindung data cadangan penting dari modifikasi dan penghancuran oleh virus ransomware.
• Multipart Upload memecah berkas raksasa menjadi bagian kecil untuk mengoptimalkan kecepatan paralel dan menjamin toleransi putus koneksi jaringan.
• Pre-signed URL membagi beban transfer data dengan mengizinkan client mengunggah file langsung ke bucket tanpa membebani server backend aplikasi.
• Durabilitas ekstrem 11 Nines di cloud dicapai dengan mereplikasi data secara otomatis lintas Availability Zones dan menerapkan teknik erasure coding.
• Selalu hindari menaruh file media dinamis di disk lokal VM; gunakan object storage agar komputasi kita tetap stateless.

← Sebelumnya: Load Balancing   Berikutnya: Block Storage →