Машинное обу­че­ние в про­мыш­лен­но­сти — формула успе­ха

Otkrytye sistemy. SUBD. - - СОДЕРЖАНИЕ -

Оль­га Плос­ская

Машинное обу­че­ние как ин­стру­мент ра­бо­ты с боль­ши­ми объ­е­ма­ми дан­ных за­ча­стую при­ни­ма­ет­ся за «се­реб­ря­ную пу­лю» для достижения за­яв­лен­ных биз­нес-це­лей. Не­уди­ви­тель­но, что про­мыш­лен­ные пред­при­я­тия при­смат­ри­ва­ют­ся к по­доб­ным ме­то­дам, ак­тив­но ини­ци­и­руя «пи­ло­ты». Од­на­ко по­доб­ные про­ек­ты со­про­вож­да­ют­ся мно­же­ством огра­ни­че­ний, боль­ши­ми рис­ка­ми и за­ча­стую тер­пят неуда­чу.

каж­дая из ко­то­рых мо­жет быст­ро со­зда­вать­ся, об­нов­лять­ся, за­ме­нять­ся и уда­лять­ся по ме­ре необ­хо­ди­мо­сти.

С пе­ре­хо­дом на бес­сер­вер­ную ар­хи­тек­ту­ру возникает во­прос нуж­но­сти ком­му­ни­ка­ци­он­но-ори­ен­ти­ро­ван­ных тех­но­ло­гий на­по­до­бие по­сред­ни­ков и mesh-се­тей. Ны­неш­ние плат­фор­мы Faas еще не обес­пе­чи­ва­ют всех функ­ций свя­зи и управ­ле­ния тра­фи­ком, но мож­но пред­ста­вить сце­на­рий, в ко­то­ром ре­а­ли­зу­ют­ся sidecar-по­доб­ные функ­ции, слу­жа­щие по­сред­ни­ка­ми для всех меж­функ­ци­о­наль­ных вза­и­мо­дей­ствий в бес­сер­вер­ном при­ло­же­нии (рис. 2, г). Вы­со­ко­уров­не­вая функ­ция управ­ля­ю­щей плос­ко­сти при этом мог­ла бы вы­пол­нять мо­ни­то­ринг и управ­лять по­ве­де­ни­ем этих по­сред­ни­че­ских функ­ций, став но­вым ви­дом сер­вис­ной (или функ­ци­о­наль­ной) mesh-се­ти.

ДАЛЬ­НЕЙ­ШИЕ ЦЕ­ЛИ

Оче­вид­ный ми­нус воз­рос­шей по­пу­ляр­но­сти мик­ро­сер­ви­сов — по­вы­ше­ние ве­ро­ят­но­сти то­го, что их бу­дут ис­поль­зо­вать в си­ту­а­ци­ях, ко­гда за­тра­ты зна­чи­тель­но боль­ше преимуществ (на­при­мер, ко­гда про­ект пред­по­чти­тель­нее бы­ло бы раз­ра­ба­ты­вать как мо­но­лит­ный). Это не зна­чит, что система не долж­на быть мо­дуль­ной, про­сто ее мо­ду­ли не тре­бу­ет­ся изо­ли­ро­вать в ка­че­стве мик­ро­сер­ви­сов.

Микросервисы не яв­ля­ют­ся и ни­ко­гда не бу­дут оп­ти­маль­ным решением для лю­бых слу­ча­ев. Воз­мож­ны та­к­же си­ту­а­ции, ко­гда микросервисы дей­стви­тель­но под­хо­дят, но про­ект тер­пит крах, че­му мо­жет быть мно­же­ство раз­лич­ных при­чин. Для ре­ше­ния со­от­вет­ству­ю­щих про­блем нуж­ны даль­ней­шие раз­ра­бот­ки.

Мо­ду­ля­ри­за­ция и ре­фак­то­ри­за­ция сер­ви­сов

Вы­бор мо­ду­лей и их мас­шта­ба, рас­пре­де­ле­ние ответственности и про­ек­ти­ро­ва­ние ин­тер­фей­сов вы­зы­ва­ют трудности независимо от ти­па мо­ду­ля­ри­за­ции. Осо­бен­но это ка­са­ет­ся при­ме­не­ния мик­ро­сер­ви­сов и дру­гих ме­то­дов, при ко­то­рых неудач­ное опре­де­ле­ние гра­ниц мо­жет при­ве­сти к воз­рас­та­нию се­те­во­го тра­фи­ка, вслед­ствие че­го со­здан­ная система мо­жет ока­зать­ся непри­год­ной для сво­их за­дач вви­ду низ­кой про­из­во­ди­тель­но­сти и неста­биль­но­сти.

В це­лом от этой про­бле­мы не из­ба­вить­ся, но мож­но пред­ло­жить ча­стич­ные ре­ше­ния. Во-пер­вых, с по­мо­щью со­от­вет­ству­ю­щих ин­стру­мен­тов мож­но об­лег­чить ре­фак­то­ри­за­цию си­стем на ос­но­ве мик­ро­сер­ви­сов (прав­да, это мо­жет иметь непред­ви­ден­ные по­след­ствия, свя­зан­ные с воз­ник­но­ве­ни­ем за­ви­си­мо­сти от ин­фра­струк­ту­ры или средств раз­ра­бот­ки). Во-вто­рых, про­бле­мы со ста­биль­но­стью мож­но ре­шить пу­тем пе­ре­хо­да на асин­хрон­ную связь, бо­лее ши­ро­кое ис­поль­зо­ва­ние за­ве­до­мо ста­биль­ных биб­лио­тек и бо­лее со­вер­шен­ных сред вы­пол­не­ния. В даль­ней ча­сти спек­тра ре­ше­ний на­хо­дит­ся пол­но­стью бес­сер­вер­ный под­ход, це­ли­ком по­ла­га­ю­щий­ся на низ­ко­уров­не­вую плат­фор­му и предо­став­ля­е­мые ею сер­ви­сы. Но та­кой ме­тод то­же чре­ват боль­шой за­ви­си­мо­стью от кон­крет­ной сре­ды, что про­ти­во­ре­чит од­но­му из глав­ных преимуществ мик­ро­сер­ви­сов.

Гра­ну­ляр­ность сер­ви­сов

Еще од­на про­бле­ма — от­сут­ствие кон­сен­су­са по по­во­ду оп­ти­маль­но­го раз­ме­ра мик­ро­сер­ви­сов. Хо­тя да­же са­мо их на­зва­ние вро­де бы го­во­рит «чем мень­ше, тем луч­ше», оцен­ки про­ект­ных ко­манд силь­но раз­нят­ся. В неко­то­рых слу­ча­ях ис­поль­зу­ют­ся микросервисы раз­ме­ром в еди­ни­цы строк ко­да. В дру­гих мик­ро­сер­вис мо­жет ин­кап­су­ли­ро­вать несколь­ко де­сят­ков строк ко­да плюс де­сят­ки клас­сов и объектов ба­зы дан­ных. Связь меж­ду по­доб­ны­ми сер­ви­са­ми сред­не­го мас­шта­ба мо­жет быть син­хрон­ной или асин­хрон­ной. А при реализации са­мо­до­ста­точ­ной си­сте­мы — од­но­го из ва­ри­ан­тов мик­ро­сер­ви­сов — рекомендуют по ме­ре воз­мож­но­сти вклю­чать в сер­вис поль­зо­ва­тель­ский веб-ин­тер­фейс.

Каж­дый из этих под­хо­дов име­ет свои плю­сы, но мож­но бы­ло бы разработать шаб­ло­ны, ко­то­рые по­мо­га­ли бы при­ни­мать ар­хи­тек­тур­ные ре­ше­ния, ко­гда систему де­лят на микросервисы и вы­би­ра­ют их раз­мер.

Ин­те­гра­ция поль­зо­ва­тель­ско­го ин­тер­фей­са

Поль­зо­ва­тель­ский ин­тер­фейс как ком­по­нент мик­ро­сер­вис­ной ар­хи­тек­ту­ры тре­бу­ет

осо­бо­го вни­ма­ния. При­вер­жен­цы кон­цеп­ции мик­ро­сер­ви­сов, боль­шин­ство из ко­то­рых ар­хи­тек­то­ры, от­ве­ча­ю­щие за си­стем­ную часть, на ин­те­гра­цию поль­зо­ва­тель­ско­го ин­тер­фей­са не ори­ен­ти­ру­ют­ся. В ре­зуль­та­те по­яв­ля­ют­ся си­сте­мы, у ко­то­рых мо­но­лит­ная поль­зо­ва­тель­ская часть ис­поль­зу­ет ряд си­стем­ных мик­ро­сер­ви­сов. Ино­гда та­кая ар­хи­тек­ту­ра мо­жет быть оп­ти­маль­ной, но не­ред­ко она сво­дит на нет пре­иму­ще­ства мик­ро­сер­ви­сов, так как име­ет все недо­стат­ки мо­но­ли­та.

Мо­ду­ля­ри­за­ция поль­зо­ва­тель­ских ин­тер­фей­сов раз­ных ти­пов: веб-ин­тер­фей­сов, на­тив­ных, ги­брид­ных — необ­хо­ди­ма для реализации пол­но­го сте­ка мик­ро­сер­вис­ной сре­ды.

Мо­ни­то­ринг и управ­ле­ние ре­сур­са­ми

С ро­стом раз­ме­ра и слож­но­сти мик­ро­сер­вис­ных при­ло­же­ний рас­тут чис­ло и раз­но­об­ра­зие ин­фра­струк­тур­ных ре­сур­сов (вир­ту­аль­ных ма­шин, кон­тей­не­ров, сер­ви­сов, со­об­ще­ний, пу­лов по­то­ков и жур­на­лов), тре­бу­ю­щих непре­рыв­но­го мо­ни­то­рин­га и управ­ле­ния при вы­пол­не­нии. Кро­ме то­го, сер­ви­сы мо­гут быть раз­вер­ну­ты в несколь­ких ре­ги­о­нах и зо­нах до­ступ­но­сти, что услож­ня­ет сбор ак­ту­аль­ной ин­фор­ма­ции о со­сто­я­нии и по­ве­де­нии. В ко­неч­ном сче­те с ро­стом уровня ав­то­ма­ти­за­ции, обес­пе­чи­ва­е­мым ны­неш­ни­ми тех­но­ло­ги­я­ми мо­ни­то­рин­га, раз­ра­бот­чи­ки при­ло­же­ния мо­гут по­пасть под «водопад» со­бы­тий мо­ни­то­рин­га и утра­тить спо­соб­ность при­ни­мать опе­ра­тив­ные ре­ше­ния, ка­са­ю­щи­е­ся управ­ле­ния.

При этом важ­но опре­де­лить­ся с тем, как пра­виль­но устанавливать по­ро­ги и филь­тры пре­ду­пре­жде­ний, что­бы раз­ра­бот­чи­ки по­лу­ча­ли уве­дом­ле­ния о про­бле­мах без пе­ре­груз­ки лиш­ней ин­фор­ма­ци­ей. Еще труд­нее ре­а­ли­зо­вать механизм обу­че­ния на со­бы­ти­ях и дей­стви­ях про­шло­го, ко­то­рый по­мог бы обос­но­вы­вать ре­ше­ния, ка­са­ю­щи­е­ся управ­ле­ния ре­сур­са­ми, и, воз­мож­но, ав­то­ма­ти­зи­ро­вать их при­ня­тие. Раз­ра­бот­ка мас­шта­би­ру­е­мых ме­ха­низ­мов мо­ни­то­рин­га мик­ро­сер­ви­сов и управ­ле­ния ре­сур­са­ми, ос­но­ван­ных на боль­ших дан­ных, бу­дет опи­рать­ся на тео­рию управ­ле­ния и машинное обу­че­ние.

От­ка­зы, вос­ста­нов­ле­ние и са­мо­кор­рек­ция

Как и лю­бые рас­пре­де­лен­ные си­сте­мы, микросервисы от­ли­ча­ют­ся неустой­чи­во­стью. Они мо­гут ста­но­вить­ся недо­ступ­ны­ми или от­ка­зы­вать по мно­гим при­чи­нам, в том чис­ле свя­зан­ным с се­тя­ми, обо­ру­до­ва­ни­ем и про­бле­ма­ми уровня при­ло­же­ний. При боль­шом чис­ле за­ви­си­мо­стей меж­ду сер­ви­са­ми лю­бой из них мо­жет ока­зать­ся вре­мен­но недо­ступ- ным для сво­их по­тре­би­те­лей. В лю­бой рас­пре­де­лен­ной сре­де связь вре­мя от вре­ме­ни пре­ры­ва­ет­ся. Что ка­са­ет­ся мик­ро­сер­вис­ной си­сте­мы в це­лом, то на­ру­ше­ния свя­зи не­ред­ко про­ис­хо­дят из-за огром­но­го числа со­об­ще­ний, ко­то­ры­ми об­ме­ни­ва­ют­ся сер­ви­сы.

Что­бы све­сти к ми­ни­му­му вли­я­ние ча­стич­ных от­ка­зов, раз­ра­бот­чи­кам нуж­но со­зда­вать устой­чи­вые сер­ви­сы, спо­соб­ные эле­гант­но от­ра­ба­ты­вать от­ка­зы неко­то­рых ти­пов. На се­год­ня раз­ра­бо­тан ряд спо­со­бов изо­ля­ции от­ка­зов, пре­пят­ству­ю­щих их рас­про­стра­не­нию по всей рас­пре­де­лен­ной си­сте­ме, но нуж­ны до­пол­ни­тель­ные ис­сле­до­ва­ния в области ав­то­ма­ти­зи­ро­ван­но­го управ­ле­ния от­ка­за­ми и средств са­мо­вос­ста­нов­ле­ния, поз­во­ля­ю­щих устра­нять непо­лад­ки в си­сте­ме по­сле сбо­ев.

Ор­га­ни­за­ци­он­ная куль­ту­ра и ко­ор­ди­на­ция

На­ли­чие мно­гих ав­то­ном­ных групп, раз­ра­ба­ты­ва­ю­щих независимо раз­вер­ты­ва­е­мые сер­ви­сы, мо­жет быть ис­точ­ни­ком до­пол­ни­тель­ных слож­но­стей. На­при­мер, для про­ект­ных групп по­вы­ша­ет­ся риск уте­ри воз­мож­но­сти на­блю­дать кар­ти­ну в це­лом, то есть по­ни­мать, оправ­дан­ны ли ло­каль­ные ре­ше­ния в кон­тек­сте об­щей ар­хи­тек­ту­ры си­сте­мы и биз­нес-за­дач. Это мо­жет вы­зы­вать раз­лич­ные нега­тив­ные по­след­ствия — от внед­ре­ния ин­фра­струк­тур­ных ре­ше­ний, в ко­то­рых есть про­бле­мы со свя­зью и мно­го­крат­ным ис­поль­зо­ва­ни­ем сер­ви­сов, до фор­ми­ро­ва­ния «куль­ту­ры укло­не­ния от кон­флик­тов», ко­гда од­ним груп­пам при­хо­дит­ся ис­прав­лять про­бле­мы, от­вет­ствен­ность за ко­то­рые ле­жит на дру­гих. Что­бы из­бе­жать это­го, раз­ра­бот­чи­кам мик­ро­сер­ви­сов нуж­на бо­лее на­деж­ная ко­ор­ди­на­ция струк­тур и мо­де­лей, ко­то­рая бы не толь­ко спо­соб­ство­ва­ла ав­то­но­мии групп, но и учи­ты­ва­ла об­ще­си­стем­ные и об­щеор­га­ни­за­ци­он­ные тре­бо­ва­ния и це­ли.

В неко­то­рых ор­га­ни­за­ци­ях, на­при­мер в Netflix, ввели прак­ти­ку ре­гу­ляр­ных сов­мест­ных со­ве­ща­ний раз­лич­ных групп. В Spotify и дру­гих раз­ра­бо­та­ли ути­ли­ты, ве­ду­щие жур­на­лы ре­а­ли­зо­ван­ных сер­ви­сов и тех­но­ло­гий в цен­траль­ном ре­по­зи­то­рии. В Uber принимают ре­ше­ния о тех­но­ло­ги­ях и язы­ках про­грам­ми­ро­ва­ния вне про­ект­ных групп. Независимо от то­го, ка­кой под­ход ока­жет­ся дей­ствен­ным в кон­крет­ной ор­га­ни­за­ции, со­от­вет­ству­ю­щие за­да­чи долж­ны ре­шать­ся на уровне ор­га­ни­за­ци­он­ной куль­ту­ры, что­бы бы­ла воз­мож­ность на­ра­щи­ва­ния мас­шта­ба си­сте­мы до со­тен и ты­сяч мик­ро­сер­ви­сов.

Ре­ше­ние про­блем

Все опи­сан­ные и дру­гие про­бле­мы вполне мо­гут быть ре­ше­ны ис­сле­до­ва­те­ля­ми в об- ла­сти ин­же­не­рии ПО и си­стем. Се­год­ня в области мик­ро­сер­ви­сов дей­стви­тель­но ве­дут­ся ак­тив­ные ра­бо­ты, рас­тет чис­ло до­кла­дов, од­на­ко на прак­ти­че­ские реализации они по­чти не вли­я­ют. Ве­ро­ят­ная при­чи­на — у ис­сле­до­ва­те­лей нет до­сту­па к мик­ро­сер­вис­ным при­ло­же­ни­ям про­мыш­лен­но­го мас­шта­ба, что за­труд­ня­ет вос­про­из­ве­де­ние про­блем тех­ни­че­ско­го и иного ха­рак­те­ра, ко­то­рые про­яв­ля­ют­ся в ре­аль­ных сре­дах раз­ра­бот­ки.

Для ис­прав­ле­ния си­ту­а­ции мож­но при­бег­нуть к двум вза­им­но до­пол­ня­ю­щим друг дру­га стра­те­ги­ям. Во-пер­вых, нуж­но со­здать боль­ше сти­му­лов для со­труд­ни­че­ства ин­ду­стрии и на­уч­но­го со­об­ще­ства. Во-вто­рых, прак­ти­ки и ис­сле­до­ва­те­ли долж­ны со­здать об­щую мик­ро­сер­вис­ную ин­фра­струк­ту­ру, спо­соб­ную мак­си­маль­но точ­но имитировать ти­пич­ные ра­бо­чие сре­ды со­от­вет­ству­ю­щих при­ло­же­ний. Та­кая ин­фра­струк­ту­ра поз­во­ли­ла бы не толь­ко ре­шать про­бле­мы, воз­ни­ка­ю­щие на практике, но и ве­сти вос­про­из­во­ди­мые, ори­ен­ти­ро­ван­ные на ин­ду­стрию эм­пи­ри­че­ские ис­сле­до­ва­ния.

ЛИТЕРАТУРА 1. 2. 3. ***

Пе­ре­чис­лен­ные тех­но­ло­гии, ар­хи­тек­ту­ры и про­бле­мы мик­ро­сер­ви­сов — это лишь ма­лая часть тех­ни­че­ских, ор­га­ни­за­ци­он­ных и биз­нес-во­про­сов, ко­то­рые при­дет­ся учи­ты­вать при про­ек­ти­ро­ва­нии мас­штаб­ных мик­ро­сер­вис­ных при­ло­же­ний, рас­счи­тан­ных на ра­бо­чее при­ме­не­ние. Но сов­мест­ное ре­ше­ние опи­сан­ных про­блем ис­сле­до­ва­те­ля­ми, прак­ти­ка­ми и раз­ра­бот­чи­ка­ми ин­стру­мен­тов, бес­спор­но, необ­хо­ди­мо для даль­ней­ше­го раз­ви­тия это­го пер­спек­тив­но­го ар­хи­тек­тур­но­го под­хо­да.

O. Zimmermann. Microservices Tenets: Agile Approach to Service Development and Deployment // Computer Science — Research and Development. — 2017. Vol. 32, N. 3–4. — P. 301–310.

J. Lewis, M. Fowler. Microservices. 25 Mar. 2014. URL: martinfowler.com/articles/microservices. html (да­та об­ра­ще­ния: 10.08.2018).

N.M. Josuttis. SOA in Practice: The Art of Distributed System Design. — O´ Reilly, 2007.

Пу­ян Джам­ши­ди (pjamshid@cs.cmu.edu) — на­уч­ный со­труд­ник Уни­вер­си­те­та Кар­не­ги — Мел­ло­на, Джеймс Лью­ис (jalewis@thoughtworks.com) — глав­ный кон­суль­тант Thoughtworks, Клаус Паль (cpahl@unibz.it) — про­фес­сор Сво­бод­но­го уни­вер­си­те­та Бо­зен-боль­ца­но, На­бор Мен­дон­ча (nabor@unifor.br) — про­фес­сор Уни­вер­си­те­та Фор­та­ле­зы, Сте­фан Тил­ков (stefan.tilkov@innoq.com) — со­ос­но­ва­тель, глав­ный кон­суль­тант INNOQ.

Newspapers in Russian

Newspapers from Russia

© PressReader. All rights reserved.