navigace

jak můžete (doufejme) vidět z tohoto webu, mám rád své stránky rychle. Velmi, velmi rychle. Nyní, než do toho skočíme, dovolte mi, abych o tom měl jasno: použití CDN vás dostane jen tak daleko. Pokud je váš web pomalý kvůli chatrné práci s frontendem, CDN vám moc nepomůže. Nejprve musíte správně pracovat s frontendem. Nicméně, jakmile jste optimalizovánivšechno, co můžete, je čas podívat se na doručování obsahu.

aktualizace o rok později
CDN je nyní zakázáno. Pokud jste zvědaví na důvody, přejděte na konec.

mým hlavním problémem bylo, že i když jste mohli získat inital webové stránky zatížení s jediným požadavkem HTTP, můj server beinghosted ve Frankfurtu, lidé z Austrálie stále musel čekat až 2-3 sekund, aby si to. Časy zpáteční cesty přes 300 ms a mnoho poskytovatelů mezi nimi způsobilo, že se stránka načítá stejně jako jakýkoli jiný web WordPress.

tak co s tím můžeme dělat? Jedním z řešení by samozřejmě bylo použití tradičního CDN. Většina komerčních CDN však na požádání stahuje data ze serveru a poté je na chvíli ukládá do mezipaměti.

uživatel požaduje stránku z CDN, která trvá 50 ms. CDN ji poté požaduje od původu, což trvá 300 ms. bez CDN uživatel požaduje přímo od původu.

při použití tradičního CDN je počáteční načítání stránky pomalejší než bez něj, protože CDN je mírnou objížďkou pro obsah. To není problém, pokud máte web s vysokým provozem, protože obsah zůstává v mezipaměti po celou dobu. Pokud na druhou stranu provozujete malý blog jako já, obsah vypadne z mezipaměti skoro pořád. Tak, v podstatě, tradiční pull-CDN by tento web zpomalil. Mohl bych, samozřejmě, použít push-CDN, Kde mohu nahrát obsah přímo, ale ty se zdají být docela drahé ve srovnání s tím, co se chystám postavit.

jak CDN fungují? ▲ Zpět na začátek Link Odkaz zde

náš plán je jasný: na naší cestě k ovládnutí světa musíme rychle zpřístupnit náš obsah všude. To znamená, že náš obsah musí být blízko publiku. Pohodlně existuje mnoho poskytovatelů cloudu, kteří nabízejí levné virtuální servery ve více regionech. Můžeme jen dát náš obsah na, říci, 6 servery a jsme v pořádku, že jo?

no, ne tak rychle. Jak bude uživatel směrován na správný server? Podívejme se na proces skutečnězískání webu. Nejprve prohlížeč uživatelů používá systém doménových jmen (DNS) k vyhledání IP adresy webu.Jakmile má IP adresu, může připojit web a stáhnout požadovanou stránku.

uživatel nejprve vyhledá IP této webové stránky ze služby DNS. Poté uživatel požaduje stránku z IP vzhlédl.

pokud o tom přemýšlíme na vysoké úrovni, řešení je poměrně jednoduché: potřebujeme inteligentní server DNS, který provede GeoIPlookup na požadující IP adrese a vrátí IP adresu nejblíže k ní. A skutečně, to je (téměř), jak to dělají komerční CDN. Je tam trochu více inženýrství, jako je měření latencí, ale v podstatě se to dělá.

rychlé servery DNS ▲ zpět na začátek Link Odkaz zde

nyní vyvstává další otázka: jak zrychlíme server DNS? Získání stahování webových stránek k nejbližšímu uzluje jen polovina práce, pokud vyhledávání DNS musí jít po celé planetě, je to stále obrovské zpoždění.

jak se ukázalo, infrastruktura, která je základem internetu, je jednoznačně vhodná k vyřešení tohoto problému. Networkproviders používají protokol Border Gateway, aby si navzájem řekli, které sítě mohou dosáhnout a kolik chmele jsou. Koncový uživatel ISP pak ve většině případů podnikne nejkratší cestu k dosažení cíle.

pokud nyní inzerujeme IP adresy na více místech, bude požadavek DNS vždy směrován do nejbližšího uzlu.Tomu se říká BGP Anycast.

proč nepoužívat BGP Anycast pro stahování webových stránek? ▲ Zpět na začátek Link Odkaz zde

počkejte, vydrž, pokud to dokážeme, proč jednoduše nepoužíváme BGP pro směrování webového provozu? No, existují tři důvody.

za prvé, dělat BGP Anycast vyžaduje kontrolu nad síťovým hardwarem a Fondem alespoň 256 IP adres,což je NAD náš rozpočet.

za druhé, trasy BGP nejsou tak stabilní. Zatímco požadavky DNS vyžadují pouze jeden paket, který má být odeslán v obou směrech, požadavky HTTP (web) vyžadují navázání připojení ke stažení obsahu. Pokud se trasa změní nebo je připojenínestabilní, spojení HTTP by mohlo být přerušeno. To dodává projektu tohoto rozsahu velkou složitost.

a konečně nejnižší počet chmele, který je základem výpočtů trasy BGP, nezaručuje nejnižší čas zpáteční cesty. Hop přes oceán může být jen jeden hop, ale je to zatraceně dlouhý.

další čtení
LinkedIn Engineering má úžasný blogový příspěvek o tomto tématu.

nastavení DNS ▲ zpět na začátek Link Odkaz zde

protože jsme zjistili, že nemůžeme spustit vlastní BGP Anycast, znamená to, že také nemůžeme spustit vlastní servery DNS. Solet jde nakupovat! … OK, jak se ukázalo, poskytovatelé DNS, kteří nabízejí servery BGP Anycast a latenční routingare trochu těžké přijít. Během hledání jsem našel jen dva, poměrně drahý Dyn a thedirt-levný Amazon Route53. (Aktualizace: jak se ukázalo, DNS je Snadnétaké směrování založené na latenci.)

protože jsme levné, Route53 to je. Přidáme naši doménu a poté začneme nastavovat IP adresy pro naše stroje. Potřebujeme tolik záznamů, kolik máme serverů po celém světě (okrajová místa), a každý záznam by měl vypadat takto:

Route53 latence-based routing by měl být nastaven v Route53 vytvořením záznamy s IP umístění hrany, a pak Nastavení zásady směrování na "latence". ID sady by mělo být něco jedinečného a umístění by mělo být nejblíže našemu okraji.
Tip:
je užitečné nastavit kontrolu stavu pro každé z okrajových míst, aby byly odstraněny, pokud klesnou.

distribuce obsahu ▲ zpět na začátek Link Odkaz zde

dalším problémem, který musíme řešit, je distribuce obsahu. Každý z vašich okrajových uzlů musí mít stejný obsah. Pokud používáte statický generátor stránek, jako je Jekyll, je váš úkol snadný: jednoduše zkopírujte generované soubory HTML na všech serverech. Něco tak jednoduchého jako rsync by mohlo stačit.

pokud chcete používat systém pro úpravu obsahu, jako je WordPress, máte výrazně těžší práci, protože není postaven torun na CDN. Může to být provedeno, ale není to bez jeho nevýhod adistribuce statického obsahu je stále problémem. Možná budete muset vytvořit distribuované úložiště objektů, aby bylo možné plně pracovat.

pomocí certifikátů SSL / TLS ▲ zpět na začátek Link Odkaz zde

dalším bodem bolesti je použití certifikátů SSL/TLS. Ve skutečnosti jim říkejme, jaké jsou: certifikáty x509. Každá z vašich okrajových lokalit musí mít platný certifikát pro vaši doménu. Jednoduchým řešením je samozřejmě použítletsencrypt pro generování jiného certifikátu pro každý, ale musíte být opatrní. LE hasa limit rychlosti, které jsem narazil na jednom z mých okrajových uzlů. Ve skutečnosti jsem musel vzít Londýnský uzel dolů po dobu, než vyprší týdenní limit.

používám však Traefik jako svůj proxy, který podporuje použití distribuovaného klíče-valuestore nebo dokonce Apache Zookeeper jako backend pro synchronizaci. I když to vyžaduje trochu více inženýrství, z dlouhodobého hlediska je pravděpodobně mnohem stabilnější.

výsledky Back zpět na začátek Link Odkaz zde

čas na pravdu, jak funguje moje CDN? Pomocí tohoto nástroje se podívejme na některé globální statistiky:

Oregon: 246ms, Kalifornie: 298ms, Ohio: 227ms, Virginie: 108ms, Irsko: 217ms, Frankfurt: 44ms, Londýn: 110ms, Bombaj: 870ms, Singapur: 517ms, Soul: 253ms, Tokio: 150ms, Sidney: 358ms, Sao Paulo: 911ms

jak vidíte, výsledky jsou docela slušné. Možná budu potřebovat další dva uzly, jeden v Asii a jeden v Jižní Americe, abych tam získal lepší časy načítání.

aktualizace

poté, co jsem se dostal na přední stránku Hacker News (wow!), Měl jsem šancisbírat trochu skutečných údajů o využití pomocí Google Analytics:

 </figure><p></p>

Sečteno a podtrženo: opravdu potřebuji ten Singapurský uzel. Doby zatížení v Indii jsou nad požadovanou 1 sekundu.

Často kladené otázky ▲ zpět na začátek Link Odkaz zde

když dělám takové projekty, lidé se mě obvykle ptají: „Proč to děláš? Musíš mít rád bolest.“Ano, do jisté míry Iradi dělat věci jinak jen kvůli zkoumání nových možností a technologií, budování vlastního CDN můžedělat hodně smysl. Pojďme se zabývat některými otázkami týkajícími se tohoto nastavení.

buďme jasní: pokud komerční poskytovatel vyjde s cenově dostupným push CDN, který mi umožní dělat pěkné adresy URL, SSL andcustom záhlaví, absolutně na ně hodím peníze a přestanu provozovat vlastní infrastrukturu. Jak zábavné bylo stavět, mám dost serverů, abych mohl běžet bez tohoto.

Proč prostě nepoužíváte CloudFlare? ▲ Zpět na začátek Link Odkaz zde

CloudFlare je skvělý nástroj pro mnoho, ale jak je uvedeno výše, CDN upustí nepoužitý obsah ze své mezipaměti. Na jiných stránkách, které řídím, vidím míru mezipaměti asi 75% se správným nastavením. Mít vlastní CDN znamená 100% zobsah je vždy v mezipaměti a neexistují žádné další zpáteční cesty na server origin.

proč nepoužíváte S3 a CloudFront? ▲ Zpět na začátek Link Odkaz zde

Amazon S3 má možnost hostit statické webové stránky a funguje ve spojení s CloudFront. Neumožňuje však nastavit vlastní záhlaví pro ukládání do mezipaměti, pěkné adresy URL atd. K tomu potřebujete [email protected], nástroj, který vám umožní spustit kódna uzlech CloudFront edge. [email protected] má však stejný problém jako CDN: pokud neobdrží požadavky na určitou dobu, kontejner, který je spuštěn, je vypnut a potřebuje až sekundu na spuštění.

proč nepoužíváte Google AMP? ▲ Zpět na začátek Link Odkaz zde

Google AMP přináší výhody pouze tehdy, když lidé navštíví váš web z vyhledávače Google. Většina mého provozu nepochází z Googlu, takže to problém nevyřeší. Takže to opravdu prospívá pouze Googlu, nikomu jinému. Jo, a já jsem dokonale schopen vytvořit rychlý web bez hloupého HTML, který nabízejí.

koho to zajímá? 3 sekundy je skvělý čas načítání! ▲ Zpět na začátek Link Odkaz zde

jsem inženýr DevOps, který se specializuje na doručování obsahu. Pokud někdo, měl bych mít web, který je rychlý kolem globe, ne?

Oh, a já jsem chtěl otočit Google AMP off, protože je to hrozná technologie. Ne že by je to zajímalo.

o rok později … Back zpět na začátek Link Odkaz zde

o rok později jsem se rozhodl strhnout své CDN. Důvody se scvrkávají na skutečnost, že jsem již zmínil: tento systém není připraven na výrobu. Před pár měsíci někteří z mých pravidelných čtenářů poukázali na to, že moje stránka někdypřijde zpět s 404. Při bližším zkoumání se ukázalo, že důvodem tohoto 404 bylo využití CPU.

není využití CPU mých strojů, ale mých „sousedů“. Přihlášení na můj server viděl jsem CPU ukrást čas až 90%:

Toto vysoké využití CPU způsobilo, že Traefik upustil backend kvůli časovému limitu,což zase způsobilo chybu 404. Když jsem nainstaloval robota Uptime pro kontrolu mých stránek, uvědomil jsem si, že je to docela běžný jev a stalo se to 3-4 krát týdně.

člověk může mít pochybnosti o Amazon Lightsail (virtualizační platforma pod CDN), ale poukazuje na většíobrázek: s distribuovaným systémem, jako je tento, je zásadní monitorování a zajištění kvality. Moje rozhovory s jinými inženýry provozujícími globálně distribuované systémy to potvrdily: při budování CDN není absolutně žádné kouzlototo. Jeho spuštění, nicméně, realizace s výkonem základní platformy, nebo výkon sítě, je těžká část, která vyžaduje neustálé úsilí a údržbu.

v důsledku toho jsem přestavěl své nastavení na jednom serveru, s animmutable infrastrukturou a správné monitorování, s Terraform. Pokud se chcete dozvědět více o tom, jak jsem to udělal, přečtěte si článek zde.

Napsat komentář

Vaše e-mailová adresa nebude zveřejněna.