Yurtdışı VPS Ne Zaman Gerekir? Bölge Seçimi, IP İtibarı ve Taşıma Planı
Yurtdışı VPS kiralamak çoğu zaman bir ülke adı seçmekle başlar. Oysa doğru başlangıç noktası kendi trafik verinizdir. Ziyaretçiler hangi ülkeden geliyor, siparişler nereden düşüyor, uygulamanız hangi yabancı servislerle konuşuyor? Bu soruların cevabı bazen Batı Avrupa'da bir sanal sunucuyu, bazen de hiç yerinizden kıpırdamamayı gösterir. Karar verildikten sonra da iş bitmiyor. Sanal sunucuda uluslararası hat komşularla paylaşılır, size verilen IP adresi sizden önce kötü bir sicil edinmiş olabilir, Türkiye'deki kişilerin verisi sınırı geçtiği anda da KVKK'nın aktarım kuralları devreye girer. Bunların çoğu teklif aşamasında sorulabilir, bir kısmı da teslimden sonraki ilk saatte ölçülebilir.
Yurtdışı VPS'e gerçekten ihtiyacınız var mı?
Çoğu zaman yok. Bunu bir sağlayıcı olarak söylemek tuhaf gelebilir, ama yanlış ülkeye kurulmuş bir sunucunun bedelini her gün, her istekte ödersiniz.
Hesap basit. İstanbul içinde ölçülen gecikme yaklaşık 10 ms, Batı Avrupa lokasyonlarında 40–55 ms. Yeni bir HTTPS bağlantısında tarayıcı ilk bayta ulaşana kadar en az üç gidiş-dönüş harcar (TCP el sıkışması, TLS 1.3 el sıkışması ve isteğin kendisi). Ziyaretçisi Türkiye'de olan bir siteyi Batı Avrupa'ya taşıdığınızda, sayfa daha üretilmeye başlamadan ilk yanıta 90–135 ms eklenir. Sepet, arama, oturum açma gibi önbelleği atlayan her dinamik istek bu farkı yeniden öder. Gecikmenin sayfa açılışında nasıl biriktiğini sunucu lokasyonunun site hızına etkisini ölçtüğümüz yazıda ayrıntısıyla gösterdik.
Tipik senaryoları yan yana koyunca tablo şöyle çıkıyor.
| Senaryo | Yurt dışı lokasyon gerekir mi? | Neden |
|---|---|---|
| Ziyaretçilerin büyük kısmı Türkiye'de, içerik Türkçe | Gerekmez | Her istek 30–45 ms daha uzun yoldan gider, karşılığında bir şey kazanılmaz |
| Kitle ağırlıklı olarak Avrupa'da, sayfalar dinamik | Genellikle evet | CDN statik dosyaları taşır, oturum ve sepet istekleri yine kaynak sunucuya gider |
| Kitle dağınık, içerik çoğunlukla statik | Çoğu zaman hayır | İstekler CDN'in kenar sunucularında karşılanır, kaynak sunucunun yeri ikinci planda kalır |
| Bir servis yalnız belirli ülke IP'lerine açık | Evet | Erişim, adresin GeoIP veritabanlarında göründüğü ülkeye bağlı |
| Uygulama gün boyu yabancı bir API ile konuşuyor | Ölçmeye değer | Sayfa başına çağrı sayısı arttıkça gidiş-dönüş farkı katlanır |
| Ana sistem Türkiye'de, ikinci ülkede yedek isteniyor | Duruma göre | Yalnız veri kopyası için depolama yetebilir, bekleme sunucusu isteniyorsa VPS mantıklı |
| "Yurt dışı daha ucuz" düşüncesi | Tek başına gerekçe değil | Kur, kart komisyonu ve vergi yükü eklenince fark sanıldığı kadar büyük çıkmayabilir |
| Arama motorunda yabancı pazara açılmak | Tek başına gerekçe değil | Ülke hedeflemesinde alan adı uzantısı, hreflang ve içerik dili öne geçer |
İlk satırdaysanız Türkiye lokasyonlu VPS sanal sunucu seçenekleri size daha düşük gecikme verir, boyutlandırma ve ilk gün sertleştirmesi de o sayfadaki rehberde anlatılıyor. "Evet" satırlarından birindeyseniz asıl iş bölgeyi doğru seçmek.
Bölge kararını verinize bırakın
Diyelim ki Google Analytics 4 raporunuz ziyaretçilerin %70'inin Türkiye'den, %30'unun Almanya'dan geldiğini söylüyor. Sunucu İstanbul'da kalırsa ek gecikmeyi kullanıcıların %30'u öder. Batı Avrupa'ya taşınırsa bu kez %70'i öder. Gecikme iki yönde de aşağı yukarı aynıdır. Yani asıl soru, ek yükü hangi gruba bindirmeyi göze aldığınız.
Oturum sayısı tek başına yanıltır. Aynı raporda dönüşüm ve gelir kırılımına da bakın, çünkü trafiğin %30'unu oluşturan pazar siparişlerin yarısını getiriyorsa tablo tamamen değişir. GA4'te ülke dağılımı kullanıcı özellikleri altındaki demografik raporda durur, ama iki eksiği var. Çerez onayı vermeyen ziyaretçiler raporda ya hiç görünmez ya da modellenmiş bir tahminle görünür, filtrelenmemiş bot trafiği de bazı ülkeleri olduğundan kalabalık gösterdiği için rakamları olduğu gibi kabul etmeyin. Search Console'un Performans raporundaki Ülkeler sekmesi, en azından arama tarafında, ikinci bir sağlama işi görür.
Sunucu tarafındaki kayıtlar daha dürüsttür. JavaScript çalışmasa da istek loga düşer. Cloudflare arkasındaysanız panel ülke dağılımını zaten gösterir ve her isteğe ziyaretçinin ülke kodunu taşıyan CF-IPCountry başlığını ekler, bu başlığı nginx log biçimine yazdırdığınızda aynı dağılımı kendi kayıtlarınızdan da çıkarabilirsiniz. CDN kullanmıyorsanız nginx'in GeoIP2 modülüyle ya da GoAccess gibi bir log çözümleyiciyi bir GeoIP veritabanıyla besleyerek aynı tabloyu çıkarırsınız.
Burada bir parantez açalım. Görsel, CSS ve JavaScript isteklerini ayıklayın, yalnız dinamik isteklere bakın. CDN önbelleğinden dönen bir dosya kaynak sunucunun nerede durduğundan etkilenmez. Sizi ilgilendiren, önbelleği atlayıp sunucuya kadar gelen istektir.
Kaba bir kural isterseniz bizim önerimiz şu. Hedef bölge dinamik isteklerin ya da gelirin yarısını geçmiyorsa kaynak sunucuyu yerinde bırakın, o bölgedeki statik yükü önce CDN ile hafifletin. Yarısını geçiyorsa ya da hızla büyüyorsa taşımayı ciddi düşünün. Arada kalan durumlarda ölçmeden karar vermeyin.
Avrupa VPS mi, Amerika VPS mi?
Kısa cevap, kullanıcınız hangi kıtadaysa. Uzun cevap fizikle başlıyor. Işık fiberde saniyede yaklaşık 200.000 km yol alır, bu da her 100 km'lik hat için gidiş-dönüşte yaklaşık 1 ms demek. İstanbul ile Frankfurt arası kuş uçuşu 1.870 km kadar, teorik alt sınır 19 ms civarında. İstanbul ile New York arası yaklaşık 8.070 km ve alt sınır 80 ms'yi geçiyor. Los Angeles'a ise 11.000 km'den fazla yol var. Kablolar düz hat izlemediği ve paket yol boyunca pek çok yönlendiriciden geçtiği için gerçek ölçümler bu alt sınırların belirgin biçimde üzerinde çıkar.
Amerika VPS bu yüzden ancak kullanıcılarınız Amerika kıtasındaysa anlamlı. Türkiye'deki bir kitleye ABD'den hizmet vermek, Batı Avrupa'nın getirdiği farkın birkaç katını göze almak demek. ABD'nin kendi içindeki mesafe de küçümsenecek gibi değil, doğu ve batı kıyıları arasında yaklaşık 4.000 km var ve kitleniz kıtanın doğusunda yaşıyorsa batı kıyısındaki bir sunucu her istekte yine onlarca milisaniye kaybettirir.
Avrupa VPS tarafında seçim daha ince. Kıtanın internet trafiğinin önemli bir bölümü Frankfurt, Amsterdam ve Londra'daki büyük internet değişim noktalarında el değiştirir, bu şehirlerin çevresindeki veri merkezleri de pek çok ağa kısa yoldan ulaşır. Bu, internetin nasıl örüldüğüne dair genel bir bilgi, Netx'in ürün listesi değil. Hangi lokasyonu önerdiğimizi hedef bölgenize göre teklifte yazılı olarak bildiriyoruz. Kitleniz Türkiye ile ABD'nin doğusu arasında bölünmüşse Batı Avrupa bir orta nokta gibi görünebilir. Öyledir de, ama iki tarafa da yakın değildir. İstanbul'dan farklı hedeflere ölçtüğümüz gecikmeleri yurt dışı ile Türkiye lokasyonunu karşılaştırdığımız yazıda tablo halinde bulabilirsiniz.
Paylaşımlı makine, paylaşımlı hat
Fiziksel bir sunucuda ağ kartı tek bir müşteriye aittir. Yurtdışı sanal sunucuda öyle değil. Sanal makinenizin ağ arayüzü, KVM gibi bir hypervisor'ün yönettiği sanal bir köprü üzerinden ana makinenin fiziksel kartına bağlanır. O kart ve arkasındaki üst bağlantı (uplink), aynı makinedeki bütün sanal sunucular arasında paylaşılır. Katmanların nasıl dizildiğini KVM sanallaştırmanın çalışma mantığını anlattığımız yazıda bulabilirsiniz.
Türkiye'deki bir VPS'te bu paylaşım çoğu zaman hissedilmez, çünkü trafiğin büyük kısmı yurt içinde kısa yoldan akar. Yurt dışında denkleme ikinci bir darboğaz girer, o da sağlayıcının diğer ağlara bağlandığı transit ve eşleşme (peering) hatları. Türkiye'deki bir kullanıcıya giden paket, kullanıcının hangi internet servis sağlayıcısına bağlı olduğuna göre bambaşka bir yoldan dönebilir. Aynı sunucuya bir operatörden 45 ms, diğerinden 70 ms ölçmeniz bu yüzden şaşırtıcı olmaz. Üstelik hedef ülkenin akşam saatlerinde ana makinedeki komşular ile bu hatlar aynı anda en yoğun dönemlerini yaşar. Kullanıcınızın en çok beklediği saat, çoğu zaman sizin ölçmeyi en az düşündüğünüz saattir.
Gürültülü komşu (noisy neighbor) etkisi işlemcide steal time olarak, diskte uzayan bekleme süresi olarak görünür. Ağda ise yoğun saatte düşen aktarım hızı ve dalgalanan gecikme (jitter) şeklinde çıkar. En çok etkilenenler saniyede çok sayıda küçük paket işleyen iş yükleridir. Oyun sunucuları, VoIP, DNS ve gerçek zamanlı API'ler bu sınıfa girer. Her paket sanallaştırma katmanından geçerken küçük bir işlemci maliyeti doğurur ve bu maliyet komşular yüklendiğinde büyür.
Steal time'ı binlerce kilometre öteden izlemek
"Sunucu yavaşladı" şikâyeti geldiğinde ilk soru, yavaşlayanın sizin uygulamanız mı yoksa makinenin geri kalanı mı olduğu. Uzaktaki bir sanal sunucuda bunun cevabı steal time'da saklı. top ya da vmstat çıktısındaki st değeri, sanal işlemcinizin çalışmak istediği halde hypervisor'ün sıra vermediği sürenin yüzdesidir. Yoğun saatte %0–1 normal kabul edilir. Düzenli olarak %5'i geçiyorsa ana makinede rekabet var demektir. Eşiklerin ve vCPU paylaşımının ayrıntısı vCPU, thread ve steal time yazısında.
Anlık değer sizi yanıltır. Şikâyet akşam 22.00'de gelir, siz ertesi sabah bakarsınız ve her şey normal görünür. Bu yüzden geçmişi kaydeden bir şey kurun. En yalın yol sysstat paketi. Etkinleştirdiğinizde varsayılan olarak 10 dakikada bir örnek alır, sar -u ile de istediğiniz günün işlemci dökümünü steal sütunuyla birlikte geriye dönük okursunuz. mpstat -P ALL 1 her vCPU'yu ayrı gösterir. Prometheus kullanıyorsanız node_exporter'ın node_cpu_seconds_total metriğinde mode etiketi steal olan seriyi grafiğe alıp beş dakikalık ortalamaya alarm bağlayabilirsiniz.
Saat dilimi de işe karışır. Orta Avrupa Saati (CET) kışın UTC+1, yazın UTC+2'dir, Türkiye ise yıl boyunca UTC+3'te kalır. Bu dilimdeki bir hedef ülkenin 20.00–23.00 arasındaki yoğun saatleri kış aylarında Türkiye saatiyle 22.00–01.00'e denk gelir. Grafiklere gündüz bakan biri sorunu hiç göremeyebilir.
Teşhis için değerleri birlikte okuyun. Steal yüksek, sizin işlemci kullanımınız düşükse sorun komşulardadır. iostat -x çıktısında await yükselirken diske yazdığınız veri artmıyorsa disk dizisi için yarışılıyor demektir. İşlemci ve disk sakin ama gecikme yalnız akşamları zıplıyorsa mesele ağdadır, mtr ile iki yönden bakmak gerekir. Destek talebi açarken sar çıktısını ve UTC zaman damgalarını ekleyin. Netx'te sunucu yurt dışında olsa da muhatabınız tek ve Türkçe konuşuyor, kanıtla açılmış bir talep de teşhisi her iki taraf için kısaltır.
IP adresinizin sizden önceki hayatı
Sanal sunucu IP'leri genellikle fiziksel sunucu IP'lerinden çok daha sık el değiştirir. Birkaç günlüğüne kiralanıp toplu e-posta ya da port taraması için kullanılan, ardından iptal edilen sanal makineler eksik olmaz. İptal edilen makinenin adresi havuza döner, bir sonraki müşteriye verilir ve kara listedeki kaydı da çoğu zaman yanında getirir, yeni sahibi bunu çoğunlukla ilk e-postası geri döndüğünde fark eder.
Mesele tek adresle bitmiyor. Bazı kara listeler tek bir IP yerine bütün bir aralığı, hatta sağlayıcının ağının tamamını listeleyebilir. UCEPROTECT'in 2. ve 3. seviye listeleri bu mantıkla çalışır. Kendi adresiniz temiz olsa bile komşu adreslerin sicili postalarınıza bulaşabilir. Yurt dışı VPS'ten doğrudan e-posta göndermeyi planlıyorsanız açıkçası önce bundan vazgeçmeyi düşünün. Kurumsal e-postayı ayrı bir hizmette tutup şifre sıfırlama ya da sipariş bildirimi gibi işlem e-postalarını o hizmet üzerinden, kimlik doğrulamalı SMTP ile göndermek itibar sorununu büyük ölçüde sunucunun dışına taşır. Postaların neden spam klasörüne düştüğünü e-postaların spama düşme nedenlerini incelediğimiz yazıda adım adım ele aldık.
Ödeme altyapılarında iki ayrı IP konuşur ve bunlar sık karıştırılır. Müşterinin tarayıcısındaki IP dolandırıcılık puanlamasına girer, sunucunuzun nerede durduğundan etkilenmez. Sunucunuzun IP'si ise ödeme kuruluşunun API'sine yaptığınız sunucudan sunucuya çağrılarda görünür. Bazı sanal POS ve ödeme kuruluşları bu çağrıları yalnız panelde tanımlanmış IP'lerden kabul eder. Taşımadan önce yeni adresi tanımlatmazsanız, canlıya geçtiğiniz dakika ödemeler hata vermeye başlar.
Pazar yeri entegrasyonlarında da aynı mantık geçerli. Sipariş ve stok API'leri IP izin listesi ya da istek sınırı uygulayabilir. IP istihbarat veritabanları veri merkezi adreslerini "hosting" sınıfına koyar, bazı platformlar da bu sınıftan gelen trafiğe daha sıkı davranır. Çaresi resmî API'yi kendi anahtarınızla ve tanımlı bir IP'den kullanmaktır. Tersi de olur. Türkiye'deki bazı kurumsal servisler yalnız yurt içi IP'lerden gelen bağlantıları kabul edebilir, entegrasyon listenizi bu gözle de tarayın.
Sunucu yurt dışında diye sıralamanız düşer mi?
Doğrudan düşmez. Google ülke hedeflemesinde alan adı uzantısına (.com.tr gibi), hreflang işaretlemesine ve içeriğin diline sunucunun konumundan çok daha fazla ağırlık verir. Googlebot'un taramalarının büyük bölümü de zaten ABD'deki IP adreslerinden yapılır. Arama motoru Türkçe bir siteyi, sunucusu İstanbul'da olsa bile çoğunlukla okyanusun öbür yakasından okur.
Dolaylı etki ise gerçek. Türkiye'deki ziyaretçiye 40–55 ms öteden cevap veren bir sunucu, ilk bayt süresini (TTFB) ve onunla birlikte Largest Contentful Paint değerini kötüleştirir. Core Web Vitals saha verisi gerçek kullanıcıların tarayıcılarından toplandığı için bu fark rapora da yansır. Hosting tercihinin aramaya hangi yollardan dokunduğunu hosting seçiminin SEO etkisini anlattığımız yazıda topladık. SEO, yurt dışına çıkmak için bir gerekçe değildir. Türkiye'deki kitleniz için yerinizde kalmanın gerekçesi olabilir.
KVKK: hangi veri sınırı geçebilir?
Önce bir yanılgıyı ayıklayalım. "Sunucuda kişisel veri yok" cümlesi çoğu zaman doğru değildir. Web sunucusunun erişim günlükleri ziyaretçilerin IP adreslerini tutar, uygulama günlüklerinde e-posta adresleri geçer, oturum çerezleri bir kişiyi tanımaya yarar. Bunların her biri kişisel veri sayılabilir.
Türkiye'deki kişilere ait kişisel verileri yurt dışındaki bir sunucuda tutmak, 6698 sayılı Kişisel Verilerin Korunması Kanunu bakımından genel olarak yurt dışına aktarım şeklinde değerlendirilir ve Kanun'un 9. maddesine tabidir. Bu madde 2024'te 7499 sayılı Kanun'la yeniden düzenlendi. Aktarım artık yeterlilik kararı, standart sözleşme gibi uygun güvenceler ya da sınırlı istisnalar üzerinden yürüyor. Bankacılık, ödeme hizmetleri ve kamu projelerinde sektörel kurallar da devreye girebilir. Bu bölüm hukuki görüş değildir, projenize uygulanacak yolu hukuk danışmanınızla birlikte değerlendirin.
Mimari tarafta elinizde birkaç seçenek var. Bizim en sık önerdiğimiz kurguda kişisel veriyi işleyen her şey, yani veritabanı, uygulama ve günlükler Türkiye'de durur, yurt dışındaki VPS ise yalnız anonim içerik taşıyan bir vitrin gibi çalışır. Statik dosyalar, ürün görselleri ve oturum açmamış ziyaretçiye gösterilen sayfaların önbelleği bu gruba girer. Kurgunun iki şartı var. Birincisi, önbellek oturum açmış kullanıcının yanıtlarını tutmamalı (Cache-Control: private başlığı ya da oturum çerezi görüldüğünde önbelleği atlayan bir kural). İkincisi, yurt dışındaki sunucunun kendi erişim günlükleri ya IP adresini anonimleştirmeli (son okteti sıfırlamak gibi) ya da çok kısa süre saklanmalı.
Akla ilk gelen ama bizce uzak durulması gereken kurgu, uygulamayı yurt dışına koyup veritabanını Türkiye'de bırakmak. Uygulama katmanı kişisel veriyi yine işler, aktarım sorusu ortadan kalkmaz. Teknik bedeli de ağır. Bir sayfa 20 veritabanı sorgusuyla üretiliyorsa ve her sorgu 45 ms'lik bir hattan gidip geliyorsa, yalnız ağ beklemesi 900 ms tutar. Bunu sorgu önbelleğiyle yamamak mümkün, ama yama tasarım hatasını gizlemekten öteye geçmez.
Tersi de kurulabilir. Avrupa Birliği'ndeki müşterilerin verisini Avrupa'daki bir sunucuda, Türkiye'deki müşterilerinkini Türkiye'de tutan bölgesel bir ayrım yapabilirsiniz. Bu durumda AB'deki kişilerin verisi için GDPR'ın kuralları gündeme gelir, raporlama için iki veritabanını birleştirmek de ayrı bir mühendislik işine dönüşür. Yedekleri unutmayın. Türkiye'deki veritabanının yedeğini yurt dışındaki bir VPS'e göndermek de bir aktarımdır. Şifrelemenin bu değerlendirmeyi nasıl etkilediğini yine hukuk danışmanınıza sorun.
Döviz faturası ile TL fatura arasındaki fark
Yurt dışındaki bir sağlayıcıyla doğrudan çalıştığınızda fatura avro ya da dolar cinsinden gelir ve aylık maliyetiniz her ay biraz farklı çıkar. Kart ekstresine ödeme günündeki kur yansır, bankanız yurt dışı işlem komisyonu ekleyebilir. Şirketseniz iş uzar. Yurt dışından alınan hizmette KDV'yi sorumlu sıfatıyla sizin beyan etmeniz gerekebilir (2 No.lu KDV Beyannamesi), yabancı faturanın muhasebeleştirilmesi ve kur farkı kayıtları da cabası. Vergisel ayrıntıyı mali müşavirinizle teyit edin.
Netx üzerinden aldığınız yurt dışı VPS'in faturası TL olarak kesilir. Ödemeyi kredi kartı ya da havale/EFT ile yaparsınız, muhatabınız da Türkiye'deki tek bir şirkettir. Şunu da saklamayalım. TL fatura döviz riskini yok etmez, yalnız riskin kimde durduğunu ve faturanıza ne zaman yansıdığını değiştirir. Altyapı maliyeti dövize bağlı bir hizmette yenileme tutarı değişebilir ve sözleşmemiz gereği yenilemede güncel fiyatlandırma geçerli olduğu için bütçeyi yalnız ilk dönemin fiyatına göre değil, kurdaki olası hareketi de hesaba katarak kurun. Kurun sunucu ve hosting fiyatlarına nasıl yansıdığını hosting fiyatlarında döviz riski yazımızda inceledik.
Yurt dışı VPS kiralama teklifinde ne yazmalı?
Formdaki "hedef bölge" kutusu tek başına az şey söyler. Ne kadar somut yazarsanız lokasyon, yapılandırma ve fiyat o kadar isabetli gelir, sonradan "aslında şunu da istiyorduk" turu da yaşanmaz.
Bölgeyle başlayın, ama gerekçesiyle. "Avrupa" yazmak yerine "dinamik isteklerin %60'ı Almanya ve Hollanda'dan geliyor, ödeme sağlayıcımızın API'si de Avrupa'da" demek önerilecek lokasyonu doğrudan şekillendirir. Ardından iş yükünü anlatın. Hangi uygulama, hangi veritabanı, yoğun saat hangi saat dilimine göre? Mevcut bir sunucunuz varsa yoğun saatteki işlemci, bellek ve disk kullanımını rakamla verin. Elinizde ölçüm yoksa VPS'te RAM ihtiyacını hesaplama yazısındaki yöntemle kabaca çıkarabilirsiniz. Aylık çıkış trafiğini, kaç IP adresine ve ne için ihtiyaç duyduğunuzu, işletim sistemini de ekleyin. Windows Server istenirse lisans bedeli teklife eklenir. Linux dağıtımlarında lisans ücreti yoktur. Root ya da yönetici erişimi her iki durumda da sizde olur.
Çoğu talepte unutulan birkaç satır var. Sunucudan e-posta gönderilecek mi? Kişisel veri işlenecek mi, işlenecekse hangi katmanda? Taşıma ve yedek isteniyor mu? Sunucuyu kendiniz mi yöneteceksiniz, yoksa güncelleme, izleme ve güvenlik işlerini devretmek mi istiyorsunuz? Son soru için sunucu yönetimi hizmetini teklife ek olarak isteyebilirsiniz.
Bu bilgileri aldıktan sonra yurtdışı VPS sunucu için uygun lokasyonu, yapılandırmayı, fiyatı ve teslim süresini yazılı teklifle bildiriyoruz. Onayınızın ardından güvenlik ve doğru hizmet için sizinle iletişime geçiyor, kurulumu ondan sonra yapıyoruz. Cevaplarınız hazırsa doğrudan teklif formuna geçebilirsiniz.
Türkiye VPS'ten yurtdışı VPS'e taşıma adımları
Taşımanın zor kısmı veriyi kopyalamak değil. Zor olan, eski IP adresine bağlı olduğunu unuttuğunuz şeyler. İşin pratiğinde önerdiğimiz sıra şu.
- Envanter çıkarın. Alan adları ve DNS kayıtları, cron görevleri, SSL sertifikaları, e-posta akışı ve en çok unutulanı, sunucu IP'nizi izin listesinde tutan dış servisler. Ödeme kuruluşu, pazar yeri, ERP ve müşterilerinizin güvenlik duvarları bu listeye girer.
- DNS kayıtlarının TTL değerini, mevcut TTL süresi kadar önceden 300 saniyeye indirin. 86.400 saniyelik bir TTL için bu en az bir gün önce demek. TTL'in nasıl işlediğini DNS'in çalışma mantığını anlattığımız yazıda bulabilirsiniz.
- Yeni sunucuyu kurun ve sertleştirin. Uygulamanın beklediği PHP, veritabanı ve kütüphane sürümleri eski sunucuyla aynı olsun. Güvenlik tarafındaki ilk adımlar Linux sunucu ilk kurulum ve güvenlik rehberinde.
- Yeni IP'yi bütün izin listelerine ekletin, eskisini henüz silmeyin. Bazı kurumlarda bu tanım günler sürebilir, o yüzden ilk iş olarak başlatın.
- İlk kopyayı alın. Dosyalar için rsync -aHAX --numeric-ids, veritabanı için mysqldump --single-transaction ya da büyük veride geçici bir replikasyon iş görür. 40–55 ms'lik bir hatta tek bir TCP akışı bağlantıyı dolduramayabilir. Büyük veriyi birkaç paralel akışa bölmek ya da Linux'ta BBR tıkanıklık denetimini açmak aktarımı kısaltır.
- Test edin. Bilgisayarınızın hosts dosyasına yeni IP'yi yazıp siteyi gerçek alan adıyla açın. Ödemeyi test ortamında deneyin, bir e-posta gönderin, cron görevlerinin hangi saat diliminde koştuğuna bakın.
- Geçiş penceresinde yazmayı durdurun (bakım modu), son rsync turunu ve veritabanı farkını alın, DNS kaydını yeni IP'ye çevirin.
- Eski sunucuyu birkaç gün ayakta tutun ve erişim günlüğünü izleyin. Eski IP'ye hâlâ istek geliyorsa bir yerde sabit yazılmış bir adres kalmış demektir.
- İlk hafta boyunca hedef bölgeden ölçtüğünüz TTFB'yi, steal time'ı ve hata günlüklerini taşıma öncesiyle karşılaştırın.
Taşımada destek istiyorsanız bunu teklif talebinize yazın. Kapsam teklifte netleşir.
Yurtdışı VPS mi, yurtdışı VDS mi?
Mesafe, VPS ile VDS arasındaki farkı büyütür. Yanınızdaki bir sunucuda performans sorununu fark etmek ve kanıtlamak kolaydır. Binlerce kilometre ötede aynı iş ölçüm, kayıt ve yazışma ister. Sonunda VDS'e geçmeye karar verirseniz ve IP adresi değişirse, yukarıdaki izin listesi turu baştan başlar. Bu yüzden iş yükünüz kaynak paylaşımına hassassa doğru sınıfla başlamak, sonradan taşımaktan ucuza gelir.
| Sinyal | Yurtdışı VPS yeterli | Yurtdışı VDS'e bakın |
|---|---|---|
| Steal time | Yoğun saatte de %0–1 civarında | Düzenli olarak %5'in üzerinde |
| Trafik profili | Düşük ya da öngörülebilir | Kampanya, yayın, maç saati gibi ani tepeler |
| Gecikmeye duyarlılık | Web sitesi, API, arka plan işleri | Oyun sunucusu, VoIP, gerçek zamanlı uygulama |
| Veritabanı | Küçük ve belleğe sığıyor | Yazma yoğun, sürekli disk G/Ç |
| Kullanım amacı | Test, geliştirme, bölgesel izleme noktası, yedek hedefi | Gelir getiren üretim uygulaması |
| Bütçe önceliği | Kaynak başına en düşük maliyet | Tutarlı performans için ek maliyet kabul edilebilir |
Ayrılmış kaynak modelini VPS ile VDS arasındaki fark yazısında ayrıntılı anlattık. İşlemci ve belleğin size ayrılmasını istiyorsanız yurtdışı VDS sunucu sayfamızdan teklif isteyebilirsiniz. Donanımın tamamının size ait olması gerekiyorsa yurt dışı kiralık fiziksel sunucu seçeneğine bakın. Gecikme ölçüm yöntemleri, IPMI ve fiziksel donanım seçimi o sayfadaki rehberde. Yurtdışı VDS de bu sayfadaki VPS gibi teklif usulüyle çalışıyor.
Teslimden sonraki ilk saat
IP adresi ve yönetici bilgileri e-postanıza geldiğinde uygulamayı kurmaya hemen başlamayın, önce sunucunun söz verilen ülkede, söz verilen kimlikle ve temiz bir sicille durduğunu doğrulayın. Bu saatte bulunan bir sorun, sunucuda henüz hiçbir şey yokken çözülür.
- Kimliği doğrulayın. whois çıktısındaki country satırı adresin hangi ülkeye kayıtlı olduğunu gösterir. Bunu MaxMind ve IP2Location gibi en az iki GeoIP kaynağıyla karşılaştırın. Ülke bazlı erişim isteyen bir servis için çalışıyorsanız asıl testi o servise bağlanarak yapın. Veritabanları yeni kullanıma alınan bloklarda geç güncellenebilir, uyuşmazlık görürseniz hemen bildirin.
- Kara listeleri tarayın. Çok sayıda RBL'i birlikte sorgulayan bir araçla hem adresi hem komşu aralığı kontrol edin. Spamhaus'u kendiniz sorgulayacaksanız sunucunun kendi çözümleyicisini kullanın. Spamhaus, Google ya da Cloudflare gibi açık DNS çözümleyicilerden gelen sorgulara gerçek sonuç yerine 127.255.255.254 gibi bir hata kodu döndürür.
- Ters DNS'e bakın. dig -x komutu sunucunun ana makine adını göstermeli. Posta gönderecekseniz nc -vz -w 5 ile dışarıdaki bir posta sunucusunun 25 numaralı portuna bağlanmayı deneyin, kapalıysa teklifte konuşulanla karşılaştırın.
- Yolu iki yönden ölçün. Türkiye'den sunucuya mtr -rwz -c 100 çalıştırın, sunucudan da ofisinizin IP adresine aynı komutu. Dönüş yolu gidişten farklı olabilir. Ölçümü hedef ülkenin akşam saatinde, mümkünse iki farklı Türk operatöründen tekrarlayın.
- Tabanı kaydedin. systemd-detect-virt, nproc ve free -h ile tanımlanan kaynakları görün, sysstat'ı açın, kısa bir fio ve iperf3 testiyle ilk günün değerlerini not edin. Bir ay sonra "yavaşladı mı" sorusuna ancak bu tabanla cevap verebilirsiniz. Test yöntemleri sunucu performans testi rehberinde.
- Saati sabitleyin. timedatectl ile saat dilimini UTC'ye alın, chrony ile eşitleyin. Müşteriye gösterilecek saatleri uygulama katmanında Türkiye saatine çevirin.
En sık yapılan hatalar
Listenin başında, ziyaretçisi Türkiye'de olan bir siteyi "yurt dışı daha hızlı" ya da "yurt dışı daha ucuz" varsayımıyla taşımak var. İkisi de ölçülmeden kurulmuş cümleler.
Bölgeyi tek bir ping'le seçmek hemen arkasından gelir. Sabah ofisin fiber bağlantısından alınmış tek bir ölçüm, akşamın yoğun saatinde mobil hattan bağlanan ve başka bir operatörün yolunu kullanan müşterinizin yaşadığı gecikme hakkında neredeyse hiçbir şey söylemez. Oturum sayısına bakıp geliri unutmak, uygulamayı yurt dışına alıp veritabanını Türkiye'de bırakmak, izin listelerini taşıma gününe bırakmak da aynı aileden. Sonuncusu en görünür olanı, çünkü ilk başarısız ödemeyle ortaya çıkar.
Teknik tarafta iki hata sık tekrarlanır. Biri yavaşlayan bir VPS'i steal time'a bakmadan büyütmek. Sorun komşulardaysa daha büyük paket aynı kalabalık makinede aynı yavaşlığı yaşar. Diğeri yeni IP'den kara liste kontrolü yapmadan posta göndermeye başlamak. İtibar bir kez zedelendiğinde temizlemek, baştan kontrol etmekten çok daha uzun sürer.
Bir de idari olanlar var. KVKK değerlendirmesini canlıya geçtikten sonra yapmak, geri dönüşü en zor olanı. Ödeme takibini aksatmak da sanıldığından pahalı. Netx sözleşmesine göre ödenmeyen hizmet vadeden 5 gün sonra durdurulur, sonraki 15 gün içinde veriler silinebilir. Varsa hizmete bağlı snapshot'lar da hizmetle birlikte gider, o yüzden en az bir yedeğin sizin kontrolünüzdeki başka bir yerde durması gerekir. Fatura bildirimlerinin gittiği e-posta adresini güncel tutmak basit bir iş. Tam da bu yüzden ihmal edilir.
Teklif istemeden önce kontrol listesi
Aşağıdaki maddelerin cevabını ya kendiniz hazırlayın ya da teklifte yazılı olarak isteyin. Boş kalan her satır, ileride bir sürpriz demek.
- Hedef bölge ve onu destekleyen veri: dinamik isteklerin ve gelirin ülke dağılımı.
- Uygulamanın konuştuğu dış servisler ve bunlardan hangilerinin IP izin listesi kullandığı.
- Yoğun saatteki işlemci, bellek ve disk kullanımı, aylık çıkış trafiği.
- İşletim sistemi tercihi. Windows Server ise lisans bedelinin teklifte ayrı satır olarak görünmesi.
- Disk tipi ve sanal makine başına IOPS sınırı olup olmadığı.
- Port hızı, bu hızın paylaşımlı mı garantili mi olduğu ve trafiğin nasıl ölçüldüğü.
- IPv4 adedi, IPv6 desteği, ters DNS tanımı ve 25 numaralı portun durumu.
- DDoS koruma kapsamı ve saldırı anında uygulanan prosedür.
- Yedeğin nerede tutulacağı ve kimin kuracağı, taşıma desteği isteniyorsa kapsamı.
- Kişisel verinin hangi katmanda ve hangi ülkede işleneceği, aktarım dayanağı.
- Sunucuyu kimin yöneteceği ve yönetim hizmetinin teklife eklenip eklenmeyeceği.
- Uptime taahhüdü ve planlı bakımın buna dahil olup olmadığı. Netx'in bütün ürünlerindeki taahhüt %99,9, bu da 30 günlük bir ayda yaklaşık 43 dakikalık kesinti payı demek.
- Teslim süresi, fatura para birimi ve yenileme koşulu.


