AWS Architecture Advice - mai multe instanțe EC2 cu bază de date partajată/sistem de fișiere cu pornire și oprire dinamică

Sunt foarte nou la arhitectura cloud, dar am o experiență decentă în dezvoltarea de aplicații. În acest moment, sunt în proces de a face o conductă de calcul mare mai accesibilă pentru 5-10 utilizatori prin intermediul unei aplicații web și configurez totul în AWS.

Implementarea mea actuală este o aplicație web ușoară React care utilizează două API-uri și un backend MySQL care permite utilizatorilor să pună în coadă job-urile cu parametri și să acceseze rezultatele finale prin aplicația web sau din e-mailurile trimise utilizatorilor după terminarea unei rulări.

În mijlocul acestei conducte se află o dependență de un software proprietar care are nevoie de o mașină foarte puternică pentru a calcula acești pași (64 GB ram, 16 nuclee, 1 TB HDD) și poate rula până la 1,5 zile doar pentru acest singur pas. Acesta este cel mai mare gât de sticlă al meu din întreaga conductă.

Pentru a economisi costuri cât mai mult posibil, încerc să fac blocajul/piesa de serviciu scalabilă/eficientă din punct de vedere al costurilor, având mai mulți „agenți” de instanță EC2 disponibili pentru a fi activați, rulați pașii, trimite un e-mail, scrie pe web baza de date a aplicației și apoi opriți instanța prin funcțiile AWS lambda care ar fi declanșate de o acțiune din aplicația web.

Plănuiesc să găzduiesc o instanță EC2 pentru aplicația web, 2 API-uri și serverul MySQL, deoarece concurența/scalabilitatea acestei piese este foarte mică. Voi avea, de asemenea, alte 1-3 instanțe pentru serviciile de blocaj pentru a partaja rulări simultane de la cei 5-10 utilizatori, ceea ce ar putea permite până la 3 rulări ale pasului greu să meargă în același timp.

Deoarece serviciile de blocaj necesită fișiere similare pentru a rula programele, iar intrarea în acești pași poate fi uneori cu dimensiuni de fișiere de 150 GB, mă gândesc să folosesc fie stocarea EFS, fie S3 pentru a păstra intrările, astfel încât să-mi fac griji doar cu transferul intrării. fișiere într-un singur loc care ar putea fi partajat între instanțe EC2 și nu ar trebui să mă asigur că au început să facă pasul de transfer. Aceasta este o piesă manuală pe care, de asemenea, nu am găsit o modalitate bună de a fi mai automatizat, deoarece dimensiunile fișierelor sunt atât de mari.

Întrebările mele sunt: ​​configurația mea sună rezonabil și vedeți vreo găuri în ideile mele de implementare? În prezent, folosesc stocarea EBS pentru instanțe de serviciu, dar vreau să minimizez locațiile de intrare pentru transferurile / întreținerea de 150 GB. De asemenea, nu sunt sigur de diferența dintre S3 și EFS, deoarece ambele par a fi montate pe mai multe instanțe, dar pe care ar trebui să îl folosesc? Și are sens să păstrez aplicația web, API-urile și baza de date pe o instanță EC2 dacă am nevoie de cele de serviciu capabile să scrie în baza de date după ce sunt terminate? Acea instanță ar fi activată tot timpul.

Vă mulțumesc pentru ajutor și iartă-mă dacă am spus ceva naiv.

Your setup does sound reasonable. I might suggest you look into having an API Gateway to "host" your API, and give it some thought if it works for you. You could also consider having your heavy-load EC2 instances in an Autoscaling Group and have your control Lambda interact with it instead of directly the instances.

S3 and EFS are different data storage solutions. S3 is object storage while EFS is file storage. S3 is not exactly mountable though it maybe presented as if it were through different utilities. Whether it's correct to use S3 or EFS depends on how you're using the files you have on there.

For your database you might consider going to RDS, perhaps with using a burstable instance class or one of the serverless options. But this will depend on your budget and use case.

În general, în cloud este bine să încerci să folosești mai degrabă servicii decât servere. Trebuie să fii atent la cost, dar poate face soluțiile mai robuste, mai rapide și mai conforme.

Am câteva gânduri despre volumul tău de muncă:

• Puteți folosi un orchestrator precum funcțiile AWS Step care apelează multe funcții lambda AWS pentru a face calculul? Observ că lambda este probabil cel mai scump timp de calcul pe AWS, deci poate nu este ideal. Cu limitele stabilite corect și un volum de lucru adecvat, poate ați putea începe 10.000 de lambda și ați face treaba în paralel în 15 minute.
• În loc de EFS/S3, ce zici de a crea o imagine EC2/AMI de aur, apoi pentru fiecare lucrare care învârte o instanță EC2 spot/dinamică suficient de mare pentru a face procesarea pentru acea lucrare oprită când este terminată? Poate Lambda ar putea orchestra munca pe baza unor evenimente de un anumit tip? Acest lucru ar evita taxele de transfer de date - deși nu sunt sigur dacă sunt taxate la EBS / S3 sau nu. Calculul spot este destul de ieftin și, dacă alegeți corect regiunea / AZ / dimensiunea instanței, întreruperile ar trebui să fie rare. Instanțele întrerupte sunt închise și volumul EBS păstrat, astfel încât acest lucru ar funcționa mai bine dacă munca dvs. este scrisă pe disc în mod regulat și poate fi repornită.

Probabil că aș dedica ceva timp optimizării acelei lucrări uriașe.