IO Aygıtları ve Gecikme Süresi
(planetscale.com)- Kalıcı depolama aygıtları teypten HDD, SSD ve bulut ağ depolamasına evrilmiş olsa da verinin konumu ve yerleşimi hâlâ IO gecikmesini belirler
- Teyp depolama sıralı okuma ve yazmada güçlüdür; ancak uzaktaki veriyi okumak onlarca saniyeye kadar sürebildiği için yüksek trafikli işlem veritabanlarına uygun değildir
- HDD, teybe kıyasla gecikmeyi büyük ölçüde düşürdü; ancak dönen plakalar ve kafa hareketi nedeniyle rastgele okuma genellikle 1~3 ms düzeyindedir ve istek sırasına göre performans farkı büyür
- SSD, mekanik parça olmadan NAND flash ile çalıştığı için rastgele okuma 16 μs kadar hızlanabilir; ancak paralelliğin kullanımı ve garbage collection nedeniyle veri yerleşimi önemini korur
- Bulutta depolama ile compute’un ayrılması ölçeklenebilirliği ve arıza yönetimini kolaylaştırır; ancak ağ gidiş-dönüşü ve IOPS sınırları ekler. PlanetScale Metal, doğrudan bağlı NVMe SSD ve replikasyonla bu maliyeti azaltmayı hedefler
Depolama Gecikmesini Belirleyen Temel Unsurlar
- Kalıcı depolama, güç kapansa bile veriyi korur ve fotoğraflar, e-postalar, banka bakiyeleri, tıbbi kayıtlar gibi verileri saklamanın temelidir
- CPU register’ları, CPU cache’i ve RAM gibi geçici depolama daha hızlıdır; ancak sürekli güç gerektirir
- Depolama performansı yalnızca kapasite meselesi değildir; veriye nasıl ulaşıldığına, okuma-yazma birimine, kuyruklamaya, paralelliğe ve ağ gidiş-dönüşü olup olmadığına göre değişir
- PlanetScale, PlanetScale Metal lansmanıyla birlikte Metal’in ağ bağlantılı depolama yerine yerel NVMe sürücülerle bulut veritabanı çalıştırdığını açıkladı
Teyp Depolama: Sıralı Erişimde Güçlü, Rastgele Erişimde Zayıf
- Bilgisayarlar 1950’lerden beri teyp sürücülerini kalıcı dijital depolama olarak kullanıyor
- Teyp kartuşları birden fazla track ve çok sayıda hücreden oluşur; her hücrenin manyetik polarizasyon durumu ikili veriyi temsil eder
- Kartuş okuyucuya yerleştirilip motorla sarıldığında IO head üzerinden geçen veriyi okur
- Okuma-yazma konumu kafaya yakınsa hızlıdır; uzaktaysa gecikme artar
- Modern teyp sistemlerinde bile uzaktaki veriyi okumak için yüzlerce metre sarmak gerekebilir
- Bu durumda okuma onlarca saniye sürebilir
- Aynı sayıda okuma-yazma olsa bile veri dağınıksa, sıralı yerleşime göre çok daha uzun sürer
- Yazıdaki örnek, dağınık okuma-yazmaların aynı iş yükünde yaklaşık 7 kat daha uzun sürdüğü bir durumu gösterir
- Teyp, rastgele okuma-yazma gecikmesi açısından kötüdür; ancak uzun sıralı okuma-yazmalar için hâlâ uygundur
- SSD ve HDD’ye göre GB başına maliyeti daha düşüktür ve saklama ömrü uzundur
- CERN, 400 PB’den fazla veriyi teyp depolama veri ambarında yönetir
- AWS de teyp arşivleme hizmeti sunar
- Yüksek trafikli işlem veritabanları için teyp uygun değildir
HDD: Dönen Disk ve Komut Kuyruklama Arasında Bir Denge
- HDD, teyp yerine veriyi platter denen dairesel metal disklere kaydeder
- Platter, muhafaza içinde yüksek hızda döner; örnekte yaygın bir hız olarak 7200 RPM verilir
- HDD’de track’ler daireseldir ve tek bir diskte 100.000’den fazla track bulunabilir
- Her track yüz binlerce page içerir; her page yaklaşık 4 KB veri taşır
- HDD, kafa hareketi ve platter dönüşüyle okuma-yazma konumunu hizalar
- Teypten farklı olarak tüm yüzeydeki bitlere her zaman erişilebilir
- İstenen veri ortaya çıkana kadar teybi sarmak gerekmez
- Tipik bir rastgele okuma 1~3 ms içinde yapılabilir
- İstek sırası performansı büyük ölçüde etkiler
- Yüksek sıralılığa sahip okuma-yazmalar hızlı biter
- Aynı 6 okuma-yazmada bile sıra karışırsa platter’ın doğru konuma gelmesini bekleme süresi artar
- Manyetik diskler uzun süredir komut kuyruklamayı destekler
- SCSI 1980’lerden, SATA ise 2000’lerden beri ilgili özellikleri sunar
- OS, birden fazla komutu paralel veya sıradan farklı yürütülecek şekilde gönderebilir
- Disk denetleyicisi, iş kuyruğunu kullanarak okuma-yazmaları disk yapısına uygun biçimde zamanlayabilir
- HDD, teybe göre iyileşmiş olsa da özellikle rastgele okuma-yazmada hâlâ yavaş kalabildiği durumlar vardır
SSD: Mekanik Parçalar Ortadan Kalksa da Kalan Performans Değişkenleri
- SSD veya flash depolama 1980’lerde icat edildi; ancak tüketici depolamasında ana akım hâline gelmesi 2000’lerde oldu
- SSD, veriyi okumak için mekanik parçalara dayanmaz
- NAND flash adlı kalıcı transistörler kullanır
- 1 ve 0’lar, fiziksel parça hareketi olmadan elektrik sinyalleriyle okunur, yazılır ve silinir
- SSD bir veya daha fazla target’tan oluşur; her target birden fazla block içerir, block’lar da birden fazla page içerir
- SSD, page biriminde okur ve yazar
- Verinin yalnızca bir kısmı gerekse bile sürücünün istek birimi page’dir
- Örnek yapılandırmada page 4096 bit, block 16K page, target 16K block ve aygıt 8 target ise toplam
4k * 16k * 16k * 8 = 8,796,093,022,208bit, yani 8 TB olur - SSD rastgele okuması modele göre değişir; ancak 16 μs kadar hızlı olabilir
- Mekanik parça olmasa da veri yerleşimi önemlidir
- SSD performans faktörleri arasında paralellik ve garbage collection bulunur
SSD Paralelliği: Target Dağılımı Verimi Değiştirir
- Genellikle her target için kontrol ünitesine bağlanan özel bir line bulunur
- Her line okuma-yazmayı işler; ancak bir seferde yalnızca bir page aktarabilir
- Page aktarımı çok hızlıdır; yine de küçük bir süre alır
- 8 write 4 target’a dağıtılırsa 4 line paralel kullanılarak iki zaman diliminde yazılabilir
- 8 write’ın tamamı aynı target’ta toplanırsa yalnızca bir line kullanılır ve diğer line’lar boşta kalır
- Okuma-yazma sırası ve veri yerleşimi SSD’de de performansı etkiler
- MySQL gibi yazılımlar tasarlanırken verinin hangi yapıda saklandığına ve diske nasıl yerleştirildiğine dikkat edilmelidir
SSD Garbage Collection: Yazmadan Önce Silmenin Maliyeti
- SSD page’leri birçok kez okunabilir; ancak bir kez yazılmış page, mevcut veri açıkça silinmeden yeni veriyle üzerine yazılamaz
- Tek tek page’ler silinemez; block’un tamamı silinmelidir
- SSD’nin empty, in-use ve dirty page’leri yöneten dahili algoritmalara ihtiyacı vardır
- dirty page, yazılmış ancak artık verisine ihtiyaç duyulmayan ve silinmeye hazır page’dir
- Yeni write almak için verinin yeniden yerleştirilmesi gerekebilir; bunu yöneten algoritma garbage collector’dır
- Yeterli unused page varsa yeni veri doğrudan yazılabilir
- Unused page az ve dirty page çoksa önce garbage collection çalıştırılmalıdır
- Örnekte, yeni 5 page yazmak için dirty olmayan 2 page başka bir konuma taşınır
- Ardından ilgili target’taki tüm page’ler silinebilir hâle gelmeleri için dirty durumuna getirilir
- Bu ek adımlar write performansını ciddi ölçüde yavaşlatır
- Okuma, yazma ve silmenin yoğun olduğu meşgul SSD’lerde garbage collection nedeniyle diğer işler yavaşlayabilir
Bulutun Getirdiği Değişim: Storage ve Compute Ayrımı
- Teypten HDD ve SSD’ye geçiş, dayanıklı IO performansını büyük ölçüde artırdı
- Buluta geçiş, IO performansında başka bir değişim yarattı
- AWS, 2006’daki çıkışından sonra buluta geçişi büyük ölçüde yaygınlaştıran hizmet olarak sunulur
- Bulut ortamında kullanıcılar, büyük veri merkezlerindeki herhangi bir donanım üzerinde sanallaştırılmış sunucular kiralar
- Sunucular donanım arızası, değişim, ağ kesintisi gibi çeşitli nedenlerle herhangi bir anda kapanabilir
- Kiralık bulut altyapısı üzerinde sistem kurarken daha sık arızalara dayanabilmek gerekir
- Bu koşullar ve dinamik olarak ölçeklenebilir depolama volume’larına duyulan ihtiyaç, storage ile compute’un ayrılmasına yol açtı
Ağ Bağlantılı Depolamanın Avantajları ve Maliyeti
- Geleneksel olarak sunucular, masaüstleri, dizüstü bilgisayarlar ve telefonlar kalıcı depolamayı doğrudan bağlar
- SATA kablosu, PCIe arayüzü veya aynı SoC içine gömülü biçim kullanılır
- Doğrudan bağlı depolama hızlıdır; ancak iki kısıtı vardır
- Sunucu kapanırsa veri de birlikte kullanılamaz hâle gelir
- Depolama boyutu sabittir
- Uygulama sunucuları genellikle geçici (ephemeral) ortamlara iyi uyum sağlar ve birçok iş bellekte gerçekleştiği için bu sorun büyük değildir
- Veritabanları ise sunucu kapansa da veri kaybetmemeli; veri boyutu hızla büyüyerek depolama sınırına ulaşabilir
- Birçok bulut sağlayıcısı, compute instance’larına ayrı yapılandırılabilen ağ bağlantılı depolama eklenmesini sağlar
- EC2’nin temel yapılandırması genellikle EBS ağ depolama volume’u bağlama biçimindedir
- Amazon RDS, Amazon Aurora, Google Cloud SQL, PlanetScale gibi veritabanı hizmetleri de compute ve storage’ın ağ üzerinden ayrıldığı sistemlere dayanır
- Bu yaklaşım, depolama volume’unun veri artışı ve azalışına göre dinamik biçimde ayarlanmasını sağlar
- Sunucu kapansa bile veri güvenle kalır ve başka bir sunucuya yeniden bağlanabilir
- Buna karşılık ağ gidiş-dönüşü ve IOPS sınırı gibi performans maliyetleri oluşur
Yerel NVMe ile Ağ Depolaması Arasındaki Gecikme Farkı
- Doğrudan bağlı NVMe SSD, kalıcı bellek host denetleyici arayüzü spesifikasyonunu kullanarak hızlı IO hızı ve bant genişliği sunan SSD’dir
- CPU’dan RAM’e gidiş-dönüş yaklaşık 100 ns olarak verilir
- CPU’dan yerel bağlı NVMe SSD’ye gidiş-dönüş yaklaşık 50.000 ns, yani 50 μs’dir
- Ağ bağlantılı depolama volume’u, veri merkezi içinde kısa bir ağ gidiş-dönüşü gerektirir
- EBS gibi ağ bağlantılı depolamada gidiş-dönüş süresi yaklaşık 250.000 ns, yani 250 μs veya 0,25 ms olarak verilir
- Aynı modern SSD kullanılsa bile ağ bağlantısı, tekil okuma-yazma isteklerinin işlem süresini tek haneli katlar ölçeğinde uzatır
- Büyük sıralı IO’da olumsuz etki azaltılabilir; ancak tamamen ortadan kaldırılamaz
- Ağ bağlantılı depolama, depolama sistemine her erişimde ek gecikme yaratır
IOPS Sınırı ve Doğrudan Bağlı Depolama Arasındaki Fark
- AWS ve Google Cloud dâhil birçok bulut sağlayıcısı, ağ bağlantılı depolama modelinde wire üzerinden gönderilebilecek IO işlem sayısını sınırlar
- Amazon’un GP3 EBS instance’ı varsayılan olarak saniyede 3000 IOPS sağlar
- Daha yüksek ayarlanabilir; ancak ek maliyet doğurur
- Önceki GP2 EBS volume’ları, zaman zaman burst’e izin vermek için IOPS pool’u biriktiren bir yapıda çalışır
- Depolama compute instance’ına doğrudan bağlandığında yapay bir IO işlem sınırı yoktur
- Doğrudan bağlantıda donanımın izin verdiği kadar okunup yazılabilir
Dayanıklılık ve Ölçeklenebilirliği Koruma Yöntemi
- Doğrudan bağlı SSD’de birinci sorun olan veri dayanıklılığı replikasyonla çözülebilir
- Yaygın yöntem, bir sunucuyu primary yapıp tüm write isteklerini onun alması ve 2 veya daha fazla ek sunucunun veriyi replike etmesidir
- Veri üç yerde bulunursa veri kaybı olasılığı azalır
- Örnek sayılarla aylık sunucu arıza olasılığının %1 olduğu varsayılırsa:
- Tek sunucuda her ay veri kaybı olasılığı %1’dir
- Üç sunucuda bu olasılık
1% × 1% × 1% = 0.0001%, yani milyonda 1’e düşer
- PlanetScale, başarısız node’ları otomatik algılayıp değiştirir ve veritabanı verilerini sık ve güvenilir biçimde yedekler
- İkinci sorun olan sürücü ölçeklenebilirliği daha fazla manuel müdahale gerektirir
- Disk kapasite sınırına yaklaşırken izleme ve uyarılar gerekir
- Gerektiğinde kapasiteyi kolayca artıracak araçlara ihtiyaç vardır
PlanetScale Metal’in Yaklaşımı
- Metal, doğrudan bağlı NVMe SSD kullanan veritabanı kümeleri sunar
- Her veritabanı instance’ı direct-attached NVMe SSD üzerinde çalışır
- Metal kümesi varsayılan olarak 1 primary ve 2 replica’dan oluşur
- Desteklenen veritabanı kümeleri Vitess veya Postgres’tir
- Depolama sınırına ulaşıldığında birkaç tıklamayla daha büyük sürücülü bir sunucuya yeniden boyutlandırılabilir
- İçeride yeni node başlatılır, veriler mevcut instance’tan yeni instance’a taşınır ve bu süreç zero downtime ile yürütülür
- Metal veritabanlarında yapay bir IOPS cap yoktur
- Kullanıcılar düşük gecikmeyle IO işlemleri yapabilir ve bulut sağlayıcısının pahalı IOPS sınıfı maliyetleri ya da throttle olmadan donanımın izin verdiği kadarını kullanabilir
1 yorum
Hacker News yorumları
Blogun yazarı benim. Bu yazıyı hazırlamak gerçekten çok keyifliydi ve şimdiye kadar yaptıklarım arasında açık ara en karmaşığıydı
İnteraktif görselleştirmeyi oluşturmak için kelimenin tam anlamıyla binlerce satır JavaScript yazdım; umarım herkes keyifle inceler
Yine de dayanıklılık için verilen “milyonda bir” ifadesi, yeni sunucu gelip yeniden çoğaltma tamamlanana kadarki arıza süresinin kısa olduğu düşünülürse fazla karamsar görünüyor
Örneğin toparlanma 10 dakika sürüyorsa, üç sunucu ayda bir kez mutlaka arızalansa bile bunların çakışıp hepsinin birden çökme olasılığı zaten yaklaşık iki milyonda bir gibi olur; aylık arıza olasılığı %1 ise üç arızanın üst üste gelmesi son derece düşük kalır
Bir milyon müşteriniz varsa milyonda bir aslında o kadar da iyi bir sayı değildir; o yüzden eklemek istedim
Klavyede geçirilen zamanla kafada düşünülen zamanın epey farklı olduğunun farkındayım
Bu konuya oldukça aşinayım, o yüzden içeriğin kendisine ekleyecek bir şeyim yok; hızlıca bakınca da gayet iyi görünüyor. Ama kendi blogum için animasyonlar tasarlıyorum ve son dönemde denediğim birkaç kütüphane pek hoşuma gitmedi
Bir süredir SQLite+NVMe yaklaşımını savunuyordum. Bana göre bu, normalde olduğundan çok daha ileri gitmeyi sağlayan yeni bir desen ve bazı durumlarda yatay ölçekleme olmadan da sonuna kadar dayanabiliyor
Performansta kral gecikmedir; özellikle de öğeleri seri işlemek zorundaysanız. SQLite’ı NVMe üzerinde çalıştırınca, başka sağlayıcıların veremeyeceği bir gecikme avantajı elde ediyorsunuz
Çoğu gerçekçi kullanım senaryosunda, bellekte çalışmanın da NVMe üzerinde kalıcı depolamadan çok daha iyi olduğunu düşünmüyorum
Tek bir host üzerinde biraz daha hızlı olabilir, ama web sunucusu 1’den 2’ye çıktığı ve ikisinin de veritabanına yazması gerektiği anda işi kendin için zorlaştırıyor gibisin
Gecikmenin önemli olduğu söylemi de biraz yanıltıcı. Tutarlılık yoksa performansın anlamı kalmaz; web sunucusu sayısı birkaç taneye çıkınca bu tutarlılığı kendin çözmek zorunda kalırsın
Ayrıca veritabanı gecikmesi genelde internet gidiş-dönüş gecikmesinden çok daha küçüktür; internet gecikmesi de görseller veya kod kütüphaneleri gibi sayfa varlıklarının yüklenmesini beklerken yaşanan “gecikmenin” yanında küçüktür
Zaten seri veritabanı sorgularından mümkün olduğunca kaçınmak gerekir; mümkünse join kullanılmalı, olmuyorsa da olabildiğince asenkron şekilde aynı anda sorgu gönderilip paralel çalıştırılmalıdır
Paralel yazma sorununu önlemek için, belli bir hantal çalışma modu ayarlamanın dışında, uygulama tarafında yalnızca yazmaya ayrılmış tek bir iş parçacığı kullanma hilesi uygulanabilir
Bu da zaten karmaşık olan paralel kodu genelde biraz daha karmaşık hale getiriyor. Ama tek bir yazma iş parçacığı olduğunda SQLite gerçekten çok iyi çalışıyor
fsync()denerseniz, NVMe disk üzerinde bile hâlâ 1~2 ms gecikme ölçülebiliyorDaha yeni sistemlerde ise yaklaşık 800µs civarındaydı
Bilgi yoğunluğu o kadar iyiydi ki bunun bir ürün tanıtımı olduğunu tamamen unutarak okudum. Görselleştirmeler ve etkileşimler çok başarılı
Disk G/Ç animasyonunu görünce Melvin Kaye aklıma geldi
Mel, yavaş Flexowriter’ın karakterler arasında gecikmeye ihtiyaç duyduğu durumlarda bile zaman gecikme döngüsü kullanmazdı
Bunun yerine drum üzerindeki komutların konumunu ayarlardı; böylece bir sonraki komuta ihtiyaç duyulduğunda okuma kafası onu yeni geçmiş olurdu ve drum bir sonraki komutu bulmak için bir tur daha dönmek zorunda kalırdı
https://pages.cs.wisc.edu/~markhill/cs354/Fall2008/notes/The...
Metal gerçekten çok etkileyici görünüyor ama önceki iş yerimde GCP’nin instance-local SSD özelliğini kullandığımızda, aygıt bloklarının veri kaybetmesi gibi ciddi güvenilirlik sorunları yaşamıştık
Acaba şimdi durum değişti mi, hangi makine tipini kullandığınızı merak ediyorum
O zaman kullandığımız geçici çözüm şuydu: https://discord.com/blog/how-discord-supercharges-network-di...
Ama biz, tüm yazıların istemciye onay verilmeden önce farklı erişilebilirlik bölgelerindeki iki makinede kalıcı hâle gelmesini sağlayan MySQL yarı senkron replikasyonu ile yedekli bir sistem işletiyoruz
Kubernetes operatörü ile Vitess’in
vtorcsüreci birlikte çalışarak arızalı ya da şüpheli replikaları agresif biçimde tespit edip değiştiriyorGCP’de en iyi sonuçları n2d-highmem makinelerde gördük; AWS’de ise örnek depolaması bulunan yeni nesil tipleri neredeyse genel olarak kullanıyoruz
Güzel yazı. Genel olarak bulutta depolamanın alışılmadık derecede yavaş olması gibi bir sorun da var.
Başka yerlerde de zaten ele alındı ama bu yazı sorunu iyi özetliyor: http://databasearchitects.blogspot.com/2024/02/ssds-have-bec...
Kısa süre önce https://github.com/feldera/feldera içinde artımlı indeksleri S3/nesne depolamada saklama desteği eklendi; NVMe ise önceki yazıda bahsedilen bariz performans avantajları nedeniyle çok daha önceden destekleniyordu.
Keşke biri daha iyi bir sunum modeliyle bu alanı sarsıp değiştirse.
Bu yazıda dağıtık depolama hakkında yeterince takdir edilmeyen bir nokta var.
Birincisi, bazı sistemler yerleşik çoğaltma sunmuyor. Cassandra kümesi ya da MySQL master-slave replikasyonu yapabilir ama birçok sistem bunu yapamaz.
İkincisi, bulutta NVMe depolama kullanırsanız bakım pencereleri ve bulutun başlattığı drain işlemleriyle ilgilenmeniz gerekir; bu da işletimi çok daha zor hale getirir.
Veriyi bu sistemlere bağlayıp başka düğümlere taşımazsanız veri kaybolur.
Depolama ile hesaplamayı ayırırsanız bulut operatörü gerektiğinde hesaplama kaynaklarını boşaltıp taşıyabilir; veri hesaplamadan bağımsız kalır ve bulut operatörü bu veri sistemini ve drain süreçlerini yönettiği için müşterinin müdahalesi olmadan iş yükü yerleşimini ayarlayabilir.
“Yerel” dosya sistemi API’si gibi görünen, replike edilmiş ağa bağlı depolama; bizimki gibi yerleşik replikasyonu olmayan sistemlere dayanıklılık kazandırmanın güçlü bir yolu.
Gerçekten harika ve PlanetScale Metal de oldukça sağlam görünüyor. Özellikle sürümle birlikte gecikmenin ciddi biçimde düştüğünü görmeyi seviyorum: https://planetscale.com/blog/upgrading-query-insights-to-met...
Yıllardır, replike veritabanlarının neden hep EBS’ye tutunup o gecikmeyi kabullendiğini anlayamıyordum. Zaten replikasyon varsa neden cesurca yerel disk kullanılmıyor diye sorguluyordum.
Önceki bir organizasyonda Elasticsearch’ü geçici log/metrik deposu olarak çalıştırırken, güvenilirlik gereksinimi de yüksek olmadığından bunu yapmayı önermiştim ama kimseyi ikna edemedim; sonunda daha kötü olan AWS Elasticsearch’ü kullanmak zorunda kaldık.
Yerel disk kapasitesinin sınırlı olduğunu biliyorum ama çekirdek/bellek/disk oranı çoğu kullanım senaryosu için yeterli olmaz mı diye düşünüyorum. Farklı oranlara sahip pek çok yerel diskli instance da var; uygun bir denge bulunabilir.
20 TB üzeri yerel HDD instance’larıyla hot/cold depolama bile kurulabilir.
PlanetScale ekibini, sonunda mantıklı olanı yaptıkları için gerçekten takdir etmek istiyorum. AWS’nin bile Elasticsearch’ü yerel disk üzerinde çalıştırmaması tuhaf; ClickHouse ya da Cassandra gibi şeylerin hepsini yerel disk üzerinde çalıştırdığınızı düşünün yeter.
Asıl sorun, stop-start olayından sonra diskin silinmesiydi. Kümenin geri kalanı sağlam olsa ve kullanılabilir replikalar bulunsa bile SQL Server bunu otomatik olarak ele alamıyor.
Sıfırlanmış düğümleri otomatik toparlamadığı için, bunu aşmak için gereken betikleme ve test düzeyi en cesur ve yetkin organizasyonlar dışında çoğu yer için prodüksiyonda taşınamayacak kadar ağır.
Biz bu modelle yüzlerce ClickHouse kümesi işletiyoruz. Boyut değiştirme, arıza çözmekten çok performans sorunlarını gidermek için yapılıyor.
Örneğin ABD saatine göre pazar sabahı bir tenant performans sorunu yaşarsa, en basit çözüm hafta sonu boyunca daha büyük bir VM’e çıkmak ve pazartesi sabahı çekirdek ekibin kök nedeni incelemesine bırakmak olur.
Ek maliyet küçüktür ve çok daha pahalı olan çalışan tükenmişliğini önler.
Gerçekten çok iyi bir yazı ve rastgele yazma görselleştirmesi çok iyi hazırlanmış.
Ağa bağlı depolamadaki IOPS sınırları hakkında belki biraz aptalca birkaç sorum var.
Birincisi, “IOPS” sınırının belirli bir tür ağ trafiğine, yani EBS volume’üne gidip gelen trafiğe uygulanan bir hız sınırı olup olmadığını merak ediyorum. Sonuçta “IOPS” ile aslında “EBS volume ağ trafiği” mi kastediliyor diye soruyorum.
İkincisi, bunun maliyet tasarrufu sağlayıp sağlamadığını merak ediyorum. Sağlıyorsa bunun garip AWS fiyat arbitrajından mı, yoksa daha az EBS ağ trafiği kullanmaktan doğan verimlilikten mi kaynaklandığını merak ediyorum.
Depolama ile hesaplamayı aynı makinede bulundurmanın gecikme açısından yapısal olarak bir hop azaltma avantajı olduğu açık görünüyor, ama dolar başına throughput açısından da avantaj sağlayıp sağlamadığını bilmek isterim.
Ben bunu farklı bir model olarak görüyorum. EBS volume, PCIe veri yoluna bağlı fiziksel bir kartın parçası değil; pek çok fiziksel sürücüden oluşan büyük bir dağıtık sistemdeki bir pay, yani hesaplama ile arasında özel ağ kapasitesi bulunan bir SAN’e daha çok benziyor.
Maliyet tasarrufu olabilir ama sonuçta bu, bir dizi ödünleşimden ibaret.