Pada pagi hari tanggal 19 Mei (EDT), quay.io jatuh. Bencana tersebut memengaruhi konsumen quay.io dan proyek Open Source yang menggunakan quay.io sebagai platform untuk membangun dan mendistribusikan perangkat lunak. Red Hat menghargai kepercayaan keduanya.
Tim insinyur SRE segera turun tangan dan mencoba menstabilkan layanan Quay secepat mungkin. Namun, saat mereka melakukan ini, klien kehilangan kemampuan untuk menampilkan gambar baru, dan hanya sesekali mereka dapat menarik gambar yang sudah ada. Untuk beberapa alasan yang tidak diketahui, database quay.io dikunci setelah layanan ditingkatkan ke kapasitas penuh.
“ Apa yang berubah? "- ini adalah pertanyaan pertama yang biasanya ditanyakan dalam kasus seperti itu. Kami memperhatikan bahwa tidak lama sebelum masalah tersebut, cluster OpenShift Dedicated (tempat quay.io berjalan) mulai memperbarui ke versi 4.3.19. Karena quay.io didukung oleh Red Hat OpenShift Dedicated (OSD), pembaruan rutin menjadi hal yang biasa dan tidak pernah menimbulkan masalah. Selain itu, selama enam bulan terakhir, kami telah memperbarui kluster Quay beberapa kali tanpa gangguan layanan apa pun.
Saat kami mencoba memulihkan layanan, teknisi lain mulai menyiapkan cluster OSD baru dengan versi perangkat lunak sebelumnya untuk menerapkan semua yang ada di dalamnya jika diperlukan.
Analisis Akar Penyebab
Gejala utama crash adalah longsoran puluhan ribu koneksi database yang membuat instance MySQL dinonaktifkan secara efektif. Ini menyulitkan untuk mendiagnosis masalah. Kami telah menetapkan batas jumlah koneksi maksimum dari pelanggan untuk membantu tim SRE menilai masalah. Kami tidak melihat lalu lintas yang tidak biasa ke database: pada kenyataannya, sebagian besar permintaan adalah untuk membaca, dan hanya sedikit untuk menulis.
Kami juga mencoba mengidentifikasi pola lalu lintas database yang dapat menyebabkan longsoran salju ini. Namun, tidak mungkin menemukan pola apa pun di log. Sambil menunggu cluster baru dengan OSD 4.3.18 siap, kami terus mencoba meluncurkan pod quay.io. Setiap kali cluster berada pada kapasitas penuh, database akan membeku. Ini berarti bahwa instance RDS harus dimulai ulang selain semua pod quay.io.
Pada malam hari, kami menstabilkan layanan dalam mode hanya-baca dan menonaktifkan fungsi non-esensial maksimum (misalnya, pengumpulan sampah di namespace) untuk mengurangi beban pada database. Hang berhenti, tetapi alasannya tidak pernah ditemukan . Kluster OSD baru sudah siap, dan kami memigrasi layanan, lalu lintas yang terhubung, dan pemantauan berkelanjutan.
Quay.io berjalan secara stabil di cluster OSD baru, jadi kami kembali ke log database, tetapi tidak dapat menemukan korelasi yang menjelaskan kunci tersebut. Teknisi OpenShift bekerja dengan kami untuk melihat apakah perubahan di Red Hat OpenShift 4.3.19 mungkin menyebabkan masalah Quay. Namun, tidak ada yang ditemukan, dan masalahnya tidak dapat direproduksi di laboratorium .
Kegagalan kedua
Pada 28 Mei, tak lama sebelum siang hari EDT, quay.io crash lagi dengan gejala yang sama: database diblokir. Sekali lagi, kami mengerahkan semua kekuatan kami untuk penyelidikan. Pertama-tama, perlu untuk memulihkan layanan. Namun , kali ini, memulai ulang RDS dan memulai kembali pod quay.io tidak menghasilkan apa-apa : longsoran koneksi lain menyapu pangkalan. Tapi kenapa?
Quay ditulis dengan Python dan setiap pod beroperasi sebagai satu kontainer monolitik. Banyak tugas paralel berjalan secara bersamaan dalam runtime penampung. Kami menggunakan perpustakaan di
geventbawahgunicornuntuk memproses permintaan web. Saat Quay menerima permintaan (melalui API kita sendiri, atau melalui Docker API), pekerja gevent ditugaskan untuk itu. Biasanya, pekerja ini perlu berkomunikasi dengan database. Setelah kegagalan pertama, kami menemukan bahwa pekerja gevent terhubung ke database menggunakan pengaturan default.
Mengingat banyaknya pod Quay dan ribuan permintaan masuk per detik, sejumlah besar koneksi database secara teoritis dapat membebani instance MySQL. Berkat pantauan, diketahui bahwa Quay memproses rata-rata 5 ribu request per detik. Jumlah koneksi ke database hampir sama. 5 ribu koneksi dengan margin yang sesuai dengan kemampuan instans RDS kami (yang tidak bisa dikatakan sekitar puluhan ribu).Untuk beberapa alasan, ada lonjakan tak terduga dalam jumlah koneksi , namun kami tidak melihat adanya korelasi dengan permintaan yang masuk.
Kali ini, kami bertekad untuk mencari dan memperbaiki sumber masalahnya, bukan hanya reboot. Perubahan telah dilakukan pada basis kode Quay untuk membatasi jumlah koneksi database untuk setiap pekerja gevent . Nomor ini menjadi parameter dalam konfigurasi: menjadi mungkin untuk mengubahnya "dengan cepat" tanpa membuat gambar container baru. Untuk mengetahui berapa banyak koneksi yang benar-benar harus ditangani, kami menjalankan beberapa pengujian dengan lingkungan penahapan yang menetapkan nilai berbeda untuk melihat bagaimana hal ini akan memengaruhi skenario pengujian beban. Hasilnya, ternyataQuay mulai menampilkan error 502 ketika jumlah koneksi melebihi 10K.
Kami segera menerapkan versi baru ini ke produksi dan mulai memantau jadwal koneksi database. Di masa lalu, pangkalan diblokir setelah sekitar 20 menit. Setelah 30 menit tanpa masalah, kami memiliki harapan, dan satu jam kemudian, kepercayaan diri. Kami memulihkan lalu lintas ke pos di situs dan memulai analisis postmortem.
Setelah berhasil mengatasi masalah yang mengarah ke pemblokiran, kami tidak menemukan penyebab sebenarnya . Dipastikan bahwa itu tidak terkait dengan perubahan apa pun di OpenShift 4.3.19, seperti yang terjadi pada versi 4.3.18, yang sebelumnya bekerja dengan Quay tanpa masalah.
Jelas ada sesuatu yang lain bersembunyi di cluster.
Studi rinci
Quay.io telah menggunakan pengaturan default untuk menghubungkan ke database selama enam tahun tanpa masalah. Apa yang berubah? Jelas bahwa lalu lintas ke quay.io terus meningkat selama ini. Dalam kasus kami, semuanya tampak seolah-olah nilai ambang tertentu tercapai, yang berfungsi sebagai pemicu longsoran koneksi. Kami terus memeriksa log basis data setelah kerusakan kedua, tetapi tidak menemukan pola atau hubungan yang jelas.
Sementara itu, tim SRE telah mengerjakan peningkatan pada observasi kueri Quay dan kesehatan layanan secara keseluruhan. Metrik dan dasbor baru telah diterapkan untuk menunjukkan bagian mana dari Quay yang paling banyak diminati pelanggan.
Quay.io bekerja dengan baik hingga 9 Juni. Di pagi hari (melalui EDT), kami kembali menyaksikan peningkatan yang signifikan dalam jumlah koneksi database. Kali ini, tidak ada downtime , karena parameter baru membatasi jumlahnya dan tidak memungkinkan melebihi bandwidth MySQL. Namun, selama sekitar setengah jam, banyak pengguna memperhatikan bahwa quay.io lambat. Kami dengan cepat mengumpulkan semua data yang mungkin menggunakan alat pemantauan tambahan. Sebuah pola tiba-tiba muncul.
Tepat sebelum lompatan koneksi, sejumlah besar permintaan dikirim ke App Registry API... App Registry adalah fitur yang kurang dikenal dari quay.io. Ini memungkinkan Anda untuk menyimpan hal-hal seperti diagram Helm dan penampung yang kaya akan metadata. Sebagian besar pengguna quay.io tidak menggunakan fitur ini, tetapi Red Hat OpenShift aktif menggunakannya. OperatorHub dalam OpenShift menyimpan semua operator di App Registry. Operator ini membentuk dasar untuk ekosistem beban kerja OpenShift dan model operasi yang berpusat pada mitra (dalam operasi Hari ke-2).
Setiap kluster OpenShift 4 menggunakan operator dari OperatorHub bawaan untuk mempublikasikan katalog operator yang tersedia untuk penginstalan dan menyediakan pembaruan untuk yang sudah diinstal. Dengan semakin populernya OpenShift 4, jumlah cluster di atasnya di seluruh dunia telah meningkat. Masing-masing cluster ini memuat konten operator untuk menjalankan OperatorHub built-in menggunakan App Registry di dalam quay.io sebagai backend. Mencari sumber masalahnya, kami melewatkan fakta bahwa popularitas OpenShift secara bertahap meningkat, begitu pula beban pada salah satu fungsi quay.io yang jarang digunakan .
Kami melakukan beberapa analisis lalu lintas permintaan App Registry dan memeriksa kode registri. Segera, kekurangan terungkap, karena kueri mana ke database dibentuk kurang optimal. Mereka tidak menimbulkan masalah di bawah beban ringan, tetapi ketika beban meningkat, mereka menjadi sumber masalah. App Registry ternyata memiliki dua titik akhir bermasalah yang tidak merespons dengan baik peningkatan beban: yang pertama memberikan daftar semua paket dalam repositori, yang kedua mengembalikan semua blob untuk sebuah paket.
Penghapusan penyebab
Selama minggu depan, kami telah mengoptimalkan kode App Registry itu sendiri dan lingkungannya. Kueri SQL yang jelas tidak efisien dikerjakan ulang, panggilan yang tidak perlu ke perintah dihilangkan
tar(dijalankan setiap kali blob diambil), dan cache ditambahkan jika memungkinkan. Kemudian kami melakukan pengujian kinerja yang ekstensif dan membandingkan kinerja App Registry sebelum dan sesudah perubahan.
Permintaan API yang biasanya membutuhkan waktu hingga setengah menit kini diselesaikan dalam milidetik . Kami meluncurkan perubahan pada produksi minggu depan dan quay.io telah stabil sejak saat itu. Selama waktu ini, ada beberapa lonjakan lalu lintas di titik akhir App Registry, tetapi peningkatan yang dilakukan telah mencegah pemadaman database.
Apa yang telah kita pelajari?
Jelas bahwa layanan apa pun mencoba menghindari waktu henti. Dalam kasus kami, kami yakin bahwa kerusakan baru-baru ini telah membantu membuat quay.io lebih baik. Untuk diri kami sendiri, kami telah mengambil beberapa pelajaran utama yang ingin kami bagikan:
- Data tentang siapa yang menggunakan layanan Anda dan bagaimana tidak berlebihan . Karena Quay "baru saja berfungsi", kami tidak pernah menghabiskan waktu untuk mengoptimalkan lalu lintas dan mengelola beban. Semua ini menciptakan rasa aman yang palsu bahwa layanan dapat diskalakan tanpa batas.
- , — . Quay , . , — , .
- Evaluasi dampak dari setiap fungsi layanan . Pelanggan jarang menggunakan App Registry, jadi itu bukan prioritas tim kami. Ketika beberapa fitur produk hampir tidak digunakan, bug mereka jarang muncul, dan pengembang berhenti memantau kode. Sangat mudah untuk menjadi mangsa khayalan bahwa memang begitulah seharusnya - sampai tiba-tiba fitur ini menjadi pusat dari sebuah insiden besar.
Apa berikutnya?
Pekerjaan untuk memastikan stabilitas layanan tidak pernah berhenti dan kami terus meningkatkannya. Volume lalu lintas di quay.io terus tumbuh dan kami menyadari bahwa kami memiliki tanggung jawab untuk melakukan segala yang kami bisa untuk memenuhi kepercayaan pelanggan kami. Oleh karena itu, kami sedang mengerjakan tugas-tugas berikut:
- , RDS.
- RDS. . , ( ); .
- . , .
- firewall’ - (WAF), , quay.io.
- , Red Hat OpenShift App Registry (Operator Catalogs), , quay.io.
- Dukungan untuk spesifikasi artefak Open Container Initiative (OCI) bisa menjadi pengganti jangka panjang untuk App Registry. Saat ini sedang diimplementasikan sebagai fungsionalitas Quay asli dan akan tersedia bagi pengguna ketika spesifikasinya diselesaikan.
Semua hal di atas adalah bagian dari investasi berkelanjutan Red Hat di quay.io saat kami beralih dari tim kecil seperti startup ke platform dewasa yang digerakkan oleh SRE. Kami tahu bahwa banyak pelanggan kami mengandalkan quay.io untuk pekerjaan sehari-hari mereka (termasuk Red Hat!) Dan berusaha seterbuka mungkin tentang gangguan yang terjadi baru-baru ini dan upaya berkelanjutan untuk memperbaiki diri.
PS dari penerjemah
Baca juga di blog kami: