Sunucu Lokasyonu Seçimi: Türkiye mi Yurt Dışı mı?

Yazar:komut.io ekibi Rehber & İpuçları
0 Yorum

Yıllar önce bir müşterimizin sunucusu Almanya’daydı. E-ticaret sitesi, Türkiye’ye hizmet veriyor, ama sunucu Frankfurt’ta. “Neden?” diye sorduğumda aldığım cevap “Daha ucuz ve daha güvenilir” oldu. Yanlış değildi, ama eksikti. O günden bu yana onlarca farklı senaryo gördüm ve şunu söyleyebilirim: doğru lokasyon seçimi, bant genişliği fiyatından çok daha karmaşık bir denklem.

Bu yazıda teknik, hukuki ve operasyonel açılardan sunucu lokasyonu kararını ele alacağız. Hem Türkiye’deki hem yurt dışındaki seçeneklerin gerçek artılarını ve eksiklerini konuşacağız, teoride değil pratikte.

Gecikme (Latency) Meselesi: Rakamlar Yalan Söylemez

İlk ve en somut kriter gecikme süresi. Ama burada çoğu sysadmin bir hata yapıyor: sadece ping süresine bakıyorlar.

# Basit ping testi - yetersiz ama başlangıç noktası
ping -c 20 sunucu-ip-adresi

# Daha anlamlı: MTR ile paket kaybı ve hop analizi
mtr --report --report-cycles 100 sunucu-ip-adresi

# Birden fazla noktadan test için
for host in tr-datacenter.example.com de-datacenter.example.com; do
    echo "=== $host ==="
    ping -c 10 $host | tail -2
done

Türkiye’deki bir kullanıcıdan İstanbul’daki sunucuya ortalama gecikme 5-15ms civarında. Aynı kullanıcıdan Frankfurt’a bakarsanız 40-60ms, Amsterdam’a 45-65ms görürsünüz. Rakamlar küçük görünüyor ama uygulamanıza göre fark devasa olabiliyor.

Bir fintech uygulaması üzerinde çalışırken fark ettiğimiz şuydu: her API çağrısında ek 50ms, kullanıcı deneyimini ciddi ölçüde etkiliyor. Özellikle mobil uygulamalarda, bir sayfa açılışında 5-6 API çağrısı yapılıyorsa bu 250-300ms ekstra demek. Kullanıcılar bunu hissediyor.

# Uygulama seviyesinde gecikme testi - HTTP response time ölçümü
curl -o /dev/null -s -w "DNS: %{time_namelookup}s | Connect: %{time_connect}s | TTFB: %{time_starttransfer}s | Total: %{time_total}sn" 
  https://api.orneksite.com/health

# Birden fazla lokasyondan simüle etmek için
for i in {1..20}; do
    curl -o /dev/null -s -w "%{time_total}n" https://api.orneksite.com/health
done | awk '{sum+=$1; count++} END {print "Ortalama: " sum/count "s"}'

Bununla birlikte, eğer kullanıcı kitleniz küresel ise Türkiye’deki bir sunucu yurt dışındaki kullanıcılara kötü deneyim yaşatır. Burada CDN devreye giriyor, ama CDN her şeyin çözümü değil.

Türkiye’deki Veri Merkezi Altyapısı: Dürüst Bir Değerlendirme

Türkiye’deki veri merkezi altyapısı son 5-6 yılda ciddi gelişme gösterdi. İstanbul, Ankara ve İzmir’de Tier 3 sertifikalı merkezler var artık. Ama yine de bazı gerçekleri konuşmak gerekiyor.

Bant genişliği maliyetleri: Türkiye’de trafik maliyeti hâlâ yurt dışına kıyasla daha yüksek. Özellikle büyük hacimli trafik için bu fark belirgin.

Peering kalitesi: Türk operatörler arasındaki peering son yıllarda iyileşti, ama uluslararası bağlantı kalitesiyle kıyaslandığında hâlâ zaman zaman sorun çıkabiliyor.

Fiyatlandırma: Aynı spesifikasyonda bir sunucu için Türkiye’de ödediğiniz fiyat, Avrupa’daki birçok sağlayıcıdan yüksek olabiliyor. Bu paradoksal görünse de altyapı yatırım maliyetleri ve operasyonel giderler buna yol açıyor.

# Türkiye'deki ve yurt dışındaki sunucular arasında traceroute karşılaştırması
traceroute -n 8.8.8.8  # Google DNS üzerinden uluslararası rota

# Türk ISP'ler arasındaki peering kalitesini test etmek için
traceroute -n turk-isp-ip-adresi

# Bağlantı stabilitesi için uzun süreli izleme
ping -i 0.5 -c 1000 hedef-ip | grep -E "loss|rtt"

KVKK ve Veri Yerelliliği: Artık Görmezden Gelemezsiniz

İşte burada işler karmaşıklaşıyor. Türk kullanıcıların kişisel verilerini işliyorsanız, KVKK (Kişisel Verilerin Korunması Kanunu) size belirli yükümlülükler getiriyor.

Veri yurt dışına aktarımı şartları:

  • İlgili kişinin açık rızası alınmalı
  • Aktarılacak ülkenin yeterli koruma sağladığına dair Kurul kararı bulunmalı
  • Yeterli korumanın bulunmadığı durumlarda taahhütname mekanizması kullanılmalı

Pratikte bu ne anlama geliyor? Eğer bir sağlık uygulaması, fintech uygulaması veya büyük ölçekli bir e-ticaret platformu işletiyorsanız, kullanıcı verilerini Türkiye’de tutmak hem hukuki riski azaltıyor hem de Kurul denetimleri sırasında sizi koruyuyor.

# Sunucunuzun hangi ülkede olduğunu ve veri akışlarını analiz etmek için
# (Bu komutları Türkiye'deki sunucunuzda çalıştırın)
ss -tunap | grep ESTABLISHED | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -rn | head -20

# Dışarı çıkan bağlantıların coğrafi dağılımı için (geoip-bin kurulu olmalı)
ss -tunap | grep ESTABLISHED | awk '{print $5}' | cut -d: -f1 | while read ip; do
    geoiplookup "$ip" 2>/dev/null | grep "Country"
done | sort | uniq -c | sort -rn

Kurumsal projeler için hukuk danışmanlığı almak şart. Ben burada teknik gerçekleri paylaşıyorum, hukuki yorum yapmıyorum.

Pratik Senaryo Analizleri

Senaryo 1: Türkiye’ye Hizmet Veren E-Ticaret

Bu en sık karşılaştığım durum. Müşteri kitlesi yüzde 95 Türkiye, ortalama sipariş değeri 200-500 TL arası, günlük 50.000-100.000 ziyaretçi.

Öneri: Türkiye + CDN hibrit yaklaşım

Statik içerikler (resimler, CSS, JS) için Cloudflare veya benzeri bir CDN kullanın. Dinamik içerik ve veritabanı için Türkiye’deki bir sunucu tercih edin. Bu şekilde hem KVKK uyumluluğunu sağlarsınız hem de yerel gecikme avantajından yararlanırsınız.

# CDN bypass testi - gerçek sunucuya mı CDN'e mi gidiyorsunuz?
curl -I https://www.orneksite.com | grep -E "server|cf-ray|x-cache"

# CDN cache hit oranını kontrol etmek için
curl -s -o /dev/null -w "%{http_code} - Cache: %{header.x-cache}n" https://cdn.orneksite.com/resim.jpg

# Origin sunucuya direkt bağlantı testi (CDN'i bypass ederek)
curl --resolve "orneksite.com:443:ORIGIN-IP" https://orneksite.com/ -o /dev/null -s -w "%{time_total}n"

Senaryo 2: SaaS Ürün – Hem Türkiye Hem Yurt Dışı Müşteri

Bu daha ilginç. Hem Türkiye’de hem Avrupa’da müşteriniz var, GDPR ve KVKK’ya aynı anda uymak zorundasınız.

Bu durumda multi-region deployment kaçınılmaz oluyor. Masraflı mı? Evet. Ama alternatifi iki farklı hukuki sistemle uğraşmak ve veri ihlali riskini taşımak.

# Çoklu bölge sağlık kontrolü scripti
#!/bin/bash

REGIONS=("tr-istanbul.api.orneksite.com" "eu-frankfurt.api.orneksite.com")
THRESHOLD_MS=200

for region in "${REGIONS[@]}"; do
    response_time=$(curl -o /dev/null -s -w "%{time_total}" "https://$region/health")
    response_ms=$(echo "$response_time * 1000" | bc | cut -d. -f1)
    
    if [ "$response_ms" -gt "$THRESHOLD_MS" ]; then
        echo "UYARI: $region - ${response_ms}ms (eşik: ${THRESHOLD_MS}ms)"
    else
        echo "OK: $region - ${response_ms}ms"
    fi
done

Senaryo 3: Oyun Sunucusu veya Gerçek Zamanlı Uygulama

Oyun sunucuları ve gerçek zamanlı uygulamalar (canlı yayın altyapısı, sesli/görüntülü iletişim) için gecikme her şeyden önce gelir.

Türkiye kaynaklı bir oyun için Türkiye veya yakın Avrupa (Frankfurt, Polonya) tercih edilmeli. 100ms üzeri gecikme oyun deneyimini mahveder.

# UDP tabanlı gecikme testi (TCP'den farklı davranır)
# hping3 kurulu olmalı
hping3 -S -p 27015 -c 20 oyun-sunucusu-ip

# Jitter (gecikme varyasyonu) ölçümü - oyunlarda kritik
ping -c 100 sunucu-ip | awk -F'/' 'END{print "Ortalama:", $5, "ms | Mdev (jitter):", $7, "ms"}'

# Paket kaybı simülasyonu ve etkisi
ping -c 1000 sunucu-ip | tail -2

Felaket Kurtarma ve Yedeklilik Perspektifinden Lokasyon

Tüm altyapıyı tek lokasyona koymak, lokasyon seçiminden bağımsız olarak zaten yanlış. Peki lokasyon seçimi DR (Disaster Recovery) stratejinizi nasıl etkiliyor?

Türkiye’deki riskleri dürüstçe değerlendirmek gerekiyor: deprem riski var, bu bir gerçek. İstanbul özelinde büyük bir sismik risk taşıyan bir coğrafyada veri merkezi işletmek, DR planını zorunlu kılıyor.

Yurt dışı riskleri de var tabii: Avrupa’da sel ve fırtına kaynaklı kesintiler yaşandı. AWS, Azure gibi devlerin bile bölgesel kesintileri oldu.

Çözüm, iki lokasyon arasında aktif-pasif veya aktif-aktif replikasyon kurmak.

# PostgreSQL streaming replication durumunu kontrol etmek için
# (Primary sunucuda çalıştırın)
psql -U postgres -c "SELECT client_addr, state, sent_lsn, write_lsn, flush_lsn, replay_lsn, 
    (sent_lsn - replay_lsn) AS replication_lag 
    FROM pg_stat_replication;"

# Replikasyon gecikmesini byte olarak görmek
psql -U postgres -c "SELECT pg_wal_lsn_diff(pg_current_wal_lsn(), replay_lsn) AS lag_bytes 
    FROM pg_stat_replication;"

# MySQL/MariaDB replikasyon durumu
mysql -u root -p -e "SHOW SLAVE STATUSG" | grep -E "Seconds_Behind_Master|Running|Error"

Önemli bir gerçek: İki lokasyon arasındaki mesafe arttıkça replikasyon gecikmesi artıyor. İstanbul-Frankfurt arası replikasyon, İstanbul-Ankara arasına kıyasla daha yüksek gecikme yaşatır. Bunu veritabanı tasarımında göz önünde bulundurmanız gerekiyor.

Maliyet Analizi: TL Bazında Düşünmek

Döviz kuru meselesi son derece pratik bir sorun. Yurt dışında sunucu kiralarken USD veya EUR ödersiniz. Türkiye’de genellikle TL (bazen USD’ye endeksli TL).

Şunu söyleyeyim: 2018’den bu yana kur hareketlerini yaşayan bir sysadmin olarak, yurt dışı sunucu maliyetlerinin TL bazında nasıl patladığını bizzat gördüm. Bütçe planlaması açısından bu büyük bir risk.

# Aylık maliyet takibi için basit bir script
#!/bin/bash
# Sunucu maliyet ve kaynak kullanımı raporu

echo "=== Sunucu Kaynak Kullanım Raporu ==="
echo "Tarih: $(date)"
echo ""

# CPU kullanımı (son 1 dakika ortalaması)
cpu_usage=$(top -bn1 | grep "Cpu(s)" | awk '{print $2}' | cut -d. -f1)
echo "CPU Kullanimi: %$cpu_usage"

# RAM kullanımı
mem_total=$(free -m | awk '/^Mem:/{print $2}')
mem_used=$(free -m | awk '/^Mem:/{print $3}')
mem_percent=$((mem_used * 100 / mem_total))
echo "RAM Kullanimi: ${mem_used}MB / ${mem_total}MB (%$mem_percent)"

# Disk I/O
echo "Disk IO:"
iostat -x 1 1 | grep -E "^sd|^nvme" | awk '{print "  "$1": okuma="$4"KB/s yazma="$5"KB/s"}'

# Ağ trafiği (aylık toplam)
echo "Network:"
cat /proc/net/dev | grep -E "eth0|ens|bond" | awk '{print "  "$1" - RX: "$2" bytes, TX: "$10" bytes"}'

Maliyet kararında göz önünde bulundurulması gerekenler:

  • Kur riski: USD/EUR bazlı maliyetin uzun vadeli TL karşılığı ne olabilir?
  • Gizli maliyetler: Egress (çıkış) trafiği maliyeti, IP adresi maliyeti, destek planı
  • Ölçekleme maliyeti: Türkiye’deki sağlayıcıların ölçekleme kapasitesi yeterli mi?
  • Ödeme kolaylığı: Yurt dışı sağlayıcılara ödeme yaparken döviz transferi ve komisyon maliyetleri

Teknik Destek ve Operasyonel Kolaylık

Bu genellikle göz ardı edilen ama kritik bir faktör. Gece 3’te sunucu çöktüğünde destek alabilmek için aynı zaman diliminde operasyon ekibi olması büyük avantaj.

Türkiye’deki sağlayıcıların teknik destek ekipleri Türkçe konuşuyor, yerel saatlerde çalışıyor. AWS, Azure, Google Cloud gibi devlerin Türkçe desteği var ama yerel sağlayıcılar kadar hızlı değil.

# Sunucu durumunu izlemek ve anında uyarı almak için basit bir healthcheck scripti
#!/bin/bash

WEBHOOK_URL="https://hooks.slack.com/services/XXXXX"  # veya Telegram bot
SUNUCU_ADI=$(hostname)
ESIK_CPU=90
ESIK_RAM=85
ESIK_DISK=90

# CPU kontrolü
cpu=$(top -bn1 | grep "Cpu(s)" | awk '{print $2}' | cut -d. -f1)
if [ "$cpu" -gt "$ESIK_CPU" ]; then
    mesaj="KRITIK: $SUNUCU_ADI - CPU kullanimi %$cpu (esik: %$ESIK_CPU)"
    curl -s -X POST -H 'Content-type: application/json' 
        --data "{"text":"$mesaj"}" "$WEBHOOK_URL"
fi

# RAM kontrolü
ram=$(free | awk '/^Mem:/{printf "%.0f", $3/$2*100}')
if [ "$ram" -gt "$ESIK_RAM" ]; then
    mesaj="KRITIK: $SUNUCU_ADI - RAM kullanimi %$ram (esik: %$ESIK_RAM)"
    curl -s -X POST -H 'Content-type: application/json' 
        --data "{"text":"$mesaj"}" "$WEBHOOK_URL"
fi

# Disk kontrolü
disk=$(df / | awk 'NR==2{print $5}' | tr -d '%')
if [ "$disk" -gt "$ESIK_DISK" ]; then
    mesaj="KRITIK: $SUNUCU_ADI - Disk kullanimi %$disk (esik: %$ESIK_DISK)"
    curl -s -X POST -H 'Content-type: application/json' 
        --data "{"text":"$mesaj"}" "$WEBHOOK_URL"
fi

DNS ve Akıllı Trafik Yönetimi

Lokasyon seçimini statik bir karar olarak görmemek gerekiyor. DNS tabanlı akıllı yönlendirme ile kullanıcıyı otomatik olarak en yakın sunucuya yönlendirebilirsiniz.

# DNS çözümleme testleri - farklı lokasyonlardan nasıl görünüyor?
# dig ile authoritative nameserver'dan sorgu
dig +short orneksite.com @8.8.8.8
dig +short orneksite.com @1.1.1.1

# TTL kontrolü - DNS değişikliklerinin ne kadar sürede yayıldığını anlamak için
dig orneksite.com | grep -E "ANSWER|TTL"

# GeoDNS çalışıyor mu test etmek için farklı resolver'lar kullanın
for resolver in 8.8.8.8 1.1.1.1 208.67.222.222 94.140.14.14; do
    echo -n "Resolver $resolver: "
    dig +short orneksite.com @$resolver
done

Route 53, Cloudflare veya benzeri servislerle latency-based routing kurabilirsiniz. Türkiye’deki kullanıcı Türkiye sunucusuna, Avrupa’daki kullanıcı Frankfurt sunucusuna düşer. Bu hibrit yaklaşım, her iki dünyanın en iyi yönlerini almanızı sağlar.

Bulut mu, Bare Metal mi, VPS mi?

Lokasyon seçimiyle bağlantılı ama ayrı bir karar daha var: altyapı modeli.

Türkiye’deki seçenekler:

  • Yerli bulut sağlayıcılar (Turkcell, Bulutistan, vb.): KVKK uyumluluğu açısından avantajlı, API’ları ve hizmet çeşitliliği henüz AWS/Azure seviyesinde değil
  • Kolokasvon: Kendi donanımınızı yerli veri merkezinde barındırırsınız. Büyük ölçekli yapılar için anlamlı
  • Bare metal kiralama: Yerli sağlayıcılarda dedicated sunucu, paylaşımlı kaynak yok

Yurt dışındaki seçenekler:

  • AWS/Azure/GCP: Servis çeşitliliği muazzam, ölçekleme kolay, ama KVKK uyumluluğu için ek çalışma gerekiyor
  • Hetzner, OVH gibi Avrupa sağlayıcıları: Fiyat/performans dengesi çok iyi, GDPR uyumlu, Türk firmaları için yaygın tercih
  • DigitalOcean, Vultr, Linode: Geliştirici dostu, küçük/orta ölçek için ideal
# Sunucu benchmark - yeni aldığınız sunucuyu test etmek için
# sysbench kurulu olmalı

# CPU testi
sysbench cpu --cpu-max-prime=20000 --threads=4 run | grep "events per second"

# Disk I/O testi
sysbench fileio --file-total-size=4G prepare
sysbench fileio --file-total-size=4G --file-test-mode=rndrw --time=60 --threads=4 run | grep -E "reads|writes|throughput"
sysbench fileio --file-total-size=4G cleanup

# Ağ testi için iperf3
# Sunucuda: iperf3 -s
# İstemcide:
iperf3 -c sunucu-ip -t 30 -P 4 | tail -4

Sonuç

Sunucu lokasyonu seçimi, tek bir doğru cevabı olmayan bir mühendislik kararıdır. Ama şunu söyleyebilirim: sırf moda olduğu için yurt dışını ya da sırf yerlilik adına Türkiye’yi seçmek yanlış.

Karar matrisiniz şu faktörler üzerine kurulmalı:

  • Kullanıcı kitlenizin coğrafyası belirleyici. Büyük çoğunluk Türkiye’deyse, Türkiye sunucusu genellikle avantajlıdır.
  • İşlediğiniz veri türü KVKK kapsamındaysa ve yurt dışına aktarım için gerekli şartları sağlamıyorsanız, Türkiye mecburiyet haline gelir.
  • Bütçe ve kur riski toleransınız yurt dışı seçeneklerde göz ardı edilemez.
  • DR ve yedeklilik stratejiniz tek lokasyona bağlı kalmayı zaten imkansız kılıyor; iyi bir DR planı, lokasyon sorusunu biraz daha ikincil hale getirir.
  • Ölçeklenme ihtiyaçlarınız yurt dışı bulut sağlayıcılar lehine önemli bir argüman sunuyor.

Çoğu Türkiye odaklı proje için gerçekçi ve sağlam yaklaşım şu: birincil sunucular Türkiye’de, CDN küresel, yedekleme ve DR yurt dışında. Ne saf bir “her şey yurt dışında” ne de saf bir “her şey Türkiye’de” yaklaşımı.

Son olarak şunu ekleyeyim: bu kararı bir kez verip unutmayın. Altyapınız büyüdükçe, kullanıcı kitleniz değiştikçe ve hukuki düzenlemeler evriştikçe lokasyon stratejinizi gözden geçirmeniz gerekiyor. Altı ayda bir lokasyon kararınızı değerlendirme gündemine alın.

Bir yanıt yazın

E-posta adresiniz yayınlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir