Eğer şimdiye kadar birkaç kez iki bölge arasında gidip geldiyseniz ve her seferinde kullanıcılarınız yavaşlıktan şikayet ettiyse, sorun başka bir yerde. Bulut sunucu konumu seçimi genellikle tek seferlik bir karar olarak alınır, oysa pratikte tahminle değil, sayıyla ölçülmesi gereken operasyonel bir karardır. Bu metin, ne aradığını bilen ve yalnızca hangi kriterin gerçekten belirleyici olduğunu öğrenmek isteyenler içindir.
Bulut sunucu konumunu haritayla değil, gecikmeyle ölçün
Yapmanız gereken ilk şey, gecikmeyi kendi ofisinizden değil, kullanıcının kendisinden ölçmektir. Her adayda geçici bir sunucu ayağa kaldırın ve birkaç gerçek noktadan ping ve mtr çalıştırın:
mtr -rwzbc 100 -T -P 443 target.example.com-T bayrağı ICMP'yi değil, 443 portu üzerinden TCP yolunu ölçer. Bu fark önemlidir çünkü birçok yol ICMP'yi daha düşük öncelikte işler ve gördüğünüz sayı, kullanıcının gerçek deneyiminden farklıdır. -c 100 bayrağı da yüz paket gönderir, böylece ortalama ve standart sapma anlam kazanır; on paketlik bir örnekleme hiçbir şeyi kanıtlamaz.
Aramanız gereken sayı, ortalamanın değil, 95. yüzdelikteki gidiş-dönüş gecikmesidir. Ortalama 40 milisaniye olsa bile 95. yüzdelik 180 milisaniyede oturuyorsa, kullanıcınız her sayfa yüklemesinde hissedilir bir duraklama yaşar. Tipik bir web uygulaması için TTFB'de 20 milisaniye ile 60 milisaniye arasındaki fark, genellikle tam yükleme süresinde %15 ila %40 arasında kendini gösterir, çünkü her sayfa onlarca paralel istek üretir ve gecikme birikir.
Ağ yolu, coğrafi mesafeden daha önemlidir
İki veri merkezi birbirinden yüz kilometre uzakta olabilir ve biri diğerinin yarısı kadar gecikme verebilir. Bunun nedeni hop sayısı ve peering kalitesidir. Sekiz hoplu ve doğrudan trafik değişimli bir yol, trafiği üç aracı ağdan geçiren dört hoplu bir yoldan daha hızlı ve daha kararlıdır. mtr çıktısı bunu gösterir: ara hoplarda kararlı paket kaybı görüyorsanız, son hop sağlıklı olsa bile o yol hassas yükler için uygun değildir.
Burada hata yapılır: ekipler bir kez ping atar, düşük bir sayı görür ve kararı kesinleştirir. Üç hafta sonra yoğun trafik saatinde, aynı yol belirli bir ISP'nin uplink tıkanıklığı nedeniyle %3 ila %7 paket kaybı gösterir. İşareti de şudur: site akşam saatlerinde yavaşlar ama sunucu loglarında olağandışı hiçbir şey yoktur, çünkü darboğaz sunucunuzun dışındadır. Bu kalıbı görürseniz, kaynaklarda herhangi bir değişiklik yapmadan önce yolu yeniden ölçün.
Bölge seçiminin gerçek kriterleri
Pratikte dört kriter belirleyicidir ve geri kalanı arka planda kalır:
- Kullanıcıların konumu, şirketin konumu değil. Trafiğin %80'i İran içinden geliyorsa, daha uzak bir bölge yalnızca trafik maliyetini ve gecikmeyi artırır.
- Veri gereksinimleri. Bazı yükler belirli bir coğrafi sınır içinde kalmalıdır; bu kısıtlama, herhangi bir gecikme optimizasyonundan önce kararı kesinleştirir.
- Bağımlı servisler. Yönetilen veritabanı veya depolama servisi A bölgesindeyse ve uygulama B bölgesindeyse, her sorgu kıtalar arası bir gidiş-dönüşe dönüşür. Bu hata çok katmanlı mimarilerde çok yaygındır.
- Yedek yol. Yalnızca tek çıkış yolu olan bir bölge, o yolun kesintisinde tamamen erişilemez hale gelir.
Aynı bölgede birkaç sunucunun birbiriyle konuştuğu yükler için, iç trafiği genel yoldan ayırın. Sunucular arası özel ağ hem gecikmeyi düşürür hem de genel bant genişliğini gerçek kullanıcı trafiği için serbest bırakır.
Birkaç bölge, tek bölge veya ikisinin kombinasyonu
Basit bir cevap yoktur ve "her zaman birkaç bölge" diyen herkes bir maliyeti göz ardı ediyordur. Gerçek karşılaştırma şudur:
| Kriter | Tek bölge | Çok bölgeli aktif-aktif |
|---|---|---|
| Dağınık kullanıcılar için gecikme | Uzak grup için kötü | Herkes için kabul edilebilir |
| Veri karmaşıklığı | Düşük | Yüksek; replikasyon ve çakışma çözümü gerekir |
| Bölgeler arası trafik maliyeti | Sıfır | Genellikle önemli |
| Bölge kesintisindeki davranış | Tamamen erişilemez | Kapasite azalması, kesinti değil |
Benim tercihim şu: kullanıcılarınız tek bir coğrafi bölgede yoğunlaştığı sürece, pasif (standby) bir yedek bölgeyle tek bölge kullanın. Çok bölgeli aktif-aktif'i, ya kullanıcılarınız gerçekten dağınıksa ya da SLA'nız birkaç saatlik kesintiye izin vermiyorsa seçin. Kimsenin önceden hesaplamadığı maliyet, kod yazma karmaşıklığıdır: her yazma sorgusu hangi bölgenin gerçeğin kaynağı olduğunu bilmelidir ve bu karar projenin ömrü boyunca sizinle kalır.
Gecikmeyi denklemden çıkaran katman
İkinci bir bölge düşünmeden önce, trafiğinizin ne kadarının aslında statik olduğuna bakın. Görseller, JS ve CSS dosyaları bir içerik dağıtım ağından sunulursa, kullanıcı isteklerindeki gecikmenin büyük bir kısmı ortadan kalkar ve belki de artık ikinci bir bölgeye ihtiyacınız kalmaz. Bu, en ucuz konum optimizasyonudur ve sıklıkla göz ardı edilir.
Büyük dosyalar ve yedekler için de bunları uygulama sunucusunun aynı diskinde tutmak hem depolama maliyetini artırır hem de gelecekteki geçişi zorlaştırır. Bunları nesne depolama alanına ayırmak bu bağımlılığı keser.
Konum seçiminden sonra yapılandırmanız gerekenler
Bölge seçimi işin yarısıdır. Diğer yarısı, kesinti olmadan oradan çıkabileceğinizden emin olmaktır. Her riskli değişiklikten önce bulut ortamında anlık görüntü kullanın ki başka bir bölgeye geçiş kötü giderse geri dönüş yolunuz olsun.
Ve izlemeyi ilk günden ciddiye alın. Gecikmeyi ölçmüyorsanız, kullanıcı ilk kez şikayet ettiğinde sorunun nerede olduğunu ancak o zaman anlarsınız. Bulut izleme ve uyarı kılavuzu tam da bu boşluğu doldurur: ortalamada değil, gecikmenin 95. yüzdelik diliminde uyarı.
Yükünüz GPU ağırlıklıysa, konum kısıtlaması farklı bir şekil alır: grafik kartları her bölgede mevcut değildir ve erişim ile gecikme arasında birini seçmeniz gerekir. Bu durumda yapay zeka modelleri için GPU sunucu kurulumu doğru başlangıç noktasıdır.
Düzensiz büyüyen yükler için, her trafik sıçramasında konumu değiştirmek zorunda kalmamak adına kapasiteyi önceden seçtiğiniz bölgede büyütün. Kesintisiz bulut kaynak ölçeklendirme kılavuzu bunu downtime olmadan açıklar. Mimariniz konteyner tabanlıysa, yönetilen Kubernetes düğümler arası taşımayı kolaylaştırır, ancak kümenin kendisinin de bir bölgeye bağlı olduğunu unutmayın.
Pratik özet: herhangi bir karardan önce üç gerçek noktadan yüz paketlik mtr çalıştırın, 95. yüzdelik dilimi görün ve sonra seçin. Sayı kabul edilebilirse orada kalın ve CDN ile özel ağa yatırım yapın; değilse mimariyi sorunun etrafından dolandırmak yerine bölgeyi değiştirin.
Sık sorulan sorular
İran içindeki kullanıcılar için kabul edilebilir gecikme nedir?
Web uygulaması için, 95. yüzdelik dilimde 50 milisaniyenin altındaki gidiş-dönüş gecikmesi iyidir ve 80 milisaniyenin altı hâlâ kabul edilebilir. 95. yüzdelik dilimde 150 milisaniyenin üzerinde, kullanıcı ardışık etkileşimlerde duraklamayı hisseder.
Bu sayılar API ve etkileşimli uygulamalar içindir. Dosya indirme ve yayın için bant genişliği ve yol kararlılığı gecikmeden daha önemlidir.
Belirli servislere erişmek için daha uzak bir bölge seçmek mantıklı mı?
Yalnızca o servis gerçekten erişilebilir değilse veya yasal bir zorunluluğunuz varsa. Aksi halde, her kıtalar arası istek 150 ila 300 milisaniye ek gecikme ekler ve bu sayı çok katmanlı mimaride katlanır.
Mecbursanız, gecikmeye duyarlı katmanları kullanıcıya yakın tutun ve yalnızca veri katmanını daha uzağa taşıyın.
Sorunun sunucu konumundan mı yoksa uygulamanın kendisinden mi olduğunu nasıl anlarım?
TTFB tüm coğrafi noktalarda tekdüze yüksekse, sorun uygulama veya veritabanındadır. Yalnızca bazı bölgelerden yüksekse, sorun ağ yolu veya konumdur.
Basit bir test: aynı isteği aynı bölgedeki bir sunucudan gönderin. Orada hızlıysa ve dışarıdan yavaşsa, darboğaz kod değil ağdır.
Hizmette kesinti olmadan bölge değiştirilebilir mi?
Evet, ama doğrudan taşımayla değil. Doğru kalıp şudur: yeni bölgeyi tamamen ayağa kaldırın, veriyi replike edin, trafiği DNS veya yük dengeleyici ile kademeli olarak aktarın ve eski bölgeyi bir süre hazır durumda tutun.
Bunun için, trafik yüzdesini kontrol edebilmek ve hata durumunda hızla geri dönebilmek adına health check ile yük dengeleyici kurulumuna ihtiyacınız vardır.