Apa yang Kami Pelajari dari Menjalankan Bot di Lebih dari 2.000 Server Discord

Bot Discord di tiga server dan bot yang sama di lebih dari dua ribu server bukanlah program yang sama dalam ukuran lebih besar. Segelintir asumsi yang sama sekali tidak berbahaya dalam skala kecil, setelah ukuran tertentu justru menjadi bug yang paling sulit ditemukan.

Berikut empat di antaranya yang membuat kami mengalami gangguan sungguhan.

1. Kegagalan tidak menyebar merata, kegagalan bersembunyi

AlphaCloud berjalan terbagi di beberapa proses yang disebut shard. Discord menentukan server mana yang masuk ke shard mana, dan setiap shard hanya mengenal server-servernya sendiri.

Dari situ muncul jenis kegagalan yang dari luar terlihat seperti kebetulan: pesan sambutan berfungsi di sebagian server dan tidak di server lain. Tidak ada error di log, tidak ada peringatan, tidak ada apa-apa. Penyebabnya satu panggilan jaringan tanpa timeout. Kalau pihak seberang menerima koneksi lalu diam, kode menunggu selama sisa umur proses itu. Semua yang ada setelahnya tidak pernah terjadi, dan karena tidak ada error yang dilempar, tidak ada yang melaporkan error.

Pelajarannya tidak spektakuler dan berlaku di mana saja: setiap panggilan keluar butuh batas atas. Panggilan yang menunggu selamanya lebih buruk daripada panggilan yang gagal, karena kegagalan setidaknya terlihat.

2. Restart bukan perbaikan, melainkan tenggat waktu

Selama kami belum tahu penyebabnya, me-restart shard yang terdampak selalu membantu. Justru itulah masalahnya dengan restart: restart berhasil, dan itu menghilangkan tekanan untuk mencari penyebabnya.

Sekarang kami memperlakukan "apakah restart membantu?" sebagai diagnosis, bukan obat. Kalau membantu, berarti keadaan yang rusak hidup di memori, dan ada satu tempat di kode yang membangunnya dan tidak pernah membongkarnya.

Kebalikannya juga berlaku: apa pun yang harus bertahan setelah restart, tempatnya di database. Kalau sebuah operasi bertahap sedang berjalan, misalnya perubahan peran untuk ribuan anggota, lalu prosesnya mati di tengah jalan, operasi itu tidak boleh begitu saja lenyap. Operasi itu harus terdeteksi dan dilanjutkan saat start berikutnya.

3. Batas Discord berlaku per bot, bukan per proses

Discord membatasi berapa banyak request yang boleh dilakukan sebuah bot per detik. Asumsi yang paling jelas: lebih banyak proses, lebih banyak throughput. Salah. Batasnya ada pada bot, bukan pada proses. Tiga shard yang masing-masing memakai jatah penuh berarti tiga kali lipat jatah, dan Discord lalu memperlambat ketiganya.

Jadi setiap proses kami menghitung ada berapa proses secara total dan hanya mengambil bagiannya. Kedengarannya jelas, tapi ternyata tidak, dan bug itu lama tidak terlihat karena setiap proses, kalau dilihat sendiri-sendiri, tampak berperilaku sangat baik.

Jebakan serupa: tugas berulang berjalan dengan interval tetap, misalnya setiap lima menit. Kalau semua shard mulai pada saat yang sama, mereka menjalankan tugasnya pada detik yang sama selamanya. Sejak itu, setiap proses mendapat offset acak saat start.

4. Apa yang benar-benar diatur orang bukan seperti yang kamu kira

Bagian teknisnya satu sisi. Sisi lainnya: bagi sebagian besar server, nilai default adalah pengaturannya. Modul yang nilai default-nya salah akan salah konfigurasi di sebagian besar server, sebagus apa pun halaman pengaturannya.

Dua hal mengikuti dari itu bagi kami. Pertama, setiap nilai default butuh lebih banyak pemikiran daripada pengaturannya sendiri. Kedua, pertanyaan yang lebih baik untuk modul baru bukan "apa yang bisa diatur di sini", melainkan "apa yang dilakukan modul ini kalau tidak ada yang mengatur apa pun, dan apakah itu tepat untuk server biasa".

Itu juga alasan di balik keputusan yang awalnya terdengar seperti kebalikannya: sejak v1.8.0, hampir setiap pesan yang dikirim bot bisa didesain dengan bebas. Tapi blok wajib seperti alasan di DM peringatan atau menu kategori di panel tiket bisa dipindah dan tidak bisa dihapus. Kebebasan desain, ya, tapi tidak sampai sebuah server tanpa sengaja membangun sesuatu yang terlihat berfungsi padahal tidak.

Benang merahnya

Tiga dari empat hal ini adalah pemikiran yang sama dalam kostum berbeda: di ukuran ini, kegagalan yang diam lebih mahal daripada yang berisik. Crash dilaporkan dan diperbaiki. Fitur yang tiba-tiba berhenti melakukan apa pun bisa tetap begitu selama berbulan-bulan, dan kamu baru tahu lewat laporan bug dari seseorang yang mau repot-repot menulis.

Jadi pertanyaan yang sekarang pertama kali kami ajukan tentang kode baru bukan "apakah ini berfungsi", melainkan "seperti apa kelihatannya kalau tidak berfungsi, dan apakah kami akan menyadarinya".