Frankfurt VPS Barındırma: Performans ve GDPR Rehberi

Frankfurt VPS barındırma hizmeti kimler içindir

Frankfurt VPS barındırma hizmeti; kullanıcıları Almanya'da, daha geniş Almanca konuşulan pazarda veya Avrupa Birliği genelinde bulunan projeler için uygundur. Frankfurt, Avrupa ağlarının kesiştiği ve trafiği doğrudan birbirine aktardığı merkezlerden biridir; bu nedenle orada bulunan bir sunucu, kıtanın büyük bölümüne birkaç on milisaniye içinde ulaşır. Kullanıcılarınızın çoğu Kuzey Amerika'daysa, makine ne kadar hızlı olursa olsun Avrupa merkezli bir sunucu onlara yavaş gelecektir; çünkü mesafe, optimizasyonla giderilemeyecek bir alt sınır belirler.

Bir konum seçimi iki ayrı soruyla belirlenir ve bunları birbirine karıştırmak hatalı tercihlere yol açar. Birincisi kullanıcılarınızın nerede olduğuyla ilgilidir ve mesafe ile gidiş-dönüş süresi (RTT) ile ilgilidir. İkincisi ise verilerinizin nerede barınmasına izin verildiğiyle ilgilidir; bu ise yasal ve sözleşmesel bir sorudur. Frankfurt, Avrupalı kitleler için birinci soruya güçlü bir yanıt sunar. İkinci soru için ise belirli bir sorunu ortadan kaldırır ancak diğer konuları çözüme kavuşturmaz.

Frankfurt neden bu kadar iyi bağlantıya sahip?

Frankfurt, zirve trafik ve bağlı ağ sayısı bakımından dünyanın en büyük internet değişim noktalarından (IXP - internet exchange point) biri olan DE-CIX'e (Deutsche Commercial Internet Exchange) ev sahipliği yapmaktadır. IXP, bağımsız ağların trafiği birbirine taşımak için daha büyük bir ağa ödeme yapmak yerine, bir veri merkezi içinde birbirine bağlandığı ortak bir anahtarlama yapısıdır. DE-CIX, güncel trafik istatistiklerini kendi sitesinde yayınlamaktadır; bu rakamlar sürekli değiştiği için bir makaleye kopyalanmış bir sayıya güvenmek yerine güncel verileri oradan takip etmek gerekir.

Bunun pratik etkisi toplam sayılardan ziyade yollarla ilgilidir. Servis sağlayıcınızın ağı ve ziyaretçinizin İSS'si (internet servis sağlayıcısı) aynı değişim noktasında bağlandığında, aralarındaki trafik bu noktada tek bir yönlendirme sekmesi (hop) üzerinden geçer. Yerel olarak eşleşmediklerinde ise trafik, her ikisini de taşıyan üçüncü bir ağa ulaşmak zorundadır ve bu ağın en yakın teslim noktası başka bir ülkede olabilir. Amsterdam veya Londra üzerinden trafik alışverişi yapan iki Alman ağı, bu ekstra mesafenin bedelini her iki yönde de öder. Ağ mühendisleri buna "trombonlama" (tromboning) adını verir ve yakındaki bir sunucunun uzak görünmesinin yaygın nedeni budur.

Bunu varsaymak yerine gözlemleyebilirsiniz. İlgilendiğiniz ağdan sunucunuza karşı mtr komutunu çalıştırın ve ters DNS kayıtlarındaki sekme isimlerini okuyun. Yönlendirici ana bilgisayar adları genellikle IATA havaalanı kodlarını içerir; bu nedenle bir sekme ismindeki fra Frankfurt'u, ams Amsterdam'ı ve lhr Londra'yı ifade eder. Bir Alman tüketici bağlantısından bir Alman sunucusuna giden yolda ortada lhr görünmesi, fazladan milisaniyelerin tam olarak nerede harcandığını size gösterir.

Frankfurt kullanıcılarınızdan ne kadar uzakta?

Fiber optik kablolardaki ışık, boşluktaki hızının yaklaşık üçte ikisi kadar bir hızla, yani saniyede 200.000 kilometreye yakın bir hızla hareket eder. Gidiş-dönüş süreci yolu iki kez kat eder; bu nedenle d kilometre mesafe için mümkün olan en hızlı gidiş-dönüş süresi d/100 milisaniyedir. Bu bir alt sınırdır ve hiçbir şey bunun önüne geçemeyeceği için referans olarak kullanışlıdır.

[
  {
    "label": "Zurich",
    "distance_km": 304,
    "min_rtt_ms": 3.0
  },
  {
    "label": "Amsterdam",
    "distance_km": 365,
    "min_rtt_ms": 3.7
  },
  {
    "label": "Berlin",
    "distance_km": 424,
    "min_rtt_ms": 4.2
  },
  {
    "label": "Paris",
    "distance_km": 479,
    "min_rtt_ms": 4.8
  },
  {
    "label": "Milan",
    "distance_km": 519,
    "min_rtt_ms": 5.2
  },
  {
    "label": "Vienna",
    "distance_km": 600,
    "min_rtt_ms": 6.0
  },
  {
    "label": "London",
    "distance_km": 640,
    "min_rtt_ms": 6.4
  },
  {
    "label": "Warsaw",
    "distance_km": 903,
    "min_rtt_ms": 9.0
  },
  {
    "label": "Stockholm",
    "distance_km": "1,197",
    "min_rtt_ms": 12.0
  },
  {
    "label": "Madrid",
    "distance_km": "1,419",
    "min_rtt_ms": 14.2
  },
  {
    "label": "New York",
    "distance_km": "6,206",
    "min_rtt_ms": 62.1
  }
]

Bu değerler ölçülmüş değil, düz hat mesafesi üzerinden hesaplanmıştır. Son sütunu, fiziğin izin verdiği en iyi durum olarak değerlendirin. Fiber kablolar büyük daireler yerine yolları ve nehir vadilerini takip ettiği ve yol üzerindeki her yönlendirici küçük bir iletim ve kuyruklama gecikmesi eklediği için, gerçek ölçümler genellikle bu alt sınırın 1,5 ila 2 katı arasında sonuçlanır.

Berlin, Frankfurt'tan 424 km uzaklıktadır ve alt sınır 4.2 ms'dir. Madrid 1,419 km mesafededir ve alt sınır 14.2 ms'dir; burası AB içindeki en uzak köşedir. New York 6,206 km uzaklıkta olup alt sınır 62.1 ms'dir; bu nedenle transatlantik bir kitleye hitap etmek bir ince ayar sorunu değil, bir konum kararıdır.

Yavaş bir gidiş-dönüş süresinin sayfa yüklenmesine maliyeti nedir?

Bir gidiş-dönüş (round trip), nadiren tek bir gidiş-dönüşten ibarettir. Bir HTTPS bağlantısı açmak, TCP (transmission control protocol) el sıkışması için bir, TLS (transport layer security) 1.3 el sıkışması için ise bir gidiş-dönüş daha gerektirir. Yanıtın ilk baytı gelmeden önce istek, üçüncü bir gidiş-dönüşe daha mal olur. TLS 1.2 ise buna dördüncü bir gidiş-dönüş ekler. Önbellekte bulunmayan bir DNS (domain name system) sorgusu, farklı bir sunucuya yapıldığı için en az bir gidiş-dönüş daha ekler.

[
  {
    "label": "User in Frankfurt",
    "rtt_ms": 5,
    "first_byte_ms": 15
  },
  {
    "label": "User in Warsaw",
    "rtt_ms": 20,
    "first_byte_ms": 60
  },
  {
    "label": "User in Madrid",
    "rtt_ms": 30,
    "first_byte_ms": 90
  },
  {
    "label": "User in New York",
    "rtt_ms": 90,
    "first_byte_ms": 270
  },
  {
    "label": "User in Singapore",
    "rtt_ms": 170,
    "first_byte_ms": 510
  }
]

Buradaki gidiş-dönüş sütunu, Frankfurt'taki bir sunucuya giden makul bir yol varsayımıdır; ikinci sütun ise bunun aritmetik sonucudur: ilk bayttan önce üç gidiş-dönüş. Frankfurt'taki bir kullanıcı 15 ms bekler. Singapur'daki bir kullanıcı ise 170 ms gidiş-dönüş süresiyle, tarayıcı henüz hiçbir şeyi çizmeden önce aynı yanıt için 510 ms bekler.

Çarpan etkisi meselenin özüdür. RTT (gidiş-dönüş süresi) değerindeki her bir milisaniyelik artış, ilk bayt gelene kadar yaklaşık üç milisaniyeye mal olur ve bu maliyet devam eder. HTML bir stil dosyasına atıfta bulunur, stil dosyası bir yazı tipine atıfta bulunur ve bu keşiflerin her biri aynı bağlantı üzerinde yeni bir gidiş-dönüş demektir. Sunucu tam olarak aynı işi aynı sürede yapsa bile, araya birkaç yüz milisaniyelik mesafe girmesi, anlık hissettiren bir sayfayı yavaş hissettiren bir sayfaya dönüştürür.

Bu durum aynı zamanda bir CDN'in (içerik dağıtım ağı) neleri düzeltebileceğinin sınırlarını da belirler. Kullanıcıya yakın bir önbellekten sunulan statik dosyalar uzun yolu atlar. Ancak veritabanına soru sorması gereken oturum açılmış bir panel bunu yapamaz: bu istek, tüm mesafeyi iki kez kat etmeye devam eder. Kaynak sunucuyu (origin) oturum açan kullanıcıların yakınına yerleştirmek, hiçbir önbelleğin sizin yerinize yapamayacağı bir işlemdir.

Bunu kullanıcılarımın bulunduğu konumdan nasıl ölçerim?

Bu komutları, hizmet verdiğiniz ülkedeki bir ev veya ofis bağlantısı gibi, önemsediğiniz ağ üzerindeki bir makineden çalıştırın. Başka bir veri merkezindeki sunucudan ölçüm yapmak, kullanıcılarınızın deneyimi hakkında değil, veri merkezi yolları hakkında bilgi verir. Aşağıdaki komutlar kendi başınıza çalıştırmanız için örneklerdir: yalnızca bizzat ölçtüğünüz gecikme değerleri dikkate alınmalıdır.

ping -c 20 your-server.example.com

Özet satırı rtt min/avg/max/mdev = ... değerini gösterir. Tipik durum için avg, paketler arasındaki değişkenlik olan jitter için ise mdev değerini okuyun. Normal bir avg değerine rağmen yüksek bir mdev değeri, yolun kararsız olduğunu gösterir; bu durum SSH veya sesli görüşme gibi etkileşimli işleri, ortalama gecikmenin biraz yüksek olmasından daha fazla olumsuz etkiler.

sudo apt update && sudo apt install -y mtr-tiny
mtr -rwzc 50 your-server.example.com

-r canlı ekran yerine bir rapor yazdırır, -w uzun ana bilgisayar adlarını olduğu gibi tutar, -z her bir sıçramanın (hop) AS (otonom sistem) numarasını gösterir ve -c 50 elli döngü gönderir. Orta bir sıçramada görülen ancak son sıçramada olmayan paket kaybı normaldir ve bir hata değildir: birçok yönlendirici, diğer tüm trafiği sorunsuz iletirken kendi ürettikleri ICMP yanıtlarını hız sınırına (rate-limit) tabi tutar. Bir sıçramada başlayıp sonraki tüm sıçramalarda devam eden kayıp ise gerçek bir kayıptır.

curl -sS -o /dev/null -w 'dns=%{time_namelookup} connect=%{time_connect} tls=%{time_appconnect} ttfb=%{time_starttransfer} total=%{time_total}\n' https://your-server.example.com/

Her alan, isteğin başlamasından itibaren geçen kümülatif saniyeleri gösterir, bu nedenle değerleri çıkarma işlemi yaparak okumalısınız. time_namelookup DNS süresidir. time_connect değerinden bunun çıkarılması, yaklaşık bir gidiş-dönüş süresi olan TCP el sıkışmasını verir. time_appconnect eksi time_connect, TLS el sıkışmasıdır. time_starttransfer eksi time_appconnect ise uygulamanızın kendi işlem süresi ile bir gidiş-dönüş süresinin toplamıdır. Aradaki farklar küçükse ve total hala büyükse, sorun şehrin ağ yapısında değil, kodunuzdadır.

Gecikme yerine bant genişliğini ölçmek için VPS üzerinde iperf3 -s komutunu çalıştırın, güvenlik duvarında ilgili portu açın ve indirme yönünü test etmek için istemci tarafında iperf3 -c your-server.example.com -R komutunu kullanın. Bir makinenizin bulunmadığı konumlardan ölçüm yapmak için RIPE Atlas size Avrupa genelinde problar sağlar. İki sunucuyu karşılaştırırken tek seferlik sayılar yerine sabit bir yöntem kullanın; tekrarlanabilir bir VPS kıyaslaması bunun içindir.

Frankfurt'taki bir sunucu projemi GDPR uyumlu hale getirir mi?

Hayır; bunun nedenini net bir şekilde ifade etmek gerekir. GDPR (Genel Veri Koruma Tüzüğü), donanımın hangi ülkede bulunduğuna değil, kimin kişisel verilerini işlediğinize ve kuruluşunuzun nerede kurulduğuna göre uygulanır. Bir sunucuyu Frankfurt'a taşımak uyumluluk sağlamaz; AB dışında bir sunucu çalıştırmak da otomatik olarak uyumluluğu bozmaz. Konum, dikkate alınması gereken birçok faktörden yalnızca biridir.

AB veya daha geniş kapsamlı AEA (Avrupa Ekonomik Alanı) içinde barındırma yapmanın ortadan kaldırdığı tek konu, uluslararası veri aktarımı sorunudur. Tüzük, kişisel verilerin AEA dışına gönderilmesiyle ilgili, yeterlilik kararı veya standart sözleşme maddeleri gibi yasal bir araç gerektiren kapsamlı bir bölüme sahiptir. Frankfurt'ta kalan veriler aktarılmadığı için bu bölüm söz konusu veri trafiği için geçerli değildir. Bu, gerçek bir basitleştirmedir ve sağladığı faydanın dürüst tanımı budur.

Geriye kalan her şey sizin sorumluluğunuzdadır. Her işleme amacı için yasal bir dayanağa, veritabanınızdaki kişiler için çalışan erişim ve silme haklarına, fiilen uyguladığınız bir saklama süresi sınırına, riske uygun güvenlik önlemlerine ve bir kişisel veri ihlalinden haberdar olduktan sonra 72 saat içinde denetleyici makama yapılacak bir bildirime ihtiyacınız vardır. Ayrıca barındırma sağlayıcınızla, Almanya'da Auftragsverarbeitungsvertrag veya AVV olarak bilinen bir veri işleme sözleşmesi yapmanız gerekir. Frankfurt'taki bir sunucunun, AEA dışındaki destek personeli tarafından erişilebilmesi durumunda yine de bir veri aktarımı teşkil edebileceğini unutmayın; bu nedenle anahtarların kimde olduğunu kontrol edin.

Almanya, tüzüğün üzerine kendi katmanını ekler: Federal BDSG (Bundesdatenschutzgesetz), tüzüğü ulusal kurallarla destekler ve çalışan verileri, insanları en çok şaşırtan alandır. Bu bölüm genel bilgilendirme amaçlıdır, yasal tavsiye niteliği taşımaz. Avrupa Veri Koruma Kurulu, resmi kılavuzları edpb.europa.eu adresinde yayımlamaktadır; gerçek sonuçları olan her konu, bir eğitim dokümanından ziyade nitelikli bir danışman gerektirir.

Sunucu üzerinde neleri değiştirmeliyim?

Sistem saatini UTC (Coordinated Universal Time) üzerinde tutun ve zaman damgalarını uygulamanızda biçimlendirin. Almanya'da yaz saati uygulaması geçerlidir; bu nedenle yerel saat yılda iki kez bir saat değişir ve Ekim ayı sonlarında bir saatlik dilim tekrarlanır. Yerel saatle yazılan günlük kayıtları o gece iki adet 02:30 girişi içerir ve bu kayıtları bölgeler arasında ilişkilendirmek tahmin yürütmeye dönüşür. Yine de sunucuda yerel saat kullanmak istiyorsanız, bunu açıkça ayarlayın ve kontrol edin:

sudo timedatectl set-timezone Europe/Berlin
timedatectl

Çıktı yazın Time zone: Europe/Berlin (CEST, +0200), kışın ise +0100 değerini göstermelidir.

Almanca metinler, varsayılan C yerel ayarı altında yanlış sıralanır çünkü C sıralaması ham baytları karşılaştırır. Yerel ayarı oluşturun ve farkı gözlemleyin:

sudo locale-gen de_DE.UTF-8
sudo update-locale
printf 'Zebra\nÄpfel\nApfel\n' | LC_ALL=C sort
printf 'Zebra\nÄpfel\nApfel\n' | LC_ALL=de_DE.UTF-8 sort

İlk sıralama, UTF-8'deki ilk baytı herhangi bir ASCII harfinden daha yüksek olduğu için Äpfel değerini Zebra değerinden sonraya koyar. İkinci sıralama ise onu, bir Alman okuyucunun beklediği yer olan Apfel yanına yerleştirir. PostgreSQL ve MySQL veritabanı oluşturulduğunda bir harmanlama (collation) belirlediği ve bunu daha sonra değiştirmenin indekslerin yeniden oluşturulması anlamına geldiği göz önüne alındığında, bu durum göründüğünden daha önemlidir. Verileri yüklemeden önce kararınızı verin.

Alman paket yansıması apt işlemlerini hızlandırır. Ubuntu 24.04 üzerinde kaynaklar /etc/apt/sources.list.d/ubuntu.sources dizininde deb822 formatında bulunur; bu nedenle ikinci bir dosya eklemek yerine URIs: satırını http://de.archive.ubuntu.com/ubuntu/ olarak değiştirin. Bir tane daha eklemek Target Packages ... is configured multiple times hatasına, yani deb822 yinelenen kaynak hatası durumuna yol açar ve siz çözene kadar güncellemeleri durdurur.

Bir AAAA kaydı yayınlayın. Bazı Alman İSS'leri, tüketici bağlantılarına DS-Lite (dual-stack lite) kurulumu sağlar; bu durumda müşterinin hiçbir genel IPv4 adresi yoktur ve IPv4 trafiği operatörün çeviri ağ geçidinden geçer. Bu ağ geçidi gecikme ekler ve yoğun saatlerde tıkanır; IPv6 trafiği ise doğrudan dışarı çıkar. Kaydı ayarladıktan sonra her iki yolu da kontrol edin:

dig AAAA your-server.example.com +short
curl -6 -sS -o /dev/null -w '%{http_code}\n' https://your-server.example.com/

İkinci komuttan gelen bir 200 yanıtı, IPv6'nın uçtan uca çalıştığı anlamına gelir. Could not resolve host veya bir bağlantı hatası, kaydın veya dinleyicinin eksik olduğunu ve DS-Lite ziyaretçilerinizin yavaş yolu kullandığını gösterir.

Frankfurt'un yanlış tercih olduğu durumlar

• Kullanıcılarınız Amerika Birleşik Devletleri'nde bulunuyorsa, onlara oradan hizmet verin: Dallas'taki bir VPS ülkenin merkezine yakındır ve New York'taki VPS barındırma hizmeti, hem doğu yakası hem de zaten Atlantik'i aşan trafik için daha kısa bir yoldur.
• Kullanıcılarınız Latin Amerika'daysa, Frankfurt'un São Paulo'ya olan uzaklığı New York'tan daha fazladır; bu nedenle bu kitle için en doğru seçenek Brezilya'daki bir VPS olacaktır.
• Verilerinizin AB dışındaki belirli bir ülkede kalması gerekiyorsa, Kanada kamu sektörü çalışmaları bunun yaygın bir örneğidir ve Kanada VPS barındırma için gerçekte önemli olanlar konusu bu bölgedeki yerleşiklik durumunu ele alır.
• Bir oyun sunucusu çalıştırıyorsanız, oyuncular gidiş-dönüş süresindeki her milisaniyeyi hisseder; bu nedenle oyunculara yakınlık diğer tüm teknik özelliklerden daha önemlidir: oyun sunucuları için VPS seçimi bu süreci detaylandırır.

Birden fazla ülkeye yayılmış bir Avrupa kitlesi için Frankfurt güvenli ve tek tercihtir; ulaşmanız gereken ağlar zaten değişim noktasında (exchange) bulunduğundan, büyüdükçe de güvenli kalmaya devam eder. Taşınmadan önce ve taşındıktan sonra kullanıcılarınızın bulunduğu konumdan ölçüm yapın ve her iki veri setini de saklayın.

FAQ

Avrupa'nın tamamı için Frankfurt'ta tek bir VPS yeterli mi?

Çoğu proje için evet. Kuş uçuşu mesafe, Stockholm için 12.0 ms ve Madrid için 14.2 ms gibi bir alt sınır belirler. Gerçek ağ yolları bu sınırın yaklaşık 1,5 ila 2 katı kadar gecikme üretir; bu nedenle AB'nin neredeyse tamamı, Frankfurt'taki tek bir sunucuya düşük onlu milisaniyeler seviyesinde erişebilir. İkinci bir lokasyonu, belirli bir ülkeden gelen somut bir şikayeti ölçümlediğinizde veya hızdan ziyade yedeklilik (failover) ihtiyacınız olduğunda ekleyin.

Frankfurt'ta barındırma yapmak projemi GDPR uyumlu hale getirir mi?

Hayır. GDPR, kişisel verilerini işlediğiniz kişilere ve sizin nerede kurulduğunuza göre uygulanır; sunucunun nerede olduğuna göre değil. Verileri AB içinde barındırmak, o aşama için uluslararası veri aktarımı sorununu ortadan kaldırır; bu gerçek bir kolaylaştırmadır ve sağladığı tek fayda budur. Yine de yasal bir dayanağa, işleyen veri sahibi haklarına, saklama süresi sınırına, güvenlik önlemlerine, 72 saat içinde ihlal bildirimine ve sağlayıcınızla yapılmış, Almanya'da AVV olarak adlandırılan bir veri işleme sözleşmesine ihtiyacınız vardır. Bu bilgiler genel bilgilendirme amaçlıdır, hukuki tavsiye niteliği taşımaz.

Frankfurt ile Berlin arasında ne kadar gecikme beklemeliyim?

İki şehir arasındaki mesafe 424 km'dir ve bu durum 4.2 ms'lik bir gidiş-dönüş süresi (RTT) alt sınırı belirler. İyi eşlenmiş (well-peered) bir yol, genellikle bu sınırın 1,5 ila 2 katı değer üretir. Bunu Berlin'deki bir bağlantıdan ping -c 20 your-server.example.com ile doğrulayın ve rtt min/avg/max/mdev satırındaki avg değerini okuyun. Bu aralığın çok üzerindeki bir sonuç, genellikle trafiğin Almanya dışına çıkıp geri döndüğü anlamına gelir; bunu mtr -rwzc 50 ile atlama (hop) isimlerinde görebilirsiniz.

Frankfurt sunucumun saat dilimini Europe/Berlin olarak ayarlamalı mıyım?

Genellikle hayır. Logların karşılaştırılabilir kalması ve zaman damgalarının belirsizleşmemesi için sistemi UTC'de tutun. Almanya ilkbaharda CEST'e, sonbaharda ise CET'e geçer. Sonbahardaki geçiş gecesinde yerel bir saat dilimi iki kez yaşanır; bu da iki farklı olayın aynı yerel zaman damgasına sahip olmasına neden olabilir. Zamanları, doğru şekilde yapabilmek için bağlama sahip olduğunuz uygulama katmanında yerel saat dilimine göre biçimlendirin. Eğer sunucunun tamamını yerel saate göre ayarlamak isterseniz, sudo timedatectl set-timezone Europe/Berlin komutunu çalıştırın ve timedatectl ile doğrulayın.

Sadece IPv4 destekleyen bir sunucu Alman ziyaretçiler için sorun yaratır mı?

Çalışacaktır, ancak bazı kullanıcılar için daha yavaş olacaktır. Birçok Alman İSS, tüketici bağlantılarına genel IPv4 adresi olmayan bir DS-Lite kurulumu sağlar. Bu müşteriler, IPv4-sadece sunuculara operatörün çeviri ağ geçidi üzerinden ulaşır; bu da gecikmeyi artırır ve yoğun saatlerde tıkanıklığa yol açar. Bir AAAA kaydı yayınlamak ve IPv6 üzerinden dinleme yapmak, onlara doğrudan bir yol sağlar. Bunu dig AAAA your-server.example.com +short ve bir curl -6 isteği ile test edin; her iki adres ailesinden de HTTP 200 yanıtı almayı bekleyin.