Sürekli yeniden icat: AWS blok depolamanın kısa tarihi

 (allthingsdistributed.com)
2 puan yazan GN⁺ 2024-08-23 | 1 yorum | WhatsApp'ta paylaş

Sürekli yeniden icat: AWS blok depolamanın kısa tarihi

  • Giriş

    • Marc Olson, Elastic Block Store (EBS) ekibinde 10 yıldan uzun süredir çalışıyor.
    • EBS, basit bir blok depolama hizmetinden günde 140 trilyondan fazla işlemi yöneten büyük ölçekli bir ağ depolama sistemine dönüştü.
    • Bu yazı, EBS'nin evrim sürecini ve önemli dersleri paylaşıyor.

  • EBS'nin erken dönemi

    • EBS, 20 Ağustos 2008'de kullanıma sunuldu ve EC2 instance'ları için ağa bağlı blok depolama sağlayan basit bir fikirle başladı.
    • İlk dönemde paylaşımlı sabit disk sürücüleri (HDD) kullanıyordu; bugün ise tek bir EC2 instance'ına yüz binlerce IOPS sağlayabiliyor.
    • EBS bugün, dağıtık bir SSD filosu üzerinden günde 140 trilyondan fazla işlemi işliyor.

  • Kuyruk teorisi

    • Bilgisayar sistemlerinin depolamayla etkileşime girme biçimi temelde değişmedi.
    • CPU istekleri bir kuyruğa koyuyor, depolama aygıtı ise veriyi CPU belleğinden alıp dayanıklı bir ortama yazıyor ya da ters yönde veriyi CPU belleğine aktarıyor.
    • Kuyruk teorisi, bu süreci anlamada önemli bir rol oynuyor.

  • HDD'den SSD'ye geçiş

    • İlk EBS, HDD kullanıyordu ve bu da fiziksel sınıırlar nedeniyle performansı kısıtlıyordu.
    • SSD'lerin ortaya çıkmasıyla rastgele istekler de neredeyse sıralı istekler kadar hızlı işlenebilir hale geldi.
    • 2012'de SSD kullanan yeni bir depolama sunucusu tipi ve Provisioned IOPS adlı yeni bir EBS volume tipi sunuldu.

  • Ölçüm ve yönetim

    • 2012'de EBS yalnızca temel telemetriye sahipti.
    • Sistem performansını iyileştirmek için neyin sorun çıkardığını bulmak ve bunları öncelik sırasına göre çözmek gerekiyordu.
    • Çeşitli alt sistemlerde IO'yu ölçme yöntemleri kuruldu ve sürekli izleme ile değişiklikler tespit edildi.

  • Organizasyonu böl ve fethet

    • EBS depolama sunucusu ekibi, veri çoğaltma, dayanıklılık, snapshot hydration gibi belirli alanlara odaklanan küçük ekiplere dönüştürüldü.
    • Her ekip değişiklikleri bağımsız biçimde yineleyip commit edebiliyordu.

  • Varsayımlara meydan okumak

    • Xen hypervisor'ünün varsayılan ayarlarının performansı sınırladığı keşfedildi.
    • Ağ ve depolama işleme görevleri, Nitro offload kartı kullanılarak donanıma offload edildi.

  • Ağ ayarlama deneyleri

    • EBS Nitro'ya taşınırken ağın kendi overhead'i arttı.
    • Ağ performansını iyileştirmek için TCP yerine SRD (Scalable Relatable Diagram) protokolü geliştirildi.

  • Kısıtlar inovasyonu teşvik eder

    • SSD'nin avantajlarını tüm müşterilere sunmak için mevcut donanım değiştirilmeden sisteme SSD eklendi.
    • SSD'ler sunuculara elle eklendi, yeni yazmalar önce SSD'ye kaydedildi ve ardından asenkron olarak HDD'ye flush edildi.

  • Performans ölçeklendirmenin ardından düşünceler

    • Kişisel gelişim hikâyesi: küçük şirket kültüründen büyük ölçekli bir organizasyona geçiş.
    • Eşli debugging oturumlarıyla sorunlar çözüldü ve ekibin verimliliği artırıldı.

  • Sonuç

    • EBS, tek ve büyük bir değişimle değil, bir dizi kademeli iyileştirmeyle gelişti.
    • Müşteri talepleri artmaya devam edecek; bu da inovasyon ve yinelemeyi sürdürmek için motivasyon sağlıyor.

# GN⁺ Özeti

  • Bu yazı, AWS'nin EBS'sinin nasıl evrildiğine dair içeriden bir bakış sunuyor.
  • Kuyruk teorisi, SSD'nin devreye alınması, ağ ayarlamaları gibi çeşitli teknik zorlukları ve çözümleri ele alıyor.
  • Performans iyileştirmesi için sürekli ölçüm ve yönetimin önemini vurguluyor.
  • Benzer işlevlere sahip ürünler arasında Google Cloud Persistent Disk ve Microsoft Azure Disk Storage bulunuyor.

İlgili okumalar

1 yorum

 
GN⁺ 2024-08-23
Hacker News yorumu

  • Büyük sistemlerle ilgileniyorsanız, bu yazıyı okumakta fayda var

    • Sabit disk performansı, kuyruktaki diğer işlemlere bağlı olarak değişir
    • Rastgele 4kB işlemlerde performans ciddi biçimde düşebilir
    • Kuyruklama ve zamanlama yardımcı olur, ancak gerçek performans iş yüküne göre 100 kattan fazla farklılık gösterebilir
    • Çok kiracılı sistemlerde, özellikle okuma işlemlerinde zorluklar vardır

  • Sorunu çözmek için neyin yanlış gittiğini bilmek gerekir

    • Marc'tan öğrendiğim en büyük ders, görselleştirme yoluyla ekibin bakış açısını değiştirmekti
    • Performans verilerini farklı şekillerde analiz etmek, görünmeyen verimlilikleri ve fırsatları ortaya çıkarabilir

  • 2013'te EBS sunucularına SSD takılan proje, AWS'nin ilginç hikayelerinden biridir

    • Sistem en baştan, yıkıcı olmayan bakım olayları dikkate alınarak tasarlanmıştı
    • Dağıtık sistem kurduğunuzda büyük ölçekte operasyon yürütmek mümkün hale gelir

  • AWS'nin yaklaşık 4 gün süren kesintisi EBS nedeniyle yaşandı ve bu durum AWS'ye duyulan güveni sarstı

    • Bunun sonucunda EBS'e yapılan yatırım arttı
    • Apple'ın müşteri olduğu dönemle de örtüşüyordu

  • Reddit, 2008'de EBS'in ilk kullanıcılarından biriydi

    • IOPS'yi artırmak için yazılımsal RAID kullanmaya çalıştılar, ancak performans tutarlı değildi
    • RAID'in sorunlarını çözmek zaman aldı
    • Netflix, EBS kullanmadı

  • Rastgele gecikme eklemek, ortalama gecikmeyi ve uç değerleri azaltma etkisi yaratır

  • Büyük ölçekli internet şirketlerinde çalışırken çok şey öğrenildi

    • Çıraklık süreci sayesinde önemli bilgi ve beceriler hızla edinilebilir
    • Mülakatlarda deneyim ve mentor tavsiyesi çok faydalıdır

  • 2013'te tüm EBS birimlerine SSD'lerin elle takılması kısmı ilginçti

    • 2010-2012 arasında I/O performansı önemli bir konuydu

  • 2009'da Amazon S3'ün iç yapısı hakkında bir konuşma yapıldı

    • Bu konuşma EBS geliştirmesini etkiledi

  • Bulutun ilk dönemlerinde genel amaçlı donanım kullanılıyordu, ancak artık tek tek hizmetlere özel donanımlar kullanılıyor

    • AWS, Graviton, Inferentia, Tranium çiplerini kullanıyor
    • Google, TPU ve Titan güvenlik kartlarını kullanıyor
    • Azure, FPGA ve Sphere kullanıyor

  • İlk diyagram yanlış ya da güncelliğini yitirmiş

    • Modern bilgisayarlarda PCIe hatlarının çoğu doğrudan CPU'ya bağlanır
    • Bu, I/O aktarım hızı ve gecikme açısından önemli bir gelişmedir

  • Yeni bir EC2 instance'ına hızlı bir 256GB veri kümesi dizini sağlamanın en iyi yolunu arıyorum

    • EBS volume'leri kullanıyorum ama güncellemeler zahmetli
    • EFS çok yavaş
    • Instance storage SSD'leri geçici
    • FSx Lustre'ı henüz denemedim