Bir Website'i Downtime'sız Migrate Etmek

Bir website migration'ı, yeni host, yeni server, bazen tamamen yeni bir stack, riskli olarak çerçeveleniyor çünkü varsayım, eski sitenin gittiği ve yeninin henüz hazır olmadığı bir an olduğu. Böyle olmak zorunda değil. Zero-downtime migration için asıl teknik exotic değil, sıralama: önce yeni server'ı tamamen çalışır hale getirin, eski hâlâ live'ken ve gerçek traffic'i sunarken yeniyi iyice doğrulayın, ve sadece o zaman geçişi yapın, bunların hiçbiri başlamadan çok önce düşürülmüş bir DNS TTL'iyle.

Günler önce: TTL'i düşürün

DNS kayıtlarının, resolver'lara bir cevabı ne kadar süre cache'leyeceklerini söyleyen bir TTL'i (time to live) var. Bir domain'in A kaydının TTL'i 24 saatse ve onu değiştirirseniz, bazı visitor'lar bir güne kadar eski server'a gitmeye devam ediyor. Migration'dan birkaç gün önce TTL'i kısa bir şeye, 300 saniyeye, düşürmek, eski, uzun TTL'e her yerde önce expire olması için zaman veriyor:

example.com.  300  IN  A  203.0.113.10

Gerçek cutover gerçekleştiğinde, her resolver'ın cache'lenmiş cevabı en fazla beş dakika eski oluyor, ki bu "geçiş beş dakika içinde etkili oluyor" ile "geçiş, visitor'a bağlı olarak önümüzdeki gün içinde bir noktada etkili oluyor" arasındaki fark.

DNS'e dokunmadan önce yeni server'ı tamamen build edin ve doğrulayın

Bu, riski gerçekten ortadan kaldıran adım, ve aynı zamanda en çok aceleye getirilen adım. Yeni server'da application deploy edilmiş, database recent bir backup'tan restore edilmiş ya da, ideal olarak, cutover'a kadar replication'la sync tutulmuş olmalı, ve DNS henüz ona point etmeden tamamen test edilebilir olmalı. Henüz live olmayan bir server'ı test etmenin yolu, DNS resolution'ı lokal olarak override etmek:

# /etc/hosts on your own machine
203.0.113.10  example.com

Bu yerindeyken, browser'da example.com'u ziyaret etmek, herkes hâlâ eskisine giderken yeni server'a vuruyor. Hiçbir baskı olmadan ve hiçbir visitor etkilenmeden, problemleri burada buluyorsunuz: eksik bir environment variable, migrate edilmemiş bir file upload path'i, restart edilmesi gereken bir service. Bir şey bozuksa, düzeltin ve yeniden test edin. Acele yok, çünkü henüz hiçbir şey live değil.

Database: gerçekten dikkat gerektiren kısım

Static dosyalar ve kod önceden kopyalanıp cutover'dan hemen önce rsync gibi bir şeyle yeniden sync edilebilir. Database daha tricky çünkü cutover anına kadar eski server'da sürekli değişiyor. Basit yaklaşım: son bir backup alıp cutover anında yeni server'a restore etmek, bunu yaparken sitenin ideal olarak read-only olması ya da spesifik olarak write'lar için kısa bir süre unavailable olması gereken kısa bir pencereyi (dump, transfer, ve restore'un sürdüğü süre) kabul etmek.

# On the old server, right before cutover
mysqldump --single-transaction myapp_db | gzip > final-dump.sql.gz
scp final-dump.sql.gz new-server:/tmp/
# On the new server
gunzip -c /tmp/final-dump.sql.gz | mysql myapp_db

Birkaç dakikalık read-only'nin bile kabul edilemez olduğu siteler için, database replication (yeni server'ı önceden eskinin bir replica'sı olarak kurmak, sonra cutover'da promote etmek) bu boşluğu daha da kapatıyor, ama çoğu küçük-orta ölçekli site için, planlanmış, düşük trafikli bir pencere boyunca "site çalışıyor ama yeni yorumlar/sipariş'ler duraklatılmış" şeklinde birkaç dakika, tek seferlik bir migration için replication kurmanın complexity'sine karşı mantıklı bir trade-off.

Asıl cutover

Yeni server /etc/hosts üzerinden tamamen test edilmiş, TTL zaten düşük, ve son bir database sync yapılmışken, DNS değişikliğinin kendisi neredeyse bir hayal kırıklığı:

example.com.  300  IN  A  198.51.100.20

TTL penceresi içinde, trafik yeni server'a kayıyor. Eski server, hem gerçek trafik altında beklenmedik bir şey çıkarsa fallback olarak, hem de onu eskimiş, cache'lenmiş bir DNS cevabı üzerinden hâlâ ziyaret edenler ölü bir server'la karşılaşmasın diye, sonrasında bir iki gün çalışır ve dokunulmamış halde kalıyor.

Bu neden özel tool'lar olmadan çalışıyor

Bunların hiçbiri migration'a özel yazılım gerektirmiyor, çünkü aceleye getirilmiş bir migration'da "downtime"ın asıl sebebi, testi geçişten sonra yapmak, yeni server zaten tek live olanken problemleri bulmak. Bu sırayı tersine çevirmek, önce tamamen hazır ve test edilmiş, DNS değişikliği en son, ve önemli olduğunda zaten düşük olan bir TTL, cutover'ın kendisini neredeyse bir non-event haline getiren şey. Hazırlık migration'ın kendisi; DNS değişikliği sadece son, en küçük adım.