AWS S3, Yavaş HDD’ler Üzerinde Saniyede 1 Petabaytı Nasıl İşliyor?

 (bigdata.2minutestreaming.com)
19 puan yazan GN⁺ 2025-09-27 | 2 yorum | WhatsApp'ta paylaş
  • AWS S3, büyük ölçekli çok kiracılı nesne depolama hizmetidir ve yüksek erişilebilirlik ile dayanıklılığı düşük maliyetle sunar
  • Eski ve yavaş (≈120 IOPS) HDD’lerden yararlanır, ancak çok düşük maliyetli, yüksek kapasiteli depolama ortamlarının ekonomisini en üst düzeye çıkarır
  • S3, dahili depolama katmanını (ShardStore) log-structured (LSM) olarak tasarlayarak yazma yolunu sıralı I/O için optimize eder; okuma yolunda ise Erasure Coding (5-of-9) ve büyük ölçekli paralelleştirme ile performans sorunlarını telafi eder
  • İstemci, frontend ve depolama boyunca multipart upload, byte-range GET, connection pool, hedge request gibi yöntemlerle tail latency azaltılır ve throughput birleştirilir
  • Rastgele dağıtık yerleştirme, Power of Two Random Choices, sürekli yeniden dengeleme ve ölçek büyüdükçe yükü düzleştiren dekorelasyon sayesinde hotspot’lardan kaçınılır; sonuçta >1 PB/s düzeyinde throughput elde edilir

AWS S3’ün büyük ölçekli depolama mimarisi

  • AWS S3’ün ne olduğunu herkes bilir, ancak S3’ün ne kadar muazzam ölçekte çalıştığını ve bunun için hangi yeniliklerin geliştirildiğini bilen kişi azdır
  • S3, API üzerinden nesnelerin depolanıp alınabildiği ölçeklenebilir çok kiracılı bir nesne depolama hizmetidir ve çok yüksek erişilebilirlik ile dayanıklılığı görece düşük maliyetle sunar

  • S3’ün ölçeği

    • 400 trilyondan fazla nesne depolama
    • Saniyede 150 milyon isteği işleme
    • Zirvede saniyede 1 PB’den fazla trafiği destekleme
    • On milyonlarca sabit disk işletme
  • Yüksek erişilebilirlik ve dayanıklılık (“11 nines” tasarım hedefi) ile görece düşük maliyet, kullanıcı deneyiminin ön koşulu olarak sunulur
    • Veri analitiği ve makine öğrenimi data lake’lerinin varsayılan depolama katmanı olacak kadar genişlemiştir
  • Tasarım hedefi, maliyet verimliliğini korurken rastgele erişim kalıpları ve büyük ölçekli eşzamanlılığı kaldırmaktır
    • S3, her kiracının rastgele boyut ve ofsetlerle eriştiği toplu bir random access workload varsayar

Temel teknoloji: hard drive (HDD)

  • S3’ün dikkat çekici ölçeklenebilirliği ve performansı, geleneksel bir depolama ortamı olan HDD üzerine kuruludur
  • HDD eski bir teknolojidir; dayanıklılığı yüksek olsa da fiziksel hareket nedeniyle IOPS ve gecikme açısından sınırlara sahiptir
    • Saniyedeki dönüş sayısı (ör. 7200 RPM) ve actuator seeking gibi mekanik hareketler zorunlu olduğu için latency yapısal olarak yüksektir ve kaçınılmazdır
    • Ortalama yarım platter seek ≈4 ms, ortalama yarım dönüş ≈4 ms, 0.5 MB aktarım ≈2.5 ms → rastgele 0.5 MB okuma ortalaması ≈11 ms, tek disk rastgele throughput’u ≈45 MB/s düzeyi
  • SSD’lerin aksine, uzun vadede kapasite↑·fiyat↓ eğrisi sayesinde “çok ucuz / çok yüksek kapasiteli” ekonomi sağlar ve bu yüzden hâlâ büyük ölçekli depolamada kullanılır
    • Fiyat: bayt başına 6 milyar kat düşüş (enflasyona göre düzeltilmiş)
    • Kapasite: 7,2 milyon kat artış
    • Boyut: 5 bin kat küçülme
    • Ağırlık: 1.235 kat azalma
  • Ancak 30 yıldır IOPS yaklaşık 120 seviyesinde takılmış durumdadır; rastgele erişim performansı ve gecikme ciddi biçimde iyileşmemiştir
  • SSD’ler rastgele I/O için avantajlı olsa da peta- ve exa-ölçekli depolamada toplam sahip olma maliyeti (TCO) açısından dezavantajlıdır

Sıralı I/O’ya optimize edilmiş yazma yolu

  • HDD’ler sıralı erişim için optimize edilmiştir; ardışık baytlar okunup yazıldığında disk platter’ı doğal biçimde dönerek veriyi hızlı işler
  • Log tabanlı veri yapıları bu sıralı özelliği kullanır
    • S3’ün dahili depolama katmanı ShardStore, log-structured LSM benimseyerek yazıları diske sıralı append şeklinde işleyen bir strateji kullanır
    • Benzer şekilde batch processing ile disklerin sıralı throughput’u en üst düzeye çıkarılabilir

Rastgele okuma yolu için paralelleştirme ve Erasure Coding

  • Okuma, kullanıcı isteğine göre rastgele konum sıçramaları gerektirdiğinden fiziksel sınırlarla doğrudan karşılaşır (rastgele I/O’nun ortalama gecikmesi yaklaşık 11 ms)
    • Tek bir HDD, rastgele I/O ile saniyede en fazla 45 MB işleyebilir
    • Bu yüzden HDD büyük miktarda veri depolamada fiyat/performans açısından çok güçlü olsa da rastgele erişim performansı düşüktür
  • S3 bu fiziksel sınırı aşmak için veriyi çok sayıda diske sharding ederek ve eşzamanlı okuyup throughput’u toplayarak çalışan büyük ölçekli paralelleştirme kullanır
    • Veriyi çok sayıda HDD’ye dağıtır ve her diskin giriş/çıkışını paralel kullanarak toplam throughput’u büyük ölçüde yükseltir
    • Örneğin 1 TB’lık bir dosya 20 bin HDD’ye bölünerek depolanırsa, tüm disklerin throughput’u toplanıp TB/s düzeyinde okuma mümkün olabilir

Erasure Coding

  • Depolama sistemlerinde yedeklilik garantisi zorunludur
  • S3, Erasure Coding (EC) kullanarak veriyi K veri parçası ve M parity parçasına böler
    • Toplam K+M parçadan herhangi K tanesi varsa veri geri yüklenebilir
  • S3, Erasure Coding (5-of-9) ile denge noktasını yakalar; burada 9 parçalı yapı kullanılır (5 veri shard’ı, 4 parity shard’ı)
    • 5 veri + 4 parity = 9 parça
    • En fazla 4 shard kaybına rağmen kurtarma yapılabildiği için, herhangi 5 parça ile orijinal veriyi geri getirebilen fault tolerance sağlar
    • Depolama overhead’i ≈1.8x olup 3’lü replikasyona (3x) göre kapasite açısından daha verimlidir
    • Aynı anda 5 paralel okuma yolu sağlayarak shard paralelleştirme ve straggler kaçınma açısından avantaj sunar
  • S3 bu fiziksel sınırı aşarak büyük ölçekli veriler üzerinde rastgele erişim sunar

Paralel işleme yapısı

  • S3, 3 temel paralelleştirme yöntemi kullanır
    • 1. Kullanıcılar veriyi birden fazla chunk’a bölerek yükler ve indirir
    • 2. İstemci, birden fazla frontend sunucuya eşzamanlı istek gönderir
    • 3. Sunucu, nesneleri birden fazla depolama sunucusuna dağıtarak saklar

  • 1. Frontend sunucu düzeyinde paralel işleme

    • Dahili HTTP connection pool kullanılarak dağıtık birden fazla endpoint’e aynı anda bağlanılır
    • Belirli altyapı düğümlerinde veya önbelleklerde aşırı yük oluşması engellenir

  • 2. Hard drive’lar arasında paralel işleme

    • EC tabanlı olarak veri birçok HDD’ye küçük shard’lar halinde dağıtılır

  • 3. PUT/GET isteklerinde paralel işleme

    • İstemci veriyi birden çok parçaya bölerek paralel yükleme yapar
    • PUT: multipart upload ile yeni yazılarda paralellik en üst düzeye çıkarılır
    • GET: byte-range GET desteğiyle nesnenin yalnızca belirli bir aralığı okunabilir
  • İş yükü paralel biçimde dağıtıldığında saniyede 1 GB yükleme gibi hedeflere rahatlıkla ulaşılabilir

Hotspot önleme

  • S3, on milyonlarca sürücü, saniyede yüz milyonlarca istek ve yüz milyonlarca shard’ın paralel işletildiği bir ortamdır
  • Yük belirli disklere veya düğümlere yığılırsa tüm sistemin performansı düşebilir
  • Bunu önlemek için temel stratejiler şunlardır:
    • 1. Veri yerleşimini rastgele dağıtmak
    • 2. Sürekli yeniden dengeleme
    • 3. Sistem ölçeğini büyütmek

  • 1. Shuffle sharding & Power of Two

    • İlk veri yerleşimi rastgele dağıtılır
    • ‘Power of Two Random Choices’ algoritması uygulanır:
      • Rastgele seçilen 2 düğümden yükü daha hafif olanın tercih edilmesi etkili bir yük dengelemesi sağlar

  • 2. Yeniden dengeleme

    • Veri sıcaklığı: yeni veri daha sıcaktır (daha sık erişilir) özelliğinden yararlanılarak periyodik yeniden dengeleme ile alan ve I/O yeniden dağıtılır
      • Veri yaşlandıkça erişim sıklığı azalır, depolama genelinde I/O kapasitesi artar
    • S3, cold data’yı yeniden dağıtarak alan ve kaynak kullanımını en üst düzeye çıkarır
    • Yeni rack eklendiğinde (ör. 20 PB/rack, 1000×20 TB) boş kapasiteye aktif dağıtım gerekir

  • 3. Chill@Scale

    • Ölçeğin etkisi: workload’lar birbirinden ne kadar bağımsızsa ani eşzamanlı patlamalar o kadar azalır ve toplam yükü düzleştiren dekorelasyon ortaya çıkar
    • Sistem büyüdükçe tepe/ortalama farkı azalır, öngörülebilirlik artar
    • Yani kullanım artış ve durgunlukları tekrar etse bile büyük ölçekte bunlar birbirini dengeleyerek öngörülebilir bir yük oluşturabilir

Operasyon, güvenilirlik kültürü ve diğer teknikler

  • DNS düzeyinde shuffle sharding ile ad çözümleme katmanında kiracılar arası izolasyon ve dengeli dağılım hedeflenir
  • Yazılım rollout süreci de EC’de olduğu gibi kademeli ve kesintisiz yürütülür; ShardStore geçişi de hizmet etkisi olmadan yapılmıştır
  • Dayanıklılık kültürü: sürekli arıza tespiti, chain of custody, dayanıklılık tehdit modellemesi, biçimsel doğrulama gibi süreçlerle güvenilirlik sağlanır

Neden önemli: S3 tabanlı veri altyapısı trendi

  • Stateless mimari yaygınlaştıkça uygulama düğümleri durumu üzerinde tutmaz; bunun yerine kalıcılık, replikasyon ve yük dengelemeyi S3’e devretme yaklaşımı yaygınlaşır
    • Örnekler: Kafka Diskless (KIP-1150), SlateDB, Turbopuffer, Lucene on S3, ClickHouse/OpenSearch/Elastic içinde nesne depolama entegrasyonu
  • Avantajları elastik ölçeklenme, operasyonel sadeleşme ve maliyet düşüşü; dezavantajı ise artan gecikme olasılığıdır; bu yüzden her workload için latency, maliyet ve dayanıklılık arasındaki üçlü ödünleşim tasarlanmalıdır

Özet

  • AWS S3, büyük ölçekli çok kiracılı bir depolama hizmeti olarak yavaş depolama ortamlarının sınırlarını büyük ölçekli paralellik, load balancing ve veri sharding ile aşar
  • Erasure Coding, rastgele dağıtım, sürekli yeniden dengeleme ve hedge request gibi tekniklerle kararlılık ve performans sağlar
  • Başlangıçta yedekleme ve medya ağırlıklı kullanım için tasarlanmışken, bugün veri analitiği ve makine öğrenimi gibi büyük veri altyapılarının ana depolama katmanına dönüşmüştür
  • S3 tabanlı mimari, stateless ölçeklenebilirlik sağlar ve dayanıklılık, replikasyon ile load balancing sorunlarını etkili biçimde AWS tarafına devretmeye olanak tanır
  • Bu da bulut maliyetlerini düşürürken yönetim verimliliği de sağlar

İlgili okumalar

2 yorum

 
shakespeares 2025-10-05

Teknoloji iyi olmasaydı kâr edebileceklerini sanmıyorum.
 
GN⁺ 2025-09-27
Hacker News görüşü

  • Birkaç olgusal hata var ama bunlar makalenin akışını büyük ölçüde etkilemiyor. Örneğin, S3’ün 5:9 sharding kullandığı iddiası; gerçekte S3 çeşitli sharding şemaları kullanıyor ve benim bildiğim kadarıyla 5:9 bunlardan biri değil. Mantıksal 1 bayt başına 1,8 fiziksel bayt oranı da HDD maliyeti açısından gerçekten kötü bir değer. Gerçekte bu oranı daha da düşürmenin yolları var; aynı zamanda paralellik artar ve erişilebilirlik de iyileşir. Örneğin, tüm bir AZ devre dışı kaldığında bir nesnenin GET ile erişilemez hale gelmeden önce kaç shard kaybedebileceğini düşünmek gerekir

    • Bu YouTube videosunda 42:20 noktasında S3’ün bu sharding şemasını kullandığını anladım. Daha fazlasını biliyorsanız merak ederim

    • 1,8x oranını düşürürken aynı anda erişilebilirliği artırmak sezgisel olarak zor görünüyor. Kopya sayısı azalırsa AZ arızasında veri kaybı riski artmaz mı? AWS’nin 3 AZ boyunca tamamen bağımsız kopyalar sağladığını sanıyordum. Ayrıca tek bir 16MB chunk okumak için gerçekte 5 farklı hard diskten 4MB’er okumak daha hızlı olur açıklaması hâlâ bana şaşırtıcı geliyor

    • VAST Data 146+4 şemasını kullanıyor. (bağlantı)

  • Bu yazıyı keyifle okudum ama başlıktaki sorunun cevabı fazla açık: paralellik

    • Normalde depolama I/O hızını bu ölçekte pek düşünmemiştim. Eskiden hard diske daha hızlı yazmak için RAID0 kullanırdım ama bu çok eski bir hikâye. İlk başta caching ya da katmanlama gibi ilginç yöntemler kullanıldığını sanmıştım. Okuduktan sonra paralelliğin zaten bariz cevap olduğunu fark ettim ama S3’ün ayrıntılı uygulaması ya da hata düzeltme yöntemleri aklıma gelmemişti. Anahtar kelime paralellik ama ayrıntılarda da ciddi içgörü vardı. MinIO’nun da benzer ölçeklenebilirlik hikâyesi vardır diye düşünüyorum: yine paralellik

    • Makale başlığının yalnızca S3’ün toplam tepe throughput’una odaklandığı için biraz kafa karıştırıcı olduğunu düşünüyorum. Asıl ilginç soru bence "HDD’nin azami throughput’unu aşan GET throughput’u nasıl mümkün oluyor?" Basit replikasyonda birkaç HDD seçip GET’i paralel yapmak, S3’ün toplamı açısından throughput’u artırır ama sonuçta tekil HDD throughput’u * GET istek sayısı sınırına takılırsınız. Oysa S3’te böyle bir sınır olmaması işin gizli ve ilginç tarafı

    • Milyonlarca hard diski bir araya getirince muazzam bir IO bant genişliği elde edersiniz

    • Kulağa "Ay’a gitmenin yolu belli: seyahat" gibi bir mantık geliyor

  • full-platter seek time: ~8ms; half-platter seek time (avg): ~4ms
    Ortalama olarak [0,1] aralığında iki nokta düzgün dağılıyorsa aralarındaki uzaklığın beklenen değeri 0,5 değil 1/3’tür. Eğer full platter seek süresi 8ms ise ortalama seek süresi 2,666ms olur

    • Modern sürücülerde full seek, 8ms’ten ziyade 25ms’ye daha yakın. Kendiniz test etmek isterseniz, bir hard diskiniz ve root yetkiniz varsa fio’da --readonly seçeneğiyle diskin iki ucundan dönüşümlü okuma yaptırabilirsiniz. Modern sürücülerde neden 1/3 sayısının tam doğru olmadığını anlatan iyi bir makale de var (burada). Disk sürücü mekaniği ya da performansı hakkında daha fazla merak ettiğiniz şey varsa cevaplayabilirim

    • Track’ler arasında hareket ederken kafanın ivmelenmesi söz konusu. Mesafe ne kadar kısa olursa ulaşılan azami hız da o kadar düşük oluyor ve sabit bir gecikme de var (yerleşme süresi vb.), dolayısıyla gerçek ortalama 4ms olabilir

    • Platter dairesel olduğu için düzgün dağılım [0, 1] değil, [0, 2pi] üzerindeki birim çember dağılımı olmalı; ayrıca platter yalnızca tek yönde döndüğünden uzaklık her zaman saat yönünde hesaplanmalı.
      Soruyu basitleştirip başlangıç noktasını 0 derece, hedef noktayı da rastgele bir yer alalım: ortalama uzaklık nedir? 0-180 derece ile 180-360 derecenin yay uzunluğu aynı olduğundan ortalama uzaklık 180 derece olur. Yani half-platter seek, full-platter seek’in tam yarısıdır

  • S3’ün temel hizmette hâlâ HDD kullanıp kullanmadığını, fiyatlara ve IOPS cinsinden karşılığına bakarak tahmin edebilirsiniz. S3’ün GET/PUT istek fiyatı yeterince yüksek olduğu için AWS, yüksek performanslı tenant’lar için disk alanının bir kısmını boş bırakarak çalışma lüksüne sahip. Ama bu, yalnızca biraz daha pahalı olma sınırında; çok daha fazlası değil

  • S3’ün bir kısmının SSD üzerinde çalışıp çalışmadığını merak ediyorum. Standart S3’ün de SSD tabanlı olduğunu, yalnızca daha yavaş katmanların HDD ya da daha yavaş sistemler kullandığını sanıyordum

    • S3’ün KeyMap Index’i SSD kullanıyor. Bugün itibarıyla SSD’nin sıcak nesne cache’inde ya da yeni one zone ürününün bir bölümünde zaten kullanılıyor olabileceğini düşünüyorum

    • Gerçek depolanan verinin büyük olasılıkla neredeyse tamamı HDD’dedir. Ama metadata, indeksler vb. için çok daha hızlı flash depolama kullanıyorlardır diye düşünüyorum. Küçük Ceph cluster’larının MDS sunucularında da genelde böyledir; S3 ise çok daha büyük ölçekte

    • Bunu yukarıda bir kez daha söylemiştim ama standart katmanda istek başı fiyat yüksek olduğu için, IOPS/TB oranı yüksek müşteriler olsa bile diskin bir kısmını boş bırakacak kadar maliyet verimliliği korunuyor. Ama bunun ötesinde pahalılaşırsa artık mantıklı olmuyor. Modern HDD’ler yaklaşık 30TB depoluyor; AWS’nin bunları gerçekte ne kadara aldığı bilinmez ama kabaca 300-500 dolar bandında olduğunu tahmin ediyorum. 30TB SSD ile kıyaslandığında çok daha ucuz. Ayrıca bu HDD’leri yüksek yoğunluklu sistemlere de takabilirsiniz (ör. 4U içinde 100 sürücü) ve bunun toplam maliyeti belki yalnızca %25 artırır. Öte yandan büyük miktarda SSD destekleyen donanım kutuları, slot başına çok daha pahalı

    • S3 Express One Zone’un muhtemelen SSD tabanlı olduğunu tahmin ediyorum. Ama Amazon bunu açıkça söylemiş gibi görünmüyor

    • Metadata’nın kesinlikle SSD’de tutulacağını varsayıyorum. Sık okunan sıcak nesneler de muhtemelen SSD’ye cache’leniyordur

  • HDD fiyatları düşmeye devam ederken S3 fiyatlarının en az 8 yıldır aynı kalmış olması ilginç. Fiyat indirimi rekabeti yetersiz olduğu için yüksek fiyat yapısını koruyabiliyorlar. Bunun AWS’ye ne kadar büyük kâr sağladığını hayal edebilirsiniz

    • AWS’nin fiyatlandırma politikası bütün hizmetlerinde benzer. Örneğin EC2’de m7a.medium instance’ı on-demand aylık 50 dolar, 1 yıllık reserved ile 35 dolar. Benzer özellikte başka şirketlerin hizmetleriyle karşılaştırınca da pek rekabetçi sayılmaz

    • Enflasyon etkisi de var; dolayısıyla nominal fiyat aynı kalsa da reel olarak fiyat düşmüş sayılır. Ama enflasyonun teknoloji ilerlemesinden çok daha yavaş yansıdığı noktasına katılıyorum

    • Bence maliyet azaltmak teşviklerin hedefi değil. Splunk ya da CrowdStrike gibi AWS üzerinde devasa veri depolayan şirketlere bakınca çok fazla tekrar eden veri görüyorsunuz; bunları müşteriye olduğu gibi faturalandırıp veri tekilleştirmeyi de basit düzeyde uyguluyorlar. Maliyeti düşürmek, aslında gereksiz tüketimi daha da artıracak ters bir teşvik yaratabilir

    • HDD fiyat düşüşünün gerçekten büyük olup olmadığını merak ediyorum. Son birkaç yılda hard disklerde GB başına fiyat düşüşü oldukça yavaşladı; bu gidişle SSD yakında yetişebilir

  • S3 hakkında daha ilginç bir yazı olarak "Building and operating a pretty big storage system called S3" önerilir

  • rustfs’nin gerçek performansının nasıl olduğunu merak ediyorum

  • On milyonlarca HDD kullanıldığına dair ifadeyi görünce, kurumsal HDD’ler 10-20TB kapasitedeyse AWS S3’ün toplam kapasitesinin yüzlerce exabyte düzeyinde olduğu tahmin edilebilir. Muhtemelen dünyadaki en büyük depolama sistemi olabilir

    • Donanım 2013’ten beri yükseltildiyse Utah’taki belirli bir veri merkezi bu kapasiteyi aşmış olabilir (ilgili haber)

    • Güncel kurumsal HDD’ler 30TB seviyesinde, yakında 50TB’ye kadar çıkmaları da bekleniyor

  • HDD’ye optimize edilmiş ve benzer performans veren açık kaynak bir servis bilmek isterim. Başlıca projelerin hepsi (MinIO, Swift, Ceph+RadosGW, SeaweedFS) flash-only deployment öneriyor. Son zamanlarda Garage adlı bir projeye bakıyorum; EC kullanmaması gibi tasarım farkları var

    • Ceph+RadosGW de HDD ile gayet iyi çalışır. Yalnız indeks pool’unun SSD’de olması gerekir ve HDD pool’undan beklenebilecek IOPS sayısı konusunda gerçekçi olmak şart. İstemci tarafındaki IOPS pratikte birkaç katına çıkıyor; S3 de bunu çok sayıda HDD ile çözüyor. 4MB streaming büyük depolama için büyük sorun değil ama çok sayıda küçük anahtarı rastgele okuyup yazıyorsanız ya da tek bir anahtara dağınık erişim fazlaysa backend performansı önemli hâle gelir

    • Lustre/ZFS de benzer hızlara ulaşabilir. Ama yüksek IOPS gerekiyorsa Lustre için MDS üzerinde flash, ZFS için ise özel bir log SSD gerekir

    • Bu hizmetlerin hepsi aynı performans için büyük veri merkezi ölçeğinde çok sayıda sürücü gerektiriyor. Bu ölçeği kaldırabilen kurulum sayısı çok az. Bu yüzden flash, alan/maliyet açısından hızlı erişimde daha verimli oluyor

    • SeaweedFS son birkaç yılda çok gelişti; artık RDMA desteği ve EC de var

    • Önceki iş yerimde SwiftStack tabanlı object storage işletiyorduk; metadata SSD’de, nesne verisi ise sıradan HDD’de tutuluyordu. Gayet iyi çalışıyordu