Realia uruchamiania apki produkcyjnej Node app na AWS ELB
Zanim przejdziemy do sedna, bądźmy szczerzy - kalkulator cen AWS jest mylący. Częściowo wynika to z oferowanej przez AWS metody płatności a la carte. To sprawia, że uzyskanie dobrej wyceny przez klienta jest trudne. Mam nadzieję, że ten artykuł rzuci trochę światła na faktyczne koszty uruchomienia aplikacji, jak również kilka sposobów na ich zmniejszenie.
Rzeczywisty koszt uruchomienia aplikacji
Zarządzam aplikacją internetową dla Node w ELB od około dwóch lat. Pierwszy rok był świetny, Amazon dawał nam (prawie) wszystko za darmo! Potem trzeba było zacząć płacić za rzeczy, takie jak instancje EC2.
W tym artykule skupię się na wymaganiach dotyczących mojej konkretnej aplikacji, która jest aplikacją Express opartą na Node, hostowaną na Elastic Beanstalk.
Po szczegółowe informacje na temat budowy, rzuć okiem na mój poprzedni artykuł tutaj.
Podział
Oto, co obecnie uruchamiam w AWS:
Pojedyncze środowisko EBS (region zachodni USA):
- 1 Classic Load Balancer
- 1 instancja t2.micro EC2
- Bucket S3, w którym znajdują się obrazki (7 GB w momencie pisania tego artykułu).
- 1 Hosted Zone w Route 53
18 USD (za Load Balancer) + 5 USD (za EC2 z RI) + 0,50 USD (za Route 53) + 0,17 USD (za S3) + 0,21 USD (transfer danych) = mniej więcej 25 USD miesięcznie.
Dodatkowo, hostuje MongoDB gdzie indziej, więc jeśli planujesz hosting DB na AWS, zapłacisz więcej. Podzielmy różne koszty.
Load Balancer
Jest to najdroższa część stosu. Kosztuje:
- 0,025 USD za klasyczną godzinę pracy (lub częściową godzinę)
- 0,008 USD za GB danych przetwarzanych przez Classic Load Balancer.
Oznacza to, że jeśli aplikacja pracuje 24 godziny na dobę, będzie Cię to kosztować około $18 + opłaty za transfer danych, co miesiąc.
Instancja EC2
Instancje EC2 na żądanie są droższe niż powinny. Aby zaoszczędzić trochę pieniędzy, zapoznaj się z sekcją dotyczącą Zarezerwowanych instancji EC2. Jeśli się nad tym zastanawiasz to uruchomienie tego samego typu instancji EC2, jak powyżej, na żądanie, kosztowałoby cię 8,40$.
S3
Mam kilka bucketów S3. Jeden dla mojej statycznej strony głównej, jeden do przechowywania obrazów i jeden do przechowywania wersji aplikacji. O ile wiem, ELB automatycznie tworzy bucket, który służy do zarządzania wersjami aplikacji.
S3 jest dość tani, więc nie jestem zbytnio zaniepokojony płaceniem za niego, ale są sposoby, aby zaoszczędzić pieniądze za pośrednictwem ich systemu Glacier.
Baza danych
Hostuje MongoDB DB w mLab, który wkrótce kończy działalność. Zaktualizuję ten tekst gdy będę zmuszony przenieść się do Atlasu Mongo i kiedy ustale, ile to będzie kosztować.
Zarezerwowane instancje EC2
Porozmawiajmy o instancjach zastrzeżonych (RI). Skomplikowany system rozliczeniowy Amazon jest najbardziej mylącą częścią zarządzania czymkolwiek w AWS. Instancje zastrzeżone mogą zmniejszyć część kosztów, ale są również bardzo skomplikowane.
Po wielu lekturach i rozmowach z działem obsługi klienta AWS, oto, do jakich doszedłem wniosków.
Po pierwsze, istnieją dwa różne sposoby rezerwowania miejsca, w którym znajduje się RI: Strefa regionalna i strefa dostępności. Regionalne oznacza, że jest on specyficzny dla jednego z głównych regionów, np. US-West-2 (Oregon). Strefa dostępności (AZ) jest specyficzna dla strefy w obrębie tego regionu, np. us-west-2a (Oregon).
Kupiłem RI wewnątrz US-West-2 i zostało to automatycznie zastosowane do mojej instancji działającej w tym obszarze. Jeśli kupisz jedną z nich w ramach jednej strefy dostępności, będzie ona miała zastosowanie tylko do konkretnej AZ, np. US-West-2a, więc jeśli ELB podniesie instancję EC2 w US-West-2b, to masz problem.
Dodatkowo istnieją "standardowe" i "zamienne" typy RI. Nie jestem w 100% pewny, co to znaczy, ale z tego, co rozumiem, zamienne są bardziej elastyczne w kwestii tego, na co można je zamienić, ale są droższe.
Ostatecznie, istnieją trzy rodzaje płatności: Nie z góry, częściowo z góry, całkowicie z góry. Jest to dość proste, płacisz nic, część lub całość, gdy rezerwujesz instancję. Nie widzę w żadnej z nich jakiejś specjalnej korzyści. Jednakże, jako nowy użytkownik, najprawdopodobniej nie masz możliwości zapłacenia z góry.
Według wsparcia klienta AWS:
Żadne podane z góry zarezerwowane instancje (RI) nie mogą stwarzać znacznego ryzyka związanego z fakturowaniem nowych rachunków, ponieważ są one umownym zobowiązaniem do comiesięcznej zapłaty za cały okres RI. Z tego powodu, nowe konta i mało używane konta nie są w stanie zapisać się do No Upfront RIs, dopóki nie powstanie prawidłowa historia rozliczeń.
Możesz natknąć się na ten błąd, jeśli spróbujesz kupić "no up-front".
Błąd: Obecna kwota nie pozwala na zakup wymaganej liczby zarezerwowanych instancji ((Service: Amazon EC2; Status Code: 400; Error Code: ReservedInstancesLimitExceeded;)
Zastrzeżenie: Z jakiegokolwiek powodu, zarezerwowana instancja potrzebuję trochę czasu, aby się “odpalić”, co oznacza, że pierwszy dzień miesiąca zawsze będzie kosztował więcej. Nie jestem pewien, dlaczego tak jest, ale jeśli się dowiem, zaktualizuję to. Rzuć okiem na wykres poniżej:
Bolesne punkty
Istnieją pewne drobne skargi dotyczące całego EBS, które pomyślałem, że dołączę do mojego artykułu jako dodatek, na wypadek, gdybyś był ciekawy.
Automatyczne aktualizacje nie są tak naprawdę automatyczne
Node nie jest kompatybilny między wersjami.
Zobacz poniżej jak zmieniam wersje Linuksa, gdy Node nie działa.
Uruchamianie więcej niż jednego środowiska
Posiadanie środowiska deweloperskiego i jednocześnie uruchomionej produkcji jest łatwe, ale kosztowne. Koszta są tak naprawdę wręcz podwojone. Dlatego zazwyczaj demontuje swoje środowisko dev, jak tylko z nim skończę.
Dokumentacja jest przerażająca
AWS-owi nie służy, że jest tak duży.. To jeden z powodów dla których piszę ten artykuł. Naprawdę ciężko było znaleźć odpowiedzi na moje konkretne potrzeby.
Jak zarządzać aktualizacjami?
Mam dwie oddzielne instancje mojego repo git zainstalowane na moim laptopie. Jedna dla Deva, a druga dla produkcji.
Używam środowiska dev do, no cóż, rozwoju! Bez owijania w bawełnę. Używam folderu produkcyjnego wyłącznie w celu pobierania aktualizacji z głównej gałęzi Git, uruchamiania konfiguracji mojego webpacka i wgrywania na serwer produkcyjny.
Powodem, dla którego są one odrębne, jest to, że mogę utrzymywać oddzielne konfiguracje elastic beanstalk i nie muszę się martwić o wgranie kodu w niewłaściwe miejsce.
Aktualizacje nie wymagające zmian w środowisku Linuksa
W przypadku aktualizacji niewymagających żadnych zmian w środowisku linuksowym, jest to tak proste jak uruchomienie eb deploy w terminalu. To niesamowite i trwa jedynie około 10 minut.
Aktualizacje wymagające zmiany środowiska Linuksa
Czasami będziesz chciał zaktualizować środowisko Linuksa, ale nie będziesz mógł tego zrobić, ponieważ AWS jest szalenie głupie (jestem pewien, że jest ku temu powód) i zezwala tylko na niektóre wersje Node na każdej kompilacji Linuksa. Przez to, jest to trochę bardziej skomplikowane, ale wciąż możliwe do opanowania.
- Zrób i pchnij nową konfigurację produkcyjną do nowego środowiska. Gdy robiłem to ostatnio, po prostu stworzyłem nową instancję za pośrednictwem eb create prod-1 . Ta funkcja zrobi to co trzeba i wgra Twoją aplikację do nowego środowiska.
- Upewnij się, że wszystkie aktualizacje działają. Mogło by się to wydawać dość oczywiste, ale to dobry moment, aby upewnić się, że w buildzie nie było żadnych czkawek.
- Upewnij się, że Twoje zmienne środowiskowe są prawidłowo ustawione. W pewnym sensie zahacza to o poprzedni punkt, jednak upewnij się przynajmniej że korzystasz z prawidłowej bazy danych.
- Upewnij się, że Twój load balancer ma ten sam certyfikat SSL. Śmieszna sprawa, wyobraź sobie że jeśli spróbujesz uzyskać dostęp do instancji ELB w https bez certyfikatu, nie uda ci się to!
- Zamień instancje. W końcu, jeśli wszystko wygląda jakby było gotowe do działania, w konsoli znajduje się przycisk do zamiany url instancji. ŁATWIZNA. Nie musisz nic zmieniać w Route 53, samo się zmienia dla ciebie.
Proszę bardzo. Oto, jak zarządzać aktualizacjami. Nie jest to trudne. Wesołego kodowania!
Oryginalny tekst w języku angielskim przeczytasz tutaj.
