Улетку традыцыйна зніжаецца і пакупальніцкая актыўнасць, і інтэнсіўнасць змены інфраструктуры вэб-праектаў, кажа нам Капітан Відавочна. Проста таму што нават айцішнікі, здараецца, ходзяць у водпуск. І CТО таксама. Тым цяжэй тым, хто застаецца на пасадзе, але зараз не пра гэта: магчыма, менавіта таму лета - лепшы перыяд для таго, каб не спяшаючыся абдумаць існуючую схему рэзервавання і скласці план па яе паляпшэнні. І ў гэтым вам будзе карысны досвед Ягора Андрэева з , пра які ён распавёў на канферэнцыі .
Пры будаўніцтве рэзервовых пляцовак, пры рэзерваванні ёсць некалькі пастак, у якія можна патрапіць. А трапляцца ў іх зусім нельга. І губіць нас ва ўсім гэтым, як і шмат у чым іншым, перфекцыянізм і… лянота. Мы спрабуем зрабіць усё-ўсё-ўсё ідэальна, а ідэальна рабіць не трэба! Трэба рабіць толькі пэўныя рэчы, але зрабіць іх правільна, давесці да канца, каб яны нармальна працавалі.
Failover - гэта не нейкая такая вясёлая фанавая штука "каб было"; гэта рэч, якая павінна зрабіць роўна адно - паменшыць час прастою, каб сэрвіс, кампанія, губляла менш грошай. І ва ўсіх метадах рэзервавання я прапаную думаць у наступным кантэксце: дзе грошы?
Першая пастка: калі мы будуем вялікія надзейныя сістэмы і займаемся рэзерваваннем - мы памяншаем колькасць аварый. Гэта страшная памылка. Калі мы займаемся рэзерваваннем, колькасць аварый мы, хутчэй за ўсё, падвышаем. І калі мы зробім усё правільна, то сукупна мы час прастою паменшым. Аварый будзе больш, але яны будуць адбывацца з меншымі выдаткамі. Бо што такое рэзерваванне? - Гэта ўскладненне сістэмы. Любое ўскладненне - гэта дрэнна: у нас з'яўляецца больш шрубак, больш шасцяронак, словам, больш элементаў - і, такім чынам, вышэй шанец на паломку. І яны сапраўды разламаюцца. І будуць ламацца часцей. Просты прыклад: скажам, у нас есць нейкі сайт, з PHP, MySQL. І яго тэрмінова трэба зарэзерваваць.
Штош(с) Бярэм другую пляцоўку, будуем ідэнтычную сістэму… Складанасць становіцца ў два разы большай — у нас дзве сутнасці. А яшчэ мы зверху накочваем пэўную логіку пераносу дадзеных з адной пляцоўкі на іншую - гэта значыць рэплікацыя дадзеных, капіраванне статыкі і гэтак далей. Дык вось, логіка рэплікацыі - яна звычайна вельмі складаная, і такім чынам, сукупная складанасць сістэмы можа быць не ў 2, а 3, 5, 10 разоў больш.
Другая пастка: калі мы будуем па-сапраўднаму вялікія складаныя сістэмы, мы фантазіюем, што ж хочам атрымаць у выніку. Вуаля: мы жадаем атрымаць супернадзейную сістэму, якая працуе наогул без прастою, перамыкаецца за паўсекунды (а лепш наогул імгненна), і пачынаем увасабляць мары ў рэальнасць. Але тут таксама ёсць нюанс: чым меншы жаданы час пераключэння, тым больш складанай атрымліваецца логіка сістэмы. Чым складаней нам давядзецца рабіць гэтую логіку, тым часцей сістэма будзе ламацца. І можна патрапіць у вельмі непрыемную сітуацыю: мы ўсімі сіламі спрабуем час прастою паменшыць, а насамрэч мы ўсё ўскладняем, і калі нешта ідзе не так, час прастою ў выніку будзе больш. Тут часта ловіш сябе на думцы: вось… лепш бы не рэзервавалі. Лепш бы яно адно працавала і са зразумелым часам прастою.
Як можна з гэтым дужацца? Трэба перастаць сабе хлусіць, перастаць сабе ліслівіць, што мы тут зараз будзем будаваць касмалёт, але адэкватна разумець, колькі праект можа паляжаць. І пад гэты максімальны час мы будзем выбіраць, якімі, уласна, метадамі будзем падвышаць надзейнасць нашай сістэмы.
Самы час для "гісторый з ж"… з жыцця, вядома ж.
Прыклад нумар адзін
Прадстаўце сайт-візітку трубапракатнага завода №1 горада N. На ёй напісана велізарнымі літарамі - Трубапракатны ЗАВОД №1. Крыху ніжэй - слоган: "Нашы трубы - самыя круглыя трубы ў N". І знізу нумар тэлефона генеральнага дырэктара і ягонае імя. Разумеем, што трэба рэзерваваць - гэта ж вельмі важная штука! Пачынаем разбірацца, з чаго складаецца. Html-статыка – гэта значыць пара картинак, дзе генеральны, уласна, за сталом у лазні са сваім партнёрам абмяркоўваюць нейкую чарговую здзелку. Пачынаем думаць пра час прастою. У галаву прыходзіць: ляжаць тамака трэба пяць хвілін, не больш. І тут пытанне: а колькі з гэтага нашага сайта было продажаў увогуле? Колькі-колькі? Што значыць «нуль»? А то і значыць: таму што ўсе чатыры здзелкі за мінулы год генеральны зрабіў за тым жа сталом, з тымі ж людзьмі, з якімі яны ходзяць у лазню сядзяць за сталом. І разумеем, што нават калі дзень паляжыць сайт - страшнага не будзе нічога.
Зыходзячы з уступных, ёсць дзень на ўзняцце гэтай гісторыі. Пачынаем думаць пра схему рэзервавання. І выбіраемы самую ідэальную схему для рэзервавання для дадзенага прыкладу: мы рэзерваванне не выкарыстоўваны. Вось гэтая ўся штука паднімаецца любым адмінам за паўгадзіны з перакурамі. Паставіць вэб-сервер, пакласці файлы - усё. Яно пачне працаваць. Ні за чым не трэба сачыць, нічому не трэба надаваць асаблівай увагі. Гэта значыць выснова з прыкладу нумар адзін даволі відавочны: сэрвісы, якія рэзерваваць не трэба - рэзерваваць не трэба.
Прыклад нумар два
Блог кампаніі: спецыяльна навучаныя пішуць туды навіны, вось мы паўдзельнічалі ў такой выставе, а вось мы выпусцілі яшчэ новы прадукт і гэтак далей. Дапушчальны, гэта стандартны PHP з WordPress, невялікая база дадзеных і ледзь-ледзь статыкі. У галаву, вядома, зноў прыходзіць, што ляжаць ні ў якім разе нельга - "не больш за пяць хвілін!", вось гэта ўсё. Але давайце падумаем далей. Што гэты блог робіць? Туды прыходзяць з Яндэкса, з Гугла па нейкіх запытах, па арганіцы. Выдатна. А продажы неяк увогуле з ім звязаныя? Прасвятленне: не асоба. Рэкламны трафік ідзе на асноўны сайт, які на іншай машыне. Пачынаем думаць пра схему рэзервавання бложака. Па-добраму, за пару гадзін яго трэба падняць, і да гэтага было б нядрэнна падрыхтавацца. Разумным будзе ўзяць у іншым дата-цэнтры машыну, на яе ўкаціць асяроддзе, гэта значыць вэб-сервер, PHP, WordPress, MySQL, і пакінуць гэта ляжаць прытушаным. У момант, калі мы разумеем, што ўсё зламалася, трэба зрабіць дзве рэчы – раскатаць дамп mysql на 50 метраў, ён праляціць там за хвіліну, і раскатаць там нейкую колькасць карцінак з бэкапу. Гэта таксама там не бог ведае колькі. Такім чынам, за паўгадзіны ўся гэтая штука паднімаецца. Ніякіх рэплікацый, ці прабач божа, аўтаматычнага failover'a. Выснова: тое, што мы можам хутка раскачаць з бэкапу - рэзерваваць не трэба.
Прыклад нумар тры, больш складаны
Інтэрнэт крама. PhP з open heart трошкі падпілаваны, mysql з самавітай базай. Даволі шмат статыкі (бо ў інтэрнэт-краме ёсць прыгожыя HD-малюначкі і ўсё такое іншае), Redis для сесіі і Elasticsearch для пошуку. Пачынаем думаць пра час прастою. І тут, вядома, відавочна, што дзень бязбольна інтэрнэт-крама валяцца не можа. Бо чым даўжэй ён ляжыць, тым болей грошай мы губляем. Варта паскорыцца. А наколькі? Мяркую, калі мы гадзіну паляжым, то ніхто з глузду не з'едзе. Так, мы нешта страцім, але пачнем завіхацца — будзе толькі горш. Вызначаем схему прастою, дапушчальнага ў гадзіну.
Як гэта ўсё можна зарэзерваваць? Машына патрэбна ў любым выпадку: гадзіна часу гэта даволі мала. Mysql: тут ужо патрэбная рэплікацыя, жывая рэплікацыя, таму што за гадзіну 100 гб у дамп, хутчэй за ўсё, не ўвальецца. Статыка, картиночки: ізноў жа, за гадзіну 500 гб можа не паспець уліцца. Такім чынам, лепш адразу карціначкі капіяваць. Redis: вось тут цікавей. У Redis сесіі ляжаць - проста ўзяць і пахаваць мы яго не можам. Таму што гэта будзе не вельмі добра: усе карыстачы апынуцца разлогі, кошыкі вычышчанымі і гэтак далей. Людзі будуць вымушаныя зноўку ўводзіць свой лагін і пароль, і шмат народу можа адкалоцца і пакупку не завяршыць. Ізноў жа, канверсія зваліцца. З іншага боку, Redis прамы адзін у адзін актуальны, з апошнімі якія залагініліся карыстачамі, мусіць, таксама не патрэбен. І добры кампраміс – узяць Redis і аднавіць яго з бэкапу, учорашняга, альбо, калі ён у вас кожную гадзіну робіцца, – гадзіннікавай даўнасці. Балазе аднаўленне яго з бэкапу - гэта капіраванне аднаго файла. А самая цікавая гісторыя – гэта Elasticsearch. Хто калі-небудзь паднімаў рэплікацыю MySQL? Хто калі-небудзь паднімаў рэплікацыю Elasticsearch? І ў каго яна пасля працавала нармальна? Я да чаго: бачым у нашай сістэме нейкую сутнасць. Яна накшталт як карысная - але яна складаная.
Складаная ў тым сэнсе, што ў нашых калег-інжынераў няма досведу працы з ёй. Альбо ёсць негатыўны досвед. Або мы разумеем, што пакуль гэта даволі новая тэхналогія з нюансамі ці волкасцю. Думаем… Блін, elastic таксама здаровы, яго з бэкапу таксама доўга аднаўляць, што рабіць? Разумеем, што elastic у нашым гэтым выпадку выкарыстоўваецца для пошуку. А як прадае нашу інтэрнэт-краму? Ідзем да маркетолагаў, пытаемся, увогуле адкуль людзі прыходзяць. Яны адказваюць: "90% з Яндэкс-маркета прыходзяць прама ў картку тавару". І альбо купляюць, альбо не. Такім чынам, пошук патрэбен 10% карыстальнікаў. А трымаць рэплікацыю elastic'a, асабліва паміж рознымі дата-цэнтрамі ў розных зонах, - там, сапраўды, шмат нюансаў. Якое выйсце? Мы бярэм elastic на рэзерваванай пляцоўцы і нічога з ім не які робіцца. Калі справа зацягнецца, то мы яе калі-небудзь потым, магчыма, уздымем, але гэта не дакладна. Уласна, выснова плюс-мінус ранейшая: сэрвісы, якія на грошы не ўплываюць, мы, зноў жа, не рэзервуем. Каб схема заставалася прасцей.
Прыклад нумар чатыры, яшчэ складаней
Інтэгратар: продажы кветак, выкліку таксі, продажу тавараў, увогуле, чаго заўгодна. Сур'ёзная штука, якая працуе 24/7 на вялікую колькасць карыстальнікаў. З паўнавартасным цікавым стэкам, дзе ёсць цікавыя базы, рашэнні, высокая нагрузка, і самае галоўнае, ляжаць яму больш за 5 хвілін балюча. Не толькі і не столькі таму, што людзі не купяць, а таму што людзі ўбачаць, што гэтая штука не працуе, знервуюцца і могуць наогул другі раз не прыйсці.
Окей. Пяць хвілін. Што з гэтым будзем рабіць? У гэтым выпадку мы па-даросламу, на ўсе грошы будуем сапраўдную рэзервовую пляцоўку, з рэплікацыяй за ўсё і ўся, і магчыма, нават аўтаматызуем па максімуме пераключэнне на гэтую пляцоўку. І ў дадатак да гэтага трэба не забыцца зрабіць адну важную рэч: уласна, напісаць рэгламент пераключэння. Рэгламент, нават калі ў вас аўтаматызавана ўсё і ўся, можа быць вельмі простай. З серыі "запусціць вось такі сцэнар ansible", "у route 53 націснуць нейкую галку" і гэтак далей - але гэта павінен быць нейкі дакладны спіс з дзеянняў.
І быццам усё зразумела. Рэплікацыю пераключыць - трывіяльная задача, альбо яна сама пераключыцца. Перапісаць даменнае імя ў dns - з той жа серыі. Бяда ў тым, што калі падае падобны праект, пачынаецца паніка, і нават наймацнейшыя, барадатыя адміны могуць быць ёй схільныя. Без дакладнай інструкцыі "адкрый тэрмінал, зайдзі сюды, адрас у нашага сервера па-ранейшаму вось такі" тэрмін у 5 хвілін, адведзеных на рэанімацыю, вытрымаць складана. Ну і плюс, калі мы гэтым рэгламентам карыстаемся, лёгка адфіксаваць нейкія змены ў інфраструктуры, напрыклад, - і адпаведным чынам змяніць рэгламент.
Ну, а калі калі сістэма рэзервавання вельмі складаная і ў нейкі момант мы дапусцілі памылку, то мы можам абкласці і нашу рэзервовую пляцоўку, а ў дадатак дадзеныя ператварыць у гарбуз на абедзвюх пляцоўках - гэта будзе зусім сумна.
Прыклад нумар пяць, поўны хардкор
Міжнародны сэрвіс з сотняй мільёнаў карыстальнікаў па ўсім свеце. Усе таймзоны, якія толькі ёсць, highload на максімалках, ляжаць увогуле ніяк нельга. Хвіліна - і будзе сумна. Што рабіць? Рэзерваваць, зноў жа, па поўнай праграме. Зрабілі ўсё, пра што казаў у папярэднім прыкладзе, і яшчэ крышачку больш. Ідэальны свет, і наша інфраструктура – яна па ўсіх паняццях дэвопсу IaaC. Гэта значыць усё наогул у git, і толькі кнопку націскай.
Чаго не хапае? Аднаго - вучэнняў. Без іх нельга. Здаецца, у нас усё ідэальна, у нас увогуле ўсё пад кантролем. Кнопку націскаем, усё адбываецца. Нават калі гэта так - а мы разумеем, што так яно не бывае - наша сістэма ўзаемадзейнічае з нейкімі іншымі сістэмамі. Напрыклад, гэта dns ад route 53, s3-сховішчы, інтэграцыя з нейкімі api. Усё прадугледзець у гэтым абстрактным эксперыменце мы не зможам. І пакуль мы рэальна не дзёрнем рубільнік - не даведаемся, запрацуе яно ці не.
На гэтым, мусіць, усё. Не лянуйцеся і не перашчыруйце. І хай застанецца з вамі uptime!
Крыніца: habr.com