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

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!

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ć.

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ę.

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.

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.

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.

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

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.