У гэтым артыкуле сабраны некаторыя агульныя шаблоны, якія дапамагаюць інжынерам працаваць з маштабнымі сэрвісамі, да якіх робяць запыты мільёны карыстальнікаў.
Па досведзе аўтара, гэта не вычарпальны спіс, але сапраўды эфектыўныя парады. Такім чынам, пачнем.
Перакладзена пры падтрымцы .
пачатковы ўзровень
Пералічаныя ніжэй меры адносна простыя ў рэалізацыі, але даюць высокую аддачу. Калі вы раней іх не рабілі, то будзеце здзіўлены значнымі паляпшэннямі.
Інфраструктура як код
Першая частка парад заключаецца ў тым, каб рэалізаваць інфраструктуру як код. Гэта азначае, што ў вас павінен быць праграмны спосаб разгортвання ўсёй інфраструктуры. Гучыць мудрагеліста, але насамрэч мы кажам аб наступным кодзе:
Разгортванне 100 віртуальных машын
- з Ubuntu
- 2 ГБ RAM на кожнай
- у іх будзе наступны код
- з такімі параметрамі
Вы можаце адсочваць змены ў інфраструктуры і хутка вяртацца да іх з дапамогай сістэмы кіравання версіямі.
Мадэрніст ўва мне кажа, што можна выкарыстоўваць Kubernetes/Docker, каб зрабіць усё вышэй пералічанае, і ён мае рацыю.
Акрамя таго, забяспечыць аўтаматызацыю, можна з дапамогай Chef, Puppet ці Terraform.
Бесперапынная інтэграцыя і дастаўка
Для стварэння які маштабуецца сэрвісу важна наяўнасць канвеера зборкі і цесты для кожнага пул-рэквеста. Нават калі тэст самы просты, ён, прынамсі, гарантуе, што код, які вы дэплоіце, кампілюецца.
Кожны раз на гэтым этапе вы адказваеце на пытанне: ці будзе мая зборка кампілявацца і праходзіць тэсты, ці валідная яна? Гэта можа падацца нізкай планкай, але вырашае мноства праблем.
Няма нічога выдатней, чым бачыць гэтыя галачкі
Для гэтай тэхналогіі можаце ацаніць Github, CircleCI ці Jenkins.
Балансавальнікі нагрузкі
Такім чынам, мы жадаем запусціць балансавальнік нагрузкі, каб перанакіроўваць трафік, і забяспечыць роўную нагрузку на ўсіх вузлах ці працу сэрвісу ў выпадку збою:
Балансавальнік нагрузкі, як правіла, добра дапамагае размяркоўваць трафік. Найлепшай практыкай з'яўляецца залішняя балансіроўка, каб у вас не было адзінага пункта адмовы.
Звычайна балансавальнікі нагрузкі наладжваюцца ў тым воблаку, якім вы карыстаецеся.
RayID, сorrelation ID ці UUID для запытаў
Вам калі-небудзь сустракалася памылка ў дадатку з паведамленнем накшталт такога: «Нешта пайшло ня так. Захавайце гэты id і дашліце яго ў нашу службу падтрымкі»?
Унікальны ідэнтыфікатар, correlation ID, RayID або любы з варыянтаў - гэта ўнікальны ідэнтыфікатар, які дазваляе адсочваць запыт на працягу яго жыццёвага цыклу. Гэта дазваляе адсачыць увесь шлях запыту ў логах.
Карыстальнік робіць запыт да сістэмы A, затым А злучаецца з B, тая злучаецца з C, захоўвае ў X і затым запыт вяртаецца ў A
Калі б вы выдалена падключыліся да віртуальных машын і паспрабавалі прасачыць шлях запыту (і ўручную суаднесці, якія адбываюцца выклікі), то звар'яцелі б. Наяўнасць унікальнага ідэнтыфікатара значна аблягчае жыццё. Гэта адна з самых простых рэчаў, якую можна зрабіць, каб зэканоміць час па меры росту сервісу.
Сярэдні ўзровень
Тут парады складаней папярэдніх, але правільныя інструменты палягчаюць задачу, забяспечваючы акупляльнасць інвестыцый нават для малых і сярэдніх кампаній.
Цэнтралізаванае вядзенне часопісаў
Віншую! Вы разгарнулі 100 віртуальных машын. На наступны дзень генеральны дырэктар прыходзіць і скардзіцца на памылку, якую атрымаў падчас тэсціравання сэрвісу. Ён паведамляе адпаведны ідэнтыфікатар, пра які мы казалі вышэй, але вам давядзецца праглядаць часопісы 100 машын, каб знайсці тую, якая выклікала збой. І яе трэба знайсці да заўтрашняй прэзентацыі.
Хоць гэта гучыць як пацешнае прыгода, аднак, лепш пераканацца, што ў вас ёсць магчымасць пошуку па ўсіх часопісах з аднаго месца. Я вырашыў задачу цэнтралізацыі часопісаў з дапамогай убудаванай функцыянальнасці стэка ELK: тут падтрымліваецца збор часопісаў з магчымасцю пошуку. Гэта сапраўды дапаможа вырашыць праблему з пошукам канкрэтнага часопіса. У якасці бонуса вы можаце ствараць дыяграмы і да таго падобныя пацешныя штукі.
Функцыянальнасць стэка ELK
Агенты маніторынгу
Цяпер, калі ваша служба ўведзена ў строй, трэба пераканацца, што яна працуе без збояў. Лепшы спосаб зрабіць гэта - запусціць некалькі агентаў, якія працуюць паралельна і правяраюць, што яна працуе і выконваюцца базавыя аперацыі.
На гэтым этапе вы правяраеце, што запушчаная зборка добра сябе адчувае і нармальна працуе.
Для невялікіх і сярэдніх праектаў я рэкамендую Postman для маніторынгу і дакументаванні API. Але ў цэлым проста трэба пераканацца, што ў вас ёсць спосаб даведацца, калі адбыўся збой, і атрымаць своечасовае апавяшчэнне.
Аўтамаштабаванне ў залежнасці ад нагрузкі
Гэта проста. Калі ў вас ёсць віртуальная машына, якая абслугоўвае запыты, і яна набліжаецца да таго, што 80% памяці занята, то можна або павялічыць яе рэсурсы, або дадаць у кластар больш віртуальных машын. Аўтаматычнае выкананне гэтых аперацый выдатна падыходзіць для эластычнай змены магутнасці пад нагрузкай. Але вы заўсёды павінны быць асцярожныя ў тым, колькі грошай марнуеце, і ўсталяваць разумныя ліміты.
У большасці хмарных службаў вы можаце наладзіць аўтаматычнае маштабаванне, выкарыстоўваючы большую колькасць сервераў або больш магутныя серверы.
Сістэма эксперыментаў
Добрым спосабам бяспечна разгарнуць абнаўленні стане магчымасць пратэставаць нешта для 1% карыстачоў на працягу гадзіны. Вы, канешне, бачылі такія механізмы ў дзеянні. Напрыклад, Facebook паказвае часткі аўдыторыі іншы колер або мяняе памер шрыфта, каб паглядзець, як карыстальнікі ўспрымаюць змены. Гэта называюць A/B-тэставаннем.
Нават выпуск новай функцыі можна запусціць як эксперымент, а пасля вызначыць, як яе выпускаць. Таксама вы атрымліваеце магчымасць "успамінаць" ці змяняць канфігурацыю на лета з улікам функцыі, якая выклікае дэградацыю вашага сэрвісу.
прасунуты ўзровень
Тут парады, якія даволі складана рэалізаваць. Верагодна, вам спатрэбіцца крыху больш рэсурсаў, таму невялікі або сярэдняй кампаніі будзе цяжка з гэтым справіцца.
Сіне-зялёныя разгортванні
Гэта тое, што я заву «эрлангаўскім» спосабам разгортвання. Erlang пачалі шырока выкарыстоўваць, калі з'явіліся тэлефонныя кампаніі. Для маршрутызацыі тэлефонных званкоў сталі прымяняць праграмныя камутатары. Асноўная задача праграмнага забеспячэння гэтых камутатараў складалася ў тым, каб не скідаць выклікі падчас абнаўлення сістэмы. У Erlang ёсць выдатны спосаб загрузкі новага модуля без падзення папярэдняга.
Гэты крок залежыць ад наяўнасці балансавальніка нагрузкі. Уявім, што ў вас версія N вашага праграмнага забеспячэння, а затым вы жадаеце разгарнуць версію N+1.
Вы маглі б проста спыніць службу і разгарнуць наступную версію ў той час, які лічыце зручным для вашых карыстальнікаў, і атрымаць некаторы час прастою. Але выкажам здагадку, што ў вас сапраўды строгія ўмовы SLA. Так, SLA 99,99% азначае, што вы можаце сыходзіць у афлайн толькі на 52 хвіліны ў год.
Калі вы сапраўды жадаеце дасягнуць такіх паказчыкаў, трэба два дэплоі адначасова:
- той, які ёсць прама зараз (N);
- наступная версія (N+1).
Вы паказваеце балансавальніку нагрузкі перанакіраваць працэнт трафіку на новую версію (N+1), у той час як самі актыўна адсочваеце рэгрэсіі.
Тут у нас ёсць зялёны дэплой N, які нармальна працуе. Мы спрабуем перайсці да наступнай версіі гэтага дэплою.
Спачатку мы пасылаем сапраўды невялікі тэст, каб паглядзець, ці працуе наш дэплой N+1 з невялікай колькасцю трафіку:
Нарэшце, у нас ёсць набор аўтаматычных праверак, якія мы ў канчатковым выніку запускаем да таго часу, пакуль наша разгортванне не будзе завершана. Калі вы вельмі вельмі асцярожныя, таксама можаце захаваць сваё разгортванне N назаўжды для хуткага адкату ў выпадку дрэннай рэгрэсіі:
Калі жадаеце перайсці на яшчэ больш прасунуты ўзровень, няхай усё ў сіне-зялёным дэплоі выконваецца аўтаматычна.
Выяўленне анамалій і аўтаматычнае змякчэнне наступстваў
Улічваючы, што ў вас цэнтралізаванае вядзенне часопісаў і добры збор логаў, ужо можна ставіць больш высокія мэты. Напрыклад, актыўна прагназаваць збоі. На маніторах і ў часопісах адсочваюцца функцыі і будуюцца розныя дыяграмы – і можна загадзя прадказаць, што пойдзе не так:
З выяўленнем анамалій вы пачынаеце вывучаць некаторыя падказкі, якія выдае сэрвіс. Напрыклад, усплёск нагрузкі на CPU можа падказаць, што цвёрдая кружэлка выходзіць з ладу, а ўсплёск колькасці запытаў азначае, што трэба маштабавацца. Такога роду статыстычныя дадзеныя дазваляюць зрабіць сэрвіс праактыўным.
Атрымліваючы такія аналітычныя дадзеныя, вы можаце маштабавацца ў любым вымярэнні, праактыўна і рэактыўна змяняць характарыстыкі машын, баз даных, злучэнняў і іншых рэсурсаў.
Вось і ўсё!
Гэты спіс прыярытэтаў пазбавіць вас ад многіх праблем, калі вы падымаеце хмарны сэрвіс.
Аўтар арыгінальнага артыкула запрашае чытачоў пакідаць свае каментарыі і ўносіць змены. Артыкул распаўсюджваецца як open source, пул-рэквесты аўтар .
Што яшчэ пачытаць па тэме:
Крыніца: habr.com