Optimizacija obrade video frame-ova uz KEDA

Projekat je paralelno obrađivao filmske frame-ove na AWS EKS. Postojeći pristup je mogao trajati više od sedam sati po jednom izvršavanju.

Izazov

Workload je bio veoma paralelan, ali neravnomjeran. Jedno izvršavanje moglo je sadržati veliki broj frame-ova, a trajanje je zavisilo od toga koliko brzo se worker-i podizu, koliko dobro se red prazni i gdje se pojavljuju infrastrukturna ograničenja. Samo povecavanje podrazumijevanog broja podova povecalo bi trošak i i dalje ostavilo tim bez jasnog odgovora koji je pravi operating point.

Cilj je bio obraditi sve frame-ove u najkraćem praktičnom vremenu, a da arhitektura ostane razumljiva za buduća izvršavanja. To znači da queue depth i throughput postaju signal za skaliranje umjesto da se frame processing tretira kao fiksni web workload.

Promena

KEDA je uvedena da skalira worker-e prema redu za obradu i potrebnom throughput-u. Ideja je bila da red opisuje trenutnu potražnju, a Kubernetes deployment-i se skaliraju gore ili dole na osnovu te potražnje umjesto da stalno održavaju visok broj podova.

Implementacija je uključila podešavanje odnosa između broja poruka u redu, konkurentnosti worker-a, vremena podizanja podova i limita cloud providera. Tim je testirao koliko frame-ova jedan worker može obraditi, koliko brzo pod postaje koristan nakon schedule-ovanja i gdje cluster ili account kvote postaju usko grlo.

Arhitektonska razmatranja

Rad se izvršavao na AWS EKS, pa optimizacija nije bila samo Kubernetes konfiguracija. Node kapacitet, scheduler ponašanje, vrijeme povlacenja container image-a i limiti eksternih servisa uticali su na ukupni throughput. KEDA je rjesavala event-driven skaliranje, ali je platforma oko nje morala imati dovoljno prostora da to skaliranje zaista pomogne.

Observability je bio bitan tokom podešavanja. Dužina reda je pokazivala da li sistem kasni. Stopa završenih worker zadataka je pokazivala da li dodatni podovi još imaju efekta. Cluster kapacitet i provider kvote su pokazivali kada se sljedeće usko grlo pomjerilo izvan aplikacije.

Tradeoff-i

Finalna konfiguracija je dala prednost predvidivom vremenu završetka umjesto maksimalnom teoretskom paralelizmu. Preagresivno skaliranje može prebaciti problem u quota greške, retry talase ili skup idle kapacitet nakon što se red isprazni. Presporo skaliranje čuva stabilnost, ali produžava obradu.

Korisno inženjersko pitanje nije bilo "koliko podova možemo pokrenuti?", već "koliko korisnih podova može obrađivati frame-ove prije nego što drugi dio sistema postane ograničenje?" Taj okvir je ucinio razgovor o skaliranju jasnijim i za inženjere i za product stakeholder-e.

Rezultat

Vreme obrade smanjeno je na oko dva sata. Tokom optimizacije sistem je dostigao limite cloud providera, pa su capacity planning i ograničenja skaliranja postali deo arhitektonske odluke.

Projekat je takođe dao ponovljiv način razmišljanja za buduće batch workload-e: definisati queue signal, izmjeriti throughput worker-a, naći infrastrukturne limite i podesiti autoscaling prema stvarnom cilju završetka, ne prema generičnom CPU pragu.