Hosting

Magento 2 în Kubernetes

M2 on Kubernetes

Abordarea headless Zento are un frontend PWA și un backend Magento 2. În timp ce frontend-ul PWA rulează în Lambda, backend-ul Magento 2 are nevoie de un mediu de execuție PHP capabil să ruleze o aplicație monolit cu complexitatea Magento. Pentru o imagine de ansamblu puteți începe cu Architectura Generală.

Backend-ul Magento 2 al Zento rulează într-un cluster Kubernetes folosind AWS EKS (Elastic Kubernetes Service).

Cum funcționează un hosting tradițional?

Un magazin cu hosting tradițional rulează pe un server și tot traficul către acesta este trimis la adresa IP a acelui server. Această abordare cu server dedicat are dificultăți de scalare atunci când traficul crește, iar dimensiunea sa trebuie să fie peste nivelul de trafic obișnuit, chiar și așa însă, această dimensiune de cele mai multe ori nu este suficientă în perioada de campanii. O altă problemă este legată de fiabilitate, deoarece dacă apare o problemă pe acest server dedicat, magazinul este offline; acest lucru este numit single-point-of-failure.

O soluție mai bună este un setup cu mai multe servere dedicate în spatele unui load balancer; acest setup poate scala cu noi servere când traficul crește. Deși acest setup este mai fiabil, problemele în general apar în ținerea acestor servere actualizate și sincronizate. Scalarea poate și ea să dureze timp (în general între 5 și 15 de minute pentru un setup Magento), ceea ce poate fi prea lent pentru creșteri rapide de trafic.

În concluzie, hosting-ul tradițional nu poate scala sau este lent în scalare, predispus erorilor, dificil de ținut la zi și relativ scump.

Ce este Kubernetes și cum funcționează?

Kubernetes este un serviciu de containere, ceea ce înseamnă că aplicațiile sunt împachetate în interiorul unor mici containere de Docker (te poți gândi la aceste containere ca și mini-servere care rulează aplicația oriunde sunt deployate); aceste containere se numesc pod-uri în Kubernetes și sunt deployate pe node-uri (în esență servere virtuale care rulează zeci de pod-uri).

Când o aplicație trebuie să scaleze în sus, noi pod-uri sunt pornite în câteva secunde și apoi servesc traficul crescut, iar când traficul scade, ele sunt oprite, iar resursele lor devin disponibile în node-uri. În Kubernetes, când numărul de pod-uri crește, se adaugă noi node-uri în câteva minute, iar pe acestea pot fi lansate noi pod-uri. Un alt beneficiu este că atunci când apare o versiune nouă a aplicației, sunt lansate noi pod-uri cu versiunea nouă, iar apoi sunt oprite pod-urile cu versiunea veche, totul în câteva secunde, cu zero downtime.

Acest mod elegant de hosting al unei aplicații, permite componente cu o singură responsabilitatea în locul serverelor cu multiple roluri. Împreună cu Serverless, Kubernetes este în prezent cea mai bună tehnologie de rulare a aplicațiilor.

La Zento, magazinele online sunt distribuite în mai multe node-uri de Kubernetes (servere cloud AWS) și pot scala reacționând la trafic în câteva secunde, menținând un mediu de execuție izolat și securizat. Dacă orice node are o problemă tehnică, datorită distribuirii pod-urilor, magazinele nu sunt afectate și pot lansa noi pod-uri în alte node-uri în câteva secunde.

Cum gestionează soluția Zento fișierele media?

Una dintre provocările majore de trecere a Magento de la un setup cu un singur server la un setup multi-server, sau în cazul nostru Kubernetes, este cea a fișierele media. Pe lângă codurile sursă, Magento presupune că are pe disc un folder media în care să stocheze toate imaginile de catalog și fișiere descărcabile; aceste date sunt în esență colocate cu codul aplicației, ceea ce nu este o practică bună.

Soluția general adoptată pentru această problemă este un folder media partajat între toate serverele (tehnic numit mount NFS4) astfel încât pentru Magento să fie ca și cum ar avea folderul pe discul propriu, iar datele persistă între servere. Această soluție este bună, însă poate fi lentă și predispusă la erori.

La Zento, avem o soluție mai bună: am extins componenta Magento de stocare a fișierelor pe disc, încât să scrie fișierele direct în Amazon S3, iar frontend-ul va încărca resursele direct din S3 prin CDN. Această abordare este foarte eficientă pentru pod-urile de Kubernetes care rulează Magento, care acum includ doar codul aplicației. În plus, servirea imaginilor este foarte rapidă și stabilă, S3 fiind unul dintre serviciile cele mai stabile din Internet.

Din moment ce fișierele media originale sunt stocate în S3, frontend-ul Zento le poate servi într-un format redimensionat și optimizat, utilizând funcții Serverless care fac conversia on-the-fly cu caching în S3. Poți citi mai multe detalii despre cum sunt optimizate și redimensionate imaginile în descrierea Arhitectura Generală.

Fluxul de trafic Zento pentru Magento 2

Toate vizitele către Magento sunt directate din CloudFront către un ALB (AWS Application Load Balancer); iar acesta va ruta traficul către namespace-ul EKS corespunzător, unde traficul este distribuit între pod-urile magazinului.

Zento Kubernetes Architecture

Pod-urile m2-http ale magazinului sunt responsabile pentru servirea acestor accesări, iar task-urile solicitate din background nu sunt niciodată servite de către acestea.

Cum sunt executate task-urile din background?

Magento are mai multe operațiuni solicitante care sunt executate în job-uri în background. Spre diferență de setup-ul cu servere dedicate, la Zento aceste task-uri nu sunt niciodată executate pe pod-urile care servesc trafic de la utilizatori, ci pe pod-uri speciale consumer.

Magento 2 are un sistem de cozi (queue) pentru executarea acestor job-uri: dacă se face o actualizare pe 10000 de produse, sunt create 10000 de job-uri în queue și apoi pod-urile consumer procesează job-urile unul câte unul. Kubernetes lansează mai multe pod-uri, capabile să proceseze aceste task-uri în paralel, pentru a procesa întregul queue rapid, iar după finalizare le închide.

Concluzii

Zento rulează Magento într-o infrastructură Kubernetes de ultimă generație, astfel încât magazinul tău să poată să:

  • scaleze în câteva secunde când e nevoie

  • nu aibă nici un single-point-of-failure

  • ruleze rapid și să stocheze corect fișierele media

  • execute task-uri complexe complet izolat, fără a impacta experiența utilizatorilor

  • lanseze update-uri cu zero downtime

Beneficiul pentru utilizatori este că vor avea în orice moment o experiență bună, cu un magazin care se încarcă rapid și nu are întreruperi sau încetiniri. Pentru tine ca și comerciant, asta se traduce în satisfacția utilizatorilor și o conversie crescută.

Vrei să afli mai multe detalii?

Contactează-ne

Acest site folosește cookie-uri

Folosim cookie-uri pentru a personaliza conținutul și publicitatea, pentru a oferi funcții de social media și să analizăm traficul. Partajăm informații despre utilizarea site-ului cu social media-ul nostru, publicitate și analitice parteneri, care se poate combina cu alte informații furnizate sau colectate folosind serviciile lor.