Bir Web Sitesini Sıfır Kesinti (Downtime) İle Taşımak

Bir web sitesini yeni bir hosting'e veya yeni bir sunucuya taşımak çoğu zaman yüksek riskli bir operasyon olarak çerçevelenir. İnsanlar, eski sitenin çevrimdışı olduğu ve yenisinin henüz tam olarak hazır olmadığı kaçınılmaz bir boşluk (downtime) olduğunu varsayarlar.

Böyle olmak zorunda değil. Sıfır kesintili (zero-downtime) taşımanın asıl tekniği hiç de egzotik değildir. Tamamen doğru sıralama ile ilgilidir: Yeni sunucuyu baştan sona eksiksiz çalışır hale getirin, eski sunucu hala gerçek trafiği karşılarken yenisini kapsamlıca doğrulayın ve geçişi (cutover) ancak ondan sonra yapın. Tabii tüm bunlara başlamadan günler önce DNS TTL değerini ciddi şekilde düşürmüş olmanız şartıyla.

Günler öncesinden: TTL değerini düşürün

DNS kayıtları, yerel çözümleyicilere (resolvers) bir cevabı ne kadar süre önbellekte (cache) tutacaklarını tam olarak söyleyen bir TTL (time to live - yaşama süresi) değerine sahiptir. Bir alan adının A kaydının TTL değeri 24 saatse ve siz IP'yi değiştirirseniz, bazı ziyaretçiler tam bir gün boyunca körü körüne eski sunucuya gitmeye devam edecektir.

Taşınmadan birkaç gün önce TTL'yi 300 saniye gibi son derece kısa bir değere düşürmek, o inatçı ve uzun TTL'nin önce her yerde doğal olarak süresinin dolmasına (expire) olanak tanır:

ornek.com.  300  IN  A  203.0.113.10

Gerçek geçiş anı geldiğinde, internetteki tüm cihazların önbelleğe alınmış cevapları en fazla beş dakika öncesine ait olacaktır. Bu, "değişiklik beş dakika içinde yürürlüğe girer" ile "değişiklik ziyaretçisine bağlı olarak muhtemelen yarın bir ara yürürlüğe girer" arasındaki o kritik farktır.

DNS'e dokunmadan önce yeni sunucuyu tamamen hazırlayın ve doğrulayın

Riski tamamen ortadan kaldıran adım budur ve ironik bir şekilde en çok aceleye getirilen adım da her zaman budur. Yeni sunucuda uygulama tamamen dağıtılmış (deploy), veritabanı yakın tarihli bir yedekten geri yüklenmiş ve %100 test edilebilir olmalıdır—üstelik bunların hepsi, public DNS henüz onu işaret etmiyorken yapılmalıdır.

Henüz canlı (live) olmayan bir sunucuyu test etmenin en doğru yolu, kendi makinenizdeki DNS çözümlemesini yerel olarak ezmektir:

# Kendi makinenizdeki /etc/hosts dosyası
203.0.113.10  ornek.com

Bu tek satır yerindeyken, tarayıcınızda ornek.com adresini ziyaret ettiğinizde doğrudan yeni sunucuya gidersiniz, dünyanın geri kalanı ise hala eski sunucuya gitmeye devam eder. Tüm problemleri bulmak isteyeceğiniz tam nokta işte burasıdır: eksik bir ortam değişkeni (environment variable), taşınmayı unutulmuş bir dosya yükleme (upload) dizini veya yeniden başlatılması gereken bir arka plan servisi. Bunları, üzerinizde sıfır baskı varken ve sıfır ziyaretçi etkilenirken bulursunuz. Bir şeyler bozuksa, düzeltin ve tekrar test edin. Acele etmeye gerek yok, çünkü henüz canlıda hiçbir şey yok.

Veritabanı: Gerçekten dikkat gerektiren kısım

Statik dosyalar ve uygulama kodları önceden kopyalanabilir ve geçişten hemen önce basit bir rsync ile tekrar senkronize edilebilir.

Veritabanı daha çetrefillidir çünkü geçiş anına kadar eski sunucuda sürekli değişmeye devam eder. En dolaysız yaklaşım: nihai bir yedek alın ve geçiş anında yeni sunucuya geri yükleyin. Bu yöntemde, sitenin (özellikle yazma işlemleri için) çok kısa süreliğine bakım moduna alınması veya sadece okunabilir (read-only) yapılması gereken o kısacık zaman dilimini (döküm alma, aktarma ve geri yükleme süresi) kabul etmiş olursunuz.

# Eski sunucuda, tam geçişten hemen önce
mysqldump --single-transaction myapp_db | gzip > final-dump.sql.gz
scp final-dump.sql.gz yeni-sunucu:/tmp/
# Yeni sunucuda
gunzip -c /tmp/final-dump.sql.gz | mysql myapp_db

Birkaç dakikalık salt okunur (read-only) durumunun bile kesinlikle kabul edilemez olduğu büyük sitelerde veritabanı replikasyonu (yeni sunucuyu önceden eskisinin gerçek zamanlı bir replikası (replica) olarak kurup geçişte ana (master) rolüne terfi ettirmek) bu boşluğu kapatır. Ancak çoğu küçük ve orta ölçekli site için, planlı ve trafiğin düşük olduğu bir bakım penceresi sırasında yaşanacak birkaç dakikalık "site yükleniyor ama yeni yorumlar ve siparişler duraklatıldı" durumu, tek seferlik bir taşıma işlemi için replikasyon yapılandırmanın devasa karmaşıklığına kıyasla inanılmaz derecede makul bir takastır.

Asıl Geçiş Anı (Cutover)

Yeni sunucu /etc/hosts üzerinden kapsamlıca test edildikten, TTL zaten 300 saniyeye düşürüldükten ve son bir veritabanı senkronizasyonu tamamlandıktan sonra, asıl DNS değişikliği artık heyecansız bir prosedürden ibarettir:

ornek.com.  300  IN  A  198.51.100.20

Beş dakikalık TTL penceresi içinde, tüm küresel trafik pürüzsüz bir şekilde yeni sunucuya kayar.

Eski sunucu sonrasında bir veya iki gün boyunca hiç dokunulmadan çalışır durumda bırakılır. Bu, gerçek production trafiği altında beklenmedik bir şey yüzeye çıkarsa anında bir geri dönüş (fallback) sağlar. Aynı zamanda, bozuk bir şekilde önbellekleme (caching) yapan bir DNS cevabı nedeniyle hala ona gelen başıboş ziyaretçilerin ölü bir sunucuyla karşılaşmamasını garanti eder.

Bu neden özel araçlar olmadan işe yarıyor?

Bunların hiçbiri pahalı, taşımaya özel yazılımlar gerektirmez. Aceleye getirilmiş bir taşımadaki "kesinti"nin (downtime) asıl kaynağı, test işlemini DNS değişikliğinden sonra yapmak ve kritik sorunları yeni sunucu zaten canlı olan tek sunucuyken bulmaktır.

Tam da bu sırayı tersine çevirmek—önce tam hazır ve test edilmiş olmak, DNS değişikliğini en sona bırakmak ve o ana gelindiğinde zaten kısaltılmış olan bir TTL—geçişin kendisini tamamen olaysız bir şeye dönüştürür. Hazırlığın kendisi taşımanın ta kendisidir. DNS değişikliği ise sadece son ve en küçük adımdır.