Skaalauskäytännöt: Target Tracking ja Step Scaling

Staattinen desired capacity toimii kuormituksen pysyessä vakiona, mutta todellinen liikenne vaihtelee. Skaalauskäytäntöjen avulla Auto Scaling Group voi säätää desired capacity -arvoa automaattisesti mittareiden perusteella. AWS tarjoaa kolme pääasiallista dynaamista käytäntötyyppiä: Target Tracking, Step Scaling ja Simple Scaling. SAA-C03-tenttiä varten on tärkeintä ymmärtää Target Tracking ja Step Scaling.

Target Tracking Scaling toimii termostaatin tavoin: määritätte mittarin ja tavoitearvon, minkä jälkeen AWS laskee automaattisesti lisättävien tai poistettavien instanssien määrän pitääkseen mittarin tavoitearvossa. Jos esimerkiksi tavoitteena on 50 %:n keskimääräinen suorittimen käyttöaste ja käyttöaste nousee 80 prosenttiin, ASG lisää riittävästi instansseja palauttaakseen suorittimen käyttöasteen 50 prosenttiin. AWS hallinnoi sekä ulos- että sisäänskaalaustoimia puolestanne.

Target Tracking tukee valmiiksi useita ennalta määritettyjä mittareita: ASGAverageCPUUtilization, ASGAverageNetworkIn, ASGAverageNetworkOut ja ALB-kohtainen ALBRequestCountPerTarget. Sovelluskohtaisia KPI-mittareita (jonon pituus, aktiiviset yhteydet, mukautetut liiketoimintamittarit) varten voitte antaa mukautetun CloudWatch-mittarin. Mukautetut mittarit antavat paljon tarkemman hallinnan siihen, mikä ohjaa skaalauspäätöksiä.

Ulosskaalaustapahtuman jälkeen ASG odottaa jäähdytysjakson ajan (oletusarvoisesti 300 sekuntia) ennen uuden ulosskaalauksen arviointia. Tämä antaa juuri käynnistetyille instansseille aikaa alkaa käsitellä liikennettä, jotta mittari voi tasaantua. Vastaavasti sisäänskaalauksen jäähdytysjakso estää kapasiteetin lisäämistä seuraavan ennenaikaisen lopettamisen. Target Trackingissa AWS suosittelee lisäksi käynnistymisaikaa, jotta uudet instanssit eivät vääristä mittaria ennen kuin ne on alustettu kokonaan.

Step Scaling reagoi CloudWatch-hälytyksiin lisäämällä tai poistamalla tietyn määrän instansseja sen perusteella, kuinka paljon mittari ylittää kynnysarvon. Määritätte useita step adjustment -säätöjä: kukin askel kattaa tietyn mittarialueen ja määrittää kapasiteetin muutoksen. Esimerkiksi: jos suorittimen käyttöaste on 60–70 %, lisätään 1 instanssi; jos se on 70–90 %, lisätään 3 instanssia; jos se ylittää 90 %, lisätään 5 instanssia. Näin kuormitustasoihin voidaan vastata asteittain ja oikeassa suhteessa.

Step Scaling edellyttää aiemmin luotua CloudWatch-hälytystä. Hälytys valvoo mittaria ja siirtyy ALARM-tilaan, kun kynnysarvo ylittyy. Skaalauskäytäntö käyttää sen jälkeen step adjustment -säätöjä, joihin viitataan mittarin arvon ja hälytyksen kynnysarvon välisen suhteen perusteella. Voitte määrittää säätötyypiksi ChangeInCapacity (lisää N), ExactCapacity (aseta arvoksi N) tai PercentChangeInCapacity (skaalaa N prosenttia).

Jokaisella step adjustment -säädöllä on MetricIntervalLowerBound ja valinnaisesti MetricIntervalUpperBound. Rajat ovat suhteessa hälytyksen kynnysarvoon. Jos hälytyksen kynnysarvo on 60 % suorittimen käyttöastetta: LowerBound=0, UpperBound=10 käynnistyy, kun käyttöaste on 60–70 %; LowerBound=10, UpperBound=null käynnistyy, kun käyttöaste ylittää 70 %. Tämä kerroksittainen lähestymistapa varmistaa, että suuret liikennepiikit saavat heti suuren kapasiteettilisäyksen sen sijaan, että jouduttaisiin odottamaan useita hälytyssyklejä.

Simple Scaling on Step Scalingin edeltäjä. Sen tavoin se edellyttää CloudWatch-hälytystä, mutta hälytyksen lauetessa se lisää tai poistaa kiinteän määrän instansseja ja odottaa sitten koko jäähdytysjakson päättymistä ennen uutta arviointia. Tämä tekee siitä hitaan nopeasti muuttuvassa kuormituksessa. Step Scaling on suositeltava, koska se voi laueta edelleen olosuhteiden heikentyessä odottamatta koko jäähdytysjakson päättymistä ja reagoi suhteessa kuormitukseen.

Joskus haluatte estää tiettyjen instanssien lopettamisen sisäänskaalauksen aikana – esimerkiksi instanssin, jossa suoritetaan pitkään kestävää eräajoa. Voitte ottaa instanssin sisäänskaalaussuojauksen käyttöön yksittäisissä instansseissa konsolin tai CLI:n kautta. Kun ASG valitsee lopetettavia instansseja, se ohittaa suojatut instanssit. Muistakaa poistaa suojaus työn valmistuttua, sillä ASG ei ehkä pysty skaalaamaan sisäänpäin lainkaan, jos kaikki instanssit ovat suojattuja.

Voitte liittää yhteen ASG:hen useita skaalauskäytäntöjä. Kun käytössä on sekä Target Tracking- että Step Scaling -käytäntö, ASG käyttää sitä käytäntöä, joka suosittelee suurempaa ulosskaalaustoimea (varovaisempi vaihtoehto). Sisäänskaalauksessa voittaa käytäntö, joka suosittelee pienimmän instanssimäärän poistamista. Tämä estää järjestelmää vaihtelemasta liian pienen ja liian suuren kapasiteetin välillä. Yleinen malli on käyttää Target Tracking -käytäntöä normaalitilanteessa ja Step Scaling -käytäntöä suojaamaan äkillisiltä kuormituspiikeiltä.

Useimpien verkkosovellusten tapauksessa aloittakaa suorittimen käyttöasteeseen tai kohdekohtaiseen pyyntömäärään perustuvasta Target Trackingista: se vaatii vain vähän määrityksiä, ja AWS hoitaa laskennan. Käyttäkää Step Scalingia, kun tarvitsette asteittaisia ja suhteutettuja reaktioita eritasoiseen kuormitukseen. Asettakaa minimum capacity aina riittävän suureksi, jotta se käsittelee perustason liikenteen ilman ulosskaalauksen apua, sillä skaalaus vie aikaa. Valvokaa CloudWatch-mittareita GroupDesiredCapacity ja GroupInServiceInstances varmistaaksenne, että käytännöt toimivat odotetusti.

Tässä oppitunnissa opitte, että Target Tracking Scaling laskee ja toteuttaa automaattisesti ulos- ja sisäänskaalaustoimet pitääkseen mittarin halutussa arvossa (kuten suorittimen käyttöasteen 50 prosentissa), Step Scaling käynnistää suhteellisesti suurempia toimia mittarin ylittäessä korkeampia kynnysarvoja CloudWatch-hälytyksiin perustuvien step adjustment -säätöjen avulla, ja käytäntöjen yhdistäminen samaan ASG:hen on turvallista: ASG käyttää varovaisinta ulosskaalaussuositusta ja vähiten voimakasta sisäänskaalaussuositusta. Seuraavaksi tutustumme ajoitettuun ja ennakoivaan skaalaukseen tunnettujen liikennemallien yhteydessä.