Yazılım dünyasında “sıfır kesinti deploy” (Zero Downtime Deployment - ZDD) kavramı neredeyse bir kutsal kase gibi anılır. Herkes ister, herkes hedefler. Ama ben kendi tecrübelerimde şunu gördüm: Her projenin gerçekten buna ihtiyacı yok. Özellikle küçük ve orta ölçekli işlerde, bu tür bir mimariyi kurmanın ve sürdürmenin maliyeti, getirisinden çok daha fazla olabilir.
Bir üretim ERP’sinde veya büyük bir e-ticaret sitesinde elbette kesinti kabul edilemez. Saniyeler bile para kaybı demek. Ancak kendi yan ürünlerimde veya bir müşterinin iç kullanımına yönelik küçük bir uygulamasında, birkaç dakikalık bir kesinti dünyanın sonu olmuyor. Hatta bazen bu “mola”, kullanıcıların güncelleme olduğunu anlaması için bir işaret bile olabiliyor. Bu yazıda, bu karmaşık deploy stratejilerini ne zaman uygulayıp ne zaman “olur o kadar” diyerek geçiştirdiğimi anlatacağım.
Sıfır Kesinti Deploy Nedir, Ne Değildir?
Sıfır kesinti deploy, adından da anlaşılacağı gibi, kullanıcıların hizmet kesintisi yaşamadan yeni bir yazılım sürümünü devreye alma sürecidir. Temel amacı, deploy sırasında uygulamanın her zaman erişilebilir olmasını sağlamaktır. Bunu yapmanın farklı yolları var: rolling updates, blue-green deployment, canary deployment gibi. Her birinin kendine göre avantajları ve dezavantajları bulunuyor.
Benim deneyimimde, ZDD genellikle birden fazla uygulama instance’ı ve bir yük dengeleyici (load balancer) gerektirir. Yeni sürüm, eski sürümle birlikte çalışır durumda tutulur ve trafik kademeli olarak yeni sürüme yönlendirilir. Peki, ne değildir ZDD? Kötü yazılmış bir kodu sihirli bir şekilde düzeltmez veya hatalı bir veritabanı migrasyonunu görünmez yapmaz. Aslında, bu tür sorunları daha da karmaşık hale getirebilir çünkü birden fazla sürümün aynı anda aktif olması demek, daha fazla potansiyel hata noktası demektir.
Rolling update’ler, uygulamalarınızın stateless olduğu ve her instance’ın birbirinden bağımsız çalıştığı durumlarda oldukça iyi iş çıkarır. Ancak ben birçok projede, özellikle kurumsal yazılımlarda, uygulamanın state’inin veya veritabanı şemasının değiştiği durumlarla karşılaşıyorum. İşte bu noktada sıfır kesinti deploy’un karmaşıklığı katlanarak artıyor.
Maliyet Hesaplaması: Basit Bir Projede Neler Gider?
Sıfır kesinti deploy’u uygulamaya karar verdiğinizde, bunun sadece bir “ayarlayalım olsun bitsin” meselesi olmadığını kısa sürede anlarsınız. Özellikle basit projeler için bu, gereksiz bir yük haline gelebilir. Ben bu yükü genellikle üç ana başlık altında toplarım: altyapı maliyeti, karmaşıklık maliyeti ve insan maliyeti.
Altyapı maliyeti, ek sunucular ve yük dengeleyiciler anlamına gelir. Blue-green deployment için mevcut uygulamanızın iki katı kaynak ayırmanız gerekebilir. Örneğin, benim kendi VPS’imde koşan bir yan ürünüm için ayırdığım kaynak yeterliyken, sıfır kesinti deploy için bunun en az iki katını ayırmam gerekir. Bu da aylık faturaları kabaca ikiye katlayabilir. Bir bankanın iç platformu için bu maliyet devede kulak kalırken, kişisel bir proje veya KOBİ için önemli bir gider kalemidir.
Karmaşıklık maliyeti, CI/CD pipeline’ınızda yapılacak değişikliklerden, rollback stratejilerinin geliştirilmesine kadar birçok alanı kapsar. Deploy sürecini otomatikleştirmeniz, hata durumlarında otomatik geri alma mekanizmaları kurmanız gerekir. Bunların hepsi ek geliştirme ve test zamanı demektir. Bir de üzerine, mevcut ve yeni sürümler arasında API veya veritabanı uyumluluğunu sağlamak için ek iş yükü biner. Bu durum, özellikle küçük ekiplerde, geliştirme hızını ciddi şekilde düşürebilir.
Son olarak, insan maliyeti var. Geliştiricilerin ve operasyon ekiplerinin bu karmaşık sistemleri kurması, anlaması, sorun gidermesi ve sürdürmesi için harcadığı zaman. Bu, projenin büyüklüğüne ve ekibin deneyimine göre değişse de, genellikle beklenenden daha uzun sürer. Basit bir uygulama için blue-green deploy kurmaya çalışırken, altyapı otomasyonu ve testler ciddi zaman alabiliyor. Sonunda, uygulamanın birincil işlevselliğini geliştirmeye ayırmanız gereken zamanı bu altyapıya harcadığınızı fark ediyorsunuz. Bu, basit projelerde kaçınmaya çalıştığım bir trade-off.
Benim “Olur O Kadar” Felsefem ve Küçük Kesintiler
Saha tecrübemde, her zaman %100 uptime hedeflemenin gerçekçi olmadığını öğrendim. Özellikle küçük, dahili kullanılan veya bireysel projelerde, belirli bir seviyede kesintiyi kabul etmek, gereksiz mühendislik ve maliyetten kaçınmak için akıllıca bir strateji olabilir. Ben buna “olur o kadar” felsefesi diyorum.
Bir müşterinin muhasebe departmanı için geliştirdiğim bir raporlama aracını düşünün. Bu araç, sadece mesai saatleri içinde ve belirli aralıklarla kullanılıyor. Gece yarısı veya hafta sonu yapılan birkaç dakikalık bir deploy kesintisi, kimseyi etkilemez. Hatta bazen, uygulamanın yeni bir versiyonunun geldiğini fark etmeleri için kısa bir kesinti daha iyi bile olabilir. Kullanıcılar, “Ha, uygulama güncelleniyor galiba” der ve birkaç dakika sonra yeni özelliklere erişir. Önemli olan, bu kesintinin ne zaman olacağının önceden bildirilmesi ve süresinin makul olmasıdır.
Kullanıcı beklentilerini yönetmek burada kritik. Eğer bir mobil uygulamamda (Android tarafında geliştirdiğim spam engelleyici gibi) bir güncelleme yayınlıyorsam, Play Store’daki süreç zaten birkaç saat hatta bazen günler sürebilir. Bu tür durumlarda, backend’deki kısa bir kesinti uygulamanın genel kullanıcı deneyimini etkilemez çünkü frontend zaten yavaş yavaş güncelleniyor. Önemli olan, bu tür kararları projenin doğasına, kullanıcı kitlesine ve iş kritiklik seviyesine göre vermektir. Her projeyi aynı kalıba sokmaya çalışmak, çoğu zaman daha fazla problem yaratır.
Veritabanı Migrasyonları ve Geriye Uyumluluk (Backward Compatibility) Çıkmazı
Sıfır kesinti deploy’un en büyük zorluklarından biri, veritabanı şeması değişikliklerini yönetmektir. Uygulama kodunu güncelleyip eski ve yeni versiyonları aynı anda çalıştırırken, ikisinin de aynı veritabanıyla uyumlu olması gerekir. Bu, geriye uyumluluk (backward compatibility) kavramını merkeze alır ve işleri inanılmaz derecede karmaşıklaştırır.
Ben bir üretim ERP’sinde çalışırken bu sorunla çok sık karşılaştım. Yeni bir feature geliştirdiğimizde, genellikle yeni bir kolon eklememiz veya mevcut bir kolonun tipini değiştirmemiz gerekiyordu. Sıfır kesinti hedeflediğimizde, bu değişiklikleri atomik ve geriye dönük uyumlu adımlara bölmek zorundaydık. Örneğin, yeni bir kolon eklemek için şu adımları izlerdim:
- Yeni kolonu nullable olarak ekle. (Eski uygulama bu kolonu görmezden gelir.)
- Yeni versiyon uygulamayı deploy et. (Hem eski hem yeni uygulama çalışabilir.)
- Yeni uygulama verileri yeni kolona yazmaya başlar. (Eski uygulama hala eski kolona yazar veya boş bırakır.)
- Veri senkronizasyonu yap (eski kolondaki verileri yeni kolona taşı).
- Eski uygulamayı tamamen devre dışı bırak.
- Yeni kolonu non-nullable yapabilir veya eski kolonu silebilirsin.
Bu “add column, deploy new app, drop old column” dansı, özellikle karmaşık veritabanı şemaları ve yüksek işlem hacimli sistemler için bir zorunluluktur. Ancak bu, aynı zamanda önemli bir mühendislik yükü getirir. Her veritabanı değişikliğini böyle çok adımlı bir plana dönüştürmek, geliştirme hızını yavaşlatır ve hata yapma potansiyelini artırır. Basit projelerde, veritabanı migrasyonları sırasında birkaç dakikalık bir kesintiyi göze almak, bu karmaşıklığı tamamen ortadan kaldırır ve ekibin daha hızlı hareket etmesini sağlar. Monolith vs microservice seçimlerinde de benzer trade-off’lar görüyorum; her zaman en sofistike çözüm en iyisi değildir.
Otomasyon ve Gözlemlenebilirlik (Observability) Yükü
Sıfır kesinti deploy, sadece altyapı ve veritabanı uyumluluğu ile bitmiyor. Bu tür bir stratejiyi başarılı bir şekilde uygulamak için, çok sağlam bir otomasyon ve kapsamlı gözlemlenebilirlik (observability) altyapısına ihtiyacınız var. Bunlar olmadan, sıfır kesinti deploy bir kumar haline gelir ve kesintileri önlemek yerine daha büyük sorunlara yol açabilir.
Otomasyon, CI/CD pipeline’ınızın kusursuz çalışması anlamına gelir. Kod değişiklikleri otomatik olarak test edilmeli, derlenmeli, imajları oluşturulmalı ve hedef ortama deploy edilmelidir. Rolling update veya blue-green deploy gibi karmaşık stratejiler, bu pipeline’ın içinde doğru şekilde orchestre edilmelidir. Benim bir üretim firmasının ERP’sini geliştirirken, bu pipeline’ı kurmak ve stabil hale getirmek hatırı sayılır bir zaman almıştı. Her adımda otomatik sağlık kontrolü, geri alma mekanizmaları ve bildirimler entegre etmiştik. Basit bir proje için bu seviyede bir otomasyonu kurmaya çalışmak, çoğu zaman “fil öldürmek için sinek avlamak” gibi hissettirir.
Gözlemlenebilirlik ise, uygulamanızın performansını ve sağlığını sürekli izlemek demektir. Metrikler, loglar ve trace’ler sayesinde, yeni deploy edilen versiyonun eski versiyona göre daha kötü performans gösterip göstermediğini, beklenmedik hatalar üretip üretmediğini anında görmeniz gerekir. Bu bilgiler, bir sorun anında hızlıca geri alma kararı vermenizi sağlar. Ben kendi yan ürünlerimde bile basit log takibi ve temel metriklerle idare ederken, kurumsal projelerde detaylı tracing ve error budgeting kullanıyorum. Küçük bir projede bu karmaşıklığı kurmak, projenin kendisinden daha fazla efor gerektirebilir. Doğru metrikleri toplamadan bir değişikliğe girişmek, performans regresyonlarını ancak çok geç fark etmenize yol açabilir; bu da gözlemlenebilirliğin önemini gösterir, ama her projenin aynı detay seviyesine ihtiyacı olmadığını da unutmamak gerekir.
Alternatif Yaklaşımlar: Basit Projeler İçin Pratik Çözümler
Her proje sıfır kesinti deploy’a ihtiyaç duymaz, bu benim net pozisyonum. Özellikle küçük ve orta ölçekli projeler için, ZDD’nin getirdiği yükten kaçınmak ve yine de iyi bir kullanıcı deneyimi sunmak için daha pratik ve basit alternatifler mevcut. Bu alternatifler, maliyeti düşük tutarken, deploy sürecini yönetilebilir ve öngörülebilir hale getiriyor.
Birinci yaklaşım, planlı kesinti ile deploy yapmaktır. Bu, özellikle dahili kullanılan uygulamalar veya belirli bir coğrafi bölgedeki kullanıcıların aktif olmadığı zaman dilimlerinde çok etkilidir. Kullanıcılara önceden bilgi verilir (“Cumartesi gecesi 02:00-03:00 arası bakım çalışması yapılacaktır”) ve bu süre zarfında uygulama kapalı kalır. Bu sayede, deploy ekibi daha az stresle çalışır ve karmaşık ZDD mekanizmaları kurmaya gerek kalmaz. Ben kendi finansal hesaplayıcılarımın backend’ini güncellerken bu yöntemi kullanıyorum; gece saatlerinde yaptığım kısa bir kesinti kimseyi rahatsız etmiyor.
İkinci alternatif, hızlı geri alma (fast rollback) mekanizmaları üzerine odaklanmaktır. Eğer deploy sırasında bir sorun çıkarsa, hızlıca önceki stabil sürüme dönebilmelisiniz. Bu, genellikle deploy edilen imajların (Docker imajları gibi) veya sanal makine snapshot’larının hazır tutulmasıyla sağlanır. Yeni bir deploy yapmadan önce, eski sürümün tüm bileşenlerini (uygulama kodu, veritabanı yedeği, konfigürasyon) bir “rollback noktası” olarak kaydetmek, olası felaketlerin önüne geçebilir. Ben kendi VPS’imde koşan Docker Compose uygulamalarımı güncellerken, her zaman bir önceki docker-compose.yml dosyasını ve uygulama imajlarını hazır tutarım. Böylece bir sorun olduğunda birkaç docker-compose down && docker-compose up -d komutuyla geri dönebilirim.
Bu yaklaşımlar, sıfır kesinti deploy’un getirdiği karmaşıklığı ve maliyeti önemli ölçüde azaltır. Projenin gerçek ihtiyaçlarına odaklanarak, gereksiz mühendislikten kaçınmak ve yine de güvenilir, yönetilebilir bir deploy süreci oluşturmak mümkün. Özellikle hızlı iterasyon gereken projelerde, bu basitlik bana daha fazla esneklik sağlıyor.
Sonuç: Doğru Aracı Doğru İşe Kullanmak
Sıfır kesinti deploy, şüphesiz güçlü ve önemli bir stratejidir. Büyük ölçekli, iş kritik sistemler için vazgeçilmezdir. Ancak saha tecrübemde gördüğüm şey, her projenin bu seviyede bir karmaşıklığa ihtiyaç duymadığıdır. Özellikle küçük ve orta ölçekli projelerde, sıfır kesinti deploy kurmanın ve sürdürmenin maliyeti, getireceği faydanın çok ötesine geçebilir.
Maliyet hesaplaması, veritabanı migrasyonlarının getirdiği geriye uyumluluk zorlukları, kapsamlı otomasyon ve gözlemlenebilirlik altyapısının gerekliliği, basit projeler için gereksiz yükler oluşturur. Bu yükler, geliştirme hızını yavaşlatır, operasyonel karmaşıklığı artırır ve bütçeyi zorlar. Benim “olur o kadar” felsefem, bu tür durumlarda devreye girer. Planlı kesintilerle, basit bakım sayfalarıyla veya hızlı geri alma mekanizmalarıyla, kullanıcıları çok fazla etkilemeden ve gereksiz mühendislik yapmadan deploy süreçlerini yönetmek mümkün.
Özetle, her zaman en sofistike çözümü uygulamaya çalışmak yerine, projenin gerçek ihtiyaçlarını, kullanıcı beklentilerini ve mevcut kaynakları göz önünde bulundurarak pragmatik bir yaklaşım sergilemek en doğrusudur. Sıfır kesinti deploy, doğru araçtır, ancak her iş için değil. Bir sonraki yazımda, network segmentasyonu yaparken karşılaştığım VLAN tagging karmaşasını ve bunun getirdiği sinsi sorunları anlatacağım.