AWS veri merkezleri gecikme süresi görselleştirmesi

 (benjdd.com)
3 puan yazan GN⁺ 2024-10-25 | 2 yorum | WhatsApp'ta paylaş
  • AWS veri merkezleri arasındaki gecikme süresini 3 ms aralığına ayırarak gösteren bir görselleştirme sayfası
  • Lejant, gecikme düzeylerini hızlıca karşılaştırmak için 100 ms altı, 100~200 ms ve 200 ms üstü olarak ayrılmış
  • Sunulan bilgilerle hangi veri merkezlerinin veya bölgelerin dahil olduğu doğrulanamıyor
  • Ölçüm yöntemi, ölçüm zamanı ve veri merkezleri arasındaki tekil gecikme süresi değerleri sağlanmıyor
  • Bu nedenle bu özette doğrulanabilen kapsam, görselleştirmenin aralık ölçütleriyle sınırlı

Gecikme süresi lejantı

  • X < 100ms: 100 ms altı
  • X 100ms - 200ms: 100 ms~200 ms
  • X > 200ms: 200 ms üstü

Doğrulanamayan ayrıntılar

  • Belirli AWS veri merkezi listesi veya bölge adları sağlanmıyor
  • Ölçüm yöntemi, ölçüm zamanı ve tekil veri merkezleri arasındaki gecikme süresi değerleri doğrulanamıyor

İlgili okumalar

2 yorum

 
devenv 2024-10-25

Görünüşe göre us-east-1, Batı dünyasına yönelik olarak en iyi konumda.
 
GN⁺ 2024-10-25
Hacker News yorumları

  • Yalnızca ping değerini göstermek yerine, teorik optimuma kıyasla ne kadar kötü olduğunu da gösterse iyi olurdu.
    Fiber optik ortamda ışık hızının, vakumdaki ışık hızından yaklaşık %30 daha yavaş olduğunu biliyorum.
    Veri merkezleri arasındaki gecikme süresi yüzünden mimari toplantılarında şikâyet edildiği, ama sonradan bunun zaten teorik olarak mümkün olan değere epey yakın olduğunun anlaşıldığı birkaç durum yaşadım.

    • Hiper ölçekleyiciler ve büyük colocation/barındırma sağlayıcıları içinde bu tür metriklerin zaten iyi bilindiğini tahmin ediyorum.
      Müşteriler yüksek erişilebilirlik veya felaket kurtarma sistemleri tasarlarken, birincil bölge ile “yapay olarak” yüksek gecikme süreli bir region ya da zone’u yanlışlıkla seçmemelerini sağlamak önemli.
      Şu anki şirketim SAP’nin buluta taşınması konusunda uzman; geçmişte yanlış varsayımlar yüzünden kabul edilemez gecikme sürelerine yakalandıktan sonra, artık teklif ve kapsam belirleme aşamasında AWS ve GCP ağ uzmanlarıyla bu konuşmayı mutlaka yapıyoruz.
    • Bu gerçek bir ping gibi görünmüyor; bence bu daha iyi.
      ICMP ping değil, tcp/443 üzerinden socket stream bağlantısı kurma yöntemi.
      Ping bir metrik olarak uygunsuz olabilir.
      https://github.com/mda590/cloudping.co/blob/8918ee8d7e632765...
    • Bunu yapmak için kablo güzergâhlarının tamamını haritalamak gerekir.
      Fiber optik kablodaki ışık kabaca ışık hızının %70’iyle, yaklaşık 210.000 km/s hızla ilerler.
      Dünya’nın çevresi yaklaşık 40.000 km’dir; Dünya’nın öbür ucuna düz bir hatla gidiş tek yön yaklaşık 100 ms, gidiş-dönüş yaklaşık 200 ms olur.
    • Haritaya tıklayınca da mesafeye göre gecikme süresinin çok saptığı örnekler pek görünmüyor.
      Elbette içi boş çekirdekli fiber ve düze yakın fiber güzergâhları kullanılsa teorik olarak yaklaşık %40 daha iyileşme sağlanabilir, ama bunun maliyetini ödemek isteyen yer sayısı azdır.
    • Yazarıyım. İlginç; X’te de aynı fikir önerildi.
      Bu değeri doğru hesaplamak için iyi bir kaynak olup olmadığını merak ediyorum.

  • Kırmızı-yeşil renk körüyüm; 100 ms altı çizgilerle 200 ms üstü çizgileri ayırt etmek zor ya da imkânsız.
    Erkek nüfusun yaklaşık %8’ine denk geldiği için bir renk körü modu eklense iyi olur.
    Görselleştirmenin kendisi çok iyi.

    • Hızlı bir geçici çözüm olarak tüm sayfaya CSS filtresi uygulanabilir.
      Geliştirici araçlarında body öğesine filter: hue-rotate(60deg); kuralını ekleyebilir veya adres çubuğunda javascript:void(document.body.style.filter='hue-rotate(60deg)') çalıştırabilirsiniz.
    • Yazarıyım. Öneri için teşekkürler.
      Geçmişte bu sorunu iyi çözen yöntemlerden en iyi örneği bilen varsa, linkiyle paylaşırsa sevinirim.
    • Çizgileri hiç göremiyorum; yalnızca veri merkezlerini tekrar tekrar gösteren mavi noktaları görüyorum.
      Epey kafa karıştırıcı.
    • Bu tür kullanım için bir erişilebilirlik aracı olup olmadığını merak ediyorum.
      Tüm ekranın renklerini belirli bir şekilde değiştirip ayırt edilebilir hâle getiren bir filtre gibi.
    • Renk körü biri olarak, renk seçerken renk körlüğünü dikkate almak önemli; ama iki rengi gerçekten ayırt edemeyen erkeklerin oranı %8’in tamamı değil.
      Bu oran daha düşük ve renk körü kişiler arasında da renk algısı farklılık gösterir.
      Birine iyi görünmesi, başkasına da iyi görüneceği anlamına gelmez; tersi de aynı şekilde.

  • Bir zamanlar bir müşteri için bununla ilgili bir plan yapmıştım.
    AWS gecikme sürelerini ölçerken, yaklaşık denizaltı kablosu uzunluğunu km cinsinden ölçüp 150’ye böldüğümüzde gerçek gecikme süresiyle %10 içinde uyuşuyordu.
    Şaşırtıcı değildi ama çok tutarlıydı; sonradan sanırım 155 olduğunu gördüm.

    • Bu bana 500 mil e-posta hikâyesini hatırlattı.
      https://www.ibiblio.org/harris/500milemail.html
    • Bunun ortam içindeki ışık hızından kaynaklandığını düşünüyorum.
      “LabVIEW aracılığıyla fiber optikteki ışık hızı yaklaşık 2.054 x 10^8 m/s olarak hesaplandı; bu da kırılma indisi n ≈ 1.4606’ya karşılık gelen tipik bir değer”
      https://web.phys.ksu.edu/posters/2009/juma-Adv-Lab-S09.pdf
    • Gerçek dünya modellemelerinde, yalnızca çarpma ve toplama ile tatmin edici hassasiyet elde edilebilen durumlar şaşırtıcı derecede çoktur.
    • Bu sayfa interaktif harita olarak gerçekten iyi yapılmış; çok keyifle inceledim.
      Bu pratik kuralın matematiksel açıklaması kabaca şöyle mi, merak ediyorum.
      https://news.ycombinator.com/user?id=Hikikomori, fiber optik ortamındaki ışık hızını 3e5 değil 2e5 olarak düzeltti.
      Işık hızı 2e5 km/s, yani yaklaşık 2e2 km/ms; bu da uzunluk(km) / 200(km/ms) biçimine geliyor ve sonuçta gecikme süresi(ms) ≈ K' × uzunluk(km) oluyor.
      Burada K yaklaşık 1,3; K' ise 1/155 ve doğrusal olmayan mesafe, ağ ek yükü ve switching, gidiş-dönüş ölçüm hatası gibi etkenleri kapsıyor sayılır mı, merak ediyorum.
    • Görselleştirmeye bakınca kırmızı çizgilerin çoğu, hatta belki tamamı, Kuzey Amerika’dan Güney Afrika’ya gidenler gibi uzun rotalara karşılık geliyor.

  • İlginç. Veri merkezlerini temsil eden mavi dairelere tıklayınca diğer veri merkezlerine olan gecikme süresi gösteriliyor.
    Bunu anlamam biraz zaman aldı; siteye seçmek için bir veri merkezine tıklayın gibi bir yönlendirme eklenirse iyi olur.

    • Bunlar kesin konuşmak gerekirse veri merkezi değil, region düzeyinde agregasyonlar.
      Veri merkezi, edge kurulum noktaları vb. gibi farklı soyutlama düzeylerindeki ağ ve bilişim bileşenleri bir araya gelerek region’ı oluşturuyor.
      Region içinde bile zone’lara göre değişkenlik büyük olduğundan ölçüm metodolojisi önemli.

  • AWS, Network Manager’da bölgeler arası, kullanılabilirlik alanları arası ve kullanılabilirlik alanı içindeki gecikme değerlerini sağlıyor
    Gecikme için bir referans çizgisi oluşturup AWS tarafında bir sorun olup olmadığını görmekte faydalı
    https://docs.aws.amazon.com/network-manager/latest/infrastru...

    • AWS, bölge veya servis kesintilerini gösteren bir pano da sunuyor; ancak geçmişe bakınca, tam da aynı nedenle böyle bir panoya olduğu gibi güvenmenin zor olduğu anlaşılıyor

  • Görselleştirme ve konsept harika, ama renklerin aralıklı değil de kesintisiz bir gradyan olması iyi olurdu
    Mevcut yöntem 100 ms’yi 99 ms’den çok daha kötü gösterirken 200 ms ile aynıymış gibi gösteriyor
    Örneğin us-east-1’e tıklayınca Batı Avrupa veri merkezlerinin gecikmeleri oldukça farklı görünüyor; oysa eu-central-1 ile eu-south-1 arasında yalnızca yaklaşık 9 ms fark var ama tamamen farklı görünüyorlar, eu-north-1 ile ap-south-1 arasında ise yaklaşık 88 ms fark var ama aynı görünüyorlar
    Işık hızına göre mümkün olan en düşük gecikme ile ölçülen değerleri karşılaştıralım diyenler de var; sorun şu ki vakumdaki ışık hızı c, fiber optik içindeki bilgi aktarım hızı değil
    Gerçek teorik en iyi değer, yalnızca ortam içindeki ışık hızına bakıldığında bile c’nin %70’ini aşmakta zorlanır; röle gecikmesi gibi bilinmeyen birçok unsur da var

    • Yazarıyım. Gradyan gerçekten iyi bir fikir
      Mevcut görselleştirme 90 ms gecikmeyi “iyi” gibi gösteriyor ama gerçekte bu birçok uygulama için tamamen kabul edilemez bir değer
      Özellikle tek bir isteği işlemek için birden fazla gidiş-dönüş gerektiğinde daha da öyle

  • Hangi veri merkezlerinin dahil edileceğini nasıl seçtiklerini merak ediyorum
    Örneğin eu-south-2 olan İspanya eksik
    Geçmişte veri merkezleri arası gecikmenin 30 ms’nin altında olması gereken bir projede çalışmıştım ve eu-west-1 İrlanda ile eu-south-2’yi kullanmam gerekiyordu
    Ancak gerçek gecikme 42 ms’ye yakındı; bunun başlıca nedeni İrlanda ile Avrupa kıtası arasında denizaltı kablosu olmaması, bu yüzden trafiğin Birleşik Krallık’a gidip ardından tekrar Birleşik Krallık’ı geçerek kıta tarafındaki kabloya yönlendirilmesi gerekmesiydi

    • Sayfanın altında CloudPing’den kazınmış veriler yazıyor ve CloudPing veri kümesine bağlantı da var
      CloudPing’e girince veri kümesinde eu-south-2 olmadığı görülüyor
    • Yazarıyım. Yalnızca https://www.cloudping.co üzerinde kullanılabilenleri kullandım; gerçekten de bazı yerler eksik
      CloudPing GitHub deposunda 4 yıldır kod değişikliği yok, dolayısıyla son aktif çalışmadan sonra birkaç yeni bölge açılmış olabilir
    • İrlanda ile Avrupa anakarası arasında kablo olmadığını nasıl öğrendiğini merak ediyorum
      Bunun nerede herkese açık olduğunu gerçekten bilmek istiyorum
    • O haritada eksik olan epey veri merkezi var
    • İsrail il-central-1 de eksik

  • Veriler çok faydalı ve dünya küresi görsel olarak etkileyici, ama pratik kullanım açısından düz bir dünya haritası daha iyi olur gibi
    Tüm veri merkezlerini tek seferde gösterir ve çizgiler aşırı birbirine yaklaşmadığı için okunması da daha kolay olur

    • Amatör telsizde bu tür azimutal eşit uzaklıklı projeksiyonun popüler olduğunu hatırlıyorum
      https://en.wikipedia.org/wiki/Azimuthal_equidistant_projecti...
    • 2B dünya haritası, konumların gerçekte ne kadar uzak olduğuna dair sezgi vermeyebilir
      İkisi arasında geçiş yapma seçeneği daha iyi olurdu
    • Katılıyorum. Havalı görünüyor ama veriyi gerçekten okumak için en iyi görselleştirme değil
    • Yazarıyım. Havalı olan ile kullanışlı olan arasında dikkatli bir denge gerekiyor

  • Gecikmenin en büyük faktörü elbette mesafe
    Ancak görece yakın bölgeler arasında bile doğrudan bağlı fiber olmadığı için, örneğin kutup bölgelerinden geçen rotalar gibi gecikmenin kötü olduğu durumlar var
    Üçgen eşitsizliğini büyük ölçüde ihlal eden bölge örnekleri olup olmadığını merak ediyorum
    Yani A–C gecikmesinin, en iyi A–B + B–C gecikmesinden çok daha kötü olduğu durumlar
    Sırf meraktan, bu fikirle hangi veri merkezlerinin fiberle doğrudan bağlı olma olasılığının yüksek olduğunu çıkarıp yalnızca o bağlantıları göstermek mümkün mü diye de merak ediyorum

    • AWS hakkında doğrudan konuşamam ama doktora tezimde RIPE Atlas prob’larını kullanarak bu tür örneklerden epey bulmuştum
      Temelde prob A ile C arasındaki gidiş-dönüş süresi, A–B + B–C’den büyük olan prob çiftlerini arama yöntemi
      Bu yöntemde ICMP/gidiş-dönüş süresi ölçümünün genel sorunları ve trafiğin gerçekten “aracı” prob üzerinden yönlendirilmemiş olması sorunu var; ama böyle çiftler mevcut
      https://theses.hal.science/tel-03666771/document belgesinin 84. sayfasında örnek var. Fransızca okuyabiliyorsanız
    • Yönlendirme biçimi nedeniyle bunun büyük ölçekte pek yaşanmayacağını düşünüyorum
      B üzerinden geçen “dolambaçlı” yol ICMP paketinin en ucuza ulaşacağı yolsa, gerçek trafikte de o yol seçilecektir
      Aksine A–C’nin A–B + B–C’ye çok yakın olduğu yerleri ararsanız bunun gerçekleştiği noktaları görebilirsiniz
      Fiber eksikliğinin yanı sıra daha avantajlı peering anlaşmaları gibi finansal nedenlerle de mümkün olabilir
    • Rusya, Moğolistan ve Hindistan arasındaki bölgede kablo çok az ve kaliteleri de iyi değil
      Bildiğim kadarıyla Mumbai’den Güney Rusya’ya mesafe olarak çok uzak değil ama gecikme şaşırtıcı derecede yüksek
      Örneğin Frankfurt’tan Moskova’ya olandan çok daha yüksek; Frankfurt–Moskova–Mumbai arasında üçgen eşitsizliğini ihlal edecek düzeyde mi bilmiyorum
    • Dünya genelindeki fiber optik kablo haritasına buradan bakabilirsiniz
      https://www.submarinecablemap.com/
      Denizaltı kablolarının döşeme maliyeti çok yüksek olduğu için kamuya açık olmayan kablo bulunması olasılığı çok düşük
    • Güney Amerika ve Güney Asya gibi ağ kalitesinin kötü olmasıyla nam salmış bölgeler var
      Genel olarak paket kaybı da daha yüksek olma eğiliminde

  • Birkaç gün önce bunu kullanıyordum
    https://aws-latency-test.com/

    • Yazarıyım. Bu görselleştirme için veri ararken o siteyi görmüştüm, fena değildi