Data wygaśnięcia: 6 kwietnia 2021 r.

6 kwietnia 2021 r. doszło do nieoczekiwanego wygaśnięcia certyfikatu TLS typu wildcard. Wygaśnięcie certyfikatu było żebujące, ale czuliśmy, że powinniśmy podzielić się tu historią tego zdarzenia z nadzieją że inni mogą wyciągnąć wnioski z naszych błędów i ulepszyć swoje systemy. Jeśli Ty lub Twoja firma korzystacie z systemów monitorowania certyfikatów, dobrze jest sprawdzić je pod kątem luk.

Certyfikat, który wygasł, był wykorzystywany przez wiele wewnętrznych usług Epic. Zbyt wiele, prawdę mówiąc. Mimo dokładania najlepszych starań, aby monitorować nasze certyfikaty pod kątem wygaśnięcia, nie objęliśmy kontrolą wszystkich obszarów, w których certyfikaty były wykorzystywane. Po wygaśnięciu i odnowieniu certyfikatu doszło do serii nieoczekiwanych wydarzeń, które poszerzyły skalę awarii. Mamy na ten temat więcej informacji.

Problem dotknął kluczowych komponentów, takich jak systemy tożsamości i uwierzytelniania, a te usługi są połączone z wieloma innymi w całym naszym ekosystemie. Następujące problemy zostały zauważone lub zgłoszone:

Zalogowanie się na konto Epic nie było możliwe z żadnego produktu korzystającego z tej formy uwierzytelniania, w tym z Fortnite, Rocket League, Houseparty, Epic Online Services oraz Epic Games Store
Nastąpiły rozłączenia z aktywnych rozgrywek oraz usług na wszystkich platformach
Zakupy produktów z programu uruchamiającego Epic Games kończyły się niepowodzeniem
W programie uruchamiającym Epic Games zauważono nieoczekiwane zachowania, od treści, które nie ładowały się prawidłowo, po niedziałający tryb offline
Produkty i strony marketingowe Epic Games, w tym strony związane z silnikiem Unreal Engine, były niedostępne lub nastąpiło pogorszenie ich wydajności
Wiele problemów z wewnętrznymi narzędziami utrudniło pracę pracowników Epic i możliwość rozwiązania problemów lub nimi zarządzania

Niniejszy post ma na celu przekazanie szczegółowych informacji na temat tego, co się wydarzyło, tego, czego się nauczyliśmy, oraz tego, co zamierzamy zrobić w przyszłości.

Co się stało?

Zdarzenie można podzielić na trzy główne etapy:

Wygasły certyfikat spowodował awarię dużej części komunikacji pomiędzy wewnętrznymi usługami i wewnętrznych narzędzi do zarządzania
Nieoczekiwany, znacznie wyższy ruch w programie uruchamiającym Epic Games spowodował problemy z programem uruchamiającym Epic Games oraz funkcjami dystrybucji treści
W ramach automatycznego skalowania została wdrożona niepoprawna wersja strony Epic Games Store, podająca nieprawidłowe informacje i materiały, co wpłynęło negatywnie na doświadczenie użytkowników Epic Games Store

1) Wygaśnięcie certyfikatu

6 kwietnia o godz. 12:00 czasu UTC wygasł certyfikat TLS. Certyfikat był używany przez dużą część usług komunikacji wewnętrznej na platformie Epic. Korzystamy z szyfrowania TLS w komunikacji pomiędzy wewnętrznymi usługami back-end do międzyusługowego wywoływania API oraz wewnętrznych narzędzi do zarządzania. Certyfikat ten jest przeznaczony dla wewnętrznej strefy DNS, która nie jest publicznie dostępna.

O godz. 12:00 czasu UTC ruch pomiędzy systemami wewnętrznymi został praktycznie wstrzymany. Sześć minut później, o 12:06 czasu UTC, awaria została zgłoszona i rozpoczął się nasz proces rozwiązywania problemu. Mamy wiele systemów informowania o awarii, ale zawsze zachęcamy również wszystkich pracowników do zgłaszania jakichkolwiek zauważonych przez nich problemów mających szerokie reperkusje. Każde zgłoszenie jest wstępnie analizowane przez nasz zespół operacyjny pracujący 24 h na dobę, 7 dni w tygodniu. Zespół ten następnie rozpoczyna procedurę zarządzania problemem. Kiedy pojawiły się pierwsze zgłoszenia dotyczące awarii, nasze wewnętrzne narzędzia i procesy zarządzania automatycznie utworzyły kanał na Slacku, a odpowiednie strony zostały do niego zaproszone lub poinformowane o awarii.

O 12:12 czasu UTC potwierdziliśmy wygaśnięcie certyfikatu, który naszym zdaniem był powodem problemu, i rozpoczęliśmy proces jego odnowienia. O 12:37 czasu UTC certyfikat został wydany ponownie i w zaktualizowanej formie zaczął docierać do naszych wewnętrznych usług. Przez kolejne pięć do 15 minut system równoważenia obciążeń zaczął automatycznie wdrażać nowy certyfikat w wewnętrznych punktach końcowych i odzyskaliśmy wewnętrzną komunikację HTTPS między usługami wraz z interfejsami do zarządzania.

Nasz zespół operacyjny, który dokonał pierwszej analizy problemu, zarządzał również jego rozwiązaniem na tym etapie i przekazywał informacje pracownikom, angażując w proces odpowiednie osoby. O 12:38 czasu UTC odbyła się rozmowa przez Zoom w celu skoordynowania osób współpracujących na Slacku. Slack to dobre narzędzie do komunikacji, ale w sytuacjach awaryjnych nie ma nic lepszego niż rozmowa na żywo, audio lub wideo. Wewnętrzne aktualizacje na temat problemu były wysyłane regularnie do zainteresowanych stron przy pomocy naszych narzędzi i procesów, żeby wszyscy byli na bieżąco. Na tym etapie mieliśmy ponad 25 osób bezpośrednio zaangażowanych i pracujących nad rozwiązaniem problemu, a dużo więcej obserwowało rozwój sytuacji: od działu wsparcia graczy, społeczności, zespołu inżynierskiego i produkcyjnego po wiele różnych produktów i zespołów.

Wykres liczby żądań na minutę do pojedynczej mikrousługi, ze spadkiem w momencie wygaśnięcia certyfikatu oraz wzrostem w chwili powrotu pełnej operacyjności.

Czynniki wpływające

Sfery DNS odpowiadające za wewnętrzną komunikację między usługami nie były aktywnie monitorowane przez nasze usługi monitorowania certyfikatów, co było przeoczeniem z naszej strony. Nasze usługi monitorowania certyfikatów bazują na całych zestawach nazw DNS, a nie pojedynczych punktach końcowych lub certyfikatach i zabrakło konfiguracji tej wewnętrznej strefy. Objęliśmy już ten obszar naszym nowym rozwiązaniem monitorowania, żeby zlikwidować tę lukę. Przed awarią zaczęliśmy również realizację projektu mającego na celu wdrożenie i skonfigurowanie usługi AWS Config globalnie na wszystkich naszych kontach. Z takim globalnym rozwiązaniem możemy z łatwością dodać regułę AWS Config umożliwiającą ostrzeżenia o wygasającym certyfikacie w ramach głębokiej obrony.

Automatyczne odnowienia nie były włączone dla tego wewnętrznego certyfikatu, a prace potrzebne do ich włączenianie stanowiły priorytetu, kiedy zostały zidentyfikowane wcześniej w tym roku. Dysponujemy odpowiednimi systemami i usługami umożliwiającymi automatyczne odnawianie, ale migracja do nich nie została ukończona przed wystąpieniem awarii. Sądziliśmy, że istniejące systemy monitorowania chroniły nas przed wygaśnięciem certyfikatu dużo lepiej niż w rzeczywistości. Zajmiemy się przeniesieniem tego certyfikatu i innych do systemu automatycznego odnawiania. W międzyczasie zakończyliśmy ręczny audyt wszystkich certyfikatów.

Ten międzyusługowy certyfikat typu „wildcard” był wykorzystywany w setkach innych usług produkcyjnych, dlatego skala awarii była tak duża. Do zarządzania tym certyfikatem wykorzystujemy ACM (AWS Certificate Manager) AWS, co pozwoliło nam szybko odnowić i zastosować ten certyfikat w setkach usług produkcyjnych na przestrzeni minut. Problem z wygaśnięciem certyfikatu nie miał nic wspólnego z samym ACM AWS, ale z tym, jak zarządzamy swoim certyfikatem. Będziemy pracować nad rozdzieleniem zasięgu oddziaływania naszych certyfikatów, a jednym z elementów naszego postępowania będzie aktualizacja procesów dotyczących używania certyfikatów za pomocą ACM AWS.

2) Istotny wzrost ruchu dla usługi programu uruchamiającego Epic Games

Podczas gdy większość usług została przywrócona natychmiast po odnowieniu certyfikatu, usługi programu uruchamiającego Epic Games pozostały efektywnieniedostępne.

O godzinie 12:46 UTC, po wydaniu certyfikatu, gwałtowny wzrost liczby żądań przeciążył usługę programu uruchamiającego Epic Games – kluczową usługę wewnętrzną, która obsługuje klienta programu uruchamiającego Epic Games. Zwiększona liczba żądań była spowodowana nieoczekiwaną logiką ponowień klientów, która ujawnia się tylko w sytuacjach awaryjnych. Na przestrzeni lat przeprowadziliśmy wiele prac związanych z odpornością programu uruchamiającego Epic Games, jednak ten przypadek zwiększenia liczby żądań był niespodziewany. Limity monitorowania połączeń u naszych hostów zostały osiągnięte. Pakiety były gubione w całej infrastrukturze, co sprawiało, że odzyskiwanie danych było trudniejsze, nawet gdy nasza sieć aplikacji wewnętrznych zwiększyła się o 250%. W usługach programu uruchamiającego Epic Games doszło do kaskadowej awarii i pełnego przestoju, a przywrócenie sprawności wymagało ograniczenia ruchu do zaplecza, a następnie stopniowego zwiększania ruchu z powrotem do systemu, przy jednoczesnym zwiększaniu limitów monitorowania połączeń.

Spora liczba klientów naszego programu uruchamiającego Epic Games Launcher generowała dziesiątki milionów połączeń z usługą wewnętrzną programu uruchamiającego Epic Games, a komponenty systemów programu uruchamiającego Epic Games w wyniku tego obciążenia doznały usterki. Musieliśmy ograniczyć ruch do zaplecza, aby umożliwić powrót do normalności. Podczas gdy normalnie dla tej usługi mamy dostępną przepustowość typu burst, nie pozwoliła ona na obsługę nawet 28-krotnego obciążenia, które zaobserwowaliśmy na początku awarii.

Wykres liczby żądań na minutę skierowanych do naszego systemu równoważenia obciążeń zaplecza programu uruchamiającego Epic Games. Ruch wzrósł początkowo 28-krotnie, a końcowy szczyt o 15:12 UTC stanowił 40-krotność normalnego.

Podczas gdy liczba żądań była ponad 28 razy większa niż normalnie, sama liczba połączeń do usługi programu uruchamiającego Epic Games wyczerpała dostępną przestrzeń monitorowania połączeń, co spowodowało utratę pakietów i ostatecznie pogorszenie łączności z węzłami zaplecza. Obciążenie zaplecza połączeniami wzrosło 3200 razy w stosunku do normalnego. Wzrost liczby połączeń TCP był znacznie większy niż liczba żądań.

Wykres liczby nowych połączeń na minutę do naszego systemu równoważenia obciążeń zaplecza programu uruchamiającego Epic Games z 3200-krotnym wzrostem połączeń w porównaniu do normalnego szczytu.

Czynniki wpływające

Certyfikat TLS, który wygasł, spowodował awarię, która wywołała nieoczekiwane zachowanie naszego klienta programu uruchamiającego. Przeprowadzona kontrola pozwoliła nam ustalić, że system ponawiania połączeń klienta używał liniowej logiki ponawiania zamiast oczekiwanego przez nas mechanizmu wykładniczego backoffu. Dodatkowy nieoczekiwany błąd powodował również, że wzorzec żądania milionów klientów programu uruchamiającego Epic Games stale i bez końca ponawiał próby, aż do uzyskania odpowiedzi. Te dwa błędy w bazie instalacyjnej naszego klienta stworzyły niezamierzony i nieprzewidziany wzorzec połączeń. Zostaliśmy skutecznie zablokowani przez naszych własnych klientów, pilnie więc pracujemy nad wprowadzeniem poprawek tych błędów w aktualizacji programu uruchamiającego Epic Games.

Interesującym czynnikiem sprzyjającym tej części incydentu jest długość początkowego przestoju. Im dłużej trwała awaria, tym większe było prawdopodobieństwo, że większa liczba klientów wykorzysta wadliwą logikę ponowienia próby i będzie stale próbować łączyć się z naszym zapleczem. Gdyby początkowa awaria trwała krócej, być może nie zgromadzilibyśmy wystarczającej liczby klientów wykonujących stale ponowne próby połączenia, które doprowadziły do przeciążenia systemu. Jedynie awaria o takiej długości trwania mogła ujawnić ten przypadek. Rozwiążemy ten problem poprzez zmiany w schemacie połączeń.

Nasz alarm dotyczący monitorowania połączeń nie został właściwie zinterpretowany. Ten alarm uruchomił się podczas awarii dla usługi programu uruchamiającego Epic Games i chociaż kilka zespołów zna znaczenie tego alarmu, jego opis i powiadomienie nie były wystarczająco jasne i nie było wiadomo, że ten stan spowoduje utratę pakietów w każdym połączeniu, które te hosty wykonają, w tym w połączeniu z wewnętrznym klastrem Redis. Moment, w którym łączność z klastrem Redis uległa degradacji, był bardzo stresujący dla zespołu badającego problem. Podejrzewano, że przyczyna leży częściowo po stronie naszych mechanizmów buforowania. Później okazało się, że było to spowodowane utratą pakietów z powodu zapełnienia tabeli monitorowania połączeń, wobec pozostających w użyciu kilkuset tysięcy połączeń. Na dalszym etapie awarii podnieśliśmy nasze limity śledzenia połączeń do ponad jednego miliona na węzeł, ale podniesienie liczby monitorowanych połączeń w naszej infrastrukturze nie następuje natychmiastowo i zajęło trochę czasu. Będziemy pracować nad aktualizacją naszego alarmu, aby wyraźniej sygnalizował, że sytuacja ta spowoduje poważne problemy z połączeniami, dopóki nie zostanie rozwiązana.

Skalowanie powodowało natychmiastowe osiąganie limitów monitorowania połączeń przez nowe węzły. Ponieważ nasza infrastruktura była przeciążona połączeniami, co powodowało poważne straty pakietów, musieliśmy zmniejszyć wszelki ruch do infrastruktury, a następnie powoli zwiększać dozwolony zakres ruchu. Najpierw próbowaliśmy użyć WAF (Web Application Firewall) AWS, aby ograniczyć ruch do podzbioru ruchu przychodzącego, jednak nasza konfiguracja nie ograniczała ruchu w wystarczającym stopniu. Przyczyna nie leżała po stronie WAF AWS, lecz określonych przez nas samych ustawień. Ze względu na upływający czas użyliśmy obciążeń docelowych naszego systemu równoważenia obciążeń AWS, aby przenieść trochę ruchu, co wraz z podniesieniem naszych limitów monitorowania połączeń ostatecznie się powiodło. Użycie WAF w tym scenariuszu opóźniło odzyskanie przez nas usług programu uruchamiającego Epic Games, ale nie było winą AWS. Zamierzamy opracować standardowy proces, pozwalający pilnie odciążyć ruch w krytycznych sytuacjach, takich jak ta, dzięki wykorzystaniu WAF AWS, obciążeń docelowych systemu równoważenia obciążeń lub innych technologii AWS.

3) Nieprawidłowe zasoby na stronie Epic Games Store

O 15:12 czasu UTC, mając odnowiony certyfikat i przywróconą usługę programu uruchamiającego Epic Games, przystąpiliśmy do odblokowania wszystkich klientów łączących się z Epic Games Store. Ze względu na długość trwania awarii znacznie więcej klientów niż zwykle zażądało zawartości ze sklepu Epic Games Store, który zaczął się w naturalny sposób powiększać. Ocenę pozostałych skutków awarii rozpoczęliśmy około godziny 15:30 czasu UTC.

Początkowo wszystko wyglądało normalnie, ale zaczęliśmy otrzymywać wewnętrzne raporty dotyczące problemów z układem i błędach w sklepie, które udało się nam potwierdzić i odtworzyć. Po analizie danych zauważyliśmy, że klient web (używany przez użytkownika witryny epicgames.com do interakcji ze sklepem) próbował pobrać unikalny identyfikator zasobu, którego nie było w naszej sieci CDN. Sprawdziliśmy wersje kontenerów wprowadzone w całej infrastrukturze i wszystkie były takie same, ale jeśli to prawda, to w jaki sposób ta sama wersja aplikacji może zwracać różne statyczne wartości zasobów?

Coś tu było nie tak. Był to bardzo zagmatwany etap incydentu i ostatecznie wiele z dostępnych sygnałów (np. wprowadzone wersje) okazały się fałszywymi sygnałami. Udało nam się skorelować skalowanie zaplecza Epic Games Store ze wzrostem błędów 403 w naszej sieci CDN, co pozwoliło nam na bardziej szczegółowe badanie nowych przypadków. Po lokalnym przeniesieniu treści z nowych przypadków odkryliśmy, że zwracana treść była nieprawidłowa. Udało nam się znaleźć nieoczekiwany push kontenera do nowego cyklu CI/CD, wykonanego dzień wcześniej i całkowicie niezwiązanego ze wszystkim, co do tej pory napotkaliśmy podczas tego incydentu. Te wyniki wciąż były zaskakujące, ale po tym odkryciu w końcu byliśmy w stanie szybko przywrócić wersję kontenera, usunąć nieprawidłowości i przywrócić ruch sieciowy.

Ten problem mógł pojawić się podczas dowolnego obszernego skalowania, które miało miejsce w tym okresie, ale ponieważ zwykle utrzymujemy duży zapas w infrastrukturze, problem ten pojawił się dopiero po skalowaniu Epic Games Store w związku z ruchem sieciowym programu uruchamiającego Epic Games.

Czynniki wpływające

Awaria certyfikatu doprowadziła do problemów z programem uruchamiającym Epic Games, które po odzyskaniu spowodowały burzę zapytań do sklepu Epic Games Store, co z kolei skutkowało skalowaniem systemów Epic Games Store. Jest to oczekiwane i mile widziane.

Sygnały i dane dotyczące stanu wersji całej naszej infrastruktury aplikacji wprowadziły nas w błędne przekonanie, że infrastruktura była wdrożona w jednolity sposób. Zmieniliśmy schemat wersjonowania, aby zapobiec błędnej diagnozie w przyszłości.

Niedawna zmiana w CI/CD pipeline dla Epic Games Store miała błędną konfigurację, która spowodowała nieoczekiwaną aktualizację artefaktu aplikacji. Naprawiono to poprzez modyfikację CI/CD pipeline, co cofnęło nieoczekiwane zmiany. Zmiana schematu wersjonowania ochroni nas, jeśli zdarzy się to ponownie.

Oś czasu

12:00 czasu UTC − Wygaśnięcie certyfikatu wewnętrznego
12:06 czasu UTC − Zgłoszono incydent i rozpoczęto działania
12:15 czasu UTC − Przygotowano pierwsze wiadomości do klientów
12:21 czasu UTC − Wiele zespołów potwierdziło liczne duże awarie serwisu
12:25 czasu UTC − Potwierdzono, że proces ponownego wydania certyfikatu został rozpoczęty
12:37 czasu UTC − Potwierdzono ponowne wydanie certyfikatu
12:46 czasu UTC − Potwierdzono odzyskanie niektórych usług
12:54 czasu UTC − Wykryto problem w śledzeniu połączeń usług programu uruchamiającego Epic Games
13:41 czasu UTC − Zrestartowano węzły usług w programie uruchamiającym Epic Games
15:05 czasu UTC − Zwiększono limity śledzenia połączeń dla usług programu uruchamiającego Epic Games
15:12 czasu UTC − Pierwsze oznaki przywrócenia usług programu uruchamiającego Epic Games
15:34 czasu UTC − Skalowanie usług internetowych Epic Games Store
15:59 czasu UTC − Pierwsze raporty o brakujących zasobach w Epic Games Store
16:57 czasu UTC − Wykryto problem z niedopasowanymi wersjami usług internetowych Epic Games Store
17:22 czasu UTC − Poprawiono wersję serwisu internetowego Epic Games Store
17:35 czasu UTC − Odzyskanie pełnego zakresu usług

Co dalej?

W powyższych sekcjach omówiliśmy scenariusze, które doprowadziły do niespodzianek i ostatecznie do przerwy w dostępności usług w dniu 6 kwietnia. Wspomnieliśmy o kolejnych krokach i czynnikach, które się do tego przyczyniły, ale podsumujmy je również tutaj.

Nie istnieje jedna główna przyczyna tych problemów. Na rozwój wydarzeń złożyło się mnóstwo czynników, zarówno technicznych, jak i organizacyjnych. Zakres i długość przerwy pomogły nam odkryć nie tylko widoczne błędy w naszych systemach, nad których naprawą będziemy pracować, ale także wcześniej niekwestionowane założenia w niektórych procesach wewnętrznych, szczególnie w zarządzaniu certyfikatami.

Mimo że natychmiast rozpoczęliśmy monitorowanie tej strefy naszym nowszym systemem monitorowania certyfikatów i przeprowadziliśmy audyt wszystkich znanych certyfikatów, przyjrzymy się dokładniej wszelkim dodatkowym lukom w monitorowaniu i wprowadzimy dodatkowe zabezpieczenia zapobiegawcze, takie jak monitorowanie AWS Config dla wszystkich certyfikatów opartych na ACM AWS. Będziemy również pracować nad minimalizacją szkód wyrządzanych przez konkretne certyfikaty.

Przyjrzymy się bliżej wzorcom połączeń klienta programu uruchamiającego Epic Games i pilnie naprawimy błędy, które odkryliśmy, a także poprawimy zdolność reagowania w przypadkach znacznie zwiększonego ruchu sieciowego. Przy ciągłym wzroście tabel śledzenia połączeń dla tej infrastruktury powinniśmy być w stanie obsłużyć podobne obciążenie bez poważnej utraty pakietów. Firmy korzystające z dużych infrastruktur powinny pamiętać o sprawdzaniu limitów tabeli śledzenia połączeń i powiadomienia, jeśli używają tej funkcji netfilter. Służymy za przypomnienie, by sprawdzić logikę ponawiania w klientach, a zwłaszcza to, jak mogą zachowywać się zbiorczo po długiej przerwie.

W Epic Games Store wprowadziliśmy poprawkę, która powinna uniemożliwić modyfikowanie działającego obiektu aplikacji, a w ramach tego znaleźliśmy i naprawiliśmy błąd dotyczący generowania zasobów.

Mamy nadzieję, że w raport wyczerpująco opisuje zdarzenia z 6 kwietnia, a zawarte w nim informacje ułatwią zrozumienie tego, czego się nauczyliśmy i co ulepszyliśmy, oraz pomogą innym uniknąć podobnych problemów.

Dołącz do nas!

Ten post został napisany przez nasz zespół inżynierski ds. niezawodności z pomocą wielu innych, niesamowitych zespołów inżynierów w Epic.

Interesują Cię problemy tego typu? Pasjonujesz się grami i związanymi z nimi usługami? W Epic zawsze poszukujemy utalentowanych osób o rozmaitych umiejętnościach i oferujemy pracę na całym świecie. Jeśli szukasz wakatów, odwiedź portal Epic Games Career.

Czy ten post był pomocny lub interesujący? Napisz do nas na public-incident-response@epicgames.com.