Menu

cloudservices

dns_route53

Domain név, DNS és az Amazon Route 53 ereje a gyakorlatban

, , , , , ,

| Olvasási idő: 5 perc |

Minden nap sok weboldalt böngészünk, akár órákon keresztül. Biztos vagyok benne, tudod, hogy a weboldalak szervereken futnak. A sok felhasználót, akik látogatják a legnépszerűbb oldalakat, nem egy szerver szolgálja ki. Esetekben ez több mint 10 vagy akár száz is lehet. Ekkor pedig felvetődik a kérdés: A felhasználó, hogyan. éri el például az Intagram szervereit, vagy terheléselosztóját?

A helyes kérdés azonban: A számítógépem, hogyan tudja melyik szervert kell meglátogatnia, ha beütöm a böngészőmbe a CloudMentor weboldalának címét?

És itt jön képbe a DNS. Ahogy az internet egyre nagyobb szerepet tölt be a mindennapi és üzleti életben, úgy válik egyre fontosabbá az, hogy hogyan jut el a felhasználó egy weboldalhoz, alkalmazáshoz vagy API-hoz. Ebben központi szerepe van a DNS-nek (Domain Name System), ami a domainnevek és IP-címek között teremt kapcsolatot.

Most bemutatom a DNS működését, elmagyarázom, hogyan illeszkedik ebbe a rendszerbe az Amazon Route 53 szolgáltatás, és mikor érdemes használni. MEgmutatom neked azt is, hogyan használható a Route 53 egy .hu végződésű domain esetében.

Mi az a DNS és hogyan működik?

A DNS (Domain Name System) az internet telefonkönyveként működik. Ahogy a telefonkönyv segítségével egy név alapján megtalálod valaki telefonszámát, a DNS is egy domainnév (pl. cloudmentor.hu) alapján megmondja, melyik IP-címet kell elérnie a számítógépnek vagy a böngészőnek.

A folyamat lépései leegyszerűsítve a következők:

  1. A felhasználó beír egy webcímet.
  2. A számítógép DNS-lekérdezést indít, hogy megtudja a hozzá tartozó IP-címet.
  3. A lekérdezés végigmegy a DNS-hierarchián:
    • Root szerverek (pl. .com, .org, .hu)
    • TLD (Top Level Domain) szerverek
    • Autoritatív névszerverek (például amit a Route 53 vagy az Azure DNS biztosít)
  4. A böngésző megkapja az IP-címet, és elkezdi letölteni az oldalt.

Ez a folyamat rendkívül gyors, de kulcsfontosságú a webes szolgáltatások működése szempontjából.

Mi az az Amazon Route 53?

Az Amazon Route 53 egy nagy rendelkezésre állású, skálázható DNS-szolgáltatás, amelyet az Amazon Web Services (AWS) kínál. A neve a DNS-szolgáltatás TCP/UDP portjáról kapta: 53.

A Route 53 három fő szolgáltatást kínál:

  1. DNS névfeloldás – villámgyors és globálisan elérhető IP-cím-lekérdezések.
  2. Domain regisztráció – bizonyos végződéseket az AWS felületén keresztül is megvásárolhatsz.
  3. Routing és monitoring – intelligens forgalomirányítás és elérhetőség-ellenőrzés.

Erősségek és lehetőségek

  • Nagy megbízhatóság – az AWS globális infrastruktúrájára épül, így a névszerverek hibatűrők és földrajzilag elosztottak.
  • Gyors válaszidő – anycast routing révén mindig a legközelebbi Route 53 szerver válaszol a lekérdezésre.
  • Routing policy-k támogatása – támogatja a failover, latency-alapú, weighted és geolocation routingot is.
  • Health check funkció – figyelheted a cél IP-címed elérhetőségét, és automatikusan átválthatsz másik IP-re, ha a fő szolgáltatás elérhetetlenné válik.
  • API és Infrastructure-as-Code támogatás – könnyen kezelhető Terraform, CloudFormation, AWS CLI vagy Python (boto3) segítségével.
  • Integrálható AWS szolgáltatásokkal – EC2, ELB, CloudFront, S3, API Gateway, stb.

Korlátai

  • Fizetős szolgáltatás – a hosted zone-ökért, lekérdezésekért és health check-ekért külön díjat számítanak fel.
  • Nem támogat minden domain végződést – például a .hu domaint nem lehet regisztrálni az AWS felületén.
  • Haladó beállításokhoz technikai tudás szükséges – bár a kezelőfelület felhasználóbarát, a komplex routing logikákhoz ismeretek kellenek.

Hogyan? – Több régiós webáruház DNS irányítása

Képzeld el, hogy van egy webáruházad, amelynek van egy szerverpéldánya Frankfurtban és egy másik Oregonban. A cél az, hogy az európai látogatók Frankfurtba, az amerikaiak Oregonba kerüljenek – ezzel csökken a késleltetés és gyorsabb lesz az oldal.

A Route 53 geolocation vagy késleltetés (latency) alapú routing policy segítségével automatikusan oda irányítja a látogatót, amelyik földrajzilag vagy válaszidő szerint a legmegfelelőbb.

Továbbá, ha az egyik szerver kiesik, a Route 53 észleli a hibát (health check segítségével), és automatikusan a működő példányra irányítja a forgalmat – mindezt felhasználói beavatkozás nélkül.

Hogyan? – .hu domain használata Route 53 névszerverként

Az Amazon Route 53 sajnos nem támogatja a .hu végződésű domainek regisztrációját, így ezeket nem tudod közvetlenül az AWS-en keresztül megvásárolni. Ennek ellenére teljes mértékben használhatod a Route 53-at névszerverként – a DNS-zóna kezelése átadható az AWS-nek.

Így használd Route 53-at egy más szolgáltatónál regisztrált .hu domainnel:

  1. Regisztrálj egy .hu domaint egy külső szolgáltatónál
    Például: XETHost, Forpsi, Rackforest.
  2. Hozz létre egy Public Hosted Zone-t az AWS Route 53-ban
    Például pelda.hu néven. Ekkor automatikusan kapsz egy NS rekordot, amely 4 AWS névszervert tartalmaz (pl. ns-123.awsdns-45.com, stb.).
  3. Másold át ezeket az NS rekordokat a domainregisztrátorod admin felületére
    Ezáltal a domainhez tartozó névfeloldás innentől kezdve a Route 53-on keresztül történik.
  4. Kezeld a DNS rekordokat Route 53-ban
    A, AAAA, CNAME, MX, TXT, SRV, ALIAS rekordokat is hozzáadhatsz, amelyek az infrastruktúrádra vagy külső szolgáltatásokra mutatnak.

Ez a módszer lehetővé teszi, hogy magyar domainnel is élvezd az AWS DNS-kezelés előnyeit – például intelligens routing, gyors válaszidők, monitoring és könnyű automatizálás formájában.

Összegzés

A DNS a modern internet gerince, és aki webes szolgáltatást üzemeltet – akár kis projektről, akár globális platformról van szó – annak előbb-utóbb szüksége lesz megbízható, gyors és rugalmas DNS-kezelésre. Az Amazon Route 53 pontosan ezt nyújtja: ipari szintű megbízhatóságot, haladó routing képességeket, és kiváló integrációt az AWS többi szolgáltatásával.

Akkor is megéri használni, ha a domain nem az AWS-nél van – akár .hu domain esetén is egyszerűen beállítható, hogy a Route 53 végezze a névfeloldást. Ezáltal egységesíthető és automatizálható az infrastruktúra DNS-kezelése, amit hosszú távon minden fejlesztő és üzemeltető értékelni fog.

sagemaker_canvas_graph

SageMaker Canvas: NoCode gépi tanulás egyszerűen kezdőknek

, , , , , , , , , , , ,

| Olvasási idő: 5 perc |

A mesterséges intelligencia és a gépi tanulás területén az elmúlt években hatalmas a hype. Egyre több vállalat szeretné az adatait hatékonyabban használni, előrejelzéseket készíteni, automatizált döntéstámogatást bevezetni. A probléma legtöbbször az, hogy a gépi tanulás bevezetéséhez általában Data Scientist-okra (adatkutató, adatszakértő), fejlesztőkre és komoly programozói háttérre van szükség. Emellett a megfelelő minőségű eredmény hihetetlenül sok adatot ás így rengeteg időt kíván.

Ezt a belépési korlátot oldja fel az Amazon Web Services (AWS) egyik szolgáltatása, a SageMaker Canvas, amely a NoCode megközelítésnek köszönhetően egyszerűsíti le a gépi tanulás folyamatát.

Mi az a SageMaker Canvas?

A SageMaker Canvas az AWS SageMaker család része, amelyet kifejezetten úgy terveztek, hogy kódírás nélkül is lehessen prediktív modelleket létrehozni. A felület egy vizuális, drag-and-drop alapú eszköz, ahol a felhasználó a teljes gépi tanulási folyamatot végigviheti:

  • adatforrások csatlakoztatása,
  • adattisztítás és előfeldolgozás,
  • modellépítés és tanítás,
  • predikciók készítése és megosztása.

Mindez úgy történik, hogy közben nincs szükség Python-kódra vagy statisztikai algoritmusok mély ismeretére. A Canvas a háttérben az AWS erőforrásait használja, és automatikusan a legmegfelelőbb algoritmusokat választja ki az adott feladathoz.

Hogyan működik a gyakorlatban?

A SageMaker Canvas első lépésként adatkapcsolatok felépítését teszi lehetővé. Ide csatolhatók CSV fájlok, Amazon S3-ban tárolt adatok, vagy akár relációs adatbázisok. Ezután a rendszer segít az adatok előkészítésében:

  • hiányzó értékek kezelése,
  • duplikált sorok kiszűrése,
  • típuskonverziók,
  • vizualizációk létrehozása az adatok megértéséhez.

A következő lépés a modellépítés, ahol a felhasználónak mindössze ki kell választania, hogy milyen típusú előrejelzést szeretne: például osztályozás (igen/nem döntés), regresszió (számérték előrejelzés) vagy idősort elemző predikciók. A Canvas az AutoML (automated machine learning) módszereit használja: több algoritmust futtat párhuzamosan, és kiválasztja a legjobban teljesítőt.

A modell elkészülte után a felhasználó azonnal kipróbálhatja a predikciókat. Például új adatokat adhat meg, és megnézheti, hogyan reagál a modell. A végeredmény exportálható és megosztható másokkal, vagy integrálható üzleti folyamatokba.

Erősségei

  1. NoCode használat – Teljesen grafikus, kódírás nélküli környezet.
  2. Gyors prototípus-készítés – Az üzleti oldalon dolgozó kollégák gyorsan tudják validálni ötleteiket.
  3. AWS integráció – Könnyen összekapcsolható más AWS szolgáltatásokkal (pl. S3, Redshift).
  4. Automatizált modellezés – Nem szükséges az algoritmusok közötti választás, a Canvas maga találja meg a legjobbat.
  5. Vizualizációk és magyarázhatóság – Grafikonokkal és elemzésekkel segít megérteni, hogy a modell miért hozott adott döntést.

Korlátai

  1. Komplex projektekhez kevés – Ha speciális algoritmusokra vagy finomhangolásra van szükség, a Canvas már nem elegendő.
  2. Adatminőség (kritikus) – A rossz adat nem ad jó eredményt, még akkor sem, ha az eszköz egyszerű.
  3. Költségvonzat – A Canvas mögött futó számítások AWS erőforrásokat igényelnek, amelyek költsége gyorsan nőhet nagy adatállományoknál.
  4. Nem minden üzleti kérdésre jó – A modell típusai korlátozottak, így nem minden problémát lehet vele lefedni.

Kapcsolódó AWS megoldások a SageMaker Canvas mellett

A SageMaker Canvas önmagában is hasznos NoCode eszköz, de az AWS-en belül több kapcsolódó szolgáltatás is erősíti a képességeit. Ezek együtt egy teljes gépi tanulási életciklust fednek le:

  • Amazon SageMaker Studio
    A Canvas „profi testvére”. Egy teljes körű fejlesztői környezet (IDE), ahol adattudósok és fejlesztők kódolva készíthetnek és finomhangolhatnak modelleket. A Canvas felhasználói gyakran ide továbbítják a sikeres prototípusokat további optimalizálásra.
  • Amazon S3
    Az egyik legfontosabb adatforrás és adattár. A legtöbb felhasználó ide tölti fel a modellhez használt nyers adatokat, amelyekhez a Canvas közvetlenül kapcsolódhat.
  • Amazon Redshift
    Ha a vállalat nagy mennyiségű strukturált adatot kezel adatbázisban, a Canvas képes közvetlenül csatlakozni a Redshifthoz, és onnan beolvasni az adatokat modellezéshez.
  • AWS Glue
    Adat-előkészítési és ETL (Extract, Transform, Load) folyamatokhoz használható. Segít megtisztítani és átalakítani az adatokat, mielőtt azok a Canvas-ba kerülnek.
  • Amazon QuickSight
    Az előrejelzések és eredmények vizualizálásához használható BI (Business Intelligence) eszköz. A Canvas által készített predikciók integrálhatók QuickSight dashboardokba, így az üzleti döntéshozók egyszerűen láthatják az elemzések eredményeit.
  • AWS Identity and Access Management (IAM)
    Fontos kiegészítő, amely biztosítja, hogy a különböző felhasználók csak a számukra engedélyezett adatokhoz és Canvas-funkciókhoz férjenek hozzá.

Ezek a szolgáltatások együtt alkotják azt a környezetet, ahol a SageMaker Canvas valóban ki tudja bontakoztatni a NoCode gépi tanulási lehetőségeit: a nyers adatok betöltésétől kezdve a modellezésen át egészen az üzleti irányítópultokig.

Kinek való a SageMaker Canvas?

A Canvas ideális választás azok számára, akik szeretnének a gépi tanulás világába belépni, de nem rendelkeznek fejlesztői tudással. Például:

  • Üzleti döntéshozók: gyors előrejelzésekhez, üzleti forgatókönyvek modellezéséhez.
  • Adatelemzők: akik szeretnének kódírás nélkül kísérletezni ML-modellekkel.
  • Oktatók és diákok: akik bevezetésként ismerkednek a gépi tanulással.
  • Kisebb cégek: ahol nincs külön adatkutató csapat, de mégis szeretnének adatvezérelt döntéseket hozni.

Jöjjön egy példa

Képzeljünk el egy üzletláncot, amelynek több telephelye van Magyarország különböző városaiban. A vállalat rendelkezik több évre visszamenőleg bevételi adatokkal, beleértve a világjárvány időszakát is. A cég elemzői most a vezetőség számára szeretnének egy minimum hat hónapos előrejelzést (predikciót) készíteni minden egyes üzlet jövőbeli bevételére.

A SageMaker Canvas lehetővé teszi, hogy az elemzők feltöltsék az eddigi adatokat, és kiegészítsék azokat olyan külső tényezőkkel, mint például a magyarországi nemzeti ünnepek és munkaszüneti napok. Így a modell nemcsak a múltbeli trendekből tanul, hanem figyelembe tudja venni azokat az időszakokat is, amikor az üzletek forgalma rendszerint megváltozik.

Miért tökéletes megoldás erre a Canvas?

  • Nincs szükség programozói tudásra, az elemzők önállóan tudják használni
  • Könnyen integrálhatók külső tényezők, például ünnepnapok vagy speciális időszakok
  • Gyorsan elkészíthető prototípus, ami azonnali üzleti értéket ad
  • A modell eredményei egyszerűen megoszthatók a vezetőséggel, vizualizációk formájában

Az így elkészült prediktív modell pontosabb előrejelzéseket ad a bevételekre, ami segíti a vezetőséget a készletezésben, a munkaerő-beosztás megtervezésében, valamint a marketingkampányok időzítésében.

Összegzés

A SageMaker Canvas az egyik legígéretesebb NoCode eszköz arra, hogy a gépi tanulás világát közelebb hozza azokhoz, akik nem fejlesztők vagy adatkutatók. Könnyű használata révén üzleti szakemberek is képesek lesznek prediktív modelleket készíteni, és ezzel adatvezérelt döntéseket hozni. Bár nem helyettesíti a szakértői munkát, remek eszköz gyors prototípusokhoz, hitelesítéshez és az AI használatának bevezetéséhez egy szervezetben.

azure_data_factory

Azure Data Factory: NoCode adatintegráció és adattisztítás

, , , , , , , , ,

| Olvasási idő: 4 perc |

A modern világunkban az adat az egyik legértékesebb erőforrás. Az üzleti döntések, a marketingkampányok és a működés hatékonysága mind azon múlnak, hogy a szervezetek mennyire tudják kiaknázni a rendelkezésre álló információkat, mind időben, mind minőségben. Gondoljunk bele, a mesterséges intelligencia is a tengernyi adaton tud csupán jól és hatékonyan működni.

Az adatok azonban gyakran széttagoltak: különböző adatbázisokban, fájlokban, rendszerekben léteznek és legtöbbször eltérő formátumban. Emiatt szükségük van egy olyan eszközre, amely segít ezeket egységesíteni, megtisztítani, átalakítani és feldolgozni. Erre nyújt megoldást az Azure Data Factory (ADF), amely a Microsoft Azure-on érhető el.

Mi az Azure Data Factory?

Az Azure Data Factory egy felhőalapú ETL (Extract, Transform, Load) és ELT (Extract, Load, Transform) szolgáltatás. Lényege, hogy adatokat tud kinyerni (Extract) különböző forrásokból, azokat átalakítani (Transform), majd a célrendszerbe betölteni (Load). Ezzel hidat képez az eltérő rendszerek és az üzleti intelligencia eszközök között.

Mivel teljesen felügyelt szolgáltatás, a felhasználónak nem kell szerverek karbantartásával, skálázásával vagy szoftverfrissítésekkel foglalkoznia. Az ADF vizuális, drag-and-drop alapú felületet kínál, de támogatja az adatfolyamok kód alapú megírását is. Így mind az üzleti felhasználók, mind a fejlesztők megtalálhatják benne a számításaikat.

Egy nagytudású NoCode megoldás, amely segít az üzleti integrációban is, de kiszolgálja a fejlesztői igényeket is.

Főbb építőelemei

  • Pipeline (csővezeték): Egy adott adatfeldolgozási folyamat leírása, amely több lépésből is állhat.
  • Activity (tevékenység): Egy pipeline egy-egy művelete, például adatmozgatás vagy átalakítás.
  • Data Flow (adatfolyam): Kifejezetten adattisztításra és transzformációra szolgáló vizuális eszköz.
  • Linked Service (kapcsolódó szolgáltatás): Az adatforrás vagy a célrendszer konfigurációja, pl. SQL adatbázis vagy blob tárhely.
  • Dataset (adathalmaz): A feldolgozott adatok logikai egysége, amelyet egy pipeline vagy activity használ.

Ezek az építőelemek együtt adják az ADF rugalmasságát és sokoldalúságát.

Erősségei

Az Azure Data Factory legnagyobb előnye a széles körű integráció. Több mint 90 különböző adatforráshoz kínál beépített csatlakozót, amelyek között megtaláljuk az SQL adatbázisokat, CSV fájlokat, NoSQL rendszereket, API-kat vagy akár SAP rendszereket is.

Másik erőssége a skálázhatóság: akár kis mennyiségű adatot, akár petabájt méretű adathalmazokat is képes kezelni, anélkül, hogy a háttérben nekünk kellene erőforrást biztosítani.

Kiemelendő az adattisztítási képessége, amely lehetővé teszi a duplikált elemek kiszűrését, a hiányzó vagy hibás értékek javítását, és a különböző formátumok egységesítését. Ez rendkívül fontos, mert a tisztítatlan adatok gyakran félrevezető jelentésekhez és rossz üzleti döntésekhez vezethetnek.

Lehetőségei

Az ADF nemcsak egyszerű adatmozgatást, hanem komolyabb adatintegrációs feladatokat is támogat:

  • Automatizálás és ütemezés: Beállítható, hogy a pipeline-ok meghatározott időpontokban, például óránként vagy naponta fussanak.
  • Big Data feldolgozás: Az Azure Synapse Analytics-szel vagy a Databricks-szel kombinálva nagy mennyiségű adatot is képes feldolgozni.
  • Hybrid környezet támogatása: Nemcsak a felhőből, hanem hagyományos (on-premise) rendszerekből is be tud gyűjteni adatokat.
  • DevOps integráció: Támogatja a Git verziókezelést, így a folyamatok fejlesztése és karbantartása könnyebben követhető.
  • Monitorozás: Az ADF képes részletes log-okat és figyelmeztetéseket küldeni, hogy lássuk, mikor és hol futott hiba a folyamatban.

Korlátok

Bár sokoldalú, nem minden helyzetben a legjobb választás. Például:

  • A valós idejű feldolgozás csak korlátozottan érhető el, főként kötegelt feldolgozásra optimalizált.
  • A komplex logikai átalakítások esetében gyakran érdemes külső szolgáltatásokkal (pl. Databricks) kombinálni.
  • A költségek nagy mennyiségű adat esetén gyorsan növekedhetnek, így fontos a folyamatok optimalizálása.

Felhasználási esetek

  1. Kereskedelmi vállalat: Egy online áruház a webes rendelések adatait, a raktárkészlet-információkat és a fizikai üzletek eladásait szeretné egy helyen elemezni. Az ADF összegyűjti az adatokat, megtisztítja azokat, majd az Azure Synapse Analytics-be tölti, ahol a menedzsment valós idejű riportokat készíthet.
  2. Banki szektor: Egy bank különböző rendszerekből (tranzakciók, ügyféladatok, CRM) gyűjt adatokat, majd azokat normalizálja és tisztítja. Az így előkészített adatokból megbízható fraud detection modellek építhetők.
  3. Gyártóipar: Egy gyártó cég különböző szenzorokból származó adatokat integrál az ADF segítségével, majd előkészíti azokat gépi tanulási modellekhez, amelyek előrejelzik a gépek meghibásodását.

Tanulság kezdőknek

Ha most ismerkedsz az adatintegráció világával, az Azure Data Factory kiváló belépési pont. Egyszerre biztosít vizuális, kódmentes megoldást és fejlesztőbarát rugalmasságot. A kulcs az, hogy először kisebb, egyszerűbb pipeline-okat hozz létre, majd fokozatosan bővítsd a tudásod összetettebb adatfolyamokkal és tisztítási feladatokkal.

A Mentor Klubban, 2025. szeptemberétől elérhető NoCode és LowCode megoldások Azure-ban és AWS-ben képzési anyagban is testközelből láthatod ennek működését.

Összegzés

Az Azure Data Factory ideális választás mindenkinek, aki adatvezérelt működésre szeretne átállni. Megbízhatóan kapcsolja össze a különböző rendszereket, tisztítja és feldolgozza az adatokat, majd elérhetővé teszi azokat riportokhoz, elemzésekhez vagy mesterséges intelligencia modellekhez. Bár vannak korlátai, a rugalmassága és az egyszerű kezelhetősége miatt az egyik legfontosabb adatfeldolgozó eszköz az Azure ökoszisztémában.

Én például a DJ fellépéseimhez szükséges zenei tárház elemeit szoktam ezzel tisztítani, mielőtt elküldöm a MAHASZ felé.

A_flat-design_digital_illustration_depicts_a_cloud

Amazon S3 Vektorok: új korszak az adatok keresésében

, , , , , , , , ,

| Olvasási idő: 4 perc |

Eddig is úgy gondoltam, hogy az Amazon S3 a világ legjobb felhő tárolási megoldása, hiszen olyan széleskörűen, egyszerűen és költséghatékonyan használható, hogy azzal magasan lekörözi versenytársait.

Teszi ezt úgy, hogy az AI megjelenésével továbbra is az egyik legszélesebb körben használható tárolási megoldás maradt. Az Amazon azonban nem elégedett meg ezzel, hanem tovább dolgozott és nemrég be is jelentették, hogy az Amazon S3 mostantól natívan támogatja a vektorokat.

Ez nem csupán egy egyszerű frissítés, hanem egy komoly lépés afelé, hogy az AI-alapú keresések és alkalmazások még gyorsabbak és hatékonyabbak legyenek, ráadásul közvetlenül ott, ahol az adatokat tároljuk: az S3-ban.

Mi is az az Amazon S3 Vector?

Az Amazon S3 Vector egy új lehetőség arra, hogy vektorokat – azaz gépi tanulási modellekből származó tömörített adatreprezentációkat – natívan tároljak és kereshetővé tegyek az S3-ban. Korábban, ha például képeket, szövegeket vagy videókat szerettem volna hasonlóság alapján keresni, az adataimat először külön vektor adatbázisba kellett töltenem (pl. Weaviate), ahol a hasonlóságkeresést elvégezhettem. Mostantól ez közvetlenül az S3-ban is elérhető.

Ez hatalmas előrelépés – nemcsak egyszerűsíti az architektúrát, hanem csökkenti a késleltetést, az összetettséget és a költségeket is.

Hogyan működik?

Az S3 Vector a meglévő Amazon S3 Express One Zone tárhelyre épül, és három fontos komponenst kínál:

  1. Vector Store (vektortár) – Ebbe töltöm fel a vektorokat és a hozzájuk tartozó metainformációkat.
  2. Ingest API – Ezen keresztül adhatom meg a vektorokat és az indexelendő adatokat.
  3. Query API – Ezzel tudok hasonlóság alapján keresni (pl. „melyik képek hasonlítanak erre a képre?”)

Minden vektor egy rekord részeként kerül be, amely lehetővé teszi, hogy ne csak vektor alapján, hanem metaadatok szerint is tudjak szűrni, például dátum, fájltípus vagy címke alapján.

Példák a használatra

1. Dokumentumkeresés

Egy nagy mennyiségű belső dokumentumot tartalmazó gyűjteményben szerettem volna hasonló jelentésű dokumentumokat megtalálni. Ahelyett, hogy kulcsszavas keresést használtam volna, minden dokumentumhoz vektort generáltam egy nyelvi modell segítségével, és azokat töltöttem fel az S3 Vectorba.

Ezután egy új keresés során elég volt megadnom egy kérdést vagy egy rövid szövegrészletet – és az S3 azonnal visszaadta azokat a dokumentumokat, amelyek a legjobban illeszkedtek a jelentésük alapján.

2. Képalapú hasonlóságkeresés

Egy e-kereskedelmi oldalon képek alapján szerettem volna hasonló termékeket ajánlani. A termékfotókat vektorizáltam egy gépi látás modell segítségével, majd betöltöttem az S3 Vectorba. Így amikor egy vásárló feltöltött egy képet, a rendszer pillanatok alatt megtalálta a hozzá leginkább hasonlító termékeket – anélkül, hogy külön vektor-adatbázist kellett volna karbantartanom.

Miben más ez, mint a meglévő megoldások?

A legtöbb vektoros keresési rendszer eddig úgy működött, hogy külön adatbázist kellett használni (pl. Pinecone, Weaviate, FAISS, Qdrant). Ez viszont újabb infrastruktúrát, szinkronizációs feladatokat és összetettebb architektúrát igényelt. Az Amazon S3 Vector ezt az egészet leegyszerűsíti: egy helyen tárolom és keresem az adatokat.

Azt is kiemelném, hogy mivel az S3 Vector az Express One Zone megoldásra épül, ezért alacsony késleltetésű hozzáférést kapok – mindezt az S3 skálázhatóságával és megbízhatóságával együtt.

Korlátok és tudnivalók

Természetesen nem minden esetben ez a legjobb megoldás. A jelenlegi verzió:

  • csak az S3 Express One Zone-on keresztül működik,
  • maximum 250 kB méretű rekordokat támogat,
  • és előzetes (preview) státuszban van, így még nem éles környezetbe szánt végleges termék.

A vektorok betöltéséhez és a keresésekhez is REST API-t használhatok, de egyelőre nincs közvetlen AWS konzolos támogatás.

Mikor érdemes használni?

Én akkor fogom választani az S3 Vector-t, ha:

  • már eleve S3-ban tárolok adatokat (képeket, szövegeket),
  • AI-alapú hasonlóságkeresésre van szükségem,
  • és szeretném leegyszerűsíteni az architektúrát, elkerülve a külön vektor-adatbázisokat.

Összegzés

Az Amazon S3 Vector egy fontos mérföldkő a natív, felhőalapú AI-alkalmazások területén. Ha te is vektoros keresést építenél, és az adataid már most is S3-ban vannak, akkor ez egy kiváló lehetőség arra, hogy gyorsan és hatékonyan vezess be intelligens keresési képességeket – közvetlenül a tárhelyeden.

Ha szeretnél még többet megtudni, akkor becsatolom ide a hivatalos blog cikket.

Én biztosan tesztelek vele a következő AI-projektem során. Ha te is érdeklődsz a hasonló technológiák iránt, most érdemes elkezdeni a kísérletezést.

amazon_s3

Amazon S3 – Rugalmas, biztonságos online adattárolás

, , , , , , ,

| Olvasási idő: 5 perc |
  • Erőforrás típus: IaaS
  • Felhő szolgáltató: Amazon Web Services
  • Angol név: Simple Storage Service
  • Magyar név: Simple Storage Service
  • Rövidített név (ha van ilyen): S3

Az Amazon Simple Storage Service, rövidebb nevén Amazon S3, az egyik legismertebb és leggyakrabban használt felhőalapú tárolási szolgáltatás. Az AWS kínálatának alappillére, és szinte minden modern, felhőben futó alkalmazásban megtalálható valamilyen formában. Aki most ismerkedik az AWS-el, annak ez egy kiváló belépési pont a felhőalapú adattárolás világába.

Mi az az Amazon S3?

Az Amazon S3 egy objektumalapú tárolási megoldás, amely lehetővé teszi, hogy szinte korlátlan mennyiségű adatot tároljunk biztonságosan és elérhetően. Az Amazon S3-ban az adatokat bucket-ekbe (ejtsd: „bakit”) rendezzük.
Egy bucket úgy működik, mint egy mappa a számítógépen, amelyben különféle fájlokat tárolunk.

A bucket-ben minden fájl (például egy kép, dokumentum vagy videó) objektumként szerepel, és mindegyik kap egy egyedi azonosítót. Ez az azonosító olyan, mint egy fájlnév a számítógépen – ennek köszönhetően tudjuk pontosan, melyik fájlhoz akarunk hozzáférni.

Fontos különbség a hagyományos fájlrendszerekhez képest, hogy az S3 nem egy hagyományos mappastruktúrát vagy merevlemezt használ. Nem „blokkokba” írja az adatokat, mint egy fizikai winchester, hanem objektumként tárolja őket, metaadatokkal és egyedi azonosítóval együtt.

Az adatokhoz két fő módon férhetünk hozzá:

  • AWS Management Console: Ez egy webes felület, ahol kattintgatással lehet fájlokat feltölteni, letölteni vagy törölni, hasonlóan a OneDrive-hoz vagy Dropbox-hoz.
  • API / SDK: Ez fejlesztőknek való módszer, ahol programkódból vagy parancssorból tölthetünk fel és kezelhetünk adatokat.

Egyszerűen fogalmazva: az S3-ban minden adat egy „felhőmappában” van, és egyedi neve vagy azonosítója alapján bármikor, bárhonnan előhívható – nem számít, hogy egy fotóról, videóról vagy akár egy nagy adatfájlról van szó.

Miért ennyire népszerű?

  1. Skálázhatóság: Az S3 automatikusan alkalmazkodik az igényekhez – nincs felső határ az adatmennyiségre vonatkozóan.
  2. Magas rendelkezésre állás: A szolgáltatás több zónában és régióban is replikálja az adatokat.
  3. Biztonság: Támogatja az adatátviteli és tárolási titkosítást, valamint integrálható IAM-mel (azonosság- és hozzáférés-kezelés).
  4. Egyszerű integráció: Szinte minden AWS-szolgáltatással közvetlenül együttműködik, és külső rendszerekkel is könnyen használható.
  5. Költséghatékonyság: A használatalapú fizetési modellnek köszönhetően csak azért fizetünk, amit valóban használunk.

Tárolási osztályok: melyiket mikor?

Az Amazon S3 egyik különlegessége, hogy több tárolási osztályt is kínál.
A tárolási osztály azt határozza meg, milyen módon és feltételekkel tárolja az S3 az adatokat, például:

  • hány példányban őrzi meg azokat,
  • milyen gyorsan érhetők el,
  • mennyibe kerül a tárolás és a lekérés.

Ez azért fontos, mert nem minden adatot használunk egyformán:

  • Van, amit naponta többször is elő kell venni (például egy weboldal képei).
  • Más fájlokat csak havonta egyszer, vagy még ritkábban érünk el (például archívumok vagy biztonsági mentések).

A megfelelő tárolási osztály kiválasztásával optimalizálhatjuk a költségeket, hiszen a ritkán használt adatok olcsóbb, de lassabban elérhető tárolóba kerülhetnek, míg a gyakran használt fájlok gyors, de drágább osztályban maradhatnak.

Egyszerűen fogalmazva: a tárolási osztály olyan, mint egy csomag a felhőtárolásban – te döntöd el, mennyiért és milyen gyors hozzáféréssel szeretnéd tárolni az adataidat.

  1. S3 Standard: Általános célra szánt tárolás, gyakori elérésű adatokhoz. Magas rendelkezésre állás és alacsony késleltetés.
  2. S3 Intelligent-Tiering: Automatikusan áthelyezi az adatokat a legköltséghatékonyabb tárolási osztályba a hozzáférési szokások alapján.
  3. S3 Standard-IA (Infrequent Access): Ritkán elérendő, de gyorsan elérhető adatokhoz. Alacsonyabb tárolási költség, de lekéréskor külön díj van.
  4. S3 One Zone-IA: Mint az IA, de csak egyetlen rendelkezésre állási zónában tárolja az adatokat.
  5. S3 Glacier: Archiváláshoz használható. Lekérés néhány perctől órákig tarthat.
  6. S3 Glacier Deep Archive: Hosszú távú archiválás, nagyon alacsony költséggel, de lekérés akár 12 óráig is eltarthat.

Egyszerű példa: Weboldal statikus tartalmainak kiszolgálása

Képzeljünk el egy céget, amely egy modern weboldalt üzemeltet. A HTML, CSS, JavaScript és képek statikus fájlokként tárolhatók az S3-ban, a bucket-et pedig nyilvánosan elérhetővé lehet tenni. Ezzel egy rendkívül gyors, skálázható, biztonságos és alacsony költségű megoldást kapunk, CDN-nel (például Amazon CloudFront-tal) kombinálva pedig globálisan optimalizált élményt biztosíthatunk a felhasználóknak.

Mikor érdemes S3-at használni?

  • Statikus weboldalak és mobilalkalmazások háttértárolásához
  • Biztonsági mentésekhez és archiváláshoz
  • Nagy adatmennyiségű adatfeldolgozási folyamatok (pl. Big Data, AI) bemeneti és kimeneti fájljainak kezelésére
  • Alkalmazások fájlfeltöltésének kezelésére (pl. profilképek, dokumentumok)
  • Médiatartalom (képek, videók, hanganyagok) tárolására

Korlátok és figyelmeztetések

Bár az S3 sokrétű és megbízható, fontos tisztában lenni a korlátokkal is:

  • Objektumalapú tárolás: nem használható klasszikus fájlrendszerként vagy adatbázisként
  • Adathozzáférési költségek: külön díj vonatkozik a letöltésre és a zónák közti adatmozgásra
  • Verziókövetés és lifecycle beállítások külön konfigurációt igényelnek
  • Nem helyettesíti az adatmentési stratégiát önmagában, különösen, ha más régióba vagy platformra is kell menteni

Összefoglalás

Az Amazon S3 egy megbízható, skálázható és költséghatékony megoldás adataink felhőben történő tárolására. A különböző tárolási osztályok és a könnyű integrálhatóság révén ideális választás kezdő és haladó felhasználók számára is. Legyen szó statikus weboldalról, adatarchiválásról vagy éppen alkalmazások kiszolgálásáról, az S3 minden esetben biztos alapot nyújt.

Ha még nem próbáltad ki, hozz létre egy saját bucket-et az AWS konzolban, és tölts fel egy fájlt – így első kézből tapasztalhatod meg, milyen egyszerű a használata.

amazon-eks-featured-final

Kubernetes az AWS-ben? Ismerd meg az Amazon EKS erejét

, , , , , , , , , , , ,

| Olvasási idő: 4 perc |
  • Erőforrás típus: IaaS
  • Felhő szolgáltató: Amazon Web Services
  • Angol név: Elastic Kubernetes Service
  • Magyar név: Elastic Kubernetes Service
  • Rövidített név (ha van ilyen): EKS

Ma is egy Kubernetes-el foglalkozó cikket hoztam nektek. És ma is egy olyan Kubernetes szolgáltatást nézünk meg közelebbről, amely közben felhőszolgáltató specifikus is.

Azt már többször többféle módon is elmondtam, hogy a konténertechnológia forradalmasította a modern alkalmazásfejlesztést (a legismertebb konténertechnológiai megoldás a Docker): egyszerűbbé vált az alkalmazások csomagolása, szállítása és futtatása különböző környezetekben. Az Azure Kubernetes Service (AKS) ebbe a világba nyújt belépőt, méghozzá teljes mértékben menedzselt formában. A kezdők számára különösen előnyös, mert elrejti a komplexitás nagy részét, miközben erős kontrollt és rugalmasságot biztosít.

Az Amazon Elastic Kubernetes Service (EKS) egy menedzselt Kubernetes-szolgáltatás az AWS-en, amely lehetővé teszi a konténeres alkalmazások egyszerű futtatását, skálázását és biztonságos üzemeltetését. Ha modern alkalmazásokkal dolgozol, és szeretnéd kihasználni a Kubernetes nyújtotta rugalmasságot anélkül, hogy a fürtkezelés technikai részleteivel kellene foglalkoznod, az EKS ideális választás lehet.

Mi az Amazon EKS?

Az Amazon EKS a Kubernetes nyílt forráskódú rendszerét kínálja menedzselt formában. Ez azt jelenti, hogy az AWS üzemelteti a Kubernetes vezérlősíkját, így neked nem kell bajlódnod a vezérlősík (control plane) telepítésével, frissítésével, vagy a rendelkezésre állás biztosításával. Az EKS lehetővé teszi, hogy a megszokott kubectl parancsokkal és deklaratív YAML-fájlokkal dolgozz, miközben kihasználod az AWS infrastruktúra erejét.

EKS felépítése

Az EKS-ben két fő összetevővel találkozol:

  • Vezérlősík (control plane): Teljes mértékben az AWS kezeli. Automatikusan elérhető és hibatűrő.
  • Munkacsomópontok (worker nodes): Ezek az EC2 példányok (vagy Fargate egységek), amelyeken a kapszulák (pods) ténylegesen futnak.

Az EKS támogatja az EC2 alapú, Fargate alapú, vagy ezek kombinációjából álló fürtöket is, így választhatsz a teljes kontroll (EC2) vagy a szerver nélküli működés (Fargate) között.

EKS erősségei

  • Felügyelt Kubernetes: Nem kell telepítened vagy karbantartanod a Kubernetes vezérlő komponenseit.
  • Biztonság: Az AWS integráció lehetővé teszi az IAM-alapú hitelesítést és az egyéb biztonsági eszközök (pl. Secrets Manager, KMS) használatát.
  • Integráció más AWS szolgáltatásokkal: Könnyen összeköthető például az ELB-vel, CloudWatch-csal, vagy az IAM-mel.
  • Skálázhatóság: Használhatsz automatikus skálázást az EC2 Auto Scaling Group-ok vagy a Kubernetes Horizontal Pod Autoscaler révén.
  • Sztenderd Kubernetes: A nyílt forráskódú Kubernetes-t használja, így hordozhatóságot biztosít más környezetek felé is (pl. on-premise vagy más felhők).

EKS korlátai

  • Összetettebb kezdeti beállítás: A konfigurálás komplexebb lehet, mint más, egyszerűbb konténeres szolgáltatásoknál (pl. App Runner).
  • Költségek: Az EKS control plane külön díjat számol fel (ez nagyjából 70 EUR havonta), az EC2 példányok vagy Fargate egységek díján felül.
  • Tanulási idő: A Kubernetes alapjainak elsajátítása időt igényel, főként azok számára, akik most ismerkednek vele.

Mikor érdemes EKS-t használni?

Az EKS különösen akkor hasznos, ha:

  • Már Kubernetes-t használsz helyben vagy más felhőben, és szeretnél migrálni AWS-re.
  • Mikroszolgáltatás-alapú, skálázható és konténeresített alkalmazásokat futtatsz.
  • Fontos számodra a rugalmas, nyílt szabványokon alapuló infrastruktúra.
  • Nagyobb cégek számára, ahol a felhő más szolgáltatásait is ki tudja használni.

Felhasználási esetek

Tegyük fel, hogy egy SaaS alkalmazást építesz (egy több ezer felhasználót kiszolgáló webshop ahol blog is található), amelyet folyamatosan frissítened kell. Több mikroszolgáltatásból áll, ekkor az alábbiakat fogod mindenképpen használni: hitelesítés (felhasználói bejelentkezések), termékkatalógus, rendeléskezelés, hírlevelek, stb. Az EKS lehetővé teszi, hogy ezeket elkülönítve futtasd kapszulákban, frissítsd őket „rolling deployment”-el, és automatikusan skálázd a forgalom (terhelés) alapján. Közben mindezt úgy, hogy nem kell a Kubernetes fürtöd vezérlősíkját manuálisan karbantartanod.

Emellett azért is hasznos az EKS, mert az AWS többi szolgáltatásával együtt, bármilyen komplex és biztonságilag kifogástalan megoldást meg lehet vele valósítani. Például lehetővé válik az EKS integrálása a VMware Cloud on AWS-sel. Ezzel együtt használjuk az AWS DevOps eszközöket az alkalmazások modernizálásának felgyorsításához.

Ezzel csupán azt szerettem volna szemléltetni, hogy „felhőben bármi lehetséges”.

Milyen más Docker-alapú szolgáltatások érhetők el az AWS-ben?

Az AWS több más konténeres szolgáltatást is kínál, amelyekről részletesen külön cikkekben is olvashatsz:

  • Amazon ECS (Elastic Container Service): AWS-specifikus konténerorchesztrátor, egyszerűbb, mint Kubernetes.
  • AWS Fargate: Szerver nélküli konténer futtatási lehetőség, amelyet EKS-szel vagy ECS-sel kombinálhatsz.
  • Amazon App Runner: Egyszerű konténer-alapú webalkalmazás telepítés.
  • AWS Lambda (konténer támogatással): Rövid ideig futó funkciók konténer image-ből.
  • AWS Batch: Nagy számítási igényű kötegfeldolgozás konténerek segítségével.
  • Amazon Lightsail (konténer támogatással): Egyszerű, kezdőknek szánt konténeres alkalmazás hosztolás.

Összefoglalás

Az Amazon EKS azok számára ideális, akik Kubernetes-t szeretnének használni az AWS környezetében anélkül, hogy a vezérlősík üzemeltetésével bajlódnának. Robusztus, skálázható és integrálható megoldás, ugyanakkor komplexebb bevezetést igényel, mint más konténeres szolgáltatások. Ha hosszú távú, mikroszolgáltatás-alapú stratégiában gondolkodsz, az EKS megbízható alap lehet.

Ha most ismerkedsz a Kubernetes világával, az EKS tökéletes kiindulópont. Ne csak olvass róla – gyakorolj, építs, és lépj egy szinttel feljebb a felhőben!

A költségekkel okosan. 🙂

azure_aks_highlight

Konténerek kezelése egyszerűen: Bevezetés az Azure AKS-be

, , , , , , , , , , , ,

| Olvasási idő: 4 perc |
  • Erőforrás típus: IaaS
  • Felhő szolgáltató: Microsoft Azure
  • Angol név: Azure Kubernetes Service
  • Magyar név: Azure Kubernetes Service
  • Rövidített név (ha van ilyen): AKS

Az elmúlt hetekben rengeteg Kubernetes-el foglalkozó cikket zúdítottam már rátok. Ez nem fog változni a közeljövőben sem, azonban ma egy olyan Kubernetes szolgáltatást nézünk meg közelebbről, amely közben felhőszolgáltató specifikus is.

Azt már többször többféle módon is elmondtam, hogy a konténertechnológia forradalmasította a modern alkalmazásfejlesztést (a legismertebb konténertechnológiai megoldás a Docker): egyszerűbbé vált az alkalmazások csomagolása, szállítása és futtatása különböző környezetekben. Az Azure Kubernetes Service (AKS) ebbe a világba nyújt belépőt, méghozzá teljes mértékben menedzselt formában. A kezdők számára különösen előnyös, mert elrejti a komplexitás nagy részét, miközben erős kontrollt és rugalmasságot biztosít.

Mi az az Azure AKS?
Az Azure Kubernetes Service (AKS) a Microsoft Azure felhőplatformjának menedzselt Kubernetes-szolgáltatása. Lehetővé teszi konténerizált alkalmazások automatikus üzembe helyezését, kezelését, skálázását és monitorozását anélkül, hogy külön kellene gondoskodni a Kubernetes-fürt (cluster) telepítéséről és karbantartásáról.

Miért előnyös az AKS használata?

  • Menedzselt vezérlőréteg
    A Kubernetes vezérlőelemeit (control plane) teljesen menedzseli az Azure – így ezek frissítése, méretezése és biztonsági javítása nem a fejlesztőcsapat feladata.
  • Automatikus skálázás
    Támogatja a vízszintes pod-autoskalázást (HPA), node pool szintű autoskalázást, valamint a manualis skálázást is.
  • Integráció az Azure ökoszisztémával
    Könnyen integrálható más Azure szolgáltatásokkal, például Azure Monitor, Log Analytics, Key Vault, EntraID (Azure AD), vagy az Application Gateway-vel.
  • Támogatás Windows és Linux node poolokra
    Lehetőség van hibrid környezetek létrehozására is, ahol egyes szolgáltatások Windows, mások Linux konténerként futnak.
  • RBAC és identitáskezelés
    Az Azure AD integráció segítségével szabályozhatjuk, ki mit tehet a fürtben (Role-Based Access Control).
  • Frissítési stratégia testreszabása
    A cluster frissítések tervezetten, lépésenként is végrehajthatók, hogy minimalizáljuk a leállást.

Korlátok, amikkel érdemes számolni

  • Control Plane testreszabhatósága korlátozott
    Mivel menedzselt szolgáltatás, bizonyos alacsony szintű beállításokhoz nincs hozzáférés.
  • Sokféle beállítási lehetőség, ami összezavarhatja a kezdőket
    Bár a vezérlőréteg menedzselt, a node poolok, hálózatkezelés, tárolók és jogosultságok konfigurálása összetett lehet.
  • Hosszabb indulási idő
    A node poolok indulása néhány perctől akár 10-15 percig is eltarthat, főleg ha új skálázást kérünk.

Mikor érdemes az AKS-t választani?
Az AKS ideális választás, ha:

  • Több mikroalkalmazást futtatnál egységes környezetben
  • DevOps pipeline-t szeretnél kiépíteni CI/CD-vel
  • Folyamatosan skálázódó alkalmazásokat futtatsz
  • Hosszú távon Kubernetes-es megközelítést szeretnél alkalmazni

Felhasználási példa: Webalkalmazás CI/CD pipeline-nal
Egy több részből álló webalkalmazás (pl. frontend, backend, adatbázis) konténerizált formában van tárolva. Az alkalmazás képfájlai pedig az Azure Container Registry-ben (ACR).

Az AKS lehetővé teszi ezen konténerek fürtbe szervezését. GitHub Actions vagy Azure DevOps használatával CI/CD pipeline-t építhetünk, amely automatikusan telepíti és frissíti az alkalmazás egyes komponenseit a Kubernetes-fürtbe.

A forgalmat Azure Application Gateway vagy Ingress Controller segítségével lehet terelni, míg a logokat Azure Monitorban gyűjthetjük.

Milyen más Azure szolgáltatások támogatják még a Docker-konténereket?
Bár az AKS a legteljesebb konténerkezelési megoldás, az Azure több más konténeres megoldást is kínál, amelyekről külön cikkekben olvashatsz:

  • Azure Container Instances (ACI): Egyszerűbb, rövid életű konténerekhez ideális
  • Azure Container Apps: Serverless konténer platform KEDA és Dapr támogatással
  • Azure App Service for Containers: Webalkalmazások konténerizált verziója
  • Azure Functions with custom containers: Egyedi konténeres serverless megoldások
  • Azure Spring Apps: Spring Boot alkalmazások futtatása konténerekben
  • Azure Dev Spaces (megszűnt): Fejlesztői környezet AKS-en belül
  • Azure Arc-enabled Kubernetes: Saját Kubernetes-fürtök Azure-ból való menedzsmentje

Összefoglalás
Az Azure Kubernetes Service (AKS) ideális választás azok számára, akik szeretnének skálázható, rugalmas, mikroszolgáltatás-alapú architektúrát kialakítani konténerek használatával, anélkül hogy a Kubernetes teljes komplexitásával kellene nap mint nap megküzdeniük. Az AKS lehetőséget ad a fejlődésre: kezdőként is elkezdhetjük, de haladó szintig is skálázhatjuk tudásunkat benne.

Azt azért megjegyezném, hogy egy AKS cluster fenntartása és üzemeltetése nem olcsó mulattság. Mielőtt kipróbálod, – márpedig ki kell próbálnod – ellenőrizd a díjkalkulátor segítségével, hogy mennyibe kerülne.

vpc-highlight

Amazon VPC és Subnet alapok: építs biztonságos hálózatot

, , , , , , , ,

| Olvasási idő: 5 perc |
  • Erőforrás típus: IaaS
  • Felhő szolgáltató: Amazon Web Services
  • Angol név: Virtual Private Cloud
  • Magyar név: Virtuális Hálózat
  • Rövidített név (ha van ilyen): VPC

A virtuális hálózat

A virtuális hálózat egy logikai izolációs réteg, amely a felhőben létrehozott erőforrásaink közötti stabil, gyors és biztonságos kommunikáció biztosítja.

Felhőben a virtuális hálózat, a hagyományos informatikai fizikai hálózat virtuális megvalósítása. Ennek megfelelően működése majdnem tejesen ugyanúgy történik. Ha valakinek van ismerete a hagyományos informatikai hálózattal kapcsolatban, akkor a virtuális hálózatban is könnyedén el tud igazodni.

Ezekkel a sorokkal kezdtem az Azure VNET cikkemet korábban. És ide is tökéletesen illenek ezek a mondatok.

Az Amazon Virtual Private Cloud (röviden VPC) az AWS egyik alapszolgáltatása, amely lehetővé teszi, hogy saját, „elszigetelt” hálózatot hozzunk létre a felhőben. A VPC segítségével úgy tervezhetjük meg a hálózati környezetünket, mintha az egy helyi adatközpont lenne – csak éppen az Amazon infrastruktúráján fut.

Ez a megoldás különösen fontos minden olyan felhős architektúrában, ahol az adatbiztonság, az irányíthatóság (IT governance) és a skálázhatóság egyszerre fontos szempont.

Mi az a VPC?

A Virtual Private Cloud (VPC) egy logikailag elkülönített hálózati tér az AWS-en belül. Olyan, mint egy saját kis adatközpont a felhőben, amelyben te határozod meg:

  • a használt IP-tartományt (CIDR blokk),
  • az elérhető alhálózatokat (Subneteket),
  • az internetkapcsolat módját,
  • a forgalom szűrését és engedélyezését.

A VPC-ben te kontrollálod, hogy melyik erőforrás honnan érhető el, legyen szó publikus vagy privát elérésről.

Mi az a Subnet?

A VPC-n belül alhálózatokat (Subnet) hozunk létre. Ezek lehetnek:

  • Publikus alhálózatok: az itt futó erőforrások (pl. EC2 példányok) közvetlenül elérhetők az internetről.
  • Privát alhálózatok: az itt található erőforrások csak a VPC-n belülről érhetők el, külső elérésük jellemzően NAT Gateway-en vagy VPN-en keresztül történik.

A subnetek lehetnek különböző Availability Zone-ökben, ezáltal biztosítva a magas rendelkezésre állást.

Konkrét példa

Példa 1 – IPv4-alapú VPC

VPC címtartománya:
10.0.0.0/16 (Elérhető ip címek: 10.0.0.1 – 10.0.255.254. Összesen: 65534)

Subnetek (külön AZ-ben):

  • Subnet 1: 10.0.0.0/24 – elhelyezés: eu-central-1a (Elérhető ip címek: 10.0.0.1 – 10.0.0.254. Összesen: 254)
  • Subnet 2: 10.0.1.0/24 – elhelyezés: eu-central-1b (Elérhető ip címek: 10.0.1.1 – 10.0.1.254. Összesen: 254)
  • Subnet 3: 10.0.2.0/24 – elhelyezés: eu-central-1c (Elérhető ip címek: 10.0.2.1 – 10.0.2.254. Összesen: 254)

Kiegészítések:

  • Internet Gateway csatlakoztatva a VPC-hez
  • Subnet 1 publikus (útvonaltábla: 0.0.0.0/0 → IGW)
  • Subnet 2 és Subnet 3 privát, kimenő forgalomhoz NAT Gateway használva
  • Alkalmazás: web frontend a Subnet 1-ben, backend a Subnet 2-ben, adatbázis a Subnet 3-ban

IP cím tartományokat Te magad is ellenőrizheted: https://jodies.de/ipcalc

Példa 2 – IPv6-alapú VPC

VPC IPv6 címtartománya:
Automatikusan kiosztva az AWS által, pl.: 2600:abcd:1234::/56

Subnetek (külön AZ-ben):

  • Subnet A: 2600:abcd:1234:1000::/64 – elhelyezés: eu-central-1a
  • Subnet B: 2600:abcd:1234:2000::/64 – elhelyezés: eu-central-1b
  • Subnet C: 2600:abcd:1234:3000::/64 – elhelyezés: eu-central-1c

Kiegészítések:

  • Internet Gateway IPv6-ra is használható (útvonaltábla: ::/0)
  • Nincs NAT IPv6-ra – az erőforrások közvetlenül elérik az internetet, ha útvonal engedi
  • Javasolt: biztonsági szabályokkal szigorúan szabályozni az elérhetőséget
  • Alkalmazás: publikus IPv6-címmel rendelkező frontend EC2 példány, belső szolgáltatások IPv6-címmel, de szűrt eléréssel

Miért fontos a VPC?

Az alapértelmezett VPC-t minden AWS-fiók tartalmaz, de a legtöbb komolyabb projekt saját, testreszabott VPC-t igényel. Ez lehetővé teszi:

  • a részletes biztonsági szabályozást,
  • a hálózati struktúra tudatos kialakítását,
  • és a felhőerőforrások biztonságos, jól átlátható kezelését.

VPC-hez kapcsolódó fontosabb fogalmak

A VPC-t számos kapcsolódó komponens egészíti ki, amelyek külön cikkek témái lesznek, de fontos most megemlíteni őket, hogy lásd, milyen lehetőségek rejlenek a szolgáltatásban:

  • Internet Gateway: lehetővé teszi, hogy egy alhálózat publikus legyen, és az erőforrások internettel kommunikálhassanak.
  • NAT Gateway / NAT Instance: privát alhálózatból lehet vele kimenő forgalmat irányítani az internet felé, anélkül, hogy a bejövő forgalmat engedélyeznénk.
  • VPN Gateway és AWS Client VPN: biztonságos, titkosított kapcsolatot alakítanak ki a saját irodai hálózat és az AWS VPC között.
  • Peering: VPC-k közötti kapcsolatot tesz lehetővé.
  • Security Group: tűzfalként működik az erőforrások (pl. EC2) körül – csak az engedélyezett forgalmat engedi át.
  • Network ACL: alhálózati szintű forgalomszűrő, kiegészítő védelmet nyújt.

Milyen esetekben érdemes saját VPC-t létrehozni?

  1. Webalkalmazások üzemeltetése
    Külön subnet-ekben futtathatod a publikus (frontend) és privát (backend, adatbázis) komponenseket, így jobban kontrollálható a hozzáférés és a biztonság.
  2. Adatbiztonság és megfelelőség
    Szabályozhatod, hogy az adatok fizikailag hol legyenek (pl. melyik régióban), és hogyan lehet hozzájuk férni.
  3. Hibrid IT környezetek
    VPN segítségével a helyi adatközpontodat összekötheted a VPC-vel, így egységes hálózatként kezelheted az infrastruktúrádat.
  4. Microservice architektúra kiépítése
    Szolgáltatások szegmentálása subnetekbe, központi kommunikációs szabályokkal és forgalomirányítással.

Lehetőségek és korlátok

Erősségek:

  • Teljes kontrol a hálózat felett
  • Széleskörű biztonsági lehetőségek
  • Komplex, de skálázható hálózati struktúrák kialakítása

Korlátok:

  • Az összetettebb VPC-k menedzselése több szakértelmet igényel
  • Az egyes komponensek külön költséggel járhatnak (pl. NAT Gateway, VPN)

Összefoglalás

Az Amazon VPC egy elengedhetetlen építőelem minden komolyabb AWS architektúrában. Segítségével biztonságos, testreszabott hálózati környezetet hozhatsz létre. Már a kezdeteknél érdemes jól átgondolt VPC struktúrát kialakítani, így elkerülhetők a későbbi átalakítások, és hosszú távon stabil, skálázható rendszert építhetsz.

Ha szeretnéd kipróbálni, az AWS Management Console-ban néhány kattintással létrehozhatsz egy saját VPC-t a „VPC Wizard” segítségével.

kubernetes-pod-concept

Kapszulák, konténerek és indulási sorrend a Kubernetes-ben

, , , , , , , ,

| Olvasási idő: 4 perc |

A Kubernetes az egyik legnépszerűbb konténer-orchesztrációs megoldás, amelyet világszerte alkalmaznak modern, skálázható és megbízható rendszerek építéséhez. A Kubernetes működésének alapját a kapszula (angolul: Pod) fogalma adja. Ez a legkisebb olyan egység, amelyet a Kubernetes kezelni tud.

Habár, mielőtt a K8s világába csöppennénk először a konténerek világával szoktunk megismerkedni. Ezen belül is a Docker szokott az első lépés lenni. Ha Te ez neked is ismerős, akkor furcsa lehet, hogy ott konténereket (angolul: container) kezelünk. Itt mégis a kapszulákat említünk.

Tehát itt nem magával a konténerrel dolgozunk közvetlenül, hanem ezzel a „kapszulázott” egységgel. Ma arról szeretnék nektek írni, hogyan működnek a kapszulák, hogyan épülnek fel, hogyan indulnak el, és hogyan segítik az init konténerek és a sidecar minták a stabil működést.

Mi az a kapszula (Pod)?

A kapszula egy vagy több konténerből áll, amelyeket egy logikai egységként kezelünk. Ezek a konténerek:

  • osztoznak ugyanazon IP-címen, amit a Kubernetes hozzárendelt a kapszulához,
  • közös tárolókat használhatnak (pl. emptyDir típusú ideiglenes fájlrendszer),
  • együtt futnak ugyanazon a csomóponton (node-on).

A kapszula úgy képzelhető el, mint egy konténercsoport, amely egy folyamat (pl. webalkalmazás) futtatására jött létre, és amelynek egyes részei (pl. naplózó eszköz) ugyanabban a környezetben futnak.

Egy vagy több konténer egy kapszulában?

A legtöbb esetben egy kapszula = egy alkalmazáskonténer. Ez a tiszta és egyszerű megközelítés jól működik. Azonban vannak olyan helyzetek, amikor egy kapszulán belül több konténerre van szükség:

  • Segédkonténer (sidecar): naplózáshoz vagy proxy-záshoz
  • Adapter konténer: régi interfészek kiszolgálására
  • Ambassador konténer: más szolgáltatások eléréséhez

Ezek a konténerek együttesen működnek, megosztják az erőforrásokat, és logikailag egy egységet képeznek. Fontos: nem különleges típusú konténerek ezek – a “sidecar” vagy “adapter” kifejezés csak szerepet jelöl, nem technikai különbséget. Tehát minden konténer ugyanúgy épül fel, csupán más szerepkört szánunk neki.

Indítási sorrend és problémák

A Kubernetes úgy lett tervezve, hogy a kapszulán belüli konténereket párhuzamosan indítsa el. Ez teljesen rendben van, ha az egyes konténerek nem függenek egymástól. De mi történik, ha egyik konténernek előbb készen kell állnia a másik előtt?

Példa:

  • Egy adatbázist csak akkor akarunk használni, ha már elérhető és inicializálva van.
  • Egy webalkalmazás csak akkor indulhat, ha a konfigurációs fájlok már betöltődtek.

Erre nyújt megoldást az init konténer.

Init konténerek: előkészítés garantált sorrenddel

Az init konténer egy olyan konténer, amely a fő alkalmazáskonténerek előtt indul el, és csak akkor indul tovább a többi konténer, ha az init konténer sikeresen befejezte a feladatát.

Tulajdonságai:

  • Teljesen független a fő konténerektől
  • Saját képpel és jogosultságokkal rendelkezhet
  • Ha hibásan fut, a fő konténerek nem indulnak el
  • Addig ismétlődik az indítás, amíg sikeresen le nem fut

Ez lehetővé teszi például, hogy:

  • megvárjuk egy adatbázis elérhetőségét,
  • végrehajtsunk fájlműveleteket vagy jogosultság-módosításokat, amelyekhez az alkalmazáskonténer nem fér hozzá.

Példa YAML definíció:

 containers:
 - name: main-app
 image: databaseD
 initContainers:
 - name: wait-database
 image: busybox
 command: ['sh', '-c', 'until ls /db/dir ; do sleep 5; done;']

Ebben az esetben a fő alkalmazáskonténer csak akkor indul el, ha a /db/dir mappa elérhető. Ugye milyen hasznos ez?

Erőforrás-korlátozás kapszulán belül

A Kubernetes lehetőséget ad arra, hogy minden konténer számára meghatározzuk, mekkora erőforrást kérhet és használhat:

resources:
 limits:
 cpu: "1"
 memory: "4Gi"
 requests:
 cpu: "0.5"
 memory: "500Mi"
  • A requests érték az a minimális erőforrás, amit a konténer igényel.
  • A limits érték az a maximum, amit a konténer fogyaszthat.

Ezeket az értékeket a kapszula leírásánál kell megadni, és a Kubernetes ennek megfelelően ütemezi be a kapszulát a fürt egyik csomópontjára.

ResourceQuota: névtér szintű korlátok

Ha azt szeretnénk, hogy a különböző felhasználók vagy csapatok ne lépjék túl az erőforráskeretüket, használhatunk ResourceQuota objektumokat:

  • Korlátozható a CPU, memória, podok, szolgáltatások, tárolók száma stb.
  • A scopeSelector mezővel például prioritás alapján is szabályozhatjuk a pod futtatását

Ez segít a fürt egészének stabil működésében, és megelőzi, hogy valaki túl sok erőforrást foglaljon le véletlenül vagy szándékosan.

Mit kezdjünk régi, monolitikus alkalmazásokkal?

Sok szervezetnél felmerül a kérdés: hogyan helyezzük át a régi (monolitikus) alkalmazásokat Kubernetes környezetbe?

Két megközelítés van:

  1. Konténerizálás, ahogy van – az alkalmazás teljes egészében bekerül egy kapszulába, minimális módosítással. Gyorsabb és olcsóbb megoldás, de korlátozott rugalmasságot ad.
  2. Újratervezés mikroszolgáltatásként – az alkalmazás komponenseit különálló kapszulákba és szolgáltatásokba bontjuk, hogy teljes mértékben kihasználjuk a Kubernetes előnyeit. Idő- és erőforrás-igényesebb, de jövőállóbb.

Egy egyszerű hasonlat:

  • A monolitikus alkalmazás olyan, mint egy városi busz: mindent egyszerre visz, de nem túl rugalmas.
  • A mikroszolgáltatás-alapú rendszer olyan, mint egy robogóflotta (pl.: Lime): kicsi, gyors, önállóan mozog, de jól kell koordinálni.

Összefoglalás

A Kubernetes kapszulái olyan, mint a konténerek futtatásának biztonságos és jól szabályozható “csomagolása”. Az init konténerek lehetőséget adnak a folyamatok sorrendjének kézben tartására, a sidecar konténerek pedig kiterjesztik az alkalmazás funkcionalitását. A precíz erőforráskezelés (limits, quota) elengedhetetlen a fürt stabil működéséhez.

Végezetül: ha régi alkalmazást szeretnél Kubernetes-be hozni, gondold át, mit nyersz a mikroszolgáltatás-alapú újratervezéssel, és hol elég a meglévő alkalmazás konténerizálása.

Ha elakadsz, akkor keress engem és segítek.

kubernetes-kubelet-operators-service

A K8s kulcsszereplői: Kubelet, Operátorok és Szolgáltatások

, , , , , , , , ,

| Olvasási idő: 3 perc |

Az elmúlt néhány alkalommal a Kubernetes architekturális felépítéséről olvashattál. Beszéltünk a Contol Plane-ről és a Worker Node-okról. Most tovább folytatjuk utazásunkat ezen a területen.

A Kubernetes működésének megértéséhez fontos, hogy ismerjük azokat az alapvető komponenseket, amelyek a rendszer „láthatatlan motorjai”. Ebben a cikkben három ilyen kulcsszereplőt mutatok be: a kubeletet, az operátorokat és a szolgáltatásokat. Ezek együttműködése biztosítja, hogy a konténeralapú alkalmazások megbízhatóan és skálázhatóan fussanak a fürtben (cluster).

Kubelet: a node-ok gondnoka

A kubelet a worker node-okon futó ügynök, amelynek feladata, hogy végrehajtsa a fürt vezérlőkomponenseitől érkező utasításokat. Minden egyes node-on található egy példány belőle.

A kubelet főbb feladatai:

  • PodSpec értelmezése: Minden kapszula (pod) egy specifikáció (PodSpec) alapján jön létre. A kubelet ezt dolgozza fel, és biztosítja, hogy a node elérje a kívánt állapotot.
  • Hozzáférés biztosítása a kötetekhez, titkokhoz és konfigurációkhoz: Ha a kapszula igényel persistent storage-ot, Secret-et vagy ConfigMap-et, a kubelet intézi ezek elérhetőségét.
  • Konténer indítás: Az utasításokat továbbítja a helyi konténerfuttató motor (pl. containerd vagy CRI-O) felé.
  • Állapotjelentés: Folyamatosan visszajelzést küld a kube-apiservernek a kapszulák és a node állapotáról.
  • Erőforrás-kezelés: Egyes fejlettebb funkciók, mint például a NUMA-topológiára érzékeny CPU vagy gyorsító hardver hozzárendelés, a Topology Manager segítségével történik.

Operátorok: az automatizált felügyelők

Az operátorok – más néven kontrollerek vagy figyelő ciklusok (watch-loops) – a Kubernetes szíve-lelke. Ezek felelősek azért, hogy a fürt állapota megfeleljen a kívánt állapotnak. Minden operátor egy adott erőforrást (például Pod, Namespace, ServiceAccount) kezel.

Hogyan működnek?

  • Informer és cache: Az operátor egy úgynevezett Informer komponensen keresztül kérdezi le az API szervertől az erőforrás aktuális állapotát. Az adatokat cache-eli, hogy minimalizálja az API hívások számát.
  • DeltaFIFO: A módosításokat egy DeltaFIFO nevű sorban kezeli, és a változások (delták) alapján dönt, hogy mi a teendő.
  • Feldolgozás: Az operátor logikája alapján végrehajtja a szükséges lépéseket (például új kapszula létrehozása vagy meglévő módosítása).
  • Workqueue: A különböző feladatokat munkamenet-sorokon keresztül osztja szét a háttérfolyamatok között, amelyek kezelik az eseményeket.

Példák beépített operátorokra:

  • Endpoints operator: Kezeli a kapszulák elérési pontjait.
  • Deployments: A replikakészleteket (ReplicaSet) vezérli, amelyek azonos PodSpec alapján több kapszulát indítanak.

Szolgáltatás operátor: a hálózati kapcsolatok kapuőre

A Kubernetesben a kapszulák IP címei múlékonyak, így egy állandó elérési mód biztosítására van szükség. Ezt a szolgáltatások (Services) biztosítják, amelyek mögött egy speciális operátor – a szolgáltatás operátor – áll.

Feladatai:

  • Tartós IP-cím biztosítása: A szolgáltatás egy stabil IP-címet biztosít a mögöttes kapszulákhoz, még akkor is, ha a kapszulák újraindulnak vagy kicserélődnek.
  • Kapszulák összekapcsolása: A szolgáltatás operátor figyeli az endpoint operátort, hogy naprakész legyen abban, mely kapszulák tartoznak a szolgáltatáshoz.
  • Kommunikáció a hálózattal: Az operátor a kube-apiserveren keresztül eljuttatja a szükséges beállításokat a kube-proxy-nak és a használt hálózati pluginnak (pl. Cilium).
  • Hozzáférési szabályok kezelése: Meghatározza, hogy kik és milyen módon érhetik el a szolgáltatás mögött álló kapszulákat. Ez nemcsak a forgalomirányítás, hanem a biztonság szempontjából is fontos.

Összegzés

A Kubernetes belső működése több komponens összehangolt munkáján alapul. A kubelet biztosítja, hogy a node-ok megfeleljenek az elvárt állapotnak. Az operátorok figyelik a rendszer változásait, és aktívan fenntartják az erőforrások kívánt konfigurációját. A szolgáltatás operátor pedig lehetővé teszi, hogy a kapszulák hálózaton keresztül is stabilan és biztonságosan elérhetők legyenek.

E három komponens együttműködése biztosítja a Kubernetes megbízhatóságát, rugalmasságát és önjavító képességét – ezek teszik lehetővé, hogy a modern felhőalapú alkalmazások skálázhatóan és hibatűrő módon működjenek.

Load More