Blue-green vs canary dağıtımları: API ve veritabanı değişikliklerini daha güvenli yapmak

Neden şema değişiklikleri ve yavaş mobil güncellemeler dağıtımları riskli hale getirir

Bir deploy testlerde mükemmel görünebilir ve gerçek trafik geldiği anda başarısız olabilir. Genelde sebep, sadece kodunuzun değişmemiş olmasıdır—API sözleşmeniz ve veritabanı şemanız da değişir ve bunlar nadiren aynı hızda ilerler.

Sistem parçaları "doğru" hakkında fikir birliğine varamadığında işler bozulur. Yeni backend var olmayan bir sütunu bekleyebilir. Eski bir backend yeni kodun artık anlamadığı bir formatta veri yazabilir. Alan adını değiştirmek, validasyonu sıkılaştırmak veya bir enum değerini değiştirmek gibi küçük değişiklikler bile prod ortamında hatalara yol açabilir.

Mobil uygulamalar riski artırır çünkü eski sürümler uzun süre kalır. Bazı kullanıcılar dakikalar içinde günceller, bazıları haftalarca güncellemez. Bu, backend’inizin aynı anda birden fazla istemci nesline hizmet vermesi gerektiği anlamına gelir. Eğer yalnızca en yeni uygulama ile çalışan bir API yayınlarsanız, bir grup kullanıcının ödeme, kayıt veya arka plan senkronizasyonu bozulabilir ve bunu hemen fark etmeyebilirsiniz.

"Kesinti riski" yalnızca sitenin kapalı olması değildir. Gerçek sistemlerde genelde kısmi arızalar şeklinde görünür:

• belirli uç noktalarda diğer her şey iyi görünürken 4xx/5xx hatalarında ani artış
• tokenlar, roller veya kullanıcı kayıtları beklentiyle eşleşmediği için girişlerin başarısız olması
• günler sonra ortaya çıkan sessiz veri sorunları (yanlış varsayılanlar, kırpılmış metin, eksik ilişkiler)
• sıkışan arka plan işlerince saatler süren kuyruk birikmeleri

Bu yüzden ekipler blue-green ve canary dağıtımlarını karşılaştırır: uyumsuz değişiklikler olduğunda etki alanını azaltmaya çalışıyorsunuz.

Blue-green ve canary basitçe

Blue-green ve canary dağıtımlarını karşılaştırırken genelde cevaplanan soru şudur: büyük, kontrollü bir geçiş mi yoksa küçük, temkinli bir test mi istiyorsunuz?

Blue-green: iki tam sürüm ve bir trafik geçişi

Blue-green, aynı anda iki eksiksiz ortam çalıştırdığınız anlamına gelir. "Blue" mevcut sürümü kullanıcılara sunar. "Green" yeni sürümdür; paralel olarak deploy edilir ve test edilir. Hazır olduğunuzda trafiği blue’dan green’e geçirirsiniz.

Bu yaklaşım öngörülebilirlik için iyidir. Yeni sürümü üretim-benzeri ayarlarla doğrulayabilir ve ardından temiz bir geçiş yapabilirsiniz.

Geri alma da basittir: geçiş sonrası bir sorun olursa trafiği blue’a geri yönlendirirsiniz. Bu çoğunlukla hızlı bir geri dönüş sağlar, ancak cache’ler, arka plan işler ve veri değişiklikleri kurtarmayı karmaşıklaştırabilir.

Canary: önce küçük bir yüzdeye gönderin

Canary, yeni sürümün önce küçük bir kullanıcı dilimine veya isteğe açılması anlamına gelir. Sağlıklı görünürse bu yüzdelik adım adım arttırılır ta ki herkes için sunulana kadar.

Canary, gerçek trafik altında bilinmeyen davranışlardan endişe duyduğunuzda en iyi seçenektir. Sorunları çoğu kullanıcı hissetmeden önce yakalayabilirsiniz.

Geri alma, canary yüzdesini sıfıra düşürmek (veya yeni sürüme yönlendirmeyi durdurmak) ile yapılır. Genelde hızlıdır ama her zaman temiz değildir; çünkü bazı kullanıcılar zaten veri veya durum oluşturmuş olabilir ve her iki sürümün bunu ele alması gerekir.

Açık bir özet:

• Blue-green temiz geçişleri ve hızlı geri dönüşleri tercih eder.
• Canary gerçek trafikten öğrenmeyi ve sınırlı etki alanını tercih eder.
• Hiçbiri veritabanı riskini otomatik olarak çözmez. Şema uyumsuzsa her ikisi de başarısız olabilir.
• Canary canlı sinyallere dayandığı için izlemeye bağımlıdır.
• Blue-green genellikle iki tam stack çalıştırdığınız için ekstra kapasite gerektirir.

Örnek: API’niz bazen yeni bir alan döndürecekse, bir canary eski istemcilerin beklenmedik veride çökmeye yatkın olup olmadığını görmenizi sağlar. Değişiklik eski kodun başa çıkamayacağı bir sütun yeniden adlandırma gerektiriyorsa, blue-green yalnızca şema her iki sürümü de destekleyecek şekilde tasarlanmışsa sizi kurtarır.

Veritabanı migrasyonlarını kod deploylarından farklı kılan nedir

Kod deploy’u genelde geri almak kolaydır. Yeni sürüm kötü davranıyorsa eski build’i yeniden deploy edersiniz ve çoğunlukla eski duruma dönersiniz.

Veritabanı değişikliği farklıdır çünkü verinin şeklini değiştirir. Satırlar yeniden yazıldıysa, sütunlar düşürüldüyse veya kısıtlamalar sıkılaştırıldıysa geri dönmek nadiren instant olur. Kod geri alsanız bile eski kod yeni şemayı anlamayabilir.

Bu yüzden şema migrasyonundaki kesinti riski çoğunlukla deploy yönteminden çok migrasyonun nasıl tasarlandığıyla ilgilidir.

Çevrimiçi migrasyon (online migration) temelleri

En güvenli migrasyonlar eski ve yeni uygulama sürümleri aynı anda çalışırken işe yaraması için tasarlanandır. Desen basittir: görmezden gelinebilecek bir değişiklik yapın, kodu bunu kullanacak şekilde güncelleyin, sonra temizleyin.

Yaygın bir genişletme-ardından-kısıtlama (expand-then-contract) dizisi şu şekildedir:

• İlk önce ekleyici değişiklikler: nullable bir sütun ekleyin, yeni bir tablo ekleyin, yazmaları kilitlemeyen bir şekilde indeks ekleyin.
• Çift davranış: hem eski hem yeni yere yazın veya yeni’den okuyup eskisine geri dönün.
• Backfill ayrı yürütülür: mevcut veriyi küçük partiler halinde taşıyın.
• Geçiş yapın: trafiğin çoğunu yeni davranışa kaydırın.
• Yıkıcı değişiklikler en sona: eski sütunları düşürün, eski kod yollarını kaldırın, kısıtlamaları sıkılaştırın.

"Big bang" migrasyonlar en riskli adımları tek bir release’te birleştirir: uzun kilitler, ağır backfill’ler ve kodun her yerde yeni şemayı varsaydığı durumlar.

Neden yavaş mobil güncellemeler işi zorlaştırır

Mobil istemciler haftalarca eski sürümlerde kalabilir. Backend’iniz eski istekleri gönderen ve eski yanıtları bekleyen istemcilere hizmet vermeye devam etmelidir.

Eğer eski bir uygulama yeni alan olmadan istek gönderiyorsa, sunucunuz bu alanı veritabanında aniden zorunlu hale getiremez. Her iki davranışın da çalıştığı bir dönem gerekir.

Şema migrasyonları için hangi strateji kesinti riskini azaltır

En güvenli seçim, deploy aracından çok şu soruya bağlıdır: eski ve yeni uygulama sürümleri aynı veritabanı şemasında bir süre boyunca doğru çalışabilir mi?

Cevap evet ise, blue-green genellikle en düşük kesinti seçeneğidir. Veritabanı değişikliğini önce hazırlayabilir, trafiği eski stack’te tutup sonra yeni stack’e tek seferde geçirebilirsiniz. Bir şey ters giderse hızlıca geri dönebilirsiniz.

Blue-green, yeni uygulama yeni şemayı anında gerektirdiğinde başarısız olur. Yaygın örnekler: eski sürümün hala okuduğu bir sütunun düşürülmesi veya NOT NULL kısıtlamasının uygulamanın değeri yazmadan önce eklenmesi. Bu durumlarda geri alma güvenli olmayabilir çünkü veritabanı zaten uyumsuzdur.

Canary, kontrollü öğrenme gerektiğinde daha iyidir. Yeni sürüm önce küçük bir gerçek trafik dilimine açılır; böylece eksik indeksler, beklenmeyen sorgu desenleri veya arka plan işlerinin üretim yükü altındaki farklı davranışları gibi kenar durumları görebilirsiniz. Dezavantajı, her iki sürümün aynı anda çalışmasını gerektirdiği için genelde geriye dönük uyumlu veritabanı değişiklikleri yapmanızdır.

Pratik bir karar kuralı

Blue-green vs canary arasında şema migrasyon kesinti riski için karar verirken:

• Şema değişikliğini ekleyici ve uyumlu tutabiliyorsanız ve hızlı, temiz bir geçiş istiyorsanız blue-green seçin.
• Değişikliğin prod ortamında nasıl davranacağını bilmiyorsanız veya nadir veri şekillerinin önemli olacağını tahmin ediyorsanız canary seçin.
• Eğer migrasyon anında kırıcı bir değişiklik zorluyorsa, blue-green veya canary arasında seçim yapmayın—planı değiştirin ve expand-then-contract yaklaşımına geçin.

"Uyumlu" gerçek hayatta nasıl görünür

orders tablosuna yeni bir alan eklediğinizi varsayın. Güvenli yol: sütunu nullable olarak ekleyin, bunu yazan uygulamayı dağıtın, eski satırları backfill edin, sonra kısıtlamaları devreye alın. Bu setup’ta blue-green temiz bir geçiş sağlar; canary ise bazı kod yollarının hala eski şekli varsayıp varsaymadığını erken uyarır.

Yavaş mobil güncellemeler dağıtım seçimini nasıl etkiler

Web kullanıcıları sayfayı yeniler. Mobil kullanıcılar yenilemez.

iOS ve Android’de insanlar eski sürümlerde haftalarca veya aylarca kalır. Bazıları cihazı hiç güncellemez. Bu, "eski" istemcinin yeni backend’i uzun süre çağırmaya devam edeceği anlamına gelir. Eski mobil istemciler sizin için sürekli bir geriye dönük uyumluluk testi haline gelir.

Bu, hedefi "kesinti olmadan deploy etmek"ten "aynı anda birden fazla istemci jenerasyonunu çalışır tutmak"a kaydırır. Pratikte mobil, altyapı için blue-green kullansanız bile API’lerde canary-benzeri düşünceyi teşvik eder.

Geriye dönük uyumlu değişiklikler vs API versiyonlama

Çoğu zaman geriye dönük uyumlu değişiklikler istersiniz, çünkü böylece eski ve yeni uygulamalar aynı endpointleri paylaşabilir.

Geriye dönük uyumlu örnekler: yeni alanlar eklemek, hem eski hem yeni payload şekillerini kabul etmek, mevcut yanıt alanlarını korumak ve anlam değişikliklerinden kaçınmak.

Davranışın değişmesi gerektiğinde (sadece veri eklenmesi değilse) veya alanları kaldırmanız/yeniden adlandırmanız gerekiyorsa mobil için API versiyonlaması faydalı olur.

Örnek: marketing_opt_in gibi opsiyonel bir alan eklemek genelde güvenlidir. price hesaplamasını değiştirmek genelde güvenli değildir.

Bir kullanım dışı bırakma (deprecation) penceresi planlama

Eğer kırıcı bir değişiklik gerekiyorsa, desteği sonlandırma kararı bir ürün kararı gibi ele alınmalı. Yararlı bir deprecation penceresi, takvim günleriyle değil "eski sürümlerdeki aktif kullanıcılar" ile ölçülür.

Pratik bir sıra:

• Hem eski hem yeni istemcileri destekleyen backend’i gönderin.
• Yeni mobil uygulamayı yayınlayın ve sürüm bazında benimsemeyi izleyin.
• Eski sürümler güvenli eşik altına düştüğünde uyarın veya kısıtlayın.
• Eski davranışı en sonda kaldırın ve bir geri alma planı bulundurun.

Adım adım: API + veritabanı değişiklikleri için güvenli bir rollout

API ve veritabanını aynı anda değiştirdiğinizde, en güvenli plan genelde iki veya üç aşamalı bir rollout’tur. Her adım kendi başına güvenli olarak deploy edilebilmeli, hatta kullanıcılar haftalarca eski mobil uygulamayı kullanmaya devam etse bile sorun çıkarmamalıdır.

Eski istemcileri kırmayan bir rollout deseni

Önce ekleyici veritabanı değişikliği ile başlayın. Yeni sütunlar veya tablolar ekleyin, yeniden adlandırma veya düşürmeden kaçının, gerektiğinde null kabul edin ve eski kodun aniden kısıtlamalara takılmaması için varsayılanlar kullanın.

Sonra hem şekilleri tolere eden uygulama kodunu yayınlayın. Okumalar "yeni alan eksik" ve "yeni alan mevcut" durumlarını kabul etmeli. Yazmalar şimdilik eski alanı yazmaya devam etmeli ve isteğe bağlı olarak yeni alanı da yazmalıdır.

Tipik sıra:

• Yeni şema parçalarını (sütunlar, tablolar, indeksler) ekleyin, eski olanları kaldırmayın.
• Hem eski hem yeni şeklini kabul eden kodu deploy edin ve null’larda çökmeden çalıştığından emin olun.
• Mevcut satırları küçük partiler halinde backfill edin, sonra sayımları, null oranlarını ve sorgu performansını doğrulayın.
• Yazma yolunu yeni alana kaydırın, geri dönüş okumalarını koruyun.
• Eski mobil sürümler azaldığında eski alanı kaldırın ve temizliği yapın.

Backfill ve doğrulama: kesintilerin saklandığı yer

Backfill’ler çoğunlukla hızlı bir script gibi ele alındığı için başarısız olur. Bunları kademeli çalıştırın, yükü izleyin ve sonuçları doğrulayın. Yeni davranış bir indeks gerektiriyorsa, okumaları/yazmaları değiştirmeden önce indeksi ekleyin, sonradan değil.

Örnek: biçimlendirmeyi iyileştirmek için phone_country_code ekliyorsunuz. Önce sütunu nullable olarak ekleyin, API’yı bunu kabul edecek şekilde güncelleyin ama eksikse çalışmaya devam etsin, mevcut numaralardan backfill yapın, sonra yeni kayıtlar için yazmaya başlayın. Haftalar sonra eski uygulama sürümleri büyük ölçüde kaybolduğunda eski parsing yolunu kaldırabilirsiniz.

Her iki stratejiyi de daha güvenli yapan araçlar (aşırıya kaçmadan)

Blue-green veya canary’yi daha güvenli kılmak için karmaşık bir kurulum gerekmez. Birkaç alışkanlık, API ve veritabanı şemaları farklı hızlarda ilerlerken sürprizleri azaltır.

Çift-okuma ve çift-yazma (geçici tutun)

Dual-write uygulama geçiş sırasında veriyi hem eski hem yeni yerlere yazar. Dual-read ise genellikle yeni alanı tercih eder ama yoksa eskiye döner.

Bu, yavaş istemci güncellemeleri için zaman kazandırır ama kısa süreli bir köprüdür. Nasıl kaldırılacağını belirleyin, hangi yolun kullanıldığını izleyin ve her iki yazmanın tutarlı kaldığını basit kontrollerle doğrulayın.

Davranış değişiklikleri için feature flag’ler

Feature flag’ler riskli davranışı kapalı tutarak kodu dağıtmanıza izin verir. Bu, hem blue-green hem de canary’de "deploy" ile "açmak" adımlarını ayırmanızı sağlar.

Örnek: yeni bir yanıt alanı için kodu deploy edin ama sunucunun eski şekli geri döndürmesini sağlayın. Sonra yeni davranışı küçük bir grupta etkinleştirin, hataları izleyin ve kademeli olarak yaygınlaştırın. Bir şey ters giderse flag’i kapatın.

Sözleşme testi (contract testing) zihniyeti (API bir vaatdir)

Birçok migrasyon olayı aslında "veritabanı problemi" değildir. Bunlar istemci beklenti problemleridir.

API’yı bir vaat olarak görün. Alanları kaldırmaktan veya anlamlarını değiştirmekten kaçının. Bilinmeyen alanları opsiyonel tutun. Ekleyici değişiklikler genelde güvenlidir. Kırıcı değişiklikler yeni bir API versiyonunu beklemelidir.

Güvenilir veri migrasyon işleri

Şema migrasyonları genelde veri kopyalamak, değer hesaplamak veya temizlemek için backfill job’ları gerektirir. Bu işler tekrar çalıştırılabilir, hata toleranslı, yeniden denemeye uygun, izlenebilir ve yükü fırlatmayacak şekilde kısıtlanmış olmalıdır.

Migrasyon sırasında kesintiye yol açan yaygın hatalar

Çoğu migrasyon kesintisi, bir sürümün her şeyin birlikte hareket edeceğini varsaymasıyla olur: tüm servisler aynı anda deploy edilir, tüm veri temizdir ve tüm istemciler zamanında güncellenir. Gerçek sistemler böyle çalışmaz, özellikle mobil tarafında.

Yaygın hata kalıpları:

• Bir sütunu çok erken düşürmek veya yeniden adlandırmak. Eski API kodu, arka plan işler veya eski mobil uygulamalar hala onu kullanıyor olabilir.
• İstemcilerin hızlı güncelleneceğini varsaymak. Mobil yayınlar kullanıcı tabanına yayılmak için zaman alır.
• Yoğun saatlerde büyük tabloları kilitleyen migrasyonlar çalıştırmak. "Basit" bir indeks veya sütun değişikliği yazmaları engelleyebilir.
• Sadece temiz örnek verilerle test etmek. Üretim verisi null’lar, tuhaf formatlar, çoğaltmalar ve miras değerleri içerir.
• Kod ve veri için gerçek bir geri alma planının olmaması. "Önceki sürümü yeniden deploy ederiz" demek, şema değiştiyse yeterli değildir.

Örnek: status sütununu order_status olarak yeniden adlandırıp yeni API’yı deploy ediyorsunuz. Web uygulaması çalışıyor. Eski mobil istemciler hala status gönderiyor ve API bu istekleri reddediyor, checkout’lar başarısız oluyor. Eğer sütunu düşürdüyseniz, davranışı eski haline getirmek hızlı bir geçiş değildir.

Daha iyi varsayılan: değişiklikleri küçük, geri alınabilir adımlarla yapın, eski ve yeni yolları birlikte çalışır durumda tutun ve metrikler fırladığında ne yapacağınızı yazılı tutun (trafik nasıl yönlendirilecek, hangi feature flag yeni davranışı kapatır, backfill yanlış giderse veriyi nasıl doğrulayacak/onaracaksınız gibi).

Deploy öncesi hızlı kontrol listesi

Bir release öncesi kısa bir kontrol listesi, gece yarısı geri almalarına yol açan sorunları yakalar. Bu özellikle API ve veritabanını aynı anda değiştirirken ve mobil güncellemeler yavaş olduğunda önemlidir.

Çoğu kesintiyi önleyen beş kontrol

• Uyumluluk: hem eski hem yeni uygulama sürümlerinin aynı veritabanı şemasıyla çalıştığını doğrulayın. Pratik bir test, mevcut production build’i yeni migration uygulanmış bir staging veritabanına karşı çalıştırmaktır.
• Migration sıralaması: ilk migration ekleyici olsun; yıkıcı değişiklikleri (sütun düşürme, kısıtlama sıkılaştırma) daha sonra planlayın.
• Geri alma: en hızlı geri alma adımını tanımlayın. Blue-green için trafiği geri çevirmek, canary için stabil sürüme %100 trafiği göndermek. Eğer geri alma başka bir migration gerektiriyorsa, bu basit değildir.
• Performans: sadece doğruluğu değil şema değişikliğinden sonra sorgu gecikmesini ölçün. Eksik bir indeks bir uç noktayı neredeyse kullanılamaz hale getirebilir.
• İstemci gerçeği: API’nizi hala çağıran en eski aktif mobil uygulama sürümünü tespit edin. Anlamlı bir yüzde hala eski sürümdeyse, daha uzun bir uyumluluk penceresi planlayın.

Hızlı bir akıl senaryosu

preferred_language gibi yeni bir alan ekliyorsanız, önce veritabanı değişikliğini nullable olarak uygulayın. Sonra sunucu kodunu yayınlayın—alan varsa kullanır, yoksa çalışmaya devam eder. Çoğu trafik güncellendikten sonra zorunlu hale getirin veya eski davranışı kaldırın.

Örnek: eski mobil uygulamaları bozmadan yeni alan eklemek

Bir profil alanı country ekliyorsunuz ve iş bunu zorunlu kılmak istiyor. Bu iki yerde kırılmaya yol açabilir: eski istemciler alan göndermeyebilir ve veritabanı NOT NULL uyguluyorsa yazmaları reddedebilir.

Daha güvenli yaklaşım iki ayrı değişikliktir: önce alanı geriye dönük uyumlu şekilde ekleyin, sonra istemciler yakaladıktan sonra "zorunlu" yapın.

Blue-green ile nasıl görünür

Blue-green ile yeni sürümü eskisinin yanında deploy edersiniz. Yine de veritabanı değişikliğinin her iki sürümü de desteklemesi gerekir.

Güvenli bir akış:

• migration’ı deploy edin (country nullable olarak ekleyin)
• eksik country durumunda fallback kullanan green sürümü deploy edin
• önemli akışları green üzerinde test edin (kayıt, profil düzenleme, ödeme)
• trafiği değiştirin

Bir şey ters giderse geri dönün. Geri dönüşün çalışması için şemanın hala eski sürümü desteklemesi gerekir.

Canary ile nasıl görünür

Canary’de yeni API davranışını önce küçük bir dilime (genelde %1–%5) açarsınız ve eksik alan doğrulama hataları, gecikme değişimleri ve beklenmeyen veritabanı hatalarını izlersiniz.

Sık görülen sürpriz: eski mobil istemciler country göndermeden profil güncellemesi yapar. API bunu hemen zorunlu kabul ederse 400 hataları görürsünüz. Eğer veritabanı NOT NULL ise 500 hataları ile karşılaşabilirsiniz.

Daha güvenli sıra:

• country nullable olarak ekleyin (isteğe bağlı güvenli varsayılan: "unknown")
• eski istemcilerden gelen eksik country değerini kabul edin
• mevcut kullanıcılar için background job ile backfill yapın
• daha sonra önce API’da sonra veritabanında "zorunlu" doğrulamayı etkinleştirin

Yayın sonrası, eski istemcilerin ne gönderebileceğini ve sunucunun ne garanti ettiğini belgeleyin. Bu yazılı sözleşme, bir sonraki migrasyonda aynı kırılmaları önler.

Eğer AppMaster (appmaster.io) ile geliştiriyorsanız, aynı rollout disiplini geçerlidir: tek bir modelden backend, web ve native mobil uygulamalar üretebilirsiniz. Platformu kullanarak önce ekleyici şema değişiklikleri ve toleranslı API mantığı yayınlayın, benimseme yeterince yüksek olunca kısıtlamaları sıkılaştırın.