Veri merkezi konumu seçmek

Güncelleme: May 9, 2026X-ZoneServers Öğren

Sunucularınızın fiziksel olarak nerede yer aldığı üç şeyi etkiler: kullanıcılarınızın deneyimlediği gecikme, verilerinizin tabi olduğu hukuki rejim ve felaket kurtarma duruşunuz. Doğru konum üçünü de dengeler. Bu rehber gecikme matematiğini gözden geçirir, büyük şehirler arasında gerçekçi gidiş-dönüş süresi tahminleri verir, başlıca veri ikametgahı rejimlerini (KVKK/GDPR, ABD CLOUD Yasası, Çin, Rusya) özetler ve tek bölge ile çoklu bölge için bir karar ağacıyla biter.

Gecikme matematiği: fiziğin dayattıkları

Vakumdaki ışık 299.792 km/s hızında ilerler. Fiber optik kablodaki ışık bunun yaklaşık 2/3'ü hızındadır — yaklaşık 200.000 km/s veya tek yönlü 1.000 km başına yaklaşık 5 ms. Gidiş-dönüş süresi (RTT) bunun iki katıdır: kablo döşemesinin 1.000 km'si başına ~10 ms. Gerçek dünya fiber yolları genellikle büyük çember mesafesinin 1,3-2 katıdır, bu nedenle yönlendirme gerçeklikleri için ekstra gecikmeyi hesaba katın.

Işık, kırılma indisi nedeniyle camda yavaşlar. Tek modlu fiberin kırılma indisi yaklaşık 1,467'dir, bu nedenle fiberdeki ışık hızı c/1,467 ≈ 204.300 km/s'dir. Bu, 1.000 km fiber başına yaklaşık 4,9 ms tek yönlü gecikme ve 9,8 ms gidiş-dönüş verir. Bu sıkı bir fiziksel zemindir — hiçbir sağlayıcı mühendisliği ışık hızını yenemez. Üretim planlaması için daha yararlı bir genel kural: tek yönlü 100 km başına 1 ms, artı ağ sıçraması başına 1-2 ms anahtarlama ve yönlendirme ek yükü bütçeleyin. Uzun mesafe denizaltı kabloları iyi mühendislik ürünüdür ve teorik minimuma yaklaşır (Londra-New York yaklaşık 70 ms RTT'dir, 5.500 km büyük çember sınırına yakın). Son mil ve şehir içi yollar genellikle mesafeden ziyade yönlendirici sıçramaları ve ISS peering geometrisi nedeniyle 5-15 ms'dir.

Büyük şehirler arasında gerçek RTT tahminleri

2026'da büyük hosting merkezleri arasında yaklaşık tek yönlü gidiş-dönüş süreleri (tam RTT): Londra-Amsterdam ~10 ms, Londra-Frankfurt ~15 ms, Londra-New York ~70 ms, New York-San Francisco ~70 ms, Frankfurt-Singapur ~160 ms, Londra-Sidney ~250 ms, Tokyo-San Francisco ~100 ms. Bunlar veri merkezi eşleri arasında TCP'den TCP'ye ölçülen tipik fiber en iyi durum değerleridir.

Bu sayılar, büyük IXP'ler (LINX, AMS-IX, DE-CIX, KINX) tarafından yayımlanan kamuya açık peering verilerinden ve büyük ölçekli gecikme atlaslarından (RIPE Atlas, WonderNetwork, Cloudping) gelir. Gerçek RTT'niz, günün saatine, sağlayıcınız ile kullanıcınızın ISS'si arasındaki peering ilişkilerine ve kullanılan belirli denizaltı kablo yoluna bağlı olarak %10-30 değişecektir. Yukarıdaki sayılar tipiktir, garanti edilmemiştir ve her iki uç noktanın çoklu Tbps transit ile veri merkezlerinde olduğunu varsayarlar. Son mil konut bağlantıları, veri merkezinden veri merkezine zeminin üzerine bir 5-30 ms daha ekler.

KaynakHedefMesafe (büyük çember)Tipik RTT
LondraAmsterdam360 km~10 ms
LondraFrankfurt640 km~15 ms
LondraParis340 km~10 ms
FrankfurtVarşova900 km~20 ms
LondraNew York5.570 km~70 ms
New YorkMiami1.760 km~30 ms
New YorkSan Francisco4.140 km~70 ms
San FranciscoTokyo8.280 km~100 ms
FrankfurtSingapur10.290 km~160 ms
LondraSidney16.990 km~250 ms
FrankfurtMumbai6.580 km~110 ms
São PauloMiami6.580 km~120 ms

Veri ikametgahı: KVKK/GDPR, CLOUD Yasası ve diğerleri

AB/AEA kişisel verileri KVKK/GDPR'a (Yönetmelik (AB) 2016/679) tabidir, bu da belirli güvencelermez AEA dışına aktarımları kısıtlar. ABD CLOUD Yasası (2018), ABD makamlarının ABD merkezli sağlayıcıları, fiziksel olarak nerede saklanırsa saklansın, verileri açıklamaya zorlamasına izin verir. Rusya ve Çin'in kendi veri yerelleştirme rejimleri vardır. Hem kullanıcılarınızın yargı yetkilerine hem de sözleşmesel yükümlülüklerinize uygun bir veri merkezi bölgesi seçin.

KVKK/GDPR (Mayıs 2018'de yürürlüğe girdi), AB veya AEA mukimlerinin herhangi bir kişisel verisini — ad, e-posta, IP adresi, davranışsal veri — denetleyenin merkezi nerede olursa olsun düzenlenmiş olarak ele alır. Sınır ötesi aktarımlar yeterlilik kararı, Standart Sözleşme Maddeleri veya Bağlayıcı Şirket Kuralları gerektirir. Madde 49 istisnaları dardır. Schrems II kararı (Avrupa Birliği Adalet Divanı, Temmuz 2020) Privacy Shield'ı geçersiz kıldı ve aktarım güvencelerini önemli ölçüde sıkılaştırdı. ABD CLOUD Yasası (Yurt Dışı Veri Kullanımının Yasal Açıklığa Kavuşturulması Yasası, 2018), ABD federal makamlarının herhangi bir ABD merkezli sağlayıcıyı, veri Frankfurt'taki bir sunucuda olsa bile, saklanan veriyi üretmeye zorlamasına izin verir. Bu, ABD merkezli hosting sağlayıcıları kullanan Avrupalı müşteriler için bir gerilim yaratır, verilerinin fiziksel olarak hangi veri merkezinde yaşadığına bakılmaksızın. Rusya Federal Yasası No. 242-FZ, Rus vatandaşlarının kişisel verilerinin başlangıçta fiziksel olarak Rusya içindeki sunucularda işlenmesini gerektirir. Çin'in PIPL'si (Kişisel Bilgi Koruma Yasası, Kasım 2021'de yürürlüğe girdi), kritik bilgi altyapısı operatörleri ve yüksek hacimli veri işlemcileri için yerelleştirme gerektirir. Bu rejimlerin hiçbiri uygulama sunucularınızın nerede çalıştığını umursamaz; hepsi kişisel verilerin nerede saklandığını ve işlendiğini umursar.

Çoklu bölge ne zaman mantıklı

Çoklu bölge, 100 ms altı gecikme gereksinimleri olan coğrafi olarak dağıtık kullanıcılarınız olduğunda, yargı yetkileri arasında düzenleyici veri ikametgahı yükümlülükleriniz olduğunda veya tek bölgeli kesinti riski kabul edilemez olduğunda haklı çıkar. Hobi projeleri, bir bölgedeki kullanıcılarla düşük trafikli SaaS veya mühendislik karmaşıklığının gecikme kazanımlarından ağır bastığı iş yükleri için nadiren haklı çıkar.

Çoklu bölge üç somut maliyet ekler. İlk olarak, mühendislik karmaşıklığı: veri çoğaltma (sonunda tutarlı veya küresel olarak senkronize), yönlendirme mantığı (geo-DNS, anycast, bölgesel yedekleme) ve bölgeler arası gözlemlenebilirlik tümü operasyonel yüzey alanını çoğaltır. İkincisi, altyapı maliyeti: en az iki kat hesaplama ve depolama, artı bulut sağlayıcılarının GB başına aldığı bölgeler arası transit ücretleri. Üçüncüsü, tutarlılık ödünleşimleri: senkron küresel yazmalar fiziksel olarak önceki bölümdeki aynı gecikme matematiğiyle sınırlıdır, bu nedenle çoğu çoklu bölge tasarımı bir tür sonunda tutarlılığı kabul eder. Bu maliyete değer haklı sebepler: 200+ ms gecikmenin dönüşümü çökerttiği kıtalar arasında dağıtılmış gerçek kullanıcılar, saniye altı RTO felaket kurtarma gereksinimleri, AB verilerini AB'de ve ABD verilerini ABD'de aynı anda tutma düzenleyici yükümlülükleri veya herhangi bir tek veri merkezi kesintisinin görünmez olması gereken aktif-aktif yüksek kullanılabilirlik gereksinimleri. Çoğu üretim iş yükü buna ihtiyaç duymaz; birçok tasarım buna doğru aşırı mühendislik yapar.

Karar ağacı: bir bölge nasıl seçilir

Adım 1: kullanıcılarınızın %80'inin nerede yaşadığını belirleyin (analitik, CDN günlükleri, beklenen hedef pazar). Adım 2: en yakın hosting bölgesini seçin. Adım 3: hukuki yargı yetkisinin veri ikametgahı yükümlülüklerinizle eşleştiğini kontrol edin. Adım 4: yalnızca 1. adım birinciden 100 ms RTT'den fazla uzakta ikinci bir kullanıcı kümesi ortaya çıkarırsa veya HA/DR gereksinimleri talep ederse ikinci bir bölge ekleyin.

Ağacı dürüstçe gözden geçirin. Çoğunlukla Almanya, Fransa, Birleşik Krallık ve Hollanda'daki kullanıcılarla tipik bir Avrupa odaklı SaaS için, tek bir Batı Avrupa veri merkezi (Frankfurt, Amsterdam veya Londra) her kullanıcıyı 30 ms RTT altında tutar ve KVKK/GDPR'ı temiz bir şekilde karşılar. Boston'dan Los Angeles'a kullanıcılarla ABD odaklı bir B2B ürünü için, tek bir ABD Doğu veri merkezi (Ashburn, NYC) Doğu Kıyısı kullanıcılarını 20 ms altında ve Batı Kıyısı'nı 80 ms altında tutar — oyun için kötü, çoğu SaaS için iyi. Gerçekten küresel ürünler için (her kıtadaki kullanıcılarla web uygulamaları), birincil bir bölge artı küresel kenar varlığı olan bir CDN, üç veri merkezinde aktif-aktif çalıştırmayı genellikle geçer. Yargı yetkileri arasında sıkı veri ikametgahı gereksinimleri olan ürünler için (yalnızca AB ve yalnızca ABD veri düzlemi), gecikme ne olursa olsun çoklu bölge zorunlu hale gelir.

Uyumluluk kısayolları: gerçekten anlam ifade eden sertifikalar

Uygulanırsa ISO/IEC 27001 (bilgi güvenliği yönetimi), SOC 2 Tip II (tek bir anda değil, zaman içinde denetlenmiş operasyonel kontroller) ve PCI DSS Seviye 1 (ödeme verileri) arayın. AB müşterileri için açık KVKK/GDPR veri işleme sözleşmeleri (DPA) ve net bir alt işleyici listesi arayın. Adlandırılmış sertifikalar olmadan genel 'kurumsal düzeyde güvenlik' pazarlaması temelde anlamsızdır.

Üç sertifika gerçek ağırlık taşır. ISO/IEC 27001:2022, bilgi güvenliği yönetim sistemleri için uluslararası standarttır ve bağımsız bir denetim ile devam eden gözetim denetimleri gerektirir. SOC 2 Tip II, bir kuruluşun kontrollerini 6-12 aylık bir gözlem penceresi boyunca denetler ve bunu Tip I'den (zaman noktasında) ayırt eder. PCI DSS, ödeme kartları işlerseniz uygulanır; Seviye 1, yılda 6+ milyon işlem işleyen kuruluşlar içindir. Avrupa müşterileri için, KVKK/GDPR DPA'sı (veri işleme eki) sözleşmesel olarak bağlayıcıdır ve sağlayıcının verilerinizle tam olarak ne yapabileceğini ve yapamayacağını listeler. Bunların ötesinde, şeffaflık raporları (sağlayıcı kolluk kuvveti taleplerini ne sıklıkta alır?), yayımlanmış bir alt işleyici listesi (verilerinize dokunan üçüncü taraflar) ve sözleşme feshinde net veri silme garantileri arayın. 'Banka düzeyinde güvenlik' veya 'askeri düzeyde şifreleme' gibi genel ifadeler size hiçbir şey söylemez — temel AES-256 algoritması her yerde aynıdır.

Sıkça sorulan sorular

Bir veri merkezine gerçek gecikmeyi nasıl ölçerim?
Hedef kullanıcı ağınızdan veri merkezindeki bir genel IP'ye `ping` ve `mtr` çalıştırın — çoğu sağlayıcı bir looking glass veya test IP'si sunar. RIPE Atlas ve Cloudping.co, herhangi bir IP'ye yüzlerce vantaj noktasından gecikme ölçen küresel sonda ağları sağlar ve tek bir ping çalıştırmasından daha temsili bir resim verir.
CDN gecikmesi iyi veri merkezi konumunun yerini alır mı?
Yalnızca statik içerik için. Bir CDN, kullanıcıya yakın kenar düğümlerinden önbelleğe alınmış HTML, CSS, görüntü ve betikler sunar, ancak her dinamik istek — oturum açma, ödeme, API çağrısı — yine de kaynağınıza ulaşır. Kaynağınız Frankfurt'taysa ve kullanıcınız Sidney'deyse, dinamik yol yine de ~250 ms RTT alır.
Bir AB veri merkezi kullanırsam veriler otomatik olarak korunur mu?
Otomatik olarak değil. Veri merkezinin fiziksel konumu gerekli ancak yeterli değildir. Sağlayıcı ayrıca sözleşmesel olarak (bir KVKK/GDPR DPA aracılığıyla) yasal güvenceler olmadan AEA dışına veri aktarmamayı taahhüt etmeli ve katı bir yargı yetkisi müşterisiyseniz ABD CLOUD Yasası gibi sınır dışı taleplere tabi olmamalıdır.
Anycast nedir?
Anycast, aynı IP adresinin birden fazla konumdan duyurulduğu ve yönlendiricilerin trafiği topolojik olarak en yakın olana otomatik olarak teslim ettiği bir ağ yönlendirme tekniğidir. Kamu DNS çözücüleri, CDN'ler ve DDoS filtreleme ağları, kullanıcılara geo-DNS olmadan düşük gecikme vermek için anycast kullanır ve bölgesel bir kesintiyi şeffaf bir şekilde atlatabilir.
Tipik bir SaaS kaç bölge kullanmalıdır?
Çoğu SaaS ürünü için, bir birincil bölge artı küresel bir CDN trafik modellerinin %95'ini ele alır. Yalnızca birinciden 100 ms RTT'den fazla uzakta ikinci bir kullanıcı kümeniz olduğunda, düzenleyici veri ikametgahı gereksinimleriniz olduğunda veya iş sürekliliği dakika altı bölgesel yedekleme gerektirdiğinde ikinci bir bölge ekleyin.
Tier-3 ve tier-4 veri merkezi derecelendirmeleri hâlâ alakalı mı?
Evet, Uptime Institute'un Tier sınıflandırması (I'den IV'e) hâlâ tesis yedekliliği için altın standardı tanımlar: Tier III, kesinti olmadan eşzamanlı bakıma izin verir, Tier IV hata toleransı ekler. Maliyet-fayda oranı nedeniyle çoğu modern hyperscale tesis IV yerine Tier III veya III+ hedefler.

İlgili X-ZoneServers ürünleri