Konteneryzacja to za mało: transformacja architektury systemu taryfowego
Migracja systemów do środowisk kontenerowych to dziś standard. Czy jej wdrożenie jest jednoznaczne z usunięciem problemów, jakie rodzi przestarzała architektura? Nie do końca. W naszym przypadku mieliśmy dwie opcje: albo iść za radą dostawcy i przenieść monolit z dużych maszyn wirtualnych do równie monolitycznego rozwiązania opartego na ogromnych Podach, albo przeprowadzić pełną przebudowę architektury, dostosowaną do naszych potrzeb i realiów operacyjnych.
Autor
Piotr Woźny
Autor
Marcin Majchrzak
Dlaczego to robimy
Przeniesienie 1:1 systemu z maszyn wirtualnych na naszą prywatną chmurę Sahul2, opartą na Kubernetesie, wiązało się z wieloma wadami. Duże instancje musiałyby przechowywać ogromne ilości konfiguracji na dysku i nieustannie je deserializować do pamięci, co skutkowałoby nieakceptowalnym czasem odpowiedzi na żądania.
Co więcej, skalowanie, odzyskiwanie sprawności po awarii, podział odpowiedzialności, czy wreszcie nawet tak podstawowe działania, jak aktualizacje infrastruktury, również stałyby się problematyczne.
Jak do tego podeszliśmy
Zamiast jednej dużej usługi, każdy produkt otrzymał własny zestaw usług, co jasno określiło zakres odpowiedzialności i pozwoliło ograniczyć ewentualne problemy do konkretnego zestawu, a nawet pojedynczej usługi.
Każdy zestaw usług został dodatkowo podzielony na warstwy:
- HA (High Availability) z dużą liczbą replik dla najnowszych i najczęściej używanych taryf.
- Warstwy retencji, z których ostatnia to wspólna dla wszystkich produktów warstwa „archiwum” (ok. 2% wszystkich kalkulacji), z podniesionym limitem timeout.
Podejście, w którym każda usługa zarządza dokładnie jedną taryfą (z wyjątkiem warstwy archiwum), w przeciwieństwie do rozwiązania, gdzie wiele taryf działa w ramach jednej usługi, umożliwiło skuteczne autoskalowanie. Instancje uruchamiane są dokładnie wtedy, gdy trzeba, a nie dopiero po wystąpieniu obciążenia. Wymagało to nie tylko opracowania nowych metod integracji z systemem, ale również stworzenia dedykowanych narzędzi do jego obsługi. W tym celu powstał m.in. osobny projekt Helm… do generowania plików konfiguracyjnych dla projektu Helm wystawionego przez dostawcę.
Kolejnym autorskim rozwiązaniem w tym procesie było narzędzie do wgrywania taryf na dedykowane warstwy HA, z automatycznym przenoszeniem starszych modeli do kolejnych warstw retencji, oczywiście przy zachowaniu ciągłej integracji z systemem polisowym.
Wszystko, co nie stanowi szeroko rozumianych danych poufnych (takich jak hasła, certyfikaty czy klucze API), umieściliśmy w systemach kontroli wersji - od konfiguracji środowisk, przez narzędzia, po diagramy opisujące proces DR.
Efekty:
- Wyeliminowaliśmy całkowicie dziesiątki błędów, powstających dziennie przy kalkulacji nowych polis.
- Zmniejszyliśmy o rząd wielkości liczbę błędów przy rekalkulacjach starszych polis - a to dopiero początek naszych optymalizacji!
- Uzyskaliśmy niezależność aktuariuszy taryfowych przy wgrywaniu taryf.
Jakie technologie za tym stoją?
- Git
- Jenkins
- Groovy
- Helm
- Stack Sahul2(min.):
- Kubernetes
- Grafana
Liczby, tego projektu 
- Projekt rlx-core do zarządzania wgrywaniem taryf: 52 klasy, 3093 linie kodu i konfiguracji
- 220 usługi, 482+ pod.
- Rolling restart całego środowiska skrócony z ponad 2 godzin do 10 minut.
- Odzyskanie pojedynczej instancji: do 2 minut zamiast 35+ minut.
- 450 000+ żądań dziennie i z dnia na dzień rośnie.
- Konfiguracja środowiska produkcyjnego uproszczona z 3500 do 100 linii (Helm dla Helm).