Un VPS offshore pentru API-ul dvs. și lucrul în fundal

O aplicație, două căi către muncă utilă

Acest scenariu ilustrativ este un mic produs de raportare, nu un studiu de caz al unui client sau o aplicație livrată. Calea sa sincronă autentifică un cont și citește metadatele raportului. Calea sa asincronă creează un export CSV. PostgreSQL păstrează starea aplicației, o coadă distribuie lucrul și o destinație separată stochează copiile de recuperare.

Operatorul instalează și întreține aceste componente. Un profil VPS nu creează automat baza de date, coada, configurația HTTPS sau aplicația. Decideți unde trăiesc datele persistente înainte de a porni un container.

Bugetați separat latența API și debitul sarcinilor

App 2 începe cu 2 vCPU, 4 GB RAM, 60 GB stocare și 2 TB transfer lunar. Acestea sunt alocări, nu o promisiune cu privire la numărul de conturi, cereri sau exporturi pe care le poate susține. Începeți o foaie de lucru pentru procesele API, baza de date, un worker, gazda și lucrul de lansare suprapus.

The foaie de lucru ilustrativă 3,840 MiB lasă prea puțină încredere lângă o graniță nominală 4 GB. Dacă măsurătorile susțin acea formă, App 2 plus 2 GB RAM totalizează $15.00 lunar înainte de reducerile de termen. Asta adaugă memorie, nu CPU sau independență a bazei de date. Comparați Scale 4 dacă atât CPU, cât și memoria au nevoie de un buget de pornire mai mare.

Monitorizați vârsta celei mai vechi sarcini și rata de finalizare utilă alături de latența API. O coadă în creștere cu CPU redus poate indica așteptarea stocării sau a bazei de date. Nu cumpărați putere de calcul pentru a compensa un export care reîncearcă în mod repetat o intrare invalidă.

Alegeți cuplajul pe care îl puteți opera

O singură gazdă simplifică prima hartă a serviciilor și evită o parte din coordonarea între gazde, dar partajează memoria, discul, mentenanța și eșecul. Un export costisitor poate interfera cu cererile obișnuite. Limitați concurența workerilor și faceți livrarea repetată sigură înainte de a adăuga procese.

Separați workerii când o încărcare realistă de sarcini dăunează în mod constant comportamentului API, când cerințele lor de runtime diverg sau când scalarea și mentenanța independente devin importante. Separați baza de date când propriile sale nevoi de resurse, acces sau recuperare justifică munca suplimentară de rețea și operațională. Acestea sunt alegeri de proiectare, nu caracteristici oferite automat prin upgradarea unui plan.

Dovediți forma printr-un exercițiu repetabil

Folosiți conturi sintetice și un set de date reprezentativ. Rulați împreună citiri API, un export mare și o suprapunere de lansare. Înregistrați latența, erorile, numărul de workeri activi, vârsta celei mai vechi sarcini, memoria și discul temporar. Apoi reporniți un worker după ce o ieșire este scrisă, dar înainte ca finalizarea să fie înregistrată; confirmați că aplicația publică tot un singur rezultat logic.

Repetați un exercițiu de recuperare pentru baza de date și o încărcare pe un target izolat. Capturați rezultatul real și reparați dependențele lipsă. Nu rulați acest exercițiu pe date ale clienților sau pe destinații reale externe de plată și e-mail fără un plan operațional separat.

Alegeți o perioadă după ce ați ales resursele

Totalurile următoare folosesc configurația de bază actuală App 2. Opțiunile de resurse cresc subtotalul lunar și primesc aceeași reducere de termen selectată. Întreaga perioadă redusă este plătită în avans; mai multe luni nu cresc alocarea de CPU, RAM sau transfer lunar.

Confirmați inventarul real, responsabilitățile de serviciu, taxele și termenii de reînnoire în faptele despre serviciu. O referință de plată locală nu stabilește o comandă înregistrată sau un server livrat. Păstrați foaia de lucru a volumului de lucru și revizuiți-o când aplicația se schimbă.