RabbitMQ - jako część backendu w API przed zapisem do bazy danych?

Cześć,
Tytuł wątku może trochę pokręcony - już spieszę wyjaśnić w czym potrzebuję porady.

Założenia aplikacji są takie:

1. Aplikacja, to taki "core" spinający w logiczną całość mikroserwisy odpowiadające za API do user'a (test logger), zapis do bazy i kolejkowanie message'y w razie potrzeby.
2. Każdy z naszych zespołów testerskich, może dopisać swój API endpoint i backend wzorując się na ogólnym templat'e i podpiąć się łatwo i szybko do tego "core".
3. Może zajść potrzeba skalowania różnych elementów (API, workerów zapisujących do bazy).
4. Niby standard, przyznam jednak, że mając małe doświadczenie z takim uniwersalnym dla wszystkich API i chcąc zabezpieczyć się kolejką na wypadek dużego trafficu, przydałoby się móc skalować np. API albo workery w zależności od obciążenia.

Zastanawiam się nad taką "architekturą" składającą się upraszczając z 3-ech głównych punktów:

pt. 1. Frontend
Zajmujący się HTTP API, walidacją danych i przesyłaniem do kolejki. Chodzi mi po głowie zastosowanie na przykład: https://fastapi.tiangolo.com ale to jest chyba drugorzędna sprawa tutaj.

pt. 2. Kolejka / Message Broker:
Myślałem o zastosowaniu RabbitMQ. Każdy API endpoint będzie mógł mieć 1 (albo więcej) kolejkę, do której tylko wrzuca dane. Po wrzuceniu message'a do kolejki frontend ma wolne, a RabbitMQ współpracuje już tylko z workerem pt. 3.
Nie chce mi się pisać kolejkowania od zera, a RabbitMQ wydaje się prosty w obsłudze, skalowalny i ma nawet ładny dashboard.

pt. 3. Worker:
Czyli obsługujący konkretną kolejkę w RabbitMQ i wrzucający dane do "swojej" bazy danych. To jedyne zadania tej części.

Zalety tego rozwiązania jakie mi się nasuwają:

• skalowalność frontendów, które są bezstanowe - to tylko przekaźniki i cenzorzy :)
• skalowalnośc workerów - zależnie od trafficu, można zwiększać ich ilość per kolejka
• mniejsza ilość połączeń do bazy? 1 conncection/worker

Minusy:

• pada jeden element (environment fault, bug, etc.) to message giną w akcji...
• trochę to rozwlekłe, zastanawiam się czy zwykłe REST API by nie wystarczyło bez żadnych kolejek itp.

Pytania:

• krytyka mile widziana
• czy RabbitMQ ma tutaj jakieś zalety? Czy prościej, napisać zwykłą kolejkę np. w Javie, Pythonie i obsługiwać ja tymi workerami?
• czy w ten sposób niweluję delikatnie wąskie gardło jakim może być zapis do bazy danych (mam na myśli możliwość kolejkowania dużego trafficu)?

Ok, przeczytałem i nie rozumiem :) te kolejki to jest część aplikacji czy jakaś infrastruktura do testów automatycznych?

Każdy z naszych zespołów testerskich, może dopisać swój API endpoint i backend wzorując się na ogólnym templat'e i podpiąć się łatwo i szybko do tego "core".

Podasz jakiś przykład?

Może faktycznie namieszałem :)

TLDR;
Powiedzmy jeden zespół (albo więcej - zależy) używa jednego test frameworka i dziennie podczas pracy zapuszcza testy automatyczne, jakieś integracyjne, itp. Wynikiem pracy takiego test frameworka są logi: rezultat, błąd, czego dotyczy, dodatkowe logi z wykonania na testu.
Te logi z test frameworka wpadają do API, tu jakaś serializacja i zapis do bazy.
Zasada jest taka - na jeden test framework, jedno API oraz jedna baza. To śmiga w w clustrze Kubernetesa.

!! To istotne !!
Niby idea wygląda jak zwykłe REST API z samym zapisem danych. Jednak bazy mam PostgreSQL i jest z nich także częsty odczyt (Grafana).
Bazy mam PostgreSQL zarządzane tak... "że lepiej nic nie ruszać bo jeszcze zepsują" i obawiam się, że porady https://medium.com/futuretech-industries/ten-thousand-high-availability-postgresql-connections-for-35-mo-part-one-4b7a2d61c51e nie dotyczą tego projektu :)

Chciałem zatem u siebie w clustrze Kubernetesa postawić RabbitMQ aby z tych różnych API per "test framework" zbierał wszystkie logi, a następnie "Workery" na spokojnie przepisywały dane z kolejek w Rabbitcie do baz, nie zajmując zbyt wiele połączeń.

PS. Generalnie firma duża (ICT) i testów jest sporo. Stąd, aplikacja ma być na tyle elastyczna, że przychodzi jakiś zespół i mówi - "chcemy się podpiąć" i ja ich podpinam a oni są zadowoleni bo mają i zapis logów do bazy oraz wizualizację w Grafanie.

PS2. Mam coś podobnego zrobionego na MongoDB i w sumie działa bez żadnych kolejek, jednak z PostgreSQL nie miałem do czynienia jak chodzi o częste mielenie bazy odczytami i jednoczesnym zapisem. Niestety o replikach read-only i write-only ze względu na ww. nie mogę na razie marzyć.

Ja też mam kilka pomysłów, ale najpierw, jeżeli masz chwilę:

• Zakładam, że dane z testów będą tylko dodawane, nie będzie żadnych update-ów etc.?
• Będzie jakiś proces który będzie czyścił te dane z testów po konkretnym okresie czasu etc.? Jak często?
• Jak wygląda struktura tych danych z testów które będziesz wrzucał do bazy?
• Rozumiem, że Grafana będzie czytała dane z PostgreSQL. Jakie to będą zapytania? To się odnosi, do punktu 3 jak wygląda struktura tych danych.
• Macie coś jeszcze w stacku oprócz PostgreSQL i MongoDB jeżeli chodzi o składowanie danych?
• Jeżeli chodzi o MQ, to jesteście w chmurze? Masz dostęp do jakichś zarządzanych MQ?Jak postawisz tego Rabbit-a to sam nim będziesz musiał zarządzać?
• Wspomniałeś Grafane więc zakładam, że już macie doświadczenie w metrykach, macie jakieś dashboardy dla PostgreSQL z aktywnymi/nieaktywnymi połączeniami?
• Rozumiem że dostaniesz oddzielną bazę danych?Nie musisz jej dzielić z nikim itd?Jakie zasoby?

Zakładam, że dane z testów będą tylko dodawane, nie będzie żadnych update-ów etc.?

W 90% tak, z doświadczenia mojej firmy zdarzają się "maual verdicts" i komentarz co poszło nie tak. Jednak takie przypadki można obsłużyć dodatkową "tabelką" wiązaną po ID testu.

Będzie jakiś proces który będzie czyścił te dane z testów po konkretnym okresie czasu etc.? Jak często?

Większość danych ma termin do usunięcia 2 lata. Jeśli ktoś stwierdza, że będzie potrzebował tego do ML to mamy zapewnić 5 lat.

Jak wygląda struktura tych danych z testów które będziesz wrzucał do bazy?

Rzekłbym - struktura płaska, żadnych zagnieżdżeń w 90% większości przypadków. Zwykła tabelka - wiersze, kolumny nadaje się do zapisu takiego test werdyktu.

Rozumiem, że Grafana będzie czytała dane z PostgreSQL. Jakie to będą zapytania? To się odnosi, do punktu 3 jak wygląda struktura tych danych.

Z Grafaną mam tutaj najmniejsze doświadczenie, ale z pewnością robione są jakieś agregacje z sumowaniem i wyliczaniem średnich na bazie. Zdarza się też zapytywać o wartości z kilku tabelek jednocześnie do wyliczeń na jednym wykresie.

Macie coś jeszcze w stacku oprócz PostgreSQL i MongoDB jeżeli chodzi o składowanie danych?

Zdarza się ElasticSearch. Ja nie mam z tym nic wspólnego póki co :)

Jeżeli chodzi o MQ, to jesteście w chmurze? Masz dostęp do jakichś zarządzanych MQ?Jak postawisz tego Rabbit-a to sam nim będziesz musiał zarządzać?

RabbitMQ raczej musiałbym sam postawić i sam nim zarządzać. Z chmurą jest tak, że lada dzień ma nadejść nasza firmowa chmura, która jak się dowiedziałem - (3 node'y master i 4 slave) klaster Kubernetesa - a reszta to zrób to sam i nie wiem jeszcze jakie mocarne te node'y niestety. Póki co do developmentu mam 3 serwerki ok 8GB, którymi sam zarządzam. Ze względu na różne zaszłości historyczne jedziemy na Kubernetes z minikube... :( .

Wracając do MQ - zastanawiałem się, czy postawienie go na Dockerze (w sensie jeden RabbitMQ w dockerze na jedne API/Baza danych) nie byłoby dobrym pomysłem w moim przypadku.

Wspomniałeś Grafane więc zakładam, że już macie doświadczenie w metrykach, macie jakieś dashboardy dla PostgreSQL z aktywnymi/nieaktywnymi połączeniami?

Rozumiem, że aktywne połączenia to monitoring w Grafanie i ona prawie nie zwalnia?
Grafana dashboardy mają być ograniczona tylko wyobraźnią troubleshooter'ów.

Rozumiem że dostaniesz oddzielną bazę danych?Nie musisz jej dzielić z nikim itd?Jakie zasoby?

Jak wcześniej pisałem, jedno API to zwykle jedna baza danych PostgreSQL. Mam możliwość zamówienia MySQL. Bazy mam zarządzane, przypuszczam, że większość configu jest defaultowa, my zamawiamy tylko pojemność.
Struktura aplikacji jest taka, że baz będzie sporo, ale każda z danymi z innego kontekstu testów.

PS. Hmm :) nie jestem zadowolny z tego jak ten mój opis wygląda - dużo niewiadomych. Niestety wynika to z tego, że aplikacja ta jest takim PoC, które ma "zbawić świat". Ja chciałbym, żeby przynajmniej nie gubiło message'y do momentu zapisu do bazy przy dużym trafficu :)

Ciężko coś doradzić nie znając kontekstu. To mi wyglada jak jakiś wspólny dashboard dla testów automatycznych prowadzonych w rożny sposób. Rozumiem, że celem są metryki i ta Grafana. Może warto uspójnić podejście i rozszerzyć same narzędzia, aby wrzucały wyniki w określony sposób? Po co w tym wszystkim Rest API, skoro trzeba wepchnąć zawartość plików do bazy - nie może tego robić jakiś job w offline (np. Spark)? Albo jakoś przez ELK?