Jak skonfigurować globalne równoważenie obciążenia za pomocą Digital Ocean DNS i Nginx?

Rozwiązanie Robocze

Nadal planuję napisać to w formie samouczka, ale czasu jest mało, ponieważ udaję się do ostatniego sprintu, aby uruchomić moją aplikację na początku przyszłego roku, więc oto krótki zarys działającego sprzętu, który skończyłem z.

Przegląd

W końcu przeniosłem całe moje rozmieszczenie do AWS. Uwielbiam Digital Ocean, ale szczera rzeczywistość jest taka, że AWS jest o lata świetlne przed nimi (i wszystkimi, naprawdę), jeśli chodzi o usługi oferowane pod jednym dachem. Moje miesięczne wydatki nieznacznie wzrosły, ale gdy już skończyłem poprawiać i usprawniać, znalazłem rozwiązanie, które kosztuje około 75 USD / miesiąc na region dla najbardziej podstawowego wdrożenia(2 instancje za ELB). I Nowy region można rozwinąć i wdrożyć w ciągu około 30 minut.

Global Balancing

Szybko przekonałem się (dzięki odpowiedzi @Brad powyżej), że próba rozkręcenia własnej globalnej warstwy DNS balancing jest szalona. To było cholernie zabawne zastanawianie się, jak taka warstwa działa, ale bez wsiadania do samolotu i skrobania kostek instalując sprzęt wart miliony dolarów na całym świecie, nie było możliwe, aby toczyć moje własne.

Kiedy w końcu zorientowałem się, czego szukam, znalazłem mojego nowego najlepszego przyjaciela: AWS Route 53 . Oferuje solidną sieć DNS z około 50-nieparzystymi węzłami globalnie i możliwość wykonywania naprawdę fajnych sztuczek routingu, takich jak routing oparty na lokalizacji, routing oparty na opóźnieniach (co jest dość niesamowite) i AWS Alias rejestruje, że "automagicznie" przekierowuje ruch do innych usług AWS, których będziesz używać (jak ELB do równoważenia obciążenia).

I skończyło się na użyciu latency-based routing, który kieruje ruch globalny do najbliższego Regionalnego Elastic Load Balancer, który ma grupę automatycznego skalowania dołączoną do niego w danym regionie.

Zostawię ci zadanie domowe na innych dostawcach: www.f5.com, www.dyn.com, www.akamai.com, www.dnsmadeeasy.com. W zależności od twoich potrzeb, może być lepsze rozwiązanie dla ciebie, ale to działa bardzo dobrze dla mnie.

Dostarczanie Treści Sieć

Route 53 integruje się z AWS Cloudfront bardzo ładnie. Skonfigurowałem wiadro S3, którego używam do przechowywania wszystkich statycznych plików multimedialnych, które moi użytkownicy będą przesyłać, i skonfigurowałem dystrybucję Cloudfront do źródła z mojego wiadra S3 media.myapp.com. Są inni dostawcy CDN, więc zrób zakupy. Ale Cloudfront dostaje całkiem dobre recenzje i jest szybki do konfiguracji.

Równoważenie obciążenia i zakończenie SSL

Obecnie używam AWS Elastic Load Balancer do równoważenia obciążenia w instancjach aplikacji, które żyją w grupie Auto-skalowania . Żądanie jest najpierw odbierane przez ELB, w którym to momencie protokół SSL jest zakończony, a żądanie jest przekazywane do instancji w grupie automatycznego skalowania.

Uwaga: jedno wielkie zastrzeżenie dla ELB jest takie, że, jak na ironię, nie radzi sobie zbyt dobrze z masywnymi kolcami. Samo uruchomienie zdarzenia skalowania może potrwać do 15 minut, tworzenie 500 / timeouts w międzyczasie. Stały, stały wzrost ruchu jest podobno obsługiwany całkiem dobrze, ale jeśli zostaniesz uderzony kolcem, może cię zawieść. Jeśli wiesz, że zostaniesz trafiony, możesz "zadzwonić do przodu", a AWS rozgrzeje Ci ELB, co jest dość śmieszne i anty-wzorzec do istoty AWS, ale wyobrażam sobie, że albo nad tym pracują, albo ignorują, bo to nie jest tak duży problem. Zawsze możesz spin up your own HAProxy lub Nginx warstwa równoważąca obciążenie, jeśli ELB nie działa dla Ciebie.

Grupa Auto-Skalowania

Każdy region ma ASG, który jest zaprogramowany do skalowania, gdy obciążenie przechodzi określoną metrykę:

IF CPU > 90% FOR 5 MINUTES: SCALEUP
IF CPU < 70% FOR 5 MINUTES: SCALEDN

Konfiguracja dla GRUPA Auto-skalowania jest moim zdaniem trochę zawiła. W rzeczywistości jest to proces trzyetapowy:

1. Utwórz AMI skonfigurowane do swoich potrzeb.
2. Utwórz konfigurację startową, która używa AMI, które utworzyłeś.
3. Utwórz grupę automatycznego skalowania, która używa utworzonej konfiguracji uruchamiania, aby określić, jaki AMI i typ wystąpienia mają zostać uruchomione dla danego zdarzenia SCALEUP.

Aby obsłużyć konfigurację i wdrażanie aplikacji po uruchomieniu dowolnej instancji, należy użyć "User Data" pole do wprowadzania skryptu, który zostanie uruchomiony po uruchomieniu danej instancji. Jest to prawdopodobnie najgorsza nomenklatura w historii czasu. Jak" dane użytkownika " opisuje skrypt startowy tylko autor wie. Tak czy siak, to tam przyklejasz skrypt, który obsługuje wszystkie Twoje apt-get, mkdirs, klony git itp.

Instances & Internal Balancing

Ta konfiguracja maksymalizuje również wykorzystanie moich zasobów, eliminując każdą bezczynną infrastrukturę, jeśli warstwa aplikacji, którą hostuje, odbiera lekki ruch. To również eliminuje potrzebę posiadania i ELB/ASG combo dla każdej aplikacji, oszczędzając więcej gotówki.

Nie ma gotchas ani zastrzeżeń, które napotkałem przy użyciu tego rodzaju konfiguracji, ale jest jedna praca, która musi być na miejscu w odniesieniu do kontroli zdrowia (zobacz poniżej).

Kontrole Zdrowia

Jeśli przechodzisz trasę powyższej konfiguracji, pakując wszystkie aplikacje na jednym pudełku i uruchamiając wewnętrzny load-balancer, musisz utworzyć mała użyteczność do obsługi kontroli zdrowia ELB . To, co zrobiłem, to stworzenie dodatkowej aplikacji o nazwie ping.myapp.com. a potem skonfigurowałem ELB Health Checks, aby wysyłać wszelkie kontrole zdrowia do portu, na którym działa moja aplikacja ping, w ten sposób: {]}

Ping Protocol: HTTP
Ping Port:     XXXX
Ping Path:     /ping

To wysyła wszystkie kontrole zdrowia do mojego małego pomocnika ping, który z kolei uderza localhost:XXXX/ping we wszystkich aplikacjach znajdujących się na instancji. Jeśli wszystkie zwrócą odpowiedź 200, moja aplikacja ping zwróci odpowiedź 200 na ocenę stanu ELB i instancje mogą żyć przez kolejne 30 sekund.

Uwaga: nie używaj automatycznej kontroli stanu skalowania, jeśli używasz ELB. Skorzystaj z kontroli zdrowia ELB. To trochę mylące, myślałem, że to to samo, nie są. Masz możliwość włączenia jednego lub drugiego. Idź z ELB.

Warstwa Danych

Jedna rzecz, która jest rażąco nieobecna w mojej konfiguracji, to warstwa danych. Używam Compose.io jako Mój dostawca zarządzanej warstwy danych wdrażam na AWS, więc mam bardzo małe opóźnienie między warstwami aplikacji a warstwą danych. Przeprowadziłem wstępne dochodzenie w sprawie tego, w jaki sposób rozpowszechniłbym moją warstwę danych na całym świecie i odkryłem, że jest to bardzo złożone - i bardzo drogie - więc wykopałem to z mojej listy jako problem, który nie wymaga jeszcze rozwiązania. Najgorsze jest to, że uruchomię moją warstwę danych tylko w US-East i wzmocnię sprzęt. Nie jest to najgorsza rzecz na świecie, ponieważ moje API jest ściśle dane JSON na przewodzie, więc średnia odpowiedź jest stosunkowo niewielka. Ale widzę, że staje się to wąskim gardłem na bardzo dużą, globalną skalę-jeśli kiedykolwiek tam dotrę. Jeśli ktoś ma jakiś wkład w tę warstwę, chciałbym usłyszeć, co masz do powiedzenia.

Ta-Da!

Globalna Wysoka Dostępność W Budżecie Piwa. Zajęło mi tylko 6 miesięcy, żeby to rozgryźć.

Możesz użyć Anycast dla swojej usługi internetowej za darmo, jeśli korzystasz z bezpłatnego planu Cloudflare.

Digital Ocean obsługuje teraz Równoważenie Obciążenia samych serwerów. Jest niezwykle łatwy w konfiguracji i działa świetnie! Oszczędza konieczność dodawania niepotrzebnych komponentów, takich jak nginx (jeśli chcesz używać tylko do równoważenia obciążenia).

Mieliśmy problemy z przesyłaniem plików SSL za pomocą nginx na serwerze digital ocean, jednak od czasu aktualizacji Digital Ocean usunęliśmy nginx i teraz korzystamy z funkcji równoważenia obciążenia Digital Ocean i działa tak, jak tego potrzebujemy!