Analisis pasca-insiden atas kejadian Kagi minggu lalu

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 [e-mail].

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.

[GN⁺]

Opini Hacker News

• Opini tentang insiden yang terjadi bersamaan dengan upgrade infrastruktur

  • Disebutkan bahwa insiden yang terjadi bersamaan dengan upgrade infrastruktur melalui penambahan resource RAM pada VM adalah kebetulan belaka.
  • Disebutkan bahwa "kebetulan" seperti ini sering terjadi dan membuat orang meragukan dirinya sendiri saat menyelesaikan masalah.
  • Diperingatkan bahwa jika panik saat menyelesaikan masalah, seseorang bisa menerapkan hotfix yang justru merusak hal lain, dan ini bisa menjadi Hukum Murphy yang kejam bagi administrator sistem dan developer.

• Pengalaman pengguna terhadap halaman status Kagi

  • Seorang pengguna mengatakan ia merasa gelisah karena halaman status Kagi menunjukkan bahwa semuanya berfungsi normal.
  • Dibandingkan dengan layanan yang pernah diandalkan sebelumnya, yang langsung memperbarui halaman status sehingga ia tahu masalahnya bukan ada di perangkatnya.
  • Ia mengatakan tetap berencana menggunakan Kagi, tetapi berharap seperti yang disebutkan dalam postmortem, kode halaman status dipindahkan ke layanan/platform lain.

• Komentar yang membagikan pengalaman pribadi

  • Seseorang membagikan bahwa ia secara pribadi telah beberapa kali mengalami jenis gangguan layanan yang sama, dan pernah mencoba menyelesaikan masalah pada kesehatan connection pool database.
  • Ditunjukkan bahwa metrik saturasi umum database (CPU%, IOPS, dan sebagainya) tidak banyak berubah selama gangguan seperti ini, dan sebaliknya lock contention bisa menjadi penyebab masalah.
  • Sebagai rekomendasi untuk RDBMS yang digunakan Kagi, disarankan untuk membuat grafik seperti latensi tunggu I/O global, waktu perolehan lock, dan waktu eksekusi query.

• Komentar tentang pengalaman startup

  • Disebutkan bahwa semua startup pada akhirnya akan mengalami masalah seperti ini di suatu titik.
  • Bisa jadi mereka tidak punya cukup waktu atau sumber daya untuk membangun kemampuan mencegahnya, atau tidak menyangka masalah tertentu itu akan terjadi.
  • Disebutkan bahwa transparansi dan pembelajaran itu penting, tetapi kadang kompensasi juga penting, dan disarankan agar Kagi mempertimbangkan pemberian kredit pencarian untuk waktu ketika layanan tidak dapat digunakan.

• Komentar tentang observabilitas sistem internal

  • Ditunjukkan bahwa masalah seharusnya bisa dikenali lebih cepat, dan dashboard Datadog serta query Splunk yang tepat seharusnya bisa memperjelas masalah jauh lebih cepat.
  • Disarankan untuk menjadikannya pengalaman belajar dengan berinvestasi pada monitoring yang lebih baik.

• Opini pengguna berbayar tentang keandalan Kagi

  • Seorang pengguna berbayar yang mengalami downtime Kagi mengatakan ia baru menyadari bahwa selama ini ia menganggap remeh keandalan Google.
  • Disebutkan bahwa kehilangan akses ke mesin pencari bisa menjadi gangguan besar, dan ia membagikan bahwa meskipun menyukai Kagi, mengalami downtime tetap terasa tidak menyenangkan.
  • Disebutkan harapannya agar pengalaman ini membuat Kagi menjadi layanan yang lebih kuat dan andal.

• Komentar tentang scraper yang menyebabkan gangguan layanan

  • Terkait fakta bahwa scraper yang dijalankan oleh satu pengguna menyebabkan layanan berhenti selama 7 jam, diajukan pertanyaan apakah saat pengujian mereka tidak menanyakan, "apa yang terjadi jika ada banyak pencarian?"

• Komentar tentang pengalaman menggunakan Kagi dan postmortem

  • Setelah menggunakan Kagi selama beberapa minggu, seseorang membagikan bahwa saat layanan tidak langsung dimuat minggu lalu, ia tidak tahu harus berbuat apa.
  • Ia mengatakan bahwa sebelum postmortem terbit, ia sudah melupakan insiden itu, dan menyampaikan terima kasih kepada tim yang membuat pencarian menjadi sesuatu yang tidak perlu dipikirkan.

• Komentar tentang database single-core yang digunakan di GCP

  • Ada respons positif terhadap fakta bahwa Kagi selama ini menggunakan database single-core termurah yang tersedia di GCP.
  • Disarankan untuk mempertimbangkan sesuatu seperti PolyScale yang dapat menangani lonjakan beban baca dan mendorong performa lebih jauh.

• Komentar tentang scraping otomatis

  • Disebutkan bahwa setelah akun diblokir, pengguna yang kemudian menghubungi mengklaim telah menggunakan akun tersebut untuk melakukan scraping hasil secara otomatis.
  • Direkomendasikan untuk menetapkan pembatasan QPS (query per second) pada semua permintaan RPC / API / HTTP yang masuk, terutama yang bersifat publik.