E-ticarette altyapı sorununun karakteri diğer sektörlerden farklı. Sistem yılın üç yüz altmış günü rahat çalışıyor, birkaç kampanya gününde trafik birkaç katına çıkıyor ve o günlerde kesinti doğrudan gelir kaybı üretiyor. Kararı zorlaştıran şey de bu: kapasiteyi tepe yüke göre kurmak yılın kalanında boşa para, tepe yükü karşılamamak ise en kötü günde kesinti demek.
Altyapıyı zorlayan ne
Birincisi trafiğin öngörülemezliği. Kampanya tarihini siz biliyorsunuz ama gelen yükün ne kadar olacağını bilmiyorsunuz. Geçen yılın rakamı bir referans ama garanti değil; kampanya iletişimi tuttuğunda tahminin iki katı yük gelebiliyor.
İkincisi darboğazın yerinin değişmesi. Yük arttığında ilk teklemeye başlayan bileşen çoğu zaman uygulama sunucusu olmuyor, veri tabanı oluyor. Uygulama katmanını yatay ölçeklemek kolay; veri tabanını ölçeklemek mimari bir karar ve kampanya sabahı verilecek bir karar değil.
Üçüncüsü ödeme akışının kırılganlığı. Sepet ve ürün sayfalarındaki yavaşlama can sıkıcı, ödeme adımındaki hata doğrudan kayıp. Bu yüzden ödeme akışının diğer bileşenlerden ayrıştırılması ve yük altında önceliklendirilmesi gerekiyor.
Dördüncüsü kesintinin ölçülebilir maliyeti. Bu sektörde "bir saat kesinti kaça mal olur" sorusunun net bir cevabı var ve bu, felaket kurtarma yatırımının karşılığını tartışmasız hale getiriyor.
Ölçekleme kararı
Otomatik ölçekleme bu sektörde en çok işe yarayan mekanizma ama her uygulama için uygun değil. Ölçeklenebilmesi için uygulamanın durumu kendi belleğinde tutmuyor olması gerekiyor; oturum bilgisi sunucunun içinde duruyorsa yeni açılan kopyalar işe yaramıyor.
İkinci dikkat noktası ölçeklemenin ne kadar sürede devreye girdiği. Trafik iki dakikada tepe yapıyorsa ve yeni kopyalar üç dakikada hazır oluyorsa ölçekleme geç kalıyor. Bu yüzden kampanya öncesi taban kapasiteyi bir miktar yukarı çekmek, tamamen otomatiğe güvenmekten daha güvenli.
Üçüncüsü maliyet kontrolü. Otomatik ölçekleme üst sınırsız bırakıldığında bir hata döngüsü faturayı hızla büyütebiliyor. Üst sınır tanımlamak ölçeklemenin ayrılmaz parçası. Bunun nasıl kurulduğunu auto-scaling ve self-healing sayfasında anlattık.
Kapsamımızda ne var
Kaynak ihtiyacı zamanla değişen iş yükleri için Cloud Server modeli uygun oluyor; büyürken sunucu değiştirmeniz gerekmiyor. Veri tabanı gibi gecikmeye duyarlı bileşenler içinse tahsisli kaynak tercih ediliyor. Üç modelin farkını VPS, VDS ve Cloud Server karşılaştırmasında açtık.
Kampanya öncesi kapasite planlaması ve sonrası küçültme birlikte yapılıyor. Maliyet tarafında hangi kalemlerin gözden kaçtığını maliyet hesabı yazımızda rakamlarla yazdık.
İzleme tarafında altyapı katmanı kesintisiz izleniyor. Kampanya dönemlerinde uygulama içi metriklerin de görünür olması işe yarıyor; bunu Monitoring as a Service kapsamında veriyoruz. Ödeme akışını taşıyan bileşenlerin ağ tarafında ayrıştırılması zero-trust yaklaşımının parçası.
Kampanya günü nasıl geçiyor
Kampanya dönemlerinde çalışma biçimimiz değişiyor. Öncesinde kapasite planı yapılıyor ve taban kapasite bir miktar yukarı çekiliyor; tamamen otomatik ölçeklemeye güvenmek, trafiğin dakikalar içinde tepe yaptığı durumlarda geç kalıyor.
Kampanya süresince altyapı katmanı yakın izleniyor ve alarm eşikleri normal dönemden farklı ayarlanıyor; sakin dönemde uyarı üretmesi gereken bir değer, kampanya günü normal olabiliyor. Eşikler ayarlanmazsa alarm gürültüsü gerçek sorunu gizliyor.
Kampanya sonrası kapasitenin geri indirilmesi de plana dahil. Bu adım en sık atlanan kısım; yukarı çıkarılan kaynak indirilmediğinde fatura aylarca yüksek kalıyor. Küçültme tarihini kampanya planına baştan yazıyoruz.
Kampanya dışı dönemde de bir iş var: ölçüm toplamak. Normal günün yanıt süreleri, kaynak kullanımı ve hata oranları bilinmeden kampanya günü neyin anormal olduğunu anlamak mümkün olmuyor. Karşılaştırılacak bir taban çizgisi olmadan alınan her karar tahmine dayanıyor.
Nereden başlanır
İlk iş, geçen kampanyanın verisine bakmak. Trafiğin ne kadar sürede tepe yaptığı, hangi bileşenin ilk teklediği ve o sırada yanıt sürelerinin ne olduğu; üçü birden yeni kurulumun tasarımını belirliyor. Bu veri yoksa ilk adım ölçmeye başlamak oluyor.
İkinci iş, uygulamanın ölçeklenmeye hazır olup olmadığını görmek. Oturum yönetimi, dosya yükleme ve arka plan işleri en sık takılan üç yer. Bunlar altyapı tarafında değil uygulama tarafında düzeltiliyor; kampanyaya iki hafta kala fark edilmesi istenmeyen türden şeyler.
Geçişin nasıl planlandığını geçiş süreci sayfasında, hangi katmandan kimin sorumlu olduğunu sorumluluk paylaşımı sayfasında bulabilirsiniz. Diğer sektörler için çözümler sayfasına bakın.
Kampanya öncesi bir yük testi yapmak, bu sektörde en çok karşılığını gören hazırlık adımı. Testin amacı sistemin dayanıp dayanmadığını görmek değil, hangi bileşenin ilk teklediğini bulmak. O bileşen bilindiğinde kampanya günü nereye bakılacağı da belli oluyor. Yük testini geçiş kapsamında birlikte planlayabiliyor ve sonucunu bulgu listesiyle ve önceliklendirmesiyle birlikte yazılı olarak paylaşıyoruz. Ölçeklemenin altındaki mimariyi yüksek erişilebilir Kubernetes sayfasında diyagramla anlattık; destek işleyişi destek ve hizmet seviyeleri sayfasında.