Jak rozwiązywać problemy i zmniejszyć zwiększone opóźnienie od Cloudfront

Krótki opis

Aby rozwiązać problem opóźnienia od Cloudfront, najpierw określ, które z poniższych zdarzeń przyczyniają się do opóźnienia:
– Czas wymagany na przejechanie między klientem a lokalizacjami Cloudfront Edge. Obejmuje to proces wyszukiwania systemu nazwy domeny (DNS) oraz negocjacje TCP i SSL/TLS.
– Czas wymagany na prośby o przejście między Cloudfront a pochodzeniem. Obejmuje to proces wyszukiwania DNS, TCP i SSL/TLS negocjacje z pochodzeniem oraz czas przyjęty przez pochodzenie, aby przetworzyć i odpowiedzieć obiektem.
Następnie postępuj zgodnie z krokami rozwiązywania problemów zidentyfikowanych zdarzeń w celu zmniejszenia opóźnienia.

Podsumowanie artykułu

W artykule omówiono doświadczenie autora w budowaniu wysokowydajnej aplikacji internetowej za pomocą Amazon Web Services (AWS), a konkretnie koncentruje się na zmniejszeniu opóźnień z CloudFront. Autor wyjaśnia tło projektu, badając różne sposoby osiągnięcia niskiego opóźnienia, a użyta architektura.
Autor podkreśla znaczenie ostatecznej spójności i omawia wyzwanie związane z zwróceniem pierwszych wyników konsumentom, jednocześnie agregując pozostałe wyniki od różnych dostawców. Zespół korzysta z asynchronicznych połączeń i AWS Elasticache dla Redis, aby osiągnąć ten cel.
Po stronie infrastruktury autor wybrał AWS Elastic Container Service (ECS) pod kątem skalowalności i Amazon Cloudfront w celu uzyskania wysokiej dostępności. Cloudfront działa jak druga warstwa buforowania na AWS Elasticache dla Redis. Artykuł zawiera ogólny schemat architektury AWS do zilustrowania systemu.
Aby zapewnić wysoką dostępność i skalowalność, zaimplementowano autoscaling dla usługi ECS. Balancer z ładunkiem aplikacji wykrywa zdrowe zadania Fargate, kończy niezdrowe zadania i wprowadza nowe zadania, aby je zastąpić. Korzystanie z wielu stref dostępności zapewnia, że ​​aplikacja działa, nawet jeśli strefa dostępności staje się niedostępna.
Autor przeprowadził testy obciążenia za pomocą JMeter i porównał opóźnienie między balansem obciążenia aplikacji a Cloudfront. Wyniki wykazały znaczny spadek opóźnienia podczas korzystania z Cloudfront, wraz z 0% błędem.
Podsumowując, autor uważa, że ​​projekt jest nagradza i przekazuje informacje zwrotne od lojalności Ascenda na temat zaimplementowanej architektury. Artykuł kończy się zaproszeniem do obejrzenia wersji aplikacji.

Pytania i odpowiedzi

1. Jakie są zdarzenia, które mogą przyczynić się do zwiększonego opóźnienia z Cloudfront?

Podczas procesu rozwiązywania problemów należy rozważyć następujące zdarzenia:
– Czas wymagany na przebywanie między klientem a lokalizacjami Cloudfront Edge, w tym proces wyszukiwania DNS oraz negocjacjami TCP i SSL/TLS.
– Czas wymagany na prośby o przejście między Cloudfront a pochodzeniem, w tym proces wyszukiwania DNS Origin, TCP i SSL/TLS Negocjacje z pochodzenie.
2. Jak mogę rozwiązywać problemy i zmniejszyć opóźnienie z Cloudfront?

Aby rozwiązać problemy i zmniejszyć opóźnienie od CloudFront, wykonaj następujące kroki:
– Zidentyfikuj, które z wyżej wymienionych wydarzeń przyczyniają się do opóźnienia.
– Dla każdego zdarzenia przeanalizuj i optymalizuj odpowiednie procesy. Na przykład upewnij się, że wydajne wyszukiwanie DNS, zminimalizuj liczbę podróży TCP lub SSL/TLS i optymalizuj czas odpowiedzi pochodzenia.
– Użyj narzędzi do monitorowania i rejestrowania CloudFront, aby gromadzić dane i uzyskać wgląd w wydajność dystrybucji.
– Regularnie przejrzyj i udoskonalaj konfiguracje CloudFront, aby zapewnić optymalną wydajność.
3. Jakie jest znaczenie ewentualnej spójności w aplikacji?

Aplikacja wymaga ostatecznej spójności, aby osiągnąć wysoką dostępność bez poświęcania tolerancji partycji. Ścisła spójność nie byłaby wykonalna ze względu na twierdzenie Brewera (twierdzenie CAP), które stwierdza, że ​​niemożliwe jest zagwarantowanie spójności, dostępności i tolerancji partycji jednocześnie w systemie rozproszonym. Wybierając ostateczną spójność, aplikacja może szybko zapewnić konsumentom pierwsze wyniki, jednocześnie agregując pozostałe wyniki.
4. W jaki sposób zespół agreguje wyniki wielu dostawców hoteli?

Zespół wykorzystuje asynchroniczne połączenia z wieloma dostawcami hoteli. Pozwala im to zwrócić pierwsze wyniki konsumentom, jednocześnie stopniowo agregując pozostałe wyniki w tle. AWS Elasticache dla Redis służy również do buforowania wyników, dalszego zwiększania wydajności.
5. Jaki jest cel korzystania z usługi Elastic Container AWS (ECS) w architekturze?

Usługa elastycznego kontenera AWS (ECS) jest używana do zapewnienia skalowalności w aplikacji. Korzystanie z kontenerów umożliwia łatwe zarządzanie i wdrażanie aplikacji, a automatyczne jest wdrażane do obsługi obciążenia ruchu poprzez odpowiednio skalowanie usług zaplecza.
6. W jaki sposób Amazon Cloudfront zapewnia wysoką dostępność?

Amazon Cloudfront działa jak druga warstwa buforowania na AWS Elasticache dla Redis. Służy jako sieć dostarczania treści (CDN), która buforuje i dostarcza zawartość z najbliższej lokalizacji krawędzi do użytkownika końcowego. Pomaga to zmniejszyć opóźnienie i zapewnia, że ​​aplikacja internetowa STATIC Reacct JS hostowana na S3 pozostaje wysoce dostępna.
7. Jakie są korzyści z korzystania z autoscalingu w usłudze ECS?

Autoscaling zapewnia, że ​​aplikacja może poradzić sobie z obecnym popytem, ​​udostępniając odpowiednią ilość zasobów i pojemności. Umożliwia automatycznie i wychodząc usługi zaplecza, co czyni je odporną na usterki i opłacalne.
8. W jaki sposób równoważenie obciążenia aplikacji zapewnia zdrowie zadań Fargate?

Balancer z ładunkiem aplikacji używa punktu końcowego kontroli zdrowia w usługach zaplecza, aby określić zdrowie zadań Fargate. Jeśli punkt końcowy kontroli zdrowia nie jest dostępny, uwzględnia zadanie niezdrowe, deregistruje je z grupy docelowej, kończy je i rozpoczyna nowe zadanie, aby. Zapewnia to, że aplikacja pozostaje dostępna, nawet jeśli strefa dostępności staje się niedostępna.
9. Jakie korzyści zapewnia CloudFront w porównaniu z równowagą ładowania aplikacji?

W przeprowadzonych testach obciążenia żądania złożone do Cloudfront wykazały znaczny spadek opóźnienia w porównaniu do równoważenia obciążenia aplikacji. Cloudfront działa jak CDN i pomaga buforować i dostarczać zawartość z lokalizacji krawędzi bliżej użytkownika końcowego, co skutkuje poprawą wydajności i zmniejszonym opóźnieniem.
10. Jak autor opisuje swoje doświadczenie w pracy nad projektem?

Autor opisuje projekt jako zniechęcający, szczególnie dla początkujących w AWS. Jednak satysfakcjonujące było również udane wdrożenie i osiągnięte niesamowite wyniki.

Jak rozwiązywać problemy i zmniejszyć zwiększone opóźnienie od Cloudfront

Знайте, как с помощю Amazon Cloudfront наладить доставку конта и искорить работу инaлforеззаааааа-łatra.

Osiągnięcie niskiego opóźnienia dzięki Amazon Cloudfront

Budowanie aplikacji internetowej o wysokiej dostępności i ostatecznej spójności

Opublikowane w

4 min Przeczytaj

23 maja 2021

Tło

To był projekt, który niedawno zrobiłem w pierwszej połowie 2021. Była to współpraca z lojalnością Assenda, w której mój zespół miał za zadanie zbudować wysokowydajną aplikację za pomocą Amazon Web Services (AWS). Wymagania dotyczące aplikacji są takie, że powinny być wysoce skalowalne i dostępne przy osiągnięciu ostatecznej spójności.

Ważne jest, aby wspomnieć o ostatecznej spójności, a nie ścisłej spójności, ponieważ praktycznie niemożliwe było osiągnięcie zarówno wysokiej dostępności, jak i ścisłej spójności bez poświęcania tolerancji partycji. Wynika to z piwowaru’Twierdzenie s (Twierdzenie o czapce).

W odniesieniu do aplikacji jego główną funkcją byłoby agregowanie wyników różnych dostawców hoteli i wyświetlanie wyników o niskim opóźnieniu dla konsumentów (korzystających z aplikacji). Ponieważ nasza aplikacja łączy się z wieloma dostawcami hoteli o różnych punktach końcowych, a tym samym w różnych czasach opóźnień, od 2 sekund do 20 sekund, jest to również wyzwanie, aby najpierw zwrócimy pierwsze wyniki konsumentom i ostatecznie zapewnić najlepsze wyniki.

Badanie

Nasz zespół bada różne sposoby spełnienia tego wymogu. Rozważaliśmy różne usługi, z których możemy korzystać w AWS, wzorach projektowych i wzorach komunikacji. Po stronie programowania agregujemy wyniki przy użyciu połączeń asynchronicznych do wielu dostawców, abyśmy mogli najpierw zapewnić naszym konsumentom wyniki, jednocześnie powoli agregując pozostałe wyniki. Mój kolega z drużyny zrobił fajny artykuł na ten temat, w którym używamy również AWS Elasticache dla Redis.

Amazon Web Services (AWS)

Po stronie infrastruktury nasz zespół postanowił wykorzystać usługi Elastic Container AWS (ECS), aby dostarczyć skalowalne wymagania i Amazon Cloudfront, aby zapewnić wysoką dostępność. Amazon Cloudfront działa również jako druga warstwa buforowania oprócz wyników, które zostały buforowane w AWS Elasticache dla Redis.

To jest nasz ogólny schemat architektury AWS.

Z powyższego schematu wynika również, że Amazon Cloudfront zapewniał wysoką dostępność naszej statycznej aplikacji internetowej React JS, która jest przechowywana w wiadrze S3. AWS S3 Storage ma trwałość danych wynoszącą 99.9999999999% ze względu na jego budowę wokół regionów, więc statyczna strona hostowana na S3 prawdopodobnie nie spadnie. Ponadto, wersja jest włączona na wiadrze S3 zawierającą statyczną stronę internetową, zapobiegając przypadkom usuwania, pozwalając nam zachować, pobierać i przywrócić każdą wersję konkretnego obiektu.

Aby zapewnić wysoką dostępność i skalowalność aplikacji, zaimplementowano autoscaling dla usługi ECS. Zapewnia to, że usługi zaplecza są odporne na uszkodzenia i mogą obsługiwać obciążenie ruchu poprzez odpowiednio skalowanie i wychodzenie (w zależności od ruchu).

Balancer z ładunkiem aplikacji wykrywa, czy zadania Fargate są zdrowe za pomocą punktu końcowego kontroli zdrowia w usługach zaplecza. Jeśli punkt końcowy kontroli zdrowia nie jest osiągalny, uznałoby to niezdrowe zadanie, wyrejestrował je z grupy docelowej, zakończy zadanie i wykonaj nowe zadanie, aby je zastąpić. Gdy wdrożyliśmy usługę ECS w wielu strefach dostępności, jeśli strefa dostępności miała być niedostępna, będą wystąpienia w innych strefach dostępności, które utrzymają aplikację. Więcej zadań zostanie przeprowadzone automatycznie w zależności od ruchu. Dzięki korzystaniu z automatycznego zakresu zapewniamy, że tylko odpowiednia ilość zasobów i pojemności jest dostarczana do obsługi obecnego popytu, oszczędzając koszty na dłuższą metę.

Wyniki

Użyliśmy JMeter do załadunku naszej aplikacji, z 500 użytkownikami i 1 szaleństwem, wskazując na dwa różne punkty końcowe (malancer ładunkowy aplikacji i Cloudfront). Patrząc na wyniki, widzimy, że żądania złożone do Cloudfront są znacznie lepsze z ogromnym spadkiem opóźnień (~ 80% zmniejszenie opóźnienia). Wskaźnik błędu był również zaskakująco 0%. Powinno to wynikać z wysokiej dostępności i automatycznego skalowania AWS ECS.

Na wynos

Chociaż ten projekt był zniechęcający, szczególnie dla nas, początkujących w AWS, z pewnością satysfakcjonujące było widzenie tego rodzaju niesamowitych wyników, co oznacza, że ​​nasze wdrożenie było dobre i godne pochwały.

Niektóre informacje zwrotne przekazane na temat naszej architektury przez lojalność Ascenda:

“Hosting of Frontend na S3 -> Niezły pomysł. Wygląda na to, że oni’ponownie budować prawdziwe spa”

Jeśli jesteś zainteresowany tym, co osiągnęliśmy, możesz zobaczyć demo naszej aplikacji tutaj!

Dziękuję za przeczytanie: D

Jak rozwiązywać problemy i zmniejszyć zwiększone opóźnienie od Cloudfront?

Widzę zwiększone opóźnienia w odpowiedzi z Amazon Cloudfront. Jak mogę zidentyfikować przyczynę i zmniejszyć opóźnienie?

Krótki opis

Aby rozwiązać problem opóźnienia od Cloudfront, najpierw określ, które z poniższych zdarzeń przyczyniają się do opóźnienia:

• Czas wymagany na przejechanie między klientem a lokalizacjami Cloudfront Edge. Obejmuje to proces wyszukiwania systemu nazwy domeny (DNS) oraz negocjacje TCP i SSL/TLS.
• Czas wymagany na prośby o przejście między Cloudfront a pochodzeniem. Obejmuje to proces wyszukiwania DNS, TCP i SSL/TLS negocjacje z pochodzeniem oraz czas przyjęty przez pochodzenie, aby przetworzyć i odpowiedzieć obiektem.

Następnie postępuj zgodnie z krokami rozwiązywania problemów dla zdarzeń, które powodują największe opóźnienie.

Rezolucja

Zidentyfikuj zdarzenia powodujące opóźnienie z Cloudfront:

Aby określić, które zdarzenia powodują opóźnienie z Cloudfront, wykonaj jedną z następujących czynności:

• Uruchom następujące polecenie Curl:

curl -w "dns_resolution: %| tcp_negotiation_time: %| ssl_negotiation_time: %| ttfb: %| Całkowity czas: %\ n" -o/dev/null -vsl https: // www.przykład.com
 
 
Notatka: Zastępować przykład.com z nazwą domeny Cloudfront lub alternatywną nazwą domeny (CNAME) i ścieżką URL.
 
 
Sprawdź, jak długo każdy etap żądania sieci wymaga narzędzi programistów Twojej przeglądarki internetowej. Na przykład, jeśli używasz Mozilla Firefox, karta czasu zawiera te informacje.
 
 
Na podstawie zajęty czas Dla każdego zdarzenia lub żądania zobacz sekcję powiązanej rozdzielczości w tym artykule.
 
Jeśli zaobserwowałeś opóźnienie w przeszłości, sprawdź pola zajęty czas I Czas do pierwszego bytu W dziennikach dostępu do Cloudfront. Dzienniki dostępu CloudFront nie rejestrują czasu poświęconego przez klienta na proces wyszukiwania DNS oraz negocjacje TCP i SSL/TLS
 
Zmniejszenie opóźnienia w rozdzielczości DNS
 
 
 
Zwiększ czas buforowania DNS w DN po stronie klienta.
 
Zwiększyć Czas na życie (TTL) pamięci podręcznej na lokalnym serwerze DNS.
 
Zwiększyć Ttl w rekordach DNS w rejestrze/dostawcy DNS.
 
Jeśli zdecydowanie serwer DNS od dostawcy usług internetowych powoduje opóźnienie, a następnie rozważ korzystanie z publicznych serwerów DNS.
 
 
Zmniejszenie opóźnienia w TCP i SSL/TLS - czas negocjacji
 
 
 
Sprawdź przepustowość sieci lokalnej i przepustowość Internetu.
 
Sprawdź, czy występuje zakłócenie sieci w dostawcy lub routera serwera internetowego.
 
Zoptymalizuj wydajność sieci lokalnej za pośrednictwem dostawcy usług internetowych lub tras sieciowych.
 
Potwierdź, że używasz prawidłowego rozwiązania DNS, który pozwala Twojej przeglądarce internetowej znaleźć najbliższą i poprawną lokalizację pop.
 
Aby poprawić wydajność witryny HTTPS, utrzymuj krótki łańcuch certyfikacyjny.
 
Opóźnienie może być spowodowane przez zaporę ogniową, proxy lub lokalny router. Aby ustalić, które z nich powoduje opóźnienie, uruchom następujące polecenie MTR z systemu. Aby uzyskać więcej informacji, zobacz zdiagnozowanie problemów sieciowych z MTR.
 
 
Przykład MTR -RW.com-no-dns
 
 
Notatka: Zastępować przykład.com z nazwą domeny.
 
Zmniejszenie opóźnienia w czasie wymaganym dla pierwszego bajtu (TTFB) i całkowitego czasu (TTL)
 
 
Jeśli CloudFront zwróci „X-Cache: Hit z Cloudfront”
 
Cloudfront zwraca „X-Cache: Hit from Cloudfront”, gdy żądania są podawane z najbliższej lokalizacji krawędziowej. Aby zmniejszyć opóźnienie:
 
 
Włącz automatyczną kompresję Cloudfront, aby kompresować pliki i zwiększyć prędkość pobierania.
 
Użyj buforowania lokalnego lub przeglądarki, aby zmniejszyć żądania do Cloudfront. Podaj nagłówek kontroli pamięci podręcznej w plikach, aby poinstruować przeglądarki internetowe, aby przechowywać zawartość witryny w pamięci przeglądarki lub na dysku lokalnym przez określony czas. Aby uzyskać więcej informacji na temat nagłówków kontroli pamięci podręcznej, patrz Określenie czasu, jaki CloudFront buforuje obiekty.
 
 
Jeśli CloudFront zwraca „X-Cache: Miss From Cloudfront”
 
Jeśli CloudFront zwraca „X-Cache: Miss From Cloudfront”, gdy żądanie zostanie wysłane do pochodzenia. Aby zmniejszyć opóźnienie:
 
 
Skróć czas podróży w obie strony (RTT) między lokalizacją Cloudfront Edge do lokalizacji pochodzenia. Jeśli żądanie z lokalizacji Cloudfront Edge trafi do najbliższej lokalizacji pochodzenia, wówczas RTT jest mniej. Jednak wpływa to na TTFB, jeśli żądanie pochodzi z lokalizacji krawędziowej geograficznie odległości od pochodzenia. Aby zoptymalizować RTT, powtórz serwer pochodzenia w wielu regionach, które są geograficznie bliższe użytkownikom. Następnie skonfiguruj DNS swojej nazwy domeny pochodzenia, aby prowadził żądanie serwerów pochodzenia na podstawie opóźnień lub geolokalizacji. Jeśli używasz Amazon Route 53 jako dostawcy DNS, zobacz Wybór zasady routingu, aby uzyskać więcej informacji.
 
Włącz automatyczną kompresję Cloudfront, aby kompresować pliki i zmniejszyć prędkość pobierania. Jeśli format pliku nie jest obsługiwany przez automatyczną kompresję CloudFront, to wstępnie skompresuj ten plik w swoim pochodzeniu i podawaj go z Kodowanie treści nagłówek.
 
Sprawdź opóźnienie od pochodzenia do Cloudfront, umożliwiając wskaźnik opóźnienia pochodzenia. Notatka: Obowiązują standardowe stawki CloudWatch.
 
Włącz tarczę Origin Cloudfront.
 
Dodaj zasady nagłówków odpowiedzi z włączoną funkcją nagłówka serwera. Ta funkcja może pomóc zrozumieć zdarzenia, które przyczyniają się do opóźnienia między Cloudfront a pochodzeniem.
 
 
Zmniejsz opóźnienia użytkowników końcowych z interfejsami API z wieloma regionami z CloudFront
 
 
W miarę rozwoju organizacji często muszą służyć użytkownikom rozproszonym geograficznie o niskim opóźnieniu, co skłoniło ich do rozproszonej globalnej infrastruktury w chmurze. W tym artykule opisujemy, jak wdrażać globalne punkty końcowe API, aby zmniejszyć opóźnienie użytkowników końcowych, jednocześnie zwiększając aplikację’dostępność S.
 
Korzystając z AWS Global Network i Amazon Cloudfront do wdrażania aplikacji w wielu regionach AWS, organizacje mogą pozwolić użytkownikom połączyć się z punktem końcowym API w regionie z najniższym opóźnieniem w sprawie żądania API’pochodzenie, jednocześnie uzyskując dostęp do danych, które są automatycznie utrzymywane w synchronizacji między regionami w czasie rzeczywistym.
 
Aby wyjaśnić rozwiązanie dla programistów API GraphQL, zapewniamy architekturę za pomocą AWS AppSync. Architektura ta opiera się na zestawie komponentów obsługi scenariuszy aktywnych/aktywnych w wielu regionach, a mianowicie: Cloudfront, Amazon Route 53, AWS Certifate Manager (ACM) i AWS lambda@Edge.
 
W przypadku GraphQL ten artykuł uzupełnia poprzedni post wdrożenie Multi Region AWS Appsync z globalnymi tabelami Amazon DynamoDB, wyjaśniając, jak przekształcić globalne rozwiązanie Active/Passive Appsync w aktywne/aktywne. Ponadto zapewnia alternatywę opartą na CloudFront dla niestandardowych nazw domen dla API AWS Appsync.
 
Jeśli ty’Ponowne programistę interfejsu API REST, a następnie możesz osiągnąć podobne wyniki, śledząc post za pomocą routingu opartego na opóźnieniu z Amazon Cloudfront dla aktywnej architektury aktywnej wielokrotności. Tam ty’Znajdź również wskazówki dotyczące kompromisów kosztów i złożoności, które pomogą ci przemyśleć względy architektoniczne i ich wpływ na funkcjonalność, odporność i wydajność twoich aplikacji.
 
API GraphQL z wieloma regionami z Cloudfront
 
 
Widzimy, że organizacje coraz częściej wybierają interfejsy API z GraphQL do szybszego dostarczania aplikacji, dając programistom front-end możliwość zapytania o wiele baz danych, mikrousług i interfejsów API za pomocą jednego punktu końcowego.
 
Poniższy schemat architektury (ryc. 1) opisuje, jak zmniejszyć opóźnienie użytkowników końcowych, jednocześnie zwiększając aplikację’Dostępność S poprzez dostarczenie punktów końcowych API GraphQL w wielu regionach, z aktywną/aktywną synchronizacją danych w czasie rzeczywistym obsługiwanym przez globalne tabele Amazon DynamoDB. W wersji tego schematu jest dostępna pod tym linkiem. Aby uzyskać dodatkowe informacje na temat wdrożenia replikacji Amazon DynamoDB, przeczytaj post wdrożenie AWSSync w regionie Multi Region z Amazon DynamoDB Global Tabele.
 
 
Rysunek 1: Schemat API GraphQL z wieloma regionami z CloudFront
 
Postępuj zgodnie z następującymi krokami, aby wdrożyć architekturę pokazaną na schemacie:
 
 
Wdrażaj interfejs API GraphQL w dwóch lub więcej regionach za pomocą AWS AppSync, a następnie obsługuj polecenia i zapytania AppSync za pomocą AWS LambDA Resistvers podłączone do bazy danych DynamODB.
 
Aby powiadomić klientów o zmianach danych we wszystkich regionach, włącz globalne tabele DynamoDB, aby zachować synchronizację w różnych regionach, a następnie obsłużyć strumienie danych DynamoDB za pomocą obsługi Lambda, tym samym wyzwalając subskrypcje schematu GraphQL w celu zbudowanego przez cel. Aby uzyskać dodatkowe informacje na temat tego, jak to zrobić, zobacz Post Multi Region wdrożenie AWS AppSync z globalnymi tabelami Amazon DynamoDB.
 
Aby obsługiwać niestandardowe domeny, prześlij domenę’certyfikat SSL do ACM i dołącz go do rozkładu Cloudfront.
 
Wskaż nazwę domeny na Cloudfront za pomocą Route 53 jako usługi rozdzielczości nazwy DNS.
 
Skonfiguruj zasadę routingu na Route 53, aby skierować swoich globalnych klientów do regionu AWS z mniejszym opóźnieniem do ich lokalizacji.
 
Aby Twoi klienci mogli bezproblemowo uwierzytelnić punkty końcowe AWS AppSync w dowolnym regionie, użyj Lambda@Edge, aby zapytać o Route 53, aby przekazać żądanie, i znormalizować autoryzację poprzez wyodrębnienie specyficzności każdego regionalnego AppSync.
 
Następnie klienci na całym świecie mogą połączyć się z interfejsem API GraphQL w jednym punkcie końcowym dostępnym w lokalizacjach Edge.
 
Cloudfront bezproblemowo prowadzi klientów’ żądania API w regionie z najniższym opóźnieniem dla klienta’S Lokalizacja.
 
 
Konfigurowanie CloudFront
 
 
Oto kroki, aby skonfigurować CloudFront dla rozwiązania Active/Active Multi-Region w tym artykule:
 
 
Zacznij od utworzenia jednego prostego ogólnego dystrybucji CloudFront (patrz jak tutaj).
 
Pochodzenie rozkładu ISN’t istotne dla stanu końcowego naszego rozwiązania, ponieważ zostanie ono zastąpione punktami końcowymi API. Musi być jednak możliwe do rozwiązania, aby wywoływano funkcję lambda@edge. Na przykład możesz użyć AWS.Amazonka.com jako twoje pochodzenie.
 
Dla uproszczenia rozwiązanie opisane w tym poście implementuje bezpieczny niestandardowy adres URL, począwszy od globalnego API . Na przykład, jeśli Twoja niestandardowa domena jest przykładem.com, wówczas aktywny/aktywny interfejs API jest dostępny na stronie https: // global-api.przykład.com . Aby go obsługiwać, dodaj alternatywną nazwę domeny (e.G., Global-API.przykład.com) do dystrybucji Cloudfront (patrz jak tutaj).
 
 
W dystrybucji CloudFront edytuj zachowanie i ustaw następujące wartości właściwości:
 
 
Zmiana “Dozwolone metody HTTP” Do “ Zdobądź, głowa, opcje, umieszczaj, post, łatanie, usuń ” - Umożliwi to żądania Post niezbędne do obsługi zapytań GraphQL.
 
Zmiana “Polityka pamięci podręcznej” Do “ Buforowanie ” - To usunie dowolną pamięć podręczną, aby upewnić się, że wszystkie żądania są dynamiczne.
 
Zmiana “Polityka żądania pochodzenia” Do “ Allviewer ” - To doda wymagane informacje do ładunku wysłanego do funkcji Lambda@Edge.
 
 
Konfigurowanie ACM
 
 
Aby wdrożyć rozwiązanie opisane w tym artykule, użyj ACM, aby poprosić o certyfikat publiczny do swojej domeny niestandardowej (patrz jak tutaj). To rozwiązanie wykorzystuje subdomeny, więc musisz poprosić o certyfikat obsługujący dzikie karty. Na przykład, jeśli twoja domena jest “przykład.com”, Następnie poproś o certyfikat, aby obsłużyć oba “przykład.com” I “*.przykład.com”.
 
Po tym, jak certyfikat będzie dostępny i zatwierdzony w ACM, dołącz go do dystrybucji CloudFront (zobacz, jak tutaj).
 
Konfigurowanie Amazon Route53
 
 
Aby wdrożyć rozwiązanie opisane w tym artykule, utwórz następujące rekordy w strefie hostowanej Route 53 dla Twojej domeny:
 
 
Prosty rekord CNAME, który służy jako punkt wejścia do dystrybucji Cloudfront (patrz jak tutaj).
 
Rekord z zasadą routingu opartą na opóźnieniu w celu skonfigurowania wielu regionalnych interfejsów API (zobacz, jak tutaj). Poprawia to wydajność dla użytkowników, obsługując ich żądania z regionu AWS, który zapewnia najniższe opóźnienie.
 
Niestandardowa domena dla każdego regionu (użyj tej samej domeny niestandardowej w następnej funkcji Lambda).
 
 
Na przykład, jeśli twoja domena jest “ przykład.com ”, Twój dystrybucja Cloudfront jest “ ABCDEFGHIJ.Cloudfront.internet ”, I masz interfejsy API w regionach Europy (Irlandii) i Azji i Pacyfiku (Sydney), a następnie powinieneś skończyć z konfiguracją Route 53 podobną do rysunku 2.
 
 
Rysunek 2: Tabela rekordów na trasie 53
 
Zwróć uwagę na następujące popularne błędy podczas konfigurowania Route 53:
 
 
 “Irlandia” I “Sydnej” Zapisz wartości w powyższym przykładzie’URL regionalnych punktów końcowych API. Zamiast tego są klucze słownika zdefiniowanego w następnym kodzie Lambda@.
 
Nazwy rekordów opóźnień w powyższym przykładzie są’t specyficzne dla regionu. Zamiast tego oni’Ponowne nazwy rekordów, z którymi Lambda@Edge skontaktuje się z Route 53 dla zalecanego regionu’S KLUCZ.
 
 
Aby uzyskać dodatkowe informacje na temat tego, jak ta konfiguracja Route 53 jest używana w kontekście rozwiązania, wykonaj kroki w sekcji testowej tego artykułu. Pozwalają one zacząć od pustego konta AWS i zbudować drogę do w pełni funkcjonalnego wieloregionalnego środowiska, które można przetestować z vue.Aplikacja JS.
 
Kod Lambda@Edge
 
 
Aby zaimplementować rozwiązanie w tym artykule, utwórz funkcję lambda@edge w węźle.JS Korzystanie z fragmentów kodu w tej sekcji jako szablon (patrz jak tutaj).
 
Istnieje wiele sposobów wdrażania funkcji na CloudFront. Prostym sposobem jest wybranie “ działania ” rozwijanie edytora Lambda, a następnie wybierz “ Wdrożenie do Lambda@Edge ”.
 
Poniższy kod pozwala znaleźć najlepszy region AWS na przychodzące żądanie. Zakłada, że ​​ustawiłeś już zasadę routingu na wyznaczonej trasie 53 “ opóźnienie ”. Możliwe wyniki tej funkcji, biorąc pod uwagę przykład w powyższej tabeli Route 53, są “Irlandia” I “Sydnej”.
 
const dns = wymaga (&bdquo;dns&rdquo;); Niech bestorigin; Niech wygasa = 0; Niech ttl = 1; Niech DNS_HOST = 'ROUTING LATENCY.przykład.com '; funkcja getBestRegion () < console.log("inside resolver"); const now = Date.now(); if (now < expires) return Promise.resolve(bestOrigin); return new Promise((resolve, reject) => < dns.resolveCname(DNS_HOST, (err, addr) =>< bestOrigin = addr[0]; expires = now + TTL; resolve(bestOrigin); >); >); > 
 
 
Poniższy kod pozwala mapować najlepszy region AWS (oceniany przez Route 53) do opublikowanego interfejsu API. Ten kod uwzględnia przykładowe ustawienia Route 53 w powyższej tabeli, z dwoma wpisami API GraphQL (jeden dla Irlandii i jeden dla Sydney). Musisz zmienić ten kod, aby pasować do ustawień regionalnych punktów końcowych API.
 
Niech regiony = []; // Użyj małych liter. Regiony [&bdquo;Irlandia&rdquo;] = < "Host": "" >; Regiony [&bdquo;Sydney&rdquo;] = < "Host": "" >; funkcja getregionalsettings (bestregion)
 
 
Poniższy kod wykorzystuje funkcję getBestregion, aby znaleźć najlepszy region AWS (zgodnie z trasą 53), a następnie mapuje go do domeny i sekretu interfejsu API za pomocą funkcji getregionalsettings, a na koniec zmienia nagłówki żądania, aby przekazać żądanie wybranego interfejsu API.
 
eksport.Handler = async (zdarzenie, kontekst, wywołanie zwrotne) => < const request = event.Records[0].cf.request; let bestRegion = await getBestRegion(); let map = getRegionalSettings(bestRegion); let target_domain = map["Host"]; // Forward GraphQL subscription requests for WebSockets. request.origin.custom.domainName = target_domain; // Forward REST and GraphQL query/mutation requests. request.headers["host"] = [< key: "host", value: target_domain >]; // konsola.log (`` nagłówki żądania ustawione na wywołanie zwrotne &bdquo;$&rdquo; (null, żądanie); >;
 
 
Przejście od końca do końca
 
 
Poniższy schemat (ryc. 3) pokazuje kompleksowy przepływ komunikacji między rozwiązaniem&rsquo;S Składniki.
 
Wizualnie opisuje, w jaki sposób żądanie klienta jest najpierw przetłumaczone przez Route 53 (lub dowolny inny serwer DNS), a następnie wysyłany do dystrybucji CloudFront zarejestrowanej na DNS. CloudFront następnie sprawdza żądanie&rsquo;S Certyfikat za pomocą ACM, a następnie zmienia początek w punkcie końcowym API z najniższym opóźnieniem dla klienta, wykorzystując Lambda@Edge. Wreszcie wniosek jest wysyłany do najlepszego regionalnego punktu końcowego API i API&rsquo;Odpowiedź S jest dostarczana z powrotem do klienta przez CloudFront.
 
 
Rysunek 3: Schemat przepływu wiadomości
 
Testowanie rozwiązania aktywnego/aktywnego w wielu regionach
 
 
W teście opisanym w tym artykule ty&rsquo;LL używa tych samych regionów Irlandii i Sydney, które zostały użyte w poprzedniej konfiguracji próbki Route 53. Kroki testowe zakładają, że ty&rsquo;ve wykonałem już poprzednie kroki wymienione w tym artykule&rsquo;S Poprzednie rozdziały, aby zbudować rozwiązanie wielofunkcyjne.
 
Aby kontrolować, który region ty&rsquo;ponownie trafić podczas testowania, ty&rsquo;LL potrzebuje klienta proxy VPN lub czegoś podobnego. Kroki testowe w tym artykule przeprowadzono za pomocą Mullvad, komercyjnej usługi VPN z siedzibą w Szwecji z siedzibą w Szwecji.
 
Testowanie interfejsu Aktywnego/Aktywnego API GraphQL z wieloma regionami
 
 
Wykonaj następujące kroki, aby przygotować testy rozwiązania wielofunkcyjnego dotyczące punktów końcowych API GraphQL.
 
W tej sekcji pozwala zbudować środowisko testowe AppSync od zera, nawet jeśli nie masz wcześniejszego doświadczenia z AppSync. Ty&rsquo;LL użyje tego środowiska jako kwalifikacji wstępnej do testowania zapytań i subskrypcji GraphQL w następnych dwóch sekcjach.
 
 
Uruchom przykładowy interfejs API GraphQL w regionach Irlandii i Sydney. To wdroży w pełni funkcjonalny punkt końcowy API AppSync z przykładowym schematem obsługiwanym przez regionalną bazę danych DynamoDB. 
 
Aby usunąć wszelkie wątpliwości co do tego, jaki region jest trafiony przez testy, Don&rsquo;T Włącz tabele globalne DynamoDB-W przeciwnym razie postępuj zgodnie z wdrożeniem AWSSync po Multi Region z tabelami globalnymi Amazon DynamoDB, jeśli chcesz włączyć dane międzyregionalne w czasie rzeczywistym i replikację subskrypcji. Testy w tym artykule zakładają, że posłużyłeś&rsquo;t Włączoną replikację.
 
 
 
Użyj Irlandii-Appsync.przykład.com, na przykład jako Irlandia&rsquo;s niestandardowa nazwa domeny;
 
Użyj Sydney-Appsync.przykład.com, na przykład jako Sydney&rsquo;s niestandardowa nazwa domeny;
 
Upewnij się, że kojarzysz interfejs API z niestandardową nazwą domeny.
 
 
Regiony [&bdquo;Irlandia&rdquo;] = < "Host": ".cloudfront.net" >; Regiony [&bdquo;Sydney&rdquo;] = < "Host": ".cloudfront.net" >;
 
 
 
Do celów testowych utwórz prostą funkcję autoryzatora Lambda dla interfejsów API GraphQL za pomocą następującego węzła.Przykładowy kod JS i wdrażaj go w obu regionach. Ta funkcja zaakceptuje ciąg &ldquo; Autoryzowany na zamówienie &rdquo; jako jedyny ważny token autoryzacji. Zwróć uwagę, że tokeny uporządkowane na twardo&rsquo;to dobra praktyka, a my&rsquo;Re Używając go tutaj tylko do prostoty testowej. Zamiast tego rozważ przechowywanie tokenów w menedżerze AWS Secrets Manager.
 
 
eksport.Handler = async (zdarzenie) => < const < authorizationToken >= zwrot zdarzenia < isAuthorized: authorizationToken === 'custom-authorized', resolverContext: <>>; >; 
 
 
 
Skonfiguruj funkcję autoryzatora Lambda jako domyślny autoryzator regionalnych punktów końcowych API AppSync (patrz tutaj) i usuń dowolne klucze API z konfiguracji AppSync. To sprawi, że interfejs API będzie dostępny z prostym tokenem podczas przeprowadzania testu, ułatwiając wykonanie testów. Jednak chyba że właśnie tego chcesz, zaleciliśmy spojrzenie na wszystkie dostępne opcje, aby zabezpieczyć interfejsy API AppSync.
 
Utwórz mutację w regionie Irlandii, aby dodać przykładowy rekord (więcej informacji można znaleźć w tej stronie): 
 
Przejdź do Irlandii&rsquo;S Console A AWS Appsync.
 
Przejdź do Irlandii&rsquo;S Appsync API, które utworzyłeś w poprzednim kroku.
 
Wybierz kartę zapytania po lewej stronie.
 
W polu tokena autoryzacji wpisz autoryzowany na zamówienie (jak w autoryzatorce Lambda).
 
Uruchom następujące polecenie mutacji: 
Mutacja CreateEvent < createEvent( name: "Ireland" when: "" where: "" description: "" ) < id name >>
 
 
Zakładając, że ty&rsquo;ve już skonfiguruj global-api.przykład.Przekierowania com za pomocą kroków z tego postu, a następnie to&rsquo;S It! Ty&rsquo;gotowy do przetestowania punktu końcowego Appsync Multi-Region Appsync.
 
Testowanie swoich aktywnych/aktywnych zapytań GraphQL z wieloma regionami
 
 
Zakładając, że ty&rsquo;VE już postępował zgodnie z niezbędnymi krokami w celu zbudowania od zera środowiska testowego Appsync z wieloma regionami, jak wyjaśniono w poprzedniej sekcji.
 
 
Na kliencie VPN skonfiguruj połączenie z serwerem VPN w pobliżu Irlandii (e.G., Londyn, Wielka Brytania).
 
Zapytaj interfejs API z poleceniem Curl podobnym do następujących, aby pokazać przykładowe dane, zastępując nazwę domeny własną i przekazując token autoryzacji dozwolony przez autoryzatora Lambda. 
$ curl -xpost -h "autoryzacja: autoryzowany na zamówienie" -d ' < "query": "query < listEvents < items < name >>> "> 'https: // global-api.przykład.com/graftql/
 
Potwierdź, że odpowiedź na curl jest 
< "data": < "listEvents": < "items": [ < "name": "Ireland" >] >>>
 
Na kliencie VPN skonfiguruj połączenie z serwerem VPN w pobliżu Sydney (e.G., Melbourne, Australia).
 
Uruchom ponownie polecenie curl - odpowiedź powinna być teraz 
< "data": < "listEvents": < "items": [ < "name": "Sydney" >] >>>
 
 
Jak widać, uruchamianie polecenia Curl z różnych lokalizacji na świecie powoduje, że odpowiedzi na inny punkt końcowy Appsync, chociaż ty&rsquo;ponownie trafienie w ten sam punkt końcowy API GraphQL Multi-Region GraphQL.
 
Testowanie subskrypcji Active/Active GraphQL z wieloma regionami
 
 
Aby przetestować subskrypcje GraphQL, wykonaj następujące kroki, aby je przetestować za pomocą WebSockets.
 
Ta sekcja zakłada również, że ty&rsquo;Postępowano już zgodnie z niezbędnymi krokami do zbudowania środowiska testowego AppSync z wieloma regionami od zera, jak wyjaśniono w poprzedniej sekcji.
 
Poniższe podejście testowe wykorzystuje Postman, aplikację, która umożliwia interakcję z interfejsami API za pomocą postów, get i wbud. Sekwencja kroków użytych w poniższym teście opiera się na instrukcjach budowy klienta WebSocket w czasie rzeczywistym dla AWS AppSync.
 
 
Utwórz ładunek uścisku dłoni, aby wysłać podczas otwierania połączenia WebSocket. Na narzędziu wiersza poleceń uruchom następujące polecenie, zastępując nazwę domeny własną i używając tokena zdefiniowanego w autoryzatorze Lambda. Rezultatem powinien być ciąg instalacji Base64-zapisz ten ciąg w notatniku, ponieważ ty&rsquo;Potrzebuję tego później dla listonosza&rsquo;konfiguracja s. 
$ echo '' | Base64
 
W Postman utwórz nowe połączenie WebSocket zgodnie z instrukcjami na tej stronie. Powinieneś być w stanie to zrobić, wybierając nowy przycisk, a następnie wybierając przycisk żądania WebSocket.
 
W polu adresu URL serwera wpisz następujący adres URL, upewniając się, że zastąpisz nazwę domeny: 
WSS: // global-api.przykład.com/ghantql/rzeczywistość
 
W sekcji Params dodaj następujące parametry: 
 
Klucz: ładunek, wartość: e30 = (to jest to samo co puste <>)
 
Klucz: nagłówek, wartość: (ciąg Base64, który utworzyłeś na pierwszym kroku)
 
 
 
Klucz: Sec-WebSocket-Protocol, wartość: Graphql-WS
 
 
 
Sprawdź, czy połączenie zostało ustanowione, szukając listonosza&rsquo;s połączona zielona etykieta w sekcji wiadomości i szukając połączonego z WSS: //. Wiadomość w tej samej sekcji.
 
 
< "id":"test", "payload": < "data": "", "extensions": < "authorization": < "Authorization":"", "host": "", > >>, &bdquo;type&rdquo;: &bdquo;start&rdquo;>
 
 
Subskrypcja < subscribeToEventComments(eventId: "Ireland") < content >>
 
 
 
Sprawdź, czy subskrypcja została pomyślnie utworzona, szukając komunikatu odpowiedzi Start_ack w Postman&rsquo;S Sekcja wiadomości. W przypadku powyższego komunikatu subskrypcji odpowiedź powinna być .
 
 
mutacja < commentOnEvent( content: "test-comment", createdAt: "2000-01-01", eventId: "Ireland" ) < commentId eventId createdAt content >>
 
 
Jak widać, mutacje wykonywane w regionie (e.G., Irlandia) wyzwala subskrypcje związane z tym regionem. Za pojedynczą mutację regionalną, aby uruchomić subskrypcje klientów we wszystkich regionach (e.G., Irlandia i Sydney), musisz skonfigurować replikację krzyżową z propagacją mutacji. Śledź Post Multi Region wdrażanie AWS AppSync z globalnymi tabelami Amazon DynamoDB, aby nauczyć się tego zrobić.
 
Budowanie aplikacji wzmacniającej w celu przetestowania interfejsu API GraphQL z wieloma regionami
 
 
Teraz, gdy ty&rsquo;Ponowne przekonanie, że Twój Active/Active GraphQL API działa zarówno na zapytania, jak i subskrypcje, możesz wykorzystać AWS wzmacnianie, aby utworzyć klienta testowego dla interfejsu API.
 
W tym artykule używamy Vue.JS z wzmacnianiem JavaScript w celu zbudowania prostej aplikacji klienckiej, ale wzmacniają biblioteki również obsługują iOS, Android i fluatter, zapewniając w ten sposób te same możliwości w tych różnych czasach pracy. Obsługiwani klienci wzmacniają zapewniają proste abstrakcje do interakcji z AppSync GraphQL API Backends z kilkoma wierszami kodu, w tym wbudowane możliwości WebSocket w pełni kompatybilne z protokołem AppSync WebSocket w czasie rzeczywistym poza pudełkiem.
 
Postępuj zgodnie z tą sekwencją kroku, aby zbudować aplikację testową.
 
 
Upewnij się, że masz węzeł.Zainstalowane JS - potrzebujesz go na następny krok.
 
Utwórz vue.JS wzmacnia aplikację w regionie Irlandii, uruchamiając te kroki.
 
Podłącz swoją aplikację do Irlandii&rsquo;S API. 
 
Uruchom następujące polecenie, aby powiązać aplikację z Irlandią&rsquo;s Appsync Endpoint, zastępując i: 
Amplify Add CodeGen --apiid --profile
 
Uruchom następujące polecenie, aby wygenerować powiązany kod zapytań i subskrypcji: 
wzmocnij CodeGen
 
 
 
Uruchom NPM Uruchom obsługę na narzędziu wiersza poleceń.
 
Sprawdź, czy istnieje&rsquo;t Wszelkie błędy.
 
Przejdź do http: // localhost: 8080/ - Powinieneś zobaczyć domyślny vue.Aplikacja JS.
 
 
ListEvents (Filter: $ Filter, Limit: $ Limit, NextToken: $ NextToken) < items < id name where when description comments < items < content commentId >>> NextToken>
 
 
   
 
 
 
Uruchom NPM Uruchom obsługę na narzędziu wiersza poleceń.
 
Sprawdź, czy istnieje&rsquo;t Wszelkie błędy.
 
Przejdź do http: // localhost: 8080/ - Powinieneś teraz zobaczyć wymienione wydarzenie Irlandii wcześniej utworzone w twoich testach, niezależnie od tego, gdzie na świecie ty&rsquo;ponownie uruchomić aplikację. To dlatego, że ty&rsquo;ponownie połączone bezpośrednio z Irlandią&rsquo;s regionalny punkt końcowy.
 
Przed następnym krokiem skopiuj wydarzenie w Irlandii&rsquo;S id do notatnika (jest to losowy 36-znak-lenght uuid).
 
 
mutacja < commentOnEvent( content: "test-comment", createdAt: "2000-01-01", eventId: "" ) < commentId eventId createdAt content >>
 
 
 
Zmodyfikuj src/AWS-Exports.plik JS, zmiana wartości parametru AWS_APPSYNC_GRAPHQLENDPOINT z Irlandii&rsquo;punkt końcowy API do twojego globalnego punktu wejścia (e.G., https: // global-api.przykład.com/ghantql).
 
Aplikacja powinna odświeżyć się automatycznie, wymieniając przedmiot Irlandii lub przedmiot Sydney, w zależności od tego, gdzie jesteś na świecie.
 
 
Testowanie aplikacji wzmacniającej w stosunku do interfejsu API GraphQL z wieloma regionami
 
 
Wykonaj następujące kroki, aby przetestować punkt końcowy API GraphQL GraphQL z aplikacją wzmacniającą.
 
 
Na kliencie VPN skonfiguruj połączenie z serwerem VPN w pobliżu Sydney (e.G., Melbourne, Australia).
 
Przejdź do aplikacji wzmacniającej w przeglądarce internetowej (e.G., http: // localhost: 8080). Powinieneś teraz zobaczyć listę wydarzenia w Sydney wcześniej utworzonym w twoich testach.
 
Uruchom polecenie mutacji, aby dodać komentarz w wydarzeniu w Sydney w taki sam sposób, jak dla Irlandii.
 
Sprawdź, czy nowy komentarz pojawił się automatycznie w Twojej aplikacji, tuż pod wydarzeniem w Sydney.
 
 
Jak widać, Twoja aplikacja płynnie trafia najbliższy punkt końcowy API AppSync, zarówno w przypadku zapytań, jak i subskrypcji, a jednocześnie podłączanie się do jednego globalnego punktu końcowego API.
 
Posprzątać
 
 
Aby oczyszczyć utworzoną infrastrukturę, usuń API AppSync, dystrybucję CloudFront, funkcję Lambda@Edge i rekordy Route53, które utworzyłeś dla tego testu.
 
Wniosek
 
 
W tym poście opisaliśmy, jak zmniejszyć opóźnienie użytkowników końcowych, jednocześnie zwiększając aplikację&rsquo;dostępność S, dostarczając punkty końcowe API w wielu regionach AWS.
 
Rozwiązanie wykorzystuje Cloudfront, Route 53 i ACM, aby obsługiwać Twój globalny interfejs API&rsquo;S Niestandardowa nazwa domeny i używa Lambda@Edge do przekazywania przychodzących żądań do najlepszego punktu końcowego API w oparciu o opóźnienie sieciowe do żądania.
 
Aby wyjaśnić rozwiązanie dla programistów API GraphQL, dostarczyliśmy dogłębnego przeglądu architektury referencyjnej, którą możesz pobrać jako pdf tutaj. Jeśli ty&rsquo;Ponowne programistę interfejsu API REST, a następnie możesz osiągnąć podobne wyniki, śledząc post za pomocą routingu opartego na opóźnieniu z Amazon Cloudfront dla aktywnej architektury aktywnej wielokrotności.
 
Aby uzyskać proste testy, nie zrobiliśmy&rsquo;T Włącz replikację danych międzyregionalnych. Jeśli ty&rsquo;D Lubię zbudować punkt końcowy Active/Active GraphQL z wieloma regionami z danych międzyregionalnych i replikacji subskrypcji, a następnie połączyć to, czego nauczyłeś się z tego artykułu wraz z postpotowaniem AWSSync AWS AWS z wieloma regionami z AWS.
 
Aaron Sempf
 
 
Aaron SEMPF to globalny główny architekt Solutions, w zespole Global Systems Integrators. Gdy nie pracuje z partnerami AWS GSI, można go znaleźć kodowanie prototypów dla autonomicznych robotów, urządzeń IoT i rozwiązań rozproszonych.
 
Fernando Ibanez
 
 
Fernando Ibanez jest architektem rozwiązań z Karoliny Północnej w zespole szkolnictwa wyższego. Fernando lubi pomagać klientom. W wolnym czasie Fernando lubi chodzić do teatru, próbować nowych kuchni i spędzać czas z rodziną.
 
Jorge Fonseca
 
 
Jorge jest architektem Solutions z ponad 20 latami, posiadającymi 2 stopnie główne i wszystkie certyfikaty AWS. W AWS pomaga klientom w ich podróży w chmurze, przekształcając złożone wyzwania w możliwe do działania mapy drogowe zarówno dla odbiorców technicznych, jak i biznesowych.
 
Ralph Richards
 
 
Ralph jest architektem rozwiązań w Amazon Web Services z siedzibą w Londynie. Współpracuje z klientami Enterprise Software i SaaS jako doradca techniczny, który pomaga im osiągnąć swoje cele biznesowe w chmurze. Jest także specjalizowany w technologiach kontenerowych, z zainteresowaniem budowaniem nowoczesnych zastosowań za pomocą podejścia mikrousług. Poza pracą lubi fotografować, czytać i odkrywać nowe miejsca na wycieczkach.
 
Доставляйте контент ыыстро, с низкой задержкой и исокой скоростюю передачичидачидиysta więc
 
 
Amazon CloudFront - это сервис сети доставки контента (cdn), созданый для ысокой производительности, бniej в.
 
 
 
Примеры исползования
 
 
Предо przykład
 
 
Ххатываййе зрителей по вем миру вечение милисекунд благодаря встрийном жжажананныхыхожожож Więc лений и шифрованию на уровне поля. 
 
Ускоряй John
 
 
ОRтимирирййййейnią доставку динамического веб-контента с помощнщнora гczka сннойннойннй сннойнноййнora сенойннноййнноййнora сеннойййнora сееной сет więc фраструктуры AWS, котоя подерживает периeliрийное завершение и Websockets. 
 
Потоковая передача видео режиме реального времени или по требованию
 
 
Оеративно запускайе потоковюю передач, восrostyons е устройство благодаря AWS Media Service и. 
 
Расространяйте исRPT
 
 
Аоматически масштаtoś й сети (OTA). 
 
Клиенты
 
 
 
Как начать работу
 
 
Знайте о принципах работы Amazon Cloudfront
 
 
Прочитайй руководсokój.
 
Начать работу с помощю практического чебого пособия
 
 
Знайте, как с помощю Amazon Cloudfront наладить доставку конта и искорить работу инaлforеззаааааа-łatra. 
 
ПRрробйте Cloudfront бесплатно
 
 
Начните разработку на aws же седня благодаря бMIrag 1 тind.
 
Подробне об AWS
 
 
Подробне об AWS
 
 
 
Что такоfe AWS?
 
Что такое о_NAчные ычислениwią?
 
Инклюзивность, многобраз %
 
Что такоfe DevOps?
 
Что такое контейнер?
 
Что такоfe ззеро данных?
 
Безасность оind AWS
 
Новые возожности
 
Блоги
 
Прессссрелизы
 
 
Ресур д!
 
 
 
Начало работы
 
ОNAнение и сертифияция
 
Биniejieniem решений AWS
 
Центр ахитектуры
 
ВRрросы и ответы по продуктам и техническим темамамамамамамамамT
 
Аналитические отчеты
 
Unkcje AWS
 
 
Разработчики на AWS
 
 
 
Центразрабочика
 
Пакеты sdk и инструентарий
 
.Net на AWS
 
Python на AWS
 
Java на AWS
 
Php на AWS
 
JavaScript на AWS
 
 
Подержка
 
 
 
Свяжитесь с нами
 
Полчение помощи сRециалиста
 
ОNAтиться в слжжбу подержки
 
Центр знаний
 
AWS Re: Post
 
Wsparcie оind AWS
 
Юридическая инфоация
 
Работа в AWS
 
 
Amazonka.com - работо więc. Ыы предо przykład представителям меншинств, женщинам, лицам с ораниченнныии вжожностямenia, веетевит !!! иenia вenia ветавиuła, ендерных груп п юбой сексуальной ориентации независо от их возраста.
 
 
Конфиденциальность
 
|
 
Условия ползования сайтом
 
|
 
Unkcje ciasteczka
 
|
 
© 2023 г. Amazon Web Services, Inc. и дочерние fot. Ве права защищены.
 
 
Ваш бразер устарел. Рекомендеем ыполнить перейти на друой совремный брааер для боле комфонной работы.
 
Прекращение подержки Internet Explorer
 
 
Подержка AWS для Explorer заканчивается 07/31/2022. Подерживаеые бразеры: Chrome, Firefox, Edge и Safari. Подроlit &raquo;