Sukces Pokémon Go, a waga odpowiedniej skalowalności usług

Sukces Pokémon Go, a waga odpowiedniej skalowalności usług Pixabay.com

Aplikacja Pokémon Go stała się nie tylko ogromnym sukcesem, ale także ogromnie frustrującym doświadczeniem dla wielu osób. Zwłaszcza dla rodziców podekscytowanych dzieci i nastolatków, chcących natychmiast wyjść i szukać aplikacyjnych stworków.

Niestety nie wszyscy mogli to uczynić, bo podczas tworzenia konta, aplikacja chwilowo się zawieszała, a następnie działała wolno z powodu przeciążenia serwera.

Szybko zareagował Werner Vogels, CTO Amazona, który zaproponował pomoc w rozwiązaniu problemów. Autorzy Pokémon Go stwierdzili, że „nie mogli od razu stworzyć aplikacji w chmurze”. A to okazuje się być powodem zaistniałych problemów. Zgodnie z informacjami podanymi na Wikipedii aplikacja przetwarza „ponad 200 milionów działań dziennie podczas interakcji z rzeczywistymi i wirtualnymi obiektami”. Wszelkie przestoje kwituje się frazą „problemy serwera”, ale wszyscy wiemy, że „serwer” to techniczny żargon na określenie „15 różnych komponentów aplikacji i infrastruktury sieciowej”.

Lekcją z tej sytuacji powinno być to, że chmura nie zawsze jest lepsza w radzeniu sobie z niespodziewanym sukcesem. Oczywiście może taką być, ale nie dlatego że jest chmurą samą w sobie, ale dlatego, że stanowi miejsce, gdzie usługa może zostać wyskalowana.

Firmy muszą być gotowe na sukces

Ciężko ocenić dlaczego Niantic Labs nie do końca poradził sobie z zapotrzebowaniem. Być może powodem były zbyt niska wydolność serwerów – w tej sytuacji chmura byłaby najlepszym wyborem. Drugim powodem mógłby być fakt, że aplikacja (lub infrastruktura) nie została zaprojektowana by się łatwo skalować – w tym wypadku umieszczenie aplikacji w chmurze by nie pomogło.

Ważne, by bazując na przykładzie Niantic Labs, inne organizacje były równie dobrze przygotowane na sukces, jak i na porażkę. I to nie na stopniowy, powolny wzrost, ale na natychmiastowy sukces, jaki obserwujemy w przypadku Pokémon Go.

Problemy ze źródłami danych

Jednym z problemów związanych ze skalowalnością są problemy ze źródłami danych. Długoletni użytkownicy Twittera z pewnością pamiętają wczesne lata social media, gdy dotykał ich problem słabej skalowalności baz danych. PayPal był jednym z najgłośniejszych rzeczników architektury Shard. Firma musiała poradzić sobie z ogromną liczbą użytkowników, a technika jaką zastosowali została uznana za uniwersalną, stosowaną w bazach danych, usługach i aplikacjach. Obecnie źródła danych NoSQL są uznawane za lepiej skalowalne niż tradycyjne bazy relacyjne.

Podobne artykuły:

Inne źródło problemów skalowalności ma swoje źródło w infrastrukturze. Autoskalowanie w chmurze nie polega na zdolności automatycznego zwiększania wydajności, ale na wzroście wydajności w punkcie styku aplikacji z użytkownikiem. Jakakolwiek architektura, która wymaga skalowalności w pewnym momencie spotka się z problemem równoważenia obciążenia. Oznacza to konieczność korzystania z API i skryptów, odpowiedniej automatyzacji i orkiestracji infrastruktury. Te komponenty powinny znaleźć się w infrastrukturze jeszcze przed tym, gdy będą potrzebne – w innym wypadku pojawią się opóźnienia wymagające z konieczności natychmiastowego zwiększenia wydajności.

Równoważenie obciążenia wspiera skalowalność

Korzystanie z usług równoważenia obciążenia w jakiejkolwiek architekturze aplikacyjnej powinno być wymogiem. Równoważenie obciążenia wspiera skalowalność – cechę konieczną do osiągnięcia sukcesu. Ale nie myślmy o równoważeniu obciążenia jedynie w szczątkowej formie. Ważne by pomyśleć o automatyzacji (skryptach) i orkiestracji (procesach), które pomogą w auto-skalowaniu popytu na aplikację. Ważne by przygotować architekturę zawczasu, by uprzedzić potencjalne przestoje.

Szczerze mówiąc Niantic Labs świetnie sobie poradził z zarządzaniem kryzysowym. Problemy z wydajnością były przedstawiane w formie zabawnych informacji. Były one łatwe do zrozumienia nawet przez dzieci. Być może jednak Niantic Labs nie byli przygotowani na tak duży sukces. Warto więc wdrożyć strategię skalowalności w proces budowania aplikacji.

F5 Networks Ireneusz Wiśniewski