Kā faktiski izveidot drošu un uzticamu AWS mākoņa arhitektūru, nezaudējot prātu

Ievads

Ja kādreiz esat mēģinājis izstrādāt mākoņa arhitektūru AWS no nulles, droši vien jau zināt, ka tas ir vienlīdz brīvs un haotisks. Ir tūkstoš veidu, kā kaut ko izveidot, un tikpat daudz veidu, kā to sabojāt.

Īss ieskats AWS dokumentācijā var likt jums domāt: "Forši, mēs vienkārši ievērosim pirmklasīgo praksi." Taču reālās starptautiskās vidēs pirmšķirīga prakse bieži vien nav pirmā saskarē ar reālām komercsabiedrības vajadzībām, cenu diapazona ierobežojumiem vai cilvēku kļūdām. Tāpēc sadarbība ar tādiem profesionāļiem kā perfsys jau pašā sākumā var novērst risku, ka vēlāk nāksies cīnīties ar aizsardzības caurumiem un sarežģījumiem, kas saistīti ar mērogošanu.

Mērķis nav tikai iegūt kaut ko, kas darbojas. Tas ir izveidot sistēmu, kas neapgāžas, kad satiksme strauji pieaug vai kāds reģions izslēdzas, un neatstāj plaši atvērtas durvis uz internetu.

Sāksim ar acīmredzamo: AWS ir briesmonis

Ar AWS var izveidot praktiski jebko. Sākot ar divu cilvēku jaunuzņēmumiem un beidzot ar plašām uzņēmumu platformām, visi pamatelementi ir pieejami - EC2, Lambda, RDS, S3, IAM, VPC un saraksts ir ļoti garš. Taču problēma ir cita. Jo vairāk iespēju, jo vieglāk ir radīt juceklīgu jucekli.

Nav tā, ka AWS ir slikti izstrādāts. Vienkārši tā ir jāprojektē pareizi. Pretējā gadījumā jūs nonāksiet pie tā, ko dažas komandas dēvē par "mākoņu spageti": savstarpēji atkarīgi pakalpojumi, grūti kodēti noslēpumi, nekāda marķēšana, nekāda reģistrēšana un absolūti nekāda priekšstata par to, kas cik maksā.

Uzticamība un drošība nav nekas patīkams.

Ir vilinoši uzskatīt drošību un uzticamību par nākotnes jūsu problēmu. "Mēs to nodrošināsim pēc tam, kad sāksim darboties." "Mēs pievienosim uzraudzību nākamajā sprintā." Bet pajautājiet ikvienam, kas ir saskāries ar datu aizsardzības pārkāpumu vai vairāku stundu pārtraukumu, - šo soļu izlaišana ir veids, kā jūs galu galā visu nakti gulēsiet mājās.

Ko patiešām nozīmē uzticamība

Runa nav par darbības laika garantijām uz diapozitīva. Runa ir par projektēšanu, kas paredz neveiksmes. Pakalpojumi nedarbojas. Diski nedarbojas. API nedarbojas. Svarīgi ir tas, vai jūsu sistēma turpina darboties, kad viss sabojājas.

Vai jums ir dublēšana visās pieejamības zonās? Vai jūsu sistēma spēj izturēt datu bāzes mezgla atteici, nezaudējot datus vai neizmetot kļūdas? Vai kritiskās slodzes tiek izmantotas vienā reģionā, jo "to bija visvieglāk izvietot"? Šie ir jautājumi, kas atdala strādājošas sistēmas no elastīgām.

Un drošība? Tā nav tikai IAM

Jā, identitātes un piekļuves pārvaldība (IAM) ir pirmā siena. Taču drošība sniedzas daudz tālāk. Publiski pieejami S3 spaiņi. Pārāk pilnvarotas lomas. Slepenības, kas stingri iekodētas Lambda funkcijās. Izslēgta pierakstīšanās, "lai ietaupītu izmaksas". Tas viss ir bumba ar laika degli.

Izmantojot aws labi izstrādātu arhitektūras sistēmu, var palīdzēt identificēt šīs problēmas, pirms tās eksplodē. Tā sadala arhitektūru piecās galvenajās jomās - drošība, uzticamība, darbības izcilība, veiktspējas efektivitāte un izmaksu optimizācija - un liek komandām godīgi izvērtēt katru no tām. Tā nav "sudraba lode", bet tā liek uzdot sarežģītus jautājumus.

Sastāvdaļas, kurām patiešām ir nozīme

Labi, ķersimies pie būtiskākās lietas. Lūk, kas ir svarīgi, veidojot drošu un uzticamu arhitektūru AWS, un kur komandas visbiežāk kļūdās.

Pareizi izmantojiet IAM lomas (jā, patiešām)

IAM lomas ir spēcīgas. Dažkārt pārāk spēcīgas. Ir pārāk viegli uzlikt "AdministratorAccess", jo kaut kas nedarbojas, apsolīt, ka vēlāk to salabosim... un pēc tam tā arī nekad to nesalabot.

Tas ir jānofiksē jau laikus. Mazāko privilēģiju princips ir ne tikai labākā prakse - tas ir vienīgais saprātīgais darbības veids. Tas nozīmē:

• Katram pakalpojumam noteiktās lomas

• Izvairīšanās no aizstājējzīmēm atļaujās

• Īslaicīgas pilnvaras

• Obligāta MFA cilvēklietotājiem

Šķiet, ka tas ir mokoši? Tā ir. Bet tas pats attiecas arī uz skaidrošanu priekšniekam, kāpēc kāds no nepareizi konfigurētas Lambda ir izfiltrējis klientu datus.

Nodaliet savu tīklu tā, kā jūs to domājat

Šī ir vēl viena joma, kurā saīsinājumi rada negatīvu rezultātu. Jums nav nepieciešama īpaši sarežģīta tīkla konfigurācija, bet daži pamatprincipi ir ļoti noderīgi:

• Publiski apakštīkli tikai tām lietām, kurām jāsaskaras ar internetu (piem., ALB).

• Privāti apakštīkli visam pārējam

• NAT vārti kontrolētai izejošai piekļuvei

• VPC galapunkti AWS pakalpojumu datplūsmai, nenonākot publiskajā internetā.

Plakans VPC ar visu vienā apakštīklā var šķist vienkāršs. Līdz brīdim, kad kaut kas sabojājas un paņem visu līdzi.

Reģistrēšana un uzraudzība: Jūs nevarat labot to, ko neredzat.

Par šo jautājumu vairs nevajadzētu diskutēt. Reģistrēšana nav obligāta. Ja jūs nefiksējat CloudTrail, CloudWatch metriku un VPC plūsmas žurnālus, jūs lidojat akli.

Bet te ir viens āķis - ar reģistrēšanu vien nepietiek. Jums patiešām ir jāpārbauda žurnāli. Izveidojiet brīdinājumus par svarīgāko. Izfiltrējiet trokšņus. Un pārliecinieties, ka žurnāli ir centralizēti visos kontos un reģionos. Sadrumstalota redzamība nav redzamība.

Šifrējiet visu (bez izņēmumiem)

Izmantojiet KMS datiem miera stāvoklī. Izmantojiet TLS tranzīta datiem. Rotējiet atslēgas. Uzraugiet piekļuvi. Šī ir viena no tām jomām, kur laiskums tagad izmaksā ļoti dārgi vēlāk.

Un neaizmirstiet par tādām lietām kā RDS šifrēšana, EBS apjoma iestatījumi un API Gateway TLS ieviešana. Šīs sīkās detaļas ir ļoti svarīgas.

Infrastruktūra kā kods vai sabrukums

Vai joprojām ievietojat, klikšķinot pa AWS konsoles logu? Tas ir labi izstrādes vajadzībām, bet bīstami pārdošanas vajadzībām.

Izmantojiet Terraform, CloudFormation vai CDK. Neatkarīgi no tā, kam jūsu komanda dod priekšroku, vienkārši izvēlieties vienu no tām un turieties pie tās. Veiciet savu veidņu versiju kontroli. Izvietošanai izmantojiet CI/CD. Automatizējiet atgriezenisko izvietošanu. Manuāla izvietošana ir atklāts aicinājums kļūdīties.

Turklāt: visu atzīmējiet. Resursi bez marķējuma ir kā kabeļi bez etiķetēm - neviens nezina, kam tie paredzēti, un visi baidās tiem pieskarties.

Mēroga palielināšana bez nogrimšanas

Būsim atklāti: AWS patīk, ja jūs pārmērīgi nodrošināt resursus. Jūs saņemat "veiktspēju", viņi saņem jūsu naudu. Lai mērogošana būtu efektīva, ir jāzina savi modeļi - un tiem jāplāno.

Izmantojiet automātiskās mērogošanas grupas, izlases gadījumus (uzmanīgi) un kešēšanas slāņus. Bet vēl svarīgāk: testējiet ar slodzi. Pēdējais, ko jūs vēlaties, ir atklāt, ka jūsu RDS instance kūst reālas datplūsmas ietekmē divas dienas pēc palaišanas.

Kad tas ir lietderīgi, rezervējiet arī jaudu. Tas ietaupa naudu un novērš negaidītas neveiksmes nodrošināšanas jomā.

Katastrofu atjaunošanas plāni nav obligāti

Kas notiek, ja reģionam nedarbojas sistēma? Ko darīt, ja jūsu primārā datubāze tiek bojāta? Ja atbilde ir "eh... mums būs problēmas", tad ir laiks pārstrādāt savu DR stratēģiju.

Tas nenozīmē identiskas infrastruktūras kopijas izveidi citā reģionā. Tas nozīmē zināt:

• Ko atjaunosiet

• Cik ilgs laiks būtu nepieciešams

• Kādi dati tiktu zaudēti (ja tādi tiktu zaudēti)

• Kas par ko ir atbildīgs avārijas pārslēgšanas laikā

Un jā - jums vajadzētu pārbaudīt savu atkopšanas plānu. Pretējā gadījumā tas ir tikai izdomājums.

Bieži sastopamie pretparaugi, no kuriem jāizvairās

Ātri izspēlēsim dažus "nē", kas parādās pārāk bieži:

• Viens liels konts visam: izmantojiet AWS Organizations. Atsevišķi prod, dev, staging utt.

• Noklusējuma VPC un drošības grupas netiek skartas: bloķējiet tās.

• Pārāk liela paļaušanās uz t2.micro instancēm "testēšanai" - tās galu galā nonāks prod.

• CloudWatch izmaksu neparedzēšana budžetā: jā, reģistrēšana maksā naudu. Neveicot reģistrēšanu, izmaksas ir lielākas.

• Piekļuves piešķiršana "vienkārši ātri salabojiet": tā vietā salabojiet savu procesu.

Pēdējie vārdi? Palieciet elastīgi un veselīgi

Mākoņu arhitektūra nav saistīta ar ideālas konfigurācijas atrašanu. Runa ir par to, lai izveidotu kaut ko elastīgu, stabilu un saprotamu ne tikai tam, kurš to ir rakstījis.

Jūs nekad neesat īsti "gatavs" - un tas ir labi. Svarīgi ir būt mērķtiecīgam. Sarežģītu jautājumu uzdošana jau sākumā. Bieža revīzija. Automatizēt, kur tas ir svarīgi. Un zināt, kad izsaukt palīdzību.

Jo, būsim godīgi - AWS ir spēcīgs, bet tajā ir arī viegli apmaldīties. Sadarbība ar pieredzējušiem inženieriem, kuri dzīvo un elpo mākoņa arhitektūru, var būt atšķirība starp "lielākoties tas darbojas" un "mēs guļam naktī".

Un to ir vērts veidot.