Monoliitrakenduselt mikroteenuste arhitektuurile üleminekul seisame silmitsi uute väljakutsetega.

Monoliitrakenduses on tavaliselt piisav lihtsalt määrata, millises süsteemi osas viga esines. Tõenäoliselt on probleem monoliidi enda koodis või andmebaasis. Kuid kui hakkame otsima probleemi mikroteenuste arhitektuuris, pole kõik enam nii selge. Peame leidma terve tee, mille meediasisend läbis algusest lõpuni, eraldama selle sadade mikroteenuste seast. Paljudel neist on ka oma andmehoidlad, kus võivad tekkida nii loogilised vead kui ka probleemid jõudluse ja usaldusväärsusega.

Otsisin pikka aega tööriista, mis aitaks selliste probleemidega toime tulla (kirjutasin sellest Habrisse: 1, 2), kuid lõpuks tegin oma avatud lähtekoodiga lahenduse. Artiklis räägin teenuste võrgustiku lähenemise eelistest ja jagan uut tööriista selle rakendamiseks.

Jaotatud jälgimine on levinud lahendus vigade leidmise probleemile jaotatud süsteemides. Kuid mida teha, kui süsteemis ei ole veel sellist lähenemist võrgusuhete teabe kogumisele rakendatud, või veel hullem, kui see töötab osaliselt, aga teistes osades mitte, kuna see ei ole vanades teenustes lisatud? Probleemi täpse juurpõhjuseni jõudmiseks on oluline omada täielikku ülevaadet süsteemis toimuva kohta. Eriti oluline on mõista, millised mikroteenusest osalevad äri jaoks kriitilistes teeotsades.

Siin võib meile abiks tulla teenuse mesh lähenemine, mis tegeleb kogu võrguteabe kogumise masinavärgiga madalamal tasemel, kui töötavad ise teenused. See lähenemine võimaldab meil kogu liiklust salvestada ja reaalajas analüüsida. Lisaks ei pea rakendused selle kohta isegi midagi teadma.

Teenuse mesh lähenemine

Service mesh lähenemise põhijõud on lisada veel üks infrastruktuuritase võrgu kohale, mis võimaldab meil teha kõike vaheteenuste suhtluses. Enamik rakendusi töötab järgmiselt: iga mikroteenusest lisatakse täiendav sidecar konteiner läbipaistva proksiga, mille kaudu suunatakse kogu teenuse sisene ja väljuv liiklus. Ja just siin on koht, kus saame teha kliendipoolset tasakaalustamist, rakendada turvapoliitikaid, kehtestada piirangud päringute arvu osas ning koguda olulist teavet teenuste vahelisest suhtlusest tootmisreeglites.

Lahendused

Selle lähenemise mitmed rakendused on juba olemas: Istio ja linkerd2. Need to adjust the balance between functionality and resource consumption. While the extensive features provide great value out of the box, they also bring significant resource overhead. The larger the cluster running this system, the more resources you need to maintain the new infrastructure. At Avito, we operate Kubernetes clusters housing thousands of service instances, and this number is rapidly growing. In the current implementation, Istio consumes approximately 300MB of RAM per service instance. Due to the wide range of functionalities, transparent load balancing also impacts the overall response time of services, reaching up to 10ms.

As a result, we assessed our immediate needs and concluded that the primary reason for implementing such solutions was the ability to gather tracing information transparently across the entire system. We also wanted control over the interactions between services and the ability to manipulate headers transmitted between them.

Ultimately, we arrived at our solution:  Netramesh.

Netramesh

Netramesh — see on kerge service mesh lahendus, mis võimaldab piiramatu skaleerimist sõltumata süsteemis olevate teenuste arvust.

Uue lahenduse peamisteks eesmärkideks olid madal ressursi ülejäänud ja kõrge jõudlus. Peamistest omadustest soovisime kohe võimalust läbipaistvalt edastada tracing span'e meie Jaeger süsteemi.

Täna rakendatakse enamik pilvelahendusi Golangis. Ja loomulikult on sellel omad põhjused. Golangis võrguühendusi kirjutamine, mis töötavad asünkroonselt sisendi-tingimusena ja skaleeruvad vastavalt vajadusele tuumadele, on mugav ja piisavalt lihtne. Ja mis samuti väga oluline, jõudlus on piisav selle ülesande täitmiseks. Seetõttu valisime ka Golangi.

Tootlikkus

Keskendume oma jõudlustega maksimaalse jõudluse saavutamisele. Lahendusele, mis paigaldatakse igas teenuse eksemplaris, on vajalik väike mälu ja protsessorite aeg. Ja loomulikult peab ka vastuse viivitus olema väike.

Vaatame, millised on tulemused.

RAM

Netramesh tarbib ~10Mb ilma liikluseta ja kuni 50Mb maksimaalselt 10000 RPS koormusel ühe instantsi kohta.

Istio envoy proxy tarbib alati ~300Mb meie klastrites, kus on tuhandeid instantsse. See ei võimalda sellel skaleeruda kogu klastrile.

Netrameshiga oleme saavutanud mälu tarbimise vähenemise umbes 10 korda.

CPU

CPU kasutamine on koormuse korral suures osas ühtlane. See sõltub sidecarile suunatud päringute arvust ajas. Arvud 3000 päringu sekundi tipul:

On veel üks oluline aspekt: Netramesh on lahendus ilma control plane'ita ja ilma koormuseta ei tarbi see protsessoriaega. Istio sidecar'id uuendavad alati teenuste lõpp-punkte. Tulemusena näeme sellist pilti ilma koormuseta:

Kasutame teenuste vahel suhtlemiseks HTTP/1. Istio vastuse aeg envoy kaudu edasi suunamisel kasvas kuni 5-10ms, mis on piisavalt palju teenuste jaoks, mis on valmis vastama millisekundi jooksul. Netrameshiga vähendati seda aega 0.5-2ms.

Skaleeritavus

Väike ressursside kogus, mida iga proxie kasutab, võimaldab seda paigutada iga teenuse lähedale. Netramesh on loodud ilma control plane komponendita, et hoida iga sidecar'i kerge. Tihti teenuse mesh'i lahendustes jagab control plane teenuse avastamise teavet igasse sidecar'i. Koos sellega tuleb ka teave timeout'ide ja koormuse tasakaalustamise seadete kohta. Kõik see võimaldab teha palju kasulikke asju, kuid kahjuks paisutab see sidecar'e suuruses.

Teenuse avastamine

Netramesh ei lisa mingeid täiendavaid mehhanisme teenuse avastamiseks. Kogu liiklus suunatakse läbipaistvalt netra sidecar'i kaudu.

Netramesh toetab HTTP/1 rakendusprotokolli. Selle määratlemiseks kasutatakse konfigureeritavat portide nimekirja. Tavaliselt on süsteemis mitu porti, mille kaudu toimub HTTP suhtlemine. Näiteks meie süsteemis kasutame teenuste ja väliste päringute suhtlemiseks 80, 8890 ja 8080. Sellisel juhul saab neid määrata keskkonna muutujaga. NETRA_HTTP_PORTS.

Kui kasutate Kubernetes't orkestreerijana ja tema Service mehhanismi teenustevaheliseks suhtlemiseks klastris, siis mehhanism jääb täpselt samaks. Esiteks saab mikroteenus teenuse IP-aadressi kube-dns'i kaudu ja avab sellele uue ühenduse. See ühendus luuakse kõigepealt kohaliku netra-sidecar'iga ja kõik TCP paketid jõuavad algselt just netrasse. Järgmiseks loob netra-sidecar ühenduse algse sihtkohaga. NAT pod IP-l sõlmes jääb samaks nagu netra puudumisel.

Jaotatud jälgimine ja konteksti edastamine

Netramesh pakub funktsionaalsust, mis on vajalik jälgimise span'ide saatmiseks HTTP suhtlemise kohta. Netra-sidecar parsink HTTP protokolli, mõõdab päringute latentsust, saadab vajalikku teavet HTTP päistest. Lõppkokkuvõttes saame kõik jälgimised ühte Jaegeri süsteemi. Täiendava seadistuse jaoks saab kasutada ka keskkonnamuutujaid, mida pakub ametlik teek. jaeger go library.

Aga probleem on. Kuni teenused ei genereeri ja edasta spetsiaalset uber päist, ei näe me ühendatud jälgimis span'e süsteemis. See on see, mida vajame probleemide kiireks leidmiseks. Siin pakub Netramesh jälle lahenduse. Proxy loevad HTTP päiseid ning kui seal pole uber trace id, genereerivad nad selle. Netramesh salvestab ka teabe sissetulevate ja väljaminevate päringute kohta sidecar'is ning seob need koos vajalike päiste rikastamise teel väljaminevatele päringutele. Kõik, mida teenustes teha tuleb, on edastada üks päis X-Request-Id, mida saab konfigureerida keskkonnamuutuja abil NETRA_HTTP_REQUEST_ID_HEADER_NAME. Netrameshi konteksti suuruse haldamiseks saab määrata järgmised keskkonnamuutujad: NETRA_TRACING_CONTEXT_EXPIRATION_MILLISECONDS (aeg, mille jooksul konteksti säilitatakse) ja NETRA_TRACING_CONTEXT_CLEANUP_INTERVAL (konteksti puhastamise sagedus).

Samuti on võimalik kombineerida mitmeid teid teie süsteemis, märgistades need spetsiaalse seansimarkeriga. Netra võimaldab seada HTTP_HEADER_TAG_MAP HTTP-pealkirjade teisendamine vastavatesse jälgimisükste tagideks. See võib olla eriti kasulik testimiseks. Pärast funktsionaalsuse testi läbimist on võimalik vaadata, milline osa süsteemist oli mõjutatud, filtreerides vastava session võtme järgi.

Päringu allika määratlemine

Päringu päritolu määramiseks saab kasutada automaatse päise lisamise funktsionaalsust. Keskkonnamuutuja abil NETRA_HTTP_X_SOURCE_HEADER_NAME on võimalik määrata päise nimi, mis seatakse automaatselt. Kasutades NETRA_HTTP_X_SOURCE_VALUE saab määrata väärtuse, millega X-Source päis seatakse kõigile väljaminevatele päringutele.

See võimaldab ühtlaselt kogu võrgus selle kasuliku päise levitamist. Edasi saab seda kasutada teenustes ja lisada logidesse, metrikatesse.

Liikluse juhtimine ja Netrameshi sisemused

Netramesh koosneb kahest peamisest komponendist. Esimene, netra-init, seadistab võrgureeglid liikluse püüdmiseks. See kasutab iptables redirect reegleid Kogu või osa liikluse püüdmiseks sidecar'is, mis on Netrameshi teine peamine komponent. Saate seadistada, milliseid portte soovite püüda sissetulevatesse ja väljuvatesse TCP sessioonidesse: SISSETULEVAD_PÜÜDURI_PORTID, VÄLJUTELEVAD_PÜÜDURI_PORTID.

Samuti on tööriistas huvitav võimalus - tõenäosuspõhine marsruutimine. Kui kasutada Netrameshi ainult jälgimisandmete kogumiseks, saab tootmisikeskkonnas ressursse kokku hoida ja lubada tõenäosuspõhise marsruutimise abil muutujaid NETRA_SISSEST_PROBABILITEET ja NETRA_VÄLJUTELEV_PROBABILITEET (0 kuni 1). Vaikimisi väärtus on 1 (püüab kogu liikluse).

Pärast edukat püüdmist võtab netra sidecar uue ühenduse ja kasutab SO_ORIGINAL_DST socketi valikut, et saada algne sihtkoht. Seejärel avab Netra uue ühenduse algse IP-aadressiga ja loob kahepoolse TCP-ühenduse osaliste vahel, kuulates kogu läbiva liikluse. Kui port on määratud kui HTTP, püüab Netra seda analüüsida ja jälgida. Kui HTTP analüüs ebaõnnestub, järgneb Netra TCP-le ja sujuvalt edastab baite.

Sõltuvuste graafi koostamine

Pärast suurt hulka jälgimisteabe saamist Jaegeris, tahaks saada täielikku süsteemi suhtlemise graafikut. Kuid kui teie süsteem on piisavalt koormatud ja päeva jooksul koguneb miljardeid jälgimise spanne, muutub nende kogumine mitte nii lihtsaks ülesandeks. On ametlik viis selleks: spark-dependencies. Sellegipoolest võtab see tunde, et koostada täielik graaf ja sunnib alla laadima Jaegerist kogu andmestiku viimase 24 tunni jooksul.

Kui kasutate jälgimispannide salvestamiseks Elasticsearchi, saate kasutada lihtsat tööriista Golangis, mis koostab sarnase graafi minutitega, kasutades Elasticsearchi omadusi ja võimalusi.

Kuidas kasutada Netrameshi

Netrat saab lihtsalt lisada igale teenusele, mis töötab mis tahes orkestreerija all. Saate vaadata näidet siin.

Praegu ei ole Netratel automaatset sidecar'i teenustele integreerimise võimalust, kuid see on plaanis.

Netrameshi tulevik

Peamine eesmärk Netramesh on saavutada madalad ressursikulud ja kõrge jõudlus, pakkudes põhivõimalusi jälgimise ja teenustevahelise suhtluse kontrollimise jaoks.

Tulevikus saab Netramesh toetada ka muid rakendustasandi protokolle peale HTTP. Peagi lisandub L7 suunamine.

Kasutage Netramesh'i, kui olete sarnaste probleemidega silmitsi, ning saatke meile oma küsimused ja ettepanekud.

Allikas: habr.com