S3 adlı devasa depolama sistemini inşa etmek ve işletmek
(allthingsdistributed.com)- Amazon S3, 14 Mart 2006'da kullanıma sunulan HTTP REST API tabanlı nesne depolama olarak başlayıp, yüzlerce mikroservis ve birden çok özel ekibin birlikte işlettiği büyük ölçekli bir hizmete dönüştü
- S3'ün ölçeği yalnızca kodla açıklanamaz; sabit diskler, firmware, veri merkezleri, operasyon organizasyonu ve müşteri iş yükleri sürekli birbirine bağlanarak değişen bir sistem oluşturur
- HDD'ler kapasite ve maliyet verimliliği açısından büyük ölçüde iyileşti, ancak rastgele erişim performansı mekanik sınırlarla kısıtlı kaldığından S3, milyonlarca diskin I/O ısı yönetimini ve veri yerleşimini temel mesele olarak ele alır
- Çoğaltma ve Reed-Solomon tabanlı erasure coding yalnızca dayanıklılığı artırmakla kalmaz; aşırı yüklü disklerden kaçınarak istekleri başka yollara yönlendirir ve performans ile tail latency yönetimine de katkı sağlar
- S3 operasyonu; dayanıklılık incelemeleri, Rust tabanlı ShardStore, hafif biçimsel doğrulama ve ekip bazlı sahiplik (ownership) ile hızlı geliştirme ve yüksek dayanıklılık standartlarını birlikte sürdürecek şekilde tasarlanmıştır
S3'ü tek bir devasa hizmet sistemi olarak görmek
- S3 bir nesne depolama hizmetidir ve HTTP REST API, frontend filoları, namespace hizmeti, sabit disk tabanlı depolama filoları ve arka plan işleri filolarından oluşur
- Her büyük bileşenin S3 organizasyonu içinde ayrı bir alanı, lideri ve birden çok ekibi vardır; daha içteki bileşenler de kendi filoları ve ekipleriyle işletilir
- Günümüzde S3, yüzlerce mikroservisten oluşur ve ekipler arası etkileşimler API düzeyinde sözleşmelere yakındır
- Modülerlik yanlış tasarlanırsa ekipler arası etkileşimler de verimsiz ve hantal hale gelebilir; bunu düzeltmek de yazılım ile ekipleri birlikte tasarlama sürecinin parçasıdır
Sistem yalnızca yazılım değil, hizmetin tamamıdır
- S3 müşterileri paketlenmiş bir yazılım değil, hizmet deneyimi satın alır ve sürekli, öngörülebilir kalite bekler
- S3'ün sistem sınırı yalnızca kodla sınırlı değildir
- Disklerin yakınında çalışan kod
- Veri merkezlerine yeni depolama rack'leri kuran teknisyenler
- Performansı ayarlayan müşteri uygulamaları
- Donanım, finans ve mühendislik organizasyonları
- S3; yazılım, donanım ve insanların birlikte sürekli büyüyüp değiştiği yaşayan bir sisteme daha yakındır
- Basit bir whiteboard mimari diyagramı, her kutunun içindeki genişletilmiş hizmetleri ve ölçeği gizlediği için gerçek sistemi olduğundan küçük gösterir
HDD'lerin fiziksel sınırlarının S3 tasarımına etkisi
- S3, milyonlarca sabit disk kullanan çok büyük bir sistemdir ve HDD özellikleri tasarımın temel kısıtlarından biridir
- 1956'daki IBM 350 disk storage unit'ten bu yana HDD'ler büyük ölçüde gelişti
- Bahsedilen mevcut en büyük HDD, Western Digital Ultrastar DC HC670 26TB'dir
- RAMAC'tan bu yana kapasite 7,2 milyon kat iyileşti
- Fiziksel boyut 5.000 kat küçüldü
- Enflasyona göre düzeltilmiş bayt başına maliyet 6 milyar kat ucuzladı
- Ancak seek time yalnızca 150 kat iyileşti ve rastgele okuma-yazma performansı saniyede yaklaşık 120 işlem seviyesinde kaldı
- Bu performans değeri S3'ün çıktığı 2006'da da benzerdi; ondan 10 yıl öncesiyle de büyük farkı yoktu
- HDD mekanik bir aygıt olduğu için kolun hareket etmesini ve platter'ın dönmesini beklemek gerekir; rastgele erişim performansı kapasite artışı kadar iyileşmez
- Sektör yol haritaları önümüzdeki 10 yıl içinde 200TB HDD'lere giden bir yolu işaret ediyor; bu seviyede, tüm verilere adil biçimde rastgele erişildiği varsayılırsa diskteki her 2TB veri için saniyede yalnızca 1 I/O'ya izin verilebileceği anlamına gelir
- S3 henüz 200TB diskler kullanmıyor, ancak bu diskleri ve aradaki tüm disk boyutlarını kullanması bekleniyor
Isı yönetimi: veri yerleşimi ve performans
- S3'te heat, belirli bir anda tek bir diske gelen istek sayısını ifade eder
- Isı yönetimi kötü yapılırsa istekler belirli bir diskte yoğunlaşıp hotspot oluşturur ve o diske bağlı isteklerin genel performansı kötüleşir
- Hotspot sistemi hemen durdurmaktan çok istek kuyrukları oluşturur ve müşteri deneyimini düşürür
- Meşgul diski bekleyen istekler gecikir
- Gecikme, metadata sorguları veya erasure coding gibi bağımlı I/O'lar üzerinden depolama stack'inin üst katmanlarına doğru büyür
- Bazı isteklerde yüksek gecikme, yani straggler oluşur
- Tekil HDD'lerdeki hotspot'lar tail latency'ye yol açar ve bırakılırsa tüm istek gecikmesini de etkiler
- S3, verinin yazıldığı anda gelecekte ne zaman ve nasıl erişileceğini bilemez; bu da yazma anındaki veri yerleşimi kararlarını zorlaştırır
- Küçük ölçekte I/O heat'i tahmin etmek ve yönetmek çok zordur; ancak S3'ün ölçeği ve çok kiracılı yapısında farklı özellikler ortaya çıkar
- Tekil iş yükleri çoğu zaman boşta kalıp aniden tepe yapma eğilimindedir, ancak milyonlarca iş yükü birleştirildiğinde toplam talep düz ve öngörülebilir hale gelir
- Belirli bir ölçek aşıldığında tek bir iş yükünün genel pik talebi etkilemesi zorlaşır veya imkânsız hale gelir
Çoğaltma ve erasure coding dayanıklılığı ve performansı birlikte ele alır
- Depolama sistemlerindeki yedeklilik yöntemleri verileri yalnızca donanım arızalarından korumakla kalmaz, ısı dağıtımına da yardımcı olur
- Çoğaltma, kopyaları birden çok diskte tutarak disk arızalarına dayanmayı ve okuma isteklerinin kopyalardan herhangi biri üzerinden karşılanabilmesini sağlar
- Çoğaltma kapasite açısından maliyetlidir, ancak okuma I/O'su açısından verimlidir
- S3, tüm veriler için çoğaltma overhead'i ödememek amacıyla erasure coding de kullanır
- Örnek yöntem Reed-Solomon gibi algoritmalar kullanır
- Nesne k adet identity shard'a bölünür
- m adet parity shard ek olarak oluşturulur
- Toplam k+m shard içinden yalnızca k tanesi kullanılabiliyorsa nesne okunabilir
- Bu yaklaşım, aynı sayıda arızaya dayanırken kapasite overhead'ini azaltır
Veri yerleşim stratejisi ve müşteri iş yükü izolasyonu
- Yedeklilik yöntemi, verileri gereken okuma sayısından daha fazla parçaya böler; bu sayede istekler aşırı yüklü disklerden kaçınarak gönderilebilir
- S3, yeni nesneleri disk filosunun geneline geniş biçimde yerleştirerek ısıyı daha da azaltır
- Tekil nesneler onlarca sürücüye yayılmış şekilde kodlanabilir ve farklı nesneler farklı sürücü kümelerine yerleştirilir
- Her bucket içindeki nesneleri çok sayıda diske yaymak iki avantaj sağlar
- Müşteri verisinin tek bir diskte kapladığı pay çok küçük hale gelir; böylece tekil iş yüklerinin belirli bir diskte hotspot oluşturması zorlaşır
- Tekil iş yükleri, bağımsız bir sistem olarak kurması zor ve pahalı olacak disk ölçeğine kadar burst yapabilir
- Genom analizi müşterisinin binlerce Lambda fonksiyonunda paralel analiz yürüttüğü burst, 1 milyondan fazla tekil disk tarafından işlenebilir
- Günümüzde S3'te, bucket'ları milyonlarca sürücüye yayılmış on binlerce müşteri vardır
- S3'ün farkı yalnızca depolama sisteminin kendi ölçeğinde değil, müşterilerin ve iş yüklerinin toplandığı ölçeğin sistemin karakterini bile değiştirebilmesindedir
Dayanıklılık incelemeleri ve guardrail'ler
- Amazon, mühendislerin ve ekiplerin hızlı ve güvenli şekilde başarısız olabilmesini önemli görür
- S3, yüksek dayanıklılığa sahip depolama sunarken hızlı hareket edebilmek için durability review sürecini kullanır
- Durability review, istatistiksel 11 9s modeline giren bir mekanizma değildir, ancak S3 operasyonunda önemli kabul edilir
- Bir mühendislik değişikliği dayanıklılık durumunu etkileyebilecekse durability review yapılır
- Bu süreç güvenlik araştırmalarındaki threat model fikrini ödünç alır
- Değişiklik özeti yazılır
- Kapsamlı bir tehdit listesi oluşturulur
- Değişikliğin bu tehditlere nasıl dayanacağı özetlenir
- Durability review iki rol üstlenir
- Yazarı ve inceleyenleri korunması gereken riskler üzerine eleştirel düşünmeye iter
- Riskler ile karşı önlemleri ayırarak her birinin ayrı ayrı tartışılabilmesini sağlar
- Karşı önlem ararken her ayrıntılı riske ayrı bir azaltım eklemek yerine, geniş risk gruplarını engelleyen basit ve güçlü guardrail'ler tercih edilir
ShardStore, Rust, hafif biçimsel doğrulama
- S3 birkaç yıl önce depolama stack'inin en alt katmanını, yani tekil disklerdeki verileri yöneten bölümü baştan yazma projesine başladı
- Yeni depolama katmanının adı ShardStore'dur
- ShardStore'u yeniden oluştururken benimsenen guardrail'lerden biri hafif biçimsel doğrulamadır
- Ekip, hataları daha erken bulmak için uygulama dilini Rust'a taşıdı
- Tip güvenliğinden yararlanır
- Yapılandırılmış dil desteğinden yararlanır
- Disk üzerindeki yapılara da tip güvenliğini genişleten kütüphaneler yazdı
- Doğrulama tarafında, ShardStore mantığının basitleştirilmiş bir modeli Rust ile yazıldı ve gerçek production ShardStore uygulamasıyla aynı repository'ye kondu
- Bu model, gerçek disk üzeri depolama katmanının ve HDD'lerin karmaşıklığını kaldıran çalıştırılabilir bir spesifikasyon işlevi görür
- Modelin boyutu gerçek sistemin yaklaşık %1'i kadardı, ancak 120 IOPS'luk sabit diskler karşısında gerçekçi olmayan düzeyde test yapılmasını sağladı
- Bu çalışma, SOSP makalesi Using lightweight formal methods to validate a key-value storage node in Amazon S3 olarak da yayımlandı
- Sonrasında araçlar ve property-based testing gibi mevcut teknikler kullanılarak uygulama davranışının spesifikasyonla uyumlu olup olmadığı doğrulandı
- Esas nokta, biçimsel doğrulama araştırma tekniklerinin sıradan mühendislerin sürdürebileceği koda ve her commit'te uygulanan araçlara endüstriyelleştirilmiş olmasıdır
- Doğrulama guardrail'i, ekibe daha hızlı geliştirme yapabilecekleri güvenini verdi ve yeni mühendisler katıldıktan sonra da korunmaya devam etti
Sahiplik ile ekiplerin ve bireylerin ölçeklenme sorununu ele almak
- Amazon'da ownership, belirli bir işin veya hizmetin başarılı olmasından sonuna kadar sorumlu olacak tek bir kişiyi ya da ekibi netleştiren kavramdır
- S3'te hızlı hareket ederken yüksek kalite standartlarını korumak için ekipler sahip olmalıdır
- Diğer sistemlerle API sözleşmelerine sahip olur
- Dayanıklılık, performans ve erişilebilirlikten sorumludur
- Beklenmeyen bir hata erişilebilirliği etkilerse sabah 3'te bile düzeltir
- Hata düzeltildikten sonra aynı şeyin tekrarlanmaması için sistemi iyileştirir
- Ownership büyük sorumlulukla birlikte güven de gerektirir
- Bir kişinin veya ekibin bir hizmete sahip olabilmesi için, onu nasıl sunacağına doğrudan karar verebileceği alan gerekir
- Lisansüstü araştırma projesi deneyiminde de öğrenciler bir fikrin kendilerine ait olduğunu hissettiklerinde ve onu kendileri geliştirebildiklerinde daha derin yatırım yaparlar
- Çok kıdemli mühendis rollerinde, çözümü doğrudan dağıtıma hazırmış gibi sunmak yerine problemi iyi tanımlamak ve ekibin çözümü sahiplenmesine yardımcı olmak daha etkilidir
- Birden fazla çözümün mümkün olduğu problemlerde uygun çözümü seçtirmek, birine çözümün sahipliğini vermenin bir yoludur
S3'ten çıkarılan sonuçlar
- S3'ün teknik ölçeği küçük sistemlerden yalnızca daha büyük olmakla kalmaz; iş yükleri, yapı ve operasyon biçimi temelden farklıdır
- “Sistem” yalnızca yazılımı değil, hizmet operasyonunu, operasyon organizasyonunu ve o hizmetle birlikte çalışan müşteri kodunu da kapsar
- Organizasyon da sistemin bir parçası olduğu için kendi ölçeklenme sorunlarına ve inovasyon fırsatlarına sahiptir
- Bireysel rolde başarılı olmak için çözümden çok problemi net ifade etmek ve güçlü mühendislik ekiplerinin çözümü gerçekten sahiplenmesini desteklemek gerekir
2 yorum
Hacker News yorumları
AWS'teyken hatırladığım konuşmalardan biri, milyarda bir olayın bile S3 ölçeğinde her gün yaşandığıydı.
Normalde olasılığı çok düşük diye endişelenmeye değmez denip geçilecek şeylerin bile mutlaka hesaba katılıp ele alınması gerekiyor.
ShardStore'u, özellikle de biçimsel doğrulama ve özellik tabanlı test gibi yaklaşımları görmek sevindirici. Önceki nesil servisler, organik büyümenin risklerini açıkça gösterecek kadar çok hataya sahipti; ama en azından arızaların “güvenli” biçimde gerçekleşmesi için tasarlanmışlardı, böylece veri kaybı önleniyordu ve S3 mühendisleri bu konuya takıntı derecesinde önem veriyordu.
Bu sadece S3 için de geçerli değil. Örneğin Prime Day 2022'de DynamoDB, yalnızca Amazon iş yükleriyle bile saniyede 105 milyondan fazla isteğe çıktı: https://aws.amazon.com/blogs/aws/amazon-prime-day-2022-aws-f...
Yazıda Andy, hafif biçimsel yöntemleri ve ekibin Rust'ı benimsemesini de ele alıyor; son derece düşük olasılıklı olayların bile olağan hale geldiği bir ölçekte, doğruluk için birden fazla araç ve süreç katmanına yatırım yapmak gerekiyor.
Hedeflediğimiz 500k TPS seviyesine çıkınca bunun dakikada 30 kez demek olduğunu açıkladım ve “o hafta on-call olmak ister misin?” diye sordum. O stack'te “en yüksek standartlarda ısrar etmek”, çoğu organizasyondakinden bambaşka bir anlama geliyor.
Neyse ki algoritma iyiydi ve günümüz donanımı da çok daha kararlı.
İlk büyük kriptografik hash çakışması patlak verdiğinde yaşanacakları şans eseri izleme fırsatı bulursam, patlamış mısırımı alıp seyretmeye hazır, biraz aksi bir ses de kafamın içinde var.
Genomik alanında çalışırken son 10 yılda petabayt ölçekli birçok veri deposuyla uğraştım.
AWS S3, GCP GCS ve ortak yerleşim donanımları için depolama sistemlerini (Ceph, Gluster, adını hafızamdan sildiğim HP sistemi) kullanınca, bu tür sistemleri işletmek için harcanan emeğe büyük saygı duymaya başladım.
Sayısız başka müşteriyle disk I/O paylaşmanın avantajını da küçümsemek zor. Yazıda geçen “heat” terimini ilk kez duydum ama tekil bir sistemde bunu hafifletmek gerçekten çok zor. Bizim ortak yerleşim kümemizde, büyük işler arasında I/O'yu düzgün yönetebilmek için batch sistemini değiştirip I/O'yu RAM veya CPU gibi tahsis edilebilir bir kaynak olarak ele almamız gerekti. S3 ve GCP çok pahalı, ama performansın bu paranın karşılığını verdiği zamanlar oluyor.
Bence HN'nin en iyi yanını gösteren yazılar bunlar.
Bulut depolama açısından en iyi müşteri, çok fazla veri depolayıp neredeyse hiç okumayan müşteridir. Bu, sabit disk kiralamaya benzer; ancak her diskin yalnızca bir kısmını “soğuk” verilerle doldurursanız, aynı diskin tüm I/O kapasitesini sıcak işleri işlemek için kullanmaya devam edebilirsiniz.
Hangi verinin hangi sürücüde tutulacağını çok dikkatli dengelediğinizde, verinin çoğu kullanılmasa bile tüm sürücüleri kullanmaya devam edebilirsiniz. Bu yüzden depolama görece ucuz, okuma ise görece pahalıdır.
S3'ü destekleseler bile performans çoğu zaman mümkün olan seviyenin çok altında kalıyor.
Zor; okuma erişilebilirliğinin yalnızca yaklaşık %99,95 olmasından dolayı üzgünüm.
S3, okuma/yazma erişimini devretmek için basit bir OAuth2 tabanlı protokol tanımlamış olsaydı, bununla yapılabilecek çok şey olurdu
Dünyanın, uygulamaların kullanıcı adına verilere erişebilmesini sağlayan HTTP tabanlı bir protokole ihtiyacı var. Google Drive buna en yakın olanı, ama yalnızca tek bir sağlayıcı var ve başka sorunları da bulunuyor[0]. remoteStorage’ın tutunamamış olması üzücü. Solid’in başarılı olmasını umuyorum ama bana fazla karmaşık geliyor. Bu soruna benim yaklaşımım https://gemdrive.io/ ancak şu anda self-hosting yığınının başka bölümlerine odaklandığım için neredeyse durmuş durumda
[0]: https://gdrivemusic.com/help
Bunu bugün düzgün şekilde yapmak inanılmaz zor. “Yalnızca şu belirli bucket’a erişebilen AWS kimlik bilgileri verme” sorununu çözmek için başlı başına bir CLI uygulaması yaptım, ama kullanıcılara bunu kurup çalıştırmalarını söylemek istemem: https://s3-credentials.readthedocs.io/en/stable/
Gerçekte kullanıcının S3 bucket’ı olan yerel bir dizini mount eden, istemci tarafı bağımlılıkları en az düzeyde bir kütüphane olsa iyi olurdu
Çünkü rakipler her an hasmane birlikte çalışabilirlik yoluyla içeri dalabilir
Kullanıcı veri egemenliği yaratmaya çalışan ya da hâlâ bunu yapan projelerin hepsinin tuhaf kripto para tarafına kaymış olması gerçekten üzücü
https://docs.aws.amazon.com/cognito/latest/developerguide/co...
Düzenleme: Yorumu yanlış okumuş gibiyim. Uygulamanın kullanıcı verilerini istemciye devretmek istediğini sanmıştım; aslında kullanıcının kendi verilerini uygulamaya devretmesini istiyor gibi. Bunlar farklı kullanım senaryoları
IBM RAMAC’ın teknik özelliklerinde depolama kapasitesi 3,75 MB, terabayt başına yaklaşık 9.200 dolar deniyor; bu doğru olamaz
Maliyeti depolama kapasitesiyle çarparsanız sürücünün fiyatı 3 sent ediyor
Bu site[1] “inç kare başına yaklaşık 2.000 bit depoluyordu ve satın alma fiyatı megabayt başına yaklaşık 10.000 dolardı” diyor
Bu yüzden teknik özellik muhtemelen megabayt başına 9.200 dolar olmalı. O zaman sürücü fiyatı 34.500 dolar olur ve bu çok daha makul
[1]: https://www.historyofinformation.com/detail.php?entryid=952
30 milyon bitti ve parite hariç yalnızca 6 veri bitinin kullanıldığı sayıydı. Ama aylık 3 bin dolara kiralandığı için fiziksel sürücüyü peşin satın almak gibi sabit bir maliyet yoktu. Bu yönüyle S3 modeline de epey benziyor
Çoğu kişinin fark etmediği şey, sihrin sistemin kendisini işletmekte değil, yetkilendirmeyi maliyetsizmiş gibi göstermekte olduğu
Dağıtık sistemlerde yetkilendirme inanılmaz zordur. AWS ölçeğinde bu neredeyse sihir gibidir. AWS’in zengin bir yetki modeli var ve yetki değişiklikleri, muhtemelen trilyonlarca isteği işlerken bile, tüm altyapıya milisaniyenin altında hızlarla yayılıyor
Bu kısım ile faturalandırma için loglama/mutabakat, AWS hakkında yazılı olarak okumak istediğim iki sihirli unsur
S3, erişim denetimini diğer hizmetlerden farklı ele alıyor; yetkiler kaynağa bağlı. Muhtemelen hız yüzünden
Bucket/anahtar erişim yaklaşımının özel olmasının nedenlerinden biri, IAM çıktığında bu modelin zaten yerleşmiş olmasıydı
Sonrasında da korunmasının nedeni muhtemelen, mevcut modeli kaldırmanın birçok müşteri ayarını bozabilecek zor bir iş olmasıdır
“Şirkette gerçekten kıdemli bir mühendis olarak elbette güçlü görüşlerim ve teknik gündemlerim var. Ama mühendislerle etkileşime girerken yalnızca fikir dağıtmaya çalışırsanız herkesin başarılı olması zorlaşır. Sahiplenmediğiniz bir fikre bağlanmak çok daha zordur. Bu yüzden ekiple çalışırken en iyi fikirlerimin benden değil, başkalarından çıkmış fikirler olmasını sağlamaya yönelik bir strateji izledim. Çözümü satmaktansa, problemi geliştirmeye ve onu çok iyi ifade etmeye bilinçli olarak çok daha fazla zaman harcıyorum. Bir problemi çözmenin çoğu zaman birden fazla yolu vardır; doğru yolu seçmek de birinin çözümü sahiplenmesini sağlamaktır.”
“Rolümde gerçekten başarılı olmak için, çözüme değil problemi net biçimde ifade etmeye odaklanmam ve güçlü bir mühendislik ekibinin o çözümü gerçekten sahiplenmesini desteklemenin yollarını bulmam gerektiğini öğrendim.”
Bu kısım gerçekten hoşuma gitti. Bir ölçüde Ikea etkisini hatırlatıyor. Birinin yaptığı işe tutkuyla bağlanmasını istiyorsanız sahiplenme duygusunu teşvik etmeniz gerekir; bunun iyi bir yolu da o işin “o kişinin fikri” haline gelmesini sağlamaktır
Sonuçta insanlar çoğu zaman daha en başta “problemin” ne olduğu konusunda farklı düşünür
Neyse ki tüm problemler böyle değil. Ama örneğin Python’daki “paketleme problemi” tartışmalarına bakarsanız, gerçekte yaklaşık 6 farklı problemin insanlar tarafından çok farklı şekillerde tarif edildiğini görürsünüz; bu olgu orada oldukça kötü biçimde ortaya çıkıyor
Andy Warfield bunu okuyorsa, ki muhtemelen okuyordur, bir sorum var. Bir problemi geliştirirken olası çözümleri kabaca taslaklamak ne kadar değerli? Problemi net ifade edince birkaç olası çözüm doğal olarak akla gelecektir; potansiyel sahiplerin düşünmesini başlatmak için bu çözümleri paylaşmaya değer mi? Yoksa yalnızca probleme odaklanıp çözüm alanını tamamen açık bırakmak mı daha iyi?
Ek olarak, böyle çok kıdemli bireysel katkı sağlayıcıların çalışma biçimi hakkında okunabilecek başka kaynaklar var mı?
Bana “Ey sıradan kişi! Senin probleminle ilgilenecek vaktim yok. Sadece problem getirirsen senin işin üzerinden terfi edemem ki” diyormuş gibi geliyor
Bir problemi çözebilmek için önce onu anlamak ve varlığını kabul edebilmek gerekir
Önceden tanınmış otorite ya da uzmanlık olmayan durumlarda, yani gündelik problemlerin çoğunun ortaya çıktığı bağlamlarda, uzun, ayrıntılı ve özenle hazırlanmış bir problem açıklamasıyla iki yönlü konuşma kanalını tek başınıza kaplarsanız, sadece konuşup iş yapmamak isteyen biri ya da başkalarıyla birlikte çözüm aramak istemeyen biri gibi görünmeniz kolaydır
Amazon çalışanlarının S3’ün iç işleyişi hakkında açıkça konuşabilir hale gelmesini görmek güzel
Glacier’ın nasıl çalıştığını da daha fazla duymak isterim. Bildiğim kadarıyla temel depolama ortamının ne olduğunu hiç açıklamadılar; bu yüzden teyp mi, çevrimdışı HDD mi, özel HDD mi diye türlü spekülasyonlar yapıldı
Ama buna katılmayanlar da var. Hâlâ bilinmiyor
AWS’in onunla ilgili her şeyi ve tüm yolculuğunu anlatmasını isterdim. Gerçekten ilginç bir konu
Tek gereken bir mühendisin sarhoş olup gevezelik etmesi olurdu. Çok daha ciddi bir alanda, Massachusetts’ten bir asker oyuncu arkadaşlarına havalı görünmek için ulusal güvenlik bilgilerini Discord’a sızdırdı ve uzun bir hapis cezasıyla karşı karşıya. Glacier ayrıntılarının şimdiye kadar ortaya çıkmış olacağını sanırdım
“Sabit disk kafasını, saatte 75 mil hızla bir çim alanın üzerinde uçan bir 747 gibi hayal edin. Uçağın altı ile çimlerin uçları arasındaki hava boşluğu iki yaprak kâğıt kalınlığındadır. Diskteki bitleri çim yapraklarıyla ölçersek, iz genişliği 4,6 çim yaprağı, bit uzunluğu ise bir çim yaprağıdır. Uçak çimlerin üzerinde uçup çim yapraklarını sayarken, dünyanın etrafında 25 bin tur attığı her seferde yalnızca bir çim yaprağını kaçırır.”
Yük dengeleme kısmı bana S3 KeyMap dönemini ve ilk uygulamadan ona geçiş yapmaya çalıştığımız zamanları hatırlattı
Öğrendiğimiz şey, en sıcak nesneyi/partition’ı/bucket’ı belirledikten sonra onu basitçe taşıyıp işi bitiremeyeceğinizdi. Her şeyi sıralamak gerekiyordu. Asıl çözüm, sıraladıktan sonra host’ların partition yükünü çeyrekliklere bölmek ve ikinci çeyrekteki partition’ı en düşük yüke sahip host’a taşımaktı
En sıcak bucket’ı, yani birinci çeyreği taşımaya çalıştığınızda kalan üyelere daha fazla yük biniyor ve işlem sürekli başarısız oluyordu
Bir başka yan etki olarak hata oranı istikrarlı yaklaşık %1 seviyesinden, günler boyunca hiç hata görülmeyen bir duruma geçti; bunun sonucunda uyarı eşiklerini çok daha sıkı hale getirdik. Yaklaşık 2009 civarıydı
Benim de UM’den akademik bir geçmişim vardı ama doktora yerine S3’e katıldım. Kafiyesi de tutuyor
S3 depolamadan fazlası, bir standart
Bazı yerlerde, genelde küçük birkaç şartla birlikte, S3 uyumlu depolama kullanabilmek güzel. Standardın ne kadar açık olduğunu ya da “S3 compatible” diyebilmek için Amazon’a para ödemek gerekip gerekmediğini bilmiyorum ama oldukça hoş
Örnek olarak iDrive’ın E2’si, Digital Ocean Object Storage, Cloudflare R2, Vultr Object Storage ve Backblaze B2 var
Düzenleme: Bakınca Azure’da gerçekten yok gibi görünüyor :-/
Hacker News yorumu
Genomik alanında çalışırken son 10 yılda birçok petabayt ölçekli veri deposuyla uğraştım.
S3, OAuth2 tabanlı bir protokolle okuma/yazma erişimini devretmeye izin verse neler inşa edebilirdik.
Dağıtık sistemlerde kimlik doğrulamayı ele almak çok zordur.
Amazon çalışanlarının S3'ün iç işleyişi hakkında kamuya açık şekilde konuştuğunu görmek güzel.
Sabit disk kafasını 747 uçağına benzeterek anlatan kısım.
S3 KeyMap dönemine geri dönünce, en sıcak nesneleri/bölümleri/bucket'ları belirledikten sonra bile sorunun sadece taşıyarak çözülemeyeceğini öğrendik.
S3 yalnızca basit bir depolama hizmeti değil, bir standarttır.