Kiedy zacząć myśleć o skalowalności? [Zamknięte]

10

Mam zabawny, ale i straszny problem. Mam zamiar uruchomić nową aplikację (iPhone). To turowa gra wieloosobowa działająca na moim własnym zapleczu. Ale boję się uruchomić.

Z jakiegoś powodu myślę, że może stać się czymś dużym, a jego popularność zabije mój biedny samotny pojedynczy serwer + bazę danych MySQL.

Z jednej strony myślę, że jeśli rośnie, lepiej być przygotowanym i mieć już skalowalną infrastrukturę.

Z drugiej strony mam ochotę wydostać się na świat i zobaczyć, co się stanie.

Często czytam takie rzeczy jak „przedwczesna optymalizacja jest źródłem wszelkiego zła” lub ludzie mówią, że powinieneś po prostu zbudować swoją zabójczą grę z dostępnymi narzędziami i martwić się o inne rzeczy, takie jak skalowalność później.

Chciałbym usłyszeć kilka opinii na ten temat od ekspertów lub osób z tym doświadczeniem. Dzięki!

Rits
źródło
1
Wydaje się, każdy zdobywa pierwszą część tego cytat: „Musimy zapomnieć o małej wydajności, powiedzmy około 97% czasu” ... małe wydajności + 97%
Guy Sirton
Niech stanie się problemem, nie naprawiaj go, jeśli nie jest zepsuty. Widziałem dziesiątki projektów, w których ludzie byli zaniepokojeni problemami skalowalności. Zgadnij co się stało? Wiele projektów nigdy nie wychodziło z domu.
CodeART
„powiedz, że około 97% czasu” brzmi jak przedwczesna optymalizacja procesu optymalizacji. ;) </kidding>
Rob

Odpowiedzi:

22

To właściwie dość łatwy wybór.

W tej chwili masz zero użytkowników, a skalowalność nie stanowi problemu.

Najlepiej, jeśli chcesz dotrzeć do punktu, w którym masz miliony użytkowników, a skalowalność staje się problemem.

W tej chwili nie masz problemu ze skalowalnością; masz problem z liczbą użytkowników. Jeśli pracujesz nad problemem skalowalności, nie rozwiążesz problemu liczby użytkowników, co oznacza, że ​​rozwiązałeś problem, którego jeszcze nie masz, i nie rozwiążesz problemu, który masz. Najbardziej prawdopodobnym rezultatem jest to, że twój produkt nie da rady, a cała twoja praca będzie na nic.

Jeśli pracujesz nad problemem liczby użytkowników, rozwiążesz problem, który masz teraz, a następnie możesz skupić się na kolejnym problemie, którym może być skalowalność.

Zaletą problemów ze skalowalnością jest to, że z definicji posiadanie ich oznacza, że ​​biznes jest cholernie dobry, a to z kolei oznacza, że ​​możesz sobie pozwolić na wydawanie pieniędzy na optymalizację pod kątem skalowalności. Nie zejdziesz od zera do dziesięciu milionów z dnia na dzień, a jeśli będziesz mieć oko na wydajność systemu, będziesz miał mnóstwo czasu na optymalizację, kiedy nadejdzie czas.

Oczywiście pomaga pamiętać o skalowalności podczas pisania potrzebnego kodu, ale nie ma sensu spędzać dziesiątek, a nawet setek roboczogodzin na funkcji, o której nie wiesz, jeśli Będę go kiedykolwiek potrzebować, a najbardziej prawdopodobnym scenariuszem jest to, że nie będziesz. W tej chwili Twoim głównym zmartwieniem jest wysyłka. Co stanie się potem; cóż, możesz się tym później martwić.

tdammers
źródło
6

Nie ma powodu do optymalizacji, dopóki nie dowiesz się, że optymalizacja jest potrzebna. Skąd wiesz, że potrzebna jest optymalizacja? Ty mierzysz.

Zakładając, że twój serwer ma interfejs sieciowy, możesz symulować wielu użytkowników za pomocą narzędzi takich jak Apache JMeter . Dowiedz się, jak korzystać z tego narzędzia, a następnie rozpocznij testy warunków skrajnych swojego zaplecza. Powinieneś być w stanie nauczyć się wystarczająco dużo, aby wiedzieć, jakie są ograniczenia twojego systemu. Następnie możesz połączyć te informacje z liczbą posiadanych użytkowników i średnią liczbą działających jednocześnie, aby zdecydować, kiedy zwiększyć skalę.

Bryan Oakley
źródło
6

TL; DR Powinieneś pomyśleć o skalowalności przed napisaniem pierwszego wiersza kodu.

Najpierw pierwsze. Skalabilność! = Optymalizacja

Powinieneś pomyśleć o skalowalności przed napisaniem pierwszego wiersza kodu. Nie oznacza to, że zbudujesz ogromną infrastrukturę, gdy Twoja gra może być hitem. Myślenie o skalowalności oznacza:

  • Upewnienie się, że kod jest napisany, aby można go było skalować. Widziałem wiele projektów, w których nie zastanawiano się nad koniecznością skalowania. Wynikiem jest baza kodu, która nie będzie skalowana bez względu na sprzęt, który rzucisz na nią, lub jest nadmiernie kosztowna.
  • Wymyśl swoją strategię skalowania. Przygotuj plan obsługi wszystkich użytkowników. Masz bazę danych MySQL, czy chcesz ją oddzielić, klaster lub coś innego. Strategie takie jak sharding wymagają wcześniejszego rozważenia, ponieważ nakłada wymagania na architekturę. Grupowanie, mniej. Czy wspierasz sesje i jak będą reagować na wiele serwerów frontonu. Czy będziesz potrzebować lepkich sesji w module równoważenia obciążenia.
  • Opracuj strategię wdrażania. Czy zamierzasz używać AWS do skalowania? Czy potrafisz wykorzystać produkty lub usługi, które umożliwiają dynamiczne skalowanie od razu po wyjęciu z pudełka? Obejmuje to również zrozumienie kosztów.

ALE wygląda na to, że masz już bazę kodów. Pytanie brzmi teraz, kiedy rozpocząć skalowanie. Jest to całkowicie zależne od twojego kodu.

Jeśli twój kod nadaje się do skalowania , masz trudną część. Możesz założyć konto AWS, w razie potrzeby podkręcić serwery i gotowe.

Jeśli Twój kod nie skaluje się lub występują wąskie gardła, musisz wykonać pracę. Musisz zidentyfikować swoje wąskie gardła i je naprawić. „Kiedy” jest naprawdę trudne do poznania. Niektóre usługi plateau, niektóre stale rosną, a niektóre wybuchają. Decyzja, kiedy rzucić zasoby w coś takiego jak skalowanie, jest zwykle funkcją firmy i stanowi ocenę ryzyka.

Na twoim stanowisku mogę wydać wersję „beta” i zarządzać oczekiwaniami użytkowników. W ten sposób mogę wyciągnąć produkt i zobaczyć, jak się rozwija.

dietbuddha
źródło
5
To okropna rada. Przy zakładaniu nowego przedsiębiorstwa wystarczy pomyśleć o tym, że skalowalność powinna być ostatnim elementem. Najważniejsze musi być to, jak szybko uzyskać przydatne informacje zwrotne na temat tego, w jaki sposób to, co zbudowałeś, nie jest tym, czego potrzebujesz. Drugi powinien dotyczyć tego, jak nie malować się w kącie. Jednak w dzisiejszych czasach możesz z łatwością stworzyć prostą skalę strony internetowej opartą na bazie danych do milionów dynamicznych stron na godzinę (powinienem wiedzieć, że to zrobiłem). Martwienie się, że baza danych będzie wąskim gardłem przed pierwszym użytkownikiem, jest odwrócone.
btilly,
Próba stworzenia tego rodzaju przewidywania przyszłości praktycznie oznacza, że ​​każda zmienna w każdej klasie nie powinna być pojedynczą instancją, ale kolekcją. (MasterServer staje się MasterServerCollection, Viewport staje się ViewportCollection przechowywanym w ClientDevice, SceneGraph na serwerze staje się WorldInstanceCollection) ... z perspektywy czasu 20-20. Jeśli znasz potencjalne problemy na przyszłość, możesz upewnić się, że te zmiany są łatwe do wprowadzenia. Niektórzy z nich.
Katana314
1
Bardzo dobra uwaga. Pierwszy duży projekt kontraktowy, w który zostałem zaangażowany, z jakiegoś powodu myślałem o skalowalności, nawet jeśli nie było to wymagane. Dostarczono na czas i nie było problemu. Kilka lat później kolega zadzwonił do mnie, aby powiedzieć mi, jak niesamowite było, gdy poproszono ich o skalowanie systemu, a części, które stworzyłem, skalowały się tak łatwo! Ale to było lata później i tylko po to, by zaoferować mi komplement.
Raybarg
3

Są dwa razy, kiedy powinieneś pomyśleć o skalowalności.

Po pierwsze, należy delikatnie się zastanowić, zanim napiszesz jeden wiersz kodu. Ma to na celu upewnienie się, że nie wpiszesz się w dziurę skalowalności, i że Twój kod jest wyposażony w narzędzia umożliwiające uzyskanie potrzebnych pomiarów po raz drugi.

Drugi raz, aby rozważyć skalowalność, jest wystarczająco szybki, aby rzeczy stały się niedopuszczalnie powolne. Oznacza to, że musisz wiedzieć, co oznacza „zbyt wolno” i jak Twoja rzecz reaguje pod obciążeniem. Jeśli masz usługę, której sterownik (prawdopodobnie qps) zwiększa się o N% miesięcznie, masz raczej inny czas niż „95% zużywanych zasobów maszynowych”, jeśli zużycie zasobów jest proporcjonalne do obciążenia lub liniowe.

W grze turowej powinieneś mieć przyzwoity margines bezpieczeństwa (prawdopodobnie nie masz jednego świata gry, a jeśli to zrobisz, prawdopodobnie jest to wewnętrzna geometria, co oznacza, że ​​nie wszyscy mają interakcje ze wszystkimi) kolei „problemy).

Nie znając szczegółów, poświęciłbym jeden lub dwa dni na zastanowienie się, gdzie masz problemy ze skalowaniem i jakie masz możliwe strategie ich rozwiązania. Ale to ważne, pomyśl o tym. Nie rób, tylko pomyśl (i udokumentuj). Jeśli nie masz problemów ze skalowalnością, które zaczynają się pojawiać u kilkuset użytkowników, powinieneś mieć czas na sprawdzenie obciążenia i zwiększenie zasobów zaplecza.

Vatine
źródło
2

Z twojego opisu wygląda na to, że istnieją dwa możliwe wyniki:

  • Gra kończy się niepowodzeniem, a ciebie to nie obchodzi.
  • Gra kończy się sukcesem, a wtedy twój backend nie będzie w stanie poradzić sobie z obciążeniem, a wynikiem będzie porażka.

Hmmm.

Oto kilka pytań, które możesz sobie zadać:

  • Ilu użytkowników może obsłużyć obecny backend przy akceptowalnej wydajności?
  • Czy masz jakiś plan ograniczenia wpływu na obecnych użytkowników, jeśli widzisz jakiś szybki wzrost (np. Tymczasowo ściągnij grę ze sklepu z aplikacjami)
  • Jak szybko możesz wymyślić lepszy backend, jeśli odniesiesz sukces?
  • Jakie są konsekwencje biznesowe oczekiwania. Czy możesz się wyżywić? Jakie są zagrożenia?
  • Jakie są konsekwencje biznesowe wydania tej wersji, biorąc pod uwagę odpowiedzi na powyższe pytanie.

Odpowiedź na twoje pytanie powinna stać się oczywista, gdy się je rozważy. Żaden ekspert nie powie Ci, co robić bez dodatkowych informacji, ponieważ każdy system jest inny, a każda firma jest inna.

Guy Sirton
źródło
1

Twój serwer będzie używany interaktywnie przez użytkowników. Oznacza to, że opóźnienia mają bardzo duży wpływ na wrażenia użytkownika. Złe opóźnienie zawsze powoduje złe wrażenia użytkownika.

Przynajmniej wykonaj testy obciążenia ad hoc zgodnie z opisem Bryana.


Bardziej poważne podejście

Przeprowadź kilka symulacji i dowiedz się, jakie opóźnienie ma wpływ na wrażenia użytkownika (przy użyciu symulacji opóźnienia sieci lub po prostu uśpienia () w aplikacji). Dowiedz się, przy jakim opóźnieniu robi się zauważalne, denerwujące i staje się bezużyteczne.

Potem jest pierwszy krok w kierunku optymalizacji. Wybierz SLA dla swojego serwera: np. W najgorszym przypadku 10% połączeń z irytującym opóźnieniem i 1% połączeń z nieużytecznym opóźnieniem. Przy tych limitach możesz użyć testu obciążenia, aby dowiedzieć się, ilu użytkowników może obsługiwać Twój serwer.

Czyste testowanie przepustowości bez mierzenia opóźnienia (lub przynajmniej ręczne używanie serwera podczas testu obciążenia) nie jest tak przydatne, ponieważ nie mówi, czy zmierzone liczby przepustowości powodują znośne wrażenia użytkownika.

Bardzo miła prezentacja Gil'a Tene na temat pomiaru opóźnień: http://www.infoq.com/presentations/latency-pitfalls

Patrick
źródło
1

Na etapie wymagań biznesowych, który jest następnie wykorzystywany do ustalenia wspólnego zrozumienia dla wydajności wszystkich elementów niższego szczebla, takich jak architektura, operacje, rozwój, kontrola jakości i monitorowanie w prod. Jeśli nie ustalisz wspólnego zrozumienia tego, co jest wymagane z góry, wówczas każda z części organizacji będzie przyjmować założenia dotyczące wydajności (lub w ogóle o nich nie myśleć) podczas angażowania się w określone zadania w całym cyklu życia podanie. Jest to prawdą, niezależnie od tego, czy jesteś zaangażowany w wodospad, krótki wodospad, zwinny, czy cokolwiek w tej chwili metodologia rozwoju jest gorąca na liście słów kluczowych wznowienia.

Wydajność i skalowalność jest trudna. Funkcjonalność jest łatwa. Zły kod skalowania będzie się powiększał, aby wypełnić dowolną pulę zasobów, którą do niego dostarczysz, więc przesunięcie bańki kosztowej poprzez zakup większego sprzętu zabierze Cię do tej pory, zanim będziesz musiał naprawić nieefektywny kod lub kupić coraz więcej sprzętu. Pozostawienie tego jako priorytetowego jest również bardzo kosztowne. Istnieją decyzje dotyczące architektury i projektowania, które są podejmowane na wczesnym etapie cyklu życia aplikacji, które mogą wymagać całkowitego odwrócenia, aby spełnić późne wymagania dotyczące wydajności - Pomyśl o producentach samochodów sportowych o wysokich osiągach, którzy będą musieli przejść z aluminium na włókno węglowe na późnym etapie cyklu projektowania, aby osiągnąć stosunek mocy do masy związany z wydajnością i tym, jak wpływa to na oprzyrządowanie, szkolenie, budowę samochodu itp.

Zapytaj architektów, programistów i osoby obsługujące Twoją organizację o wymagania dotyczące wydajności aplikacji. Jeśli nie zostaną one przechwycone z firmy, nie zdziw się, jeśli otrzymasz różne odpowiedzi (lub brak odpowiedzi) od różnych osób, nawet w tej samej grupie. Te „założenia” zawsze wracają, by uprościć organizację we wdrożeniu.

James Pulley
źródło
„Zapytaj architektów, programistów i osoby obsługujące Twoją organizację ...” - Nic w pytaniu nie wskazuje, że jest to organizacja, to tylko poboczny projekt tego faceta.
Graham