Geçen Haftaki Kagi Olayına Dair Sonradan Analiz

Kagi.com hizmetindeki kararsızlık sorununun çözümü

• İnceleniyor - Dağıtımdan sonra bir sorun ortaya çıktı ve ekip çözüm üzerinde çalışıyor. (12 Ocak 16:45 UTC)
• İzleme - Sorunun nedeni olduğu düşünülen yapılandırma değişikliği geri alındı ve hizmetin normale dönmesi sürekli olarak izleniyor. (12 Ocak 18:30 UTC)
• Güncelleme - Kararlılığı tamamen geri kazanmak için trafiği kısa süreliğine durdurup kullanıcıları bu sayfaya yönlendireceğiz. Hizmete yükü kontrollü biçimde geri verirken durum ilerledikçe ek ayrıntılar paylaşacağız. (12 Ocak 20:26 UTC)
• İzleme - Trafik geri yüklendi ve hizmetin tamamen normale dönmesi izlenmeye devam ediyor. (12 Ocak 21:14 UTC)
• Çözüldü - Tüm hizmetler normal şekilde çalışıyor. Sorunun çözülmesini bekleyen kullanıcılara teşekkür edildi.

Sonradan analiz

• Kagi’nin teknik lideri Zac, geçen haftaki hizmet kesintisine dair ayrıntılı bir sonradan analiz paylaştı.
• Bu olaya müdahale kapsamında kıdemli mühendis Seth ve DevOps mühendisi Luan birlikte çalıştı.
• Hizmeti kötüye kullanan ve altyapı darboğazlarını istismar eden aktörler vardı; buna karşı anında hafifletici önlemler alındı ve kod ile iletişimin çeşitli alanlarında iyileştirme çalışmaları sürüyor.

Olayın gelişimi

• 12 Ocak saat 17:30 civarında, iç izleme ve kullanıcıların sorun bildirimleri sayesinde bir altyapı sorunu yaşandığı fark edildi.
• Sorun, çeşitli bölgelerdeki kullanıcılar için yavaş yükleme veya sayfa zaman aşımına yol açtı.
• Sorunun çözümü önemli ölçüde zaman aldı; bu yüzden arka plan, süreç ve bundan sonraki planlar açıklandı.

Teknik sorun giderme süreci

• Başlangıçta sorun, tesadüfen VM’e ek RAM kaynağı yükseltmesi yapılmasıyla aynı anda ortaya çıktı.
• İzleme, yüksek gecikme ve uygulamanın veritabanı bağlantı havuzunda sorunlar olduğunu bildirdi.
• Bağlantı havuzu doygunluğa ulaştı; bu da toplam bağlantı sayısının yapılandırılmış azami bağlantı sınırını aştığı anlamına geliyordu.
• Veritabanının iç sağlığı ve sorgu performansı değerlendirilirken, bazı instance’lar değiştirilerek sıkışıklığın azaltılıp azaltılamayacağı test edildi.
• Instance’ların bir kısmını değiştirmenin yardımcı olduğu görüldü; bunun üzerine tüm bağlantı havuzlarını tek seferde tamamen sıfırlamak için kullanıcı trafiği geçici olarak durduruldu.
• Veritabanı durumu incelendiğinde, kullanıcı tablosundaki satırlara yönelik yüksek çekişmenin kök neden olduğu netleşti.
• Bu çekişme, yazma gecikmesini keskin biçimde artırdı; uygulamanın bağlantı havuzunda backpressure oluşturdu ve sonunda kullanılabilir tüm bağlantılar tükendi.
• Kagi şimdiye kadar GCP üzerinde kullanılabilen en ucuz tek çekirdekli veritabanını kullanıyordu; bu da veritabanının kolayca felç olma riskini beraberinde getiriyordu.
• Kötü niyetli aktörler tespit edilerek 24 saat içinde oluşturulmuş hesaplar ve kısa sürede 60.000’den fazla arama yapan tek bir kullanıcı hesabı belirlendi.
• Söz konusu hesabın arama özelliği kaldırıldı ve soruna yol açan belirli yazmayı devre dışı bırakan bir hotfix yayımlandı.
• Gece yarısına kadar sorun tamamen çözüldü ve aktörlerin geri döndüğüne dair işaretler yakından izlenmeye devam edildi.

Gelecek adımlar

• Bu olaydan çok şey öğrenildi; sistemi daha da güçlendirmek ve olay anındaki iletişim sürecini iyileştirmek için acil planlar şimdiden yürürlüğe alındı.
• İlk olarak, durum sayfası güncellemelerinin yeterince hızlı olmadığı kabul edildi.
• Kullanıcılara otomatik iç izlemeyi daha kolay görünür kılabilecek bir durum sayfası platformuna geçilecek; böylece platformun sağlık durumu gerçek zamanlı görülebilecek.
• Soruna yol açan sorgular doğrudan hafifletiliyor ve benzer zayıflıklar olup olmadığını görmek için yük testleri yürütülüyor.
• Altyapıda doğru noktayı daha hızlı işaret edecek ek izleme kurulacak; böylece bu olayda olduğu gibi yanlış sinyallerin peşinden giderek zaman kaybedilmeyecek.
• Bu tür kötüye kullanımları tespit eden sistemler güçlendiriliyor; çünkü bunlar yalnızca performans etkisi yaratmıyor, doğrudan maliyet de doğuruyor ve bu yüzden otomatik sınırlar konulup uygulanması gerekiyor.
• Yeni sınırlar bu yazı yayımlandığı sırada zaten devreye alınmıştı; etkileri izlenecek ve gerektiğinde ayarlanmaya devam edilecek.
• Kagi’ye erişimin yanlışlıkla engellendiğini düşünenlerin [e-mail] ile iletişime geçmesi istendi.

GN⁺ görüşü

• Kagi, kullanıcı tablosundaki satır çekişmesinden kaynaklanan bir yazma gecikmesi sorunu yaşadı; bu durum uygulamanın bağlantı havuzunda backpressure oluşturarak hizmet kesintisine yol açtı.
• Bu sorunlar, Kagi’nin GCP’de en ucuz tek çekirdekli veritabanını kullanmasının doğurduğu riskin bir sonucu oldu.
• Kagi ekibi, bu olayın ardından sistemi güçlendirme, kullanıcılarla iletişimi iyileştirme ve kötüye kullanımı önlemek için otomatik sınırlar koyma gibi adımlarla hizmetin kararlılığını ve şeffaflığını artırma çabasını gösterdi. Bu çabalar, kullanıcılara daha güvenilir bir hizmet sunma yönündeki Kagi iradesini yansıtıyor.

[GN⁺]

Hacker News görüşleri

• Altyapı yükseltmesiyle aynı anda meydana gelen olay hakkındaki görüş

  • Olayın, VM’e ek RAM kaynağı eklenerek altyapı yükseltmesi yapılırken aynı anda yaşanmasının tamamen tesadüf olduğu belirtiliyor.
  • Bu tür "tesadüflerin" sık yaşandığı ve sorun çözerken insanın kendi varlığını bile sorgulamasına yol açtığı ifade ediliyor.
  • Sorun çözümü sırasında paniğe kapılırsanız, başka şeyleri bozan bir hotfix uygulayabileceğiniz ve bunun sistem yöneticileri ile geliştiriciler için acımasız bir Murphy yasası olabileceği konusunda uyarılıyor.

• Kullanıcının Kagi durum sayfası deneyimi

  • Kullanıcı, Kagi’nin durum sayfasında her şeyin normal çalışıyor olarak görünmesinin kendisini tedirgin ettiğini söylüyor.
  • Geçmişte güvendiği hizmetlerin durum sayfalarını anında güncellediğini ve bu sayede sorunun kendi cihazında olmadığını anlayabildiğini karşılaştırma olarak aktarıyor.
  • Kagi’yi kullanmaya devam etmeyi planladığını, ancak postmortem’de de belirtildiği gibi durum sayfası kodunun başka bir hizmete/platforma taşınmasını umduğunu ifade ediyor.

• Kişisel deneyimini paylaşan yorum

  • Kişisel olarak aynı türden hizmet kesintilerini birkaç kez yaşadığını ve veritabanı bağlantı havuzunun sağlık durumuyla ilgili sorunları çözmeye çalıştığını paylaşıyor.
  • Veritabanının genel doygunluk metriklerinin (CPU%, IOPS vb.) bu kesintiler sırasında büyük ölçüde değişmediğini, bunun yerine lock contention’ın sorunun nedeni olabileceğini belirtiyor.
  • Kagi’nin kullandığı RDBMS için, global I/O gecikmesi, lock edinme süresi ve sorgu yürütme süresi gibi değerlerin grafiğe dökülmesini öneriyor.

• Bir startup deneyimine dair yorum

  • Her startup’ın bir noktada bu tür sorunlar yaşadığını belirtiyor.
  • Bu sorunları önleyebilecek kapasiteyi oluşturmak için yeterli zaman ya da kaynağa sahip olunmayabileceğini ve belirli bir sorunun yaşanacağını düşünmemiş olabileceklerini söylüyor.
  • Şeffaflık ve öğrenmenin önemli olduğunu, ancak bazen telafinin de önemli olduğunu belirterek Kagi’nin hizmetin kullanılamadığı süre için arama kredisi vermeyi değerlendirmesi gerektiğini öneriyor.

• İç sistemler için gözlemlenebilirlik hakkındaki yorum

  • Sorunun daha erken fark edilmesi gerektiğini ve doğru Datadog panoları ile Splunk sorgularının meseleyi çok daha hızlı netleştirmesi gerektiğini belirtiyor.
  • Bunu bir öğrenme deneyimi olarak görüp daha iyi izlemeye yatırım yapılmasını tavsiye ediyor.

• Ücretli kullanıcının Kagi’nin güvenilirliğine dair görüşü

  • Kagi kesintisini yaşayan ücretli bir kullanıcı, Google’ın güvenilirliğini kanıksadığını fark ettiğini söylüyor.
  • Bir arama motoruna erişimin kesilmesinin büyük bir aksaklık olabileceğini belirtiyor; Kagi’yi sevdiğini ama kesinti yaşamanın hoş olmadığını paylaşıyor.
  • Bu deneyimin Kagi’yi daha güçlü ve daha güvenilir bir hizmete dönüştürmesini umduğunu ifade ediyor.

• Hizmet kesintisine yol açan scraper hakkındaki yorum

  • Tek bir kullanıcının çalıştırdığı bir scraper yüzünden hizmetin 7 saat boyunca kesildiği gerçeği karşısında, test sırasında "çok fazla arama olursa ne olur?" sorusunun neden sorulmadığını sorguluyor.

• Kagi kullanım deneyimi ve postmortem hakkındaki yorum

  • Kagi’yi birkaç haftadır kullandıktan sonra, geçen hafta hemen yüklenmediğinde ne yapacağını bilemediğini paylaşıyor.
  • Postmortem çıkmadan önce olayı zaten unuttuğunu belirtiyor ve arama yaparken düşünmek zorunda kalmamasını sağlayan ekibe teşekkür ediyor.

• GCP’de kullanılan tek çekirdekli veritabanı hakkındaki yorum

  • Kagi’nin GCP’de mevcut en ucuz tek çekirdekli veritabanını kullanıyor olması gerçeğine olumlu yaklaşıyor.
  • Okuma yükündeki ani artışı karşılamak ve performansı daha da artırmak için PolyScale benzeri bir şeyin değerlendirilebileceğini öneriyor.

• Otomatik scraping hakkındaki yorum

  • Hesabı engellendikten sonra iletişime geçen bir kullanıcının, hesabını sonuçları otomatik olarak scrape etmek için kullandığını iddia ettiğini belirtiyor.
  • Tüm gelen RPC / API / HTTP istekleri, özellikle de herkese açık olanlar için QPS (saniye başına sorgu sayısı) sınırı belirlenmesini tavsiye ediyor.