Chaos Proxy - niestandardowy sposób na testowanie mikroserwisów

TLDR: Twoje mikroserwisy są podatne na nieoczekiwane awarie, jeśl inne usługi, od których są zależne, zawiodą (a Ty nic z tym nie zrobisz). Przetestuj swoje mikroserwisy HTTP przy użyciu "Chaos Proxy".

Stworzyłem już takie proxy, a znajdziesz je tutaj.

Chaos Engineering - Co to jest?

Netfliksowy Chaos Monkey jest w większości odpowiedzialny za popularyzację koncepcji Chaos Engineering.

Chaos Engineering to świetna sprawa - zautomatyzowane rozwiązanie/narzędzie, które losowo próbuje zepsuć system w jakiś sposób, aby ostatecznie dowiedzieć się, jak ten zachowuje się w takich sytuacjach. Następnie można wykorzystać nowo zdobytą wiedzę, aby znaleźć sposoby na zwiększenie odporności systemu na awarie w przyszłości.

Czym jest Chaos Proxy?

Chaos Proxy jest usługą, z którą mogą się połączyć Twoje mikroserwisy. Kieruje ruch do prawdziwych usług docelowych i zwraca odpowiedzi z powrotem do mikroserwisów przez serwer proxy. Ale robi to w bardzo zawodny sposób.

Za pośrednictwem serwera proxy żądania są losowo opóźniane i/lub losowo zawodzą w nieoczekiwany sposób. Wszystko to wyłącznie w celu zrozumienia, jak mikroserwis reaguje na różne warunki awarii.

Dlaczego ktokolwiek chciałby mieć nierzetelne proxy HTTP?

Wszystko w końcu zawiedzie. WSZYSTKO. Zaakceptuj to i przyjmij porażkę. Projektuj z myślą o awarii. Porażką osiągnij sukces.

Mikroserwisy często komunikują się z innymi usługami poprzez REST i HTTP. Jak radzą sobie Twoje mikroserwisy, skoro usługi, od których są zależne, nieuchronnie zawodzą w jakiś nieprzewidywalny sposób?

Źródło

W jaki sposób jest to przydatne?

Ostatnio badałem wyciek połączenia JDBC w mikroserwisie.

Przy nowoczesnych frameworkach wprowadzających abstrakcję nad operacje JDBC, przecieki połączeń nie powinny się wydarzyć, ale jednak doszło do takiej sytuacji.

Źródło

Chciałem ocenić, jak odporny był mikroserwis (A) na awarie i opóźnienia w innym mikroserwisie (B), od której była zależna. Potrzebowałem sposobu symulowania okresowych awarii i opóźnień w mikroserwisie "B", podczas gdy ja wykonywałem żądania i automatyczne testy regresji lokalnie w odniesieniu do mikroserwisu "A".

Miałem zdalny dostęp do mikroserwisu 'B', ale z powodu różnych ograniczeń, nie mogłem uruchomić 'B' lokalnie, aby spróbować go zmodyfikować w celu wyemitowania awarii. Nie mogłem znaleźć niczego, co byłoby lekkie, stosunkowo łatwe do ustawienia, i co pozwoliłoby mi osiągnąć to, co miałem nadzieję osiągnąć. Po krótkim dłubaniu, narodziła się pierwsza iteracja ClusterFk Chaos Proxy!

Dzięki ClusterFk Chaos Proxy byłem w stanie zidentyfikować, że przy wystarczająco opóźnionych odpowiedziach z mikroserwisu "B", połączenia JDBC w mikroserwisie "A" zaczynały się kumulować i pozostały otwarte tak długo, jak długo trwało żądanie HTTP - nawet jeśli transakcja JDBC była rzeczywiście od dawna zrealizowana.

Po poznaniu przyczyny otworzył się szereg możliwych rozwiązań problemu (i łatwy sposób na sprawdzenie ich skuteczności przez chaos proxy), np:

• Implementacja kontrolowanego limitu czasu na żądanie od "A" do "B".
• Implementacja limitu czasu połączeń JDBC i powrót do puli połączeń.
• Elementy przetwarzania asynchronicznego należy wykonać w taki sposób, aby wątek żądania skończył się szybciej.

ClusterFk Chaos Proxy

Tutaj znajdziesz ClusterFk Chaos Proxy na Githubie.

Założenie jest proste:

• Skonfigurować lokalnie działającą usługę którą chcesz testować, aby wskazać Chaos Proxy i skonfigurować Chaos Proxy, aby wskazać rzeczywistą, zależną od niej usługę.
• Włączyć ClusterFk Chaos Proxy i skonfigurować "strategię chaosu".
• Skorzystać z mikroserwisu (odpal do niego żądanie).
• Obserwować, jak świat się pali (poprzez monitorowanie logów lub poprzez zachowanie aplikacji).
• Opcjonalnie - nauczyć się od chaosu i wprowadzać zmiany, aby poprawić odporność swojego mikroserwisu.
• Powtórzyć całość.

Gdy pierwszy raz napisałem Chaos Proxy, nie byłem tak naprawdę świadomy jego koncepcji, ale zdecydowałem się dokończyć pierwszą iterację.

Od czego zacząć?

ClusterFk Chaos Proxy jest dostępne na DockerHub. Aby zainstalować, po prostu:

docker pull andymacdonald/clusterf-chaos-proxy

Następnie skonfiguruj plik docker-compose ze szczegółami usługi docelowej - np. jeśli usługa 'B' działa na http://10.0.0.231:8098:

version: "3.7"
services:
  user-service-chaos-proxy:
    image: andymacdonald/clusterf-chaos-proxy
    environment:
      JAVA_OPTS: "-Dchaos.strategy=RANDOM_HAVOC -Ddestination.hostProtocolAndPort=http://10.0.0.231:8098"
    ports:
      - "8080:8080"

Skonfiguruj strategię chaosu zgodnie z plikiem README.md projektu:

NO_CHAOS - Request is simply passed through

DELAY_RESPONSE - Requests are delayed but successful (configurable delay)

INTERNAL_SERVER_ERROR - Requests return with 500 INTERNAL SERVER ERROR

BAD_REQUEST - Requests return with 400 BAD REQUEST

RANDOM_HAVOC - Requests generally succeed, but randomly fail with random HTTP status codes and random delays

Potem po prostu wpisz: docker-compose up.

Po uruchomieniu aplikacji, możesz wskazać mikroserwisy, które chcesz przetestować w instancjach ClusterFk Chaos Proxy (zamiast rzeczywistych usług docelowych). Następnie wystarczy odpalić mikroserwis i rozpocząć testowanie i korzystanie z niego.

Proxy będzie stosować wybraną strategię w stosunku do żądań, które do niego wysyłasz. Prawdopodobnie najbardziej użytecznymi strategiami są RANDOM_HAVOC i DELAY_RESPONSE - ale inne również mogą okazać się przydatne.

Więcej funkcji oraz możliwości konfiguracji zostanie dodanych w przyszłości!

Dzięki za przeczytanie! ?

Mam nadzieję, że podobał Ci się ten artykuł i wprowadzenie do koncepcji Chaos Proxy.

Chociaż wykorzystałem tu swój własny projekt, koncepcja jest niezwykle prosta do zrealizowania. Zapraszam Cię do skorzystania z mojego projektu i rozszerzenia go lub po prostu wykonania własnej implementacji!


Oryginał tekstu w języku angielskim przeczytasz tutaj.