Czy korzystanie z Cloud PaaS automatycznie rozwiąże problemy ze skalowalnością?

Question

W tej chwili szukam Cloud PaaS, który pozwoli mi skalować aplikację, aby obsłużyć wszystko od 1 użytkownika do 10 milionów + użytkowników ... Nigdy nie pracowałem nad niczym tak dużym i wielkim pytaniem, na które nie mogę Wydaje się, że dostaniesz jasną odpowiedź, że jeśli rozwiniesz, powiedzmy, standardową aplikację z relacyjną bazą danych i mydlanymi usługami sieciowymi, czy ta aplikacja skaluje się automatycznie po wdrożeniu w rozwiązaniu Paas, czy nadal musisz zbudować aplikację z nad, redundancja i wszystkie te rzeczy na myśli?

Załóżmy, że wdrażam aplikację Spring Hibernate do Amazon EC2 i tworzę pojedynczą instancję Ubuntu Server z zainstalowanym Tomcat, czy ta aplikacja skaluje się w nieskończoność, czy potrzebuję więcej instancji Ubuntu? Jeśli potrzebna jest więcej niż jedna instancja Ubuntu, czy Amazon zajmie się uruchomieniem aplikacji w obu instancjach, czy jest to odpowiedzialność dewelopera? A co z przechowywaniem bazy danych, czy mogę zainstalować bazę danych EC2, która będzie skalowad się w miarę wzrostu bazy danych, czy też będę musiał używać jednego z ich interfejsów API, jeśli chcę, aby była skalowana w nieskończoność?

CloudFoundry pozwala budować lokalnie i po prostu wdrażać bezpośrednio do swoich PaaS, ale ponieważ jest w wersji beta, istnieje limit ilości zasobów, których możesz użyć, a bazy danych są ograniczone do 128 MB, jeśli dobrze pamiętam, więc to nie -do teraz. Niektórzy sugerują instalację CloudFoundry na Amazon EC2, w jaki sposób skaluje się i jak traktuje się wtedy warstwę bazy danych?

GAE (Google App Engine), czy to pozwoli mi po prostu wdrożyć aplikację i nie martwić się o to, jak skaluje i wdraża redundancję? Wydaje się, że istnieją pewne ograniczenia, które można i nie można uruchomić na GAE, a ich wzrost cen bardzo zmartwił dość dużą liczbę programistów, czy to naprawdę jest tak drogie w porównaniu do innych dostawców?

W zasadzie, czy będzie skalować i co należy zrobić, aby skalować?

Answer 1

To wiele pytań na jeden wpis. W każdym razie:

1. Amazon EC2 nie skaluje się automatycznie z obciążeniem. EC2 to w zasadzie tylko wirtualna maszyna. Skalowanie instancji EC2 można uzyskać za pomocą Auto Scaling i Elastic Load Balancing.

2. Bazy danych SQL źle się skalują. Dlatego ludzie zaczęli używać baz danych NoSQL w pierwszej kolejności. Najlepiej sprawdzić, którą bazę danych dostawca usług w chmurze oferuje jako usługę zarządzaną: Datastore na GAE i DynamoDB na Amazon.

3. Zainstalowanie własnej bazy danych na instancjach EC2 jest bardzo niepraktyczne, ponieważ EC2 ma ephemeral storage (traci wszystkie dane na "dysku" przy ponownym uruchomieniu).

4. GAE Datastore to tak naprawdę jedna duża baza danych dla wszystkich działających na niej aplikacji. Jest więc dość skalowalny - twój milion użytkowników nie powinien być dla niego problemem. http://highscalability.com/blog/2011/1/11/google-megastore-3-billion-writes-and-20-billion-read-transa.html

5. Tak App Engine skaluje się automatycznie, zarówno instancji frontend i bazy danych. Nie ma nic specjalnego, co trzeba zrobić, aby skalować, wystarczy użyć ich API.

6. Istnieją ograniczenia co można zrobić z AppEngine:

   A. Brak lokalnej pamięci masowej (system plików) - trzeba korzystać z magazynu danych lub Blobstore.

   B.Kometa jest obsługiwana tylko za pośrednictwem zastrzeżonego kanału API

   C. Datastore to baza danych NoSQL: brak powiązań, ograniczone zapytania, ograniczone transakcje.

7. Koszt GAE nie jest zły. Robimy 1M wniosków dziennie za około 5 dolarów dziennie. Największe oszczędności wynikają z faktu, że nie potrzebujesz administratora systemu na GAE (ale potrzebujesz jednego dla EC2). W porównaniu z kosztami siły roboczej GAE jest niewiarygodnie tani.

Kilka wskazówek, aby zaoszczędzić pieniądze (przyspieszyć) GAE:

A. Zastosowanie dostać zamiast kwerendy w magazynie danych (wymaga starannie umacnianie klucze natiral).

B. Użyj memcache do buforowania danych, które otrzymałeś z magazynu danych. Można to zrobić automatycznie z Objectify i jest to @Cached annotation.

C. Denormalizuj dane. Oznacza to, że dane są redundantnie zapisywane w różnych miejscach, aby uzyskać dostęp do nich w jak najmniejszej liczbie operacji.

D. Jeśli masz dużo żądań REST z urządzeń, na których nie korzystasz z plików cookie, wyłącz wsparcie sesji (lub uruchom własne, tak jak robiliśmy). Sesje wykorzystują bazę danych pod maską i na każde żądanie, które dostaje i umieszcza.

E. Przeczytaj o adjusting app settings. Wypróbuj inne ustawienia (w zależności od tego, jak tolerancyjna jest Twoja aplikacja, aby zażądać opóźnienia i wzorce ruchu/skoki). Udało nam się zmniejszyć liczbę instancji frontend o 70%.