S3 Files ve S3’ün Değişen Yüzü

• Büyük ölçekli veri taşımanın verimsizliğini azaltmak için, S3 verilerine dosya sistemi gibi doğrudan erişim sağlayan S3 Files kullanıma sunuldu
• Bu özellik, Amazon EFS ile S3’ü entegre ederek EC2, container ve Lambda gibi ortamlarda S3 bucket’larını NFS olarak mount etmeyi ve okuma-yazma işlemlerini mümkün kılıyor
• İçeride stage ve commit yapısı kullanılarak değişiklikler periyodik olarak S3’e yansıtılıyor ve dosyalar ile nesneler arasında çift yönlü senkronizasyon destekleniyor
• S3 Files, S3 Tables ve S3 Vectors ile birlikte S3’ü birleşik bir veri platformuna genişleten temel bileşenlerden biri olarak çalışıyor
• S3 artık basit bir depolamanın ötesine geçerek, geliştiricilerin veriyi doğrudan kullanabilmesini sağlayan veri odaklı birleşik bir çalışma alanına dönüşüyor

---

S3’ün dönüşümü ve S3 Files’ın tasarımı

• Veri taşımanın zorlukları ve S3 Files’ın çıkış noktası

  • Büyük ölçekli veriyi taşımak, bilimsel araştırmadan makine öğrenimine kadar birçok sektörde sürekli bir verimsizlik kaynağı olmaya devam ediyor
  • UBC’nin genomik araştırma örneğinde araştırmacılar, S3 ile yerel dosya sistemi arasında kopyalama işleri için çok zaman harcıyor
  • Bu veri sürtünmesi (data friction), araçların veriye farklı şekillerde erişmesinden kaynaklanıyor
  • S3 Files, bu sürtünmeyi azaltmak için S3 verilerine doğrudan dosya sistemi gibi erişilebilmesi amacıyla tasarlandı

• Ajan tabanlı geliştirme ve verinin önemi

  • Ajanik araçların (agentic tooling) gelişmesiyle uygulama geliştirme hızı ve çeşitliliği keskin biçimde arttı
  • Kod yazma eşiği düştükçe, alan uzmanlarının doğrudan uygulama geliştirebildiği bir ortam oluşuyor
  • Uygulamaların ömrü kısalırken, uzun vadede kalan temel varlık olarak veri öne çıkıyor
  • Depolamanın yalnızca bir saklama alanı değil, veriyi uygulamalardan ayırıp kalıcı biçimde değerlendirmeyi mümkün kılan bir soyutlama katmanı olması gerekiyor

S3’ün yeni veri primitifleri

• S3 Tables

  • S3, yapılandırılmış veriyi işlemek için Apache Iceberg tabanlı S3 Tables’ı kullanıma sundu
  • Iceberg’in yeteneklerini korurken veri bütünlüğü koruması, otomatik sıkıştırma (compaction), bölgeler arası replikasyon gibi özellikler sağlıyor
  • Şu anda 2 milyondan fazla tablo S3 Tables üzerinde saklanıyor ve çeşitli uygulamalar bunun üzerine inşa ediliyor

• S3 Vectors

  • Yapay zekadaki ilerlemeyle birlikte vektör indekslerine yönelik talep artıyor
  • Mevcut vektör veritabanları indeksleri bellekte veya SSD’de tutuyor, ancak bu yaklaşımın maliyet ve ölçeklenebilirlik sınırları var
  • S3 Vectors, S3 nesnelerine benzer maliyet-performans-dayanıklılık profiline sahip, tamamen elastik bir vektör indeksi sunuyor
  • Yüzlerce kayıttan milyarlarca kayda kadar ölçeklenebiliyor ve benzerlik araması (scalar similarity search) için API endpoint’leri sağlıyor

S3 Files’ın ortaya çıkışı

• Genel bakış

  • S3 Files, Amazon EFS’yi S3’e entegre ederek S3 verilerine ağ dosya sistemi (NFS) gibi doğrudan erişim sağlıyor
  • EC2, container ve Lambda gibi ortamlarda S3 bucket’larını veya prefix’lerini mount ederek dosya gibi okuyup yazmak mümkün
  • Değişiklikler otomatik olarak S3’e yansıtılıyor ve dosyalar ile nesneler arasında çift yönlü senkronizasyon destekleniyor

• Tasarımdaki zorluklar

  • Dosya sistemleri ile nesne depolama, temelden farklı veri modellerine sahip
  • Başlangıçta EFS ile S3’ü basitçe birleştirme fikri düşünülse de geriye yalnızca “hoşa gitmeyen tavizler (unpalatable compromises)” kaldı
  • Dosyalar ince taneli değişiklikleri ve eşzamanlı erişimi desteklerken, nesneler değişmezlik ve tüm nesnenin tek seferde güncellenmesi varsayımıyla çalışıyor
  • S3’ün olay bildirim sistemi, günde 300 milyardan fazla bildirimi işliyor ve nesne düzeyindeki değişiklikler üzerine kurulu

Stage and Commit tasarım ilkesi

• Sınırı bir özelliğe dönüştürmek

  • Dosyalar ile nesneler arasındaki fark gizlenmek yerine açık bir sınır olarak tasarlanıyor
  • Değişiklikler EFS üzerinde stage (geçici saklama) edilir, ardından belirli aralıklarla commit edilerek S3’e yansıtılır
  • Bu yaklaşım, Git’in sürüm kontrolü kavramından ilham alarak zamana ve politikalara dayalı veri aktarım kontrolünü mümkün kılar

• Tutarlılık ve atomiklik

  • Dosya sisteminin atomik (rename, move) işlemleri ile S3’ün tüm nesne düzeyinde güncellemeleri birlikte destekleniyor
  • İki katmanı ayırarak her sistemin tutarlılık modelini korurken tek bir veri görünümü sunuluyor

• Yetki yönetimi

  • S3’ün IAM politikaları ile dosya sisteminin inode tabanlı izinleri yapısal olarak farklı
  • S3 Files, mount birimi düzeyinde yetkilendirme ile bu iki sistemi birbirinden ayırıyor
  • S3 IAM politikaları, nihai güvenlik ağı (backstop) olarak korunuyor ve veri sınırları değiştiğinde erişim denetimi sağlıyor

• Namespace uyumsuzluğu

  • S3’te dizin kavramı yoktur ve yol ayıracı (delimiter) de keyfi olarak belirlenebilir
  • Dosya sistemiyle olan uyumsuzluğu çözmek için iki tarafın adlandırma kuralları olduğu gibi korunuyor
  • Uyumsuz nesneler taşınmıyor; bunun yerine geliştiricinin müdahale edebilmesi için olay üretiliyor

• Performans ve gecikme (latency)

  • Dosya sistemi metadata merkezli erişime, S3 ise büyük ölçekli paralel erişime optimize edilmiştir
  • Çoğu iş yükü dosyalara ve nesnelere aynı anda erişmediği için, iki modeli tamamen birleştirmektense senkronizasyon katmanını korumak daha gerçekçi görülüyor
  • Dosya görünümü NFS tutarlılığını, nesne görünümü ise S3’ün güçlü tutarlılığını koruyor; senkronizasyon katmanı da ikisi arasında köprü görevi görüyor

S3 Files nasıl çalışıyor

• Temel yapı

  • S3 Files, arka uç olarak EFS kullanarak dosya sistemi deneyimi sunar
  • Dizin erişiminde S3 metadata’sı alınarak senkronize bir görünüm oluşturulur; 128KB altındaki dosyalarda veri de anında yüklenir
  • Büyük dosyalar için lazy hydration ile veri gerektiğinde getirilir
  • Değişiklikler yaklaşık her 60 saniyede bir tek bir PUT ile S3’e commit edilir ve çift yönlü senkronizasyon sağlanır

• Çakışmalar ve yönetim

  • Her iki tarafta aynı anda değişiklik yapıldığında S3, doğruluğun kaynağı (source of truth) olarak kabul edilir
  • Çakışan dosyalar lost+found dizinine taşınır ve CloudWatch metric’leri ile kaydedilir
  • 30 gün boyunca erişilmeyen dosyalar, maliyet optimizasyonu için dosya sistemi görünümünden kaldırılır

• Performans optimizasyonu

  • read bypass özelliği sayesinde büyük hacimli sıralı okumalarda dosyalar, paralel GET istekleriyle doğrudan S3’ten okunur

    • İstemci başına 3GB/s throughput elde edilir; çoklu istemci senaryolarında ise terabit düzeyinde ölçeklenebilirlik sağlanır

• Sınırlar ve planlanan iyileştirmeler

  • S3’te yerel rename işlemi olmadığından, dizin adı değiştiğinde tüm içeriğin kopyalanıp silinmesi gerekir
  • 50 milyondan fazla nesne içeren mount’lar için uyarı gösterilir
  • Açık commit kontrolü ilk sürümde yer almaz
  • Bazı nesne anahtarları POSIX dosya adı olarak ifade edilemez, bu nedenle dosya görünümünün dışında bırakılır

Veri çeşitliliği ve S3’ün evrimi

• Veri erişim biçimlerinin birlikte var olması

  • UBC araştırma örneğinde olduğu gibi geliştiriciler, veri taşıma, cache’leme ve ad yönetimi için çok zaman harcıyor
  • S3 ekibi, Tables, Vectors ve Files ile farklı veri erişim biçimlerini birleşik şekilde destekliyor
  • Dosyalar ile nesneler arasındaki farkı yok etmeye çalışmak yerine, her birinin özelliklerini kabul edip sınırları işlevselleştiriyor

• S3’ün genişleyen rolü

  • S3, basit bir nesne depolamadan çeşitli veri biçimlerini destekleyen birleşik bir depolama platformuna evriliyor
  • Tables, Vectors ve Files sayesinde veri, çalışma biçimine uygun şekilde doğrudan kullanılabiliyor
  • Hedef, depolamanın işin önünde engel olan değil, görünmez bir temel altyapı haline gelmesi
  • Gelecekte stage/commit kontrolü, pipeline entegrasyonu gibi özelliklerin genişletilmesi planlanıyor

• Sonuç

  • S3 Files, dosyalar ile nesneler arasındaki açık sınırı korurken iki tarafın avantajlarını birleştiriyor
  • 20 yıl önce nesne depolama olarak başlayan S3, artık veri odaklı birleşik bir çalışma alanına dönüşmüş durumda
  • “Artık, inşa edin (Go build!)” mesajında olduğu gibi, S3 geliştiricilerin veriyle daha hızlı deney yapıp ürün geliştirmesini sağlayan bir temel haline geliyor

[xguru]

Ah, artık birlikte okunabilecek iyi yazılar ilgili resmi yazıları da güzelce bağladığı için rahat oldu.
Tanıtım yazısı ile resmi yazının ayrı olduğu durumlarda bunu nasıl ele almak gerektiğini hep düşünürdüm,
beraber okunabilecek iyi yazılar özelliğinin iyi çalışması hoşuma gitti.. hehe

Artık S3, dosya·tablo·vektörün tamamını kapsayan bir veri platformu olarak genişliyor.

Modern bulut altyapısının başlangıç noktası olan S3, 20 yıl sonra yeniden tanımlanıyormuş gibi hissettiriyor

[rtyu1120]

S3 ile dosya yapısı şeffaf biçimde paylaşılmasa da, ZeroFS adlı; S3’ü veritabanı olarak kullanıp POSIX uyumlu bir dosya sistemi çalıştıran açık kaynaklı bir proje de var. S3 üzerinde PostgreSQL çalıştıran demosuyla epey popüler olmuştu.

https://www.zerofs.net/

[rtyu1120]

Daha önce S3 mühendisi olan kişilerin kurduğu Archil'de, kendi ürünleriyle karşılaştırdıkları bir yazı da var; ona da birlikte bakmak eğlenceli haha

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

[GN⁺]

Hacker News görüşleri

• Bu, temelde S3FS kullanıp EFS'yi (AWS'nin yönetilen NFS hizmeti) aktif veri ve küçük rastgele erişimler için bir önbellek katmanı olarak kullanmak demek
  Sorun şu ki EFS'nin pahalı ücret yapısı da aynen beraberinde geliyor
  — tüm yazma işlemleri GB başına $0.06, bu da yazma ağırlıklı iş yükleri için ölümcül olabilir
  — önbellekten okumalarda GB başına $0.03 ücret alınıyor ve 128KB'ı aşan büyük okumalar doğrudan S3 bucket'tan stream edilerek ücretsiz oluyor
  — önbellek ücreti aylık GB başına $0.30, ancak çoğunlukla yalnızca 128KB altındaki küçük dosyalar kalıcı tutulduğu için maliyet çok büyük olmayabilir

  • Büyük dosya okumalarının (>128KB) gerçekten her zaman önbelleği atlayıp atlamadığını merak ediyorum
    S3 gecikmesi (latency) epey kötü olabildiği için endişeliyim

• “NFS provides the semantics your applications expect” ifadesi şimdiye kadar gördüğüm en komik şeylerden biriydi

  • Uygulamaların tek bir ağ kopması yüzünden sistem çağrılarının sonsuza kadar beklemesini ve dosya sisteminin unmount edilemez hale gelmesini beklediğini sanmıyorum

• Hugging Face Buckets da yakın zamanda bucket'ları dosya sistemi gibi mount etme özelliği ekledi
  hf-mount değişiklik günlüğü

• Senkronizasyon kısmını merak ettim
  AWS dokümanına göre,
  /mnt/s3files/report.csv dosyasını değiştirdikten sonra S3 bucket'a başka bir sürüm yüklenirse, çakışma durumunda benim sürümüm .s3files-lost+found-file-system-id dizinine taşınıp bucket sürümüyle değiştiriliyor
  Yani çakışma durumunda otomatik kurtarma dizini diye bir şey var

• FiberFS neredeyse ilk resmi sürüm aşamasında
  yerleşik önbellek, CDN uyumluluğu, JSON metadata ve eşzamanlılık güvenliği sunuyor; ayrıca tüm S3 uyumlu depolamaları hedefliyor

  • Amazon'un kendi FUSE implementasyonu ile karşılaştırıldığında nasıl olduğunu merak ediyorum. Şimdiye kadar üçüncü sürüme geldiler

• AWS'nin yerel NVMe depolama ile yönetilen bir köprüleme sunmasını isterdim
  NVMe, EBS'den çok daha hızlı ve EBS de EFS'den daha hızlı
  NVMe üzerinde bir önbellek katmanı kurarsanız hız oldukça iyi olabilir, ama tamamen entegre bir seçenek daha ideal olurdu

  • EFS sadece basit bir NFS mount ise, NVMe volume bağlayıp cachefilesd yapılandırarak bunu kendiniz de kurabilirsiniz gibi görünüyor
    Örneğin

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

    bunu böyle yapınca doğrudan çalışabilir
    Esasen üç satırlık bir komut, ama bunu yönetilen hizmet olarak sunmak tam AWS'lik hareket

• AWS'nin eskiden S3'ü dosya sistemi olarak kullanmayın dediğini hatırlıyorum, neden şimdi değiştiğini merak ediyorum

  • Bu kez S3'ün önüne gerçek bir dosya sistemi (EFS) koyup şeffaf senkronizasyon yapan bir yapı gibi görünüyor
    Blog yazısında da tutarlılık sorunları ve nesne adı işleme gibi dikkat noktalarından bahsediliyor
    Bir S3 hayranı olarak bunun oldukça makul bir orta yol olduğunu düşünüyorum
  • Büyük müşteri şirketlerin mimarları uzun zamandır S3'ü dosya sistemi gibi kullanıyordu
    AWS'nin aldığı destek talebi baskısı ve “neden olmuyor” şikayetleri birikince sonunda bu yöne gitmiş gibi görünüyor
    Kişisel olarak “özünde farklı olan bir şeyi sadece yeniden paketleme” yaklaşımını pek sevmiyorum, ama burada $$$'ın toplumsal baskısı etkili olmuş gibi
  • Bu, daha düşük teknik yeterliliğe sahip kullanıcı kitlesini de çekme stratejisi gibi görünüyor
    “S3asYourFS.exe” gibi araçlar kullananları bile AWS müşterisine dönüştürebilirler
    Ama AWS'nin müşteri destek kapasitesi düşünülünce bunun akıllıca bir karar olup olmadığı şüpheli
    Yine de her ay fatura ödeyen kullanıcı sayısını artırma cazibesi büyük olmuştur
  • İnsanlar zaten S3'ü dosya sistemi gibi kullanacaksa, en azından bunu resmi olarak desteklemek daha iyi bence
  • Sonuçta AWS, ön tarafa bir önbellek koyup bundan bir gelir modeli çıkarmış oldu
    Kullanıcı açısından performans artıyor, AWS açısından yük azalıyor
    Para tasarrufu sağlayabilir de sağlamayabilir de

• Bunun üzerinde bir SQLite veritabanı tutulursa ne olacağını merak ediyorum
  Muhtemelen yalnızca salt okunur replikalar mümkün olur, Litestream tarzı yedekleme ise olmaz gibi

  • SQLite'ın kilit (lock) mekanizması NFS üzerinde güvenli değil, bu yüzden çalışmaz

• NFS'nin kilitleme davranışı zaten yeterince karmaşık; buna bir de uzak S3 backend eklenirse daha da kafa karıştırıcı hale gelir gibi

• Werner Vogels gerçekten inanılmaz biri
  Yıllar önce DynamoDB çalışırken onun yazılarıyla ilk kez karşılaşmıştım, o zamandan beri hayranıyım