Mērogojama mākoņu infrastruktūra augošiem uzņēmumiem

Kad GRADAX sāka piedāvāt apskatāmu hostingu un mākoņa pakalpojumus, lielākā daļa klientu darbojās ar prognozējamu slodzi. Vietnē vietējam restorānam bija stabila satiksme, iespējams, neliels pieaugums brīvdienās. Grāmatveža portfeļa vietne praktiski neapgrūtināja servera resursus. Mēs rezervējām resursus piesardzīgi, un tas strādāja. Taču, pieslēdzot e-komercijas zīmoliem, SaaS sākumuzņēmumiem un mediju izdevumiem, satiksmes modeļi kļuva ārkārtīgi neparedzami.

Viens no mūsu klientiem, rumāņu modes tirgus vieta, rīkoja flash izpārdošanu, kas deva 14 reizes lielāku satiksmi nekā parasti, mazāk nekā 90 sekundēs. To iepriekšējais hostinga pakalpojumu sniedzējs nevarēja nodrošināt. Nākamajā dienā viņi vērsās pie mums ar lūgumu garantēt, ka tā vairs neatkārtosies. Šis vienīgais sarunas brīdis lika mums pārvērtēt visu infrastruktūras filozofiju. Mēs vairs nevarējām projektēt vidējo rādītāju līmenī, mums bija jāprojektē ekstremālajiem gadījumiem.

Pamatizaicinājums bija trīskāršs: apstrādāt pēkšņus satiksmes pиковus bez manuālas iejaukšanās, uzturēt saprotamas izmaksas mierīgākos periodos un saglabāt atbildes laiku zem 200 ms Eiropas un globālajiem lietotājiem. Jebkura šo problēmu atrisināšana izolēti ir vienkārša. Visu trīs vienlaicīga risināšana prasīja fundamentāli citu arhitektūru.

Pirms nonācām pie pašreizējās tehnoloģiju kaudzes, novērtējām vairākas pieejas. Pilnībā serverless arhitektūra bija vilinoša, taču tā ieviesa aukstā starta aiztures, kas pārkāpa mūsu veiktspējas prasības, it īpaši server-rendered Next.js lietojumprogrammām, uz kurām paļaujas mūsu klienti. Tradicionāla VM bāzēta konfigurācija deva mums kontroli, bet nebija elastības, kādu mums vajadzēja. Mēs izvēlējāmies hibrīda modeli: pamatpakalpojumu dedicated compute, ko papildina pēc pieprasījuma cloud server baseini, kas var tikt aktivizēti četru sekunžu laikā.

Mūsu vadības līmenis darbojas uz Kubernetes, koordinējot darbu slodzes vairākās pieejamības zonās katrā datu centra reģionā. Katra klienta lietojumprogramma ir konteinerizēta ar standartizētu darbības attēlu, kas ietver mūsu monitoringu aģentu, žurnālu forwarder un veselības pārbaudes galapunktu. Šī vienveidība ļauj realizēt automātisko mērogošanu: katrs konteiners ir savstarpēji aizvietojams, tāpēc orķestrators var pievienot vai noņemt instaces, nerūpējoties par specifiskām vides niansēm.

Datu slānim mēs pieņēmām daudzslāņu glabāšanas stratēģiju. Karstie dati atrodas uz NVMe SSD disk ar replikāciju starp divām mezgliem. Siltie dati tiek pārvietoti uz standarta SSD pēc septiņām dienām. Aukstie dati tiek arhivēti objekta glabātājā pēc trīsdesmit dienām. Tas pats par sevi samazināja mūsu glabāšanas izmaksas par 40%, nemazinot klientu veiktspēju.

Automātiskā mērogošana teorijā šķiet vienkārša: pieaugot pieprasījumam, pievieno jaudu; tam krītot, noņem to. Praksē laiks un sliekšņi ir ārkārtīgi svarīgi. Mērogojot pārāk vēlu, lietotāji saskaras ar kļūdām. Mērogojot pārāk agri, jūs iztērējat naudu par dīkstāvē esošiem resursiem. Mēs pavadījām trīs mēnešus, pielāgojot mūsu mērogošanas politikas, pirms bijām pietiekami pārliecināti, lai tās darbinātu ražošanā bez cilvēka uzraudzības.

Mūsu sistēma izmanto prognozējošu mērogošanas modeli, kas balstīts uz reakcijas triecieniem. Prognozējošais slānis analizē vēsturiskos satiksmes modeļus, nedēļas dienu, diennakts laiku, sezonas tendences un zināmus notikumus, piemēram, produktu palaišanu vai mārketinga kampaņas, kurus klienti plāno caur mūsu paneli. Tas iepriekš rezervē kapacitāti 15 minūtes pirms paredzamās pieprasījuma pieauguma. Reakcijas slānis uzrauga reāllaika metrikas: CPU izmantošanu, atmiņas spiedienu, pieprasījumu rindas dziļumu un P95 atbildes latenci. Ja jebkura metrika pārsniedz savu slieksni, jauni konteineri tiek aktivizēti daž sekundēs.

Mēs arī izveidojām pielāgotu atdzišanas mehānismu. Kad piks nokrītas, mēs nekavējoties neiznīcinām papildu kapacitāti. Tā vietā mēs to turam konfigurable logā (noklusējums: desmit minūtes), jo satiksmes piki bieži nāk vilnī. Tas novērš dārgo konteinera aktivizēšanas un deaktivizācijas ciklu atkārtotu veikšanu ilgstošu augstas satiksmes notikumu laikā, piemēram, Black Friday vai vīrusveida sociālo mediju momentus.

SLD līdzsvars GRADAX darbojas divos slāņos. Ārējais slānis ir globāls anycast tīkls, kas novirza lietotājus uz tuvāko datu centru, balstoties uz latenci, nevis tikai ģeogrāfiju. Lietotājam Minhenē var tikt novirzīts uz Frankfurti vai Amsterdamu, atkarībā no reāllaika tīkla nosacījumiem. Šis lēmums tiek pārvērtēts ik pēc sešdesmit sekundēm, izmantojot aktīvās veselības zondes, kas tiek sūtītas no katras malas atrašanās vietas.

Iekšējais slānis sadala trafiku starp konteineriem datu centrā. Mēs agri atteicāmies no vienkārša round-robin, jo tas neņem vērā konteinera veselību vai pašreizējo slodzi. Mūsu balancer izmanto svērto least-connections algoritmu, kas ņem vērā katras konteinera pašreizējo pieprasījumu skaitu, CPU izmantošanu un nesenās kļūdu procentu. Konteineri, kas cīnās, saņem mazāk pieprasījumu, dodot tiem laiku atgūties, netiekot pilnībā izņemti no rotācijas.

Mēs arī ieviesām savienojumu novirzīšanu (connection draining) maigai apturēšanai. Kad auto-scalers nolēmis noņemt konteineru, tas vispirms aptur jaunu savienojumu nosūtīšanu uz to, tad gaida līdz trīsdesmit sekundēm, lai esošie pieprasījumi pabeigtos. Tas likvidēja 502 kļūdas, kas mūs mocīja agrākajos iterācijās scale-down notikumu laikā.

Mākoņu infrastruktūra var kļūt dārga ātri, it īpaši, kad jūs veicat automātisko mērogošanu vairākās reģionos. Mēs no pirmās dienas veicām disciplinētu pieeju izmaksu pārvaldībai, uzskatot infrastruktūras izdevumus par produkta metriku tikpat svarīgu kā uptime vai latence. Katrs arhitektūras lēmums tiek pārbaudīts izmaksu ietekmes ziņā, pirms tas nonāk ražošanā.

Mūsu lielākās ietaupījumi nāca no pareizas izmēra noteikšanas. Mēs izveidojām analīzes rīku, kas parauga konteinera resursu izmantošanu četrpadsmit dienu logā un iesaka optimālu CPU un atmiņas allokāciju. Vairums klientu bija pārspilots par 30-50% saskaņā ar mūsu sākotnējiem novērtējumiem. Pēc pareizas izmēra noteikšanas mēs samazinājām pamata aprēķinu izmaksas par 35% visā flotē. Mēs arī vienojāmies par rezervētu kapacitātes līgumiem ar mūsu augšējiem sniedzējiem pamata slodzei, fiksējot cenas par 45% zemākas nekā pēc pieprasījuma cenas.

Klientiem, kuri vēlas maksimālu izmaksu efektivitāti, mēs piedāvājam "burstable" līmeni, kas darbojas uz koplietojamu infrastruktūru normālos stundās un mērogojas uz dedikētiem resursiem tikai virsotņu periodos. Šis līmenis maksā par 60% mazāk nekā mūsu standarta piedāvājums un ir ideāls uzņēmumiem ar prognozējamu zemas satiksmes periodiem, piemēram, B2B SaaS produktiem, kas redz gandrīz nevienas izmantošanas ārpus darba stundām.

Jūs nevarat pārvaldīt to, ko nevarat mērīt, un distributīvā auto-scaling sistēmā redzamība ir viss. Mēs izveidojām mūsu observability stack ap trim stabiem: metrikas, žurnāli un trases. Katrs konteiners emitē strukturētas metrikas piecu sekunžu intervālos, aptverot CPU, atmiņu, diska I/O, tīkla caurlaidspēju, pieprasījumu skaitu, kļūdu likmi un atbildes latences percentiles. Šie plūst uz laika rindu datubāzi, kas saglabā augstas izšķirtspējas datus septiņas dienas un samazinātas izšķirtspējas datus trīspadsmit mēnešus.

Distributīvā trasēšana bija daļa, kas paņēma visilgāk, lai to pareizi iegūtu, bet sniedza visvairāk vērtības. Katrs ienākošais pieprasījums saņem trace ID, kas seko tam caur load balancer, lietojumprogrammas konteineru, kešatmiņas slāni un datubāzi. Kad clients ziņo par lēnu lapu ielādi, mēs varam izvilkt precīzo trasi un redzēt precīzi, kur tika tērēts laiks. Devītas reizes no desmit, barjera ir neoptimizēta datubāzes vaicājums vai trūkstošs kešatmiņas atslēga, nevis infrastruktūra.

Mūsu brīdinājumu sistēma izmanto hierarhiskas smaguma līmeņus, kas saistīti ar biznesa ietekmi, nevis tikai tehniskajiem sliekšņiem. Apvienojumā ar mūsu website security monitoringu, viens konteiners, kas darbojas karsti, ir informatīvs. Ilgstoša kļūdu likme virs 1% visā klienta flotē ir brīdinājums. Jebkurš pieejamības kritums zem 99.9% piecu minūšu logā nekavējoties paziņo on-call inženierim. Šī pieeja samazināja brīdinājumu troksni par 70% salīdzinājumā ar mūsu sākotnējo sliekšņu bāzēto sistēmu.

Pēc osmten mēnešiem šīs arhitektūras ekspluatācijas ražošanas vidē skaitļi runā paši par sevi. Mēs uzturējām 99,97% darbības laiku visiem klientu darbu slodzes apjomiem, tostarp trīs lielās satiksmes notikumu laikā, kas katrs pārsniedza bāzes līmeņa slodzi 50 reizes. Platforma apstrādāja vairāk nekā 2,8 miljardus pieprasījumu tikai pēdējā ceturksnī, ar globālo P95 atbildes laiku 142 milisekundes. Neviens klients piedzīvoja dīkstāvi mērogošanas kļūdu dēļ.

Attiecībā uz izmaksām mūsu klienti kopumā ietaupa aptuveni 40%, salīdzinot ar ekvivalentām konfigurācijām galvenajos publiskajos mākoņpakalpojumu sniedzējos. Auto-mērogošanas sistēma pagājušajā gadā novērš aptuveni 180 000 EUR nevajadzīgu aprēķinu iztērējumu, samazinot resursus ārpus kulakstas stundām, nevis darbojoties pilnā jaudā visu diennakti. Mūsu modes tirdzniecības vietnes klientam, kura ārkārtas izpārdošana sākusi šo ceļu, mēneša infrastruktūras rēķins samazinājās par 52% pēc migrācijas uz mūsu platformu, neskatoties uz to, ka tas apstrādāja 3 reizes lielāku satiksmi nekā iepriekš.

Operatīvie uzlabojumi bija tikpat nozīmīgi. Vidējais laiks problēmu noteikšanai samazinājās no 12 minūtēm līdz mazāk nekā 90 sekundēm. Vidējais laiks risinājumam samazinājās no 45 minūtēm līdz vidēji 8 minūtēm. Mūsu infrastruktūras komanda, kas iepriekš 60% sava laika veltija reaktīvai ugunsdzēšanai, tagad 80% laika velta proaktīviem uzlabojumiem un jaunu funkciju izstrādei.

Mēs vēl neesam pabeiguši. Nākamā mūsu mākoņinfrastruktūras attīstības plāna fāze ir fokusēta uz trim jomām: malu skaitļošana (edge computing), AI vadīta kapacitātes plānošana un oglekļa apzināta grafiku veidošana. Pašlaik mēs testējam malu skaitļošanas mezglus divpadsmit papildu pilsētās, kas ļautu latentuma jutīgām slodzēm, piemēram, attēlu optimizācijai un API atbildēm, darboties tuvāk gala lietotājiem. Agrīnie rezultāti rāda 40% P99 latentuma samazinājumu lietotājiem, kas atrodas vairāk nekā 1000 kilometru attālumā no mūsu tuvākā datu centra.

AI frontē mēs trenējam kapacitātes prognozēšanas modeli, izmantojot divu gadu vēsturiskos datus par visiem klientu darbu slodzes apjomiem. Mērķis ir paredzēt satiksmes rakstus 24 stundas iepriekš ar pietiekamu pārliecību, lai rezervētu kapacitāti pirms pikiem, novēršot pat īso latentuma pieaugumu, kas rodas reaktīvā mērogošanas notikumu laikā. Sākotnējie rezultāti ir solīdi, modelim sasniedzot 89% precizitāti nākamās dienas piksatikmes prognozēs.

Visbeidzot, mēs izpētam oglekļa apzinātu grafiku veidošanu, kas pārvietotu nesteidzamas slodzes, piemēram, rezerves kopijas, partiju apstrādi un priekšapstrādi, uz laikiem, kad vietējā elektrības tīklā ir vislielākais atjaunojamās enerģijas īpatsvars. Tas atbilst mūsu plašākam saistībām pret ilgtspējīgu infrastruktūru un dod mūsu videi draudzīgiem klientiem taustāmu metriku, uz kuru viņi var atsaukties. Ja vēlaties uzzināt, kā šie uzlabojumi var dot labumu jūsu biznesam, sazinieties ar mūsu komandu. Mēs plānojam palaist visas trīs funkcijas līdz 2026. gada beigām.