WordPress ja autoscale-hosting: Mitä oikeasti skaalautuu

WordPress ja autoscale-hosting kokonaisuutena

Autoscale-hosting kuulostaa WordPress-maailmassa lähes taikasanalta. Liikenne kasvaa, infrastruktuuri skaalautuu automaattisesti ja sivusto pysyy nopeana ilman, että kukaan koskee mihinkään. Todellisuus on vähemmän maaginen ja paljon mielenkiintoisempi.

Kaikki WordPressissä ei skaalaudu samalla tavalla, eikä osa asioista skaalaudu lainkaan – riippumatta siitä, kuinka moderni hosting-alusta on. Autoscale ei poista arkkitehtuurin merkitystä. Se paljastaa sen.

Mitä autoscale-hosting oikeasti tarkoittaa

Skaalautuva infrastruktuuri, ei skaalaava sovellus

Autoscale-hosting tarkoittaa yleensä sitä, että:

• PHP-prosessien määrä kasvaa automaattisesti

• kontteja tai instansseja lisätään kuorman mukaan

• CPU- ja muistiresurssit laajenevat dynaamisesti

Tämä on infrastruktuuritason skaalautuvuutta. WordPress itsessään ei tiedä tästä mitään. Se toimii samalla tavalla yhdellä palvelimella tai sadalla.

Jos WordPressin arkkitehtuuri ei tue vaakaskaalausta, autoscale vain monistaa ongelman useammalle solmulle.

Mikä WordPressissä skaalautuu hyvin

Anonyymi liikenne + cache

Paras skaalautuvuusskenaario WordPressissä on:

• anonyymi käyttäjä

• cachettava HTML

• edge-, CDN- tai reverse proxy -cache

Tässä mallissa autoscale-hosting on usein lähes turhaa, koska:

• backend-kuorma on minimaalinen

• yksi instanssi riittää pitkälle

• suurin osa liikenteestä ei osu WordPressiin

Tämä on se tapaus, jota hosting-markkinointi rakastaa.

Staattiset resurssit

Kuvat, CSS ja JavaScript:

• skaalautuvat erinomaisesti CDN:n kautta

• eivät kuormita PHP:tä

• eivät kosketa tietokantaa

Autoscale ei ole näiden pullonkaula. Hyvä edge-verkko on.

Mikä ei skaalaudu automaattisesti

Tietokanta on lähes aina pullonkaula

WordPressin MySQL/MariaDB:

• on usein yksi instanssi

• ei skaalaudu horisontaalisesti ilman merkittävää arkkitehtuuria

• kuormittuu erityisesti kirjautuneista käyttäjistä

Autoscale voi lisätä PHP-solmuja, mutta:

• kaikki puhuvat samaa tietokantaa

• hitaat kyselyt hidastavat kaikkia

• lukitukset ja I/O rajoittavat

Tietokanta ei “autoskaalaudu” WordPressissä itsestään.

wp-admin ja kirjautuneet käyttäjät

Kirjautunut liikenne:

• ohittaa page cachen

• käyttää wp_optionsia, usermeta-taulua ja sessioita

• kuormittaa PHP:tä ja tietokantaa

Autoscale lisää kyllä PHP-kapasiteettia, mutta:

• jokainen pyyntö on edelleen raskas

• huono koodi skaalautuu huonosti nopeammin

Admin ei muutu kevyeksi lisäämällä solmuja.

Autoscale ja PHP-FPM käytännössä

Mitä oikeasti skaalautuu

PHP-FPM skaalautuu hyvin, kun:

• koodi on kevyttä

• muistivuodot ovat hallinnassa

• requestit ovat lyhyitä

Autoscale auttaa erityisesti:

• liikennepiikeissä

• burst-tyyppisessä kuormassa

• kampanjoissa ja uutispiikeissä

Mutta jos yksittäinen request kestää kauan, autoscale vain lisää rinnakkaisia hitaita prosesseja.

Mitä ei korjata autoscalella

Autoscale ei korjaa:

• hitaita SQL-kyselyitä

• wp_optionsin ylipaisumista

• raskaita cron-tehtäviä

• huonosti tehtyä custom-koodia

Se peittää oireita, ei syitä.

Object cache on autoscalen edellytys

Ilman object cachea autoscale on tehoton

Kun PHP-instansseja on useita:

• jokaisella on oma muistinsa

• ilman jaettua object cachea data ladataan toistuvasti

• wp_options ja meta-taulut kuormittuvat

Redis tai Memcached ei ole “nice to have”, vaan:

• edellytys järkevälle autoscalelle

• tapa jakaa tila solmujen välillä

Ilman object cachea autoscale kasvattaa tietokantakuormaa.

Sessioiden ja tilan hallinta

WordPress ei ole tilaton

WordPress käyttää:

• evästeitä

• käyttäjätilaa

• ajoittain PHP-sessioita (lisäosien kautta)

Autoscale-ympäristössä:

• sessiot eivät saa olla paikallisia

• tiedostopohjainen tila ei skaalaudu

• uploads-kansio vaatii jaetun tallennuksen

Jos tila on sidottu yhteen solmuun, autoscale rikkoo sovelluksen.

WooCommerce ja autoscale

Skaalautuu huonommin kuin sisältösivusto

WooCommerce:

• käyttää paljon kirjautunutta liikennettä

• tekee raskaita kyselyitä

• tarvitsee konsistenttia tilaa

Autoscale auttaa:

• tuotesivujen lukemisessa

• kampanjapiikeissä

Se ei auta:

• checkoutin pullonkauloissa

• tietokannan lukituksissa

• huonosti optimoiduissa raporteissa

WooCommerce vaatii arkkitehtuuria, ei vain lisää solmuja.

Cron ja taustatyöt autoscale-ympäristössä

Yleinen sudenkuoppa

Kun instansseja on useita:

• WP-Cron voi käynnistyä useassa solmussa

• sama tehtävä ajetaan rinnakkain

• lukitusmekanismit pettävät

Autoscale vaatii:

• keskitetyn cron-ajon

• tai ulkoisen job runnerin

Muuten taustatyöt muuttuvat arvaamattomiksi.

Milloin autoscale on oikea ratkaisu

Autoscale-hosting on järkevä, kun:

• liikenne vaihtelee voimakkaasti

• sivusto on pääosin cachettava

• object cache on käytössä

• tietokanta on optimoitu

• tila on irrotettu yksittäisestä solmusta

Ilman näitä autoscale on kallis ja tehoton ratkaisu.

Milloin autoscale on väärä ratkaisu

Autoscale ei ratkaise ongelmaa, jos:

• sivusto on jatkuvasti kuormitettu

• tietokanta on jo pullonkaula

• admin ja kirjautuneet käyttäjät dominoivat

• koodi on raskasta ja optimointia ei ole tehty

Tällöin tarvitaan:

• arkkitehtuurimuutoksia

• kyselyoptimointia

• välimuististrategiaa

Ei vain lisää instansseja.

Lopuksi: autoscale skaalaa infrastruktuuria, ei WordPressiä

Autoscale-hosting on tehokas työkalu, mutta se ei tee WordPressistä automaattisesti skaalautuvaa sovellusta. Se skaalauttaa vain sen osat, jotka on suunniteltu skaalautumaan.

WordPressissä oikeasti skaalautuvat:

• cache

• stateless PHP

• anonyymi liikenne

Ne osat, jotka eivät skaalaudu, vaativat:

• suunnittelua

• kurinalaista optimointia

• tietoista arkkitehtuuria

Autoscale ei ole oikotie. Se on suurennuslasi.