Салам, Хабр! Биз акыркы эки айдан бери абдан кызыктуу кырдаалда жашап жатабыз жана мен инфраструктураны масштабдоо тарыхыбыз менен бөлүшкүм келет. Бул убакыттын ичинде СберМаркет 4 эсеге көбөйүп, 17 жаңы шаарда кызматты ишке киргизди. Азык-түлүк жеткирүүгө болгон суроо-талаптын кескин өсүшү бизден инфраструктураны кеңейтүүнү талап кылды. Кесилген астындагы эң кызыктуу жана пайдалуу корутундуларды окуңуз.
Менин атым Дима Бобылев, мен СберМаркеттин техникалык директорумун. Бул биздин блогдогу биринчи билдирүү болгондуктан, мен өзүм жана компания жөнүндө бир нече сөз айта кетейин. Былтыр күзүндө жаш рунет лидерлеринин конкурсуна катыштым. Конкурска И СберМаркетте биз ички маданиятты жана кызматты өнүктүрүүгө болгон мамилени кандай көрүп жаткандыгыбыз жөнүндө. Сынакта жеңе албасам да, мен өзүм үчүн IT экосистемасынын өнүгүүсүнүн негизги принциптерин иштеп чыктым.
Команданы башкарууда бизнеске эмне керек жана ар бир иштеп чыгуучунун муктаждыктары ортосундагы балансты түшүнүү жана табуу маанилүү. Азыр SberMarket жылдан-жылга 13 эсе өсүп жатат, бул өнүмдүн көлөмүн жана өнүгүү темпин тынымсыз жогорулатууну талап кылган продуктка таасирин тийгизет. Буга карабастан, биз иштеп чыгуучуларга алдын ала талдоо жана сапаттуу коддоо үчүн жетиштүү убакыт бөлөбүз. Түзүлгөн ыкма жумушчу продуктуну түзүүгө гана жардам бербестен, аны андан ары кеңейтүүгө жана өнүктүрүүгө жардам берет. Мындай өсүштүн натыйжасында SberMarket азык-түлүк жеткирүү кызматтарынын арасында лидер болуп калды: биз күнүнө 18 миңге жакын буйрутмаларды жеткиребиз, бирок февралдын башында 3500гө жакын.
Күндөрдүн биринде кардар СберМаркеттин курьеринен азык-түлүктү балконго тийбей жеткирүүнү суранган.
Бирок, келгиле, конкреттүүлөргө өтөлү. Акыркы бир нече айдын ичинде биз компаниябыздын инфраструктурасын жигердүү кеңейтип жатабыз. Бул муктаждык тышкы жана ички факторлор менен түшүндүрүлгөн. Кардар базасынын кеңейиши менен бирге, туташкан дүкөндөрдүн саны жыл башындагы 90дон май айынын ортосуна чейин 200дөн ашты. Биз, албетте, даярдандык, негизги инфраструктураны сактадык, ошондой эле Яндекс булутунда жайгашкан бардык виртуалдык машиналарды вертикалдуу жана горизонталдуу масштабдоо мүмкүнчүлүгүнө ишендик. Бирок, практика көрсөткөндөй: «Жамандыктын баары туура эмес болот». Бүгүн мен ушул жумаларда болгон эң кызыктуу кырдаалдар менен бөлүшкүм келет. Биздин тажрыйба сизге пайдалуу болот деп ишенем.
Кул согушка толук даяр
Пандемия башталганга чейин эле биз серверлерибизге суроо-талаптардын көбөйүшүнө туш болдук. Үйгө жеткирүү үчүн азык-түлүккө буйрутма берүү тенденциясы күч ала баштады жана COVID-19дан улам биринчи өзүн-өзү изоляциялоо чараларын киргизүү менен жумуштун жүгү күн бою кескин өстү. Негизги маалымат базасынын башкы серверлерин тез арада түшүрүү жана окуу сурамдарынын бир бөлүгүн реплика серверлерине (кул) өткөрүп берүү зарылчылыгы келип чыкты.
Биз бул кадамга алдын ала даярдандык жана мындай маневр үчүн 2 кул сервери ишке киргизилген. Алар, негизинен, өнөктөштөр менен маалымат алмашуу үчүн маалыматтык ленталарды түзүү боюнча пакеттик тапшырмалар үчүн колдонулган. Бул процесстер кошумча жүктү жаратып, бир-эки ай мурун теңдемеден туура чыгарылган.
Репликация Кулда болгондуктан, биз тиркемелер алар менен окуу гана режиминде гана иштей алат деген түшүнүктү кармандык. Кырсыкты калыбына келтирүү планы кырсык болгон учурда биз Кулду Кожоюндун ордуна жөн эле орнотуп, бардык жазуу жана окуу өтүнүчтөрүн Кулга которсок болот деп болжолдогон. Бирок, биз ошондой эле репликаларды аналитика бөлүмүнүн муктаждыктары үчүн колдонгубуз келди, андыктан серверлер окуу үчүн гана статуска толугу менен которулган жок, бирок ар бир хосттун өзүнүн колдонуучуларынын топтому бар, ал эми кээ бирлеринин ортодогу эсептөө натыйжаларын сактоо үчүн жазуу укуктары бар.
Белгилүү бир жүктөө деңгээлине чейин бизде http суроо-талаптарын иштеп чыгууда жазуу жана окуу үчүн жетиштүү мастер болгон. Март айынын орто ченинде, Sbermarket толугу менен аралыктан иштөөгө өтүүнү чечкенде, биздин RPS экспоненциалдуу өсө баштады. Биздин көбүрөөк кардарларыбыз өзүнчө обочолонуп же үйдөн иштешти, бул биздин иш жүктөмүнүн көрсөткүчтөрүнө таасирин тийгизди.
"Кожоюндун" аткаруусу жетишсиз болуп калды, ошондуктан биз эң оор окуу сурамдарын репликага өткөрүп баштадык. Кожоюнга жазуу өтүнүчтөрүн ачык-айкын багыттоо жана кулга суроо-талаптарды окуу үчүн, биз рубин асыл ташын колдондук "" Биз жазуу укугу жок _readonly постфикси менен атайын колдонуучуну түздүк. Бирок хосттордун биринин конфигурациясындагы катадан улам, жазуу өтүнүчтөрүнүн айрымдары тиешелүү укуктарга ээ болгон колдонуучунун атынан кул серверине өтүп кеткен.
Маселе дароо эле көрүнгөн жок, анткени... жогорулатылган жүк кулдардын артта калышын жогорулатты. Маалыматтардын дал келбестиги эртең менен түнкү импорттон кийин кулдар кожоюнду «кууп жетпегенде» аныкталган. Биз муну жаңы дүкөндөрдүн ишке киришине байланыштуу кызматтын өзүнө жана импортко жүктөмдүн көптүгү менен байланыштырдык. Бирок маалыматтарды көп сааттык кечигүү менен жөнөтүү алгылыксыз болгон жана биз процесстерди экинчи аналитикалык кулга котордук, анткени аныночоңураак ресурстар жана окуу сурамдары жүктөлгөн эмес (биз репликациянын артта калуусунун жоктугун өзүбүзгө ушундайча түшүндүрдүк).
Негизги кулдун «жайылышынын» себептерин тапканыбызда, аналитикалык дагы ошол эле себеп менен ишке ашпай калган. Кошумча эки сервердин бар экендигине карабастан, биз мастер иштен чыккан учурда жүктү өткөрүп берүүнү пландаштырганбыз, өкүнүчтүү катадан улам, критикалык учурда алардын бири да жок болуп чыкты.
Бирок биз маалымат базасын гана таштабастан (ал кездеги калыбына келтирүү 5 саатка жакын убакытты талап кылган), ошондой эле башкы сервердин сүрөтүн тартып алгандыктан, репликаны 2 сааттын ичинде ишке киргизе алдык. Ырас, ушундан кийин биз репликация журналынын узак убакытка айланып кетишине туш болдук (анткени процесс бир жиптүү режимде жүрөт, бирок бул такыр башка окуя).
корутундусу: Мындай окуядан кийин колдонуучулар үчүн жазууну чектөө практикасынан баш тартып, бүт серверди окуу үчүн гана жарыялоо керек экени белгилүү болду. Мындай ыкма менен репликалар оор учурларда жеткиликтүү болорунда шек жок.
Бир эле оор суроону оптималдаштыруу маалымат базасын кайра жандандырышы мүмкүн
Сайттагы каталогду дайыма жаңыртып турсак да, Кул серверлерине жөнөткөн суроо-талаптар Мастерден бир аз артта калууга жол берди. Биз кулдардын "капыстан аралыкты таштап кетүү" көйгөйүн таап, жок кылган убакыт "психологиялык тоскоолдуктан" көп болгон (бул убакыттын ичинде баалар жаңыланып, кардарлар эскирген маалыматтарды көрүшмөк) жана биз аргасыз болдук. бардык суроо-талаптарды негизги база серверине которуу. Натыйжада, сайт жай эле ... бирок, жок дегенде, ал иштеген. Ал эми Кул айыгып жатканда, оптималдаштыруудан башка аргабыз жок болчу.
Slave серверлери калыбына келтирилип жатканда, мүнөттөр акырындап өтүп, Мастер ашыкча жүктөлгөн бойдон кала берди жана биз "Парето эрежеси" боюнча активдүү тапшырмаларды оптималдаштырууга бардык күчүбүздү жумшадык: биз жүктөмдүн көпчүлүк бөлүгүн түзгөн ТОП сурамдарды тандап, жөндөп баштадык. . Бул түздөн-түз учуп жасалган.
Кызыктуу эффект, кубаттуулукка чейин жүктөлгөн MySQL процесстердин бир аз жакшырышына да жооп берген. Жалпы жүктөмдүн 5% гана түзгөн бир нече суроону оптималдаштыруу процессордун байкаларлык жүгүн көрсөттү. Натыйжада, биз Мастерге маалымат базасы менен иштөө үчүн алгылыктуу ресурстарды камсыздай алдык жана репликаларды калыбына келтирүүгө керектүү убакытты ала алдык.
корутундусу: Ал тургай, кичинекей оптималдаштыруу бир нече саат бою ашыкча жүктөм астында "аман калууга" мүмкүндүк берет. Бул серверлерди репликалар менен калыбына келтирүү үчүн жетиштүү болду. Айтмакчы, биз төмөнкү посттордун биринде суроо-талаптарды оптималдаштыруунун техникалык жагын талкуулайбыз. Андыктан, эгер сиз үчүн пайдалуу болсо, биздин блогго жазылыңыз.
Өнөктөш кызматтардын аткарылышына мониторингди уюштуруу
Биз кардарлардын буйрутмаларын иштетебиз, ошондуктан биздин кызматтар үчүнчү тараптын API'лери менен тынымсыз иштешет - бул SMS жөнөтүү үчүн шлюздар, төлөм платформалары, маршруттук системалар, геокодер, Федералдык салык кызматы жана башка көптөгөн системалар. Жана жүк тездик менен өсө баштаганда, биз өнөктөш кызматтарыбыздын API чектөөлөрүнө туш боло баштадык, бул жөнүндө биз мурда ойлобогонбуз.
Өнөктөш кызматтардын квоталарынан күтүүсүз ашып кетүү сиздин өзүңүздүн иштебей калууңузга алып келиши мүмкүн. Көптөгөн API'лер чектен ашкан кардарларды бөгөттөйт жана кээ бир учурларда өтө көп суроо-талаптар өнөктөштүн өндүрүшүн ашыкча жүктөшү мүмкүн.
Мисалы, жеткирүүлөрдүн саны өскөндө, коштоп жүрүүчү кызматтар аларды бөлүштүрүү жана каттамдарды аныктоо милдеттерин аткара алган жок. Жыйынтыгында буйрутмалар берилип, бирок маршрутту түзгөн сервис иштебей калганы белгилүү болду. Бул шарттарда биздин логисттердин дээрлик мүмкүн эмес экенин айтышыбыз керек, жана команданын так өз ара аракеттенүү убактылуу кызмат кемчиликтердин ордун толтурууга жардам берди. Бирок мындай көлөмдөгү буйруктарды дайыма кол менен иштеп чыгуу реалдуу эмес жана бир нече убакыт өткөндөн кийин биз буйруктар менен алардын аткарылышынын ортосунда жол берилгис ажырымга туш болобуз.
Биз жаңы шарттарды макулдашып, айрым өнөктөштөрдөн кызмат көрсөтүүлөрдү модернизациялоону күтүп жаткан учурда бир катар уюштуруу чаралары көрүлүп, команданын жакшы координацияланган иши убакытты утууга жардам берди. Трафик көп болгон учурда жогорку чыдамкайлык менен мактанган башка API'лер бар. Мисалы, башында биз жеткирүү түйүнүнүн дарегин аныктоо үчүн бир белгилүү карта API колдондук. Бирок айдын аягында биз дээрлик 2 миллион рублга тыкан эсеп алдык. Ушундан кийин, алар тез арада аны алмаштырууну чечишти. Мен жарнама менен алектенбейм, бирок биздин чыгашаларыбыз бир топ азайды деп айтам.
корутундусу: Бардык өнөктөш кызматтардын иштөө шарттарына мониторинг жүргүзүү жана аларды эске алуу зарыл. Бүгүнкү күндө алар сиз үчүн "чоң маржа менен" болуп көрүнсө да, бул эртең алар өсүүгө тоскоол болбойт дегенди билдирбейт. Анан, албетте, алдын ала кызмат үчүн көбөйгөн суроо-талаптардын каржылык шарттарын макулдашуу жакшы.
Кээде ушундай болуп калат""(c) жардам бербейт
Биз негизги маалымат базасында же тиркеме серверлеринде “капка” көнүп калганбыз, бирок масштабдашканда көйгөйлөр күтүлбөгөн жерден пайда болушу мүмкүн.Сайтта толук текстти издөө үчүн биз Apache Solr кыймылдаткычын колдонобуз. Жүктөө көбөйгөн сайын, биз жооп берүү убактысынын азайгандыгын белгиледик, ал эми сервердик процессордун жүгү 100% га жетти. Эмне жөнөкөй болушу мүмкүн - келгиле, Solr менен контейнерге көбүрөөк ресурстар берели.
Күтүлгөн өндүрүмдүүлүктүн жогорулашынын ордуна сервер жөн эле "өлдү". Ал дароо 100% жүктөлүп, андан да жайыраак жооп берди. Башында бизде 2 өзөк жана 2 ГБ оперативдүү эс тутум бар болчу. Биз адатта жардам берген нерсени жасоону чечтик - серверге 8 ядро жана 32 ГБ бердик. Баары ого бетер начарлап кетти (биз сизге кантип жана эмне үчүн өзүнчө постто так айтып беребиз).
Бир нече күндүн ичинде биз бул маселенин татаал жактарын түшүндүк жана 8 ядро жана 32 ГБ менен оптималдуу көрсөткүчтөргө жетиштик. Бул конфигурация бүгүнкү күндө жүктөмдү көбөйтүүнү улантууга мүмкүндүк берет, бул абдан маанилүү, анткени өсүү кардарларда гана эмес, ошондой эле туташкан дүкөндөрдүн санында - 2 айдын ичинде алардын саны эки эсеге өстү.
корутундусу: "Көбүрөөк темир кошуу" сыяктуу стандарттуу ыкмалар дайыма эле иштей бербейт. Ошентип, кандайдыр бир кызматтын масштабын кеңейтүүдө сиз анын ресурстарды кантип колдоноорун жакшы түшүнүп, жаңы шарттарда анын иштешин алдын ала текшерип турушуңуз керек.
Жарандыгы жок - бул оңой горизонталдуу масштабдын ачкычы
Жалпысынан алганда, биздин команда белгилүү ыкманы карманат: кызматтардын ички абалы (жарандыгы жок) болбошу керек жана аткаруу чөйрөсүнөн көз карандысыз болушу керек. Бул жөн эле горизонталдуу масштабда жүктүн өсүшү менен күрөшүүгө мүмкүндүк берди. Бирок бизде бир өзгөчө кызмат бар болчу - узак фондо тапшырмалар үчүн иштетүүчү. Ал электрондук почта жана смс жөнөтүү, окуяларды иштетүү, каналдарды түзүү, бааларды жана акцияларды импорттоо жана сүрөттөрдү иштетүү менен алектенген. Ошентип, ал жергиликтүү файл сактагычка көз каранды жана бир нускада болгон.
Процессордун кезектериндеги тапшырмалардын саны көбөйгөндө (жана бул табигый түрдө заказдардын санынын көбөйүшү менен болгон), процессор жана файл сактагычы жайгашкан хосттун иштеши чектөөчү фактор болуп калды. Натыйжада, ассортиментти жана бааларды жаңылоо, колдонуучуларга эскертмелерди жөнөтүү жана кезекте турган башка көптөгөн маанилүү функциялар токтоду. Ops командасы файл сактагычын S3 сымал тармак сактагычына тез көчүрдү жана бул бизге фондо тапшырма процессорун масштабдоо үчүн бир нече күчтүү машиналарды көтөрүүгө мүмкүнчүлүк берди.
корутундусу: Жарандыгы жок эреже бардык компоненттер үчүн сакталышы керек, ал тургай, "биз бул жерде сөзсүз туруштук бере албайбыз" деп көрүнсө дагы. Кодду шашылыш кайра жазып, ашыкча жүктөлгөн кызматты оңдоодон көрө, бардык системалардын иштешин туура уюштурууга бир аз убакыт короткон жакшы.
Интенсивдүү өсүш үчүн 7 принцип
Кошумча кубаттуулуктар болгонуна карабастан, биз өсүү процессинде бир нече катачылыктарга жол алдык. Бул убакыттын ичинде заказдардын саны 4 эседен ашык осту. Азыр биз 17 шаарда күнүнө 000 62ден ашык буйрутмаларды жеткирип жатабыз жана географияны мындан да кеңейтүүнү пландап жатабыз - 2020-жылдын биринчи жарымында кызмат бүткүл Россияда ишке киргизилиши күтүлүүдө. Өсүп жаткан жумуш жүгүн көтөрүү үчүн, ансыз деле толук конустарыбызды эске алуу менен, биз туруктуу өсүү шарттарында иштөө үчүн 7 негизги принциптерди иштеп чыктык:
- Окуяларды башкаруу. Жирада такта түздүк, анда ар бир окуя билет түрүндө чагылдырылат. Бул иш жүзүндө приоритеттүү болууга жана окуяга байланыштуу милдеттерди аткарууга жардам берет. Анткени, негизи ката кетирүү коркунучтуу эмес, бирок бир эле учурда эки жолу ката кетирүү коркунучтуу. Себептерин оңдоого чейин инциденттер кайталанган учурларда, иш-аракеттер боюнча көрсөтмөлөр даяр болушу керек, анткени оор жүктөө учурунда чагылгандын ылдамдыгы менен реакция кылуу маанилүү.
- Мониторинг инфраструктуранын бардык элементтери үчүн зарыл. Анын аркасында биз жүктөмдүн өсүшүн алдын ала айта алдык жана жоюуга артыкчылык берүү үчүн “тоскоолдуктарды” туура тандай алдык. Кыязы, чоң жүктүн астында сиз эч качан ойлобогон нерселердин баары бузулат же жайлай баштайт. Ошондуктан, биринчи инциденттер пайда болгондон кийин, аларды көзөмөлдөө жана алдын ала билүү үчүн жаңы эскертүүлөрдү түзүү эң жакшы.
- Туура эскертүүлөр жөн гана жүк кескин көбөйгөндө зарыл. Биринчиден, алар так эмне бузулганын билдириши керек. Экинчиден, эскертүүлөр көп болбошу керек, анткени критикалык эмес эскертүүлөрдүн көптүгү бардык эскертүүлөрдү таптакыр этибар албай коюуга алып келет.
- Тиркемелер жарандыгы жок болушу керек. Бул эрежеден эч кандай четтөөлөр болбошу керек деп ишенебиз. Бизге иштөө чөйрөсүнөн толук көз карандысыздык керек. Бул үчүн, сиз бөлүшүлгөн маалыматтарды маалымат базасында же, мисалы, S3 түз сактай аласыз. Дагы жакшы, эрежелерди сактаңыз.. Убакыттын кескин өсүшү учурунда кодду оптималдаштыруунун эч кандай жолу жок жана сиз эсептөө ресурстарын жана горизонталдык масштабды түз көбөйтүү менен жүктү көтөрүүгө туура келет.
- Квота жана тышкы кызматтарды аткаруу. Тез өсүү менен инфраструктураңызда гана эмес, тышкы кызматта да көйгөй жаралышы мүмкүн. Эң тажаткан нерсе, бул ийгиликсиздиктен эмес, квоталарга же чектерге жеткендиктен келип чыгат. Демек, тышкы кызматтар сиздей масштабдуу болушу керек.
- Бөлүнгөн процесстер жана кезектер. Бул шлюздардын биринде блокада болгондо көп жардам берет. Эгерде толук SMS жөнөтүү кезеги маалыматтык системалардын ортосунда билдирүүлөрдү алмашууга тоскоол болбосо, биз маалыматтарды өткөрүүдө кечигип калмакпыз. Ал эми жумушчулар өзүнчө иштесе, алардын санын көбөйтүү оңой болмок.
- Финансылык чындыктар. Маалымат агымынын кескин өсүшү болгондо, тарифтер жана жазылуулар жөнүндө ойлонууга убакыт жок. Бирок, аларды эстеп калуу керек, айрыкча, сиз кичинекей компания болсоңуз. Ар кандай API ээси, ошондой эле сиздин хостинг провайдериңиз чоң эсепти талап кылышы мүмкүн. Андыктан келишимдерди кунт коюп окуп чыгышыңыз керек.
жыйынтыктоо
Жоготуулар жок эмес, бирок биз бул этаптан аман калдык жана бүгүн биз табылган бардык принциптерди карманууга аракет кылабыз жана ар бир машина күтүлбөгөн окуяларга туруштук берүү үчүн x4 өндүрүмдүүлүгүн жонокой жогорулатуу мүмкүнчүлүгүнө ээ.
Төмөнкү посттордо биз Apache Solr программасынын иштешинин начарлашын иликтөө боюнча тажрыйбабыз менен бөлүшөбүз, ошондой эле сурамдарды оптималдаштыруу жана Федералдык Салык кызматы менен өз ара аракеттенүү компанияга акчаны үнөмдөөгө кандайча жардам берери жөнүндө сүйлөшөбүз. Эч нерсени өткөрүп жибербөө үчүн биздин блогго жазылыңыз жана трафиктин өсүшү учурунда ушундай кыйынчылыктарга туш болгон болсоңуз, комментарийлерде бизге айтыңыз.
Сурамжылоого катталган колдонуучулар гана катыша алышат. , өтүнөмүн.
Төмөнкүлөргө байланыштуу жүктөмдүн кескин көбөйүшүнө байланыштуу кызмат көрсөтүүнүн басаңдашы/төмөндөшүнө туш болдуңуз беле:
-
55,6%Эсептөө ресурстарын тез кошууга жөндөмсүз10
-
16,7%Хостинг провайдеринин инфраструктурасынын чектөөлөрү3
-
33,3%Үчүнчү тараптын API'леринин чектери6
-
27,8%Алардын кайрылууларынын жарандыгы жок принциптеринин бузулушу5
-
88,9%Өздүк кызматтардын оптималдуу эмес коду16
18 колдонуучу добуш берди. 6 колдонуучу добуш берүүдөн баш тартты.
Source: www.habr.com