Spark przy 8 mln zadań dziennie: gdzie uciekają zasoby

Salesforce przeanalizował środowisko Spark obsługujące osiem milionów zadań dziennie i wyszło z tego dość proste rozpoznanie: przy tej skali zasoby marnują się szybciej, niż zwykle widać to na poziomie pojedynczego joba.

Najwięcej problemów robiły nadmiarowo przydzielana pamięć, słabe wykorzystanie wątków CPU i długie czekanie na dostęp do zasobów. Odpowiedź nie sprowadza się do podbicia limitów, tylko do telemetrii, kontroli współbieżności i automatycznego strojenia konfiguracji.

Telemetria pokazuje, które joby naprawdę duszą klaster

Przy milionach uruchomień dziennie nie da się oceniać wydajności po kilku głośnych incydentach. Potrzebna jest szczegółowa analiza danych telemetrycznych, bo dopiero ona pokazuje, które zadania biorą najwięcej pamięci, gdzie CPU stoi niewykorzystane i które kolejki zaczynają się korkować.

To podejście dobrze zna każdy, kto utrzymuje większy krajobraz danych obok platformy CRM. W praktyce problem nie zaczyna się wtedy, gdy jeden pipeline padnie, tylko wtedy, gdy wiele zadań działa niby poprawnie, ale razem zjada przepustowość klastra i wydłuża czas oczekiwania całej reszty.

Nadmiar pamięci i słabe użycie CPU nie rozwiązują się same

W analizie wyszły trzy klasyczne wąskie gardła: za dużo pamięci przypisanej do zadań, nieefektywne użycie wątków CPU i długi czas oczekiwania na zasoby. Każdy z tych problemów osobno boli, ale razem tworzą układ, w którym klaster jest jednocześnie drogi i wolny.

Nadmierny przydział pamięci daje złudne poczucie bezpieczeństwa. Job ma zapas, ale ten zapas blokuje miejsce dla innych zadań. Z kolei słabe wykorzystanie CPU oznacza, że zespół płaci za moc obliczeniową, która przez część czasu po prostu nie pracuje. Gdy do tego dochodzi kolejka czekających zadań, stabilność całego środowiska zaczyna zależeć od tego, czy scheduler wytrzyma skoki obciążenia.

Ten sam schemat pojawia się też w innych obszarach platformowych: bez sensownego monitoringu łatwo przegapić, że problemem nie jest pojedyncza konfiguracja, tylko suma małych strat. Podobny nacisk na obserwowalność widać w temacie monitoringu danych w czasie rzeczywistym, gdzie liczy się nie sam alarm, ale kontekst zdarzeń.

Dynamiczne przydzielanie zasobów zamiast ręcznego zgadywania

Jednym z kluczowych mechanizmów jest dynamiczne przydzielanie zasobów. Chodzi o lepszy balans między czasem wykonania a zużyciem pamięci i CPU, bez sztywnego ustawiania wszystkiego pod najgorszy możliwy przypadek.

To ma znaczenie zwłaszcza tam, gdzie obciążenie nie jest równe. Jedne zadania kończą się szybko, inne chwilowo podbijają zapotrzebowanie. Jeśli konfiguracja jest statyczna, bardzo łatwo przepalić zasoby na zapas. Jeśli jest dostosowywana automatycznie, klaster ma większą szansę utrzymać responsywność bez dokładania kolejnych rezerw.

W zespołach, które na co dzień stroją flow, deploymenty i integracje, ten wniosek brzmi znajomo: ręczne ustawienia dobrze wyglądają na starcie, ale przy wzroście skali zaczynają przegrywać z automatyzacją. Dlatego dyskusja o wydajności zwykle kończy się nie na jednym parametrze, tylko na całym modelu zarządzania obciążeniem.

Limity współbieżności i kolejki decydują o stabilności

Osobny temat to zarządzanie limitem równoczesnych zadań i monitorowanie kolejek przetwarzania. Bez tego klaster może zostać przeciążony nawet wtedy, gdy pojedyncze joby są poprawnie skonfigurowane.

Przy dużej skali stabilność nie zależy wyłącznie od szybkości wykonywania. Liczy się też to, ile zadań wpuszczasz naraz i jak długo reszta czeka. Jeżeli kolejki rosną, a czas oczekiwania przestaje być przewidywalny, system traci responsywność. Właśnie dlatego ciągły monitoring, elastyczne zarządzanie zasobami i automatyzacja konfiguracji nie są dodatkiem do Spark, tylko warunkiem utrzymania sensownej wydajności.

Jeśli ktoś utrzymuje środowisko data processing obok Salesforce, pierwsza rzecz do sprawdzenia nie brzmi: czy mamy dość mocy. Lepiej zacząć od tego, które joby dostają za dużo pamięci, gdzie CPU się nudzi i czy limity współbieżności nie duszą klastra bardziej niż sam wolumen pracy.