Colțul inginerilor: Trecerea lui Xactly la Chrome Headless

Aceasta este o postare pe blog pentru invitați de la Xactly Software Engineer, Anvesh Checka. Rămâneți la curent cu viitoarele bloguri de la echipa Xactly Engineering!

Un document de plan este un document legal între o companie și reprezentanții săi de vânzări, utilizat pentru urmărirea progresului. Planificați documentele în cadrul Xactly eDocs & Approvals atât simplifică procesele, cât și mărește flexibilitatea, deoarece documentele trec fără probleme prin diverse canale din organizația dvs.

Ori de câte ori un reprezentant de vânzări solicită un document de plan, documentul este formatat de Serviciul PDF Generator utilizând marcajul HTML pe care îl primește de la Serviciul Headless Browser.

Xactly a trecut recent de la PhantomJS la Headless Chrome pentru a genera conținut pentru documentele de plan în fluxurile de lucru Xactly DocuSign. Comutatorul ne-a ajutat să continuăm să construim un sistem fiabil, cu câștiguri semnificative de performanță și stabilitate.

Acest articol va acoperi:

• Ce a inspirat această tranziție
• Provocări cu care se confruntă în timpul procesului
• Cum echipa de ingineri Xactly a atins acest obiectiv

Un pic de fundal

La Xactly, rulăm automatizări pe mașini la distanță cu sarcini de lucru cu date de producție. În acest proces, am făcut în mod conștient o serie de modificări care au condus la provocări de întreținere, cum ar fi un consum mai mare de memorie, o viteză mai mică de procesare, blocări intermitente și invalidări ale memoriei cache.

Având la îndemână mai multă putere de calcul, a existat o explozie de capabilități tehnice cu ceea ce pot face computerele de astăzi.

PhantomJS a devenit un element de bază în fluxul nostru de lucru, cu toate acestea, PhantomJS și alte browsere fără cap nu s-au dezvoltat în același ritm cu ecosistemele front-end de-a lungul anilor. Folosind ES6/7/8, lucrătorii web și service, API-urile native și specifice browserului, shadow DOM și alte caracteristici și-au adăugat propriul set de provocări. Stabilitatea este și ea o preocupare majoră.

Când sfârșitul vieții PhantomJS a fost anunțat, coincizând cu sosirea Headless Chrome, a fost o binecuvântare deghizată pentru echipa de ingineri Xactly. Am început să rulăm mai multe PoC (Proof of Concepts) pentru a-i evalua caracteristicile, pentru a-i monitoriza stabilitatea și performanța și pentru a-i verifica compatibilitatea cu setul de caracteristici ale produsului.

Am observat că Headless Chrome este extrem de rapid (având suficient hardware), stabil și, la fel de important, prietenos cu dezvoltatorii. Aceste motive au fost suficiente pentru ca noi să dăm comutatorul.

Cum am reușit asta?

Ca parte a inițiativei noastre de inginerie a fiabilității, am lansat noua implementare în aproximativ două luni (inclusiv testare amănunțită).

În acest proces, am elaborat o listă de verificare a celor mai importante lucruri de luat în considerare legate de infrastructură. Aceste considerații includ:

• Hardware
• Compatibilitate software cu sistemul de operare
• Configurarea mașinii
• Creați și implementați fluxuri de lucru și scripturi
• Crons
• Descoperirea serviciului
• Controale de sănătate
• Monitorizarea securității
• Monitorizare server
• Sandboxing (acolo unde este necesar)

Monolitul nostru PhantomJS a fost convertit într-un serviciu independent care rulează Headless Chrome, cu mai multe instanțe ale serviciului scalate orizontal pe mai multe mașini multi-core cu HAProxy.

Pe fiecare mașină, o aplicație NodeJS este scalată vertical prin gruparea instanțelor nodurilor și echilibrarea încărcăturii folosind PM2. De asemenea, am folosit Puppeteer ca client API de facto pentru a vorbi cu Chromium. În prezent, colectăm toate jurnalele într-un fișier local de pe computer, dar intenționăm să migrăm către ELK (Elastic, Logstash, Kibana) în viitor.

Cu fiecare solicitare, serviciul nod atinge un punct final intern și generează codul HTML necesar pentru parametrii solicitați. Ulterior, aceasta este transmisă unui serviciu de generator PDF care generează documente PDF personalizate.

Cache rece și sesiuni Pristine

Este important să nu sacrificați niciodată securitatea pentru performanță. Fiecare solicitare este rulată fără cache partajată și într-o nouă instanță Chromium. Aceste instanțe nu sunt reutilizate pentru a crea file. Acest lucru elimină șansa de a partaja date între două instanțe Chromium la procesarea codului HTML, evitând astfel accesul accidental la datele între afaceri.

Taxa generală de creare și distrugere a proceselor Chromium pentru fiecare solicitare primită impune o penalizare de performanță, dar am acceptat acest compromis în numele securității. Acest lucru este ușor de rezolvat folosind hardware mai capabil.

Idei sumare

Am reușit să colectăm câteva statistici de bază și alte informații despre implementarea noastră, care includ următoarele:

• Timpul de generare a conținutului pentru un singur document variază între 4 și 10 secunde, în funcție de dimensiunea documentului.
• În ciuda faptului că creează o nouă instanță de browser pentru fiecare solicitare, o mașină cu 8 nuclee este de obicei capabilă să genereze peste 8000 de documente în mai puțin de o oră. Acest lucru nu a fost niciodată posibil folosind PhantomJS.
• În timpul testelor noastre de sarcină, am observat următoarele:
  • Rularea a aproximativ 35 de instanțe de browser active este ideală. Orice lucru care este semnificativ peste acest număr degradează performanța din cauza supraîncărcării procesului. Pentru a menține lucrurile mai departe sub control, am implementat mecanisme de așteptare.
• Fără să stăm la coadă, am întâlnit probleme legate de memorie și fire maxime. În aceste cazuri, am observat o creștere a numărului de procese fantomă Chrome, care trebuiau eliminate folosind un cronjob la intervale regulate.
• În cazul în care cererea primită durează prea mult pentru a se finaliza sau nu reușește din cauza unei erori interne, încercăm mai multe încercări pe baza unei setări preconfigurate.
• Am mutat setări precum expirarea timpului API, reîncercări, prag și multe altele în fișierele de configurare externe.
• Toate datele de analiză a valorilor sunt transmise către un sistem intern, intern. În cazul în care nu aveți o implementare internă, puteți utiliza aplicația Keymetrics.

Ce urmeaza

Sistemul nostru continuă să evolueze cu îmbunătățiri planificate și alte îmbunătățiri, inclusiv următoarele:

• Analiza jurnalului structurat prin ELK
• Monitorizare îmbunătățită
• Fiabilitate și performanță îmbunătățite

Despre autor

Numele meu este Anvesh Checka și lucrez ca inginer software cu echipa de produse la Xactly. Îmi place să construiesc interfețe de utilizator și aplicații web cu diverse sisteme. Dacă aveți întrebări sau comentarii, nu ezitați să scrieți pe Twitter sau să-mi trimiteți un mesaj.