Cara Kami Mencapai Penerbitan Dengan Sifar Ralat 502

Setiap kali kami menerbitkan bahagian belakang Mythex, beberapa permintaan gagal dengan 502 Bad Gateway. Tidak banyak, tetapi 502 semasa penerbitan bermakna klik seseorang tidak melakukan apa-apa, atau binaan yang sedang mereka perhatikan terhenti seketika. Kami mengesannya kepada dua masalah berasingan: pemantau pemulihan kendiri yang bertelingkah dengan penerbitan kami, dan jurang antara masa pelayan berhenti mendengar dan masa pengimbang beban berhenti menghantar trafik kepadanya. Merentasi tiga penerbitan pengeluaran berturut-turut selepas pembetulan, bilangannya turun dari 10 kepada 6 dan kemudian kepada 0.

Susunannya

API dan orkestra kami berjalan sebagai kontena pada sekumpulan kecil pelayan di belakang Application Load Balancer (ALB) AWS. Penerbitan mengemas kini satu pelayan pada satu masa: ia mengosongkan kontena lama, memulakan yang baharu, dan beralih ke yang seterusnya. Sebuah pemantau pada setiap pelayan memeriksa sama ada kontena sedang berjalan dan memulakan semula apa-apa yang tidak berjalan. Ia wujud supaya proses yang ranap pada pukul 3 pagi kembali tanpa sesiapa perlu bangun.

Kedua-duanya munasabah secara berasingan. Bersama-sama, ia tidak.

Masalah 1: pemantau berlumba dengan penerbitan

Pemantau berjalan sekali seminit dan "memulihkan" selepas satu pemeriksaan kesihatan yang gagal. Penerbitan sengaja mengosongkan perkhidmatan selama sehingga 150 saat, dan selama itu pemeriksaan kesihatan sepatutnya gagal. Maka pemantau itu terpicu pada setiap penerbitan.

Kebanyakan masa ia kalah dalam perlumbaan dengan tidak memudaratkan. Sekali, ia menang: ia menulis semula fail compose (penerangan kontena mana yang sepatutnya berjalan) di tengah-tengah penerbitan, dan meninggalkan satu pelayan tanpa kontena gerbang laluan langsung, sementara tugas penerbitan melaporkan kejayaan.

Pembetulannya:

• Satu kunci. Penerbitan kini mengambil kunci fail yang sama dengan skrip bootstrap pelayan, supaya pemantau dan penerbitan tidak pernah berjalan serentak.
• Empat amaran, bukan satu. Pemantau memerlukan empat pemeriksaan gagal berturut-turut sebelum ia bertindak. Perkhidmatan yang sedang dikosongkan tidak lagi kelihatan mati.
• Satu definisi. Fail compose kini mempunyai satu sumber sahaja, diterbitkan kepada pelayan, dan bukannya salinan yang boleh menyimpang.
• Sahkan, jangan percaya. Tugas penerbitan tidak lagi lulus hanya kerana satu arahan mengembalikan kod keluar. Ia menyemak API, orkestra, get laluan dan pekerja penerbitan setiap pelayan sebelum ia boleh berjaya.

Masalah 2: pelayan pergi sebelum trafik

Masalah kedua lebih senyap. Apabila penerbitan mengosongkan pelayan, pelayan itu mula menjawab titik kesihatannya dengan 503 supaya pengimbang beban mengeluarkannya dari edaran. Pelayan kami berbuat demikian selama 5 saat, kemudian ditutup.

Tetapi ALB hanya memeriksa kesihatan dari semasa ke semasa, dan memerlukan beberapa kegagalan berturut-turut sebelum ia berhenti menghala ke sesuatu sasaran, sehingga kira-kira 60 saat dari hujung ke hujung. Maka selama kira-kira 55 saat, pengimbang beban terus menghantar permintaan sebenar kepada pelayan yang sudah berhenti mendengar. Itulah 502 kami.

Pembetulannya ialah menyelaraskan dua garis masa:

• Kumpulan sasaran kini memeriksa setiap 5 saat dan menandakan sasaran sebagai tidak sihat selepas 2 kegagalan. Ia mengambil kira-kira 10 saat untuk menyedarinya.
• Pengosongan terus melayani trafik sebenar selama 15 saat selepas ia mula gagal pemeriksaan kesihatan, supaya sentiasa ada pertindihan.
• Tetapan ini berada dalam skrip yang menyediakan infrastruktur, bukan dalam konsol yang pernah diklik seseorang sekali.

Menjadikan nombor saling mengesahkan

Tamat masa seperti ini bergantung antara satu sama lain. Pengosongan mesti lebih lama daripada masa yang diperlukan pengimbang untuk menyedarinya; pengosongan ditambah penutupan mesti selesai sebelum kontena dibunuh secara paksa. Mudah bagi seseorang untuk menukar satu nombor enam bulan kemudian dan secara senyap memperkenalkan semula pepijat itu.

Jadi kami menulis hubungan itu sebagai ujian: pengosongan mesti lebih panjang daripada selang pemeriksaan kesihatan didarab dengan ambang kegagalan; masa untuk ditandakan sihat semula mesti kekal pendek; keseluruhan pengosongan mesti muat dalam tempoh tangguh henti kontena. Ubah satu nombor tanpa yang lain dan CI gagal. Kami juga menguji ujian itu sendiri dengan mutasi, iaitu menukar setiap nombor kepada nilai yang salah dan memeriksa sama ada satu ujian menangkapnya.

Mengukur penerbitan mudah tersilap

Ukuran pertama kami menyatakan penerbitan yang bersih itu kira-kira 3% rosak. Ia tidak rosak. Kami mengira setiap respons yang bukan 200, dan 503 daripada titik kesihatan semasa pengosongan bukan kegagalan. Itu pengosongan yang melakukan tugasnya, memberitahu pengimbang beban supaya tidak memilih pelayan itu sementara ia terus melayani permintaan sebenar.

Apa yang dirasai pengguna ialah 502: permintaan tidak sampai kepada sesiapa. Mengira hanya itu memberi gambaran sebenar: 10, kemudian 6, kemudian 0 merentasi tiga penerbitan pengeluaran.

Apa yang kami pelajari daripadanya

• Pemulihan kendiri perlu tahu tentang masa henti yang dirancang. Pemantau yang tidak dapat membezakan penerbitan daripada ranap akhirnya akan berlawan dengan penerbitan.
• Pengosongan ialah jabat tangan. Pelayan mesti terus berkhidmat sehingga pengimbang beban terbukti telah berhenti menghantar trafik, dan masa itu ditetapkan pada pengimbang, bukan pada pelayan.
• Kodkan invarian sebagai ujian. Nombor operasi menyimpang. Ujian yang menghubungkannya antara satu sama lain tidak.
• Tentukan apa yang anda ukur sebelum mengukur. "Ralat" ialah metrik yang salah; "permintaan yang tidak sampai kepada sesiapa" ialah yang betul.

Jika anda menerbitkan aplikasi di Mythex, tiada satu pun ini kelihatan kepada anda, dan itulah tujuannya. Berkaitan: bagaimana aplikasi terbitan anda kekal aktif semasa anda menerbitkannya semula.