Skip to main content
Perde Arkası
Perde ArkasıEngineeringDecisions

Bir botu 2.000'den fazla Discord sunucusunda çalıştırmak bize ne öğretti

Kodu yazarken varsaydığından farklı işleyen, ölçekle birlikte değişen dört şey.

Yayınlanma yazan AlphaCloud3 dk okuma

Üç sunucudaki bir Discord botu ile iki binden fazla sunucudaki aynı bot, sadece daha büyük ölçekte aynı program değildir. Küçükken tamamen zararsız olan bir avuç varsayım, belirli bir büyüklükten sonra tam da bulunması en zor hatalara dönüşür.

İşte bize gerçek kesintilere mal olan dördü.

1. Arızalar eşit dağılmaz, saklanır

AlphaCloud, shard adı verilen birkaç sürece bölünmüş şekilde çalışıyor. Hangi sunucunun hangi shard'a düşeceğine Discord karar verir ve her shard yalnızca kendi sunucularını bilir.

Bu, dışarıdan rastlantı gibi görünen bir arıza sınıfı doğurur: karşılama mesajları bazı sunucularda çalışır, bazılarında çalışmaz. Kayıtta hata yok, alarm yok, hiçbir şey yok. Sebep, zaman aşımı olmayan tek bir ağ çağrısıydı. Karşı taraf bağlantıyı kabul edip sonra susarsa, kod sürecin geri kalan ömrü boyunca bekler. Ondan sonraki hiçbir şey asla gerçekleşmez ve hata fırlatılmadığı için hiçbir şey hata bildirmez.

Ders gösterişsiz ve evrensel: giden her çağrının bir üst sınırı olmalı. Sonsuza kadar bekleyen bir çağrı, başarısız olandan daha kötüdür, çünkü başarısız olmak en azından görünürdür.

2. Yeniden başlatma bir çözüm değil, bir son tarihtir

Sebebi bilmediğimiz sürece, etkilenen shard'ı yeniden başlatmak güvenilir şekilde işe yarıyordu. Yeniden başlatmaların sorunu tam olarak bu: işe yararlar ve bu, sebebi bulma baskısını ortadan kaldırır.

Artık "yeniden başlatma işe yarıyor mu?" sorusunu bir çare değil, bir teşhis olarak ele alıyoruz. İşe yarıyorsa, bozuk durum bellekte yaşıyordur ve kodda onu kuran ama asla yıkmayan bir yer vardır.

Tersi de geçerli: yeniden başlatmadan sağ çıkması gereken her şey veritabanına aittir. Çok adımlı bir işlem çalışıyorsa, örneğin binlerce üyede bir rol değişikliği, ve süreç yarı yolda ölürse, işlem öylece kaybolmamalı. Bir sonraki başlangıçta algılanmalı ve devam ettirilmeli.

3. Discord'un sınırları süreç başına değil, bot başına geçerlidir

Discord bir botun saniyede kaç istek yapabileceğini sınırlar. Bariz varsayım: daha fazla süreç, daha fazla kapasite. Yanlış. Sınır süreçte değil, bottadır. Her biri tam bütçeye sahip üç shard, izin verilenin üç katına ulaşır ve Discord sonra üçünü de yavaşlatır.

Bu yüzden süreçlerimizin her biri toplamda kaç tane olduğunu hesaplıyor ve yalnızca kendi payını alıyor. Kulağa bariz geliyor ama değildi ve hata uzun süre görünmez kaldı, çünkü her bir süreç kendi başına mükemmel şekilde uslu görünüyordu.

İlgili bir tuzak: tekrarlanan işler sabit aralıklarla çalışır, örneğin her beş dakikada bir. Tüm shard'lar aynı anda başlarsa, işlerini sonsuza kadar aynı anda tetiklerler. O zamandan beri her süreç başlangıçta rastgele bir kayma alıyor.

4. İnsanların gerçekte ayarladığı şey beklediğin şey değil

Teknik kısım bir yarısı. Diğeri: çoğu sunucu için varsayılan değer, ayarın ta kendisidir. Varsayılanları yanlış olan bir modül, ayarlar sayfası ne kadar iyi olursa olsun, sunucuların büyük çoğunluğunda yanlış yapılandırılmıştır.

Bundan bizim için iki şey çıkıyor. Birincisi, her varsayılan değer, ayarın kendisinden daha fazla düşünce gerektirir. İkincisi, yeni bir modül için daha iyi soru "burada neler ayarlanabilir" değil, "kimse hiçbir şey ayarlamadığında bu modül ne yapar ve bu normal bir sunucu için doğru mu" sorusudur.

Bu, ilk bakışta tam tersi gibi görünen bir kararın da sebebi: v1.8.0'dan beri botun gönderdiği neredeyse her mesaj serbestçe tasarlanabiliyor. Ama bir uyarı mesajındaki sebep ya da bir ticket panelindeki kategori menüsü gibi zorunlu bloklar taşınabiliyor, silinemiyor. Tasarım özgürlüğü evet, ama bir sunucunun yanlışlıkla çalışıyormuş gibi görünen ve çalışmayan bir şey kuracağı noktaya kadar değil.

Ortak nokta

Dördünden üçü, farklı kılıklara bürünmüş aynı düşünce: bu büyüklükte sessiz bir arıza, gürültülü olandan daha pahalıdır. Bir çökme bildirilir ve düzeltilir. Basitçe hiçbir şey yapmayı bırakan bir özellik aylarca öyle kalabilir ve bunu, yazma zahmetine katlanan birinin hata bildiriminden öğrenirsin.

Bu yüzden yeni kod hakkında artık ilk sorduğumuz soru "bu çalışıyor mu" değil, "çalışmadığında nasıl görünüyor ve fark eder miydik".

Diğer yazılar