Penyelesaian masalah ketidakstabilan layanan Kagi.com
- Sedang diselidiki - Masalah terjadi setelah deployment dan tim sedang bekerja untuk menanganinya. (12 Januari 16:45 UTC)
- Pemantauan - Perubahan konfigurasi yang diduga menjadi penyebab masalah telah dibatalkan, dan layanan terus dipantau hingga kembali normal. (12 Januari 18:30 UTC)
- Pembaruan - Untuk sepenuhnya memulihkan stabilitas, lalu lintas akan dihentikan sementara dan pengguna akan diarahkan ke halaman ini. Detail tambahan akan diberikan seiring perkembangan situasi saat layanan dipulihkan dengan beban yang dikendalikan. (12 Januari 20:26 UTC)
- Pemantauan - Lalu lintas telah dipulihkan dan layanan terus dipantau hingga sepenuhnya kembali normal. (12 Januari 21:14 UTC)
- Terselesaikan - Semua layanan beroperasi normal. Kagi menyampaikan terima kasih kepada para pengguna yang telah menunggu penyelesaian masalah ini.
Analisis pasca-insiden
- Zac, pemimpin teknis Kagi, membagikan analisis pasca-insiden yang rinci terkait gangguan layanan minggu lalu.
- Sebagai respons terhadap insiden ini, senior engineer Seth dan DevOps engineer Luan bekerja bersama.
- Ada pihak-pihak yang menyalahgunakan layanan dan mengeksploitasi bottleneck infrastruktur, sehingga langkah mitigasi segera diambil dan perbaikan sedang dilakukan di berbagai area kode maupun komunikasi.
Kronologi insiden
- Sekitar pukul 17:30 pada 12 Januari, masalah infrastruktur dikenali melalui pemantauan internal dan laporan masalah dari pengguna.
- Sifat masalah ini menyebabkan loading lambat atau timeout halaman bagi pengguna di berbagai wilayah.
- Penyelesaiannya memakan waktu cukup lama, dan penjelasan diberikan mengenai latar belakang, progres, serta rencana ke depan.
Proses pemecahan masalah teknis
- Awalnya, masalah terjadi secara kebetulan bersamaan dengan upgrade resource RAM tambahan pada VM.
- Pemantauan melaporkan latensi tinggi dan masalah pada connection pool database aplikasi.
- Connection pool mencapai kondisi jenuh, yang berarti total koneksi melebihi batas maksimum koneksi yang telah dikonfigurasi.
- Sambil mengevaluasi kesehatan internal database dan performa query, beberapa instance diganti untuk menguji efek pengurangan kemacetan.
- Karena penggantian sebagian instance tampak membantu, lalu lintas pengguna dihentikan sementara untuk mereset seluruh connection pool sepenuhnya sekaligus.
- Setelah meninjau kondisi database, menjadi jelas bahwa akar masalahnya adalah contention tinggi pada row di tabel pengguna.
- Contention ini meningkatkan latensi penulisan secara tajam, memberi backpressure pada connection pool aplikasi, dan pada akhirnya menghabiskan semua koneksi yang tersedia.
- Hingga saat itu, Kagi menggunakan database single-core termurah yang tersedia di GCP, yang membawa risiko database menjadi lumpuh dengan mudah.
- Setelah mengidentifikasi pelaku yang berniat buruk, ditemukan akun yang dibuat dalam 24 jam terakhir dan satu akun pengguna yang melakukan lebih dari 60.000 pencarian dalam waktu singkat.
- Fitur pencarian pada akun tersebut dihapus, dan hotfix diterbitkan untuk menonaktifkan penulisan spesifik yang menyebabkan masalah.
- Pada tengah malam, masalah telah sepenuhnya terselesaikan, dan sinyal bahwa para pelaku kembali terus dipantau dengan ketat.
Langkah selanjutnya
- Banyak pelajaran diambil dari insiden ini, dan rencana segera untuk lebih memperkuat sistem serta memperbaiki proses komunikasi saat insiden sudah mulai dijalankan.
- Pertama, diakui bahwa pembaruan pada halaman status tidak cukup cepat.
- Kagi akan berpindah ke platform halaman status yang memungkinkan pemantauan internal otomatis lebih mudah dipublikasikan kepada pengguna agar kondisi kesehatan platform dapat dipahami secara real-time.
- Query yang menyebabkan masalah sedang dimitigasi secara langsung, dan load test sedang dijalankan untuk melihat apakah masih ada kelemahan serupa lainnya.
- Pemantauan tambahan akan dipasang agar lebih cepat menunjuk ke titik yang tepat di infrastruktur, sehingga waktu tidak terbuang mengejar sinyal yang keliru seperti kali ini.
- Sistem untuk mendeteksi jenis penyalahgunaan ini sedang diperkuat, dan karena dampaknya tidak hanya pada performa tetapi juga langsung menimbulkan biaya, perlu diterapkan pembatasan otomatis untuk menegakkannya.
- Batasan baru sudah diberlakukan pada saat posting ini dibuat, dan dampaknya akan terus dipantau serta disesuaikan sesuai kebutuhan.
- Jika merasa akses ke Kagi terblokir secara keliru, pengguna diminta menghubungi support@kagi.com.
Pendapat GN⁺
- Kagi mengalami masalah latensi penulisan akibat contention row pada tabel pengguna, yang memberikan backpressure pada connection pool aplikasi dan menyebabkan gangguan layanan.
- Masalah ini merupakan akibat dari risiko yang timbul karena Kagi menggunakan database single-core termurah di GCP.
- Melalui insiden ini, tim Kagi menunjukkan upaya untuk meningkatkan stabilitas dan transparansi layanan dengan memperkuat sistem, memperbaiki komunikasi dengan pengguna, dan menetapkan pembatasan otomatis untuk mencegah penyalahgunaan. Upaya ini mencerminkan komitmen Kagi untuk menyediakan layanan yang lebih andal bagi para pengguna.
1 komentar
Opini Hacker News
Awalnya ternyata benar-benar kebetulan bahwa upgrade infrastruktur berupa penambahan RAM ke VM terjadi pada waktu yang persis sama dengan insiden, tetapi “kebetulan” seperti ini sangat sering terjadi dan membuat kita meragukan keberadaannya sendiri saat menelusuri masalah
Kalau panik dalam kondisi seperti itu, pada akhirnya kita akan mendorong hotfix yang justru merusak hal lain, dan sejak saat itu semuanya menjadi jauh lebih menyakitkan
Hukum Murphy kejam bagi administrator sistem dan developer
Ada satu ungkapan favorit saya: “Kalau kamu tidak tahu kenapa/bagaimana kamu memperbaikinya, mungkin sebenarnya kamu belum memperbaikinya”
“Untungnya” tidak ada hubungannya dengan query saya, tetapi kalau dua kebetulan seperti ini bertumpuk, rasanya benar-benar menakutkan
Setelah cukup sering mengalami hal seperti ini, saya jadi terbiasa meragukan lebih banyak asumsi dan tidak menandai sesuatu yang belum diverifikasi sebagai data terkonfirmasi
Bias dan kesimpulan tergesa-gesa memang tidak sepenuhnya hilang, tetapi itu membantu, dan menjaga pikiran tetap terbuka adalah hal yang cukup sulit
Kemampuan penting bagi engineer adalah mampu menalar secara kritis, men-debug perubahan respons insiden, dan “menguji secara terisolasi”. Ini jauh lebih sulit daripada kelihatannya dan biasanya mendekati kemampuan level senior
Saya salah satu pengguna yang melaporkan masalah ini di Discord. Saya suka Kagi, tetapi cukup mengecewakan ketika halaman status menunjukkan semuanya normal
Saat insiden berdampak pada pengguna nyata, rasanya meresahkan melihat halaman status seolah bukan prioritas, dan saya berharap ke depannya halaman itu diperbarui dengan akurat
Layanan yang dulu banyak saya andalkan, misalnya GitHub, segera memperbarui halaman statusnya, sehingga saya bisa tenang karena tahu masalahnya bukan di perangkat saya, melainkan masalah yang sudah disadari di sisi layanan
Kali ini saya perlu mencari toko kelontong terdekat yang masih buka sebelum salju turun hari itu, tetapi akhirnya harus beralih ke Google, jadi agak kecewa
Meski begitu, 99,9% waktu menggunakan Kagi lebih baik daripada Google, jadi saya akan tetap memakainya, dan berharap mereka memindahkan kode halaman status ke layanan/platform lain seperti yang disebutkan dalam postmortem
Pada akhirnya, memasang sesuatu di halaman status itu sendiri menjadi sebuah percakapan, dan percakapan itu menyita waktu serta perhatian engineer, sehingga penyelesaian insiden ikut tertunda
Kita harus menyeimbangkan komunikasi dan pemulihan nyata, tetapi jawabannya tidak selalu jelas
Kalau jumlah orang memadai, Technical Incident Manager bisa menangani komunikasi dan lebih banyak engineer bisa ditempatkan di sisi komunikasi, tetapi itu tidak selalu memungkinkan. Sebagian sistem bersifat khusus, kurang terdokumentasi, dan kurang instrumentasi
Secara pribadi saya lebih suka langsung memasang pemberitahuan besar dan samar seperti “sedang menyelidiki kemungkinan masalah” begitu tanda-tanda masalah terlihat, lalu mengisi detailnya atau menariknya kembali nanti. Namun perusahaan-perusahaan tempat saya bekerja tidak menyukai gagasan itu
Saat itu saya langsung tertarik pada Kagi dan sempat bolak-balik memakainya untuk beberapa query, tetapi karena LLM, Perplexity, dan Google semakin sering langsung menjawab di halaman pencarian, tidak banyak query yang tersisa untuk Kagi
Kalau Kagi entah bagaimana bergabung dengan Perplexity, sepertinya akan cukup menarik
Banyak juga yang sama sekali tidak menampilkannya sampai akhir
Insiden ini terasa terlalu familier sampai mengejutkan
Secara pribadi, saya sudah menangani insiden jenis yang persis sama ini lebih banyak daripada yang ingin saya akui, dan seperti tim Kagi, saya juga terperosok ke rabbit hole status connection pool database, mencoba mitigasi yang sama seperti menambahkan instance baru atau percaya bahwa “reset” traffic akan menyelesaikannya, tetapi semuanya sia-sia
Dalam insiden seperti ini, indikator saturasi umum database seperti penggunaan CPU, IOPS, dan sebagainya juga tidak banyak bergerak, sehingga tidak membantu. Latensi query terlihat tinggi, tetapi kita berpikir “CPU dan IOPS masih longgar…”, lalu seperti biasa melewatkan bahwa ada kontensi lock yang tersembunyi
Berdasarkan pengalaman, 98% tanda aneh pada connection pool DB berasal dari keanehan pada DB itu sendiri. Saya tidak tahu database relasional apa yang dipakai Kagi, tetapi saya sangat menyarankan untuk membuat grafik latensi I/O global DB (detik/detik), waktu akuisisi lock global (detik/detik), dan waktu eksekusi per query yang dinormalisasi (detik/detik)
Jika ditambah grafik penggunaan CPU, ini menjadi dashboard yang bisa dengan cepat mengidentifikasi sebagian besar masalah performa skala besar
Secara terpisah, agak mengejutkan bahwa query pencarian memicu penulisan ke database relasional. Saya mengira database relasional hanya dipakai untuk hal-hal seperti pengaturan pengguna dan manajemen login
Jika Kagi melakukan agregasi penggunaan, misalnya peningkatan counter, di database relasional, itu adalah mode kegagalan yang sangat klasik saat skala membesar
Bisa saja ada penulisan tidak langsung karena pencarian, seperti saat memblokir hasil pencarian, dan tentu saja ada riwayat kunjungan atau analitik
Meski begitu, belum jelas apa yang bisa menimbulkan kontensi write lock pada setiap satu pencarian
Ini adalah sesuatu yang pada akhirnya akan dialami semua startup. Pernah mengalaminya, dan rasanya benar-benar menyakitkan
Kadang tidak ada cukup waktu atau sumber daya untuk membangun kemampuan mencegah masalah seperti ini, dan kadang bahkan tidak terpikir bahwa masalah tertentu benar-benar bisa terjadi, lalu tiba-tiba kena hantam dari belakang
Transparansi itu penting, begitu juga pembelajaran, tetapi kadang kompensasi juga penting. Kagi sebaiknya mempertimbangkan pemberian kredit pencarian untuk waktu ketika layanannya tidak bisa digunakan
Apalagi karena mereka sendiri mengakui bahwa respons real-time mereka kurang memadai
Gangguan pada layanan berbayar tidak sama dengan gangguan pada layanan yang “penggunanya adalah produk”
Ini menunjukkan banyak hal tentang sejauh mana observabilitas terhadap sistem internal mereka
Mudah mengatakan bahwa mereka seharusnya menyadarinya lebih cepat, tetapi dengan dashboard Datadog dan query Splunk yang tepat, masalahnya akan terlihat jelas jauh lebih cepat
Semoga mereka menjadikan kejadian ini sebagai kesempatan belajar dan berinvestasi pada monitoring yang lebih baik
Kejadian ini 100% merupakan pengalaman belajar, tetapi saya bisa memberi sedikit lebih banyak konteks tentang observabilitas
Kagi adalah tim kecil, dan orang yang secara realistis bisa merespons kejadian seperti ini hanya 3 orang, tersebar di 3 zona waktu. Bagi saya dan developer inti, ini adalah tahap awal karier web kami, jadi kami bukan veteran Silicon Valley yang sudah pernah mengalami semuanya
Sudah tentu masih banyak yang harus dipelajari, tetapi karena kami membangun Kagi dari nol, saya bangga dengan perjalanan kami sejauh ini dan arah yang akan kami tuju
Observabilitas baru mulai kami tangani dengan lebih serius kira-kira sejak 6 bulan terakhir. Sekarang kami punya banyak dashboard, juga alert yang langsung masuk ke kanal chat perusahaan dan memanggil orang terkait
Sebagai penanggung jawab utama DB, Query Insights dari GCP sangat membantu. Saat gangguan terjadi, monitoring juga berbunyi dan Query Insights juga menunjukkan query “pelakunya”, tetapi meskipun ada semua monitoring di dunia, kita tetap bisa kurang pengalaman untuk menafsirkan akar masalah atau langkah mitigasi yang paling efisien
Dengan kata lain, kami masih kurang kebijaksanaan agar tidak, jika tidak hati-hati, ter-gaslight oleh apa yang ditunjukkan sistem kami sendiri. Jika melihat ke belakang, saya bisa mengatakan bahwa GCP Query Insights 100% benar dan ini bukan bug di ruang aplikasi
Berkat pertumbuhan, kini kami bisa cukup memperluas tim, dan sebelumnya kami juga pernah mendapat konsultasi SRE; ke depannya kami akan terus memperbaiki diri dengan mendapatkan lebih banyak dukungan penuh waktu maupun paruh waktu
Jadi satu pengguna menjalankan scraper dan membuat layanan down selama 7 jam? Saya tahu mudah bagi orang luar untuk berkata “harusnya sudah diperkirakan”, tetapi aneh rasanya kalau saat pengujian tidak ada yang bertanya, “apa yang terjadi kalau ada pencarian dalam jumlah sangat besar?”
https://news.ycombinator.com/item?id=39019936
Singkatnya, kami adalah tim muda dengan sangat sedikit orang inti, dan semua orang merangkap banyak peran. Kami belum punya tim SRE khusus
Soal “apa yang terjadi kalau ada pencarian dalam jumlah sangat besar?”, jika melihat https://kagi.com/stats, sudah ada “banyak pencarian” yang terjadi, dan jumlahnya mendekati 400 ribu per hari. Dalam kondisi sehari-hari, sistem berjalan dengan kapasitas cadangan yang cukup dan ada beberapa langkah autoscaling
Masalahnya ada pada detail ketika sebagian pengguna mengeksploitasi kasus patologis. Karena kurang pengalaman, kami tidak tahu jenis traffic alami atau patologis apa yang seharusnya bisa kami prediksi dan simulasikan sebelumnya
Mensimulasikan beban 20 ribu pengguna pencarian bersamaan terdengar seperti eksperimen yang layak dilakukan sejak awal, dan kami memang melakukan hal yang mirip. Namun melihat gangguan kali ini, tetap saja masalah ini kemungkinan tidak akan tertangkap
Sejauh ini ada sekitar 10 orang yang menjalankan security scanner pada layanan produksi kami, dan traffic yang terjadi saat itu lebih besar daripada gangguan kali ini
Menyeimbangkan pengembangan seperti ini sambil tetap harus membangun fitur sangat sulit, dan jelas kami seharusnya melakukan lebih banyak. Seperti saya katakan di tulisan lain, dalam waktu dekat kami ingin memperluas tim agar upaya seperti ini tidak terlalu tersebar tipis
Ada banyak hal yang bisa dikatakan jika melihat ke belakang, tetapi saya harap ini memberi gambaran yang lebih transparan tentang bagaimana kami sampai di titik ini
Apalagi jika seseorang menghantam mereka dengan cara seperti itu untuk pertama kalinya
Sebagai perbandingan, sistem yang saya tangani bukan skala FAANG, tetapi dari sisi request rate jelas lebih besar daripada Kagi. Kagi juga akan belajar dengan cepat, dan kalau selama itu masalah seperti ini masih muncul, menurut saya itu justru masih cukup wajar. Itu juga bisa menjadi tanda bahwa mereka bergerak ke arah yang benar
Sebagai pengguna berbayar Kagi, setelah mengalami downtime saya jadi sadar betapa saya selama ini menganggap keandalan Google sebagai sesuatu yang biasa saja
Selama 20 tahun terakhir, Google hampir tidak pernah down bagi saya kecuali mungkin satu kali. Kehilangan akses ke mesin pencari cukup fatal
Saya benar-benar menyukai Kagi sehingga membayarnya, tetapi mengalami downtime pada bulan kedua pemakaian terasa cukup mengganggu. Saya memang suka postmortem, tetapi saya berharap tidak perlu membacanya
Meski begitu, saya berharap pengalaman ini membuat Kagi menjadi layanan yang lebih tangguh dan andal
Mesin pencari bukan layanan dengan lock-in seperti penyedia email atau ISP
Saya ternyata benar-benar bergantung pada Kagi yang cepat dan berfungsi baik di mana saja
Saya teringat saat menjalankan proof of concept untuk tool networking baru di tempat pelanggan. Sekitar 2 menit setelah dijalankan, seluruh jaringan pelanggan tumbang
Kami berada di area sandbox yang terisolasi, jadi produk kami seharusnya tidak mungkin menyebabkan gangguan ke seluruh jaringan, tetapi di kepala saya terus terpikir, “nggak mungkin kan, iya kan… iya kan?!?!”
“Kemudian kami berhasil menghubungi akun yang diblokir itu, dan akun tersebut mengaku menggunakan akun itu untuk melakukan scraping otomatis atas hasil kami; ini tidak diperbolehkan dalam ketentuan layanan.”
Semua permintaan RPC/API/HTTP yang masuk sebisa mungkin, terutama permintaan publik, harus diberi batas QPS
Pernah ada fitur pencarian dengan autocomplete, dan demi mendukung pengguna yang mengetik cepat, kami sengaja menghapus sebagian pembatasan laju pada endpoint itu
Suatu hari sekitar pukul 6 pagi, seseorang di Tennessee berangkat kerja lalu meletakkan dompetnya di atas keyboard, dan dompet itu menekan satu tombol terus-menerus sehingga setiap input tombol mulai menghantam API
Tentu saja setelah sekitar 15 menit, DB menjadi sangat tidak stabil, dan latensi DB menjadi begitu besar sampai satu server web crash. Gangguan berantai berlanjut hingga seluruh klaster produksi tumbang
Tak perlu dikatakan lagi, hari itu pembatasan laju ditambahkan kembali