Kako izgleda uspješan DevOps sustav koji broji preko 20 milijuna korisnika?

DevOps bi u idealnom slučaju trebao besprijekorno povezati software development (Dev) i IT operations (Ops) procese. No, to ne ide uvijek glatko kako je zamišljeno, pogotovo ne u stvarnom svijetu… Lekcije i iskustva onih koji su prošli DevOps stranputice zato su neprocjenjive, a jedan DevOps inženjer podijelio je s nama svoje tajne u koordiniranju velikih sustava.

Možete se zamisliti na mjestu glavnog DevOps inženjera i voditelja tima za razvoj sustava koji broji preko 20 milijuna korisnika? Kako bi u tom slučaju riješili problem automatskog skaliranja? Kako bi radili deployment, a kako bi tek napravili taj cijeli sustav sigurnim? Upravo je za tu ključnu ulogu i ova pitanja zadužen Boris Mijač u Ars Futuri.

U detalje nam je otkrio kako su u Ars Futuri postavili DevOps za Call of Duty League.

Počnimo od generalne podjele

Kada govorimo o proizvodu kojeg koristi 20 milijuna ljudi, organizaciju i praćenje sustava možemo promatrati kao temelje kuće. Boris nam zato odmah na početku objašnjava kako izgleda orkestracija servisa i nadzor takvog sustava.

Gledajući sa strane developmenta, sustav Ars Future sastoji se od frontenda, backenda te iOS i Android mobilnih aplikacija. Većina servisa koje koriste za frontend i backend se nalazi na Amazon Web Services (AWS). Frontend dio nalazi se u docker containerima na Fargateu u sklopu ECS servisa pomoću kojeg vrše i samu orkestraciju, no više o tome kasnije.

Što se tiče nadzora sustava, tu je Amazon CloudWatch koji je spojen na sve potrebne servise i kroz njegove metrike u Ars Futuri izvlače potrebne informacije, optimiziraju sustav, definiraju alarme na koje se određene stvari trebaju događati i slično. Također koriste Datadog, a treće servise po potrebi. Važno je spomenuti i kako na AWS-u općenito koriste 20+ različitih servisa i komuniciraju s 10-ak vanjskih (third party) servisa, a dalje ćete se upoznati i s tim kako koriste neke od najbitnijih kao što su: CloudFront, ECS, API Gateway, Lambda…

Skaliranje sustava za navale igrača vikendom

Ars Futura morala je riješiti problem automatskog skaliranja jer tijekom vikenda imaju pojačano korištenje njihovih servisa na nekoliko sati, a tijekom tjedna promet je nešto manji. Kako bi riješili taj problem, frontend dio su smjestili u docker containere na Fargateu u sklopu ECS servisa jer on pruža razne opcije skaliranja, poput automatskog skaliranja resursa na točno određeni datum i vrijeme te automatskog skaliranja resursa ako dođe do neočekivanog povećanja broja korisnika. To rezultira povećanjem u korištenju memorije, CPU-a i slično:

Naravno, sve je s naše strane točno definirano politikom skaliranja pod kojim uvjetima će se određeni servis skalirati.

Ne smijemo zaboraviti kako sustav posjećuju korisnici s raznih lokacija koji se nalaze diljem svijeta pa je vrlo bitno isporučiti isti sadržaj svima, istom brzinom. To su postigli korištenjem Cloudfront content delivery network servisa:

On nam omogućuje custom cacheiranje, geografska ograničenja te sigurnosne benefite, a jedan od njih je zaštita i kontroliranje DDoS napada.

Backend izazovi

Backend dio sustava je organiziran kroz Lambda funkcije. Svaka funkcija na sebi ima uključeno nadziranje uz pomoć kojeg smo analizirali pod kojim su opterećenjem te na osnovu toga svaku od njih optimizirali, pojašnjava Boris.

Jedan od problema na koje smo naišli je duljina trajanja izvođenja određenog requesta, što povećava “concurrent executions”. Povećanjem memorije na Lambdi i boljim definiranjem cacheiranja na API gatewayima je ovaj problem riješen.

Zatim, drugi problem nastaje kada dođe do naglog povećanja invokacija na određenu Lamdba funkciju. Tada se poveća i broj uzastopnih izvršavanja, a to rezultira throtlleanjem uslijed nemogućnosti podizanja u kratkom vremenskom periodu velikog broja okruženja (environment) za izvršenje. Taj problem je riješen korištenjem provisioned concurrencyja gdje se izbjegne ta anomalija hladnog starta novih izvršnih okruženja, dodaje Boris.

Kako optimizirati troškove kad imate velike oscilacije?

Kada imamo ovako specifičnu upotrebu proizvoda u određeno vrijeme dolazimo do pitanja kako su napravili optimizaciju troškova. Prije svega, ono što je utjecalo na samu optimizaciju troškova je prebacivanje s EC2 instanci na Fargate, dobra optimizacija cacheiranja, kao i korištenje opcije autoskaliranja na Lambda provisioned concurency.

Također, u tome je pomoglo korištenje privatnih poveznica, automatsko gašenje nekih servisa na QA okruženju kada se ne koriste (primjerice izvan radnog vremena):

Uz navedeno, optimizacija korištenja memorije i CPU-a na Lambdama i smanjenje vremena izvođenja je u konačnici smanjilo sam trošak izvođenja.

Također, optimizaciji troškova je doprinijelo i korištenje nekih od planova štednje koje nudi AWS, poput Compute Cloud Plan koji nudi smanjenje troškova za određene servise i do 60%.

Deployment…

Ars Futura ima 3 razvojna okruženja, a to su Quality Assurance, Staging i Production. Na svaki od njih se deployja ovisno po potrebi i dogovoru.

Za deployanje frontenda trenutno koristimo Jenkins, ali smo u potrazi za boljim rješenjem s obzirom na use case kada je potrebno istovremeno buildanje 20-ak različitih docker imagea i deployanje istih.

Što se tiče backenda, kada se novi kod spaja u zadane brancheve, automatski se deployja putem GitHub actionsa na odgovarajući environment. Borisu je teško istaknuti dobre alate i prakse za deployment jer to najviše ovisi o specifičnosti projekta i njegovim potrebama, tako da ne možemo reći kako je neki alat loš u odnosu na drugi:

Više je riječ o rješenju koje je za nas u tom trenutku bilo najpogodnije.

Kada imamo ogroman broj korisnika onda sustav ujedno zahtijeva i sigurnost na visokoj razini. Ars Futura je sigurnost postigla implementiranjem najboljih praksi poput ove:

Primjerice, okruženja na kojima testiramo su zaštićeni firewallom kroz koji kontroliramo tko ima pristup, a implementiranjem SSO servisa smo smanjili rizik neovlaštenog pristupa.

Sadržaj koji se ne dohvaća od trećih servisa se kreira i organizira kroz ContentStack. Govorimo o content management platformi putem koje mogu definirati što od sadržaja se objavljuje i na kojem environmentu:

Svakako, s gledišta sigurnosti, jako je bitno osvijestiti i educirati ljude uključene u projekt o potencijalnim prijetnjama i rizicima.

Što Boris savjetuje u osmišljavanju uspješnih DevOps praksi?

Nakon što ste postavili moderne DevOps prakse i mikroservisne arhitekture, Boris ima za ponuditi i pokoji savjet za one koji žele napraviti slično. Potrebno je dobro proučiti zahtjeve i potrebe sustava i vidjeti je li potrebna mikroservisna arhitektura i u kojoj mjeri će doprinijeti rješavaju dosadašnjih problema:

Da bi se postigla cjelokupna transformacija, potrebno je sudjelovanje cijelog tima koji poznaje tehnološki “stack” i arhitekturu sustava, definirani vremenski period u kojem će se promjene raditi te budžet i očekivani rezultat.