Veri merkezleri arası latency ölçümü: Doğru test nasıl yapılır?

Giriş: Latency ölçümü neden tek sayıyla anlatılamaz?

Veri merkezleri (datacenter) arasında latency (gecikme) ölçümü, en sık “ping kaç ms?” sorusuyla geçiştiriliyor. Oysa uygulama performansını belirleyen şey; sadece ortalama RTT (Round Trip Time) değil, jitter (dalgalanma), paket kaybı, yol (route) değişimleri ve testin hangi katmanda yapıldığıdır. Bu rehberde, iki lokasyon arasında doğru latency ölçümü için neyi ölçmeniz gerektiğini, hangi araçları nasıl kullanacağınızı ve sonuçları nasıl yorumlayacağınızı adım adım göreceksiniz. Hedef: Siz test yapınca “ben niye bu değerleri görüyorum?” sorusu netleşsin ve veri merkezi seçimi/optimizasyonu için somut karar verin.

1) Latency türleri: Ping RTT mi, yoksa uygulama gecikmesi mi?

Önce ölçtüğünüz “gecikme” türünü ayırt edin. Aynı datacenter çifti için ping 15 ms görünüp uygulama 200 ms görebilirsiniz; bunun temel nedeni gecikmenin farklı katmanlarda birikmesidir.

Hangi metrik ne anlatır?

• ICMP latency (ping): Paketlerin IP katmanında gidiş dönüş süresini gösterir. Uygulama protokolünüz (TCP/HTTP) üzerinden birebir aynı sonucu vermez.
• TCP handshake latency: Bir bağlantının kurulması için geçen süre. SYN/SYN-ACK dönüşleri, güvenlik duvarları ve load balancer kuralları etkiler.
• TLS handshake latency: HTTPS kullanıyorsanız sertifika doğrulama, anlaşma (negotiation) ve şifreleme ek maliyeti vardır.
• Uygulama katmanı RTT: HTTP istek/yanıtında ve (varsa) ilk byte (TTFB) süresinde görülen gecikme.
• Jitter: Aynı ortalama latency etrafında değerlerin dalgalanması. Canlı sistemler için çoğu zaman “ortalama”dan daha kritik olabilir.
• Packet loss (paket kaybı): Ortalama gecikmeyi gizleyebilir; ama retransmit nedeniyle kuyruk ve gecikme zinciri üretir.

“Sadece ping” neden yanıltır?

• Birçok ortamda ICMP kısıtlıdır veya önceliklendirilir (QoS/DLP policy).
• Uygulama trafiği aynı yolu kullanmayabilir (ECMP, farklı routing politikaları).
• Load balancer/WAF/L7 proxy devredeyse gecikme proxy katmanında birikir.

Bu yüzden hedefiniz “datacenter A ile B arasında genel ağ kalitesi” ise ICMP + TCP + HTTP/TLS birlikte ölçülmelidir.

2) Ölçüm planı: Nereden, neyle, kaç tur?

Latency ölçümü için tek seferlik test yerine ölçüm planı kurun. Aşağıdaki şablon pratikte en az tartışmayla sonuç verir.

Minimum test seti (önerilen)

1. ICMP: 50-100 paket, varsayılan boyut.
2. TCP: Belirli portlar için 100 bağlantı (ör. 443, 80).
3. HTTP/TLS: Aynı URL’ye, sabit kullanıcı ajanı ile çoklu istek (ör. 100 istek).
4. Traceroute/mtr: Yol değişimlerini ve olası darboğazları görmek için kısa rapor.

Nereden test etmelisiniz?

• Testi sizin gerçek iş yükünüzün çıkışını temsil eden noktadan yapın. Örneğin uygulama sunucunuz VPC içinde ise ölçümü de aynı VPC’den yapın.
• Eğer amaç “Türkiye’den Avrupa’ya latency” ise test kaynağı lokasyonu sabit olmalı.

Kaç tur? Hangi istatistikler?

Şunları raporlayın: - Ortalama RTT - Medyan RTT - 95. yüzde dilim (p95) - Jitter (RFC 3550’deki kavram; pratikte standart sapma/dağılım) - Packet loss yüzdesi

Ortalama tek başına karar için yetmez; p95 gecikme kuyruklarını yakalar.

3) Araçlar ve komutlar: Ping, mtr, TCP connect ve HTTP/TLS ölçümü

Aşağıdaki araçlar çoğu Linux ortamında doğrudan kullanılabilir. Windows ortamında da benzerleri vardır; ancak burada Linux odaklı net komutlar veriyorum.

3.1 ICMP ile temel RTT (ping)

Örnek: - ping -c 100 -i 0.02 <hedef-ip>

Kontrol edin: - “packet loss” oranı - RTT dağılımı (min/avg/max ve mümkünse daha detay)

Not: Bazı sunucular ICMP’ye kısıt getirebilir; loss yüksekse uygulama trafiği farklı davranabilir.

3.2 Yol ve jitter için mtr (tercihen)

mtr, traceroute ve ping kombinasyonu gibi çalışır. - mtr -rwzbc 100 <hedef-ip>

Rapor okuma: - En yüksek gecikme hangi hop’ta artıyor? - Aynı hop’ta packet loss var mı? - Jitter geniş mi?

3.3 TCP ile port bazlı gecikme (connect)

ICMP yerine uygulama trafiğiyle daha uyumlu bir yaklaşım için TCP connect testleri yapın. - Basit test (ncat/netcat ile): nc -vz <hedef-ip> 443

Daha sistematik test için kısa bir script yaklaşımı kullanabilirsiniz; fakat pratikte şu hedef yeterlidir: - 443 ve (varsa) 80 için bağlantı kurma süresini loglayın.

Burada amaç: “Port açılıyor mu, hızlı mı kuruluyor?” sorusunu netleştirmek.

3.4 HTTP/TLS ile gerçek uygulama gecikmesi

Bir URL’ye istek atarak sadece bağlantı değil, TLS ve ilk byte (TTFB) davranışını ölçersiniz. Örnek fikir: - curl -o /dev/null -s -w "time_namelookup=%{time_namelookup} time_connect=%{time_connect} time_appconnect=%{time_appconnect} time_starttransfer=%{time_starttransfer} time_total=%{time_total}\n" https://<domain>/

Okunacak alanlar: - time_connect: TCP kurulma - time_appconnect: TLS anlaşması - time_starttransfer: Sunucudan ilk byte - time_total: İstek toplam süresi

Eğer time_appconnect aşırı yüksekse; sertifika/şifreleme pazarlığı, ara cihazlar (WAF/LB) veya route etkisi söz konusu olabilir.

4) Sonuçları yorumlama: Hangi senaryoda ne yapmalısınız?

Ölçüm değerleri “kötü” çıkınca tek cevap yoktur. Aşağıdaki ayrım, sorunun ağ mı yoksa mimari mi olduğunu hızla belirler.

Senaryo A: Ping iyi, HTTP kötü

Olası nedenler: - Uygulama katmanında WAF/LB gecikmesi - TLS handshake maliyeti - HTTP istek başına ek yönlendirmeler (redirect, farklı upstream)

Net aksiyon: - Aynı hedefe HTTP/TLS ölçümünü p95 ile kıyaslayın. - Load balancer/WAF loglarında “handshake” ve “upstream latency” alanlarına bakın.

Senaryo B: Paket kaybı var (packet loss)

Olası nedenler: - Orta yolda congestion - MTU/fragmentation sorunu (özellikle VPN veya container overlay ile)

Net aksiyon: - mtr’de loss’un yoğunlaştığı hop’u raporlayın. - Mümkünse MTU ayarını ve overlay ağ parametrelerini kontrol edin. - Uygulamada retransmit etkisini p95 ile gözleyin.

Senaryo C: Jitter yüksek, ortalama düşük

Olası nedenler: - ECMP nedeniyle route değişimleri - Yoğun saatlerde kuyruk

Net aksiyon: - p95/p99 ve standart sapmayı takip edin. - Testi farklı saatlerde tekrarlayın. - Kritik servis için “sticky” yönlendirme veya daha deterministik routing seçeneklerini değerlendirin (sağlayıcı/Load balancer düzeyinde).

Senaryo D: mtr’de belirli hop’ta gecikme artıyor

Olası nedenler: - O hop üzerinde oversubscription veya fiziksel darboğaz

Net aksiyon: - Sağlayıcıyla “hop bazlı” kanıt paylaşın: mtr raporu, saat aralığı, kaynak IP. - Alternatif route/peering seçenekleri olan bölge/ISP varyantını test edin.

5) Veri merkezi seçimi için latency ölçüm kontrol listesi

Bu bölüm, test sırasında sık yapılan hataları kapatır. Ölçüm yapmadan önce aşağıdakileri checklist olarak uygulayın.

5.1 Ölçüm disiplini

• [ ] Kaynak konum sabit (aynı sağlayıcı/aynı lokasyon)
• [ ] Hedef adres sabit (IP mi domain mi? Domain kullanıyorsanız DNS süresi etkisini ayrı raporlayın)
• [ ] En az 100 örnek (ping/TCP/HTTP)
• [ ] p95 raporlanıyor (sadece ortalama yok)
• [ ] Test saatleri gün içi değişime bakıyor

5.2 Protokol ve güvenlik etkileri

• [ ] HTTPS ölçülüyor (TLS maliyeti hariç bırakılmıyor)
• [ ] Port 443 için ölçüm yapılıyor
• [ ] Cache/WAF etkisi kontrol ediliyor (ilk istek vs tekrarlı istek ayrımı)

5.3 Mimari doğrulama

• [ ] Aynı mimari katman test ediliyor: CDN/WAF varsa gerçek trafiği temsil ediyor mu?
• [ ] Uygulama veritabanı çağrıları varsa “app-to-db” gecikmesi de ölçülüyor
• [ ] Stateful bileşenler (session store, queue) için de ayrı test var

5.4 Sonuçların karar değeri

• [ ] Ölçüm sonuçları “tek datacenter çifti” için değil, servis bazında yorumlanıyor
• [ ] SLA hedefiyle uyum kontrol ediliyor (ör. p95 60 ms ise gerçek kullanıcı deneyimi ne olur?)

6) Pratik örnek: İki lokasyon arasında 3 aşamalı kıyas

Somutlaştırmak için basitleştirilmiş bir kıyas kurgulayalım.

Kurgu

• Uygulama sunucusu: DC-A (ör. İstanbul)
• Veritabanı ve servis: DC-B (ör. Almanya)
• Ölçüm: Aynı kaynak VM’den, aynı hedef domain/IP ile

Beklenen okuma biçimi

1. ICMP RTT: DC-A ↔ DC-B genel ağ gecikmesi
2. TCP 443: Load balancer’a kadar bağlantı kurulma süresi
3. HTTPS (TTFB dahil): Gerçek kullanıcıya en yakın metrik

Karar kuralı (örnek, net)

• Eğer TCP 443 p95 yüksekse: rota/peering veya güvenlik cihazı kaynaklı olabilir.
• Eğer time_appconnect yüksekse: TLS anlaşması/ara katman etkisi var.
• Eğer time_starttransfer yüksekse: uygulama tarafında (upstream, cache, DB çağrısı) gecikme birikiyor.

Bu üç aşama ile “sadece ağ mı, uygulama mı?” ayrımı netleşir.

Sonuç: Aksiyon alınabilir ölçüm formatına geçin

Veri merkezleri arası latency ölçümünde en büyük hata, tek metrikle (çoğu zaman ping) karar vermektir. En doğru yaklaşım; ICMP + TCP + HTTPS/TLS’yi aynı hedef için çoklu denemelerle raporlamak ve p95 + jitter + paket kaybı ile yorumlamaktır. Bugün yapmanız gereken net adım: Test kaynağınızı sabitleyin, 100 örnekle çalışın, ping yerine özellikle 443 ve HTTPS zamanlarını loglayın, mtr raporuyla hop bazlı kanıt üretin. Bu çıktılarla sağlayıcıdan teknik açıklama istemek ve doğru veri merkezi/planı seçmek çok daha hızlı olur.