- Tartışmanın özü monolitik mi mikroservis mi değil, dağıtık sistemlerin geliştirme/işletim ek yüküne değecek kadar değer üretip üretmediği sorusudur
- Modern bir tekil sunucu; onlarca ila yüzlerce çekirdek, TB düzeyinde bellek, onlarca ila yüzlerce Gbps I/O ile çoğu web hizmetini kaldıracak yeterli performans payına sahiptir
- Gerçek benchmark'lar, tek bir sunucuyla Nginx 500 bin RPS, PostgreSQL 70 bin IOPS, NoSQL 1 milyon IOPS, 4K kodlama 75 FPS gibi yüksek performanslı işleme yapılabildiğini gösterir
- Cloud kullanmak kolaylık ve erişilebilirliği artırır, ancak maliyet primi yüksektir; yatırımın karşılığını dikkatle değerlendirmek gerekir
- Yalnızca kullanım örüntüsü aşırı derecede dalgalı olduğunda cloud-native ve serverless mimariler maliyet açısından avantaj sağlar
- Ancak serverless/mikro VM yapılandırmalarının maliyet primi büyüktür; iş yükü sürekli/öngörülebilir ise dikey ölçekleme daha ekonomiktir
- Erişilebilirlik, birincil/ikincil (veya 2×2) yedeklilik ve farklı donanım kombinasyonları ile büyük ölçüde çözülebilir; yalnızca CDN ve yedeği dağıtık olarak satın alma stratejisi makuldür
Genel Bakış: Dağıtık sistemler yerine “tek bir büyük sunucu”nun değeri
- “Monolitik vs. mikroservis” tartışmasının özü, dağıtık sistem benimsemenin gerektirdiği gerçek geliştirici zamanı ve maliyetinin buna değip değmediğidir
- Modern yazılımlar sunucu sanallaştırması ve çeşitli soyutlama katmanları üzerinde çalışır; “serverless” ya da “bare metal” de sonuçta fiziksel sunucu kaynakları üzerine kuruludur
- Günümüz sunucuları, düşündüğümüzden daha fazla performans/maliyet verimliliği sunar
- Geçmişe kıyasla sunucu özellikleri çekirdek sayısı, bellek bant genişliği, PCIe hattı ve NVMe depolama açısından sıçrama yapmıştır; birçok hizmet dağıtık yapı olmadan da hedef QPS düzeyine ulaşabilir
Sunucu donanımının güçlü performansı
- Microsoft Azure'un örnek sunucusu, toplam 128 çekirdek 256 thread yapılandırmasına sahip iki adet AMD 3. nesil sunucu CPU içerir
- Tek bir sunucuda 4 TFLOPs düzeyinde hesaplama performansı elde edilebilir; bu, 2000'lerin başındaki süper bilgisayarları aşar
- Soket başına 16 yuvalı DDR4-3200 RAM yerleşimi ile en fazla 8 TB bellek ölçeklenebilirliği sağlanır; pratik satın alma seçeneklerinde de 1 TB bellek desteklenir
- Toplam 128 adet PCIe Gen4 hattı, 30 NVMe SSD ve 50~100Gbps ağ kartı ile yüksek performanslı depolama ve ağ bağlantısı mümkündür
Böyle tek bir sunucuyla yapılabilecekler (benchmark alıntıları)
- 400–800 Gbps video aktarımı, NoSQL 1 milyon IOPS, PostgreSQL 70 bin IOPS, Nginx 500 bin RPS mümkündür
- Linux kernel'i 20 saniyede derleme, x264 4K 75FPS kodlama gibi CPU, bellek ve I/O yoğun işlerde de yüksek çıktı alınır
Sunucu kiralama/satın alma maliyeti karşılaştırması
- OVHCloud: 128 çekirdek/512GB RAM sunucu aylık yaklaşık $1,318'e kiralanabilir
- Hetzner: 32 çekirdek/128GB RAM sunucuyu aylık €140'a sunar; boyuta göre fiyat aralığı değişir
- AWS m6a.metal: 96 fiziksel çekirdek/768GB RAM sunucu saatlik $8.29, aylık yaklaşık $6,055'tir; yani cloud primi yüksektir
- Dell'den benzer özellikte sunucuyu doğrudan satın almak yaklaşık $40,000'dır; cloud'a kıyasla yatırım geri dönüşü yaklaşık 8 ayda mümkündür
- Aynı throughput serverless ile varsayıldığında, maliyet priminin instance'lara göre 5.5 kat, düşük maliyetli hosting'e göre 25 kat olduğu tahmin edilir
Dağıtık sistemler neden öne çıktı
- Geçmişte (2010 civarı), CPU, bellek ve depolama performansı sınırlı olduğu için büyük ölçekli hizmetlerde birden fazla sunucunun birleşimi gerekirdi
- Son yıllarda büyük tekil sunucular, NVMe SSD'ler ve yüksek bellek bant genişliği sayesinde tek düğümün işleme sınırı ciddi biçimde yükseldi; ancak VM ve container birimleri hâlâ küçük sunucu kaynakları temel alınarak tasarlanıyor
Tek bir büyük sunucunun yeterli olduğu durumlar
- 10k QPS altındaki çoğu web hizmeti için tek bir makine yeterlidir; basit hizmetler milyon QPS düzeyine kadar çıkabilir
- Video streaming'de bile control plane için tek bir sunucu gerçekçidir; benchmark'lar ve ortak performans tablolarıyla uygun sunucu boyutu hesaplanabilir
- Özel durumlar dışında, yalnızca ana sunucu ve yedek sunucu kurulumu ile erişilebilirlik sağlamak da yeterlidir
“Yatay” değil “dikey”: büyük sunucu sayısı az, küçük sunucu sayısı çok olmasın
- Cluster gerekse bile birkaç büyük sunucu, çok sayıda küçük sunucuya göre orkestrasyon ek yükünü (O(n)) azaltır
- Yani uzun vadede sunucu sayısını azaltıp özelliklerini büyütmek daha verimlidir
- Serverless ve kısa ömürlü container temelli yapılarda ek yük oranı özellikle daha yüksektir
- Dezavantaj tek hata noktası olmasıdır, ancak birincil/ikincil (farklı DC'lerde) kurulumla bu büyük ölçüde giderilebilir
- Daha sağlam bir yapı için 2×2 kurulum (birincil DC'de 2, ikincil DC'de 2 sunucu) ve farklı donanım/üretim partileri ile ilişkili arıza riski azaltılabilir
- Kiralama durumunda sunucu modeli çeşitlendirmesi ile aynı parti disk/SSD kaynaklı zincirleme arıza riski düşürülebilir
Cloud kullanımının avantajları ve sınırları
- Cloud'un güçlü yanları erişilebilirlik, kurtarma hızı ve operasyonel kolaylıktır; bunun için prim maliyet ödemek anlamlı olabilir
- Kesinti olmadan, bütçe dahilinde hızlı yeniden başlatma mümkündür; grid olarak yönetilen büyük kaynak havuzlarından yararlanılabilir
- Kiralık sunucu sağlayıcıları daha ucuzdur, ancak kalite, ağ ve premium destek açısından sınırlamaları olabilir
- Ancak cloud satış yaklaşımı auto-scale VM, serverless, managed HA DB gibi vendor lock-in yaratan mimarileri teşvik eder; bu yüzden maliyet ve karmaşıklık açısından dikkatli olmak gerekir
- Büyük ölçekli trafiği işlemek tek başına cloud-native'in ana gerekçesi değildir; tek bir büyük sunucu ile de aynı anda milyonlarca kullanıcıya hizmet veren çok sayıda örnek vardır
Tepe yük maliyeti ve bursty yük ölçütü
- Birileri tepe yüke göre kapasite hazırlamak zorundadır; dolayısıyla tepe maliyeti tedarik zincirinin bir yerinde mutlaka faturalandırılır
- Ani ve geçici işler (ör. tek seferlik büyük simülasyonlar) için serverless/auto-scale ekonomiktir; ancak sürekli ve öngörülebilir yükte büyük sunucuyu sabit çalıştırmak daha maliyet verimlidir
- 1 yıllık taahhüt/spot/satış pazarlığı kullanılırsa instance maliyeti daha da düşer, serverless'e kıyasla prim daha da büyür
“Cloud primi”nin nicel değerlendirmesi
- AWS Lambda gibi serverless computing seçeneklerinde, aynı sunucuya kıyasla maliyet primi 5 ila 30 kat olabilir
- Varsayım: Saatlik $8.2944'lık bir sunucu 1k QPS, 768GB RAM sağlıyorsa, aynı throughput'u Lambda ile değiştirmek yaklaşık saatlik $46 ile 5.5 kat prim anlamına gelir
- OVH kiralamasına göre 25 kat prim tahmin edilir; yalnızca %5 kullanım oranı olsa bile düşük maliyetli hosting, serverless'tan daha ekonomiktir
- Uzun vadeli sözleşmeler, spot instance'lar vb. kullanıldığında prim farkı daha da açılabilir
- QPS değişse bile bellek-zaman dönüşümü üzerinden prim katsayısı benzer kalır; asıl kritik nokta sunucuyu iş yükünün boyutuna göre ölçeklemektir
Yaygın itirazlar ve yanlış anlamalar
- “Cloud kullanırsak sistem operasyon ekibine gerek kalmaz”: Sadece rolün adı Cloud Ops olur; dokümantasyon, değişiklik takibi ve deprecation yönetimi hâlâ gerekir, hatta personel maliyetini artırabilir
- “Cloud'da güvenlik güncellemeleriyle uğraşmaya gerek yok”: Bazı alanlarda yük azalır, ancak bu otomasyonun kolay olduğu bölümlerle sınırlıdır; kütüphane denetimi ve yapılandırma doğrulaması yine gerekir
- “Cloud yüksek erişilebilirlik tasarımı sunduğu için içimiz rahat”: Artan karmaşıklık yeni zayıflıklar yaratır; region veya provider yedekliliği bile ilişkili arızaları tamamen ortadan kaldırmaz
- “Cloud geliştirme hızını artırır”: Başlangıç çevikliği bir avantajdır; yine de maliyet kırılma noktasını izleyip zamanında geçiş yapmak gerekir
- “Bizim trafik çok bursty”: Bu durumda serverless ve auto-scale uygundur
- “Peki CDN?”: Gecikme ve bant genişliği tasarrufu için mutlaka dağıtık olarak satın alınması gereken bir bileşendir; yedekleme de benzer şekilde satın alınıp kullanılan bir alandır
Monolitik vs. mikroservis ve sunucu yapısı
- “Büyük sunucu” çoğu zaman monolitik mimari ile ilişkilendirilir, ancak tek bir sunucu üzerinde birden fazla container olarak mikroservis kurmak da mümkündür
- Ancak süreçler arası iletişim, deployment ve gözlemlenebilirlik ek yükü, tek host üzerinde bile maliyet yaratır; bu yüzden karmaşıklığa kıyasla gerçek performans kazanımı ciddi biçimde azalır
- Erken aşama ve orta ölçekli yapılarda monolitik veya az sayıda servis, operasyonel sadelik açısından daha avantajlıdır
Sonuç
- Çoğu durumda yatay ölçekleme veya cloud merkezli mimariler yerine dikey ölçeklemeyi, yani tek bir büyük sunucuyu tercih etmek daha basit ve daha ekonomiktir
- Birincil/ikincil yedeklilik, farklı donanım kullanımı ve CDN/yedek dışsallaştırması birlikte kullanıldığında pratik güvenilirlik sağlanabilir; sürekli yük ortamlarında toplam sahip olma maliyeti (TCO) açısından üstünlük büyüktür
- Sağlam bir donanım yedekliliği stratejisi kurulduğu sürece, “tek bir büyük sunucu” yaklaşımı gerçek hizmetler için son derece uygun bir seçimdir
Henüz yorum yok.