S3 Files dan wajah S3 yang terus berubah

• Untuk mengurangi inefisiensi dalam pemindahan data skala besar, diperkenalkan S3 Files yang memungkinkan akses langsung ke data S3 seperti sistem file
• Fitur ini mengintegrasikan Amazon EFS dan S3 sehingga bucket S3 dapat di-mount sebagai NFS dan dibaca-tulis dari EC2, container, Lambda, dan lainnya
• Secara internal, fitur ini menggunakan struktur stage dan commit untuk secara berkala menerapkan perubahan ke S3, serta mendukung sinkronisasi dua arah antara file dan objek
• Bersama S3 Tables dan S3 Vectors, S3 Files menjadi komponen inti yang memperluas S3 menjadi platform data terpadu
• S3 kini berevolusi melampaui sekadar penyimpanan, menjadi ruang kerja terpadu berbasis data yang memberi fondasi bagi developer untuk memanfaatkan data secara langsung

---

Perubahan pada S3 dan desain S3 Files

• Sulitnya memindahkan data dan titik awal S3 Files

  • Proses memindahkan data dalam skala besar telah menjadi sumber inefisiensi yang terus-menerus di berbagai industri, dari riset ilmiah hingga machine learning
  • Dalam kasus riset genomik di UBC, para peneliti menghabiskan banyak waktu untuk menyalin data antara S3 dan sistem file lokal
  • Data friction ini muncul karena berbagai tool mengakses data dengan cara yang berbeda-beda
  • Untuk mengurangi friction tersebut, S3 Files dirancang agar data S3 bisa diakses langsung seperti sistem file

• Pengembangan berbasis agent dan pentingnya data

  • Perkembangan agentic tooling mendorong peningkatan pesat dalam kecepatan dan keragaman pengembangan aplikasi
  • Karena hambatan untuk menulis kode makin rendah, tercipta lingkungan di mana pakar domain dapat membangun aplikasi secara langsung
  • Umur aplikasi makin pendek, sementara data muncul sebagai aset inti yang bertahan dalam jangka panjang
  • Storage tidak lagi sekadar tempat menyimpan, tetapi harus menjadi lapisan abstraksi yang memisahkan data dari aplikasi agar bisa terus dimanfaatkan

Primitive data baru di S3

• S3 Tables

  • Untuk menangani data terstruktur, S3 memperkenalkan S3 Tables berbasis Apache Iceberg
  • Sambil mempertahankan kemampuan Iceberg, layanan ini juga menyediakan perlindungan integritas data, compaction otomatis, replikasi lintas region, dan lainnya
  • Saat ini, lebih dari 2 juta tabel telah disimpan di S3 Tables, dan berbagai aplikasi dibangun di atasnya

• S3 Vectors

  • Perkembangan AI mendorong peningkatan kebutuhan akan indeks vektor
  • Database vektor tradisional menyimpan indeks di memori atau SSD, tetapi pendekatan ini memiliki batasan biaya dan skalabilitas
  • S3 Vectors menyediakan indeks vektor yang sepenuhnya elastis dengan profil biaya, performa, dan durabilitas yang mirip dengan objek S3
  • Layanan ini dapat diskalakan dari ratusan hingga miliaran record, serta menyediakan endpoint API untuk scalar similarity search

Hadirnya S3 Files

• Gambaran umum

  • S3 Files mengintegrasikan Amazon EFS ke dalam S3, sehingga data S3 dapat diakses langsung seperti network file system (NFS)
  • Dari EC2, container, Lambda, dan lainnya, bucket atau prefix S3 dapat di-mount lalu dibaca dan ditulis seperti file biasa
  • Perubahan akan otomatis diterapkan ke S3, sehingga mendukung sinkronisasi dua arah antara file dan objek

• Tantangan desain

  • Sistem file dan object storage memiliki model data yang pada dasarnya berbeda
  • Pada awalnya, EFS dan S3 ingin digabungkan secara sederhana, tetapi yang tersisa hanya “kompromi yang sulit diterima (unpalatable compromises)”
  • File mendukung perubahan granular dan akses bersamaan, sedangkan objek mengasumsikan immutability dan pembaruan per objek secara utuh
  • Sistem notifikasi event S3 memproses lebih dari 300 miliar notifikasi per hari dan bekerja berdasarkan perubahan pada level objek

Prinsip desain Stage and Commit

• Mengubah batasan menjadi fitur

  • Perbedaan antara file dan objek tidak disembunyikan, melainkan dirancang sebagai batas yang eksplisit
  • Perubahan akan di-stage (disimpan sementara) di EFS, lalu secara berkala di-commit ke S3
  • Pendekatan ini terinspirasi dari konsep version control di Git, sehingga memungkinkan kontrol transfer data berbasis waktu dan kebijakan

• Konsistensi dan atomicity

  • Operasi atomik pada sistem file seperti rename dan move, serta pembaruan per objek secara utuh di S3, didukung secara berdampingan
  • Dengan memisahkan kedua lapisan tersebut, sistem dapat mempertahankan model konsistensi masing-masing sambil tetap menyediakan satu tampilan data terpadu

• Manajemen izin

  • Kebijakan IAM di S3 dan izin berbasis inode di sistem file secara struktural berbeda
  • S3 Files memisahkan keduanya melalui pemberian izin di level mount
  • Kebijakan IAM S3 tetap dipertahankan sebagai backstop terakhir, sehingga kontrol akses tetap bisa diterapkan saat batas data berubah

• Ketidakcocokan namespace

  • S3 tidak memiliki konsep direktori, dan delimiter path pun bisa ditentukan secara arbitrer
  • Untuk mengatasi ketidakcocokan dengan sistem file, aturan penamaan dari kedua sisi dipertahankan apa adanya
  • Objek yang tidak kompatibel tidak dipindahkan, melainkan memicu event agar developer dapat menanganinya sendiri

• Performa dan latensi

  • Sistem file dioptimalkan untuk akses berbasis metadata, sedangkan S3 dioptimalkan untuk akses paralel berskala besar
  • Karena sebagian besar workload tidak mengakses file dan objek secara bersamaan, mempertahankan lapisan sinkronisasi lebih realistis dibanding memaksakan penyatuan penuh kedua model
  • Tampilan file mempertahankan konsistensi NFS, tampilan objek mempertahankan strong consistency S3, dan lapisan sinkronisasi berperan sebagai penghubung

Cara kerja S3 Files

• Struktur dasar

  • S3 Files menggunakan EFS sebagai backend untuk menyediakan pengalaman seperti sistem file
  • Saat direktori diakses, metadata S3 diambil untuk membuat tampilan yang tersinkronisasi, dan file berukuran 128KB ke bawah juga langsung memuat datanya
  • File berukuran besar menggunakan lazy hydration untuk mengambil data hanya saat diperlukan
  • Perubahan di-commit ke S3 sekitar setiap 60 detik melalui satu operasi PUT, sambil melakukan sinkronisasi dua arah

• Konflik dan pengelolaan

  • Jika kedua sisi dimodifikasi secara bersamaan, S3 dianggap sebagai source of truth
  • File yang konflik dipindahkan ke direktori lost+found dan dicatat melalui metrik CloudWatch
  • File yang tidak diakses selama 30 hari akan dihapus dari tampilan sistem file untuk mengoptimalkan biaya

• Optimasi performa

  • Melalui fitur read bypass, saat membaca berurutan file besar, data dibaca langsung dari S3 dengan permintaan GET paralel

    • Mencapai throughput 3GB/s per klien, dan pada banyak klien dapat diskalakan hingga kelas terabit

• Batasan dan peningkatan yang direncanakan

  • Karena S3 tidak memiliki operasi rename native, perubahan nama direktori memerlukan salin-hapus seluruh isi
  • Mount yang berisi lebih dari 50 juta objek akan menampilkan peringatan
  • Kontrol commit eksplisit belum disertakan pada versi awal
  • Sebagian object key tidak dapat direpresentasikan sebagai nama file POSIX, sehingga dikecualikan dari tampilan file

Keragaman data dan evolusi S3

• Koeksistensi berbagai cara akses data

  • Seperti pada kasus riset UBC, developer menghabiskan banyak waktu untuk memindahkan data, melakukan caching, dan mengelola nama
  • Tim S3 mendukung secara terpadu berbagai cara mengakses data melalui Tables, Vectors, dan Files
  • Alih-alih menghapus perbedaan antara file dan objek, pendekatan ini mengakui karakteristik masing-masing dan menjadikan batasnya sebagai fitur

• Peran S3 yang makin luas

  • S3 berevolusi dari sekadar object storage menjadi platform storage terpadu yang mendukung berbagai bentuk data
  • Melalui Tables, Vectors, dan Files, data bisa dimanfaatkan langsung sesuai cara kerja yang diinginkan
  • Tujuannya adalah menjadikan storage bukan penghambat pekerjaan, melainkan infrastruktur dasar yang transparan
  • Ke depan, perluasan fitur seperti kontrol stage/commit dan integrasi pipeline akan terus dilanjutkan

• Kesimpulan

  • S3 Files menggabungkan keunggulan file dan objek sambil tetap mempertahankan batas eksplisit di antara keduanya
  • S3, yang dimulai sebagai object storage 20 tahun lalu, kini berkembang menjadi ruang kerja terpadu berbasis data
  • Seperti pesan “Go build!”, S3 kini menjadi fondasi yang memungkinkan developer bereksperimen dan membangun lebih cepat dengan data

[xguru]

Ah, sekarang jadi lebih praktis karena bagian “bacaan terkait” menghubungkan artikel resmi yang relevan dengan baik.
Selama ini saya selalu bingung bagaimana sebaiknya menangani kasus ketika ada tulisan pengantar dan artikel resmi yang terpisah seperti ini,
jadi rasanya menyenangkan karena “bacaan terkait” bekerja dengan sangat baik.. hehe

Sekarang S3 juga meluas menjadi platform data yang mencakup file, tabel, dan vektor.

Rasanya seperti S3, yang dulu menjadi titik awal infrastruktur cloud modern, sedang didefinisikan ulang lagi setelah 20 tahun

[rtyu1120]

Memang tidak berbagi struktur file secara transparan dengan S3, tetapi ada juga open source bernama ZeroFS yang menggunakan S3 sebagai basis data untuk menjalankan file system yang kompatibel dengan POSIX. Demo menjalankan PostgreSQL di atas S3 juga cukup populer.

https://www.zerofs.net/

[rtyu1120]

Ada juga tulisan dari Archil, yang didirikan oleh mantan engineer S3, yang membandingkannya dengan produk mereka sendiri, jadi seru juga kalau dibaca bersama hehe

https://x.com/jhleath/status/2042613823522377933

[GN⁺]

Komentar Hacker News

• Ini pada dasarnya adalah arsitektur yang memakai S3FS, lalu menggunakan EFS (layanan NFS terkelola dari AWS) sebagai lapisan cache untuk data aktif dan akses acak kecil
  Masalahnya, skema tarif EFS yang mahal ikut terbawa apa adanya
  — Semua operasi tulis dikenai $0.06 per GB, yang bisa sangat mematikan untuk workload yang berpusat pada penulisan
  — Pembacaan dari cache dikenai $0.03 per GB, sementara pembacaan besar di atas 128KB langsung di-stream dari bucket S3 secara gratis
  — Cache dikenai $0.30 per GB per bulan, tetapi karena yang disimpan permanen terutama hanya file kecil di bawah 128KB, biayanya tampaknya tidak akan terlalu besar

  • Saya penasaran apakah benar pembacaan file besar (>128KB) selalu tidak melewati cache
    Saya khawatir karena latensi S3 cukup buruk

• Kalimat “NFS provides the semantics your applications expect” adalah hal paling lucu yang pernah saya lihat belakangan ini

  • Aplikasi jelas tidak mengharapkan system call masuk ke status menunggu tanpa batas hanya karena satu gangguan jaringan, lalu filesystem menjadi tidak bisa di-unmount

• Hugging Face Buckets juga baru-baru ini menambahkan fitur untuk me-mount bucket seperti filesystem
  changelog hf-mount

• Saya penasaran dengan bagian sinkronisasi
  Menurut dokumentasi AWS,
  jika /mnt/s3files/report.csv dimodifikasi lalu versi lain diunggah ke bucket S3, saat terjadi konflik versi saya akan dipindahkan ke direktori .s3files-lost+found-file-system-id dan diganti dengan versi dari bucket
  Artinya, ada direktori pemulihan otomatis saat konflik

• FiberFS hampir mencapai tahap rilis resmi pertamanya
  Ia menargetkan semua storage yang kompatibel dengan S3, dengan cache bawaan, kompatibilitas CDN, metadata JSON, dan keamanan konkurensi

  • Saya penasaran bagaimana perbandingannya dengan implementasi FUSE milik Amazon sendiri. Sekarang sudah sampai versi ketiga

• Akan menarik jika AWS menyediakan bridging terkelola dengan storage NVMe lokal
  NVMe jauh lebih cepat daripada EBS, dan EBS lebih cepat daripada EFS
  Jika lapisan cache ditempatkan di atas NVMe, performanya sepertinya bisa sangat bagus, meskipun opsi yang sepenuhnya terintegrasi akan lebih ideal

  • Jika EFS hanya berupa mount NFS biasa, mungkin kita juga bisa memasang volume NVMe dan mengatur cachefilesd untuk membangunnya sendiri
    Misalnya

    mkfs.ext4 /dev/nvme0n1 && \
    mount /dev/nvme0n1 /var/cache/fscache && \
    mount -t s3files -o fsc fs-0aa860d05df9afdfe:/ /home/ec2-user/s3files
    

    Dengan cara seperti ini, mungkin langsung bisa jalan
    Pada dasarnya cuma perintah tiga baris, dan memang sangat khas AWS kalau mereka merilis ini sebagai layanan terkelola

• Setahu saya dulu AWS mengatakan agar tidak menggunakan S3 sebagai filesystem, jadi saya penasaran kenapa sekarang berubah

  • Kali ini sepertinya mereka menaruh filesystem sungguhan (EFS) di depan S3 lalu melakukan sinkronisasi transparan
    Di blognya juga disebutkan hal-hal yang perlu diperhatikan seperti masalah konsistensi atau penanganan nama objek
    Sebagai penggemar S3, menurut saya desain seperti ini adalah kompromi yang cukup bagus
  • Arsitek pelanggan besar sudah lama menggunakan S3 seolah-olah itu filesystem
    Tekanan dari support ticket yang diterima AWS dan akumulasi permintaan “kenapa ini tidak bisa” tampaknya akhirnya mendorong arah ini
    Secara pribadi saya kurang suka karena terasa seperti “sesuatu yang secara esensial berbeda hanya diberi bungkus baru”, tetapi ini tampak seperti contoh tekanan sosial dari $$$ yang bekerja
  • Ini terlihat seperti strategi untuk menarik pengguna dengan tingkat kemampuan teknis yang lebih rendah
    Karena bahkan orang yang memakai tool seperti “S3asYourFS.exe” pun bisa dijadikan pelanggan AWS
    Namun mengingat kapabilitas dukungan pelanggan AWS, saya ragu ini keputusan yang bijak
    Meski begitu, godaan untuk menambah jumlah pengguna yang membayar tagihan bulanan pasti besar
  • Kalau orang-orang memang akan tetap memakai S3 seperti filesystem, saya rasa lebih baik AWS mendukungnya secara resmi
  • Pada akhirnya AWS hanya menaruh cache di depan dan membangun model pendapatan
    Dari sudut pandang pengguna, performa membaik, dan beban AWS berkurang
    Soal apakah itu menghemat uang atau tidak, belum tentu

• Saya penasaran apa yang terjadi jika database SQLite disimpan dengan ini
  Mungkin hanya replika read-only yang memungkinkan, dan backup seperti Litestream tampaknya tidak akan bisa

  • Mekanisme lock SQLite tidak aman di NFS, jadi tidak akan berfungsi

• Perilaku locking NFS sendiri sudah rumit, dan jika backend S3 jarak jauh dicampurkan ke dalamnya rasanya akan jadi lebih membingungkan lagi

• Werner Vogels benar-benar sosok yang luar biasa
  Saya pertama kali membaca tulisannya saat mempelajari DynamoDB, dan sejak saat itu saya jadi penggemarnya