Nawigacja

jak można (mam nadzieję) zobaczyć z tej strony, lubię moje strony szybko. Bardzo, bardzo szybko. Teraz, zanim przejdziemy do tego, pozwól mi być bardzo jasnym: korzystanie z CDN doprowadzi Cię tylko do tej pory. Jeśli Twoja witryna jest powolna z powodu tandetnej pracy frontend,CDN nie pomoże Ci zbytnio. Najpierw musisz poprawnie wykonać frontend. Jednak po zoptymalizowaniu wszystkiego, co możesz, nadszedł czas, aby spojrzeć na dostarczanie treści.

zaktualizuj rok później
CDN jest teraz wyłączony. Jeśli jesteś ciekawy powodów, przewiń do końca.

moim głównym problemem było to, że mimo że można było uzyskać ładowanie strony początkowej za pomocą jednego żądania HTTP, mój serwer był hostowany we Frankfurcie, ludzie z Australii nadal musieli czekać do 2-3 sekund, aby go uzyskać. Czasy podróży w obie strony ponad300 ms i wielu dostawców między nimi sprawiło, że strona ładowała się tak jak każda inna witryna WordPress.

więc co możemy z tym zrobić? Jednym z rozwiązań byłoby oczywiście użycie tradycyjnego CDN. Jednak większość komercyjnych CDN pobiera dane z serwera na żądanie, a następnie buforuje je przez jakiś czas.

 użytkownik żąda strony z CDN, co zajmuje 50 ms. CDN następnie żąda jej z Origin, co zajmuje 300 ms. bez CDN użytkownik żąda bezpośrednio z Origin.

Korzystanie z tradycyjnego CDN początkowe ładowanie strony jest wolniejsze niż bez niego, ponieważ CDN jest lekkim objazdem dla użytkownika. Nie jest to problem, jeśli masz witrynę o dużym natężeniu ruchu, ponieważ zawartość pozostaje w pamięci podręcznej przez cały czas. Z drugiej strony, jeśli prowadzisz małego bloga, tak jak ja, zawartość wypada z pamięci podręcznej prawie cały czas. Tak więc, w efekcie, tradycyjny pull-CDN sprawi, że ta strona będzie wolniejsza. Mógłbym, oczywiście, użyć push-CDN, gdzie mogę przesłać zawartość bezpośrednio, ale te wydają się być dość drogie w porównaniu do tego, co mam zamiar zbudować.

jak działają CDNs? ▲ Powrót na górę Link Link tutaj

nasz plan jest jasny: na naszej drodze do dominacji nad światem musimy szybko udostępniać nasze treści wszędzie. Oznacza to, że nasze treści muszą być blisko odbiorców. Wygodnie, istnieje wiele dostawców usług w chmurze, którzy oferują tanie serwery w wielu regionach. Możemy po prostu umieścić nasze treści na, powiedzmy, 6 serwerach i jesteśmy dobrzy, prawda?

cóż, nie tak szybko. W jaki sposób użytkownik zostanie przekierowany na właściwy serwer? Przyjrzyjmy się procesowi faktycznegozakładanie witryny. Po pierwsze, przeglądarka użytkowników korzysta z systemu nazw domen (DNS), aby wyszukać adres IP witryny.Gdy ma adres IP, Może połączyć się z witryną i pobrać żądaną stronę.

 użytkownik najpierw wyszukuje IP tej strony z usługi DNS. Następnie użytkownik żąda strony z podanego IP.

jeśli myślimy o tym na wysokim poziomie, rozwiązanie jest dość proste: potrzebujemy inteligentnego serwera DNS, który wykonuje GeoIPlookup na żądanym adresie IP i zwraca adres IP najbliższy temu. I rzeczywiście, tak (prawie) robią to komercyjne CDN. Jest trochę więcej inżynierii, jak mierzenie opóźnień, ale tak to się robi.

szybkie serwery DNS ▲ powrót do góry Link Link tutaj

teraz pojawia się kolejne pytanie: Jak sprawić, by serwer DNS był szybki? Pobieranie strony internetowej, aby przejść do najbliższego nodeis tylko połowa pracy, jeśli wyszukiwanie DNS musi przejść całą planetę, to wciąż ogromne opóźnienie.

jak się okazuje, Infrastruktura, na której opiera się internet, jest wyjątkowo odpowiednia do rozwiązania tego problemu. Networkproviders używają protokołu Border Gateway, aby powiedzieć sobie nawzajem, do których sieci mogą dotrzeć i ile przeskoków są oddalone. Użytkownik końcowy ISP następnie, w większości przypadków, wybiera najkrótszą trasę, aby dotrzeć do miejsca docelowego.

jeśli teraz reklamujemy adresy IP w wielu lokalizacjach, żądanie DNS będzie zawsze kierowane do najbliższego węzła.Nazywa się to BGP Anycast.

dlaczego nie użyć BGP Anycast do pobrania strony? ▲ Powrót do góry Link Link tutaj

poczekaj, poczekaj, jeśli możemy to zrobić, dlaczego po prostu nie użyjemy BGP do kierowania ruchu internetowego? Są trzy powody.

po pierwsze, Robienie BGP Anycast wymaga kontroli nad sprzętem sieciowym i puli co najmniej 256 adresów IP, co znacznie przekracza nasz budżet.

po drugie, trasy BGP nie są tak stabilne. Podczas gdy żądania DNS wymagają wysłania tylko jednego pakietu w obu kierunkach, żądania HTTP (web) wymagają nawiązania połączenia w celu pobrania zawartości. Jeśli trasa się zmieni lub połączenie jestniestabilne, połączenie HTTP może zostać przerwane. To zwiększa złożoność projektu o takiej skali.

i wreszcie najniższa liczba przeskoków, która jest podstawą obliczeń trasy BGP, nie gwarantuje najniższego czasu podróży w obie strony. Skok przez ocean może być tylko jednym skokiem, ale jest cholernie długi.

Czytaj dalej
LinkedIn Engineering ma ciekawy wpis na blogu na ten temat.

Konfigurowanie DNS Back powrót do góry Link Link tutaj

ponieważ ustaliliśmy, że nie możemy uruchomić naszego własnego BGP Anycast, oznacza to, że nie możemy również uruchomić naszych własnych serwerów DNS. Solet idzie na zakupy! … OK, jak się okazuje, dostawcy DNS, którzy oferują serwery BGP Anycast i routing oparty na opóźnieniach, są trochę trudni do zdobycia. Podczas moich poszukiwań znalazłem tylko dwa, dość drogi Dyn i thedirt-tani Amazon Route53. (Aktualizacja: jak się okazuje, łatwy DNS robi również routing oparty na opóźnieniach.

skoro jesteśmy Tani, to Route53 jest. Dodajemy naszą domenę, a następnie rozpoczynamy konfigurowanie adresów IP dla naszych maszyn. Potrzebujemy tak wielu rekordów, jak Mamy serwery na całym świecie( lokalizacje brzegowe), a każdy rekord powinien wyglądać tak:

Route53 routing oparty na opóźnieniach należy skonfigurować w Route53, tworząc rekordy z adresem IP lokalizacji krawędzi, a następnie ustawiając zasadę routingu na "opóźnienie". Ustawiony identyfikator powinien być czymś unikalnym, a lokalizacja powinna być najbliższa naszej lokalizacji krawędzi.
Wskazówka:
przydatne jest skonfigurowanie kontroli stanu każdej z lokalizacji krawędzi, aby były one usuwane, jeśli spadną.

dystrybucja treści ▲ powrót do góry Link Link tutaj

kolejnym problemem, który musimy rozwiązać, jest dystrybucja treści. Każdy węzeł krawędzi musi mieć tę samą zawartość. Jeśli używasz statycznego generatora witryn, takiego jak Jekyll, Twoje zadanie jest proste: po prostu skopiuj wygenerowane pliki HTML na wszystkich serwerach. Coś tak prostego jak rsync może załatwić sprawę.

jeśli chcesz korzystać z systemu edycji treści, takiego jak WordPress, masz znacznie trudniejszą pracę, ponieważ nie jest zbudowany na CDN. Można to zrobić, ale nie jest to pozbawione jego wad, a rozpowszechnienie statycznej treści nadal stanowi problem. Być może trzeba będzie utworzyć rozproszoną pamięć obiektową do pełnej pracy.

używanie certyfikatów SSL/TLS Back powrót do góry Link Link tutaj

następnym punktem bólu jest używanie certyfikatów SSL/TLS. Nazwijmy je tym, czym są: certyfikatami x509. Każda z Twoich lokalizacji brzegowych musi mieć ważny certyfikat dla Twojej domeny. Prostym rozwiązaniem jest oczywiście użycieletsencrypt, aby wygenerować inny certyfikat dla każdego, ale musisz być ostrożny. Limit szybkości LE hasa, na który wpadłem na jednym z moich węzłów krawędziowych. W rzeczywistości, musiałem wziąć London node w dół na czas beinguntil tygodniowy limit wygasa.

jednak używam Traefik jako mojego wybranego serwera proxy, który obsługuje używanie rozproszonego Key-valuestore lub nawet Apache Zookeeper jako zaplecza do synchronizacji. Chociaż wymaga to nieco więcej inżynierii, prawdopodobnie jest o wiele bardziej stabilny na dłuższą metę.

wyniki ▲ powrót na górę Link Link tutaj

czas na prawdę, jak działa mój CDN? Korzystając z tego narzędzia, zobaczmy niektóre globalne statystyki:

Oregon: 246ms, Kalifornia: 298ms, Ohio: 227ms, Wirginia: 108ms, Irlandia: 217ms, Frankfurt: 44ms, Londyn: 110ms, Bombaj: 870ms, Singapur: 517ms, Seul: 253ms, Tokio: 150ms, Sidney: 358ms, Sao Paulo: 911ms

jak widać, wyniki są całkiem przyzwoite. Mogę potrzebować jeszcze dwóch węzłów, jednego w Azji i jednego w Ameryce Południowej, aby uzyskać lepsze czasy ładowania.

Update

po dotarciu na pierwszą stronę Wiadomości hakerskich (wow!), Miałem szansę zebrać trochę prawdziwych danych o użytkowaniu za pomocą Google Analytics:

 </figure><p></p>

Podsumowując: naprawdę potrzebuję tego węzła w Singapurze. Czasy ładowania w Indiach są powyżej pożądanej 1 sekundy.

Najczęściej zadawane pytania ▲ powrót na górę Link Link tutaj

kiedy robię takie projekty, ludzie zwykle mnie pytają: „Dlaczego to robisz? Musisz lubić ból.”Tak, do pewnego stopnia lubię robić rzeczy inaczej tylko ze względu na odkrywanie nowych opcji i technologii, budowanie własnego CDN może mieć wiele sensu. Zajmijmy się niektórymi pytaniami dotyczącymi tej konfiguracji.

powiedzmy sobie jasno: jeśli komercyjny dostawca wyjdzie z niedrogim CDN push, który pozwala mi robić ładne adresy URL, SSL i niestandardowe nagłówki, absolutnie rzucę na nich pieniądze i przestanę uruchamiać własną infrastrukturę. Mimo, że budowanie było zabawne, mam wystarczająco dużo serwerów, aby działać bez tego.

dlaczego po prostu nie użyjesz CloudFlare? ▲ Powrót do góry Link Link tutaj

CloudFlare jest wspaniałym narzędziem dla wielu, ale jak opisano powyżej, CDN upuszczają nieużywaną zawartość z pamięci podręcznej. Na innych stronach, którymi zarządzam, widzę szybkość pamięci podręcznej około 75% przy prawidłowej konfiguracji. Posiadanie własnego CDN oznacza, że 100% zawartości jest zawsze w pamięci podręcznej i nie ma dodatkowych przejazdów w obie strony do serwera origin.

dlaczego nie używasz S3 i CloudFront? ▲ Powrót do góry Link Link tutaj

Amazon S3 ma opcję hostowania statycznych stron internetowych i działa w połączeniu z CloudFront. Nie pozwala jednak na ustawienie niestandardowych nagłówków do buforowania, ładnych adresów URL itp. Do tego potrzebujesz [email protected], narzędzia, które umożliwia uruchamianie codeon węzłów CloudFront edge. Lambda @ Edge ma jednak ten sam problem co CDNs: jeśli nie odbiera żądań przez pewien czas, uruchomiony kontener jest zamykany i potrzebuje do sekundy na uruchomienie.

dlaczego nie korzystasz z Google AMP? ▲ Powrót do góry Link Link tutaj

Google AMP przynosi korzyści tylko wtedy, gdy ludzie odwiedzają Twoją witrynę z wyszukiwarki Google. Większość mojego ruchu nie pochodzi z Google, więc nie rozwiąże to problemu. Więc to naprawdę tylko korzyści Google, nikt inny. I jestem w stanie zbudować szybką stronę internetową bez głupiego HTML, który oferują.

kogo to obchodzi? 3 sekundy to wspaniały czas ładowania! ▲ Powrót na górę Link Link tutaj

jestem inżynierem DevOps, który specjalizuje się w dostarczaniu treści. Jeśli ktokolwiek, to powinienem mieć stronę internetową, która jest szybka wokół Globe, nie?

Och, a ja lubię odwracać Google AMP, bo to okropna technologia. Nie żeby ich to obchodziło.

rok później… ▲ powrót do góry 🔗 Link tutaj

rok później postanowiłem zburzyć mój CDN. Powody sprowadzają się do tego, że już wspomniałem: ten system nie jest gotowy do produkcji. Kilka miesięcy temu niektórzy z moich stałych czytelników zauważyli, że moja strona czasami powraca z 404. Po bliższym zbadaniu okazało się, że powodem tego 404 było użycie procesora.

Nie wykorzystanie procesora moich maszyn, ale moich „sąsiadów”. Logując się do mojego serwera widziałem procesor kradnący czas do 90%:

to wysokie zużycie procesora spowodowało, że Traefik opuścił backend z powodu limitu czasu, co z kolei spowodowało błąd 404. Gdy zainstalowałem Uptime Robot, aby sprawdzić moją witrynę, zdałem sobie sprawę, że jest to dość powszechne zjawisko i stało się 3-4 razy w tygodniu.

można mieć wątpliwości co do Amazon Lightsail (platformy wirtualizacji w ramach CDN), ale wskazuje to na dużą ilustrację: przy takim rozproszonym systemie monitorowanie i zapewnienie jakości jest kluczowe. Potwierdziły to moje rozmowy z innymi inżynierami działającymi w systemach rozproszonych globalnie: nie ma absolutnie żadnej magii w budowaniu takiego CDN. Uruchamianie go, jednak realing z podstawowej wydajności platformy, lub wydajność sieci, jest trudnymktóry wymaga ciągłego wysiłku i konserwacji.

w rezultacie przebudowałem konfigurację na jednym serwerze, z infrastrukturą animmutable i odpowiednim monitoringiem, za pomocą Terraform. Jeśli chcesz dowiedzieć się więcej o tym, jak to zrobiłem, przeczytaj artykuł tutaj.

Dodaj komentarz

Twój adres e-mail nie zostanie opublikowany.