Sürekli yenilik: AWS blok depolamanın kısa tarihi
(allthingsdistributed.com)- AWS EBS, EC2 için ağa bağlı blok depolama fikrinden yola çıktı; paylaşımlı HDD tabanlı bir hizmetten, günde 140 trilyondan fazla işlemi işleyen dağıtık bir SSD filosuna dönüştü
- İlk performans sınırları yalnızca HDD’lerin 120~150 IOPS ve ortalama 6~8 ms gecikmesinden değil, birden fazla müşteri iş yükünün aynı diski paylaşmasından doğan noisy neighbor sorunundan da kaynaklanıyordu
- SSD’lerin devreye girmesiyle 2012’de Provisioned IOPS birimleri en fazla 1.000 IOPS ve ortalama yaklaşık 2~3 ms gecikme sundu; ancak darboğaz ağ, hipervizör ve yazılım kuyruklarına kaydı
- EBS ekibi tüm IO yolunu ölçümledi ve Xen kuyrukları, Nitro offloading, şifrelemenin donanımda işlenmesi, TCP ayarları ve SRD taşıma protokolüne kadar katman katman iyileştirmeler yaptı
- Performans artışı, büyük ölçekli yeniden yazımlardan çok kesintisiz geçişler, küçük ekiplerin bağımsız değişiklikleri, sürekli ölçüm ve geri alınabilir kademeli iyileştirmelerle ilerledi
EC2 için blok depolamadan büyük ölçekli SSD filosuna
- EBS, 20 Ağustos 2008’de, EC2 beta lansmanından yaklaşık 2 yıl sonra, EC2 instance’ları için ağa bağlı blok depolama sağlama fikrinden doğdu
- O dönemde ekipte bir iki depolama uzmanı ve birkaç dağıtık sistem mühendisi vardı; bilgisayar sistemleri ve ağ bilgilerine dayanarak hizmeti oluşturmaya başladılar
- Daha sonra EBS, paylaşımlı HDD ürününden tek bir EC2 instance’ına yüz binlerce IOPS sağlayabilen bir hizmete dönüştü
- Bugün tek bir instance’a sağlanabilen IOPS, ilk HDD tabanlı dönemde tüm Availability Zone’a sağlanan seviyeden daha yüksek
- EBS’in tamamı, dağıtık SSD filosunda günde 140 trilyondan fazla işlem işliyor
- Başlıca iş yükü EC2 instance’larının sistem diski; fiziksel bir sunucudaki sabit diskin rolünü ağ depolaması olarak sunmaya yakın bir yapı
- Müşteriler dayanıklılığı önemli görse de EC2 deneyimiyle doğrudan bağlantılı olan performans ve erişilebilirliği de aynı derecede önemli kabul ediyor
- io2 Block Express birimleri ve volume snapshot’ları, yüksek dayanıklılığa ulaşmak için temel bileşenler olarak sunuluyor
- EBS birimlerinin performans ve erişilebilirliği, EC2 tabanlı uygulama deneyimine neredeyse doğrudan yansıyor
Kuyruklama ve HDD’lerin oluşturduğu ilk sınırlar
- Bilgisayar sistemlerinde depolama istekleri CPU, veri yolu ve aygıt arasında birçok kuyruktan geçerek işlenir
- Ağ depolamasında işletim sistemi çekirdeği, depolama adaptörü, depolama fabric’i, hedef depolama adaptörü ve depolama ortamı arasında birden çok kuyruk oluşur
- 2008’de EBS ilk oluşturulduğunda depolama pazarı ağırlıklı olarak HDD idi ve gecikmeyi depolama ortamının kendisi belirliyordu
- Sabit diskler mekanik aygıtlar olduğundan fiziksel sınırlara sahipti
- On yıllar boyunca HDD performansı kabaca saniyede 120~150 işlem, ortalama IO gecikmesi ise 6~8 ms seviyesinde kaldı
- Kuyruklama ve sürücü içi komut yeniden sıralama nedeniyle kuyruk gecikmesi yüzlerce ms’ye kadar uzayabiliyordu
- O dönemde EBS’in uçtan uca gecikmesi onlarca ms mertebesindeydi; bu yüzden ağdan eklenen onlarca mikrosaniye toplam gecikmenin küçük bir kısmını oluşturuyordu
- HDD performansı, kuyrukta bekleyen diğer işlerden büyük ölçüde etkilenir
- Ortama dağılmış küçük rastgele istekleri bulmak ve erişmek, birbirine yakın birkaç büyük isteğe göre daha uzun sürer
- Müşterileri birden fazla diske dağıtmak, en yoğun iş yüklerinin tepe anlarının üzerindeki gecikmeyi azalttı; ancak düzensiz davranış daha fazla müşteriye yayıldı
- Bir iş yükünün başka bir iş yükünü etkilemesi anlamına gelen noisy neighbor, önemli bir iş sorunu haline geldi
- AWS, müşteri deneyimi kalitesini artırmak için güçlü performans yalıtımına ihtiyaç olduğunu düşündü
- Disk zamanlama algoritmalarını değiştirmek ve iş yüklerini daha fazla spindle’a yaymak yalnızca küçük, kademeli iyileştirmeler sağladı
SSD sonrası ölçümlemenin önemi
- 2011 civarında SSD’ler daha yaygın hale geldi ve AWS’in değerlendirebileceği kapasitede sunulmaya başladı
- SSD’lerde veriyi bulmak için fiziksel kol hareketi yoktur; rastgele istekler sıralı isteklere neredeyse aynı hızda yanıt verir ve denetleyici ile NAND çipleri arasında birden çok kanal bulunur
- EBS önce SSD tabanlı yeni bir depolama sunucusu tipi ve Provisioned IOPS adlı yeni bir volume tipi oluşturdu
- Yeni volume tipini çıkarmak küçük bir iş değildi ve bundan yararlanabilecek iş yükleri de sınırlıydı
- HDD’leri SSD’lerle değiştirince neredeyse tüm sorunların çözüleceği beklentisinin aksine, noisy neighbor sorunu otomatik olarak ortadan kalkmadı
- Ağustos 2012’de çıkan Provisioned IOPS en fazla 1.000 IOPS sağlıyordu
- Mevcut EBS standard volume’larından 10 kat yüksekti
- Ortalama gecikme yaklaşık 2~3 ms idi; 5~10 kat iyileşme sağlandı
- Aykırı değerlerin kontrolü de büyük ölçüde iyileşti
- Bu noktada EBS’te yalnızca temel telemetri vardı; neyin düzeltileceğine karar vermek için daha ayrıntılı ölçümleme gerekiyordu
- Ekip, her IO’yu birden fazla noktadan izleyen bir yöntem kurdu
- EBS istemci initiator’ı
- Ağ yığını
- Depolama dayanıklılık motoru
- İşletim sistemi
- Müşteri iş yükü izlemesine ek olarak, iyi bilinen iş yüklerinde değişikliklerin olumlu ve olumsuz etkilerini sürekli kontrol eden canary testleri oluşturuldu
Donanım ve yazılımı birlikte ele alan iyileştirmeler
- Yeni telemetri, ilk yatırım alanlarını net biçimde gösterdi
- Tüm sistemdeki kuyruk sayısının azaltılması gerekiyordu
- EC2’de kullanılan Xen hipervizörünün IO yolundaki karmaşıklığı azaltma fırsatı vardı
- Ağ yazılımı optimizasyonu gerekiyordu
- Temel dayanıklılık motorunda disk üzeri veri yerleşimi, cache line optimizasyonu ve asenkron programlama modelinin benimsenmesi gerekiyordu
- AWS’in sistem performansı sorunları çoğu zaman donanım ve yazılım yığınının birden fazla katmanını aynı anda keser
- EBS, depolama sunucusu ekibiyle istemci ekibini paralel hareket ettirdi; EC2 hipervizör mühendisleri ve AWS iç ağ performans grubu da birlikte katıldı
- Geliştirme organizasyonu da yazılım sistemleri gibi divide and conquer yaklaşımıyla bölündü
- Monolitik depolama sunucusu geliştirme ekibi, veri çoğaltma, dayanıklılık, snapshot hydration gibi alanlara göre küçük ekiplere yeniden düzenlendi
- Her ekip, sıkı testlere dayanarak bağımsız biçimde yineleme yapıp değişiklikleri uygulayabiliyordu
- 2013’te oluşturulan plan, bugünkü EBS görünümüyle aynı değildi ama gidilecek yönü sağladı
- O dönemde Amazon’un bir gün kendi SSD’sini geliştireceği ve EBS ihtiyaçlarına göre uyarlanmış bir teknoloji yığınına sahip olacağı öngörülmemişti
Xen’den Nitro ve SRD’ye uzanan darboğazların kaldırılması
- 2017 sonuna kadar tüm EC2 instance’ları Xen hipervizörü üzerinde çalışıyordu
- Xen aygıt yolunda, guest domain ile ayrıcalıklı driver domain olan dom0’ın bilgi paylaştığı bir ring queue vardı; EBS istemcisi dom0’daki çekirdek blok aygıtı olarak çalışıyordu
- Bir instance’tan EC2 host’unun dışına çıkana kadar IO isteği birçok kuyruktan geçiyordu
- Instance blok aygıt kuyruğu
- Xen ring
- dom0 çekirdek blok aygıt kuyruğu
- EBS istemci ağ kuyruğu
- EBS ekibi, her kuyruğun etkisini ayrıştırmak için çeşitli loopback aygıtları yazdı
- dom0 aygıt sürücüsü gecikmesi neredeyse hiç olmasa bile, birden fazla instance aynı anda IO ürettiğinde tüm sistemin etkin throughput’unun yavaşladığı görüldü
- EC2, Xen’in varsayılan blok aygıt kuyruğu sayısı ve kuyruk entry sayısıyla çıkmıştı
- Bu varsayılan değerler, geçmişteki Xen geliştirme ortamının sınırlı depolama donanımı temel alınarak belirlenmişti
- Tüm host için outstanding IO isteği 64 ile sınırlıydı; bu cihaz başına bir sınır değildi
- 2013’te yalnızca ağ için ilk Nitro offload card geliştiriliyordu
- VPC yazılım tanımlı ağ işlemesini Xen dom0 çekirdeğinden özel bir donanım pipeline’ına taşıdı
- Paket işleme data plane’ini hipervizörden ayırarak müşteri instance’larının CPU cycle’larını ağ trafiğini işlemeye harcamamasını sağladı
- Aynı yaklaşım EBS depolamasına da uygulandı
- Daha fazla işlem donanıma taşınarak hipervizördeki işletim sistemi kuyrukları azaltıldı
- Interrupt tabanlı işler offload edilerek hipervizörün istek işlemeye harcadığı süre azaldı
- İkinci Nitro kartı, EBS şifreli volume’larını performans etkisi olmadan işleyebilen donanım özelliklerine de sahipti
- Şifreleme anahtarı materyalini hipervizörden ayırarak müşteri verilerini ek olarak korudu
- EBS Nitro’ya taşındıktan sonra darboğaz ağın kendisine kaydı
- Modern veri merkezi TCP tuning parametreleri ve congestion control algoritmaları incelendi
- Depolama sunucusu isteklerine küçük rastgele gecikmeler eklemenin, ağ smoothing etkisiyle ortalama gecikmeyi ve aykırı değerleri azalttığı durumlar da oldu
- Bu tür ayarlar, sistem performansı ve ölçek büyümeye devam ettikçe uzun ömürlü olmadı; regresyonları önlemek için ölçüm ve izleme sürekli gerekliydi
- 2014’te TCP’den daha iyi bir yöntemi hedefleyen Scalable Reliable Datagram(SRD) tabanlı çalışma başladı
- İlgili makale A Cloud-Optimized Transport Protocol for Elastic and Scalable HPC
- Gereksinimler arasında hata kurtarma ve yön değiştirme kabiliyetinin iyileştirilmesi, donanım offloading kolaylığı yer alıyordu
- SRD tasarımında iki gözlem önemliydi
- Genel internet yerine AWS veri merkezi ağı tasarımına odaklanılabilirdi
- Depolamada uçuş halindeki IO isteklerinin yürütme sırası yeniden düzenlenebilirdi
- TCP’nin katı in-order delivery maliyetinden kaçınmak ve farklı istekleri birden fazla ağ yolundan gönderip vardıklarında çalıştırmak mümkündü
- SRD yalnızca depolamada değil, ağda da kullanılıyor
- Elastic Network Adapter(ENA) Express içinde SRD, guest’in TCP yığını performansını iyileştirir
- Birden fazla ağ yolundan yararlanarak ve ara ağ aygıtlarındaki overflow ile kuyrukları azaltarak daha yüksek ağ kullanımı sağlayabilir
SSD cache ve kesintisiz geçiş
- EBS, yalnızca bazı volume’ların ve müşterilerin daha iyi performans elde ettiği durumdan memnun değildi; SSD avantajlarını daha geniş sunmak istedi
- O dönemde binlerce depolama sunucusunda milyonlarca non-provisioned IOPS müşteri volume’u çalışıyordu
- Bunların bazıları bugün hâlâ mevcut
- Tüm donanımı atıp değiştirmek maliyetliydi
- Sunucu kasasında boş alan vardı; ancak soğutma hava akışını engellemeyen tek konum anakart ile fanlar arasındaydı
- SSD’ler küçük ve hafifti ama kasa içinde sallanmamaları gerekiyordu; malzeme bilimcilerin yardımı ve deneme yanılma sonunda ısıya dayanıklı endüstriyel hook and loop fastening tape bulundu
- 2013’te birkaç ay boyunca EBS, binlerce sunucunun her birine elle 1 SSD yerleştirdi
- Yazılıma, yeni yazmaları SSD’ye staging yapıp uygulamaya tamamlandı yanıtı verdikten sonra yavaş HDD’ye asenkron flush eden küçük bir değişiklik eklendi
- Bu çalışma müşteri kesintisi olmadan yürütüldü
- EBS en baştan kesintisiz bakım etkinlikleri düşünülerek tasarlanmıştı
- EBS volume’u yeni bir depolama sunucusuna retarget edilebiliyor, boş sunucu güncellenebiliyor veya yeniden oluşturulabiliyordu
- Müşteri volume’larını yeni depolama sunucusuna taşıma becerisi daha sonra birçok kez işe yaradı
- Disk üzeri format için daha verimli veri yapıları devreye alınırken kullanıldı
- Eski donanım yeni donanımla değiştirilirken de kullanıldı
- 2008’de EBS’in ilk çıkışından sonraki ilk aylarda oluşturulmuş ve hâlâ aktif olan volume’lar var
- Bu volume’lar muhtemelen yüzlerce farklı sunucudan ve birden fazla donanım neslinden geçti
- Filo güncellemeleri ve yeniden oluşturma işlemleri bu iş yüklerini etkilemeden yapıldı
Performans ölçeğine göre liderlik biçimi
- EBS’in ölçeği yalnızca teknik açıdan değil, organizasyon açısından da küçük şirket veya startup ortamlarından farklıydı
- Bir sistem uzmanı tüm escalation’lara, commit review’larına ve tasarım değişikliği incelemelerine dahil olursa organizasyonun performans darboğazı haline gelebilir
- Bunu çözmek için yalnızca kodda değil, işbirliği biçiminde de deneyler yapıldı
- Temel araçlardan biri olarak peer debugging kullanıldı
- Birden fazla mühendis kodu ve terminali birlikte izleyerek sorunu takip etti
- Kritik data structure güncellemelerinde locking’in nerede ve nasıl yapıldığıyla ilgili bir sorun bulunan örnek tespit edildi
- Normalde sorun görünmüyordu; ancak bazen istek yanıtları yavaşlıyordu ve bu düzeltilerek jitter’ın kaynaklarından biri ortadan kaldırıldı
- Mühendislere güvenli biçimde deney yapabilecekleri yetki vermek, engelleri azaltırken guardrail’leri korumak daha iyi sonuçlara yol açabiliyordu
Büyük yeniden yazımlar yerine sürekli iyileştirme
- EBS iyileştirmeleri tek bir dev değişiklik olarak değil, zamana yayılan kademeli iyileştirmeler dizisi olarak ilerledi
- Bu yaklaşım müşteri değerini daha hızlı sunmayı ve müşteri iş yükleri değiştikçe öğrenilenleri yansıtarak yönü değiştirmeyi mümkün kıldı
- EBS gecikme deneyimi, IO işlemi başına ortalama 10 ms’nin üzerinde seviyeden, en yüksek performanslı io2 Block Express volume’larında tutarlı sub-millisecond IO seviyesine iyileşti
- Bu değişim, yeni mimariyi sunmak için hizmet offline’a alınmadan başarıldı
- Müşteriler sürekli daha fazla performans istiyor; bu talep EBS’in inovasyon ve yinelemelerini sürükleyen güç olmaya devam ediyor
1 yorum
Hacker News yorumları
Bu yazıyı burada görmek gerçekten sevindirici. Büyük ölçekli sistemlere azıcık bile ilginiz varsa mutlaka okunmalı.
Sıralı iş yüklerinde modern manyetik diskler okuma/yazmada 100MB/s üzeri hız verebilir, ancak tamamen rastgele 4kB iş yüklerinde bu değer 400kB/s'ye kadar düşebilir. Kuyruklama ve zamanlama en kötü durumu engellese de, gerçek performans iş yüküne göre 100 kattan fazla değişebilir; bu da çok kiracılı sistemlerin başa çıkmasını son derece zorlaştırır. Özellikle okuma tarafında, “gidip başka bir yere yazmak” gibi bir kaçınma yöntemi yoktur.
Marc'tan öğrendiğim en büyük şey, neyin bozuk olduğunu anlamak için önce ona düzgün bakmak gerektiğiydi. Gecikme görselleştirmeleri, örneğin yazıdaki histogram zaman serileri gibi şeyler oluşturdu ve o görselleştirmeler üzerinden hikâyeyi anlatarak ekibin ne yapması gerektiğine tamamen farklı bakmasını sağladı. Histogramdaki her tepenin kendine özgü bir nedeni ve optimizasyon çalışması vardı; performans verilerine farklı açılardan derinlemesine bakmaya yatırım yapmadan görünmeyen verimlilikler ve fırsatlar ortaya çıkıyor.
2013'te her birine birer SSD eklenen binlerce sunuculuk retrofit projesi, AWS hikâyeleri içinde en sevdiklerimden biri. En baştan kesintisiz bakım olayları düşünülerek EBS volume'lerinin yeni depolama sunucularına yeniden atanabilmesi ve boşalan sunucuların güncellenip yeniden kurulabilmesi mümkün kılındığı için bu yapılabildi. Bu, dağıtık sistemlerin sadece ölçek büyütmek için olmadığını; sunucu arızalarını doğal biçimde tolere edip veriyi kayıpsız taşıyarak büyük ölçekli operasyonları da mümkün kıldığını gösteren güzel bir örnek.
Google'dan Dick Lyon da Google depolama sunucularında aynı yaklaşımı kullanmıştı ve https://www.pdl.cmu.edu/SDI/2015/slides/DatacenterComputers.... bağlantısındaki 62. slayttan itibaren blok depolamadaki temel darboğazlar olarak çeşitli kuyrukları ve kaynak çekişmesini tespit ediyor.
Eski günleri hatırlattı. Reddit, 2008'de EBS'in ilk kullanıcılarından biriydi ve 5 EBS volume'ü ile yazılımsal RAID kurmanın IOPS'u artırdığını keşfedince kendimizi çok akıllı sanmıştık.
O dönemde her volume'ün performansı çok dalgalıydı; bu yüzden 7-8 tane açıp okuma/yazma yükü çalıştırıyor, sonra en iyi performans veren 5 tanesini seçip Linux yazılımsal RAID ile birleştiriyorduk. İyi gittiğinde istediğimiz etkiyi veriyor, hatta tek bir düğümün 5 katından bile fazla IOPS üretiyordu; ama kötü gittiğinde gerçekten korkunç oluyordu.
Yazılımsal RAID'de tek bir düğüm yavaşsa tüm RAID'in en yavaş volume hızında çalıştığını bilmiyorduk; sonuç olarak veritabanı bozuluyormuş gibi görünüyordu. Sebebin RAID olduğunu anlamamız zaman aldı ve kötü düğümü çıkarmak da zordu. Çünkü yazılımsal RAID, o yavaş volume'e yazmayı bitirene kadar onu bırakmıyordu.
Yeni EBS volume'leri ekleyip diziyi yeniden oluşturmak zorunda kalıyorduk; bu da yine yeni volume'lerin IOPS'una takıldığı için iyi değildi. Sonrasında o yazılımsal RAID'i kullanmayı bıraktık ve Netflix'te neredeyse hiç EBS kullanmadık. Reddit'te yaptığım hataları dinleyen herkese anlatıyordum; ben katılmadan önce bile Netflix zaten yalnızca yerel disk kullanma yönünde standartlaşmıştı.
Komik bir ayrıntı olarak, AWS'nin büyük EBS kesintisi sırasında ben Reddit'te çalışıyordum ve veritabanını düzeltmek için EBS'in geri gelmesini beklerken Netflix izliyordum. Netflix mülakatında “EBS kesintisi sırasında nasıl ayakta kaldınız?” diye sorduğumda, “Aa, biz zaten EBS kullanmıyoruz” demişlerdi.
Bu yazıyı okumak güzeldi.
İlginç olan şu ki, yazının kapsadığı dönemde AWS'in EBS yüzünden yaklaşık 4 günlük bir kesinti yaşadığını ve bunun EC2, EBS ve RDS'yi etkilediğini hatırlıyorum. Bu kesinti, AWS'e duyulan güveni ciddi biçimde sarstı.
Bunun sonucunda organizasyonel değişiklikler oldu ve EBS'e bağımsız bir servis olarak çok daha derin yatırım yapıldı. Bu dönem aynı zamanda Apple'ın müşteri olduğu zamana denk geliyor ve Netflix, Zynga, Dropbox gibi girişimlerin benimsemesi sayesinde AWS genelinde çok hızlı büyümenin yaşandığı bir dönemdi.
Bu tür teknik ve operasyonel hikâyeler ilginç olsa da, prodüksiyondaki teknik yenilikler dağınık süreçler ve gerçek dünyadaki iş gereksinimleri zemininde ortaya çıkar. Keşke bu hikâyeleri de daha fazla duyabilsek.
Ama çark yeniden döndü ve tekrar özellik geliştirmeye geri dönüldü. Orada bulunduğum süre boyunca o yılı her zaman en az eskalasyonun yaşandığı yıl olarak hatırladım.
“Depolama sunucusu isteklerine az miktarda rastgele gecikme eklemek, ağı düzleştirme etkisi yarattığı için ortalama gecikmeyi ve aykırı değerleri aslında azalttı” kısmı ilgimi çekti. Bunun neden olduğunu açıklayabilir misiniz?
İlgilenenler için, 2009'da Amazon S3'ün iç yapısı hakkında yapılmış bir konuşma [0] var. S3 ekibinin iç materyallerine dayanarak hazırlanmıştı ve buradaki birçok şey EBS'in geliştirilme biçimini de etkiledi.
[0]: https://vimeo.com/7330740
2013’te tüm EBS ekipmanlarına SSD’leri elle eklemiş olmaları hoşuma gitti. Fotoğrafa bakınca Samsung SATA SSD’ye oldukça benziyor
https://www.allthingsdistributed.com/images/mo-manual-ssd.pn...
Yanılıyor olabilirim ama Dell blade’lere SSD takıp kullanmak bundan çok daha önceydi diye hatırlıyorum. 2010–2012 civarında I/O performansı gerçekten büyük bir konuydu ve döner disklerden flash belleğe geçilen dönemdi
Hata işleme ya da wear leveling bile olmayan ham flash tabanlı aygıtlarla denemeler yaptığımı hatırlıyorum. Çılgıncaydı ama herkes döner disklerden silikona geçişin getirdiği muazzam I/O performansı artışına çaresizce ihtiyaç duyuyordu
Disk hızları o kadar hızlı arttı ki ilk SKU 6 ay içinde eski kaldı. Bu rack’leri plandan birkaç yıl önce devre dışı bırakırken varlık ekibine bizzat açıklama yapmak zorunda kalmamış olmama sevindim. Çünkü daha yeni, daha yoğun ve daha hızlı modeller koymak rack alanı açısından çok daha değerliydi
İşe yarar açık kaynaklar çıkmadan önce hizmet olarak depolama altyapısı kurduğum günleri hatırladım. Sun SAN, Fibre Channel ve Solaris’ten çıkıp Linux ve NFS çalıştıran Supermicro depolama sunucuları üzerindeki GlusterFS’e geçmiştik; 2007’de ayrılmadan önce neredeyse 2PB’a ulaşmıştık
Ayrıca sunucu çalışır durumdayken döner diskleri SSD’lerle değiştirip mdraid’i gizlice bozup yeniden kurmanın gayet makul görüldüğü günleri de hatırlıyorum. Çünkü SATA belli ölçüde disk hot-swap destekliyordu. Döner disklerden SSD’ye geçince platformdaki en kritik sistemin IOPS değeri 14 kat arttı
Kariyerimin başlarında, insan sayısı değil teknik ve operasyonel ölçek açısından büyük bir internet şirketinde tüm sistem genelinde çalıştım. Kısa sürede öğrendiğim derslerin sayısı akıl almazdı. O şirketten ayrıldıktan sonra, çoğu insanın kariyeri boyunca bu tür sorunlarla neredeyse hiç karşılaşmadığını ve bu yüzden o dersleri de öğrenemediğini fark ettim
Bu yüzden bir mesleki yeterlilik sistemi olması gerektiğini düşünüyorum. Usta bir mühendisin yanında çıraklık şartı olursa, yalnızca deneyimle öğrenilebilecek çok değerli bilgi ve beceriler kısa sürede kazanılabilir ve sonrasında çok daha etkili çalışılabilir. Adaylarla mülakat yaparken de deneyim kanıtı ve mentor tavsiyesi çok değerli olurdu
Şu cümleyi beğendim
“Geniş övgü gören full-stack engineer ideali de değerli, ancak derin ve karmaşık sistemlerde asıl daha değerli olan şey çoğu zaman tüm stack boyunca ve herkesin kendi derin uzmanlık alanları arasında iş birliği yapabilen ve yaratıcı çalışabilen bir uzmanlar topluluğu oluşturmaktır”
Yazının ilk diyagramı hatalı ya da oldukça eski. Modern bilgisayarlarda PCIe lane’lerin çoğu eskisi gibi ayrı bir PCH üzerinden değil, doğrudan CPU’nun I/O hub’ına ya da Uncore bölgesine bağlanır
Bu, hem I/O throughput’u hem de gecikme açısından önemli bir gelişme. Bunun dışında harika bir yazı; sonuçta her yerin bir kuyruk olduğunu iyi gösteriyor
Görsel açıklamasına bunun o dönemin yapısı olduğunu net biçimde ekleyeceğim