Găzduire WordPress pe Google Cloud, o soluție modernă pentru profesioniști

Am scris acum ceva timp un articol despre un tip de găzduire care scalează la infinit și poate susține orice nivel de trafic.

E un stack construit de oamenii de la BitPoke, prima fază a proiectului e aproape gata, adică o soluție tehnică funcțională, fără erori. A doua fază e un dashboard atât pentru admin cât și pentru client.

Am mutat în week-end blogul meu și pe cel al soției pe un cluster cu acest stack pe care l-am creat pe Google Cloud, ca să testez, și pare a fi în regulă până acum.

Cum funcționează

Fiecare site WordPress rulează într-un container (pod), izolat complet de alte site-uri WordPress, fiecare cu resursele sale.

Un pod are alocat un nr. de PHP workers (2, 3, 10, 20 etc); cu cât are mai mulți cu atât poate să susțină mai mult trafic. Deci prima și cea simplă metodă de scalare este cea verticală, se alocă mai mulți workeri ca să țină mai mult trafic.

A doua metodă de scalare e cea orizontală – se creează un nr. de replici ale site-ului WordPress (2, 3, 20 etc) iar load balancer-ul împarte traficul între acestea.

Pentru a funcționa chestia asta cu replicarea e nevoie ca setup-ul să fie unul mai „ciudat”, în sensul că e diferit de ceea ce știm și cum lucrăm noi, proprietarii obișnuiți de site-uri.

Core-ul WordPress e managed, proprietarul site-ului nu are acces. Biblioteca media WordPress e separată de partea de cod, stă pe un bucket de pe Google Cloud Storage (poate fi și AWS S3). Baza de date rulează pe un pod diferit de pod-ul în care rulează codul PHP WordPress.

Parte de cod (folderul wp-content fără uploads) e un repository pe Github (sau Gitlab sau orice alt provider).

Modificările pe partea de cod nu se pot face din wp-admin, nu se pot instala, șterge sau modifica teme sau pluginuri. Orice modificare se face doar prin GIT.

De exemplu, actualizarea unui plugin s-ar face în felul următor.

Ai pe calculator un server local de test (eu folosesc Local) și ai acolo site-ul tău WordPress. Faci update la plugin, verifici să nu se bușească nimic, dacă e ok faci push la codul actualizat pe repository-ul din Github.

Pe baza repository-ului actualizat, stack-ul creează un nou pod cu un nou site WordPress, actualizat, în timp ce pod-ul vechi este distrus în background.

Programatorii cred că sunt familiarizați cu această metodă modernă de a face actualizări de cod, e folosită nu doar pentru site-uri și WordPress, însă pentru proprietarii obișnuiți de site-uri este o schimbare de paradigmă destul de dificil de digerat.

Dar ăsta e dezavantajul dacă se dorește ca site-ul să susțină orice nivel de trafic fără să cadă. Avantajele sunt scalabilitate ridicată, uptime ce se apropie de 100% și viteză de încărcare.

De aceea consider că soluția asta e una modernă pentru profesioniști, nu e pentru toată lumea.

Ce părere aveți de soluția asta?


Comments

14 răspunsuri

  1. Sună bine, știu că atunci când am încercat pe AWS să fac replication sau rsync sau să folosesc același codebase am întâmpinat numai probleme dar asta pare o soluție elegantă.

    Ce costuri implică și ce downsides ar avea, de exemplu load balancer-ul știe să păstreze sesiunea pe același pod, face el SSL Handshake, cât adaugă la timpii de încărcare?

    1. Avatar Andrei Chira
      Andrei Chira

      Nu știu toate detaliile tehnice în amănunt dar n-am întâmpinat probleme în teste. Eu am acum și Cloudflare în față și îmi adaugă vreo 200 ms la timpul de încărcare dar o să testez și fără, ca să văd exact timpii.

    2. Avatar Calin Don
      Calin Don

      Salut Andrei, incerc sa iti raspund la fiecare dintre puncte:

      1. Ingress-ul implicit este https://github.com/kubernetes/ingress-nginx. Se poate face session affinity setand pe obiectul ingress corespunzator anotarea `nginx.ingress.kubernetes.io/affinity: cookie`. Vezi: https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/annotations/#session-affinity

      2. Pt. ingress, sunt mai multe pod-uri de nginx care ruteaza traficul la pod-urile corespunzatoare fiecarui site. Pod-urile ingress-ului sunt sub un load balancer. Load balancer-ul de la Google, din ce stiu eu ruteaza direct pachetele spre pod-uri, deci latenta e minima. Cel de la AWS (cel clasic) din ce stiu este un fel de HAproxy, deci introduce el insusi latenta. Oricum latenta introdusa de networking, adica LoadBalancer -> Ingress -> WordPress pod e neglijabila comparativ cu timpul de randare a unei pagini in PHP.

      3. Ingress-ul de nginx face el SSL Handshake

      Referitor la costuri, acestea variaza cu nevoile si modul de deployment. Daca urmezi bunele practici (de ex. faci deploy direct din git sau iti faci imaginea ta la care ii faci deploy) atunci poti folosi masini preemptible (spot instances in limbaj AWS) care sunt de 3 ori mai ieftine.

      Din datele pe care le am, un cluster cu aprox. 3 noduri preemptible de 4 core-uri pt WordPress si 3 noduri „normale” de 2 core-uri pt. stack + db + memcached sustine un trafic de aproximativ 1000 request-uri pe secunda fara vreun fel de page cache.

    3. Badass! Mersi.

      Cam când credeți că iese din beta soluția?

    4. Avatar Andrei Chira
      Andrei Chira

      Cred că pe la finalul lui mai.

    5. OK, multumesc.

  2. Pentru ce nivel de trafic ai recomanda aceasta solutie ? (sau mai bine zis de la ce nivel trafic ?) La ce costuri se ajunge cu totul (raportat la trafic)? Eu folosesc un VPS pe care il administrez singur (o varianta mai complicata).

    1. Avatar Andrei Chira
      Andrei Chira

      Aș zice că există 2 scenarii sau tipologii de site la care s-ar preta soluția:

      1. site-uri importante (business) care vor neapărat o soluție pro de găzduire dar care nu au neapărat trafic mare.
      2. publisheri cu trafic mare sau spike-uri de trafic (ziare, reviste).

      Eu nu văd discuția neapărat despre trafic cât despre găzduire ca o fundație solidă (high-availability, high-scalability) care să nu te încurce, să poți să-ți faci business-ul fără să te gândești dacă ține sau nu serverul, fără să administrezi serverul.

      Legat de costuri, eu aș miza pe un model de pricing bazat pe trafic (ai mult, plătești mult; ai puțin, plătești puțin) am explicat în primul articol cum ar funcționa.

      E dificil de pus un preț, banda e foarte scumpă pe Google Cloud (premium tier), ar trebui integrat și un CDN, se lucrează și la asta.

      Teoretic, s-ar putea scoate și prețuri de 10-15 dolari pe lună dar mai plauzibil ar fi 30-50. Asta ar fi cu limitări de bandă și fără scalare orizontală. Dacă lăsăm la liber, să scaleze la infinit, costurile depind de consum, pe modelul Presslabs actual: un cost fix lunar + 0,10 $ / 1000 pageviews.

  3. Sună tentant

  4. Avatar Vasile R

    Interesant, dar complicat. Izolarea site-urilor o văd binevenită, căci ești sigur că nu te „omoară” vecinul. Soluții de izolare sunt și la nivel mai mic, cum ar fi EasyEngine 4 care folosește Docker. Faza cu load balancer-ul sună al naibii de bine, iar celor mega pretențioși le mai pui și un DNS Failover pe deasupra.

    1. Avatar Andrei Chira
      Andrei Chira

      E o soluție complexă, gândită pentru proprietarii de site-uri care nu se ocupă ei de tot ci au oameni (dev) care oricum nu fac update-uri direct pe live.

      O să facem și o soluție alternativă, mai clasică, unde să aibă acces clientul la fel ca în orice WP, să facă ce vrea dar nu o să mai fie scalabilă.

  5. Avatar Vasile R

    Poate e puțin off topic, dar am observat că folosești ceva pentru preload. WP Instant Links cred. Face o treabă bună, adică ai comparat cum e cu el și fără el?

    1. Avatar Andrei Chira
      Andrei Chira

      E un plugin care se cheama Tada, n-am observat diferențe, poate pe site-uri mai încărcate să aibă impact dar la mine nu.

  6. Avatar Vasile R

    Am încercat acum Tada, dar parcă mai bun e WP Instant Links cu scriptul încărcat local (nu de pe CDN). Are o opțiune pentru așa ceva. O fi mai mult pentru site-urile mari, deși pare că face preload doar la un singur script de pe pagină.

Lasă un răspuns

Adresa ta de email nu va fi publicată. Câmpurile obligatorii sunt marcate cu *