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. Co może być przyczyną i jak Pokemon Go odnosi się do problemu skalowalności ocenia Ireneusz Wiśniewski, Dyrektor Zarządzający w F5 Networks
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.
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.
- 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.
- 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.
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.
Ireneusz Wiśniewski, Dyrektor Zarządzający w F5 Networks
