Content Delivery Network (CDN) Přednáška KIV/PDS Pavel Bžoch,

Transkript

1 Cntent Delivery Netwrk (CDN) Přednáška KIV/PDS Pavel Bžch,

2 Obsah Cesta k CDN Histrie CDN Architektura CDN Distribuce bsahu Genervání dynamických stránek Streamvání videa Case study

3 Internet a cesta k CDN Internet celsvětvý systém navzájem prpjených pčítačvých sítí pčítače kmunikují pmcí rdiny prtklů TCP/IP cílem všech lidí využívajících internet je bezprblémvá kmunikace Nejznámější službu pskytvanu v rámci internetu je WWW kmbinace textu, grafiky a multimédií prpjených hypertextvými dkazy Další důležitu službu je

4 Internet a cesta k CDN Dvě skupiny lidí (institucí), které chtějí naplnit své ptřeby: Knzumenti bsahu, uživatelé - hlavní ptřebu je získání infrmací a využívání pskytvaných služeb Pskytvatelé bsahu cílem je vydělat peníze (reklama, pskytvání služeb) Obě tyt skupiny mají různé ptřeby a čkávání d interenetu

5 Internet a cesta k CDN Očekávání uživatelů d internetu: Výknnst Uživatelva lajalita navštěvvat stále stejné stránky (když jsu pmalé) je malá, prtže je velice jednduché přejít na jiné stránky. Dstupnst Uživatelé d internetu čekávají, že všechny typy infrmací budu stále dstupné Bezpečnst Je kmunikační cesta zabezpečena? Jsu data bezpečně ulžena na serveru? Jak je těžké ukrást něčí identitu či hesl? Annymita Se zvětšujícím se pčtem uživatelů internetu se annymita uživatelů zvětšuje. Persnalizace, sbní nastavení Nastavení vzhledu, přadí zbrazvaných infrmací atd. Sukrmí Uživatelé si přejí být infrmváni, pkud jejich údaje mhu být sdíleny s někým dalším

6 Internet a cesta k CDN Očekávání pskytvatelů bsahu Bezpečnst Jaký zisk by měla stránka, když by byl mžné se na placený bsah dstat i zadarm? Kntrla Pskytvatelé kntrlují, jaký bsah uživatelé navštěvují, vytvářejí třídy služeb pr různé typy uživatelů. Cílem je vytvření knkurenční výhdy. Ovladatelnst, řiditelnst Pskytvatelé bsahu musí mít přehled výknu svých systémů, aby věděli, jestli splňují pžadavky uživatelů na dstupnst a rychlst. Škálvatelnst Systémy by tedy měli být lehce rzšiřitelné pr buducí expanzi. Rzmanitsti (zařízení a uživatelů) Pskytvatel bsahu musí brát zřetel různá zařízení a pskytvaný bsah jim přizpůsbit. Ziskvst Jak peněžní, tak duchvní

7 Cntent Delivery Netwrk - definice CDN je skupina splupracujících, gegraficky rzptýlených serverů nasazených pr usnadnění distribuce infrmací genervaných webvými vydavateli včas a účinně. Tat definice všem nezahrnuje kapacitu a výkn rzptýlených serverů. Tyt dvě vlastnsti se většinu určují na základě zkušenstí administrátra systému.

8 Cntent Delivery Netwrk - definice Technlgie, která umžňuje nvý phled na rzlžení zátěže webvých serverů mezi více uzlů. Systém serverů rzmístěných p internetu, které splupracují pr zajištění rychléh dručení dat klientvi. Virtuální vrstva nad fyzicku infrastrukturu, která funguje na principu prxy serverů. Primárně se hdí pr statická data neb pr data, která se mění jen v dluhých časvých intervalech. Typický prvz - statická multimediální data, distribuce aktualizací SW zákazníkům Pžadavky uživatelů jsu rzprstřeny přes servery pdle pžadavků, které jsu na síť kladeny.

9 Histrie internetu a CDN

10 Histrie internetu a CDN Vylepšený Web server Při nedstatku výknu na straně serveru se vylepšil želez Nasazení cache prxy Pžadavky uživatelů jdu v tmt návrhu přes prxy cache server u ISP. Prxy server uchvává ve své cache nejčastěji navštěvvané stránky. Hierarchické cachvání Úrvně mhu být například lkální, reginální, mezinárdní Servervé farmy Škálvatelné řešení, které se pužíval a pužívá v psledních letech. Využívají přepínání na 4-7 úrvni OSI mdelu (inteligentní přepínání zalžené na URL, typu bsahu a uživatelském jméně). Celý systém je dbře škálvatelný, dlný prti pruchám díky replikacím bsahu Nevýhda je, že farma je stále na jednm místě

11 Histrie internetu a CDN První generace CDN Snaží se dstranit prblém servervých farem (umístění na jednm místě) Gegraficky rzděluje uzly participující v CDN Zaměření na statický a dynamický bsah stránek Druhá generace CDN Pzrnst přesunula k Vide-n-Demand (vide na pžádání), News-n- Demand (nvinky na pžádání), audi a vide streaming s vysku uživatelsku interaktivitu Dručvání bsahu na mbilní zařízení

12 Architektura CDN Cíle při návrhu CDN: Celý systém lehce rzšiřitelný Při zjištění úzkéh hrdla systému (výpčetníh) -> přidání nvéh uzlu Distribuce bsahu s vysku kvalitu za c nejmenší nákladvu cenu Bezpečnst (eliminace neautrizvanéh přístupu a mdifikace ulžených dat) Odlnst prti DS a DDS útkům

13 Architektura CDN

14 Architektura CDN Server s riginální infrmací (Origin server) Základní stavební jedntka CDN Obsahuje knzistentní data, která pskytuje statním serverům v CDN Obsahuje statická data (statické HTML stránky, brázky, dkumenty, balíčky sftware) neb videa (uživatelem genervaná, streamvaná a real-time videa) Obsahuje také algritmy (prgramy) pr genervání dynamickéh bsahu stránek Může bsahvat databázvý server (data pr dynamicky genervané stránky) Všechny tyt infrmace pskytuje na základě pžadavků uživatelů na hranvé servery. Pžadavky na velké úlžní prstry, menší na rychlst

15 Architektura CDN Hranvý server (Edge server) Základní stavební jedntka CDN Obsahuje replikace infrmací, které dále pskytuje uživatelům Umístěn v nějaké dané gegrafické lkalitě Předpkládá se, že uživatelé v tét lkalitě budu pžadvat určitý druh infrmací Tat data se budu na hranvém serveru ukládat priritně (např. sftwarvý balíček s danu jazykvu mutací) V jiných lkalitách tat data nebudu tak třeba Pžadavky na rychlst, menší na velikst úlžiště S rigin serverem tvří dhrmady cntent-delivery S rigin serverem bývá čast spjen pmalými WAN linkami

16 Architektura CDN Směrvač pžadavků (Request Ruting System) Na základě infrmace, dkud pchází pžadavek, rzhduje, který hranvý server bude pužit Využívá infrmace ze 4 až 7 vrstvy OSI (TCP prtkl + aplikační prtkl) Musí existvat DNS záznam, který dkazuje na směrvač a nikli na hranvý server Mnitrvací systém (Accunting System) Mnitrvání a udržvání lgů přístupu uživatelů Zaznamenává vytížení jedntlivých CDN serverů Rzhdnutí replikaci serveru Infrmace pr výpčet částky za distribuci infrmace Systém pr distribuci dat (Distributin System) Stará se knzistentnst dat na hranvých serverech Něklik algritmů pr přens dat z Origin d hranvých serverů viz dále v přednášce

17 Distribuce bsahu, Rzdělení webvé aplikace

18 Distribuce bsahu, Rzdělení webvé aplikace Frnt-end vrstva Rzhraní pr přístup k webvým službám Přímá pžadavky d uživatelů (prváděné pmcí HTTP), pskytuje uživatelům statický bsah webu a služí pr přístup k aplikační vrstvě. Statická data jsu ulžena v subrvém systému Aplikační vrstva Zdpvědná za business lgiku a zpracvání infrmací, které jsu pté pužity na genervání dynamickéh bsahu Genervání dynamickéh bsahu čast vyžaduje splupráci s back-end vrstvu a vrstvu uživatelskéh prfilu Back-end vrstva Ulžení a pskytvání dat (typicky v databázi) Vrstva uživatelskéh prfilu Ulžení infrmací preferencích uživatele (pr genervání persnalizvanéh bsahu stránek)

19 Distribuce bsahu Replikace dat na Frnt-end vrstvě Služí ke snížení pužívání WAN linek, které jsu náchylné na zahlcení při přensu velkých dat Statický bsah stránek (většinu videa) je uchván v cache hranvéh serveru (zde také nazýván surrgate server) Důvdy pr replikaci dat (videí): Při pužití HTTP streamvání nedchází k rzptylu rychlsti přenášených částí a přehrávání multimédií je plynulejší Nedchází ke zpždění při přensu, který má vliv na uživatelv vnímání rychlsti Distribuce subrů: pull bez splupráce serverů při chybějícím subru jej načte z rigin serveru pull se spluprácí serverů hranvé servery splupracují, chybějící subr si mhu vyměnit push se spluprací serverů rigin server zasílá nvu verzi subrů d hranvých serverů

20 Distribuce bsahu Replikace dat na Frnt-end vrstvě (pkračvání) Streamvání videí D cache se neukládají celé vide subry, ale jen čast přistupvané části (segment caching) Pkud je subr přistupván sekvenčně, mhu být v cache ulženy fragmenty ze začátku subru; fragmenty z knce se získají v průběhu přehrávání (sequential caching) Pkud uživatelé čast seekují na jedn míst ve videu (např. přeskakují úvdní reklamu a titulky), je mžné pužít interleaved caching Vhdný caching se vlí na základě pzrvání U každéh fragmentu musí být infrmace, z jakéh je subru a jak dluh má být v cache O streamvání videa bude ještě řeč dále

21 Distribuce bsahu Replikace na aplikační vrstvě Úzkým hrdlem replikace na frnt-end vrstvě je, že umí replikvat jen statický bsah Replikace na aplikační vrstvě zahrnuje přenesení kódu, který se stará genervání dynamickéh bsahu (edge cmputing) Každý hranvý server má svu vlastní kpii aplikačníh kódu Back-end aplikace stále běží na rigin serveru Příchzí pžadavky mhu být transakční a netransakční Transakční pžadavek bude data měnit, vyžaduje tedy přístup přím na rigin server Netransakční pžadavek data puze čte, může být bslužen na edge serveru Distribuce kódu pr genervání bsahu (stránek) má na starsti rigin server. Při změně kódu je nvý kód hned pslán na hranvé servery. Nevýhdy: pmalá WAN linka pr distribuci dat a centrální databáze na straně rigin serveru

22 Distribuce bsahu Replikace na back-end vrstvě

23 Distribuce bsahu Replikace na back-end vrstvě (pkračvání) Replikace části neb celé databáze pr vytváření dynamickéh bsahu stránek Cntent-blind caching Hranvý server výsledky čast pužívaných databázvých dtazů Při pakujících se dtazech - výsledky uchvávány v cache dluh Řešení pmcí tzv. TTL (Time-T-Live) Jiné řešení je invalidce ze strany rigin serveru pmcí skupinvéh vysílání (ale zatěžvání WAN linek) Obecně lze Cntent-blind caching pužít za předpkladu, že se data v databázi budu jen žřídka měnit. Cntent-aware caching Hranvý server musí mít svůj databázvý server V tét databázi se zrcadlí část databáze z rigin serveru (čast přistupvaná data) distribuvaná databáze

24 Distribuce bsahu Replikace na back-end vrstvě (pkračvání) Cntent-aware caching Nevýhda neexistuje nástrj, který by distribuvanu databázi plně pdprval (většinu je třeba centrální krdinátr dtazů) Nevýhda žádný z dstupných nástrjů neuvažuje pmalé linky Replikace celé databáze Hranvé servery mají identicku kpii databáze (slave kpie; na rigin serveru master kpie) Nutnst prpagvat změny v DB (zpět d master a pak k statním slave) Eager přístup všechny změny ihned prpagvány d všech databází Lazy přístup - prpagvána puze infrmace změně, při pžadavku na změněnu infrmaci je tat ddatečně stažena z centrální databáze Opět prblém při uvažvání pmalých linek mezi uzly Nejčastěji pužívaný přístup Cntent-blind caching

25 Distribuce bsahu Replikace na vrstvě uživatelskéh prfilu

26 Distribuce bsahu Replikace na vrstvě uživatelskéh prfilu Vyžaduje databázi pr ukládání dat Replikace databáze jsu pdbné jak v back-end vrstvě Rzdíl v případě uživatelskéh prfilu jsu data ulžena jen na jednm hranvém serveru, se kterým uživatel čast kmunikuje (nejsu psílána na centrální server) Při přesunu uživatele nutné zajistit migraci dat z hranvéh uzlu na jiný hranvý uzel Mžnst řešení centrální prvek při nemžnsti kmunikace mezi jedntlivými hranvými uzly

27 Genervání dynamických stránek Je pdmíněn existencí generátru stránek na hranvém serveru a dále přítmnstí částí (fragmentů) stránek Generátrem stránek se rzumí aplikace, která na základě pžadavku uživatele zajistí fragmenty a dá je dhrmady ve výslednu stránku Dynamickým bsahem stránek se může rzumět výsledek hledání na vyhledávacím serveru, aktuální zprávy na zpravdajském serveru atd. dynamický bsah stránek se může měnit v závislsti na čase neb na pžadavcích uživatele

28 Genervání dynamických stránek Při časvých změnách - hranvý server v pravidelně kntaktuje rigin server V případě vyhledávání hranvý server uchvává výsledky častých dtazů v databázi a vracet je rvnu uživateli Veškeré infrmace pr genervání stránek jsu ulženy v lkální databázi na hranvém serveru Některé části stránky se mění častěji než jiné U každé části stránky se uchvává, jak čast se má v hranvém serveru aktualizvat pmcí značkvacíh jazyka ESI

29 Genervání dynamických stránek, ESI ESI (Edge Side Includes) Jazyk zalžený na XML Navržen tak, aby byly využity prstředky (např. cache) pr lepší vnímání výknu systému na straně kncvéh uživatele a k zmenšení nutnsti kmunikace s rigin serverem Vyvinut splečnstmi Akamai, ATG, BEA Systems, Circadence, Digital Island, IBM, Interwven, Oracle a Vignette Definuje fragmenty, ze kterých se má stránka skládat Každému fragmentu lze určit zdrj, dkud pchází; živtnst; jestli se má cachvat neb má být pkaždé načten z rigin serveru a další parametry Lze také definvat css styl, který má být pužit na vykreslení stránky Pmcí ESI lze identifikvat prhlížeč, následně genervat stránky přím určené pr daný prhlížeč V ESI lze i deklarvat prměnné a pracvat s nimi

30 Genervání dynamických stránek, ESI Příklad: <esi:include src=" alt=" nerrr="cntinue" max-age="300"/> ESI se pkusí načíst stránku 1.html a vlžit ji d d aktuálně sestavvané stránky. Pkud stránka 1.html nebude existvat, pkusí se vlžit stránku 2.html. Pkud ani ta nebude existvat, nebude na tt míst vlžen nic a pkračuje se v genervání stránky. Dále je pmcí tagu max-age definván, jak dluh se má stránka udržvat v cache (300s).

31 Genervání dynamických stránek, ESI Příklad s prměnnými: <!-- image list --> <esi:assign name="image_list"> ['qute1.gif','qute2.gif','qute3.gif','qute4.gif','qute5.gif'] </esi:assign> <!-- chsing randm ffset --> <esi:assign name="index" value="$rand()%$len($(image_list))" /> <esi:vars> <!-- Index: $(index) <br> Image: $(image_list{$(index)}) <br> --> </esi:vars> <center> <esi:vars> <img src="$(image_list{$(index)})" brder="0"> </esi:vars> </center> Další příklady:

32 Streamvání videa Již jsme viděli, jak je mžné uchvat vide na hranvém serveru Segment caching (cachvání čast přistupvané částí videa), sequential caching (cachvání částí videa, většinu začátku) a interleaved caching (cachvání míst, kam uživatelé čast seekují) Existují i další mžnsti dručení videa Zaměříme se na Live Stream (živé vysílání) a na Vide-n-Demand (vide na pžádání)

33 Streamvání videa živé vysílání V klasickém pjetí se pužívá multicast a IGMP prtkl Nelze vyžadvat zajištění QS (Quality f Service) při ztrátě prudu dat Uživateli se tat ztráta jeví jak rzpad brazu či chvilkvá ztráta zvuku Využití CDN při živém vysílání Cachvání na straně hranvých serverů Prud dat je deslán ze zdrjvéh serveru d CDN sítě, krátku dbu cachván na hranvém serveru a deslán uživatelům. V kncvé síti se vide pět šíří pmcí multicastu. Výhda tht řešení je, že nasazení CDN zabraňuje ztrátě paketů při přensu streamu ze zdrjvéh serveru ke kncvým uživatelům. Pkud k jednmu hranvému serveru bude připjen více kncvých sítí pžadujících různé streamy, může pět djít ke ztrátě dat (zahlcení hranvéh serveru). Stále zde zůstává tázka šíření streamu v lkální síti, kdy stále může pět dcházet ke ztrátě paketů a rzkladu přehrávanéh videa.

34 Streamvání videa živé vysílání Cachvání na straně hranvých serverů

35 Streamvání videa živé vysílání P2P překrytí CDN sítě Pr eliminaci ztráty prudu dat je mžné nad hranvými servery vybudvat P2P architekturu

36 Streamvání videa živé vysílání P2P překrytí CDN sítě Pr eliminaci ztráty prudu dat je mžné nad hranvými servery vybudvat P2P architekturu v CDN je umístěn tzv. vstupní server, ze kteréh je prud přenášen na hranvé servery P2P přináší d CDN technlgii Prbe-based verlay ruting (rutvání pmcí snd) Sndy mnitrují linky mezi datvými centry a udržují směrvací tabulky pr směrvání mezi servery Když chce hranvý server získat stream, je aktivvána lkální snda, která zajistí nejlepší (nejrychlejší) cestu pr získání streamu Systém je díky P2P lépe rzšiřitelný Datvé streamy v tét síti jsu psílány p nejrychlejších linkách

37 Streamvání videa živé vysílání P2P sít u kncvých uživatelů V klasickém pjetí kncvé sítě může dcházet při zahlcení směrvače (-ů) k zahazvání paketů

38 Streamvání videa živé vysílání P2P sít u kncvých uživatelů V klasickém pjetí kncvé sítě může dcházet při zahlcení směrvače (-ů) k zahazvání paketů Klientská P2P síť je v tmt případě zdpvědná za dručení streamu ke kncvému uživateli Dvě kategrie klientů: push peer a nrmální P2P klienti Push peer udržuje (tzn. přímá a krátkdbě cachuje) celý datvý prud přím d hranvéh serveru Nrmální P2P klienti pptávají stream d statních klientů Čím více push serverů bude v kncvé síti, tím lepší bude QS u kncvých uživatelů Zárveň ale bude více zatížena linka(-y) k hranvým serverům. Při přensu dat mezi push peery a hranvými servery se již nepužívá multicast ale unicast

39 Streamvání videa Vide-n-Demand Vide, které je ulžen jak datvý subr na vzdáleném serveru a uživatel si jej chce n-line přehrát Některé servery pskytují tat videa zdarma (např. yutube.cm), někdy jsu tat videa placené (např. n-line vide půjčvny) Kncvý uživatel si přeje, aby se vide přehrával plynule a aby byl mžné v tmt videu seekvat (přeskakvat)

40 Streamvání videa Vide-n-Demand Využití CDN pr dručení: V tmt případě je mžné cachvat na hranvých serverech celé vide subry (neb jejich větší část) P2P překrytí na straně CDN již není ptřeba V kncvých sítích je vhdné pužít P2P síť pr zajištění QS

41 Streamvání videa Vide-n-Demand Využití CDN pr dručení: Prblém s autrizací uživatelů Pkud si některý z uživatelů chce půjčit vide n-line, musí prkázat svu identitu a také prkázat, že za půjčení videa zaplatil. Řešení tracker server - udržuje infrmaci všech uživatelích a videích ulžených na hranvých serverech Při pžadavku na vide zjistí tracker server, jestli je tt vide přítmn v síti a jestli k němu má klient právnění přistupvat Pkud an, je klient přesměrván na hranvý server, který mu tt vide pskytne. Tracker server zárveň služí k vyvažvání zátěže mezi hranvými servery

42 Akamai Case study Zalžena v rce 1998 z pdnětu MIT (Massachusetts Institute f Technlgy) Důvdem - zamezení tzv. flash crwd (vlně přelžen jak náhlé zácpy, nával na internetu) Je vůdce trhu v dručvání bsahu, kdy pkrývá 90% trhu, má serverů v 72 zemích Přes servery Akamai denně prjde 15-20% celsvětvéh prvzu na internetu Akamai servery pskytují statické bjekty, dynamicky genervané stránky, streamvané vide a audi Snaží se předcházet flash crwd umístěním více serverů d míst, kde čekává větší prvz (více pžadavků d klientů) Při pžadavku klienta na bsah, systém přesměruje tent pžadavek na nejbližší dstupný server

43 Akamai Case study Tplgie sítě se získá z hraničních směrvačů, z nichž pužívají infrmace BGP prtklu Pskytuje autmatické řízení sítě pmcí mapvání, které pužívá dynamický DNS systém Mapvací systém pužívá k rzhdnutí nejvhdnějším serveru infrmace umístění klienta, stavu sítě a pžadavku klienta Dynamické DNS je také pužíván k rvnměrnému zatížení sítě (průběžně mnitruje služby a zatížení serverů) Pr mnitrvání stavu kmunikace d uživatele až k serveru se pužívají agenti, kteří simulují chvání kncvých uživatelů Detekují a vyřazují z prvzu prblematické uzly v síti Při dpjení serveru ze sítě nebude dčasně jeh IP adresa pužívána Pr dručvání bsahu pužívá HTTP a HTTPS prtkl

44 Akamai Case study Pr statické webvé bjekty, uchvává Akamai různé druhy atributů, které jsu důležité pr přens k uživateli (např. živtnst bjektu, řešení bezpečnsti přes HTTPS prtkl, alternativní bsah, kódvání přensu, ckies). Dynamický bsah je generván na hranvých serverech pmcí technlgie ESI V přehrávání streamvaných videí Akamai pdpruje Micrsft Windws Media, Real a Apple QuickTime Stream je nejprve zachycen pskytvatelem bsahu a následně zaslán d vstupníh serveru Akamai, který je spjen s hranvými servery Akamai Na hranvé servery se videa kpírují na základě pžadavků uživatelů

45 Glbule Case study Technlgie vyvinutá na Vrije Universiteit v Amsterdamu Síť splupracujících uzlů zapjených d P2P sítě Sučástí tét sítě jsu i uzly kncvých uživatelů Každý uzel v tét síti pskytuje své dstupné zdrje (paměť, šířku pásma a výpčetní výkn). Pskytuje replikaci bsahu, mnitrvání serverů a přesměrvaní pžadavků klientů na dstupné repliky Existují zde tzv. místa (site), která jsu definvána jak klekce dkumentů, které patří jednmu uživateli Dále zde existuje prces server, který je instancí Glbule sftware Každé míst - čtyři druhy serverů: server s riginální infrmací, zálžní server, replikační servery a směrvací server Server s riginální infrmací drží všechny dkumenty a může je distribuvat d statních zúčastněných serverů

46 Glbule Case study Každé míst - čtyři druhy serverů: server s riginální infrmací, zálžní server, replikační servery a směrvací server Zálžní server bsahuje zálžní kpii všech dkumentů Replikační servery uchvávají část dkumentů (při velké kapacitě mhu i všechny) Směrvací server je zdpvědný za směrvání pžadavků uživatelů na ptimální replikační server Směrvání v Glbuli může směrvat na základě rzbru HTTP pžadavku neb na základě DNS Jak měřítk se v Glbuli pužívá zpždění při kmunikaci mezi servery Glbule je implementvána jak mdul pr Apache HTTP Server