Yurt dışındaki bir iş yükünü Türkiye'ye taşımak, doğru sırayla yapıldığında kesinti süresi dakikalarla ölçülen bir projedir. Sıra şudur: bağımlılıkları çıkarın, strateji seçin, hedef ortamı hazırlayın, veriyi replikasyonla taşıyın, paralel test edin, DNS ile devri yapın ve eski kopyaları temizleyin. Projelerin çoğu teknik bir engel yüzünden değil, keşif aşamasında atlanan bir bağımlılık yüzünden uzar.
Türkiye'ye taşıma kararı genellikle üç nedenden biriyle alınır: Türk kullanıcılar için gecikme süresi, KVKK açısından kişisel verileri Türkiye'de tutma isteği ve maliyet. Neden ne olursa olsun teknik süreç aynıdır. Bu rehberde o süreci baştan sona ele alıyoruz.
Taşımadan önce: başarı kriterini yazın
Neden taşındığınız, neyi ölçeceğinizi belirler ve bunu işe başlamadan yazmak gerekir.
Gecikme için taşıyorsanız başarı kriteri, taşıma öncesi ve sonrası p95 yanıt süresidir. Maliyet için taşıyorsanız, trafik çıkış ücretleri dahil aylık toplam maliyettir. Kişisel verilerin KVKK açısından Türkiye'de kalması için taşıyorsanız kriter tektir: tüm kopyalar Türkiye'de. Buna yedekler, snapshot'lar, log arşivleri ve DR ortamı da dahildir.
Bu kriteri yazmadan başlayan projeler, sonunda "taşıma tamamlandı mı" sorusuna net cevap veremez.
1. Keşif: bağımlılık haritası
Sunucu listesi çıkarmak kolaydır. Zor olan, o sunucuların nelere bağlı olduğunu ve nelerin onlara bağlı olduğunu bulmaktır. Keşif aşamasında envantere girmesi gerekenler:
- Sunucular, rolleri ve kaynak kullanımı (en az 30 günlük CPU, RAM, disk IOPS)
- Yapılandırma dosyalarına, güvenlik duvarı kurallarına ve betiklere sabit yazılmış IP adresleri
- DNS kayıtları ve mevcut TTL değerleri
- SSL/TLS sertifikaları ve yenileme yöntemleri
- Zamanlanmış görevler (cron, Windows Görev Zamanlayıcı)
- Dış entegrasyonlar: ödeme, SMS, e-posta, ERP, kargo
- Donanıma veya MAC adresine bağlı lisanslar
- Yedekleme, izleme ve güvenlik ajanları
Listede en sık atlanan kalem şudur: müşterinizin veya iş ortağınızın kendi güvenlik duvarında sizin IP adresinizi beyaz listeye almış olması. Yeni IP'lerin karşı tarafta açılması haftalar sürebilir, bu yüzden bu bildirimi keşif aşamasında gönderin.
Windows iş yükleri taşıyorsanız lisanslama ayrı bir başlıktır; taşıma sonrasında lisansın geçerli kalıp kalmadığını önceden netleştirin. Konuyu Windows sanal sunucu lisanslama rehberimizde ayrıntılı ele aldık.
2. Taşıma stratejisi seçimi
| Strateji | Ne değişir | Süre | Risk | Ne zaman |
|---|---|---|---|---|
| Rehost (lift-and-shift) | Yalnızca konum | Kısa | Düşük | Çoğu iş yükünün ilk adımı |
| Replatform | İşletim sistemi, veritabanı sürümü, yönetilen servisler | Orta | Orta | Taşıma sırasında bariz bir kazanç varsa |
| Refactor | Uygulama mimarisi | Uzun | Yüksek | Ayrı bir proje olarak |
Çoğu ekip için önerimiz basittir: önce olduğu gibi taşıyın, sonra iyileştirin. Taşımayı ve modernizasyonu aynı anda yapmak, bir sorun çıktığında bunun konumdan mı yoksa yapılan değişiklikten mi kaynaklandığını bilememek demektir.
3. Hedef ortamın hazırlanması
Hedef ortam, kaynak ortamın bir kopyası olarak başlamalıdır. Farklılaştırma taşımadan sonra yapılır.
Boyutlandırma. Kaynak ortamdaki gerçek kullanım metriklerine yüzde 20–30 pay ekleyin. Kaynağın kâğıt üzerindeki yapılandırmasına değil, 30 günlük ölçülmüş kullanımına bakın; çoğu sunucu fazla boyutlandırılmıştır. Farklı yapılandırmaların maliyetini karşılaştırmak için sanal sunucu fiyat karşılaştırmamız iyi bir başlangıç noktasıdır.
Ağ. IP planını, alt ağları ve güvenlik gruplarını kaynaktaki segmentasyonun birebir aynısı olacak şekilde kurun. Yönetim erişimini baştan bastion veya VPN üzerinden tasarlayın; taşıma sonrasına bırakılan güvenlik düzenlemeleri genellikle hiç yapılmaz.
İki ortam arası bağlantı. Replikasyon ve paralel çalışma dönemi için kaynak ile hedef arasında site-to-site VPN tüneli kurun.
Hedef tarafta fiziksel katmanla uğraşmak zorunda değilsiniz. İstanbul'daki bir Tier III+ veri merkezinde çalışan Türkiye lokasyonlu bulut sunucular üzerinde ortamı dakikalar içinde ayağa kaldırabilir, zamanınızı asıl zor kısım olan keşfe ve devir planına ayırabilirsiniz.
4. Veriyi taşıma
Veri türüne göre yöntem değişir.
Sanal makineler. En düşük kesintili yöntem, VM düzeyinde sürekli replikasyondur: kaynak çalışmaya devam ederken disk değişiklikleri hedefe aktarılır, devir anında yalnızca son fark senkronize edilir. VMware tabanlı ortamlarda vCAV ile sanal makine çoğaltma bu işi uygulamaya dokunmadan yapar ve kesinti süresini dakikalara indirir.
Veritabanları. Veritabanının kendi replikasyon mekanizmasını kullanın: MySQL ve PostgreSQL için replika, SQL Server için log shipping veya Availability Group. Dump ve geri yükleme yöntemi yalnızca küçük veritabanlarında veya uzun bir bakım penceresi varsa mantıklıdır.
Nesne depolama. rclone veya aws s3 sync gibi araçlarla ilk kopyayı alın, devir öncesinde farkı senkronize edin. Hedef S3 uyumlu nesne depolama olduğunda uygulama kodunda yalnızca uç nokta adresi değişir.
Dosya sunucuları. rsync ile ilk tam kopya, ardından düzenli fark senkronizasyonu.
Büyük veri setlerinde ilk kopyayı hafta sonu veya düşük trafik saatlerinde başlatın; devir gecesi yalnızca farkı taşımak zorunda kalırsınız.
5. Test ve paralel çalıştırma
Hedef ortam hazır ve veri senkronize olduğunda, devirden önce dört test yapılmalıdır:
- Fonksiyonel test: uygulamanın temel akışları uçtan uca çalışıyor mu?
- Performans karşılaştırması: aynı yük altında yanıt süreleri kaynakla kıyaslanabilir mi?
- Entegrasyon testi: dış servisler yeni IP adreslerini kabul ediyor mu?
- Geri yükleme testi: yeni ortamda alınan yedek gerçekten geri yüklenebiliyor mu?
Mümkünse trafiğin bir kısmını, örneğin yalnızca iç kullanıcıları, birkaç gün yeni ortama yönlendirin. Gerçek kullanım, test senaryolarının bulamadığı sorunları bulur.
6. Devir
Devir gecesinin kontrol listesi:
- DNS TTL değerini devirden en az 48 saat önce 300 saniyeye düşürün
- Uygulamayı bakım moduna alın, yazma işlemlerini durdurun
- Son fark senkronizasyonunu çalıştırın
- Veri tutarlılığını doğrulayın: tablo bazında satır sayıları, kritik tablolarda checksum
- DNS kayıtlarını değiştirin
- Hata oranını ve yanıt süresini izleyin
- Başarı kriterine göre devri onaylayın veya geri dönün
Geri dönüş planı yazılı değilse devir yapılmamalıdır. Planda üç şey net olmalı: hangi koşulda geri dönülecek, kararı kim verecek ve kaynak ortam kaç gün hazır bekletilecek.
7. Temizlik: taşıma, devirle bitmez
Taşıma, eski ortamdaki son kopya silindiğinde biter.
Eski sunucuları, snapshot'ları, yedekleri, nesne depolama bucket'larını ve log arşivlerini listeleyin ve bir kapatma tarihi belirleyin. Kaynak ortamı en az bir tam iş döngüsü, örneğin bir ay sonu kapanışı boyunca bekletin, ardından kapatın.
Taşımanın nedeni KVKK ve verinin lokasyonuysa bu adım zorunludur. Eski bölgede kalan bir yedek, kişisel verinin hâlâ ülke dışında olması demektir ve taşımanın amacını boşa çıkarır.
Aynı gün yeni ortamda yedekleme ve DR hedeflerini yapılandırın. Bulut yedekleme ve felaket kurtarma (DRaaS) hizmetlerinin hedef lokasyonunu doğrulayın ve imha işlemini belgeleyin.
Sık yapılan hatalar
Sahada en sık karşılaştığımız beş hata:
TTL'yi devir günü düşürmek. Eski TTL süresi dolana kadar kullanıcıların bir kısmı eski ortama gitmeye devam eder.
Saat senkronizasyonunu unutmak. Yeni sunucularda NTP yapılandırılmazsa loglar, token'lar ve zamanlanmış görevler kayar.
E-posta itibarını hesaba katmamak. Yeni IP adresinden giden işlemsel e-postalar ilk günlerde spam klasörüne düşebilir. SPF kayıtlarını önceden güncelleyin ve gönderim hacmini kademeli artırın.
Lisansları son ana bırakmak. Donanıma bağlı lisanslar yeni ortamda geçersiz kalabilir.
Yedekleme ajanını yeniden yapılandırmamak. En pahalı hata budur: taşıma sonrası ilk hafta sistem yedeksiz çalışır ve bunu kimse fark etmez.
