# Felhőalapú számítástechnika magyarázata: az a 11 építészeti koncepció, amit ismernie kell (4K mesterkurzus).

Published: 2026-09-15

A legtöbb szoftvermérnök úgy próbálja megtanulni a felhőarchitektúrát, hogy memorizálja a több száz AWS, GCP és Azure gyártói termék rövidítését. Azonban a valós felhőmérnöki munka tizenegy alapvető építészeti primitíven alapszik. Ebben a 4K remaster mesterkurzusban Niko lebontja a teljes vállalati tervrajzot: a vertikális és horizontális skálázástól és a Layer 7 terheléselosztástól a dinamikus autoskálázásig, a szerver nélküli microVM végrehajtásig, az aszinkron eseményvezérelt szétválasztásig, a konténer-orkesztrációig, a négypilléres tárolási hierarchiáig, a magas rendelkezésre állás és a 11 kilences tartósság közötti kritikus különbségig, a deklaratív Infrastruktúra mint Kód, és a Virtuális Privát Felhő hálózatépítésig. Ismerje meg ezt a tizenegy koncepciót, és bármilyen backendet megtervezhet éles környezetben. Ítélet: SHIP IT.

Canonical: https://thedailydiff.dev/hu/video/2026-09-14-cloud-computing-explained-4k/

## Amit ez a videó tartalmaz

- - Az Architektúra Fal & Mester Tervrajz
- - 01. Vertikális vs. Horizontális Skálázás
- - 02. Terheléselosztási Architektúra (L4 vs. L7 & Állapotellenőrzések)
- - 03. Autoskálázás és Rugalmasság
- - 04. Szervermentes (FaaS és Firecracker MicroVM-ek)

## Fejezetek

- 0:00 - Az Architektúra Fal & Mester Tervrajz
- 0:57 - 01. Vertikális vs. Horizontális Skálázás
- 2:17 - 02. Terheléselosztási Architektúra (L4 vs. L7 & Állapotellenőrzések)
- 3:45 - 03. Autoskálázás és Rugalmasság
- 4:50 - 04. Szervermentes (FaaS és Firecracker MicroVM-ek)
- 6:05 - 05. Eseményvezérelt Architektúra (EDA & Szétválasztás)
- 7:13 - 06. Konténer-orkesztráció (Docker és Kubernetes)
- 8:16 - 07. A 4 felhőtárolási pillér (S3, EBS, DB-k és Redis)
- 9:44 - 08. Magas rendelkezésre állás és a kilencesek (Több-AZ feladatátvétel)
- 10:53 - 09. Tartósság vs. Rendelkezésre állás (Miért nem az üzemidő 11 kilences)
- 12:14 - 10. Infrastruktúra mint Kód (Terraform vs. Konzol eltolódás)
- 13:20 - 11. Felhőhálózat (VPC, Alhálózatok, NAT és Biztonsági csoportok)
- 14:26 - 12. A teljes vállalati tervrajz és ítélet

## Lefordított átirat

Az eredeti angol narrációból fordítva. A rendelkezésre álló hangot és feliratokat a YouTube vezérli.

### - Az Architektúra Fal & Mester Tervrajz

0:00 Minden szoftvermérnök előbb-utóbb szembesül a felhőarchitektúra falával. Építesz egy alkalmazást a laptopodon, feltöltöd éles üzembe, és abban a pillanatban, amikor valódi felhasználók érkeznek, a szerverek összeomlanak, az adatbázis-kapcsolatok elfogynak, és az AWS számlád úgy néz ki, mint egy telefon szám. A legtöbb fejlesztő úgy próbálja megoldani a felhőmérnöki munkát, hogy memorizálja háromszáz különböző AWS termék rövidítését. De a valódi felhőalapú számítástechnika nem a gyártói katalógusok memorizálásáról szól: az tizenegy alapvető építészeti primitívre épül.

0:34 Ebben a mesterkurzusban végigvesszük a teljes vállalati tervrajzot: a skálázástól és terheléselosztástól a szervermentes, eseményvezérelt szétválasztásig, tárolási hierarchiákig és felhőhálózatokig. Sajátítsa el ezt a tizenegy koncepciót, és bármilyen backendet megtervezhet az AWS-en, GCP-n vagy Azure-on. Ez a The Daily Diff, a felszín alatt.

### - 01. Vertikális vs. Horizontális Skálázás

0:57 Első koncepció: Skálázás. Amikor az alkalmazásod forgalomnövekedést tapasztal, két alapvetően különböző módon tudod kezelni a terhelést: vertikális skálázással, vagy horizontális skálázással. A vertikális skálázás, vagy felfelé skálázás, azt jelenti, hogy a meglévő gépedhez több erőforrást adsz hozzá: négy CPU magról harminckettőre frissítesz, vagy harminckét gigabájt RAM-ot százhúsznyolcra cserélsz. nyolcra. A vertikális skálázás nulla architekturális változtatást igényel: a kódod

1:28 és az adatbázisod pontosan ugyanaz marad. De brutális hardverplafont üt el. Egyetlen gépnek sincs a világon tízezer CPU magja, és a felsőkategóriás példányok exponenciális felárat hordoznak. A horizontális skálázás, vagy kifelé skálázás, azt jelenti, hogy a szervereket kicsiben és áruként tartod, de több példányt futtatsz párhuzamosan egy router mögött. Ha egy példány összeomlik, a fennmaradó csomópontok nulla leállással nyelik el a forgalmat. A horizontális skálázás aranyszabálya az

2:01 állapotmentesség: az alkalmazásszerverek nem tárolhatnak felhasználói munkameneteket, feltöltött fájlokat vagy állapotot a helyi lemezeiken. Az állapotnak külső adatbázisban vagy gyorsítótárban kell élnie, lehetővé téve bármely csomópont számára, hogy bármely felhasználói kérést kezeljen.

### - 02. Terheléselosztási Architektúra (L4 vs. L7 & Állapotellenőrzések)

2:17 Második koncepció: Terheléselosztás. A horizontális skálázás papíron jól hangzik, de azonnal felvet egy problémát: amikor tízezer felhasználó éri el a domain nevedet, melyik specifikus szerver kapja a forgalmukat? A terheléselosztó fordított proxynak működik, amely a nyilvános internet és a privát backend klasztered között helyezkedik el. Fogadja a bejövő TCP vagy HTTP kapcsolatokat és elosztja a kéréseket az egészséges példányaid között.

2:47 A terheléselosztók két elsődleges hálózati rétegen működnek. A 4-es rétegű hálózati terheléselosztók a szállítási rétegen működnek, nyers TCP és UDP csomagokat irányítanak IP cím és port alapján mikroszekundumos késleltetéssel és másodpercenként millió kéréssel. A 7-es rétegű alkalmazás terheléselosztók magát a HTTP protokollt vizsgálják: URL útvonalakat, kérés fejléceket, sütiket és HTTP metódusokat olvasnak. Ez lehetővé teszi az útvonal alapú útválasztást: a per-API kéréseket a backend klaszteredre, és a per-statikus kéréseket egy

3:25 objektumtárolóba küldve. Kulcsfontosságú, hogy a terheléselosztók aktív állapotellenőrzéseket végeznek. Néhány másodpercenként a terheléselosztó pingel egy állapotellenőrzési végpontot minden példányon. Ha egy példány három egymást követő ötszázas hibát dob, vagy nem válaszol, automatikusan kizárásra kerül a poolból nulla eldobott kéréssel.

### - 03. Autoskálázás és Rugalmasság

3:45 Harmadik koncepció: Autoskálázás. Ha a webalkalmazásodnak hajnali háromkor két szerverre van szüksége, de húsz szerverre egy déli indításkor, a gombok kézi kattintgatása a felhőkonzolban garantált út a leálláshoz és a csődhöz. Az autoskálázás dinamikus rugalmasságot biztosít a horizontális szerverparkoknak. Az Autoskálázási Csoport figyeli a teljesítménymutatókat, mint az átlagos CPU kihasználtság, hálózati I-O, vagy a sor hátralékának mélysége. Amikor az átlagos CPU átlépi a meghatározott küszöböt – mondjuk,

4:19 hetven százalékot három egymást követő percig – az autoskálázó automatikusan új virtuális gépeket indít, regisztrálja őket a terheléselosztódnál, és elkezdi a forgalom irányítását. Ugyanilyen fontos a visszaskálázás: amikor a forgalmi hullám alábbhagy, az autoskálázó leállítja a felesleges példányokat, így abbahagyod a fizetést az üres számítási kapacitásért. A „flapping” – ahol a szerverek gyorsan létrejönnek és megsemmisülnek egy végtelen zűrzavaros ciklusban – megakadályozására a felhőarchitektek hűtési periódusokat konfigurálnak. Negyedik koncepció: Szervermentes.

### - 04. Szervermentes (FaaS és Firecracker MicroVM-ek)

4:53 Évekig a marketingcsapatok a szervermentest úgy hirdették, mint varázslatos kódot, ami az égben fut. Valójában a szervermentes továbbra is szervereket használ – de te nem birtoklod, nem javítod, és nem fizetsz értük, ha nincs futó kód. A Function-as-a-Service, mint az AWS Lambda vagy a Google Cloud Functions esetén, egy önálló kezelőfüggvényt írsz. Amikor HTTP kérés, S3 fájlfeltöltés vagy adatbázis változás történik, a felhő futtatókörnyezet elindít egy efemer

5:23 mikro-virtuális gépet, mint a Firecracker öt milliszekundum alatt. A kódod végrehajtódik, visszaad egy választ, és leáll. Ha három hónapig senki sem látogatja a weboldaladat, a számítási számlád pontosan nulla dollár és nulla cent. Ha egymillió felhasználó egyszerre éri el, a szolgáltató egymillió párhuzamos microVM-et indít. A mérnöki kompromisszumok valósak: hidegindítási késleltetés friss futtatókörnyezetek indításakor, kemény tizenöt perces végrehajtási korlát Lambdánál, és szigorú állapotmentesség.

5:55 A szervermentes verhetetlen eseményfolyamokhoz és szórványos API-khoz, de gyenge a tartós WebSockets vagy a többórás képzési futtatásokhoz.

### - 05. Eseményvezérelt Architektúra (EDA & Szétválasztás)

6:05 Ötödik koncepció: Eseményvezérelt Architektúra, vagy EDA. A hagyományos architektúrákban a szolgáltatások szinkron módon kommunikálnak. A pénztári szolgáltatásod hívja a fizetést, a fizetés hívja a készletet, a készlet hívja a csalást, és a csalás hívja az e-mailt. Ez teremti meg a végzet szinkron kaszkádját. Ha a harmadik féltől származó e-mail szolgáltató hálózati hibát tapasztal, és tíz másodpercig tart a válasz, az ügyfeled teljes pénztári kérése időtúllépéssel zárul, hibával. Eseményvezérelt architektúrában a szolgáltatások teljesen szétválasztottak.

6:37 Amikor egy ügyfél a vásárlás gombra kattint, a pénztári szolgáltatás nem hívja az alsóbb szintű szolgáltatásokat. Egyszerűen közzétesz egy eseményt, az úgynevezett RendelésFeladva-t, egy központi Eseménybuszon, mint az Amazon EventBridge vagy egy SNS téma. A pénztári művelet ötven milliszekundum alatt befejeződik. Az alsóbb szintű munkások a fizetés, a készletcsökkentés és az e-mail nyugták üzeneteket húznak le önállóan saját dedikált SQS sorukból. Ha az e-mail szolgáltatás egy órára leáll, az üzenetek biztonságosan pufferezve várnak a sorban, egyetlen eldobott rendelés nélkül.

### - 06. Konténer-orkesztráció (Docker és Kubernetes)

7:13 Hatodik koncepció: Konténer-orkesztráció. A Docker megoldotta a csomagolást: becsomagolja az alkalmazáskódodat, a rendszerkönyvtárakat, a konfigurációt és a futtatókörnyezetet egy immutábilis képbe, amely azonosan fut a MacBookodon és a felhőben. De egy konténer csomagolása egyszerű. Ötszáz konténer futtatása ötven fizikai virtuális gépen az, ahol a mérnöki munka összeomlik. Ezért léteznek konténer-orkesztrátorok, mint a Kubernetes és az AWS ECS.

7:41 Egy orkesztrátor vezérlőfelületet biztosít: egy API szervert, egy etcd állapotraktárat és egy intelligens ütemezőt. Deklarálod a kívánt állapotot: tíz replikát szeretnék az auth szolgáltatásomból, mindegyik két gigabájt RAM-mal. Az ütemező megvizsgálja a klasztert, podokat helyez el a szabad memóriával rendelkező csomópontokon, konfigurálja a belső hálózatot, és folyamatosan egyezteti a valóságot. Ha egy csomópont hardverhibát szenved, a Kubernetes észleli a veszteséget, és azonnal újraütemezi az összes elmozdult podot az

### - 07. A 4 felhőtárolási pillér (S3, EBS, DB-k és Redis)

8:16 egészséges csomópontokra. Hetedik koncepció: A felhőtárolási hierarchia. A kezdők gyakran egyetlen vödörként kezelik a felhőtárolást, ahová fájlokat dobnak. A gyártási architektúrában a tárolás négy különböző pillérre oszlik a hozzáférési minták és a késleltetés alapján. Először is az Objektumtárolás, mint az Amazon S3 vagy a Google Cloud Storage. Fájlokat HTTP REST API-k segítségével érhet el, egyszerű PUT és GET hívásokkal. Végtelen horizontális kapacitást kínál havonta két cent/gigabájt áron,

8:49 így ideális videókhoz, felhasználói feltöltésekhez, naplókhoz és biztonsági mentésekhez. Másodszor a Blokktárolás, mint az Amazon EBS. Ezek virtuális merevlemezek, amelyeket közvetlenül egy adott virtuális géphez csatolnak nagy sebességű összeköttetéseken keresztül. Standard fájlrendszerekké formázódnak, mint az ext4, támogatva az adatbázis motorok által igényelt gyors véletlenszerű olvasási és írási hozzáférést. Harmadszor a Felügyelt Adatbázisok: relációs motorok, mint a PostgreSQL RDS-en, amelyek ACID tranzakciókat és komplex joinokat biztosítanak,

9:21 és NoSQL motorok, mint a DynamoDB, amelyek egyjegyű milliszekundumos késleltetést biztosítanak hatalmas léptékben. Negyedszer pedig az In-Memory Caches, mint a Redis. Az adatok olvasása RAM-ból mikroszekundumokat vesz igénybe, nem milliszekundumokat. A gyorsítótárak az adatbázisod előtt ülnek, védve azt az ismétlődő olvasási forgalomtól és kezelve az illékony felhasználói munkamenet tokeneket.

### - 08. Magas rendelkezésre állás és a kilencesek (Több-AZ feladatátvétel)

9:44 Nyolcadik koncepció: Magas rendelkezésre állás, vagy HA. A rendelkezésre állás egy kérdésre válaszol: az idő hány százalékában működik az alkalmazásod és elérhető a felhasználók számára? Vállalati szerződésekben a rendelkezésre állást kilencesekben mérik. Két kilences, vagy kilencvenkilenc százalékos rendelkezésre állás, évente több mint három és fél nap leállást engedélyez. Négy kilences ötvenkét percre csökkenti az engedélyezett leállási időt, és öt kilences alig öt perc teljes leállást engedélyez évente.

10:15 A magas rendelkezésre állás eléréséhez meg kell szüntetni az egypontos hibákat a hiba domainek között. A felhőben ez több rendelkezésre állási zóna közötti telepítést jelent. Egy rendelkezésre állási zóna nem egyetlen rack: ez egy vagy több különálló fizikai adatközpont, mérföldekre egymástól, független áramellátással és hűtéssel. Aktív példányok futtatásával A és B zónában szinkron adatbázis-replikációval, egy villámcsapás vagy szálaszakadás, amely egy teljes fizikai létesítményt leállít, automatizált feladatátvételt eredményez.

10:50 harminc másodperc alatt, emberi beavatkozás nélkül.

### - 09. Tartósság vs. Rendelkezésre állás (Miért nem az üzemidő 11 kilences)

10:53 Kilencedik koncepció: Tartósság versus Elérhetőség. Ez a leggyakoribb fogalmi csapda a felhőarchitektúra interjúkban. A mérnökök gyakran felcserélhetően használják a szavakat, pedig teljesen különböző tulajdonságokat mérnek. Az elérhetőség az üzemidőt méri: tudok API-hívást végrehajtani az adataim olvasásához vagy írásához pont ebben a pillanatban? A tartósság a megőrzést méri: az adataim megmaradnak-e maradandó bitromlás, korrupció vagy megsemmisülés nélkül tíz éven keresztül?

11:24 Nézzük az Amazon S3 Standardot. A szolgáltatási szintű megállapodása kilencvenkilenc egész kilenc tized százalékos elérhetőséget biztosít, ami havonta körülbelül negyvenhárom percnyi leállást enged meg, amikor egy API-kérés ötszázas hibát adhat vissza. De az S3 tizenegy kilences tartósságot ígér: kilencvenkilenc egész kilenc kilenc kilenc kilenc kilenc kilenc kilenc kilenc kilenc százalék. Ha tízmillió fájlt tárolsz az S3-ban, statisztikailag arra számíthatsz, hogy elveszítesz

11:56 átlagosan egy fájlt tízezer évente. Az S3 ezt az objektumok hibatűrő kódolásával és a darabok replikálásával éri el legalább három földrajzilag elkülönített adatközpontban. Egy nagyobb regionális hálózati kimaradás során az S3 átmenetileg nem elérhető lehet, de az adataid soha nem semmisülnek meg.

### - 10. Infrastruktúra mint Kód (Terraform vs. Konzol eltolódás)

12:14 Tizedik koncepció: Infrastruktúra mint kód, vagy IaC. A felhőalapú számítástechnika korai időszakában a mérnökök bejelentkeztek az AWS webes felügyeleti konzoljára, és manuálisan kattintgattak virtuális gépek létrehozásához, alhálózatok konfigurálásához és biztonsági csoportok csatolásához. Az iparág ezt ClickOps-nak nevezi, és éles környezetben ez egy abszolút katasztrófa. A manuális konzolváltoztatásoknak nincs auditálási nyoma, nincs visszaállítási mechanizmusa, és elkerülhetetlenül konfigurációs eltérést okoznak a staging és éles környezetek között. Az Infrastruktúra

12:48 mint kód eszközökkel, mint a Terraform, OpenTofu, Pulumi vagy AWS CDK, teljes felhőarchitektúrádat deklaratív konfigurációs fájlokban definiálod, amelyeket Gitben tárolsz. Minden nyitott portra vagy adatbázis-replikára vonatkozó változtatás pull requesten és peer review-n megy keresztül. A terraform plan futtatása előnézetben megmutatja a pontos API diffet, mielőtt bármihez hozzányúlnának, és az éles környezeted egy identikus replikájának elindítása négy percet vesz igénybe, nem pedig négy hetet.

### - 11. Felhőhálózat (VPC, Alhálózatok, NAT és Biztonsági csoportok)

13:20 Tizenegyedik koncepció: Felhőhálózat és Virtuális Magánhálózatok. Amikor szervereket telepítesz a felhőbe, azok nem az nyílt, nyilvános interneten vannak kitéve. Egy szoftveresen definiált, izolált határon belül élnek, amit VPC-nek hívnak. A VPC-n belül privát IP-címtartományt osztasz ki, mint például a tíz-pont-nulla-pont-nulla-pont-nulla per tizenhat, és felosztod nyilvános és privát alhálózatokra. A nyilvános alhálózat közvetlen útvonallal rendelkezik egy Internet Gatewayhez.

13:51 Nyilvánosan elérhető eszközöket tartalmaz, mint az Application Load Balancereket és a NAT Gatewayeket. Ez az egyetlen része a hálózatodnak, amely nyilvános IP-címmel rendelkezik. Az alkalmazásszerverek és éles adatbázisok szigorúan privát alhálózatokban élnek, nyilvános IP-címek és nulla bejövő útvonal nélkül az internetről. Amikor a backend szervereknek biztonsági frissítéseket kell letölteniük, kimenő forgalmuk a nyilvános alhálózatban lévő NAT Gatewayen keresztül halad. Minden példányt biztonsági csoportok vesznek körül: állapotfigyelő virtuális tűzfalak, amelyek érvényesítik a legkevésbé jogosultság elvét.

### - 12. A teljes vállalati tervrajz és ítélet

14:28 Az adatbázis biztonsági csoportja csak az 5432-es porton fogad el kapcsolatokat, szigorúan az alkalmazásszerverek biztonsági csoportjából, így a külső behatolás matematikailag lehetetlenné válik. Ha távolabbról nézzük, ez a tizenegy primitív egy összefüggő rendszerré kapcsolódik össze. A DNS-ed egy nyilvános alhálózatban lévő terheléselosztóhoz irányul, az automatikus skálázási csoportok kezelik a forgalmi csúcsokat több rendelkezésre állási zónában, az eseménybuszok szétválasztják a backend dolgozókat, és a teljes stack-ed Gitből van telepítve, Infrastruktúra mint kód segítségével.

15:02 A mai mesterkurzus ítélete: SHIP IT. Ne memorizálj több száz felhőmarketing-rövidítést. Sajátítsd el ezt a tizenegy architektúramintát, válaszd szét az állapotodat, és építs olyan rendszereket, amelyek nem hibázhatnak. Írd meg kommentben, melyik felhőkoncepció okozta a legnagyobb fejfájást, amikor először kezdtél el építeni. És hogy megszerezd a teljes architektúra cheat sheetet, iratkozz fel a hírlevélre a daily diff dot dev oldalon,

15:28 link lent. És ennyi volt a mai diff. Niko vagyok az Axrisitől. Felelősségteljesen egyesíts.

## Források

- [AWS Well-Architected Framework (Reliability & Performance Pillars)](https://aws.amazon.com/architecture/well-architected/) — aws.amazon.com
- [Kubernetes Architecture & Control Plane Concepts](https://kubernetes.io/docs/concepts/architecture/) — kubernetes.io
- [Martin Fowler: What is Event-Driven Architecture?](https://martinfowler.com/articles/201701-event-driven.html) — martinfowler.com
- [Amazon S3 Data Durability & Availability Technical Whitepaper](https://aws.amazon.com/s3/features/) — aws.amazon.com
- [HashiCorp: Declarative Infrastructure as Code with Terraform](https://www.terraform.io/) — www.terraform.io