Catetan. narjamahkeun.: dina awal Agustus, Red Hat sacara umum nyarioskeun ngeunaan ngarengsekeun masalah aksésibilitas anu dipendakan ku pangguna dina sasih sasih sateuacana. (éta dumasar kana pendaptaran pikeun gambar wadahna, nu parusahaan narima babarengan jeung meuli CoreOS). Paduli kapentingan anjeun dina layanan ieu, jalur nu insinyur SRE parusahaan nyandak pikeun nangtukeun jenis panyakitna sarta ngaleungitkeun ngabalukarkeun kacilakaan éta instructive.
Dina 19 Méi, isuk-isuk (Eastern Daylight Time, EDT), jasa quay.io nabrak. Kacilakaan éta mangaruhan duanana konsumen quay.io sareng proyék Open Source nganggo quay.io salaku platform pikeun ngawangun sareng nyebarkeun parangkat lunak. Red Hat ngahargaan kapercayaan duanana.
Tim insinyur SRE langsung aub sareng nyobian nyaimbangkeun jasa Quay pas mungkin. Sanajan kitu, bari maranéhna ngalakukeun ieu, klien leungit kamampuhan pikeun nyorong gambar anyar, sarta ngan aya kalana aranjeunna bisa narik leuwih aya. Kanggo sababaraha alesan anu teu dipikanyaho, pangkalan data quay.io diblokir saatos skala jasa kana kapasitas pinuh.
«Naon geus robah?"- Ieu patarosan kahiji anu biasana ditanya dina kasus kawas. Kami perhatikeun yén teu lami sateuacan masalah éta, kluster OpenShift Dedicated (anu ngajalankeun quay.io) mimiti ngamutahirkeun kana versi 4.3.19. Kusabab quay.io dijalankeun dina Red Hat OpenShift Dedicated (OSD), apdet rutin rutin sareng henteu kantos nyababkeun masalah. Leuwih ti éta, salila genep bulan saméméhna, kami geus ditingkatkeun Quay klaster sababaraha kali tanpa gangguan dina layanan.
Bari urang nyobian mulangkeun jasa, mimiti insinyur séjén nyiapkeun klaster OSD anyar kalawan versi saméméhna tina software nu, ku kituna lamun aya kajadian, aranjeunna bisa nyebarkeun sagalana dina eta.
Analisis Akar Cukang lantaranana
Gejala utama gagalna nyaéta longsoran puluhan rébu sambungan databés, anu nyababkeun instansi MySQL teu tiasa dianggo sacara efektif. Hal ieu ngajadikeun hésé pikeun nangtukeun jenis panyakitna masalah. Kami geus nyetel wates dina jumlah maksimum sambungan ti klien pikeun mantuan tim SRE evaluate masalah. Kami henteu perhatikeun patalimarga anu teu biasa kana pangkalan data: kanyataanna, seueur pamundut dibaca, sareng ngan ukur sababaraha anu nyerat.
Kami ogé nyobian ngaidentipikasi pola dina lalu lintas databés anu tiasa nyababkeun longsoran ieu. Nanging, kami henteu mendakan pola naon waé dina log. Bari ngadagoan klaster anyar kalawan OSD 4.3.18 siap, urang terus nyobian ngajalankeun pods quay.io. Unggal waktos klaster ngahontal kapasitas pinuh, database bakal freeze. Ieu ngandung harti yén éta téh perlu balikan deui conto RDS salian ti sakabéh pods quay.io.
Nepi ka soré, kami nyaimbangkeun jasa dina modeu baca wungkul sareng mareuman saloba fungsi anu henteu penting (contona, kumpulan sampah namespace) pikeun ngirangan beban dina pangkalan data. Freezes geus dieureunkeun tapi alesanana teu kapanggih. Klaster OSD anyar éta siap, sarta kami hijrah jasa, lalulintas disambungkeun tur ngawaskeun terus.
Quay.io digawé stably dina klaster OSD anyar, sangkan indit deui ka log database, tapi masih teu bisa manggihan korelasi anu bakal ngajelaskeun blockages. Insinyur OpenShift damel sareng kami pikeun ngartos naha parobahan dina Red Hat OpenShift 4.3.19 tiasa nyababkeun masalah sareng Quay. Sanajan kitu, nanaon kapanggih, jeung Henteu mungkin pikeun ngahasilkeun deui masalah dina kaayaan laboratorium.
Kagagalan kadua
Dina 28 Méi, teu lila saméméh EDT lohor, quay.io nabrak deui kalayan gejala anu sarua: database diblokir. Jeung deui urang threw sagala usaha urang kana panalungtikan. Anu mimiti, ieu diperlukeun pikeun mulangkeun jasa. Sanajan kitu waktos ieu rebooting RDS jeung restarting quay.io pods teu nanaon: longsoran sejen tina sambungan geus overwhelmed dasar. Tapi naha?
Quay ditulis dina Python jeung unggal pod beroperasi salaku wadahna monolithic tunggal. Runtime wadahna ngajalankeun seueur tugas paralel sakaligus. Urang ngagunakeun perpustakaan gevent di handap gunicorn pikeun ngolah pamundut wéb. Nalika pamundut sumping ka Quay (via API urang sorangan, atanapi via Docker's API), éta ditugaskeun hiji pagawe gevent. Biasana pagawe ieu kedah ngahubungi pangkalan data. Saatos gagalna munggaran, urang mendakan yén pagawé gevent nyambung ka pangkalan data nganggo setélan standar.
Dibikeun jumlah anu signifikan tina pods Quay sareng rébuan pamundut anu asup per detik, sajumlah ageung sambungan pangkalan data sacara téoritis tiasa ngaleungitkeun conto MySQL. Hatur nuhun kana monitoring, dipikanyaho yén Quay ngolah rata-rata 5 rébu pamundut per detik. Jumlah sambungan kana database éta kira sarua. 5 sarébu sambungan ogé aya dina kamampuan conto RDS kami (anu teu tiasa nyarios ngeunaan puluhan rébu). Kanggo sababaraha alesan aya lonjakan anu teu kaduga dina jumlah sambungan, kumaha oge, urang teu aya bewara naon korelasi jeung requests asup.
waktos Ieu kami ditangtukeun pikeun manggihan tur ngaleungitkeun sumber masalah, sarta teu ngawatesan diri ka reboot a. Ka pangkalan kode Quay parobahan dijieun pikeun ngawatesan jumlah sambungan kana database pikeun tiap worker gevent. Jumlah ieu janten parameter dina konfigurasi: éta janten mungkin pikeun ngarobah éta dina laleur tanpa ngawangun gambar wadahna anyar. Pikeun milarian sabaraha sambungan anu tiasa diurus sacara réalistis, kami ngajalankeun sababaraha tés dina lingkungan pementasan, netepkeun nilai anu béda pikeun ningali kumaha ieu bakal mangaruhan skenario tés beban. Hasilna, kapanggih yén Quay mimiti ngalungkeun 502 kasalahan nalika jumlah sambungan ngaleuwihan 10 sarébu.
Urang langsung nyebarkeun versi anyar ieu pikeun produksi sareng mimiti ngawas jadwal sambungan database. Baheula, pangkalanna dikonci saatos sakitar 20 menit. Saatos 30 menit tanpa masalah kami ngagaduhan harepan, sareng sajam saatosna kami ngagaduhan kapercayaan. Urang malikkeun lalulintas ka loka sarta mimiti analisis postmortem.
Sanggeus junun jalan ngaliwatan masalah ngarah ka blocking, kami henteu acan mendakan alesan anu leres. Ieu dikonfirmasi yén éta teu patali jeung sagala parobahan dina OpenShift 4.3.19, saprak hal anu sarua kajadian dina versi 4.3.18, nu saméméhna gawé bareng Quay tanpa masalah.
Aya jelas hal sejenna lurking dina klaster.
Diajar lengkep
Quay.io nganggo setélan standar pikeun nyambung ka pangkalan data salami genep taun tanpa masalah. Naon robah? Ieu jelas yén sadaya waktos lalulintas on quay.io geus tumuwuh steadily. Dina hal urang, éta kasampak saolah-olah sababaraha nilai bangbarung geus ngahontal, nu dilayanan salaku pemicu pikeun longsoran sambungan. Urang terus diajar log database sanggeus gagal kadua, tapi teu manggihan pola atawa hubungan atra.
Samentawis waktos, tim SRE parantos ngusahakeun perbaikan pikeun observasi pamundut Quay sareng kasehatan jasa sadayana. Métrik sareng dasbor énggal parantos dipasang, némbongkeun bagian mana tina Quay nu paling di paménta ti konsumén.
Quay.io damel saé dugi ka 9 Juni. Isuk ieu (EDT) urang ningali deui kanaékan signifikan dina jumlah sambungan database. waktos ieu teu aya downtime, Kusabab parameter anyar ngawatesan jumlah maranéhanana sarta henteu ngidinan aranjeunna ngaleuwihan throughput MySQL. Sanajan kitu, salila kira satengah jam, loba pamaké nyatet kinerja slow quay.io. Kami gancang ngumpulkeun sadaya data anu mungkin nganggo alat ngawaskeun tambahan. Ujug-ujug muncul pola.
Saméméh surge dina sambungan, sajumlah badag requests dijieun ka App Registry API. App Registry mangrupikeun fitur anu teu dipikanyaho ku quay.io. Eta ngidinan Anjeun pikeun nyimpen hal kawas Helm grafik na wadah kalawan metadata euyeub. Seuseueurna pangguna quay.io henteu tiasa dianggo sareng fitur ieu, tapi Red Hat OpenShift aktip ngagunakeunana. OperatorHub salaku bagian tina OpenShift nyimpen sadaya operator dina App Registry. Operator ieu janten dasar pikeun ékosistem beban kerja OpenShift sareng modél operasi mitra-centric (operasi Day 2).
Unggal klaster OpenShift 4 nganggo operator ti OperatorHub anu diwangun pikeun nyebarkeun katalog operator anu sayogi pikeun dipasang sareng nyayogikeun apdet pikeun anu parantos dipasang. Kalayan popularitas OpenShift 4 anu ningkat, jumlah klaster di sakumna dunya ogé ningkat. Unggal klaster ieu ngaunduh eusi operator pikeun ngajalankeun OperatorHub anu diwangun, nganggo App Registry di jero quay.io salaku backend. Dina pilarian kami pikeun sumber masalah, urang sono kanyataan yén salaku OpenShift laun tumuwuh dina popularitas, beban dina salah sahiji fungsi quay.io jarang dipaké ogé ngaronjat..
Urang ngalakukeun sababaraha analisa lalu lintas pamundut App Registry sareng ningali kode pendaptaran. Langsung, shortcomings kaungkap, alatan queries ka database teu kabentuk optimal. Nalika bebanna rendah, aranjeunna henteu nyababkeun masalah, tapi nalika bebanna ningkat, aranjeunna janten sumber masalah. App Registry tétéla gaduh dua titik tungtung masalah anu henteu ngaréspon saé pikeun ningkatkeun beban: anu kahiji nyayogikeun daptar sadaya bungkusan dina gudang, anu kadua ngabalikeun sadaya gumpalan pikeun pakét.
Ngaleungitkeun sabab
Dina minggu hareup urang nyéépkeun optimalisasi kode tina App Registry sorangan sareng lingkunganana. queries SQL jelas teu epektip anu reworked sarta panggero paréntah teu perlu dileungitkeun tar (Ieu dijalankeun unggal waktos blobs dicandak), cache ieu ditambahkeun dimana wae mungkin. Urang teras ngalaksanakeun tés kinerja éksténsif sareng ngabandingkeun laju App Registry sateuacan sareng saatos parobihan.
Paménta API anu sateuacana nyandak dugi ka satengah menit ayeuna parantos réngsé dina milliseconds. Minggu hareup urang nyebarkeun parobihan kana produksi, sareng ti saprak éta quay.io parantos damel sacara stabil. Antukna, aya sababaraha spike seukeut dina lalulintas dina titik App Registry, tapi perbaikan dijieun nyegah outages database.
Naon anu urang diajar?
Éta jelas yén jasa naon waé nyobian ngahindari downtime. Dina kasus urang, urang yakin yén pareum panganyarna geus mantuan nyieun quay.io hadé. Kami parantos diajar sababaraha palajaran konci anu kami hoyong bagikeun:
- Data ngeunaan saha anu ngagunakeun jasa anjeun sareng kumaha henteuna langkung seueur. Kusabab Quay "karék digawé," urang pernah kungsi méakkeun waktu optimizing lalulintas sarta menata beban. Sadaya ieu nyiptakeun rasa aman palsu yén jasa éta tiasa skala salamina.
- Nalika jasa turun, Nyadangkeun sareng ngajalankeun éta mangrupikeun prioritas utama.. Kusabab Quay terus sangsara tina database dikonci salila outage munggaran, prosedur baku urang teu boga pangaruh dimaksudkeun sarta kami teu bisa mulangkeun jasa maké éta. Ieu nyababkeun kaayaan dimana waktos kedah dihabiskeun pikeun nganalisa sareng ngumpulkeun data kalayan ngarep-arep mendakan akar sababna - tibatan museurkeun sadaya usaha pikeun ngabalikeun deui fungsionalitas.
- Evaluate dampak unggal fitur jasa. Klién jarang nganggo App Registry, janten éta sanés prioritas pikeun tim kami. Nalika sababaraha fitur produk bieu dianggo, bug na jarang muncul, sareng pamekar ngeureunkeun ngawas kodeu. Gampang janten mangsa kasalahpahaman yén ieu mangrupikeun cara anu kedahna-dugi ujug-ujug fungsi éta janten pusat kajadian utama.
Naon saterusna?
Usaha pikeun mastikeun stabilitas jasa henteu pernah lirén sareng kami teras-terasan ningkatkeun éta. Nalika volume lalu lintas terus ningkat dina quay.io, kami sadar yén kami ngagaduhan tanggung jawab pikeun ngalakukeun sagala rupa anu kami tiasa pikeun ngalaksanakeun kapercayaan para nasabah. Ku alatan éta, urang ayeuna keur dipake dina tugas handap:
- Nyebarkeun réplika database anu dibaca wungkul pikeun ngabantosan palayanan nanganan lalu lintas anu pas upami aya masalah sareng conto RDS primér.
- Ngamutahirkeun hiji conto RDS. Versi ayeuna sorangan henteu masalah. Rada, urang ngan saukur hayang nyabut jalan satapak palsu (anu urang dituturkeun salila gagalna); Ngajaga parangkat lunak énggal-énggal bakal ngaleungitkeun faktor sanés upami aya gangguan ka hareup.
- Caching tambahan dina sakabéh klaster. Urang terus néangan wewengkon mana cache bisa ngurangan beban dina database.
- Nambahkeun firewall aplikasi wéb (WAF) pikeun ningali saha anu nyambung ka quay.io sareng kunaon.
- Dimimitian ku sékrési salajengna, klaster Red Hat OpenShift bakal ngantunkeun Pendaptaran Aplikasi pikeun milih Katalog Operator dumasar kana gambar wadah anu aya dina quay.io.
- Panggantian jangka panjang pikeun App Registry tiasa janten dukungan pikeun spésifikasi artefak Open Container Initiative (OCI). Éta ayeuna dilaksanakeun salaku fungsionalitas Quay asli sareng bakal sayogi pikeun pangguna nalika spésifikasina parantos réngsé.
Sadayana di luhur mangrupikeun bagian tina investasi Red Hat di quay.io nalika urang ngalih ti tim "gaya ngamimitian" leutik ka platform anu didorong ku SRE. Urang terang yen loba konsumén urang ngandelkeun quay.io dina karya poean maranéhanana (kaasup Red Hat!) Sarta kami nyoba jadi transparan sabisa ngeunaan outages panganyarna na usaha lumangsung pikeun ngaronjatkeun.
PS ti penerjemah
Baca ogé dina blog urang:
- «";
- «";
- «".
sumber: www.habr.com