A Netflix vezető szerepet tölt be az internetes televíziós piacon - ez a cég létrehozta és aktívan fejleszti ezt a szegmenst. A Netflix nemcsak a bolygó szinte minden szegletéből elérhető filmek és TV-sorozatok kiterjedt katalógusáról és minden kijelzős eszközről ismert, hanem megbízható infrastruktúrájáról és egyedi mérnöki kultúrájáról is.
A DevOops 2019 kiállításon bemutatták a Netflix komplex rendszerek fejlesztésére és támogatására irányuló megközelítésének egyértelmű példáját. - A Netflix fejlesztési igazgatója. Végzett a Nyizsnyij Novgorodi Állami Egyetem Számítástechnikai Matematikai és Matematikai Karán. Lobacsevszkij, Szergej az Open Connect – CDN csapat egyik első mérnöke a Netflixnél. Kiépített rendszereket a videoadatok figyelésére és elemzésére, elindított egy népszerű szolgáltatást az internetkapcsolat sebességének felmérésére a FAST.com-on, és az elmúlt néhány évben azon dolgozik, hogy optimalizálja az internetes kéréseket, hogy a Netflix alkalmazás a lehető leggyorsabban működjön a felhasználók számára.
A beszámoló a legjobb értékeléseket kapta a konferencia résztvevőitől, mi pedig elkészítettük Önnek egy szöveges változatát.
Szergej beszámolójában részletesen beszélt
- arról, hogy mi befolyásolja a kliens és a szerver közötti internetes kérések késését;
- hogyan csökkenthető ez a késés;
- a hibatűrő rendszerek tervezése, karbantartása és felügyelete;
- hogyan lehet rövid időn belül és minimális kockázattal elérni az eredményt;
- hogyan lehet elemezni az eredményeket és tanulni a hibákból.
Ezekre a kérdésekre nem csak a nagyvállalatoknál dolgozóknak van szükségük válaszokra.
A bemutatott elveket és technikákat mindenkinek ismernie és gyakorolnia kell, aki internetes termékeket fejleszt és támogat.
A következő az elbeszélés a beszélő szemszögéből.
Az internet sebességének fontossága
Az internetes kérések sebessége közvetlenül kapcsolódik az üzlethez. Gondoljunk csak a vásárlási ágazatra: az Amazon 2009-ben hogy a 100 ms-os késés az eladások 1%-os kiesését eredményezi.
Egyre több a mobileszköz, ezt követik a mobil oldalak és alkalmazások. Ha az oldal betöltése 3 másodpercnél tovább tart, akkor a felhasználók körülbelül felét elveszíted. VAL VEL A Google figyelembe veszi az oldal betöltési sebességét a keresési eredmények között: minél gyorsabb az oldal, annál magasabb a pozíciója a Google-ban.
A kapcsolat sebessége olyan pénzintézeteknél is fontos, ahol a késleltetés kritikus. 2015-ben a Hibernia Networks egy 400 millió dolláros kábel New York és London között, hogy 6 ms-al csökkentse a városok közötti késleltetést. Képzeljen el 66 millió dollárt 1 ms-os késleltetéscsökkentésért!
Szerint , az 5 Mbit/s feletti kapcsolati sebesség már nem befolyásolja közvetlenül egy tipikus weboldal betöltési sebességét. A kapcsolat késése és az oldalbetöltési sebesség között azonban lineáris kapcsolat van:
A Netflix azonban nem egy tipikus termék. A késleltetés és a sebesség felhasználóra gyakorolt hatása az elemzés és fejlesztés aktív területe. Létezik a késleltetéstől függő alkalmazásbetöltés és tartalomválasztás, de a statikus elemek betöltése és a streamelés a kapcsolat sebességétől is függ. A felhasználói élményt befolyásoló kulcstényezők elemzése és optimalizálása a Netflix több csapata számára is aktív fejlesztési terület. Az egyik cél a Netflix-eszközök és a felhő-infrastruktúra közötti kérések késleltetésének csökkentése.
A jelentésben a késleltetés csökkentésére összpontosítunk a Netflix infrastruktúra példáján keresztül. Tekintsük gyakorlati oldalról, hogyan közelítsük meg a komplex elosztott rendszerek tervezésének, fejlesztésének és üzemeltetésének folyamatait, és fordítsunk időt az innovációra és az eredményekre, ahelyett, hogy a működési problémákat és meghibásodásokat diagnosztizálnánk.
A Netflixen belül
Különböző eszközök ezrei támogatják a Netflix alkalmazásokat. Négy különböző csapat fejleszti őket, amelyek külön verziót készítenek a kliensből Androidra, iOS-re, TV-re és webböngészőkre. És sok erőfeszítést fordítunk a felhasználói élmény javítására és személyre szabására. Ennek érdekében több száz A/B tesztet futtatunk párhuzamosan.
A személyre szabást az AWS felhő több száz mikroszolgáltatása támogatja, amelyek személyre szabott felhasználói adatokat, lekérdezések küldését, telemetriát, Big Data-t és kódolást biztosítanak. A forgalomábrázolás így néz ki:
A bal oldalon található a belépési pont, majd a forgalom több száz mikroszolgáltatás között oszlik meg, amelyeket különböző háttércsapatok támogatnak.
Infrastruktúránk másik fontos eleme az Open Connect CDN, amely statikus tartalmat juttat el a végfelhasználóhoz – videókat, képeket, klienskódot stb. A CDN egyedi szervereken található (OCA – Open Connect Appliance). A belsejében SSD- és HDD-meghajtók tömbjei vannak, amelyek optimalizált FreeBSD-t futtatnak, NGINX-szel és egy sor szolgáltatással. Úgy tervezzük és optimalizáljuk a hardver- és szoftverkomponenseket, hogy egy ilyen CDN-szerver a lehető legtöbb adatot el tudja küldeni a felhasználóknak.
Ezeknek a szervereknek a „fala” az internetes forgalom cserepontján (Internet eXchange - IX) így néz ki:
Az Internet Exchange lehetőséget biztosít az internetszolgáltatók és tartalomszolgáltatók számára, hogy „kapcsolatba lépjenek” egymással az interneten történő közvetlenebb adatcsere érdekében. Körülbelül 70-80 Internet Exchange pont található szerte a világon, ahol a szervereinket telepítjük, és mi önállóan telepítjük és karbantartjuk őket:
Emellett közvetlenül az internetszolgáltatóknak is biztosítunk szervereket, amelyeket ők telepítenek a hálózatukra, javítva ezzel a Netflix forgalom lokalizációját és a streaming minőségét a felhasználók számára:
Az AWS-szolgáltatások egy csoportja felelős a kliensektől a CDN-szerverek felé küldött videokérésekért, valamint maguk a szerverek konfigurálásáért - tartalom, programkód, beállítások stb. Utóbbihoz egy gerinchálózatot is építettünk, amely az Internet Exchange pontokban lévő szervereket AWS-szel köti össze. A gerinchálózat az optikai kábelek és útválasztók globális hálózata, amelyet igényeinknek megfelelően tervezhetünk és konfigurálhatunk.
On , CDN-infrastruktúránk a világ internetes forgalmának körülbelül ⅛-át biztosítja csúcsidőben, és a forgalom egyharmadát Észak-Amerikában, ahol a Netflix a legrégebben működik. Lenyűgöző számok, de számomra az egyik legcsodálatosabb eredmény, hogy a teljes CDN-rendszert egy kevesebb mint 150 fős csapat fejleszti és tartja karban.
Kezdetben a CDN infrastruktúrát videoadatok továbbítására tervezték. Idővel azonban rájöttünk, hogy az AWS-felhőben lévő ügyfelektől érkező dinamikus kérések optimalizálására is használhatjuk.
Az internetes gyorsításról
Ma a Netflix 3 AWS-régióval rendelkezik, és a felhőbe irányuló kérések késleltetése attól függ, milyen messze van az ügyfél a legközelebbi régiótól. Ugyanakkor számos CDN-szerverünk van, amelyeket statikus tartalom szállítására használnak. Van valami mód ennek a keretrendszernek a használatával a dinamikus lekérdezések felgyorsítására? Sajnos azonban ezeknek a kéréseknek a gyorsítótárazása lehetetlen – az API-k személyre szabottak, és minden eredmény egyedi.
Készítsünk proxyt a CDN-kiszolgálón, és kezdjük el rajta keresztül küldeni a forgalmat. Gyorsabb lesz?
Materiel
Emlékezzünk a hálózati protokollok működésére. Manapság a legtöbb internetes forgalom HTTP-t használ, amely az alsóbb szintű TCP és TLS protokolloktól függ. Ahhoz, hogy egy kliens csatlakozhasson a szerverhez, kézfogást végez, a biztonságos kapcsolat létrehozásához pedig háromszor kell üzenetet váltania a szerverrel és még legalább egyszer az adatátvitelhez. A 100 ms-os oda-vissza út késleltetése (RTT) esetén 400 ms-ra lenne szükségünk, hogy megkapjuk az első adatbitet:
Ha a tanúsítványokat a CDN szerveren helyezzük el, akkor a kliens és a szerver közötti kézfogási idő jelentősen lecsökkenhet, ha a CDN közelebb van. Tegyük fel, hogy a CDN-kiszolgáló várakozási ideje 30 ms. Ezután 220 ms kell az első bit fogadásához:
De az előnyök ezzel nem érnek véget. A kapcsolat létrehozása után a TCP megnöveli a torlódási ablakot (az az információ mennyiségét, amelyet párhuzamosan továbbíthat a kapcsolaton keresztül). Ha egy adatcsomag elveszik, akkor a TCP protokoll klasszikus implementációi (például a TCP New Reno) felére csökkentik a nyitott „ablak” méretét. A torlódási ablak növekedése és a veszteségből való felépülés sebessége ismét a szerver késleltetésétől (RTT) függ. Ha ez a kapcsolat csak a CDN-kiszolgálóig megy, a helyreállítás gyorsabb lesz. Ugyanakkor a csomagvesztés általános jelenség, különösen a vezeték nélküli hálózatok esetében.
Az internet sávszélessége csökkenhet, különösen csúcsidőben a felhasználóktól érkező forgalom miatt, ami forgalmi dugókhoz vezethet. Az interneten azonban nincs mód arra, hogy egyes kéréseket elsőbbségben részesítsenek másokkal szemben. Például adjon elsőbbséget a kicsi és késleltetésre érzékeny kéréseknek a hálózatot terhelő „nehéz” adatfolyamokkal szemben. A mi esetünkben azonban a saját gerinchálózatunk lehetővé teszi, hogy ezt a kérési útvonal egy részén - a CDN és a felhő között - megtegyük, és teljes mértékben be tudjuk állítani. Győződjön meg arról, hogy a kis és késleltetésre érzékeny csomagok prioritást kapnak, és a nagy adatfolyamok egy kicsit később mennek. Minél közelebb van a CDN az ügyfélhez, annál nagyobb a hatékonyság.
Az alkalmazás szintű protokollok (OSI 7. szint) szintén hatással vannak a késleltetésre. Az új protokollok, például a HTTP/2 optimalizálják a párhuzamos kérések teljesítményét. Vannak azonban Netflix klienseink olyan régebbi eszközökkel, amelyek nem támogatják az új protokollokat. Nem minden kliens frissíthető vagy konfigurálható optimálisan. Ugyanakkor a CDN proxy és a felhő között teljes az irányítás és lehetőség van új, optimális protokollok és beállítások használatára. A régi protokollokkal nem működő rész csak a kliens és a CDN-kiszolgáló között működik. Sőt, a CDN és a felhő között már kialakított kapcsolaton multiplex kéréseket tudunk küldeni, javítva a kapcsolat kihasználtságát TCP szinten:
Mérünk
Annak ellenére, hogy az elmélet fejlesztésekkel kecsegtet, nem rohanunk azonnal a rendszer gyártásba való beindításával. Ehelyett először be kell bizonyítanunk, hogy az ötlet a gyakorlatban is működni fog. Ehhez több kérdésre kell válaszolnia:
- Sebesség: gyorsabb lesz a proxy?
- Megbízhatóság: Gyakrabban fog törni?
- Bonyolultság: hogyan lehet integrálni az alkalmazásokkal?
- Költség: Mennyibe kerül a további infrastruktúra kiépítése?
Tekintsük részletesen az első pont értékelésére vonatkozó megközelítésünket. A többit hasonló módon kezelik.
A kérések sebességének elemzéséhez minden felhasználó adatait szeretnénk megszerezni anélkül, hogy sok időt fordítanának a fejlesztésre és a termelés megszakítására. Ennek több megközelítése is létezik:
- RUM, vagy passzív kérés mérés. Mérjük a felhasználóktól érkező aktuális kérések végrehajtási idejét, és biztosítjuk a teljes felhasználói lefedettséget. Hátránya, hogy a jel sok tényező miatt nem túl stabil, például az eltérő kérésméretek, a szerveren és a kliensen eltöltött feldolgozási idő miatt. Ezenkívül nem tesztelhet új konfigurációt anélkül, hogy az éles folyamatban lenne.
- Laboratóriumi tesztek. Speciális szerverek és infrastruktúra, amelyek szimulálják az ügyfeleket. Segítségükkel elvégezzük a szükséges vizsgálatokat. Így teljes ellenőrzést kapunk a mérési eredmények felett és tiszta jelet kapunk. De nincs teljes körű lefedettség az eszközökről és a felhasználói helyekről (különösen a világszerte elérhető szolgáltatás és több ezer eszközmodell támogatása esetén).
Hogyan lehet kombinálni a két módszer előnyeit?
Csapatunk megtalálta a megoldást. Írtunk egy kis kódrészletet - mintát -, amelyet beépítettünk az alkalmazásunkba. A szondák lehetővé teszik, hogy teljesen ellenőrzött hálózati teszteket végezzünk eszközeinkről. Ez így működik:
- Röviddel az alkalmazás betöltése és a kezdeti tevékenység befejezése után lefuttatjuk a szondákat.
- A kliens kérést küld a szervernek, és megkapja a „receptet” a teszthez. A recept azoknak az URL-eknek a listája, amelyekhez HTTP(k) kérést kell küldeni. Ezenkívül a recept konfigurálja a kérés paramétereit: a kérések közötti késések, a kért adatok mennyisége, a HTTP(k) fejlécek stb. Ugyanakkor párhuzamosan több különböző receptet is tesztelhetünk - konfiguráció kérésekor véletlenszerűen határozzuk meg, hogy melyik receptet adjuk ki.
- A próbaindítási idő úgy van kiválasztva, hogy ne ütközzen a kliens hálózati erőforrásainak aktív használatával. Lényegében az az idő kerül kiválasztásra, amikor a kliens nem aktív.
- A recept kézhezvétele után a kliens párhuzamosan kéri az egyes URL-eket. Az egyes címekre irányuló kérés megismételhető - az ún. "impulzusok". Az első impulzusnál megmérjük, mennyi ideig tartott a kapcsolat létrehozása és az adatok letöltése. A második impulzusnál megmérjük, hogy mennyi idő szükséges az adatok betöltéséhez egy már létrehozott kapcsolaton keresztül. A harmadik előtt beállíthatunk egy késleltetést és mérhetjük a visszakapcsolás sebességét stb.
A teszt során megmérjük az összes paramétert, amit a készülék megszerezhet:
- DNS kérés ideje;
- TCP kapcsolat beállítási ideje;
- TLS kapcsolat beállítási ideje;
- az első adatbájt fogadásának ideje;
- teljes betöltési idő;
- állapot eredménykódja.
- Miután az összes impulzus befejeződött, a minta betölti az összes mérést elemzés céljából.
A kulcsfontosságú pontok a minimális logikától való függés a kliensen, az adatfeldolgozás a szerveren és a párhuzamos kérések mérése. Így képesek vagyunk elkülöníteni és tesztelni a lekérdezés teljesítményét befolyásoló különféle tényezők hatását, variálni egy recepten belül, és valódi ügyfelektől kapni eredményeket.
Ez az infrastruktúra nem csak a lekérdezések teljesítményének elemzéséhez bizonyult hasznosnak. Jelenleg 14 aktív receptünk van, több mint 6000 minta másodpercenként, a Föld minden szegletéből fogadunk adatokat, és a készülék teljes lefedettsége. Ha a Netflix vásárolna egy hasonló szolgáltatást egy harmadik féltől, az évente több millió dollárba kerülne, sokkal rosszabb lefedettséggel.
Tesztelmélet a gyakorlatban: prototípus
Egy ilyen rendszerrel ki tudtuk értékelni a CDN-proxyk hatékonyságát kérés késleltetése esetén. Most szüksége van:
- proxy prototípus létrehozása;
- helyezze a prototípust egy CDN-re;
- határozza meg, hogyan kell az ügyfeleket egy adott CDN-kiszolgálón lévő proxyhoz irányítani;
- Hasonlítsa össze a teljesítményt a proxy nélküli AWS-kérelmekkel.
A feladat a javasolt megoldás hatékonyságának mielőbbi értékelése. A prototípus megvalósításához a Go-t választottuk, mivel jó hálózati könyvtárak állnak rendelkezésre. Minden CDN-kiszolgálón statikus binárisként telepítettük a prototípus-proxyt a függőségek minimalizálása és az integráció egyszerűsítése érdekében. A kezdeti megvalósításban a lehető legnagyobb mértékben szabványos komponenseket és kisebb módosításokat használtunk a HTTP/2 kapcsolat pooling és a kérés multiplexelés során.
Az AWS-régiók közötti egyensúly érdekében egy földrajzi DNS-adatbázist használtunk, ugyanazt, amelyet az ügyfelek egyensúlyára használtunk. A kliens CDN-kiszolgálójának kiválasztásához TCP Anycast-ot használunk az Internet Exchange (IX) kiszolgálóihoz. Ebben az opcióban egy IP-címet használunk az összes CDN-kiszolgálóhoz, és a kliens a legkevesebb IP-ugrással rendelkező CDN-kiszolgálóhoz kerül. Az internetszolgáltatók (ISP-k) által telepített CDN-kiszolgálókon nincs irányításunk az útválasztó felett a TCP Anycast konfigurálásához, ezért , amely az ügyfeleket az internetszolgáltatókhoz irányítja videó streamelés céljából.
Tehát háromféle kérési útvonalunk van: a felhőbe a nyílt interneten keresztül, a IX-es CDN-kiszolgálón vagy egy internetszolgáltatónál található CDN-kiszolgálón keresztül. Célunk, hogy megértsük, melyik út a jobb, és mi a haszna a proxynak ahhoz képest, ahogyan a kérelmek elküldik a termelésbe. Ehhez a következő mintavételi rendszert használjuk:
Mindegyik ösvény külön célponttá válik, és megnézzük a kapott időt. Az elemzéshez a proxyeredményeket egy csoportba egyesítjük (válasszuk ki a legjobb időt az IX és az ISP-proxy között), és összehasonlítjuk őket a felhőbe proxy nélkül érkező kérések idejével:
Amint látható, az eredmények vegyesek voltak - a legtöbb esetben a proxy jó gyorsulást ad, de vannak olyan ügyfelek is, akiknek a helyzete jelentősen romlik.
Ennek eredményeként több fontos dolgot is megtettünk:
- Felmértük az ügyfelektől a felhőbe küldött kérések várható teljesítményét egy CDN-proxyn keresztül.
- Valódi ügyfelektől kaptunk adatokat, minden típusú eszközről.
- Rájöttünk, hogy az elméletet nem erősítették meg 100%-ban, és a CDN proxyval ellátott kezdeti ajánlat nem működne számunkra.
- Nem vállaltunk kockázatot – nem változtattuk meg az ügyfelek gyártási konfigurációit.
- Nem tört el semmi.
Prototípus 2.0
Tehát térjen vissza a rajztáblához, és ismételje meg a folyamatot újra.
Az ötlet az, hogy a 100%-os proxy helyett minden kliens számára meghatározzuk a leggyorsabb útvonalat, és oda küldjük a kéréseket, vagyis azt csináljuk, amit kliensirányításnak nevezünk.
Hogyan lehet ezt megvalósítani? Nem használhatunk logikát a szerver oldalon, mert... A cél az, hogy csatlakozzon ehhez a szerverhez. Valamilyen módon kell ezt megtenni az ügyfélen. És ideális esetben ezt minimális mennyiségű összetett logikával tegye, hogy ne oldja meg a nagyszámú kliens platformmal való integráció kérdését.
A válasz a DNS használata. Esetünkben saját DNS infrastruktúrával rendelkezünk, és beállíthatunk egy tartományzónát, amelyhez a szervereink tekintélyelvűek lesznek. Ez így működik:
- Az ügyfél kérést küld a DNS-kiszolgálónak egy gazdagép segítségével, például api.netflix.xom.
- A kérés megérkezik a DNS szerverünkre
- A DNS-kiszolgáló tudja, hogy melyik elérési út a leggyorsabb ehhez a klienshez, és kiadja a megfelelő IP-címet.
A megoldásnak van egy további összetettsége: a tekintélyelvű DNS-szolgáltatók nem látják a kliens IP-címét, és csak a kliens által használt rekurzív feloldó IP-címét tudják olvasni.
Ebből kifolyólag tekintélyelvű feloldónknak nem egy egyedi kliensre, hanem a rekurzív feloldó alapján klienscsoportra kell döntenie.
A megoldáshoz ugyanazokat a mintákat használjuk, összesítjük az ügyfelek mérési eredményeit az egyes rekurzív feloldókhoz, és eldöntjük, hogy hova küldjük ezeknek a csoportoknak a csoportját – proxyt az IX-en keresztül TCP Anycast segítségével, ISP-proxyn keresztül vagy közvetlenül a felhőbe.
A következő rendszert kapjuk:
Az eredményül kapott DNS-irányítási modell lehetővé teszi az ügyfelek irányítását az ügyfelek és a felhő közötti kapcsolatok sebességének történeti megfigyelései alapján.
Ismét a kérdés az, hogy ez a megközelítés mennyire lesz hatékony? A válaszadáshoz ismét a szondarendszerünket használjuk. Ezért konfiguráljuk az előadói konfigurációt, ahol az egyik cél követi a DNS-irányítás irányát, a másik pedig közvetlenül a felhőbe (jelenlegi termelés).
Ennek eredményeként összehasonlítjuk az eredményeket, és értékeljük a hatékonyságot:
Ennek eredményeként több fontos dolgot tanultunk meg:
- Felmértük az ügyfelektől a felhőbe küldött kérések várható teljesítményét a DNS-irányítás segítségével.
- Valódi ügyfelektől kaptunk adatokat, minden típusú eszközről.
- A javasolt ötlet hatékonysága bebizonyosodott.
- Nem vállaltunk kockázatot – nem változtattuk meg az ügyfelek gyártási konfigurációit.
- Nem tört el semmi.
Most a nehéz részről - elindítjuk a gyártásban
A könnyű résznek most vége – van egy működő prototípus. Most a nehéz rész egy megoldás bevezetése a Netflix teljes forgalmára, 150 millió felhasználóra, több ezer eszközre, több száz mikroszolgáltatásra, valamint egy folyamatosan változó termékre és infrastruktúrára. A Netflix szerverei több millió kérést kapnak másodpercenként, és könnyen megtörheti a szolgáltatást gondatlan lépésekkel. Ugyanakkor a forgalmat dinamikusan szeretnénk átirányítani több ezer CDN-szerveren keresztül az interneten, ahol folyamatosan és a legalkalmatlanabb pillanatban változik és eltörik valami.
Mindezzel együtt a csapatnak 3 mérnöke van, akik a rendszer fejlesztéséért, telepítéséért és teljes körű támogatásáért felelősek.
Ezért továbbra is a pihentető és egészséges alvásról fogunk beszélni.
Hogyan lehet folytatni a fejlesztést, és nem minden idejét támogatásra fordítani? Megközelítésünk 3 alapelven alapul:
- Csökkentjük a meghibásodások lehetséges mértékét (robbanási sugarat).
- Meglepetésekre készülünk - arra számítunk, hogy a tesztek és a személyes tapasztalatok ellenére valami eltörik.
- Kecses leromlás – ha valami nem működik megfelelően, azt automatikusan meg kell javítani, még ha nem is a leghatékonyabb módon.
Kiderült, hogy esetünkben a probléma ilyen megközelítésével egyszerű és hatékony megoldást találhatunk, és jelentősen leegyszerűsíthetjük a rendszertámogatást. Rájöttünk, hogy hozzáadhatunk egy kis kódrészletet az ügyfélhez, és figyelhetjük a csatlakozási problémák okozta hálózati kérések hibáit. Hálózati hibák esetén közvetlenül a felhőbe állítunk vissza. Ez a megoldás nem igényel jelentős erőfeszítést az ügyfélcsapatoktól, de nagymértékben csökkenti számunkra a váratlan meghibásodások és meglepetések kockázatát.
Természetesen a visszaesés ellenére a fejlesztés során egyértelmű fegyelmet követünk:
- Minta teszt.
- A/B tesztelés vagy Kanári-szigetek.
- Progresszív bevezetés.
A minták esetében a megközelítést leírták - a változtatásokat először egy testreszabott recept segítségével tesztelik.
A kanári teszteléshez összehasonlítható szerverpárokat kell beszereznünk, amelyeken össze tudjuk hasonlítani a rendszer működését a változtatások előtt és után. Ehhez számos CDN-webhelyünkről kiválasztunk pár szervert, amelyek hasonló forgalmat kapnak:
Ezután telepítjük a buildet a változtatásokkal a Canary szerveren. Az eredmények kiértékeléséhez egy olyan rendszert futtatunk, amely körülbelül 100-150 mérőszámot hasonlít össze a Control szerverek egy mintájával:
Ha a Kanári tesztelés sikeres, akkor fokozatosan, hullámokban adjuk ki. Nem frissítjük egyszerre az egyes webhelyeken lévő szervereket – ha egy teljes webhelyet veszítünk el problémák miatt, az jelentősebb hatással van a szolgáltatásra a felhasználók számára, mint a különböző helyeken lévő azonos számú szerver elvesztése.
Általában véve ennek a megközelítésnek a hatékonysága és biztonsága az összegyűjtött mutatók mennyiségétől és minőségétől függ. Lekérdezésgyorsító rendszerünkhöz az összes lehetséges összetevőből összegyűjtjük a mérőszámokat:
- ügyfelektől - munkamenetek és kérések száma, tartalék aránya;
- proxy - statisztika a kérések számáról és idejéről;
- DNS - kérések száma és eredményei;
- felhő széle – a kérések száma és ideje a felhőben.
Mindezt egyetlen csőbe gyűjtjük, és az igényektől függően döntjük el, hogy melyik mérőszámot küldjük a valós idejű elemzésnek, és melyiket az Elasticsearch-nek vagy a Big Data-nak a részletesebb diagnosztikához.
Figyelünk
Esetünkben a kliens és a szerver közötti kérések kritikus útvonalán hajtunk végre változtatásokat. Ugyanakkor óriási a különböző összetevők száma a kliensen, a szerveren és az interneten keresztül. A kliensen és a szerveren folyamatosan történnek változások – több tucat csapat munkája és az ökoszisztéma természetes változásai során. Középen vagyunk – a problémák diagnosztizálása során jó eséllyel részt veszünk. Ezért világosan meg kell értenünk, hogyan lehet mérőszámokat meghatározni, összegyűjteni és elemezni a problémák gyors elkülönítése érdekében.
Ideális esetben valós idejű, teljes hozzáférés minden típusú metrikához és szűrőhöz. De sok mérőszám létezik, így felmerül a költségek kérdése. Esetünkben az alábbiak szerint különítjük el a mérőszámokat és a fejlesztőeszközöket:
A problémák észlelésére és osztályozására saját nyílt forráskódú, valós idejű rendszerünket használjuk и - vizualizációhoz. Aggregált mérőszámokat tárol a memóriában, megbízható és integrálható a riasztási rendszerrel. A lokalizációhoz és a diagnosztikához hozzáférünk az Elasticsearch és a Kibana naplóihoz. A statisztikai elemzéshez és modellezéshez big data-ot és vizualizációt használunk a Tableau-ban.
Úgy tűnik, hogy ezzel a megközelítéssel nagyon nehéz dolgozni. A mérőszámok és eszközök hierarchikus rendezésével azonban gyorsan elemezhetünk egy problémát, meghatározhatjuk a probléma típusát, majd részletes mérőszámokba áshatunk bele. Általában körülbelül 1-2 percet fordítunk a meghibásodás forrásának azonosítására. Ezt követően egy meghatározott csapattal dolgozunk a diagnosztikán - több tíz perctől akár több óráig is.
Még ha a diagnózist gyorsan felállítják is, nem akarjuk, hogy ez gyakran megtörténjen. Ideális esetben csak akkor kapunk kritikus figyelmeztetést, ha az jelentős hatással van a szolgáltatásra. Lekérdezésgyorsító rendszerünkhöz csak 2 riasztásunk van, amelyek értesítenek:
- Client Fallback százalék - az ügyfelek viselkedésének felmérése;
- százalék Probe errors - a hálózati összetevők stabilitási adatai.
Ezek a kritikus riasztások figyelik, hogy a rendszer működik-e a felhasználók többségénél. Megvizsgáljuk, hogy hány ügyfél használt tartalékot, ha nem tudtak kérésgyorsítást kapni. Hetente átlagosan kevesebb, mint 1 kritikus riasztást adunk, annak ellenére, hogy rengeteg változás történik a rendszerben. Miért elég ez nekünk?
- Ha a proxynk nem működik, az ügyfél tartaléka van.
- Van egy automatikus kormányrendszer, amely reagál a problémákra.
Utóbbiról bővebben. Próbarendszerünk, valamint a klienstől a felhő felé tartó kérések optimális útvonalának automatikus meghatározására szolgáló rendszer lehetővé teszi számunkra, hogy automatikusan megbirkózzunk bizonyos problémákkal.
Térjünk vissza a mintakonfigurációnkhoz és a 3 útvonalkategóriához. A rakodási időn kívül magát a szállítás tényét is megnézhetjük. Ha nem sikerült betölteni az adatokat, akkor az eredményeket különböző utak mentén nézegetve megállapíthatjuk, hogy hol és mi tört el, illetve a kérési útvonal megváltoztatásával tudjuk-e automatikusan kijavítani.
Példák:
Ez a folyamat automatizálható. Szerelje be a kormányrendszerbe. És tanítsa meg reagálni a teljesítmény- és megbízhatósági problémákra. Ha valami elkezd eltörni, reagálj, ha van jobb lehetőség. Ugyanakkor az azonnali reakció nem kritikus, köszönhetően az ügyfelek tartalékának.
Így a rendszertámogatás alapelvei a következőképpen fogalmazhatók meg:
- a meghibásodások mértékének csökkentése;
- mérőszámok gyűjtése;
- A meghibásodásokat lehetőség szerint automatikusan kijavítjuk;
- ha nem, értesítjük;
- A gyors reagálás érdekében műszerfalakon és osztályozási eszközökön dolgozunk.
Tanulságok
A prototípus megírása nem sok időt vesz igénybe. Nálunk 4 hónap után lett kész. Ezzel új mutatókat kaptunk, és 10 hónappal a fejlesztés megkezdése után megkaptuk az első gyártási forgalmat. Aztán elkezdődött a fárasztó és nagyon nehéz munka: fokozatosan termékesíteni és méretezni a rendszert, migrálni a fő forgalmat és tanulni a hibákból. Ez a hatékony folyamat azonban nem lesz lineáris – minden erőfeszítés ellenére sem lehet mindent előre megjósolni. Sokkal hatékonyabb az új adatok gyors iterálása és reagálása.
Tapasztalataink alapján a következőket tudjuk ajánlani:
- Ne bízzon az intuíciójában.
A megérzéseink folyamatosan cserbenhagytak minket, csapatunk hatalmas tapasztalata ellenére. Például helytelenül jósoltuk meg a CDN-proxy használatából származó várható gyorsulást vagy a TCP Anycast viselkedését.
- Adatok lekérése a termelésből.
Fontos, hogy a lehető leggyorsabban hozzáférjen legalább egy kis mennyiségű termelési adathoz. Laboratóriumi körülmények között szinte lehetetlen megszerezni az egyedi esetek, konfigurációk és beállítások számát. Az eredményekhez való gyors hozzáférés lehetővé teszi, hogy gyorsan megismerje a lehetséges problémákat, és figyelembe vegye azokat a rendszer architektúrában.
- Ne kövesse mások tanácsait és eredményeit – gyűjtse saját adatait.
Kövesse az adatgyűjtés és -elemzés elveit, de ne fogadja el vakon mások eredményeit, kijelentéseit. Csak Ön tudhatja, hogy pontosan mi működik a felhasználók számára. Az Ön rendszerei és ügyfelei jelentősen eltérhetnek a többi vállalattól. Szerencsére az elemző eszközök már elérhetőek és könnyen használhatók. Előfordulhat, hogy az elért eredmények nem olyanok, mint amit a Netflix, a Facebook, az Akamai és más cégek állítanak. Esetünkben a TLS, HTTP2 vagy a DNS-kérések statisztikáinak teljesítménye eltér a Facebook, az Uber, az Akamai eredményeitől – mert más eszközökkel, kliensekkel és adatáramlással rendelkezünk.
- Ne kövesse a divatirányzatokat szükségtelenül, és értékelje a hatékonyságot.
Kezdje egyszerűen. Jobb egy egyszerű működő rendszert rövid idő alatt elkészíteni, mint rengeteg időt tölteni olyan alkatrészek fejlesztésével, amelyekre nincs szükség. Mérései és eredményei alapján oldja meg a fontos feladatokat és problémákat.
- Készüljön fel az új alkalmazásokra.
Ahogy az összes problémát nehéz előre megjósolni, úgy az előnyöket és alkalmazásokat is nehéz előre megjósolni. Vegye figyelembe az induló vállalkozásokat – az ügyfelek körülményeihez való alkalmazkodás képességét. Az Ön esetében új problémákat és azok megoldásait fedezheti fel. Projektünkben célul tűztük ki a kérések késésének csökkentését. Az elemzés és a megbeszélések során azonban rájöttünk, hogy proxyszervert is használhatunk:
- az AWS régiók közötti forgalom kiegyensúlyozása és a költségek csökkentése;
- a CDN stabilitás modellezése;
- a DNS konfigurálásához;
- a TLS/TCP beállításához.
Következtetés
A jelentésben leírtam, hogy a Netflix hogyan oldja meg az ügyfelek és a felhő közötti internetes kérések felgyorsításának problémáját. Hogyan gyűjtünk adatokat egy mintavételi rendszer segítségével az ügyfelekről, és hogyan használjuk fel az összegyűjtött előzményadatokat az ügyfelektől érkező gyártási kérelmek továbbítására az internet leggyorsabb útvonalán. Hogyan használjuk a hálózati protokollok, a CDN-infrastruktúra, a gerinchálózat és a DNS-kiszolgálók alapelveit ennek a feladatnak az eléréséhez.
A mi megoldásunk azonban csak egy példa arra, hogyan valósítottunk meg egy ilyen rendszert a Netflixnél. Ami nekünk bevált. Jelentésemnek az Ön számára alkalmazott része a fejlesztési és támogatási alapelvek, amelyeket követünk és jó eredményeket érünk el.
Lehet, hogy a mi megoldásunk nem felel meg Önnek. Az elmélet és a tervezési elvek azonban megmaradnak, még akkor is, ha nincs saját CDN infrastruktúrája, vagy ha az jelentősen eltér a miénktől.
Továbbra is fontos az üzleti kérések gyorsaságának fontossága. És még egy egyszerű szolgáltatás esetén is választania kell: a felhőszolgáltatók, a szerver helye, a CDN és a DNS szolgáltatók között. Az Ön választása befolyásolja az internetes lekérdezések hatékonyságát ügyfelei számára. És fontos, hogy mérje és megértse ezt a hatást.
Kezdje egyszerű megoldásokkal, törődjön azzal, hogyan változtatja meg a terméket. Tanuljon menet közben, és javítsa a rendszert az ügyfelektől, az infrastruktúrától és a vállalkozástól származó adatok alapján. Gondoljon a tervezési folyamat során előforduló váratlan meghibásodások lehetőségére. És akkor felgyorsíthatja a fejlesztési folyamatot, javíthatja a megoldás hatékonyságát, elkerülheti a felesleges támogatási terheket és nyugodtan alhat.
Ebben az évben online formátumban. Kérdéseket tehet fel a DevOps egyik atyjának, magának John Willisnek!
Forrás: will.com