Firma fintech działająca w branży mediowej unowocześniła swoją platformę Kubernetes na AWS, aby radzić sobie z nieprzewidywalnymi skokami ruchu podczas wydarzeń sportowych na żywo. Architektura multi-account, optymalizacja EKS, dostrojenie Aurora Serverless v2 i tymczasowe środowiska preview zastąpiły konfigurację opartą na jednym koncie, bez izolacji ryzyka awarii.
Branża
Fintech, dystrybucja treści
Lokalizacja
Edynburg, Wielka Brytania
Czas
07.2025 - obecnie (stała współpraca)
Firma
Startup z UK, Fintech, Platforma Mikropłatności
Nasz klient to Fintech z Edynburga, startup który dostarcza globalną infrastrukturę płatniczą dla treści cyfrowych. Jej platforma pozwala właścicielom praw i mediom zarabiać na wideo, transmisjach na żywo, podcastach i artykułach dzięki mikropłatnościom oraz dostępowi pay-per-view, bez zmuszania użytkowników do wykupywania subskrypcji. Firma współpracuje z dużymi organizacjami sportowymi i rozrywkowymi, oferując widzom na całym świecie elastyczny dostęp do treści bez abonamentu podczas wydarzeń na żywo.
Istniejąca platforma Kubernetes klienta była zaprojektowana pod wcześniejszy obszar biznesu, skupiony na przetwarzaniu wideo. Gdy firma przestawiła się na obsługę płatności w czasie rzeczywistym podczas wydarzeń sportowych na żywo, infrastruktura zaczęła stwarzać poważne problemy:
Ryzyko było jasne: bez modernizacji kolejne duże wydarzenie na żywo mogło pokazać globalnej publiczności problemy z obsługą płatności.
Przebudowaliśmy środowisko AWS do modelu multi-account w ramach AWS Organizations, z osobnymi kontami dla developmentu, stagingu i produkcji. Service Control Policies pilnują spójnych zasad bezpieczeństwa na wszystkich kontach. Izolacja na poziomie kont gwarantuje, że prace developerskie nigdy nie wpłyną na produkcyjną obsługę płatności.
Klient miał duże doświadczenie z Kubernetesem, więc zostaliśmy przy EKS i zmodernizowaliśmy konfigurację klastra zamiast przenosić wszystko na inny model orkiestracji. Rozważaliśmy ECS Fargate jako alternatywę, ale koszt przepisywania istniejących Helm chartów, manifestów i narzędzi deploymentowych nie miał uzasadnienia.
Nasza modernizacja skupiła się na:
Wdrażamy też distributed tracing oparty na OpenTelemetry, z danymi trafiającymi do stacku Amazon Managed Service for Prometheus i dashboardami w Amazon Managed Grafana, które dają wgląd w przepływy obsługi płatności podczas wydarzeń na żywo.
Platforma korzysta z Aurora Serverless v2 dla workloadów PostgreSQL i MySQL, a RDS Proxy zapewnia connection pooling podczas skoków ruchu. Amazon MSK obsługuje streaming zdarzeń dla płatności w czasie rzeczywistym i wyliczania podziału przychodów. ElastiCache odpowiada za warstwę cache.
Duża część naszej pracy polegała na optymalizacji kosztów warstwy danych. Dzięki analizie pojemności w CloudWatch znaleźliśmy klastry, które były przewymiarowane przez całą dobę, blokowały pojemność mimo niskiego średniego użycia, obok klastrów, które były dobrze dobrane i faktycznie rosły podczas wydarzeń. Każdy klaster wymagał osobnego dostrojenia na podstawie realnych wzorców użycia, zamiast jednej zmiany dla wszystkich. Wykryliśmy też starsze wersje silników, które generowały niepotrzebne dopłaty za extended support.
Cała infrastruktura AWS jest zdefiniowana i zarządzana w Terraformie, od struktury multi-account i klastrów EKS, po konfiguracje Aurora, MSK, role IAM, security groups i sieć. Zmiany są wersjonowane, przechodzą review i są wdrażane spójnie na wszystkich środowiskach.
Fundament IaC jest szczególnie ważny przy przygotowaniach do wydarzeń na żywo. Wcześniejsze skalowanie infrastruktury, node group, limity pojemności baz danych, rozmiary connection pooli, musi dziać się niezawodnie i powtarzalnie przed każdym wydarzeniem, a nie przez ręczne klikanie w konsoli. Nasza usługa Chmura pod kontrolą dokładniej pokazuje takie podejście.
Na dziś nie ma mocnych wymagań compliance wymuszających policy-as-code, ale elementy AWS Landing Zone z regułami AWS Config są zaplanowane i znajdują się w backlogu. Mają zapewnić automatyczną walidację zgodności, gdy platforma będzie rosnąć wraz z nowymi partnerstwami eventowymi.
IAM Identity Center zastąpił rozproszone zarządzanie dostępem centralnym SSO i wymuszonym MFA. Zestawy uprawnień są dopasowane do ról w zespole, sesje wygasają automatycznie, a w systemie nie ma żadnych długowiecznych danych dostępowych użytkowników IAM. AWS Secrets Manager przechowuje wszystkie dane dostępowe do baz, klucze API do obsługi płatności i sekrety integracyjne, całkowicie eliminując hardcodowane dane logowania.
AWS KMS zapewnia klucze szyfrowania zarządzane przez klienta dla danych w spoczynku w Aurora, S3 i EBS. Security groups wymuszają warstwową izolację sieci: ALB jest jedynym komponentem wystawionym do internetu, nody EKS przyjmują ruch tylko z ALB, Aurora przyjmuje połączenia tylko z EKS, a brokerzy MSK są ograniczeni do uprawnionych workloadów. Wszystko jest zdefiniowane w Terraformie.
CloudTrail zapisuje całą aktywność API na wszystkich kontach i we wszystkich regionach. VPC endpoints kierują ruch do S3 i DynamoDB wewnętrznie, zamiast przez NAT Gateways, co zmniejsza zarówno powierzchnię ataku, jak i koszty transferu danych.
Skanowanie obrazów kontenerów odbywa się na poziomie ECR, dzięki czemu podatności są wyłapywane, zanim obrazy trafią na produkcję. Kosli jest zintegrowane z pipeline’ami CI jako narzędzie do attestation łańcucha dostaw i SAST, dając ślad audytowy tego, co zostało zbudowane, przetestowane i wdrożone. Sprawdzamy też dodatkowe opcje, żeby jeszcze bardziej wzmocnić podejście shift-left security.
Architektura dobrze przygotowuje klienta do certyfikacji ISO 27001: izolacja multi-account, szyfrowanie KMS, IAM Identity Center, WAF i pełne ślady audytowe są już na miejscu. Zobacz nasze usługi bezpieczeństwa i compliance, jeśli chcesz zobaczyć, jak podchodzimy do gotowości compliance.
Przebudowaliśmy pipeline’y deploymentowe w GitHub Actions, zastępując odziedziczone workflowy, które spowalniały zespół. Nowe pipeline’y obsługują automatyczne testy, budowanie obrazów kontenerów, push do ECR i deployment na EKS z rolling updates oraz walidacją health checków.
Największą poprawą komfortu pracy było wprowadzenie tymczasowych środowisk preview: izolowanych środowisk dla każdego pull requesta, które uruchamiają się automatycznie i pozwalają developerom sprawdzić zmiany w realistycznej konfiguracji przed mergem. To całkowicie usunęło problem wspólnego stagingu jako wąskiego gardła. Zobacz nasze usługi konsultingowe CI/CD, żeby dowiedzieć się więcej o tym podejściu.
Aurora Serverless v2 zapewnia ciągłe, automatyczne backupy z point-in-time recovery, co jest kluczowe dla platformy płatniczej, gdzie utrata danych oznacza rozbieżności finansowe. Wbudowana replikacja partycji w MSK zapewnia trwałość wiadomości w przypadku awarii brokerów. Workloady EKS można w każdej chwili ponownie wdrożyć z ECR, a całą infrastrukturę da się odtworzyć z kodu Terraform.
Ustaliliśmy z klientem cele RTO i RPO, ze szczególnym naciskiem na to, jak wygląda awaria podczas wydarzenia na żywo. Deployment w jednym regionie, eu-west-1, z dystrybucją multi-AZ był świadomym kompromisem między kosztem a dostępnością, zaakceptowanym na podstawie obecnych wzorców ruchu.
Runbooki operacyjne do przygotowania wydarzeń na żywo i reagowania na incydenty to ważny temat na kolejny kwartał, bo druga połowa roku przynosi bardziej intensywny harmonogram wydarzeń. Sprawdzamy narzędzia takie jak AWS DevOps Agent do automatycznego triage’u, z celem przejścia od reaktywnego gaszenia pożarów do zapobiegawczych działań naprawczych opartych na dobrze opisanych runbookach.
Na początku nie doszacowaliśmy złożoności refaktoryzacji dojrzałego Infrastructure as Code połączonego ze skomplikowaną architekturą event-driven opartą na Kafce. Głęboko zagnieżdżone moduły Terraform i mocno powiązane konfiguracje MSK spowalniały nas w pierwszych tygodniach. Poradziliśmy sobie z tym, robiąc krok w tył, wskazując krytyczne wąskie gardła i ponownie ustawiając priorytety pod bieżące oczekiwania biznesowe klienta, zamiast próbować pełnej przebudowy wszystkiego naraz. Lekcja: przy działającej platformie, która przetwarza płatności podczas zaplanowanych wydarzeń, kolejność prac ustala się pod ryzyko biznesowe, a nie pod techniczną elegancję.
Faza modernizacji przeszła w stałą współpracę obejmującą CloudOps i utrzymanie platformy. Nadal zarządzamy klastrami EKS, stroimy konfiguracje Aurora pod harmonogramy wydarzeń, optymalizujemy koszty i wspieramy zespół inżynierski przy deploymentach oraz troubleshootingu.
Wraz ze wzrostem wolumenów transakcji wynikającym z nowych partnerstw eventowych rozwijamy strategie autoskalowania, które wcześniej dogrzewają infrastrukturę na podstawie harmonogramów wydarzeń i historycznych wzorców ruchu, tak żeby platforma była gotowa, zanim pojawią się widzowie.
Usługi AWS: Amazon EKS, Amazon ECR, Application Load Balancer, Amazon Aurora Serverless v2 (PostgreSQL, MySQL), Amazon RDS Proxy, Amazon MSK, Amazon ElastiCache, AWS Secrets Manager, AWS KMS, AWS IAM Identity Center, Amazon CloudWatch, Amazon Managed Service for Prometheus, AWS CloudTrail, Amazon S3, AWS Certificate Manager, Amazon Route 53, AWS Lambda, AWS WAF
Narzędzia: Terraform, GitHub Actions, Kosli, Docker, Helm
Czas usuwania podatności spadł o 83%. Ręczna praca przy bezpieczeństwie zmniejszyła się o 93%. Platforma teraz stabilnie skaluje się automatycznie podczas skoków ruchu na wydarzeniach na żywo, z wcześniejszym dogrzewaniem infrastruktury na podstawie harmonogramów wydarzeń, a zespół inżynierski szybciej dowozi zmiany dzięki tymczasowym środowiskom preview i usprawnionym procesom developmentu.