🥇Post Mortem karena tidak tersedianya Quay.io

Catatan. terjemahan: pada awal Agustus, Red Hat secara terbuka berbicara tentang penyelesaian masalah aksesibilitas yang dihadapi pengguna layanannya pada bulan-bulan sebelumnya dermaga.io (Ini didasarkan pada registri untuk gambar kontainer, yang diterima perusahaan bersamaan dengan pembelian CoreOS). Terlepas dari minat Anda terhadap layanan ini, jalur yang diambil oleh para insinyur SRE perusahaan untuk mendiagnosis dan menghilangkan penyebab kecelakaan sangatlah bermanfaat.

Pada tanggal 19 Mei, dini hari (Waktu Musim Panas Bagian Timur, EDT), layanan quay.io mogok. Kecelakaan tersebut berdampak pada konsumen quay.io dan proyek Open Source yang menggunakan quay.io sebagai platform untuk membangun dan mendistribusikan perangkat lunak. Red Hat menghargai kepercayaan keduanya.

Sebuah tim insinyur SRE segera terlibat dan mencoba menstabilkan layanan Quay sesegera mungkin. Namun, saat mereka melakukan hal 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 diblokir setelah layanan ditingkatkan ke kapasitas penuh.

«Apa yang telah berubah?" - ini adalah pertanyaan pertama yang biasanya ditanyakan dalam kasus seperti itu. Kami memperhatikan bahwa sesaat sebelum masalah ini, cluster OpenShift Dedicated (yang menjalankan quay.io) mulai memperbarui ke versi 4.3.19. Karena quay.io berjalan pada Red Hat OpenShift Dedicated (OSD), pembaruan rutin dilakukan secara rutin dan tidak pernah menimbulkan masalah. Selain itu, selama enam bulan sebelumnya, kami telah meningkatkan cluster Quay beberapa kali tanpa gangguan layanan.

Saat kami mencoba memulihkan layanan, teknisi lain mulai menyiapkan kluster OSD baru dengan versi perangkat lunak sebelumnya, sehingga jika terjadi sesuatu, mereka dapat menerapkan semua yang ada di dalamnya.

Analisis Akar Penyebab

Gejala utama dari kegagalan ini adalah longsornya puluhan ribu koneksi database, yang membuat instance MySQL tidak dapat dioperasikan secara efektif. Hal ini mempersulit diagnosis masalahnya. Kami telah menetapkan batasan jumlah maksimum koneksi dari klien untuk membantu tim SRE mengevaluasi masalah tersebut. Kami tidak melihat adanya lalu lintas yang tidak biasa ke database: faktanya, sebagian besar permintaan telah dibaca, dan hanya sedikit yang ditulis.

Kami juga mencoba mengidentifikasi pola lalu lintas database yang dapat menyebabkan longsoran salju ini. Namun, kami tidak dapat 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 mencapai kapasitas penuh, database akan terhenti. Ini berarti bahwa instance RDS perlu direstart selain semua pod quay.io.

Pada malam hari, kami menstabilkan layanan dalam mode read-only dan menonaktifkan sebanyak mungkin fungsi yang tidak penting (misalnya, pengumpulan sampah namespace) untuk mengurangi beban pada database. Pembekuan telah berhenti tapi alasannya tidak pernah ditemukan. Kluster OSD baru telah siap, dan kami memigrasikan layanan, menghubungkan lalu lintas, dan melanjutkan pemantauan.

Quay.io bekerja secara stabil pada cluster OSD baru, jadi kami kembali ke log database, tetapi tidak dapat menemukan korelasi yang dapat menjelaskan penyumbatan tersebut. Insinyur OpenShift bekerja bersama kami untuk memahami apakah perubahan pada Red Hat OpenShift 4.3.19 dapat menyebabkan masalah pada Quay. Namun, tidak ada yang ditemukan, dan Masalah tersebut tidak dapat direproduksi dalam kondisi laboratorium.

Kegagalan kedua

Pada tanggal 28 Mei, sesaat sebelum tengah hari EDT, quay.io kembali mogok dengan gejala yang sama: database diblokir. Dan sekali lagi kami mengerahkan seluruh upaya kami untuk penyelidikan. Pertama-tama, perlu memulihkan layanan. Namun kali ini me-reboot RDS dan me-restart pod quay.io tidak menghasilkan apa-apa: Longsoran koneksi lainnya telah membanjiri pangkalan. Tapi kenapa?

Quay ditulis dengan Python dan setiap pod beroperasi sebagai wadah monolitik tunggal. Runtime kontainer menjalankan banyak tugas paralel secara bersamaan. Kami menggunakan perpustakaan gevent bawah gunicorn untuk memproses permintaan web. Saat permintaan masuk ke Quay (melalui API kami sendiri, atau melalui API Docker), permintaan tersebut ditetapkan ke pekerja gevent. Biasanya pekerja ini harus menghubungi 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 teori dapat membebani instance MySQL. Berkat pantauan, Quay diketahui rata-rata memproses 5 ribu permintaan per detik. Jumlah koneksi ke database kira-kira sama. 5 ribu koneksi berada dalam kemampuan instance RDS kami (yang tidak bisa dikatakan sekitar puluhan ribu). Untuk beberapa alasan, terjadi lonjakan jumlah koneksi yang tidak terduga, namun, kami tidak melihat adanya korelasi dengan permintaan masuk.

Kali ini kami bertekad untuk mencari dan menghilangkan sumber masalahnya, dan tidak membatasi diri pada reboot. Ke basis kode Quay perubahan dilakukan untuk membatasi jumlah koneksi ke database untuk setiap pekerja acara. Angka ini menjadi parameter dalam konfigurasi: dimungkinkan untuk mengubahnya dengan cepat tanpa membuat image container baru. Untuk mengetahui berapa banyak koneksi yang dapat ditangani secara realistis, kami menjalankan beberapa pengujian dalam lingkungan pementasan, menetapkan nilai yang berbeda untuk melihat bagaimana hal ini akan memengaruhi skenario pengujian beban. Hasilnya, ditemukan hal itu Quay mulai memunculkan 502 kesalahan ketika jumlah koneksi melebihi 10 ribu.

Kami segera menerapkan versi baru ini ke produksi dan mulai memantau jadwal koneksi database. Dulu, markas dikunci setelah sekitar 20 menit. Setelah 30 menit bebas masalah, kami punya harapan, dan satu jam kemudian kami punya kepercayaan diri. Kami memulihkan lalu lintas ke situs tersebut dan memulai analisis postmortem.

Setelah berhasil melewati masalah yang menyebabkan pemblokiran, kami belum menemukan alasan sebenarnya. Dipastikan bahwa hal ini tidak terkait dengan perubahan apa pun di OpenShift 4.3.19, karena hal yang sama terjadi pada versi 4.3.18, yang sebelumnya bekerja dengan Quay tanpa masalah.

Jelas ada sesuatu yang lain yang mengintai di cluster itu.

Studi Terperinci

Quay.io menggunakan pengaturan default untuk terhubung ke database selama enam tahun tanpa masalah. Apa yang berubah? Terlihat jelas bahwa selama ini traffic di quay.io terus berkembang. Dalam kasus kami, sepertinya beberapa nilai ambang batas telah tercapai, yang berfungsi sebagai pemicu longsoran koneksi. Kami terus mempelajari log database setelah kegagalan kedua, namun tidak menemukan pola atau hubungan yang jelas.

Sementara itu, tim SRE telah berupaya meningkatkan kemampuan observasi permintaan Quay dan kesehatan layanan secara keseluruhan. Metrik dan dasbor baru telah diterapkan, menunjukkan bagian Quay mana yang paling banyak diminati pelanggan.

Quay.io berfungsi dengan baik hingga 9 Juni. Pagi ini (EDT) kami kembali melihat peningkatan signifikan dalam jumlah koneksi database. Kali ini tidak ada waktu henti, karena parameter baru membatasi jumlahnya dan tidak mengizinkannya melebihi throughput MySQL. Namun, selama sekitar setengah jam, banyak pengguna mencatat kinerja quay.io yang lambat. Kami dengan cepat mengumpulkan semua kemungkinan data menggunakan alat pemantauan tambahan. Tiba-tiba sebuah pola muncul.

Tepat sebelum lonjakan koneksi, sejumlah besar permintaan dibuat ke App Registry API. App Registry adalah fitur quay.io yang kurang dikenal. Ini memungkinkan Anda menyimpan hal-hal seperti bagan Helm dan wadah dengan metadata yang kaya. Sebagian besar pengguna quay.io tidak menggunakan fitur ini, tetapi Red Hat OpenShift secara aktif menggunakannya. OperatorHub sebagai bagian dari OpenShift menyimpan semua operator di App Registry. Operator-operator ini menjadi dasar ekosistem beban kerja OpenShift dan model operasi yang berpusat pada mitra (operasi Hari ke-2).

Setiap cluster OpenShift 4 menggunakan operator dari OperatorHub bawaan untuk menerbitkan katalog operator yang tersedia untuk instalasi dan memberikan pembaruan kepada operator yang sudah diinstal. Dengan semakin populernya OpenShift 4, jumlah cluster di seluruh dunia juga meningkat. Masing-masing kluster ini mengunduh konten operator untuk menjalankan OperatorHub bawaan, menggunakan App Registry di dalam quay.io sebagai backend. Dalam pencarian kami untuk sumber masalahnya, kami melewatkan fakta bahwa seiring dengan semakin populernya OpenShift, beban pada salah satu fungsi quay.io yang jarang digunakan juga meningkat..

Kami melakukan beberapa analisis lalu lintas permintaan App Registry dan melihat kode registri. Kekurangan langsung terungkap, sehingga query ke database tidak terbentuk secara optimal. Saat beban rendah tidak menimbulkan masalah, namun bila beban bertambah menjadi sumber masalah. App Registry ternyata memiliki dua titik akhir bermasalah yang tidak merespons dengan baik terhadap peningkatan beban: yang pertama menyediakan daftar semua paket di repositori, yang kedua mengembalikan semua blob untuk paket tersebut.

Penghapusan penyebab

Selama minggu berikutnya kami menghabiskan waktu untuk mengoptimalkan kode App Registry itu sendiri dan lingkungannya. Kueri SQL yang jelas-jelas tidak efektif dikerjakan ulang dan panggilan perintah yang tidak perlu dihilangkan tar (dijalankan setiap kali blob diambil), caching ditambahkan jika memungkinkan. Kami kemudian melakukan pengujian kinerja ekstensif dan membandingkan kecepatan App Registry sebelum dan sesudah perubahan.

Permintaan API yang sebelumnya memakan waktu hingga setengah menit kini diselesaikan dalam hitungan milidetik. Minggu berikutnya kami menerapkan perubahan pada produksi, dan sejak itu quay.io telah bekerja dengan stabil. Selama waktu ini, terdapat beberapa lonjakan tajam lalu lintas di titik akhir App Registry, namun perbaikan yang dilakukan dapat mencegah pemadaman basis data.

Apa yang telah kita pelajari?

Jelas bahwa layanan apa pun berusaha menghindari waktu henti. Dalam kasus kami, kami percaya bahwa pemadaman yang terjadi baru-baru ini telah membantu menjadikan quay.io lebih baik. Kami telah mempelajari beberapa pelajaran penting yang ingin kami bagikan:

Data tentang siapa yang menggunakan layanan Anda dan bagaimana caranya tidak pernah berlebihan. Karena Quay “baru saja berfungsi”, kami tidak perlu menghabiskan waktu untuk mengoptimalkan lalu lintas dan mengelola beban. Semua ini menciptakan rasa aman palsu bahwa layanan dapat diperluas tanpa batas waktu.
Ketika layanan turun, mengaktifkannya kembali dan menjalankannya adalah prioritas utama.. Karena Quay terus mengalami database yang terkunci selama pemadaman pertama, prosedur standar kami tidak memberikan efek yang diharapkan dan kami tidak dapat memulihkan layanan menggunakan prosedur tersebut. Hal ini menyebabkan situasi di mana waktu harus dihabiskan untuk menganalisis dan mengumpulkan data dengan harapan menemukan akar permasalahan - alih-alih memfokuskan semua upaya untuk memulihkan fungsionalitas.
Evaluasi dampak setiap fitur layanan. Klien jarang menggunakan App Registry, jadi ini bukan prioritas tim kami. Ketika beberapa fitur produk jarang digunakan, bugnya jarang muncul, dan pengembang berhenti memantau kodenya. Sangat mudah untuk menjadi korban kesalahpahaman bahwa memang demikianlah seharusnya—sampai tiba-tiba fungsi tersebut menjadi pusat dari sebuah insiden besar.

Apa selanjutnya?

Upaya untuk memastikan stabilitas layanan tidak pernah berhenti dan kami terus meningkatkannya. Seiring dengan pertumbuhan volume lalu lintas di quay.io, 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:

Terapkan replika database hanya-baca untuk membantu layanan menangani lalu lintas yang sesuai jika terjadi masalah dengan instans RDS utama.
Memperbarui instans RDS. Versi saat ini sendiri bukanlah masalahnya. Sebaliknya, kami hanya ingin menghapus jejak yang salah (yang kami ikuti selama kegagalan); Menjaga perangkat lunak tetap mutakhir akan menghilangkan faktor lain jika terjadi pemadaman di masa mendatang.
Caching tambahan di seluruh cluster. Kami terus mencari area dimana caching dapat mengurangi beban pada database.
Menambahkan firewall aplikasi web (WAF) untuk melihat siapa yang terhubung ke quay.io dan alasannya.
Dimulai dengan rilis berikutnya, cluster Red Hat OpenShift akan meninggalkan App Registry dan memilih Operator Catalogs berdasarkan image container yang tersedia di quay.io.
Pengganti jangka panjang untuk App Registry dapat berupa dukungan untuk spesifikasi artefak Open Container Initiative (OCI). Saat ini diimplementasikan sebagai fungsionalitas Quay asli dan akan tersedia bagi pengguna ketika spesifikasinya sendiri telah diselesaikan.

Semua hal di atas adalah bagian dari investasi berkelanjutan Red Hat di quay.io seiring kami beralih dari tim kecil "gaya startup" ke platform matang yang digerakkan oleh SRE. Kami tahu bahwa banyak pelanggan kami mengandalkan quay.io dalam pekerjaan sehari-hari mereka (termasuk Red Hat!) dan kami berusaha setransparan mungkin mengenai pemadaman yang terjadi baru-baru ini dan upaya berkelanjutan untuk melakukan perbaikan.

Post Mortem di Quay.io tidak tersedia