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