Aplicații strălucitoare la prețuri accesibile pentru 500 de utilizatori concurenti

Furnizorii de cloud nu mai oferă doar servere tradiționale X86, serverele bazate pe ARM devin acum o alternativă serioasă. Și dintr-un motiv întemeiat: adesea sunt mult mai rentabili și eficienți în putere decât omologii lor x86. De exemplu, am găsit un furnizor care oferă un server cu 16 nuclee virtuale și 32 GB RAM pentru doar 30 de euro pe lună. Pentru a fi realist, majoritatea furnizorilor percep între 100 și 200 € pe lună pentru un astfel de server. Aceste servere mai scumpe au de obicei mai puțini clienți pe un singur server, îmbunătățind performanța din viața reală. În această postare, vom pune la încercare unul dintre aceste servere ARM favorabile bugetului. Desigur, rezultate similare pot fi obținute cu un server Intel sau AMD. Obiectivul este de a stabili un mediu strălucitor de producție, conceput pentru a găzdui o singură aplicație publică și să vezi câți utilizatori concurenti se poate descurca în mod realist. (Și da, titlul probabil oferă deja un indiciu!).

Deși acest post se concentrează pe un caz de utilizare specific, aceleași principii se aplică și atunci când rulează mai multe aplicații cu autentificare.

Selectarea serverului

Primul pas este să alegeți un furnizor de cloud și să comandați un server. Alegeți un centru de date care se află aproape de utilizatorii finali pentru a minimiza latența și a îmbunătăți performanța. Majoritatea furnizorilor vă permit, de asemenea, să vă redimensionați serverul mai târziu adăugând mai mult CPU sau RAM, astfel încât să puteți începe mici și să vă extindeți pe măsură ce cererea crește. Asigurați -vă că serverul vine cu o adresă IP publică, deoarece nu este nevoie de un echilibrator de încărcare în această configurație.

Când vine vorba de sistemul de operare, puteți utiliza orice distribuție Linux pe care o preferați. În acest tutorial, vom folosi Ubuntu 24.04. Odată ce serverul dvs. este furnizat, următorul pas este să vă conectați prin SSH. De obicei, furnizorul dvs. de cloud oferă documentație care explică cum să faceți acest lucru.

Ca o condiție prealabilă finală, veți avea nevoie de un nume de domeniu. Acest lucru face mai ușor accesul serverului dvs. folosind o adresă prietenoasă pentru om și este, de asemenea, necesară pentru configurarea TLS. Puteți utiliza fie un domeniu rădăcină (de exemplu example.com) sau un subdomeniu (de exemplu shinyproxy.example.com) În setările DNS ale domeniului dvs., creați o înregistrare A care indică domeniul sau subdomeniul către adresa IP publică a serverului dvs.

Instalare

Cu serverul în funcțiune, următorul pas este instalarea operatorului ShinyProxy. Acest instrument are grijă de procesul de instalare shinyproxy, precum și de toate componentele laterale necesare, astfel încât nu trebuie să le gestionați manual. Pentru instrucțiuni detaliate, urmați documentația oficială. Pentru cea mai bună configurație, asigurați -vă că activați TLS și stiva de monitorizare. În acest moment, ar trebui să vă puteți autentifica și să începeți aplicația demo.

Inspectarea consumului de resurse al aplicației

Cu shinyproxy implementat, puteți implementa aplicația dvs. Încă o dată, documentația conține tot ce trebuie să știți. Pentru a menține lucrurile simple, puteți construi imaginea Docker pe server. De exemplu, clonați depozitul Git cu tot codul dvs. de pe server și construiți imaginea folosind Docker. În acest fel, nu aveți nevoie de un registru de containere. După ce ați adăugat aplicația la configurația ShinyProxy, o puteți începe prin ShinyProxy. Pentru a ști câți utilizatori concurenti sunt acceptați de server, este bine să aruncați mai întâi o privire asupra resurselor consumate de aplicație. Porniți aplicația, efectuați câteva acțiuni ale utilizatorului și rulați următoarea comandă:

sudo docker stats

Ieșirea va fi similară:

Ultima linie din captura de ecran arată containerul care rulează aplicația noastră strălucitoare. Folosește aproximativ 125 MIB de RAM și foarte puțin timp de procesor. Rețineți că lucrăm cu o mică aplicație demo, utilizarea procesorului va crește dacă aplicația dvs. procesează mai multe date sau efectuează calcule mai grele. Majoritatea aplicațiilor strălucitoare folosesc de obicei mai puțin de 500 MIB de RAM, dar unele pot consuma mai multe gigabyte, în special atunci când încărcați seturi de date mari. Pentru a menține exemplul nostru realist, vom presupune că fiecare aplicație necesită 500 MIB de RAM. Celelalte componente ale sistemului (inclusiv ShinyProxy) consumă și o anumită memorie. În captura de ecran, acestea consumă aproximativ 1,5 gib. Shinyproxy necesită, în general, până la 2 gib de RAM. Pentru a evita degradarea performanței serverului, este o practică bună să lăsați câteva gigabyte. Pentru această configurație, vom rezerva 4 GIB pentru ShinyProxy și serverul în sine, lăsând 28 GIB disponibile pentru containerele strălucitoare. Cu fiecare recipient folosind 0,5 GIB, acest lucru ne permite să rulăm concomitent până la 56 de containere.

Optimizarea configurației

Inițial, ShinyProxy a creat un nou container pentru fiecare utilizator. Deși această abordare este simplă și îmbunătățește securitatea, nu este ideal pentru găzduirea unei aplicații publice cu mulți utilizatori. Din fericire, încă de ceva timp, ShinyProxy are un sprijin excelent pentru ceea ce numim pre-inițializare și schimb de containere. Cu această caracteristică, un singur container poate servi mai mulți utilizatori simultan. Deoarece containerele sunt pre-inițializate, timpii de încărcare sunt minime. Cu toate acestea, fiecare container strălucitor are încă o limită pentru numărul de utilizatori pe care îi poate gestiona. Pentru tablouri de bord simple, vă puteți aștepta de obicei aproximativ 20 de utilizatori concurenti pe container. În exemplul nostru, vom presupune 10 utilizatori concurenti pe container. Având în vedere cele 56 de containere ale noastre, această configurație permite serverului să se ocupe de până la 560 de utilizatori concurenti. Pentru a rămâne pe partea sigură și pentru a evita supraîncărcarea serverului, vom rotunji acest lucru până la 500 de utilizatori concurenti.

Având în vedere aceste numere, este timpul să ajustați configurația. Să începem cu configurația aplicației.

proxy:
specs:
- id: my-app
container-image: openanalytics/shinyproxy-demo
seats-per-container: 10
max-total-instances: 500
minimum-seats-available: 500

seats-per-container: 10 Setarea spune ShinyProxy că fiecare container poate gestiona 10 utilizatori sau „scaune”. Pentru a preveni supraîncărcarea serverului, limităm numărul total de utilizatori concurenti la 500 cu max-total-instances: 500
setare. Dacă mai mult de 500 de utilizatori încearcă să acceseze aplicația în același timp, vor vedea un mesaj care indică faptul că nu este disponibilă suficientă capacitate. În plus, The
minimum-seats-available: 500 Setarea asigură că ShinyProxy pre-creează 50 de containere și le menține în funcțiune, astfel încât utilizatorii să poată porni aplicația imediat fără a aștepta inițializarea containerelor.

În acest exemplu, am estimat numărul maxim de utilizatori concurenti și am limitat serverul la acea valoare. Deoarece implementăm o singură aplicație, are sens să creăm toate containerele la pornire. Cu toate acestea, dacă găzduiești mai multe aplicații pe un singur server (pe care ShinyProxy îl acceptă pe deplin), este mai bine să începi cu doar câteva containere pe aplicație. ShinyProxy creează automat noi containere pe măsură ce utilizatorii încep să acceseze aplicațiile, asigurându -se că resursele sunt utilizate eficient.

În timp ce actualizați configurația ShinyProxy, adăugați (sau actualizați) și următoarele setări:

proxy:
hide-navbar: true
landing-page: SingleApp
authentication: none
# ...
memory-limit: 2Gi

Prima proprietate ascunde ShinyProxy Navbar, care este adesea inutilă atunci când găzduiește o singură aplicație publică. Prin setare landing-page: SingleApputilizatorii sunt redirecționați automat către aplicație atunci când vizitează pagina de destinație. Deoarece aceasta este o aplicație publică, dezactivați și autentificarea. În cele din urmă, limităm memoria pe care ShinyProxy o poate folosi pentru a ne asigura că există întotdeauna suficientă RAM disponibilă pentru aplicațiile strălucitoare.

După actualizarea configurației, operatorul creează o nouă instanță ShinyProxy cu setările actualizate. Acest proces durează de obicei câteva minute. S -ar putea să vedeți o pagină „interzisă” dacă v -ați conectat anterior să utilizați un nume de utilizator și o parolă. Acest lucru se întâmplă doar o dată când treceți de la authentication: simple la
authentication: none. Pentru a -l repara, pur și simplu ștergeți cookie -urile Shinyproxy din browserul dvs.

Testarea performanței

De îndată ce începe ShinyProxy, creează 50 de containere noi. Când lansați aplicația, aceasta se încarcă aproape instantaneu, datorită containerelor pre-inițializate. Am testat această configurație cu 500 de sesiuni de browser, iar sistemul le -a gestionat fără efort. Atât ShinyProxy, cât și aplicația Shiny au răspuns rapid, iar încărcarea serverului a rămas minimă. Desigur, performanța reală depinde de consumul de resurse al aplicației dvs., dar ShinyProxy este conceput pentru a gestiona aceste variații în mod eficient. Configurația demonstrează că chiar și un server bazat pe ARM poate gestiona cu ușurință sute de utilizatori concurenti, oferind performanțe robuste, de calitate de producție.

Primul panou din captura de ecran arată cât timp așteaptă utilizatorii înainte de a fi atribuite un loc, iar cel de -al doilea panou arată numărul de locuri disponibile. Când am lansat 500 de sesiuni în doar două minute, locurile disponibile au scăzut rapid. Chiar și așa, timpii de încărcare au rămas la doar câteva milisecunde, ceea ce face clar că shinyproxy rămâne extrem de receptiv în timpul unei creșteri bruste de sute de noi sesiuni.

Odată ce toate aplicațiile sunt încărcate, utilizarea procesorului ShinyProxy scade și rămâne scăzut, așa cum se arată în ceea ce arată docker stats ieșire:

Monitorizare

Deși stiva de monitorizare a fost activată atunci când s -a implementat pentru prima dată shinyproxy, dezactivarea autentificării înseamnă că Grafana nu mai este accesibilă prin shinyproxy. O soluție simplă este de a implementa o a doua instanță shinyproxy care încă folosește autentificarea. Această instanță privată poate servi, de asemenea, ca mediu de testare pentru noi versiuni de dezvoltare a aplicației dvs. înainte de a le implementa pe serverul de producție publică. Pentru a configura acest lucru, creați un nou fișier de configurare în directorul de intrare, de exemplu private.shinyproxy.yamlși adăugați următorul cod:

server:
servlet:
context-path: /private

Asigurați -vă că actualizați proxy.realm-idde exemplu, setând -o la private.

După implementarea serverului, îl puteți accesa la același nume de gazdă cu serverul principal, dar sub /private/ sub-path. De exemplu, dacă serverul dvs. este disponibil la http://localhost/, instanța privată este accesibilă la
http://localhost/private/și Grafana la http://localhost/private/grafana/. Pentru a vizualiza jurnalele și valorile instanței publice, trebuie să ajustați variabila spațiului de nume în tablourile de bord.

Concluzie

Odată cu introducerea operatorului ShinyProxy pentru Docker, configurarea unui server ShinyProxy de calitate nu a fost niciodată mai ușoară. Această postare demonstrează că este necesară doar o configurație minimă pentru a gestiona un număr mare de utilizatori concurenti. Serverele sau clusterele scumpe nu sunt necesare, doar un singur server este suficient. Dacă aveți nevoie să susțineți mai mulți utilizatori, pur și simplu extindeți serverul: în majoritatea cazurilor, dublarea procesorului și RAM dublează aproximativ numărul de utilizatori concurenti. În comparație cu utilizarea resurselor a aplicațiilor strălucitoare în sine, ShinyProxy consumă foarte puțin procesor și RAM, astfel încât rareori devine un blocaj chiar și sub sarcină grea.

Nu ezitați să trimiteți întrebări sau sugestii și să vă distrați cu shinyproxy!