Заўв. перав.: у пачатку жніўня Red Hat публічна распавяла аб рашэнні праблем даступнасці, што ўзнікалі ў папярэднія месяцы ў карыстальнікаў яе сэрвісу. (У яго аснове – рэестр для вобразаў кантэйнераў, які дастаўся кампаніі разам з пакупкай CoreOS). Незалежна ад вашай зацікаўленасці ў гэтым сэрвісе як такім, павучальны сам шлях, па якім прайшлі SRE-інжынеры кампаніі для дыягностыкі і ўхіленні чыннікаў аварыі.
19 траўня, раніцай (па летнім паўночнаамерыканскім усходнім часе, EDT), сэрвіс quay.io упаў. Аварыя закранула як спажыўцоў quay.io, так і Open Source-праекты, якія выкарыстоўваюць quay.io у якасці платформы для зборкі і распаўсюджванні ПЗ. Red Hat шануе давер як як адных, так і іншых.
Каманда SRE-інжынераў адразу падключылася да працы і пастаралася як мага хутчэй стабілізаваць працу сэрвісу Quay. Аднак пакуль яны гэтым займаліся, кліенты пазбавіліся магчымасці push'іць новыя вобразы, і толькі перыядычна ім атрымоўвалася pull'іць наяўныя. Па невядомым чынніку база дадзеных quay.io блакавалася пасля маштабавання сэрвісу на поўную магутнасць.
«Што змянілася?»- гэта першае пытанне, якое прынята задаваць у падобных выпадках. Мы заўважылі, што незадоўга да праблемы кластар OpenShift Dedicated (на якім працуе quay.io) пачаў абнаўляцца да версіі 4.3.19. Паколькі quay.io працуе на Red Hat OpenShift Dedicated (OSD), рэгулярныя абнаўленні былі штодзённай аперацыяй і ніколі не прыводзілі да праблем. Больш за тое, за папярэднія паўгода мы некалькі разоў абнаўлялі кластары Quay без якіх-небудзь перапынкаў у абслугоўванні.
Пакуль мы спрабавалі аднавіць працу сэрвісу, іншыя інжынеры пачалі рыхтаваць новы кластар OSD з папярэдняй версіяй ПЗ, каб у выпадку чаго разгарнуць усё на ім.
Аналіз першапрычын
Асноўным сімптомам збою была лавіна з дзясяткаў тысяч падлучэнняў да БД, з-за якой асобнік MySQL апынуўся фактычна недзеяздольным. Праз гэта было складана дыягнаставаць праблему. Мы ўстанавілі абмежаванне на максімальную колькасць падлучэнняў ад кліентаў, каб дапамагчы камандзе SRE ацаніць праблему. Ніякага незвычайнага трафіку да базы дадзеных не заўважылі: насамрэч, большасць запытаў былі на чытанне, а толькі нешматлікія – на запіс.
Мы таксама паспрабавалі выявіць патэрн у трафіку БД, які мог бы выклікаць гэтую лавіну. Аднак ніякіх заканамернасцяў у логах адшукаць не ўдалося. Чакаючы гатоўнасці новага кластара з OSD 4.3.18, мы працягвалі спробы запусціць pod'ы quay.io. Кожны раз, калі кластар выходзіў на поўную магутнасць, база дадзеных завісала. Гэта азначала, што было неабходна перазапусціць асобнік RDS у дадатак да ўсіх pod'ам quay.io.
Да вечара мы стабілізавалі сэрвіс у рэжыме read-only і адключылі максімум неістотных функцый (напрыклад, збор смецця ў прасторы імёнаў), каб зменшыць нагрузку на БД. Завісанні спыніліся, але прычына так і не была знойдзена. Новы кластар OSD быў готаў, і мы перанеслі сэрвіс, падлучылі трафік і працягнулі маніторынг.
Quay.io стабільна працаваў на новым OSD-кластары, таму мы вярнуліся да логаў базы дадзеных, але так і не змаглі выявіць карэляцыю, якая тлумачыць блакіроўкі. Інжынеры OpenShift працавалі сумесна з намі, спрабуючы зразумець, ці маглі змены ў Red Hat OpenShift 4.3.19 прывесці да праблем з Quay. Аднак нічога выявіць не ўдалося, а прайграць праблему ў лабараторных умовах не атрымалася.
Другі збой
28 траўня, незадоўга да поўдня па EDT, quay.io зноў зваліўся з тым жа сімптомам: функцыянаванне базы дадзеных блакавалася. І зноў мы кінулі ўсе сілы на расследаванне. Першым чынам трэба было аднавіць працу сэрвісу. Аднак гэтым разам перазагрузка RDS і перазапуск pod'аў quay.io ні да чаго не прывялі: чарговая лавіна падключэнняў захліснула базу. Але чаму?
Quay напісаны на Python, і кожны pod працуе як адзіны маналітны кантэйнер. У асяроддзі выканання кантэйнера адначасова выконваецца мноства раўналежных задач. Мы выкарыстоўваем бібліятэку gevent пад gunicorn для апрацоўкі вэб-запытаў. Калі ў Quay паступае запыт (праз наш уласны API, ці праз API Docker'а), яму прызначаецца gevent worker. Звычайна гэты worker павінен звязацца з базай даных. Пасля першага збою мы выявілі, што gevent worker'ы падлучаліся да базы дадзеных, выкарыстаючы налады па змаўчанні.
Улічваючы значны лік pod'ов Quay і тысячы якія паступаюць запытаў у секунду, вялікі лік падлучэнняў да базы дадзеных тэарэтычна магло перагрузіць асобнік MySQL. Дзякуючы маніторынгу было вядома, што Quay у сярэднім апрацоўвае 5 тыс. запытаў у секунду. Прыкладна такім жа была і колькасць падключэнняў да базы даных. 5 тыс. падлучэнняў з запасам ўкладваліся ў магчымасці нашага асобніка RDS (чаго нельга сказаць аб дзясятках тысяч). Па нейкай прычыне адбываліся нечаканыя ўсплёскі колькасці падключэнняў, аднак мы не заўважалі які-небудзь карэляцыі са ўваходнымі запытамі.
На гэты раз мы цвёрда вырашылі знайсці і ўхіліць крыніцу праблемы, а не абмежавацца перазагрузкай. У кодавую базу Quay былі ўнесены змены, якія лімітуюць колькасць падлучэнняў да БД для кожнага worker'а gevent. Гэты лік стаў параметрам у канфігурацыі: стала магчымым змяняць яго «на лёце», не збіраючы новую выяву кантэйнера. Каб даведацца, які лік падлучэнняў рэальна апрацаваць, было праведзена некалькі выпрабаванняў са staging-асяроддзем, у якіх задаваліся розныя значэнні, каб паглядзець, як гэта адаб'ецца на сцэнарах нагрузачнага тэставання. У выніку выявілася, што Quay пачынае выдаваць памылкі 502, калі колькасць падключэнняў перавышае 10 тыс.
Мы адразу разгарнулі гэтую новую версію ў production і сталі сачыць за графікам падлучэнняў да базы дадзеных. У мінулым база блакавалася прыкладна праз 20 хвілін. Праз 30 беспраблемных хвілін у нас з'явілася надзея, а праз гадзіну - упэўненасць. Мы аднавілі трафік на запіс на сайце і прыступілі да postmortem-аналізу.
Здолеўшы абыйсці праблему, якая прыводзіць да блакавання, мы не высветлілі яе сапраўдныя прычыны. Пацвердзілася, што яна не злучана з якімі-небудзь зменамі ў OpenShift 4.3.19, паколькі тое ж самае здарылася і на версіі 4.3.18, якая да гэтага працавала з Quay без якія-небудзь праблем.
У кластары відавочна хавалася нешта яшчэ.
Дэталёвае вывучэнне
Quay.io шэсць гадоў выкарыстоўваў налады па змаўчанні для падлучэння да БД без якіх-небудзь праблем. Што змянілася? Зразумела, што ўвесь гэты час трафік на quay.io няўхільна рос. У нашым выпадку ўсё выглядала так, нібы дасягалася нейкае парогавае значэнне, якое служыла трыгерам для лавіны падлучэнняў. Мы працягнулі вывучаць логі БД пасля другога збою, але не выявілі якія-небудзь заканамернасцяў або відавочных узаемасувязяў.
Тым часам каманда SRE займалася паляпшэннямі ў вобласці назіральнасці запытаў у Quay і агульнага здароўя сэрвісу. Былі разгорнуты новыя метрыкі і панэлі маніторынгу, Якія паказваюць, якія часткі Quay карыстаюцца найбольшым попытам з боку кліентаў.
Quay.io нармальна працаваў да 9 чэрвеня. Раніцай (па EDT) мы зноў сталі сведкамі значнага павелічэння колькасці падлучэнняў да базы дадзеных. На гэты раз прастою не здарылася, паколькі новы параметр абмяжоўваў іх колькасць і не дазваляў перавысіць прапускную здольнасць MySQL. Аднак прыкладна на працягу паўгадзіны шматлікія карыстачы адзначалі павольную працу quay.io. Мы хутка сабралі ўсе магчымыя дадзеныя, скарыстаўшыся дададзенымі прыладамі маніторынгу. Раптам выявілася заканамернасць.
Перад самым скокам ліку падлучэнняў вялікая колькасць запытаў паступіла на App Registry API. App Registry - гэта малавядомая функцыя quay.io. Яна дазваляе захоўваць такія штукі, як чарты Helm і кантэйнеры з багатымі (rich) метададзенымі. Большасьць карыстальнікаў quay.io не працуюць з гэтай функцыяй, аднак ёй актыўна карыстаецца Red Hat OpenShift. OperatorHub у складзе OpenShift захоўвае ўсе аператары ў App Registry. Гэтыя аператары фармуюць аснову для экасістэмы працоўных нагрузак OpenShift і аперацыйнай мадэлі (у рамках аперацый "другога дня", Day 2), арыентаванай на партнёраў.
Кожны кластар OpenShift 4 выкарыстоўвае аператары з убудаванага OperatorHub'а для публікацыі каталога аператараў, даступных для ўстаноўкі, і прадастаўлення абнаўленняў для ўжо ўсталяваных. З ростам папулярнасці OpenShift 4 павялічылася і колькасць кластараў на ім па ўсім свеце. Кожны з гэтых кластараў загружае змесціва аператараў, каб запусціць убудаваны OperatorHub, выкарыстоўваючы App Registry ўнутры quay.io як бэкэнд. У пошуках крыніцы праблемы мы выпусцілі тое, што з паступовым ростам папулярнасці OpenShift павялічвалася і нагрузка на адну з рэдка выкарыстоўваных функцый quay.io.
Мы правялі некаторы аналіз трафіку запытаў App Registry і зазірнулі ў код рэестра. Адразу ж выявіліся недахопы, з-за якіх запыты да базы дадзеных фармаваліся неаптымальна. Пры невялікай нагрузцы яны не прычынялі ніякіх клопатаў, аднак пры яе ўзрастанні станавіліся крыніцай праблем. У App Registry апынулася два праблемных endpoint'а, дрэнна якія рэагуюць на ўзрастанне нагрузкі: першы выдаваў спіс усіх пакетаў у рэпазітары, другі - вяртаў усе blob'ы для пакета.
Устараненне прычын
Увесь наступны тыдзень мы займаліся аптымізацыяй кода самога App Registry і яго асяроддзі. Былі перапрацаваны відавочна неэфектыўныя SQL-запыты, ухілены лішнія выклікі каманды tar (яна запускалася пры кожным выманні blob'ов), дададзена кэшаванне ўсюды, дзе магчыма. Затым было праведзена маштабнае тэсціраванне прадукцыйнасці і параўнаная хуткасць працы App Registry да і пасля змен.
Запыты API, якія раней займалі да паўхвіліны, зараз выконваліся за мілісекунды. На наступным тыдні мы разгарнулі змены ў production, і з таго часу quay.io працуе стабільна. За гэты час назіраліся некалькі рэзкіх усплёскаў трафіку на endpoint'е App Registry, але выкананыя ўдасканаленні прадухілілі перабоі ў працы базы дадзеных.
Чаму мы навучыліся?
Зразумела, што любы сэрвіс імкнецца пазбегнуць прастояў. У нашым выпадку мы верым, што нядаўнія збоі дапамаглі зрабіць quay.io лепей. Для сябе мы вынеслі некалькі асноўных урокаў, якімі жадаем падзяліцца:
- Дадзеныя аб тым, хто і як выкарыстоўвае ваш сэрвіс, не бываюць лішнімі.. Паколькі Quay проста працаваў , у нас ніколі не ўзнікала неабходнасць марнаваць час на аптымізацыю трафіку і кіраванне нагрузкай. Усё гэта стварыла ілжывае адчуванне бяспекі, што сэрвіс можа маштабавацца да бясконцасці.
- Калі сэрвіс падае, аднаўленне яго працы - галоўны прыярытэт. Паколькі Quay працягваў пакутаваць ад заблакаванай базы дадзеных падчас першага збою, нашыя стандартныя працэдуры не аказалі меркаванага эфекту і мы не змаглі аднавіць працу сэрвісу з іх дапамогай. Гэта прывяло да сітуацыі, калі прыйшлося марнаваць час на аналіз і збор дадзеных у надзеі знайсці першапрычыну - замест таго, каб накіраваць усе намаганні на аднаўленне працаздольнасці.
- Ацэньвайце ўплыў кожнай з функцый сэрвісу. Кліенты рэдка выкарыстоўвалі App Registry, таму ён не з'яўляўся прыярытэтным для нашай каманды. Калі некаторыя функцыі прадукта амаль не выкарыстоўваюцца, іх багі «усплываюць» рэдка, і распрацоўнікі перастаюць сачыць за кодам. Лёгка стаць ахвярай памылкі, што так і павінна быць - пакуль раптоўна гэтая функцыя не апыняецца ў цэнтры маштабнага інцыдэнту.
Што далей?
Праца па забеспячэнні стабільнасці сэрвісу ніколі не спыняецца і мы ўвесь час паляпшаем яго. Аб'ёмы трафіку на quay.io працягваюць расці, і мы ўсведамляем, што абавязаны рабіць усё магчымае, каб апраўдаць давер кліентаў. Таму зараз працуем над наступнымі задачамі:
- Разгортванне рэплік баз дадзеных толькі для чытання, каб дапамагчы сэрвісу апрацоўваць адпаведны трафік у выпадку ўзнікнення праблем з асноўным асобнікам RDS.
- Абнаўленне асобніка RDS. Бягучая версія сама па сабе не праблема. Хутчэй, мы проста жадаем прыбраць ілжывы след (па якім пайшлі падчас збою); падтрыманне ПЗ у актуальным стане дазволіць ухіліць яшчэ адзін фактар на выпадак будучых адключэнняў.
- Дадатковае кэшаванне па ўсім кластары. Мы працягваем пошук абласцей, у якіх кэшаванне дазволіць знізіць нагрузку на базу дадзеных.
- Даданне firewall'а вэб-прыкладанняў (WAF), каб бачыць, хто і чаму падключаецца да quay.io.
- Пачынальна з наступнага рэлізу, кластары Red Hat OpenShift адмовяцца ад App Registry у карысць каталогаў аператараў (Operator Catalogs), якія базуюцца на выявах кантэйнераў, даступных на quay.io.
- Доўгатэрміновай заменай App Registry можа стаць падтрымка спецыфікацый артэфактаў Open Container Initiative (OCI). У наш час яна рэалізуецца ў выглядзе роднага функцыяналу Quay і будзе даступная для карыстачоў, калі саму спецыфікацыю канчаткова ўзгодняць.
Усё вышэйпералічанае з'яўляецца часткай якія працягваюцца інвестыцый Red Hat у quay.io па меры таго, як мы пераходзім ад невялікай каманды у духу стартапа да спелай платформы, кіраванай SRE. Мы ведаем, што многія нашы кліенты належаць на quay.io у сваёй паўсядзённай працы (уключаючы Red Hat!) і імкнемся быць максімальна адчыненымі ў стаўленні нядаўніх збояў і якія працягваюцца намаганняў стаць лепш.
PS ад перакладчыка
Чытайце таксама ў нашым блогу:
- «»;
- «»;
- «.
Крыніца: habr.com