W jaki sposób rozpowszechniasz swoją aplikację na wielu serwerach za pomocą EC2?

Question

Po raz pierwszy opracowuję aplikację, która wymaga sporo skalowania, nigdy wcześniej nie musiałem uruchamiać aplikacji na wielu wystąpieniach.

Jak to zwykle jest osiągane? Czy grupuję serwery SQL, a następnie odzwierciedlają programowanie na wszystkich serwerach i wykorzystuję równoważenie obciążenia?

Czy mogę oddzielić tę funkcjonalność, aby uruchomić niektóre na jednym serwerze na innym?

Również w jaki sposób mogę wypchnąć kod do wszystkich moich instancji okien EC2?

Answer 1

Zrzeczenie się - Nie będę wspominał o żadnych specyfikacjach Windows, ponieważ zawsze pracowałem na maszynach uniksowych. Te wytyczne są dość ogólne.

Jest to subiektywne pytanie i każdy będzie szykował własny system w unikalnym stylu. Oto kilka wskazówek, które podążam.

Jeśli jest to aplikacja internetowa, oddziel warstwy prezentacji (front-end), warstwy pośredniej (API) i warstwy bazy danych. Plasterkowana architektura skaluje się najlepiej w porównaniu do monolitycznej aplikacji.

1. Database - Amazon zapewnia doskonałe i wysoce dostępnych usług (chyba że jesteś na nas-wschodniej strefy dostępności) dla SQL i magazynów danych NoSQL. Możesz chcieć sprawdzić RDS dla Relacyjnych baz danych i DynamoDb dla NoSQL. Oba skalują się dobrze i nie musisz się martwić o zarządzanie i ładowanie shardingu/grupowania magazynów danych po ich uruchomieniu.
2. API oprogramowania warstwy pośredniej - To kluczowa część. Ważne jest, aby mieć zestaw interfejsów API (najlepiej REST, ale można tu w znacznym stopniu użyć czegokolwiek), które eksponują funkcjonalność back-end jako usługę. Architekturę zorientowaną na usługi można bardzo łatwo skalować, aby obsłużyć wiele klientów przednich, takich jak strony internetowe, urządzenia mobilne, komputery stacjonarne, widżety innych firm itp. Interfejsy API oprogramowania pośredniego zazwyczaj NIE powinny być miejscem, w którym przetwarzana jest logika biznesowa, większość z nich (lub wszystko to) powinno zostać przetłumaczone na zapytania/zapytania w bazie danych w celu zwiększenia wydajności. Te usługi mogą być równoważone obciążeniem dla wysokiej dostępności. Amazon's Elastic Load Balancers (ELB) są dobre na początek. Jeśli chcesz uzyskać więcej możliwości dostosowywania, takich jak blokowanie ruchu dla określonego zestawu adresów IP, wykonując Blue/Green deployments, to może powinieneś rozważyć ustawienie równoważników obciążenia HAProxy wdrożonych w oddzielnych instancjach.
3. Front-end - Tutaj powinna znajdować się twoja warstwa prezentacji. Powinien unikać jakichkolwiek bezpośrednich zapytań do bazy danych, z wyjątkiem tych, które są ograniczone do zakresu front-endu, np .: proste wywołanie Redis, aby uzyskać najnowsze klucze pamięci podręcznej dla fragmentów front-end. Tutaj można wykonać wiele operacji buforowania, od zgłoszeń serwisowych do fragmentów front-end. Możesz użyć AWS CloudFront do dostarczania zasobów statycznych i AWS ElastiCache dla swojego magazynu pamięci podręcznej. ElastiCache to nic innego jak zarządzany klaster z pamięcią. Powinieneś nawet rozważyć równoważenie obciążenia węzłów frontowych za ELB.

Wszystko to może zostać dołączone i wdrożone za pomocą funkcji AutoScaling za pomocą AWS Elastic Beanstalk. Obecnie obsługuje kontenery ASP .NET, PHP, Python, Java i Ruby. AWS Elastic Beanstalk nadal ma swoje własne ograniczenia, ale jest bardzo fajnym sposobem zarządzania infrastrukturą przy najmniejszym kłopocie z monitorowaniem, skalowaniem i równoważeniem obciążenia.

Wskazówka: Identyfikacja obszarów intensywnie korzystających z zapisu i odczytu aplikacji bardzo pomaga. Możesz wtedy odpowiednio pokroić swoją infrastrukturę i wykonać wymagane optymalizacje, jednocześnie koncentrując się na czytaniu lub pisaniu.

Podsumowując, Amazon AWS ma prawie wszystko, czego można użyć do stworzenia topologii serwera. Musisz wybrać komponenty.

Mam nadzieję, że to pomoże!

Answer 2

To będzie zależeć od wymagań, które masz. Ale jako ogólna wytyczna (zakładam, że strona internetowa) oddzieliłbym db, serwer WWW, serwer buforujący itd. Od różnych instancji i użyłbym s3 (+ cloudfont) dla zasobów statycznych. Upewniam się również, że istnieje pewne właściwe ograniczenie liczby tak, aby tylko uzasadnione obciążenie dotyczyło infrastruktury.

Dla serwera RDBMS mogę skonfigurować konfigurację db master-slave (RDS ułatwia to), użyć zagnieżdżenia db itp. Istnieją również rozwiązania klastra DB, które będą bardziej skomplikowane w konfiguracji, ale upraszczają dostęp do bazy danych dla programisty aplikacji. Chciałbym również sprawdzić wszystkie zapytania db i odpowiednie zapytania db/sql. W niektórych przypadkach czyste bazy danych typu NoSQL mogą być lepsze niż RDBMS lub połączenie obu, w których aplikacja przełącza się między nimi w zależności od wymaganych danych.

Dla serwera internetowego ustawiam loadbalancer, a następnie używam autoskalowania na instancjach serwera WWW za loadbalancerem. Coś podobnego będzie obowiązywać dla serwera aplikacji, jeśli taki istnieje. Będę również dostroić ustawienia serwerów internetowych.

Serwer buforowania zostanie również podzielony na jego klaster (-y) instancji. ElastiCache wydaje się miłą usługą. Redis ma porównywalną wydajność do memcache, ale ma więcej funkcji (jak listy, zestawy itp.), Które mogą się przydać podczas skalowania.

Answer 3

Sposób, w jaki bym to zrobił, to mieć 1 serwer jako serwer DB z uruchomionym na nim mysql. Wszystkie moje dane memcached, które mogą obejmować wiele serwerów i moich klientów z prostym "jeśli nie memcached, czytać z db, umieścić go na memcached i powrócić".

Memcached jest bardzo łatwy do skalowania w porównaniu do DB. Skalowanie bazy danych wymaga dużego wysiłku administracyjnego. To ból, który sprawia, że ​​wszystko działa prawidłowo. Więc wybieram memcached. Infact Mam dodatkowe serwery memcached, aby zarządzać przestojami (jeśli którekolwiek z moich memcached) serwerów.

Moje dane są w większości przeczytane, a kilka zapisanych. Kiedy piszę, pcham dane również do memcached. W sumie działa to lepiej dla mnie, kodu, administracyjnego, awaryjnego, awaryjnego, loadbalancingu. Wszyscy wygrywają. Trzeba tylko trochę "trochę" zakodować.

Tworzenie klastrów mysql jest bardziej kuszące, ponieważ wydaje się łatwiejsze do kodowania, wdrażania, utrzymywania i utrzymania. Pamiętaj, że mysql jest oparty na twardym dysku, a memcached jest oparty na pamięci, więc z natury jest znacznie szybszy (10 razy conajmniej). A ponieważ przejmuje on całe obciążenie odczytu z bazy danych, konfiguracja bazy danych może być NAPRAWDĘ prosta.

Naprawdę mam nadzieję, że ktoś wskaże na przeciwny argument, bardzo chciałbym to usłyszeć.