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 yorumları

• Başta VM'e RAM ekleme şeklindeki altyapı yükseltmesi ile kesintinin tam olarak aynı anda gerçekleşmesinin tamamen tesadüf olduğu ortaya çıktı; ancak bu tür “tesadüfler” gerçekten çok sık olur ve sorunu izlerken varlıklarından bile şüphe etmenize yol açar.
  O durumda paniğe kapılırsanız sonunda başka bir şeyi bozan bir acil düzeltmeyi (hotfix) devreye alırsınız; işte o noktadan sonra süreç çok daha acı verici hâle gelir.
  Murphy Kanunları sistem yöneticileri ve geliştiriciler için acımasızdır.

  • Tamamen katılıyorum. Şimdiye kadar birçok farklı seviyede kesintiyi sınıflandırdım; en kötü vakalar her zaman birinin, “aynı anda oldu” olmasından başka makul bir açıklaması olmadan yanlış ipucuna aceleyle sarıldığı durumlardı.
    Sevdiğim bir söz var: “Neyi neden/nasıl düzelttiğini bilmiyorsan, aslında düzeltmemiş olabilirsin.”
  • Geçen hafta küçük bir kesinti yaşandı ve veritabanı sorguları normalden çok daha uzun sürdü. Tam o sırada aynı tablo üzerinde geçici bir sorgu çalıştırıyordum.
    “Neyse ki” benim sorgumla ilgisi yoktu, ama bu tür iki tesadüf üst üste gelince gerçekten korkutucu oluyor.
  • “Tesadüf” yüzünden değişikliğimin sebep olduğu sonucuna aceleyle varıyorsunuz. Bu çok insani bir tepki ve hepimiz bunu sık sık yapıyoruz.
    Bu tür şeyleri yeterince yaşadıktan sonra daha fazla varsayımdan şüphe etmeyi ve henüz doğrulanmamış şeyleri doğrulanmış veri olarak işaretlememeyi alışkanlık edindim.
    Önyargıları ve aceleci sonuçları tamamen ortadan kaldıramadım ama yardımcı oldu; açık fikirli kalmak epey zor bir iş.
  • Kesinti sırasında konuyla hiç ilgisi olmayan değişiklikleri geri aldığım gerçekten çok oldu.
    Bir mühendis için önemli beceri, kesinti müdahalesi kapsamındaki değişiklikleri eleştirel biçimde akıl yürüterek değerlendirebilmek, debug edebilmek ve “izole edip test edebilmek”tir. Göründüğünden çok daha zordur ve genelde senior seviyeye yakın bir yetkinliktir.

• Bu sorunu Discord'da bildiren kullanıcılardan biriydim. Kagi'yi seviyorum, ancak durum sayfasının her şeyin normal olduğunu göstermesi epey hayal kırıklığı yarattı.
  Gerçek kullanıcıları etkileyen bir kesinti sırasında bile durum sayfasının öncelik değilmiş gibi görünmesi endişe vericiydi; umarım bundan sonra doğru şekilde güncellenir.
  Geçmişte çok güvendiğim servisler, örneğin GitHub, durum sayfasını hemen güncellerdi; böylece sorunun benim cihazımda değil, servis tarafında bilinen bir sorun olduğunu anlayıp rahatlayabiliyordum.
  Bu sefer o gün kar yağmadan önce yakındaki açık bir marketi bulmam gerekiyordu; sonunda Google'a gitmek zorunda kalınca biraz hayal kırıklığına uğradım.
  Yine de Kagi'yi kullandığım zamanların %99,9'unda Google'dan daha iyiydi; bu yüzden kullanmaya devam edeceğim ve olay sonrası analizde söylendiği gibi durum sayfası kodunu başka bir servis/platforma taşımalarını umuyorum.

  • Geçmişte GitHub'ın durum sayfasını hemen güncellediği oldu, ama bunun tersine GitHub durum sayfasının hemen güncellenmediği durumlar da vardı.
  • On-call mühendis olarak bu tür konuşmaları gerçekten çok yaşadım: “Kırmızı ışığı yakalım mı?”, “Bu gerçekten kesinti mi, yoksa metrik sorunu mu?”, “Kaç kullanıcı etkileniyor?”, “Kontrol edebilirim ama şu anda stack trace okuyorum”, “Sorunu sadece duyursak olmaz mı?”, “Hangi servisi kesintide olarak işaretlemem gerektiğini bilmiyorum” gibi.
    Sonunda durum sayfasına bir şey koymak başlı başına bir konuşmaya dönüşüyor; bu konuşma mühendis zamanını ve dikkatini tüketiyor, dolayısıyla kesintinin çözümü de o kadar gecikiyor.
    İletişim ile gerçek kurtarma arasında denge kurmak gerekiyor; doğru cevap her zaman net olmuyor.
    Yeterince insan varsa Technical Incident Manager iletişimi üstlenebilir ve iletişim tarafına daha fazla mühendis ayrılabilir, ama bu her zaman mümkün değil. Bazı sistemler özeldir, dokümantasyonu yetersizdir ve enstrümantasyonu da eksiktir.
    Kişisel olarak, sorun belirtisi görülür görülmez “olası bir sorunu araştırıyoruz” şeklinde büyük ve muğlak bir duyuru yayınlayıp, ayrıntıları daha sonra doldurmayı veya duyuruyu geri çekmeyi tercih ederim. Ancak çalıştığım şirketler bu fikri pek sevmedi.
  • Henüz tamamen geçiş yapmadım ama Kagi'nin, Google arama sonuçlarının hiçbir sayfasında bulamadığım bir sonucu döndürdüğü an oldukça çarpıcıydı.
    O anda Kagi'ye ciddi şekilde çekildim ve bazı sorgularda gidip gelerek kullandım; ancak LLM'ler, Perplexity ve Google'ın arama sayfasında doğrudan yanıt verdiği durumlar arttıkça Kagi'ye kalan sorgu sayısı fazla olmuyor.
    Kagi bir şekilde Perplexity ile birleşirse oldukça ilginç olabilir.
  • Başka servislerde böyle bir deneyim yaşamış olmanı kıskandım. Ben kesinti yaşamaya başladığım anda ya da hemen sonrasında durum sayfasının servisin kapalı olduğunu gösterdiğini hiç görmedim.
    Çoğu zaman sonuna kadar hiç göstermiyorlar.
  • Microsoft, durum sayfası güncellemelerini gevşek tutmasıyla kötü ünlüdür.

• Bu kesintinin bu kadar tanıdık gelmesi şaşırtıcı.
  Kişisel olarak kabul etmek istemeyeceğim kadar çok kez bununla birebir aynı türde kesintilerle uğraştım; Kagi ekibi gibi veritabanı bağlantı havuzu durumu tavşan deliğine girip yeni instance'lar eklemek veya trafiği “sıfırlamak”la çözüleceğine inanmak gibi aynı hafifletme yollarını denedim, ama hepsi boşa çıktı.
  Bu tür kesintilerde veritabanının tipik doygunluk metrikleri olan CPU kullanımı, IOPS vb. metriklerin pek kıpırdamaması da yardımcı olmuyor. Sorgu gecikmesi yüksek görünür, ama “CPU ve IOPS'ta boşluk var…” diye düşünürken, her zamanki gibi arka planda kilit çekişmesinin saklı olduğunu kaçırırsınız.
  Deneyimime göre DB bağlantı havuzundaki anormalliklerin %98'i DB'nin kendisindeki anormalliklerden kaynaklanır. Kagi'nin hangi ilişkisel veritabanını kullandığını bilmiyorum, ancak DB'nin global I/O bekleme süresini (saniye/saniye), global kilit edinme süresini (saniye/saniye) ve normalize edilmiş sorgu başına çalışma süresini (saniye/saniye) grafiklemelerini şiddetle öneririm.
  Buna CPU kullanım grafiğini de eklerseniz, büyük ölçekli performans sorunlarının çoğunu hızlıca belirleyebilen bir dashboard elde edersiniz.
  Ayrı olarak, arama sorgusunun ilişkisel veritabanına yazmayı tetiklemesi biraz şaşırtıcı. İlişkisel veritabanının yalnızca kullanıcı ayarları, oturum açma yönetimi gibi yerlerde kullanılacağını düşünmüştüm.
  Kagi kullanım toplama işini, örneğin sayaç artırmayı ilişkisel veritabanında yapıyorsa, bu ölçek büyüdüğünde patlayan çok tipik bir hata modudur.

  • Ben de aynı noktayı merak ettim.
    Arama sonuçlarını engelleme durumunda olduğu gibi arama nedeniyle dolaylı yazmalar olabilir; ziyaret geçmişi veya analiz de elbette vardır.
    Yine de her bir aramada yazma kilidi çekişmesi yaratabilecek şeyin ne olduğu net değil.

• Her startup’ın bir gün yaşayacağı türden bir şey. Ben de yaşadım ve gerçekten acı vericiydi
  Böyle sorunları önleyecek yetkinliği geliştirmek için zaman ya da kaynak yetersiz olabiliyor; bazen de belirli bir sorunun gerçekten yaşanabileceğini aklınıza bile getirmeden hazırlıksız yakalanıyorsunuz
  Şeffaflık da önemli, öğrenmek de önemli; ama bazen telafi de önemlidir. Kagi, hizmetin kullanılamadığı süre için arama kredisi vermeyi değerlendirmeli
  Özellikle gerçek zamanlı müdahalenin yetersiz kaldığını kendileri kabul etmişken
  Ücretli bir hizmetteki kesinti, “kullanıcının ürün olduğu” bir hizmetteki kesintiyle aynı şey değil

• İç sistemlerdeki gözlemlenebilirlik düzeyi hakkında çok şey gösteriyor
  Daha erken fark etmeleri gerektiğini söylemek kolay; ama uygun Datadog panelleri ve Splunk sorguları olsaydı durum çok daha hızlı ve net biçimde ortaya çıkardı
  Umarım bunu bir öğrenme fırsatı olarak görür ve daha iyi izlemeye yatırım yaparlar

  • Kagi’nin teknik lideri ve bu olay sonrası analizin yazarı Zac’im
    Bu olay %100 bir öğrenme deneyimiydi, ama gözlemlenebilirlik konusunda biraz daha bağlam verebilirim
    Kagi küçük bir ekip; bu tür olaylara müdahale edebilecek kişi sayısı fiilen 3 ve 3 farklı saat dilimine dağılmış durumdayız. Ben ve çekirdek geliştirici için bu, web kariyerimizin ilk aşaması; yani bunları zaten yaşamış Silikon Vadisi veteranları değiliz
    Öğrenecek çok şeyimiz olduğu açık; ama Kagi’yi sıfırdan inşa ettiğimiz için şimdiye kadar geldiğimiz yol ve bundan sonra gideceğimiz yönle gurur duyuyorum
    Gözlemlenebilirlik konusunu yaklaşık son 6 aydır daha ciddiye almaya başladık. Şu anda çok sayıda panelimiz ve şirket sohbet kanalına doğrudan düşüp ilgili kişiyi çağıran uyarılarımız var
    DB’nin birincil sorumlusu olarak GCP’nin Query Insights aracı çok yardımcı oluyor. Kesinti sırasında izleme sistemleri alarm verdi ve Query Insights da “suçlu” sorguyu gösterdi; ama dünyadaki tüm izleme sistemlerine sahip olsanız bile kök nedeni ya da en verimli hafifletme adımını yorumlayacak deneyiminiz eksik olabilir
    Başka bir deyişle, dikkatli olmazsak kendi sistemimizin bize gösterdikleri tarafından gaslighting’e uğramayacak bilgeliğe henüz tam sahip değiliz. Geriye dönüp bakınca GCP Query Insights’ın %100 doğru olduğunu ve bunun uygulama alanındaki bir bug olmadığını söyleyebilirim
    Büyüme sayesinde artık ekibi epey genişletebilecek durumdayız; daha önce SRE danışmanlığı da aldık ve bundan sonra da tam zamanlı ya da yarı zamanlı destek alarak iyileştirmeye devam etmek istiyoruz
  • “Uygun Datadog panelleri ve Splunk sorguları” tam olarak nedir?
  • Kagi, düşük marjlı ve yüksek operasyon maliyetlerine sahip bir startup

• Yani tek bir kullanıcı scraper çalıştırıp hizmeti 7 saat boyunca mı düşürdü? Dışarıdan “bunu öngörmeliydiniz” demenin kolay olduğunu biliyorum, ama testlerde kimsenin “Çok fazla arama olursa ne olur?” diye sormamış olması tuhaf

  • Kagi’den Zac. İlginizi çekebilecek ayrıntıları başka bir yerde yazdım
    https://news.ycombinator.com/item?id=39019936
    Özetle çekirdek kadromuz çok küçük ve genç bir ekip; herkes aynı anda birden fazla rol üstleniyor. Henüz özel bir SRE ekibimiz yok
    “Çok fazla arama olursa ne olur?” konusuna gelirsek, https://kagi.com/stats sayfasına bakarsanız zaten “çok sayıda arama” olduğunu ve günde 400 bine yaklaştığımızı görebilirsiniz. Günlük kullanımda sistem yeterli kapasite payıyla çalışıyor ve bazı otomatik ölçekleme önlemlerimiz de var
    Sorun, bazı kullanıcıların patolojik bir vakayı kötüye kullanmasına yol açan ayrıntılardaydı. Deneyim eksikliğimiz nedeniyle hangi doğal trafiği ya da patolojik trafiği önceden öngörüp simüle edebileceğimizi bilmiyorduk
    Aynı anda arama yapan 20 bin kullanıcıyı yük simülasyonuna sokmak başlangıçta yapılabilir bir deney gibi geliyor; buna benzer şeyler de yaptık. Ama bu kesintiye bakınca, yine de bu sorunu yakalayamayacaktı
    Şimdiye kadar çalışan hizmet üzerinde güvenlik tarayıcısı çalıştıran yaklaşık 10 kişi oldu ve o zaman oluşan trafik bu kesintidekinden fazlaydı
    Bir yandan özellik de geliştirmemiz gerekirken bu tür geliştirme dengesini kurmak çok zor; kesinlikle daha fazlasını yapmalıydık. Başka bir yazıda söylediğim gibi, yakın zamanda ekibi büyüterek bu tür çabalara gereğinden fazla ince yayılmamaya çalışacağız
    Geriye dönüp bakınca söylenecek çok şey var; umarım buraya nasıl geldiğimizi biraz daha şeffaf biçimde aktarabilmişimdir
  • Kagi’nin ölçeği, “büyük ölçekli operasyon” yürüten yerlerle karşılaştırıldığında çok küçük. Günde 400 bin arama yapan bir hizmetin, birkaç saat içinde beklenmedik 60 bin ek arama geldiğinde zorlanmasını mantıksız bulmuyorum
    Özellikle de biri ilk kez o şekilde vurduysa
    Karşılaştırmak gerekirse benim ilgilendiğim sistem FAANG ölçeğinde değil, ama istek oranı açısından kesinlikle Kagi’den büyük. Kagi de hızlı öğrenecektir; bu arada böyle sorunlar tekrar yaşansa bile bunun bir ölçüde iyi olduğunu düşünüyorum. Doğru yönde ilerlediklerinin de bir işareti

• Kagi’nin ücretli kullanıcısı olarak kesinti yaşayınca Google’ın güvenilirliğini ne kadar kanıksadığımı fark ettim
  Google son 20 yılda, bir kez dışında, benim için hiç çökmemişti. Bir arama motoruna erişimi kaybetmek epey kritik
  Kagi’yi gerçekten seviyorum ve para ödüyorum; ama kullanımımın ikinci ayında kesinti yaşamam oldukça rahatsız ediciydi. Olay sonrası analizleri sevsem de, keşke okumak zorunda kalmasam
  Yine de bu deneyimle Kagi’nin daha dayanıklı ve güvenilir bir hizmete dönüşmesini umuyorum

  • Kagi’nin bir başka ücretli kullanıcısı olarak, Kagi’yi kullanamadığınız 6 saat boyunca başka bir arama motoru kullanmanızı neyin engellediğini merak ediyorum
    Arama motoru, e-posta sağlayıcısı ya da ISP gibi kilitleme etkisi olan bir hizmet değil
  • %100 katılıyorum. Bu kesintiden bağımsız olan yeni mobil Safari eklentisi bug’ı epey sarsıcıydı
    Kagi’nin hızlı olmasına ve her yerde iyi çalışmasına kesinlikle bel bağlamıştım

• Bir müşteride yeni bir ağ aracının kavram kanıtını çalıştırdığımız zaman aklıma geldi. Çalıştırdıktan yaklaşık 2 dakika sonra müşterinin tüm ağı çöktü
  İzole bir sandbox bölgesindeydik, bu yüzden ürünümüzün tüm ağda kesintiye yol açmasının bir yolu yoktu; ama kafamın içinde “İmkânı yok, değil mi… değil mi?!?!” diye geçiriyordum

  • Sebebi neymiş? Sızdıran bir soyutlama gibi bir şey mi?

• “Daha sonra engellediğimiz hesapla iletişime geçtik; hesap, sonuçlarımızı otomatik olarak scrape etmek için kullanıldığını iddia etti ve bu, kullanım şartlarımızın izin vermediği bir şey.”
  Olası tüm giriş RPC/API/HTTP isteklerine, özellikle de herkese açık isteklere QPS sınırı koymak gerekir

  • Kesinlikle doğru. Bunu zor yoldan öğrendik
    Otomatik tamamlama özelliği olan bir arama fonksiyonumuz vardı; hızlı yazan kullanıcıları desteklemek için o endpoint’in hız sınırını bilerek kaldırmıştık
    Bir gün sabah 6 civarında Tennessee’de biri işe gelip cüzdanını klavyenin üstüne bırakmış; cüzdan bir tuşa basılı kalmış ve her tuş girdisinde API’ye istek atmaya başlamış
    Doğal olarak yaklaşık 15 dakika sonra DB çok kararsız hale geldi; DB gecikmesi o kadar büyüdü ki web sunucularından biri çöktü. Zincirleme arızalar devam etti ve tüm operasyon kümesi düştü
    O gün hız sınırının yeniden eklendiğini söylemeye gerek yok
  • Herkese açık endpoint, kullanıcının giriş yapmasını gerektiren endpoint’ler dahil internete açık tüm endpoint’lerdir. Bunu unutan çok kişi var