Жазда сатып алу белсенділігі де, веб-жобалардың инфрақұрылымындағы өзгерістердің қарқындылығы да дәстүрлі түрде төмендейді, дейді капитан Обвиус. Өйткені IT мамандары да кейде демалысқа шығады. Және де CTO. Қызметте қалатындар үшін бұл қиынырақ, бірақ бұл енді маңызды емес: мүмкін, сондықтан жаз бар брондау схемасы туралы баяу ойлануға және оны жақсарту жоспарын құруға ең жақсы кезең. Егор Андреевтің тәжірибесі , бұл туралы ол конференцияда айтты .
Сақтық көшірме сайттарын құру кезінде сіз бірнеше қателіктерге тап болуыңыз мүмкін. Ал оларға ілініп кету мүлде мүмкін емес. Ал мұның бәрінде бізді құртатын нәрсе, басқа да көптеген нәрселер сияқты, перфекционизм мен ... жалқаулық. Біз бәрін, бәрін, барлығын мінсіз орындауға тырысамыз, бірақ оны мінсіз орындаудың қажеті жоқ! Сізге тек белгілі бір әрекеттерді орындау керек, бірақ оларды дұрыс орындаңыз, дұрыс жұмыс істеуі үшін аяқтаңыз.
Құтқару - бұл қандай да бір қызықты, көңілді нәрсе емес; Бұл дәл бір нәрсені істеуі керек нәрсе - қызмет, компания аз ақша жоғалту үшін бос уақытты қысқарту. Барлық брондау әдістерінде мен келесі контекстте ойлануды ұсынамын: ақша қайда?
Бірінші тұзақ: біз үлкен, сенімді жүйелерді құрастырған кезде және резервтеумен айналысқанда, біз жазатайым оқиғалардың санын азайтамыз. Бұл қорқынышты қате түсінік. Қысқартумен айналысқанда, біз жазатайым оқиғалардың санын көбейтуіміз мүмкін. Ал егер біз бәрін дұрыс жасасақ, онда ұжымдық түрде тоқтап қалу уақытын азайтамыз. Көбірек жазатайым оқиғалар болады, бірақ олар аз шығындармен болады. Брондау дегеніміз не? - бұл жүйенің күрделілігі. Кез келген асқыну жаман: бізде көп тістер, көп берілістер, бір сөзбен айтқанда элементтер көп - демек, бұзылу мүмкіндігі жоғары. Және олар шынымен бұзылады. Және олар жиі бұзылады. Қарапайым мысал: бізде PHP және MySQL бар веб-сайт бар делік. Және оны тез арада резервтеу керек.
Shtosh (c) Біз екінші сайтты аламыз, бірдей жүйені құрастырамыз... Күрделілік екі есе артады - бізде екі нысан бар. Біз сондай-ақ деректерді бір сайттан екіншісіне тасымалдаудың белгілі бір логикасын шығарамыз - яғни деректерді репликациялау, статикалық деректерді көшіру және т.б. Сонымен, репликация логикасы әдетте өте күрделі, сондықтан жүйенің жалпы күрделілігі 2 емес, 3, 5, 10 есе көп болуы мүмкін.
Екінші тұзақ: біз шынымен үлкен күрделі жүйелерді құрастырған кезде, біз соңында не алғымыз келетіні туралы қиялдаймыз. Voila: біз тоқтаусыз жұмыс істейтін, жарты секундта (немесе жақсырақ, бірден) ауысатын өте сенімді жүйені алғымыз келеді және біз армандарды орындай бастаймыз. Бірақ мұнда да бір нюанс бар: қажетті ауысу уақыты неғұрлым қысқа болса, жүйе логикасы соғұрлым күрделі болады. Бұл логиканы неғұрлым күрделі етіп жасауымыз керек болса, жүйе соғұрлым жиі бұзылады. Және сіз өте жағымсыз жағдайға тап болуыңыз мүмкін: біз тоқтау уақытын қысқартуға бар күшімізді салып жатырмыз, бірақ іс жүзінде біз бәрін қиындатып жатырмыз, ал бірдеңе дұрыс болмаса, тоқтау уақыты ұзағырақ болады. Бұл жерде сіз өзіңізді жиі ойлайсыз: жақсы... брондау жасамағаныңыз дұрыс болар еді. Ол жалғыз және түсінікті үзіліспен жұмыс істесе жақсы болар еді.
Мұнымен қалай күресуге болады? Біз өзімізге өтірік айтуды доғаруымыз керек, қазір біз ғарыш кемесін жасаймыз деп мақтануды доғарамыз, бірақ жобаның қаншалықты жалған болатынын дұрыс түсінуіміз керек. Осы максималды уақыт ішінде біз жүйеміздің сенімділігін арттыру үшін қандай әдістерді қолданатынымызды таңдаймыз.
Әрине, өмірден алынған «әңгімелер» уақыты келді.
Бірінші нөмірлі мысал
Н қаласындағы №1 құбыр прокат зауытының визиткалық сайтын елестетіп көріңізші, онда үлкен әріптермен жазылған – №1 ҚҰБЫРПРОКТАУ ЗАВОТЫ. Дәл төменде мынадай ұран бар: «Біздің құбырлар - N-дегі ең дөңгелек құбырлар». Ал төменде бас директордың телефон нөмірі мен оның аты-жөні берілген. Біз сізге брондау қажет екенін түсінеміз - бұл өте маңызды нәрсе! Оның неден тұратынын анықтауға кірісейік. Html-статика - бұл бас менеджер, шын мәнінде, серіктесімен моншадағы үстелде келесі мәміленің қандай да бір түрін талқылап жатқан бірнеше сурет. Біз бос уақыт туралы ойлай бастаймыз. Ойға келеді: бес минут жату керек, артық емес. Сонда сұрақ туындайды: жалпы біздің сайттан қанша сатылым болды? Қанша - қанша? «Нөл» нені білдіреді? Бұл дегеніміз: генерал өткен жылы төрт мәміленің барлығын бір үстел басында, олар моншаға баратын және үстел басында отырған адамдармен жасаған. Сайт бір күн отырса да, қорқынышты ештеңе болмайтынын түсінеміз.
Кіріспе ақпаратқа сүйене отырып, бұл оқиғаны көтеру күні бар. Қысқарту схемасы туралы ойлануды бастайық. Және біз бұл мысал үшін ең идеалды артық схеманы таңдаймыз: біз артықшылықты қолданбаймыз. Осының бәрін кез келген админ жарты сағатта түтін үзілістерімен көтере алады. Веб-серверді орнатыңыз, файлдарды қосыңыз - дәл солай. Ол жұмыс істейді. Еш нәрсені бақылап отырудың қажеті жоқ, ештеңеге ерекше назар аударудың қажеті жоқ. Яғни, №XNUMX мысалдан қорытынды анық: брондау қажет емес қызметтерді резервтеу қажет емес.
Екінші нөмірлі мысал
Компания блогы: арнайы дайындалған адамдар сонда жаңалықтар жазады, анау-мынау көрмеге қатыстық, бірақ тағы бір жаңа өнім шығардық, т.б. Бұл WordPress бар стандартты PHP, шағын дерекқор және аздап статикалық делік. Әрине, сіз ешбір жағдайда жатпауыңыз керек деген ойға оралады - «бес минуттан артық емес!» Міне, осы. Бірақ ары қарай ойланайық. Бұл блог не істейді? Адамдар ол жерге Яндекстен, Google-дан кейбір сұрауларға негізделген, органикалық түрде келеді. Тамаша. Сатудың бұған қатысы бар ма? Epiphany: шынымен емес. Жарнамалық трафик басқа машинада орналасқан негізгі сайтқа өтеді. Брондау схемасы туралы ойлануды бастайық. Жақсы мағынада, оны бір-екі сағатта көтеру керек, оған дайындалу жақсы болар еді. Басқа деректер орталығынан құрылғыны алып, оған қоршаған ортаны, яғни веб-серверді, PHP, WordPress, MySQL-ді айналдырып, оны сол жерде қалдыру орынды болар еді. Біз бәрі бұзылғанын түсінген кезде, біз екі нәрсені істеуіміз керек - mysql қоқысын 50 метрге шығарыңыз, ол бір минуттан кейін сонда ұшады және сол жерде сақтық көшірмеден белгілі бір суреттерді шығарыңыз. Бұл да жоқ, Құдай біледі қанша уақытқа дейін. Осылайша жарты сағатта бәрі көтеріледі. Көшіру жоқ немесе Құдай кешірсін, автоматты түрде істен шығу. Қорытынды: сақтық көшірмеден тез шығара алатын нәрсенің сақтық көшірмесін жасаудың қажеті жоқ.
Үшінші мысал, күрделірек
Интернет дүкен. Жүрегі ашық PhP сәл өзгертілген, берік негізі бар MySQL. Өте көп статикалық (интернет-дүкенде әдемі HD кескіндері және осының бәрі бар), сеанс үшін Redis және іздеу үшін Elasticsearch. Біз бос уақыт туралы ойлай бастаймыз. Бұл жерде, әрине, интернет-дүкеннің бір күн бойы ауыртпалықсыз жата алмайтыны анық. Өйткені, ол қаншалықты ұзақ болса, соғұрлым көп ақша жоғалтамыз. Бұл жылдамдатуға тұрарлық. Қанша? Бір сағат жатсақ, ешкім жынды болмайды деп ойлаймын. Иә, біз бірдеңе жоғалтамыз, бірақ егер біз қатты жұмыс істей бастасақ, ол одан сайын нашарлайды. Біз сағатына рұқсат етілген тоқтап қалудың схемасын анықтаймыз.
Мұның бәрін қалай сақтауға болады? Сізге кез келген жағдайда көлік қажет: бір сағат уақыт өте аз. Mysql: мұнда бізге репликация, тірі репликация қажет, өйткені бір сағаттан кейін 100 ГБ қоқысқа қосылмайды. Статика, суреттер: тағы бір сағаттан кейін 500 ГБ қосуға уақыт болмауы мүмкін. Сондықтан суреттерді бірден көшіріп алған дұрыс. Редис: бұл жерде қызық болады. Redis-те сеанстар сақталады - біз оны жай ғана алып, көме алмаймыз. Өйткені бұл өте жақсы болмайды: барлық пайдаланушылар жүйеден шығады, олардың себеттері босатылады және т.б. Адамдар өздерінің пайдаланушы аты мен құпия сөзін қайта енгізуге мәжбүр болады және көптеген адамдар сатып алуды аяқтамауы мүмкін. Қайтадан, конверсиялар төмендейді. Екінші жағынан, Redis тікелей жаңартылған, соңғы рет кірген пайдаланушылар да қажет емес. Және жақсы ымыра - Редисті алып, оны кешегі сақтық көшірмеден қалпына келтіру, немесе егер сіз мұны әр сағат сайын жасасаңыз, бір сағат бұрын. Бақытымызға орай, оны сақтық көшірмеден қалпына келтіру бір файлды көшіруді білдіреді. Ал ең қызықты оқиға - Elasticsearch. MySQL репликациясын кім алды? Elasticsearch репликациясын кім алды? Кімге кейін қалыпты жұмыс істеді? Менің айтқым келгені, біз жүйемізде белгілі бір нысанды көреміз. Бұл пайдалы сияқты - бірақ бұл күрделі.
Біздің инженер әріптестеріміз онымен жұмыс істеу тәжірибесі жоқ деген мағынада күрделі. Немесе жағымсыз тәжірибе бар. Немесе бұл әлі де нюанстары немесе шикілігі бар жаңа технология екенін түсінеміз. Біз ойлаймыз... Қарғыс атсын, серпімді де сау, оны сақтық көшірмеден қалпына келтіруге де көп уақыт кетеді, не істеуім керек? Біздің жағдайда серпімді іздеу үшін қолданылатынын түсінеміз. Біздің интернет-дүкен қалай сатылады? Біз маркетологтарға барып, адамдардың қайдан келгенін сұраймыз. Олар: «Яндекс Маркеттің 90% тікелей өнім картасына келеді» деп жауап береді. Және олар оны сатып алады немесе алмайды. Сондықтан іздеу пайдаланушылардың 10% қажет. Және серпімді репликацияны сақтау, әсіресе әртүрлі аймақтардағы әртүрлі деректер орталықтары арасында шын мәнінде көптеген нюанстар бар. Қай шығу? Біз резервтелген сайттан серпімді аламыз және онымен ештеңе жасамаймыз. Егер мәселе созыла берсе, біз оны бір күні көтеретін шығармыз, бірақ бұл анық емес. Шын мәнінде, қорытынды бірдей, плюс немесе минус: біз ақшаға әсер етпейтін қызметтерді қайталамаймыз. Диаграмманы қарапайым ету үшін.
Төртінші мысал, одан да қиын
Интегратор: гүл сату, такси шақыру, тауар сату, жалпы, кез келген нәрсе. Көптеген пайдаланушылар үшін тәулік бойы жұмыс істейтін маңызды нәрсе. Қызықты негіздер, шешімдер, жоғары жүктеме бар, ең бастысы, 24 минуттан артық жату ауыратын толыққанды қызықты стекпен. Адамдар сатып алмайтындықтан ғана емес, адамдар бұл нәрсе жұмыс істемейтінін көргендіктен, олар ренжіп, мүлде қайтып келмеуі мүмкін.
ЖАРАЙДЫ МА. Бес минут. Бұл туралы не істейміз? Бұл жағдайда біз, ересектер сияқты, барлық ақшаны барлығын қайталай отырып, нақты резервтік сайтты құруға жұмсаймыз, мүмкін, бұл сайтқа ауысуды мүмкіндігінше автоматтандырамыз. Бұған қоса, сіз бір маңызды нәрсені есте сақтауыңыз керек: шын мәнінде, коммутация ережелерін жазыңыз. Егер сізде бәрі автоматтандырылған болса да, ережелер өте қарапайым болуы мүмкін. «Осындай сценарийді іске қосу», «53-бағдардағы осындай құсбелгіні басыңыз» және т.б. - бірақ бұл әрекеттердің нақты тізімі болуы керек.
Және бәрі түсінікті сияқты. Репликацияны ауыстыру тривиальды тапсырма болып табылады немесе ол өздігінен ауысады. DNS жүйесінде домен атауын қайта жазу бірдей сериядан. Мәселе мынада, мұндай жоба сәтсіз болғанда, дүрбелең басталады, тіпті ең күшті, сақалды әкімшілер де оған сезімтал болуы мүмкін. «Терминалды ашыңыз, мұнда келіңіз, біздің сервердің мекенжайы әлі осындай» деген нақты нұсқауларсыз реанимацияға бөлінген 5 минуттық шектеуді орындау қиын. Сонымен қатар, біз осы ережелерді пайдаланған кезде, мысалы, инфрақұрылымдағы кейбір өзгерістерді тіркеп, соған сәйкес ережелерді өзгерту оңай.
Ал, егер брондау жүйесі өте күрделі болса және бір сәтте біз қателестік, онда біз резервтік сайтымызды жоя аламыз, сонымен қатар деректерді екі сайтта да асқабаққа айналдыра аламыз - бұл мүлдем қайғылы болады.
Бесінші мысал, толық хардкор
Дүние жүзіндегі жүздеген миллион пайдаланушылары бар халықаралық қызмет. Барлық уақыт белдеулері бар, максималды жылдамдықта жоғары жүктеме, сіз мүлде жата алмайсыз. Бір минут - және бұл қайғылы болады. Не істеу? Толық бағдарлама бойынша қайтадан резервке қойыңыз. Біз алдыңғы мысалда айтқанымның барлығын орындадық және тағы біраз. Идеалды әлем және біздің инфрақұрылымымыз IaaC devops концепцияларының барлығына сәйкес келеді. Яғни, барлығы git-те, ал сіз жай ғана түймені басыңыз.
Не жетіспейді? Біреуі – жаттығулар. Оларсыз мүмкін емес. Бізде бәрі тамаша сияқты, жалпы бізде барлығы бақылауда. Біз түймені басамыз, бәрі орын алады. Бұл солай болса да - және біз бұлай болмайтынын түсінеміз - біздің жүйе басқа жүйелермен өзара әрекеттеседі. Мысалы, бұл 53-маршруттағы dns, s3 сақтау, кейбір API-мен біріктіру. Бұл алыпсатарлық экспериментте біз бәрін алдын ала көре алмаймыз. Біз қосқышты шынымен тартпайынша, оның жұмыс істейтінін немесе істемейтінін білмейміз.
Бәрі осы шығар. Жалқау болмаңыз немесе оны асыра пайдаланбаңыз. Жұмыс уақыты сізбен бірге болсын!
Ақпарат көзі: www.habr.com