WAF-mallien soveltaminen todellisiin arkkitehtuureihin

WAF-mallien soveltaminen todellisiin arkkitehtuureihin ei ole teoreettinen harjoitus — se edellyttää kunkin suunnittelupäätöksen arviointia viiden pilarin perusteella ja perusteltujen kompromissien tekemistä. Yleinen lähtökohta on arkkitehtuurikaavio: seuratkaa käyttäjän pyynnön kulkua jokaisen komponentin läpi ja kysykää jokaisen siirtymän kohdalla, mitä tapahtuu, jos komponentti vikaantuu, mitä se maksaa ja miten se on suojattu.

Tarkastellaan perinteistä monoliittista verkkosovellusta: yhtä virtuaalikonetta, jossa verkkopalvelin ja tietokanta toimivat yhdessä julkisen IP-osoitteen takana. WAF:n pilareiden perusteella sen tulokset ovat heikot kaikissa viidessä: redundanssia ei ole (luotettavuus), tietokanta on samalla palvelimella verkkotason kanssa (tietoturva), virtuaalikone on aina käynnissä liikenteen määrästä riippumatta (kustannukset), CI/CD puuttuu (toiminnan erinomaisuus) ja käytössä on vain vertikaalinen skaalaus (suorituskyvyn tehokkuus).

Vastataksesi Luotettavuus-pilariin liittyviin vaatimuksiin hajauta verkkokerros useille eri käytettävyysalueilla sijaitseville virtuaalikoneille, varmuuskopioi tietokanta maantieteellisellä replikoinnilla toissijaiselle alueelle ja sijoita sen eteen Azure Load Balancer. Näin poistat yksittäisen vikaantumispisteen, ja sovellus pystyy jatkamaan toimintaansa alue- tai aluetason katkon aikana ilman manuaalisia toimenpiteitä.

Tietoturva-pilarin osalta erota verkkokerros ja tietokanta eri aliverkkoihin NSG-säännöillä, jotka sallivat verkkokerroksesta yhteydet vain tietokannan porttiin. Tallenna tietokannan yhteysmerkkijono kohteeseen Azure Key Vault ja käytä verkkosovelluksessa hallittua identiteettiä sen noutamiseen ajonaikana. Näin tunnistetietoja ei tarvitse kovakoodata sovelluksen koodiin tai määritystiedostoihin.

Kustannusten optimointia varten korvaa jatkuvasti käynnissä olevat virtuaalikoneet Virtual Machine Scale Set -ratkaisulla, joka vähentää instanssien määrää ruuhkahuippujen ulkopuolella. Arvioi tietokannan osalta, tuleeko hallittu PaaS-palvelu, kuten Azure SQL Database sopivalla DTU-tasolla, edullisemmaksi kuin kokonainen virtuaalikone, jossa on SQL Server. Hanki varattuja instansseja sellaiselle peruskapasiteetille, jonka tarpeen pystyt ennustamaan 12 kuukautta etukäteen.

Paranna toiminnan erinomaisuutta määrittelemällä koko infrastruktuuri Bicep- tai ARM-malleina, jotka tallennetaan versionhallintaan. Luo Azure Pipelines- tai GitHub Actions -ympäristöön CI/CD-putki, joka ottaa infrastruktuurin muutokset ja sovelluskoodin käyttöön automaattisesti. Lisää käyttöönottovaiheiden väliin tarkistuspisteet: automaattiset savutestit ja manuaalinen hyväksyntä ennen muutosten siirtymistä tuotantoon.

Suorituskyvyn tehokkuutta varten lisää tietokannan eteen Azure Cache for Redis usein luettujen kyselyiden välimuistiksi ja vähennä tietokannan kuormitusta. Ota staattiset resurssit, kuten kuvat, CSS ja JavaScript, käyttöön Azure CDN:n kautta, jotta ne voidaan tarjota käyttäjiä lähellä sijaitsevista reunasolmuista kaikkialla maailmassa. Kuormita sovellus jokaisen muutoksen jälkeen varmistaaksesi, että parannukset ovat mitattavissa.

Jokaiseen arkkitehtuurimuutokseen liittyy kompromisseja. Esimerkiksi siirtyminen usean alueen arkkitehtuuriin parantaa luotettavuutta, mutta kasvattaa kustannuksia (kaksi aluetta tarkoittaa kahta virtuaalikonetta). Redis-välimuistin lisääminen parantaa suorituskykyä, mutta lisää toiminnan monimutkaisuutta (valvottavia ja ylläpidettäviä palveluita on yksi enemmän). Hyvä arkkitehtuuridokumentaatio kirjaa nämä kompromissit selkeästi, jotta tulevat arkkitehdit ymmärtävät, miksi päätökset tehtiin.

Älkää yrittäkö saavuttaa täydellisyyttä yhdellä uudelleensuunnittelulla – tällainen lähestymistapa on kallis, riskialtis ja hidas. Ottakaa sen sijaan käyttöön iteratiivinen parannussykli: suorittakaa Well-Architected Review, tunnistakaa kolme vaikutukseltaan merkittävintä ongelmaa, korjatkaa ne, mitatkaa parannus ja toistakaa prosessi. Tämä lähestymistapa sovittaa arkkitehtuurin parannukset ketterään toimitukseen ja tekee edistymisestä näkyvää sidosryhmille jokaisessa sprintissä.

Microsoft julkaisee yleisiä työkuormamalleja varten viitearkkitehtuureja osoitteessa Azure Architecture Center. Niihin kuuluu verkkosovellusarkkitehtuureja, AKS:n mikro­palveluita, data-analytiikan putkia ja paljon muuta. Jokainen viitearkkitehtuuri on jo arvioitu WAF-pilareiden näkökulmasta, ja se sisältää kuvauksen kyseiseen malliin liittyvistä kompromisseista.

Käyttäkää Architecture Decision Records (ADR) -tietueita merkittävien arkkitehtuurivalintojen, niiden tekohetken asiayhteyden, harkittujen vaihtoehtojen ja WAF-pilareihin kohdistuvien vaikutusten dokumentointiin. Versionhallintaan koodikannan yhteyteen tallennetut ADR:t muodostavat tarkastettavan historian, jonka avulla uudet tiimin jäsenet ymmärtävät, miksi arkkitehtuuri on nykyisen kaltainen.

Tässä oppitunnissa opit, että WAF-malleja sovelletaan arvioimalla jokainen arkkitehtuuripäätös kaikkien viiden pilarin näkökulmasta, parannuksia voidaan tehdä iteratiivisesti aloittamalla vaikutukseltaan merkittävimmistä ongelmista ja kompromissit on dokumentoitava, jotta tulevat arkkitehdit ymmärtävät päätösten perustelut. Seuraavaksi tutustumme Azure-SLA-sopimuksiin ja yhdistelmä-SLA-sopimusten laskemiseen usean palvelun arkkitehtuureissa.