Infrastruktúra

A projekt környezetek infrastruktúrájának kialakításakor az alábbi szempontokat kell figyelembe venni:

• Legyen megvalósítva a Magas Szintű Rendelkezésre Állás (High Availability).
• Legyen terhelés elosztás (Load Balancing).
• A környezet szerepkörének (éles, teszt) megfelelő hardverspecifikáció megválasztása.

Fontos

Habár a tesztkörnyezeteknél is igyekszünk az éles környezetet leginkább tükröző infrastruktúrát létrehozni, de természetesen egy tesztkörnyezetnek nincs ugyanakkora hardverigénye. Ebből következően a tesztkörnyezet költségvonzatát igyekezzünk (a fenti szempontok figyelembe vétele mellett) a lehető legalacsonyabban tartani.

1. Hardveres követelmények

A projektek indulásakor ajánlott minimális hardverigény.

1.1 Ügyfél oldali környezetek (éles, UAT):

• Load Balancer - 1 darab VM.

  • Processzor: 2 vCPU
  • Memória: 2GB RAM
  • Tárhely: 20GB SSD

• Alkalmazások - annyi darab VM ahány példányban szeretnénk futtatni az alkalmazásokat (az alábbi konfiguráció VM-enként értendő).

  • Processzor: 2 vCPU
  • Memória: 8GB RAM
  • Tárhely: 40GB SSD

1.2 Fejlesztői tesztkörnyezetek (AWS):

• 1 darab VM
• Processzor: 2 vCPU
• Memória: 4GB RAM (a projekt növekedése során igény lehet a 8GB, de kezdésnek a 4GB is elég lehet).
• Tárhely: 40GB SSD

2. Ügyfél oldali környezetek

Ügyfél oldali környezetek architektúrális felépítése

2.1 Infrastruktúra

A klienstől érkező kérések a 443-as porton keresztül jutnak el a Load Balancer rétegig, innen lesznek átirányítva a megfelelő alkalmazásokhoz.

A Load Balancer (Semi Product esetén HAProxy) egy külön VM-re kerül.

Az ügyfél oldali környezeteken az alkalmazásokat két külön VM-re is telepítjük, ezáltal két példányban futtathatóak.

Célszerű ezt a három VM-et fizikailag is három külön gépen futtatni.

A fentieken kívül az infrastruktúra részét képezi még az adatbázis, az SMTP szerver és a ClamAV, amiket az alkalmazások VM-jei közösen használnak.

2.2 High Availability

Azt, hogy a klienstől érkező kéréseket melyik alkalmazásokat futtató VM-nek kell kiszolgálnia a Load Balancer (Semi Product esetén HAProxy) kezeli.

A Load Balancer mindamellett, hogy képes a terhelést (a konfigurált stratégia alapján) elosztani az esetünkben két (de lehetne több is) VM között, azt is észleli ha valamelyik VM esetleg nem elérhető. Ilyenkor a teljes forgalmat a másik, még elérhető VM-re irányítja, ezzel biztosítva a High Availability-t.

2.3 Állapotmentesség

Az egyik legfontosabb fejlesztési alapelv, hogy az alkalmazásaink ne tartalmazzanak állapotot rögzítő kódot, ez ugyanis több példányos futtatás esetén súlyos hibákat okozhat.

Például

Tegyük fel, hogy az alkalmazásunk emaileket küld ki, de egy típusú emailt csak napi egyszer szeretnénk kiküldeni.

Ebben az esetben ha azt az információt, hogy kiküldtük-e már az emailt osztályszintű változóban tároljuk, akkor azt a példányt leszámítva amelyik már kiküldte az emailt, a többi példány nem fog tudni az email küldés állapotáról.

Ezáltal előfordulhat, hogy szándékainkkal ellentétben naponta többször is kiküldjük az emailt. (Akár annyiszor ahány példányunk van.)

3. Fejlesztői tesztkörnyezetek

Fejlesztői tesztkörnyezetek architektúrális felépítése

A fejlesztői tesztkörnyezetek infrastruktúrája elsősorban abban különbözik az ügyfél környezetek infrastruktúrájától, hogy a tesztkörnyezeteken csak 1 darab VM-ünk van.

Ennek ellenére a backend alkalmazásból itt is két példányt futtatunk, hogy a több példányos futásból eredő esetleges hibákat már a tesztelés során ki tudjuk szűrni.

Miért nem futtatunk több példányt a frontend alkalmazásokból is?

A frontend alkalmazások valójában csak statikus kontentet szolgálnak ki, ebből következően nem fordulhatnak elő olyan hibák több példányos futtatás esetén sem, mint a backend alkalmazásoknál.