Olağanüstü trafik ile nasıl başa çıkılır???
Öncelikle sektördeki dostumuz ve rakibimiz sahibinden.com ailesine 3 Ocak 2024 tarihinde yaşadıkları kesinti sebebiyle geçmiş olsun dileyerek yazımıza başlamak isteriz…
3 Ocak 2024 tarihinde arabam.com IT ekibi olarak sistemlerimizde anormal bir yoğunluk hissetmeye başladık. İlk başta sistemlerimize “DDoS saldırısı (DDoS Attack)” olduğunu düşündük. Tüm ekip olarak gerekli noktalarda incelemelerimizi yapmaya başladık. Kısa bir süre sonra rakibimiz sahibinden.com ‘a erişilemediği haberlerini aldık. Bu haber bu ani ve anormal artışın sebebini açıklıyor gibiydi. Bazı kullanıcılar alternatif olarak ya da başka sebeplerle arabam.com ’a yönelmeye başlamıştı. Yapılan kontrollerimizde de bunun “bir atak” değil “doğal (organik)” bir yoğunluk olduğu belli olmuştu.
Sistemlerimiz anormal durumlar ve diğer faktörleri de katarak 3 katına kadar yük alacak şekilde tasarlandı. Diğer sektörler gibi anlık bir şekilde artışına sebep olan kampanya dönemlerimiz (bkz: kara cuma, çılgın kasım, harika ekim) olmadığını, trafik artışlarının göreceli olarak daha öngörülebilir olduğunu söyleyebiliriz.
Sistemlerimizdeki bu yoğunluk ilk 1–2 saati hızlı bir artış grafiği ve sonrasında aynı seviyede kalarak yaklaşık 7–8 saat sürdü.
(daha sonra rakibimizin sorunu düzeldi)
Bu süreçte oldukça yüksek, beklentilerimizin üzerinde trafiklere ulaştık. Bu anlık yüksek trafiğin sistemlerimizde bir çok noktada beklenmedik sorunlar oluşturması olasıydı, kaynak tüketimleri ve dar boğazlar oluşabilirdi (ki yer yer bunları gözlemledik). Buna yönelik devops ekibi olarak daha önce kurduğumuz monitoring sistemleriyle eş zamanlı olarak alt yapımızı ve kaynaklarımızı izlemeye başladık. arabam.com devops ekibi olarak open source teknolojileri kullanmayı ve destek vermeyi şirket kültürü haline getirdik. Yapımız “cloud native standard”larına göre yatayda büyüyebilecek (horizontal scaling) şekilde tasarlanmış durumdaydı.
Sorun yaratabilecek bazı noktalarda (elimizden geldiğince) hızlı aksiyon almaya çalışarak sistemlerimizde yaşanan bu yoğunluğu karşılayabilecek ön hazırlıklarımızı sorunsuz bir şekilde devreye almayı başardık ve süreç içerisinde kısa süreli yavaşlamalar dışında herhangi bir kopukluk (down) yaşamadık.
Ekip olarak farklı durumlardan bir şeyler öğrenmeyi düstur edindik. Uzaktan çalışsak da çok hızlı bir şekilde “gather” üzerinden bir araya geldik. Gather, bizim online ofisimiz :)
Bir grup toplandığında burada tüm ekibimiz görüntüleyebiliyor ve eşlik edebiliyor. Detaylı bilgi için ekip arkadaşımızın yazısına göz atabilirsiniz.
Şimdi de bu süreçte neler yaşadık, neler yaptık teknik olarak sizlerle paylaşmak istedik.
Monitoring
Yük geldiğinde “elasticsearch cluster”ımızda bir darboğaz olacağını tahmin edebiliyorduk. GCP veya AWS gibi provider’ları kullanmadığımız için cluster’a worker node eklemek biraz zaman alabiliyor bu esnada otomasyon sistemlerini kullanarak yapıya yeni worker’lar eklendi.
Bu arada vakit kazanabilmek için response cache için kullandığımız sistemde, optimizasyon yaparak, cluster’a linux sunucu ekleyebilmek için vakit kazanıldı.
Response cache süresini arttırmak veya yoğun istek alan endpointlerin cache’lenmesi hayat kurtarıcı oluyor. Yine bu noktada merkezi kurduğumuz izleme ile hem mobil uygulamadan hem de web’den yoğun istek alan yerleri hızlıca tespit ettik ve buna göre güncellemelerimizi yaptık. Gün içinde kesintisiz deployment yapabildiğimiz için değişiklikleri anında yansıtabildik. Gerçek trafikte, yük testinde farketmediğimiz noktalar açıga çıktı. Bu tip uygulamalar için de çok hızlı bir sekilde güncellemeler (fix deployment) çıkarak yoğunluğun azaldığını anlık olarak görüntüledik.
Loadbalancer
Load balancer tarafında DDOS veya L7 ataklara karşı kurguladığımız yapının aslında çok daha fazla yüke karşı sorunsuz çalışabileceğini gözlemledik ve bu tarafta alınan herhangi bir aksiyon olmadı. L4 seviyesinde 2 adet instance, session’ları arka taraftaki reverse proxy’lere iletmek ile sorumlu idi. Burada yaşayacağımız en büyük problem, L4 tarafında hızlı bir şekilde açılan sessionların linux işletim sisteminde 65535 adet port’u doldurması olabilirdi.
Bunu daha önceden tahminleyip, her bir L4 HAProxy başına 5 adet virtual interface tanımı yaparak bertaraf edilmiş oldu.
Kubernetes
arabam.com aslında en başından beri bir ilan sitesi olduğu için problemin yaşandığı gün listeleme servislerinin ağır yüke gireceğini tahmin edebiliyorduk. Bu tarafta da herhangi bir aksiyon almaya gerek kalmadan, listing servislerimiz kubernetes cluster’ı içerisinde yüke göre scale olup, gelen yükü karşıladı.
arabam.com olarak mikroservis mimarisine geçmemiz bu süreçte gelen yüke göre hareket edebilen bir mimari üzerinde çalışmamız sebebi ile tüm siteyi etkileyecek herhangi bir major (ciddi) problem ile karşılaşmadık.
Eğer dışarıya açık (public) bir sisteminiz varsa (örneğin: bir e-ticaret platformu, ilan sitesi ya da push notification hizmeti veren platform) sistemleriniz 7x24 kesintisiz olmak zorundadır. Kullanıcılarınız sizden hep aynı kalitede hizmet almak isteyecektir.
Varolan yapıda sistemleriniz (sunucularınız, backend sistemleriniz, vs..) normal şartlarda iyi çalışıyor ve sorun yaşanmıyor olabilir. Siz günlük veya saatlik ortalama kullanıcı sayılarınızı zaten iyi takip ediyor olabilirsiniz. Ancak dışarıya açık sistemlerde kısa bir süre içerisinde normalden çok daha fazla kullanıcı ile karşılaşma durumunu göz ardı etmemeniz gerekir. Bu fazla kullanıcı bazen saldırı (attack) olarak gelebilir, bazen de sektörel değişimler ya da yapılan iş bazlı reklam kampanyaları beklediğinizden çok fazla sistemlerinizde yoğunluğa sebep olabilir.
Sistemlerini tasarlarken 3–5–10 kat trafiği karşılayacak şekilde kaynak ayırmak veya bu ölçekte bir altyapıyı sürekli olarak tutmak maliyet açısından anlamsız olacaktır. Önemli olan mevcut sisteminizin ne kadar trafik karşılayabildiği değil artan trafiği karşılamak için sisteminizin ne kadar hızlı ölçeklendirebileceğindir. Eğer bu ölçeklendirme süreci saatler, günler sürüyorsa bu durumda olağan üstü durumlarda ani gelen trafik artışlarında belki ilk kez platformu deneyimleyecek kullanıcı erişim, yavaşlık problemleri yaşayarak olumsuz bir deneyim yaşayabilir.
Aynı şekilde çok güldüğümüz bir tweette bir kullanıcımızın dediği gibi;
Yazılım
Yaptığımız işleri canlıya almadan önce yük testine tabi tutuyoruz. Özellikle yük altında çalışan sistemlerde bu bizim için zorunlu bir adım. Bunun yararını bir kez daha görmüş olduk.
Haftalık olarak endpoint ve kaynak (resource) kullanımlarını takip ediyoruz. Yapılan bir geliştirme sonrası eğer beklenenin çok üstünde bir kötüleşme varsa çoğu zaman bu sorun kullanıcılara yansımadan önce farkına varılıyor. Ancak bazen ufak tefek artışlar gözden kaçabiliyor. Bunları da haftalık incelemelerimizde yakalıyoruz ve öncelikli olarak planlarımıza dahil edip hızlıca düzeltiyoruz.
Her developer en az 1 kez şu sözleri söylemiştir:
“burada refactor ihtiyacım var, bu kod performanssız çalışıyor ama zaman yok“
Bu tarz söylemleri de kulak arkası etmiyoruz. Ürün ekibinden gelen işler kadar yazılımcılardan gelen iyileştirme isteklerini de öncelik sıramıza göre planlarımıza dahil ediyoruz.
Bazen büyük maliyetlere girmeden alt yapınızda doğru dokunuşlarla yüksek trafiklere de hazırlıklı duruma gelebilirsiniz.
Belki doğru soru şu da olabilir: Biz ne kadar büyümeye (artışa) hazırız?
Medium kanalımıza sıklıkla içerik girmeye çalışıyoruz. Takipte kalın. 🤞Son zamanlarda performans odaklı bir kaç yazımızı da altta bırakıyoruz.
