Studium przypadku: Hathora oszczędza miliony, łącząc chmurę z serwerami fizycznymi

Discover how to deliver better software and systems in rapidly scaling environments. Join our Community

Początkowo Hathora polegała wyłącznie na infrastrukturze chmurowej AWS, aby skalować swoją platformę do gier wieloosobowych, jednak wysokie koszty zagroziły jej największemu segmentowi klientów. Przechodząc na model hybrydowy, wykorzystujący serwery fizyczne i strategiczne zastosowanie chmury, Hathora znacznie obniżyła wydatki, poprawiła wydajność i odblokowała ogromne możliwości globalnego skalowania.

Why Hathora Made a Big Bet on Bare Metal

Key Takeaways

Wielkie ambicje spotykają się z realiami chmury: Hathora dążyła do szybkiego rozwoju, polegając na infrastrukturze chmurowej i hostując rozwiązanie w AWS z wykorzystaniem Kubernetes, obsługując twórców gier — od małych zespołów po ogromne studia.

Rynek gier MMO: plac zabaw wart miliardy dolarów: Przewiduje się, że rynek gier MMO powiększy się do 2029 roku o niemal 30 miliardów dolarów, stwarzając zarówno ogromne możliwości, jak i poważne wyzwania infrastrukturalne dla firm takich jak Hathora.

Sukces i przeciążenie: zbyt wiele, zbyt szybko: Platforma Hathora szybko zyskała ponad 100 studiów, jednak wymagania większych klientów ujawniły ograniczenia i wysokie koszty podejścia opartego wyłącznie na chmurze.

Ponowna ocena strategii: nauka na trudnych doświadczeniach: Zdając sobie sprawę z niedoskonałości swojej infrastruktury, zespół Hathora ponownie przeanalizował plan biznesowy, aby znaleźć zrównoważone sposoby obsługi dużych studiów tworzących gry i czerpania z tego zysków.

Wnioski dla liderów technologicznych: dostosowanie do skali: Doświadczenia Hathora są dla liderów technologicznych lekcją na temat znaczenia skalowalności infrastruktury oraz równoważenia kosztów chmury ze strategiami rozwoju.

Czasami ta sama infrastruktura, która pomaga osiągnąć udany start, ostatecznie staje się przeszkodą, gdy firma zaczyna błyskawicznie się rozwijać.

W przypadku Hathora było to zarówno dosłownie prawdą, jak i odrobinę ironiczne: firma zajmuje się dostarczaniem krytycznej infrastruktury oraz orkiestracją serwerów dla studiów gier wideo, aby mogły hostować i skalować swoje wieloosobowe gry online.

Według większości miar jest to ogromny rynek. Na przykład firma badawcza Technavio prognozowała, że rynek gier MMO (masowe gry wieloosobowe online) wzrośnie o prawie 30 miliardów dolarów w latach 2025–2029. Inni analitycy prognozują podobny wzrost w ciągu mniej więcej najbliższych pięciu lat.

Hathora chciała szybko uruchomić i skalować swoją platformę, dlatego zastosowała podejście, które stało się powszechnym schematem działania wielu startupów, małych zespołów i innych firm: całkowicie postawiła na chmurę, uruchamiając wszystko w Amazon Web Services z wykorzystaniem EKS, czyli w pełni zarządzanej usługi Kubernetes giganta chmurowego. Jej ambicje wydawały się nieograniczone: Hathora chciała obsługiwać twórców gier każdej wielkości — od najmniejszych zespołów po największe studia i wszystkich pomiędzy nimi

I działało to — do pewnego momentu. W ciągu sześciu miesięcy od początkowego uruchomienia platformę Hathora przyjęło ponad 100 studiów gier. Ten początkowy sukces ujawnił fundamentalny problem związany z celem Hathora, jakim była obsługa studiów gier każdej wielkości i z całego świata: gdy firma zaczęła współpracować z coraz większymi studiami, ekonomika jej infrastruktury opartej wyłącznie na chmurze szybko stała się nie do utrzymania — do tego stopnia, że groziło jej utracenie dużego i dochodowego segmentu całego rynku.

W tym studium przypadku przyjrzymy się z pierwszej ręki temu, jak dyrektor ds. technologii Hathora i jego zespół przekształcili początkową strategię biznesową i technologiczną firmy, osiągając potencjalnie spektakularne rezultaty — a także omówimy kilka wniosków dla innych liderów technologicznych z dowolnej branży.

Firma i dyrektor ds. technologii

Firma: Hathora, globalny dostawca krytycznej infrastruktury i orkiestracji serwerów dla studiów gier wideo, umożliwiający im hostowanie wieloosobowych gier online.

Dyrektor ds. technologii: Harsh Pandey, który jest również założycielem firmy:

„Zbudowaliśmy Hathora, aby zapewnić studiom gier każdej wielkości dostęp do infrastruktury o globalnej skali bez konieczności samodzielnego jej tworzenia. Kiedy jednak zaczęliśmy wyliczać koszty dla większych studiów, ekonomika przedsięwzięcia przestała się zgadzać. Koszty chmury, zwłaszcza transferu danych wychodzących, sprawiły, że nasza oferta stała się nie do utrzymania właśnie dla klientów, których chcieliśmy obsługiwać.”

Siedziba: Nowy Jork

Zasięg klientów: Obecnie Hathora obsługuje klientów (dosłownie) na całym świecie, korzystając z 14 globalnych regionów rozmieszczonych na sześciu kontynentach.

Problem biznesowy

Wielkie ambicje zwykle wiążą się z wielkimi wyzwaniami i dokładnie tak było w przypadku Harsha i Hathora.

Część z tych wyzwań wynika z samej natury branży gier: gry MMO nie są małymi, rodzinnymi sklepami o przewidywalnych wzorcach ruchu. Gry wieloosobowe muszą natomiast jednocześnie dostarczać stałe aktualizacje każdemu pojedynczemu połączonemu graczowi, zachowując wysoką wydajność.

Oznacza to ogromne ilości danych regularnie przesyłanych tam i z powrotem między infrastrukturą zaplecza a poszczególnymi graczami, których w przypadku większych gier mogą być miliony. A jeśli uważasz, że Twoi klienci są wymagający, cóż, powiedzmy tylko, że poważni gracze niekoniecznie należą do cierpliwych, jeśli chodzi o wydajność gry i doświadczenia użytkownika.

Uruchamianie obciążeń serwerów gier na platformie Hathora opartej wyłącznie na chmurze sprawdzało się dobrze w przypadku mniejszych studiów. Kiedy jednak większe studio zwróciło się do firmy z pytaniem o ceny, Harsh i zespół zdali sobie sprawę z ograniczeń modelu finansowego.

„Wiedzieliśmy, że musimy rozwiązać problem, gdy duże studio gier korzystające z naszej platformy hostingu serwerów gier do wewnętrznych testów rozgrywki zapytało o ceny na potrzeby premiery” — powiedział nam Harsh. „Przewidywany rachunek za przepustowość wyniósł ponad milion dolarów miesięcznie.”

Według Harsha było to czterokrotnie więcej niż normalnie oczekiwane koszty obliczeniowe uruchomienia gry. Nie było to możliwe do utrzymania ani dla studia, ani dla Hathora. Hathora znalazła się tym samym na przysłowiowym rozdrożu: pozostać przy pierwotnej strategii opartej wyłącznie na chmurze, ryzykując utratę segmentu dużych studiów, albo wprowadzić zmianę.

„Problem, który należało rozwiązać, dotyczył cen — mówiąc wprost” — mówi Harsh.

Rozwiązanie było jednak techniczne: Hathora musiała przekształcić własną infrastrukturę, aby lepiej sprostać wyjątkowym wymaganiom obciążeń serwerów gier, a jednocześnie przyjąć model cenowy, który mogłyby z łatwością zaakceptować nawet największe studia.

Co zrobili i dlaczego

Specjaliści techniczni wszelkiego rodzaju słyszeli mnóstwo prezentacji na temat korzyści z przenoszenia infrastruktury i obciążeń do chmury lub po prostu uruchamiania działalności wyłącznie w chmurze. Od lat jest to jeden z głównych trendów, a Hathora nie stanowiła wyjątku.

Hathora obrała niemal przeciwny kierunek, aby rozwiązać problem związany z dużymi klientami, przyjmując architekturę chmury hybrydowej i ostatecznie stawiając na sprawdzone od lat rozwiązanie: serwery fizyczne. 

(Przeczytaj nasz artykuł o tym nowszym trendzie, czyli odchodzeniu ze środowisk chmurowych na rzecz infrastruktury lokalnej.)

Harsh opowiada o ewolucji firmy:

„Przeszliśmy na model hybrydowy i śledziliśmy koszt infrastruktury przypadający na jednoczesną sesję, opóźnienia w różnych regionach świata oraz nakład pracy inżynierskiej potrzebny do obsługi całości. Przenosząc 80% naszych obciążeń na serwery fizyczne, możemy obniżyć koszty obliczeniowe niemal o połowę i zmniejszyć koszty przepustowości o ponad 90%. Obecnie zarządzamy ponad 30 000 rdzeniami w 14 regionach przy stosunkowo niewielkim zespole inżynierskim. Taki poziom wydajności i zasięgu byłby niemożliwy w naszej pierwotnej architekturze.”

Nadal wykorzystują infrastrukturę chmurową na potrzeby skalowalności i obsługi nagłych wzrostów zapotrzebowania, która odpowiada za około 20% obciążeń (zamiast 100%). Obecnie jednak stos Hathory opiera się na zasobach dwóch dostawców serwerów fizycznych oraz chmur AWS i GCP, zamiast utrzymywać wszystko w AWS. Harsh i jego zespół wybrali Talos Linux, minimalistyczną dystrybucję zaprojektowaną specjalnie dla środowisk Kubernetes, oraz Omni (również od Sidero Labs) do orkiestracji z jednej płaszczyzny sterowania w całym środowisku hybrydowym.

Nie trzeba dodawać, że nie było to tak proste jak włączenie lub wyłączenie przełącznika. Ponadto należało rozważyć zalety i wady. Początkowo model wyłącznie chmurowy pomógł Hathorze szybko i skutecznie rozpocząć działalność. Odejście od tego modelu oznaczało rezygnację z części korzyści oferowanych przez chmurę, przynajmniej na początku:

„Wprowadzenie zmiany oznaczało rezygnację z wielu udogodnień oferowanych przez platformy chmurowe” — mówi Harsh. „Stracilibyśmy łatwe automatyczne skalowanie, wbudowane monitorowanie i usługi zarządzane. Zwiększyło to złożoność operacyjną. Musieliśmy również udowodnić, że możemy dorównać wydajności chmury lub ją przewyższyć. Nie było gwarancji, że znajdziemy dostawców lub narzędzia działające w sposób, którego potrzebowaliśmy. Wierzyliśmy jednak, że opanowanie kosztów i wydajności jest kluczowe dla naszego modelu biznesowego, i byliśmy gotowi podjąć to ryzyko.”

Ta decyzja się opłaca, torując drogę do kolejnego etapu rozwoju Hathory: firma obsługuje obecnie klientów na sześciu kontynentach. Może dostarczać tę samą krytyczną infrastrukturę największym studiom po znacznie niższym koszcie niż wcześniej. Zapewnia również bardziej szczegółową kontrolę nad unikalnymi wymaganiami obciążeń związanych z grami (jest to także główna korzyść z oprogramowania do zarządzania wymaganiami), oferując kontrolę na poziomie węzłów dzięki Talos Linux oraz ujednoliconą orkiestrację klastrów za pomocą Omni, niezależnie od miejsca uruchomienia obciążeń.

„Te narzędzia są minimalistyczne, bezpieczne i łatwe w obsłudze w różnych typach infrastruktury” — mówi Harsh. „Ocenialiśmy nasz stos pod kątem wydajności, kosztów oraz zakresu kontroli, jaki zachowamy. Nowa konfiguracja pozwala nam działać przy niewielkim zespole i skalować się globalnie bez uzależnienia od jednego dostawcy.”

Rzeczywiście, niewielki zespół inżynierski Hathory stał się swego rodzaju nieoficjalnym KPI. Po przeniesieniu pierwszego pełnego regionu do modelu hybrydowego firma odnotowała natychmiastową poprawę wydajności i obniżenie kosztów, a następnie szybko się rozrosła (obecnie działa w 14 regionach na całym świecie).

„Za każdym razem, gdy ktoś dowiaduje się, że naszą infrastrukturą zarządza zaledwie kilku inżynierów, jest to moment, który uświadamia nam, jak wiele osiągnęliśmy.”

Najważniejsze wnioski i zdobyte doświadczenia

Nie musisz działać w branży infrastruktury cyfrowej ani gier wideo, aby zastosować podobne zasady i wyciągnąć podobne wnioski we własnej firmie.

  • Słuchaj swoich klientów: Harsh i jego zespół zorientowali się, że mają problem — i że muszą aktywnie go rozwiązać — słuchając swoich klientów, w szczególności dużego studia, które wykorzystywało Hathorę do testów wewnętrznych, a później poprosiło o oszacowanie kosztów uruchomienia na niej rzeczywistej gry. Dyrektorzy ds. technologii są w takim samym stopniu odpowiedzialni za rozwiązywanie problemów klientów, jak za tworzenie rozwiązań technologicznych — te dwa obszary są ze sobą ściśle powiązane.
  • Nie bój się zmieniać kierunku. „Chmura przede wszystkim”, „natywna chmurowość” i podobne terminy należy traktować jako elastyczne strategie, a nie święte dogmaty. Ta sama zasada ma szerokie zastosowanie: to, że zaczynasz od określonej strategii, nie oznacza, że musisz trzymać się jej na zawsze. Hathora mogła pozostać przy dotychczasowym rozwiązaniu i działać wyłącznie w chmurze, ale ograniczyłoby to jej potencjał wzrostu, a ostatecznie także wydajność gier działających na jej infrastrukturze.

Przejście na model hybrydowy umożliwiło firmie obsługę klientów każdej wielkości i poprawę wydajności dzięki większej elastyczności oraz kontroli podczas spełniania konkretnych wymagań obciążeń związanych z grami. Hathora mogła od tego czasu uruchomić ofertę dla przedsiębiorstw, która zapewnia największym studiom przewidywalne ceny i gwarancje wysokiej wydajności.

  • Dokładnie analizuj sytuację. Tego rodzaju transformacji nie da się przeprowadzić na podstawie zgadywania. Harsh i jego zespół przeprowadzili pełną weryfikację koncepcji z użyciem Talos i Omni, aby przetestować zmianę strategiczną:

„Gdy potwierdziliśmy, że możemy zorganizować całość za pomocą jednego systemu, przenieśliśmy nasz pierwszy kompletny region. Wzrost wydajności był natychmiastowy. Następnie wdrożyliśmy ten model globalnie, po drodze dodając dostawców i lokalizacje” — powiedział Harsh.

Przeanalizowano zalety i wady — w tym początkową utratę korzyści chmury, którą Harsh opisał powyżej — aby zminimalizować niespodzianki. Firma wiedziała, że musi znaleźć rozwiązanie przyjazne dla Kubernetes, które mogłoby koordynować całość w wielu środowiskach i regionach, a także zasadniczo traktować każdą maszynę tak samo, niezależnie od tego, czy działała na serwerze fizycznym, czy w chmurze.

Harsh zauważył, że szczegółowo przeanalizowali także wyniki testów porównawczych dostawców, porównując procesory AMD i Intel, testując rzeczywistą wydajność sieci oraz oceniając dostawców pod kątem tego, jak dobrze radzili sobie w porównaniu z usługą Global Accelerator firmy AWS. 

„Dopilnowaliśmy, aby nasza nowa konfiguracja była nie tylko tańsza, lecz także szybsza i bardziej niezawodna w regionach, które miały znaczenie”.

  • Myśl długofalowo: Takie przełomowe zmiany kierunku nie służą wyłącznie rozwiązywaniu jednorazowych problemów. Jeśli zostaną właściwie przeprowadzone, otwierają coraz więcej możliwości na przyszłość. Długofalowe podejście już przynosi Hathorze korzyści. Firma nadal opracowuje nowe funkcje dla większych studiów, takie jak opcje dedykowanych klastrów, peering regionalny zapewniający przekazywanie danych z małymi opóźnieniami oraz rozszerzone możliwości obserwowalności podczas wydarzeń na żywo.

Harsh powiedział również, że nowy model infrastruktury Hathory dla branży gier wykazuje potencjalną wartość w innych branżach, które wymagają reagowania w czasie rzeczywistym i dużej przepustowości, a długoterminowy plan firmy zakłada wprowadzanie nowych rozwiązań dla deweloperów spoza branży gier.

„Przejście na model hybrydowy zapewniło nam długoterminową elastyczność. Możemy teraz szybko wchodzić do nowych regionów, testować nowych dostawców sprzętu bez uzależnienia od jednego z nich oraz zapewniać klientom większą kontrolę nad sposobem wdrażania ich infrastruktury. Platforma stała się znacznie bardziej modułowa i elastyczna”.

Aby poznać więcej studiów przypadków i podręczników strategicznych, zasubskrybuj biuletyn The CTO Club.

Kevin Casey
Kevin Casey is an award-winning technology and business writer with deep expertise in digital media. He covers all things IT, with a particular interest in cloud computing, software development, security, careers, leadership, and culture. Kevin's stories have been mentioned in The New York Times, The Wall Street Journal, CIO Journal, and other publications. His InformationWeek.com on ageism in the tech industry, "Are You Too Old For IT?," won an Azbee Award from the American Society of Business Publication Editors (ASBPE), and he's a former Community Choice honoree in the Small Business Influencer Awards. In the corporate world, he's worked for startups and Fortune 500 firms – as well as with their partners and customers – to develop content driven by business goals and customer needs. He can turn almost any subject matter into stories that connect with their intended audience, and has done so for companies like Red Hat, Verizon, New Relic, Puppet Labs, Intuit, American Express, HPE, Dell, and others. Kevin teaches writing at Duke University, where he is a Lecturing Fellow in the nationally recognized Thompson Writing Program.
Follow the author:

You may also like