Farma Flasków i HaProxy jako przykład load balancingu

Witam Was świątecznym nastrojem ;) Mimo ganiania za króliczkami, barankami i borówkami przedstawię Wam dziś dwie fajne rzeczy – Flaska i HaProxy.

We wpisie zajmiemy się tematyką load balancingu – czyli równoważenia ruchu – a więc rozwiązania problemu kiedy na naszą stronę dostajemy N requestów i to N jest o K za duże ;) a więc nasz serwer się nie wyrabia z ich obsługą.

Aby sytuację poprawić możemy na 3 „główne” sposoby:

1. Wkładamy wszędzie gdzie możemy cache – czyli odciążamy nasz serwer HTTP.
2. Skalujemy naszą infrastrukturę horyzontalnie – czyli dokładamy więcej podobnych serwerów.
3. Skalujemy wertykalnie – czyli do naszej jednostki dodajemy więcej RAMu, zmieniamy dysk na SSD itp.

My dziś zajmiemy się skalowaniem horyzontalnym. Ma ono swoje plusy:

• Jednostki są odseparowane od siebie – awaria jednej nie powoduje awarii całej naszej usługi
• Jednostki mogą być w różnych miejscach geograficznych – co znaczy że routing może być szybszy dla konkretnej lokalizacji
• Zawsze możemy dodać kolejny serwer – a w porównaniu do wertykalnego podejścia – nie zawsze dodamy więcej RAMu

Ale ma też wady – np. przechowywanie sesji użytkowników czy ewentualne problemy ze spójnością systemu itp – ale generalnie idzie się w tę stronę.

Problem pojawia się gdy chcemy osiągnąć sytuację w której ruch kierowany na naszą stronę jest dystrybuowany na każdy z naszych serwerów równomiernie:

I jak obrazek pokazuje – rozwiązaniem jest Load Balancer. Może on być software’owy lub hardware’owy. My dziś zajmiemy się, rzecz jasna, rozwiązaniem software’owym ;)

Zacznijmy od Flaska.. Flask to biblioteka Pythonowa która pozwala szybko i łatwo postawić serwer HTTP. Jest dość prosta i mała.

Zainstalować możemy ją pipem:

Flask w domyślnej konfiguracji jest synchroniczny a więc może przyjąć jednego klienta na raz.
Kawałek kodu który uruchomi nam taki serwer to:

Mapujemy funkcję hello na adres roota. Akcja będzie wykonywać się 5 sekund – sleep nam to zapewnia. Serwer będzie bindować się na wszystkich interfejsach i na porcie przekazanym jako argument.

Oczywiście Flask może przyjąć więcej niż jednego klienta jeśli poprawimy mu nieco konfigurację:

Parametr threaded będzie przekazany do werkzeug.serving.run_simple – czyli serwera który jest pod spodem Flaska. A z jego dokumentacji wiemy że parametr ten spowoduje przyjęcie każdego requesta w osobnym wątku:

Sprawdziłem to – działa.

Ale na potrzeby tego wpisu nie będziemy korzystać z tej opcji. Możliwość przyjęcia jednego klienta na raz zasymuluje nam sytuację w której mamy bardzo obciążony serwer HTTP.

Poza tym Flask ma też np. bardzo fajny tryb debuggera. Jeśli dodamy do konfiguracji debug:

To uruchamiając dostaniemy dodatkową informację:

I sprawimy że w obsłudze requesta zrobimy jakiś np. błąd który wyrzuci wyjątek to dostaniemy taki oto komunikat:

A jak klikniemy na małą ikonkę terminala i podamy PIN który dostajemy przy uruchomieniu to mamy interaktywną konsolkę gdzie możemy podejrzeć np. wartości zmiennych:

Super sprawa ;) ogólnie Flask ma sporo fajnych rzeczy – sesje, autoryzacje, template’ki.
Rzecz jasna biblioteka ta nie nadaje się na produkcję – służy raczej do developmentu.

Pobawiliśmy się Flaskiem a czas wrócić do głównego tematu. A więc mamy serwer HTTP który może przyjąć ograniczoną ilość połączeń. U nas to jest jedno połączenie. Nie zadowala nas to więc chcemy przeskalować naszą infrastrukturę horyzontalnie. A więc tworzymy 6 instancji Flaska :D Wpis dodajemy do supervisora (nie wiesz co to – przeczytaj):

I uruchamiany:

Ostatni proces to proces z poprzedniego wpisu. Nie patrzymy na niego. A więc mamy farmę Flasków :D na portach od 5001 do 5006 ;) Więc jak otworzymy w przeglądarce nasz IP z jednym z tych portów to po 5 sekundach (sleep) otrzymamy odpowiedź.

No i fajnie, mamy 6 takich serwerków, ale to każdy oddzielnie pozwala na przyjęcie jednego połączenia a My chcemy ruch przekierować do każdego z nich tak aby uzyskać możliwosć 6 jednoczesnych połączeń.

I tutaj wchodzi na scenę HaProxy. Jest to software’owy load balancer. Pozwala na rozdystrybuowanie ruchu na N serwerów.

Pracuję na CentOSie 6.5 – więc komendy instalacyjne mogą się nieco różnic, ale Internet bardzo szybko Wam podpowie jakie powinny być Was waszych dystrybucji.

HaProxy instalujemy:

Następnie edytujemy plik /etc/haproxy/haproxy.cfg. W tym pliku będzie cała konfiguracja naszego load balancera. Konfiguracja jest podzielona na kilka sekcji, więc pierw przejdziemy przez każdą sekcję a potem pokażę jak wygląda całość.
Sekcja global

Ustawimy w niej gdzie mają pisać się logi (/var/log/messages), maksymalną ilość połączeń, usera, grupę. Natomiast daemon uruchamia haproxy jako demona:

Makes the process fork into background. This is the recommended mode of
operation. It is equivalent to the command line „-D” argument. It can be
disabled by the command line „-db” argument.

Dalej mamy sekcję defaults:

Ustawiamy zdefiniowanego loga, tryb pracy na http, informacja na ten temat wyciągnięta z dokumentacji:

Right now, two major proxy modes are supported : „tcp”, also known as layer 4,
and „http”, also known as layer 7. In layer 4 mode, HAProxy simply forwards
bidirectional traffic between two sides. In layer 7 mode, HAProxy analyzes the
protocol, and can interact with it by allowing, blocking, switching, adding,
modifying, or removing arbitrary contents in requests or responses, based on
arbitrary criteria.

Oraz opcje httplog i dontlognull:

Enable logging of HTTP request, session state and timers

Enable or disable logging of null connections

retries to oczywiście ilość prób pogadania z serwerami zanim uzna się połączenie za nieudane. Przydatna opcja to redispatch:

In HTTP mode, if a server designated by a cookie is down, clients may
definitely stick to it because they cannot flush the cookie, so they will not
be able to access the service anymore.

Specifying „option redispatch” will allow the proxy to break their
persistence and redistribute them to a working server.

It also allows to retry last connection to another server in case of multiple
connection failures. Of course, it requires having „retries” set to a nonzero
value.

This form is the preferred form, which replaces both the „redispatch” and
„redisp” keywords.

If this option has been enabled in a „defaults” section, it can be disabled
in a specific instance by prepending the „no” keyword before it.

No i timeout’y:

timeout client – Set the maximum inactivity time on the client side.
timeout server – Set the maximum inactivity time on the server side.
timeout connect – Set the maximum time to wait for a connection attempt to a server to succeed.

To była typowa konfiguracja HaProxy. Teraz czas na nasz właściwy load balancer:
Sekcja frontend :

Tworzymy frontend o nazwie front który stoi na porcie 80 i jego domyślnym backendem jest backend o nazwie back.

Teraz dodamy backend:

opcja balance określa algorytm który będzie używany do wyboru serwera obsługującego żądanie. Tutaj mamy roundrobin. Inne możliwości jak i opis tej możecie zobaczyć w dokumentacji.

Sporo w tym wpisie odniesień do suchej dokumentacji, ale ciężko bez niej coś przedstawić rzetelnie. A nie widzę sensu przepisywania tego :P nie jest to kreatywne.

Dwie kolejne opcje to:

If „option httpclose” is set, HAProxy will work in HTTP tunnel mode and check
if a „Connection: close” header is already set in each direction, and will
add one if missing.

forwardfor – Enable insertion of the X-Forwarded-For header to requests sent to servers

Kolejne 6 linijek to już zdefiniowane servery backendowe – czyli nasze Flaski. Opcja check pozwala na monitoring ich „stanu zdrowia”.

Ostatnią sekcją jest listen:

Uruchamiamy tutaj statystyki HaProxy na porcie 1936 po adresem roota. Bez autoryzacji.

A więc całość wygląda tak:

Sprawdźmy teraz czy to działa. Użyjemy grequests (pip install grequests) czyli asynchronicznych żądań HTTP – żeby wywołać w tym samym czasie adres pod którym stoi HaProxy. Logi pokażą nam godzinę o której odpowiedź została wysłana.

Kawałek Pythona:

No i logi HaProxy:

Z logów można wywnioskować że przetworzono 6 requestów, każdy na innym serwerze (Flasku). Odpowiedź została odesłana z każdego Flaska w tym samym czasie.

A więc udało się nam przeskalować naszą infrastrukturę horyzontalnie. Dodaliśmy 5 serwerów i otrzymaliśmy liniowy wzrost efektywności – jesteśmy w stanie obsłużyć 6 requestów jednocześnie :)

Gdybyś wszedł na stronę gdzie swoi Twój HaProxy to za każdym F5 otrzymywał byś zwrot z innego serwera o czym informował by napis „Uruchomiono mnie na porcie 5001”, „Uruchomiono mnie na porcie 5002” itp.. ;)

Dla potwierdzenia w tym kodzie z grequests podałem adres do jednego flaska i oto logi z Flaska:

Każdy request jest od siebie oddalony w czasie o 5 sekund. Nie ma przetwarzania współbieżnego.

Super sprawa, nie? Poza tym warto zerknąć na staty:

Jeśli np. w supervisorze wyłączymy jeden z serwerów:

To HaProxy szybko to zauważy i odnotuje w statystykach:

Fajne statystyki, ale czasem też nie chcemy ich wystawiać na zewnątrz albo basic auth jest nie wystarczające. Wtedy możemy skorzystać np. z haproxyctl – takiej tam alternatywy w konsoli. Łudząco przypomina supervisorctl ;) ale w sumie to nie jest minus.

Tak czy siak poznaliśmy dziś sporo nowych rzeczy. A co ważniejsze, nowych i przydatnych.

HaProxy nie musi być tylko load balancerem. Zauważ proszę że w configu serwery podawałem po adresie lokalnym, więc nie musimy ich bindować na wszystkie interfejsy co podnosi poziom bezpieczeństwa.

Poza tym HaProxy wynosi na zewnątrz jeden port – port frontendu. Pozwala to np. na zmniejszenie progu wejścia w swoją aplikację, tzn jeśli nasza aplikacja ma poza HTTP jakieś websockety to czasem wymaga to otwierania portów u klientów co zazwyczaj jest problematyczne. Jeśli wszystko puścimy przez port 80 to nadal możemy mieć swoje N websocketów ale nie musimy nic u klientów otwierać.. :) czysty profit.

A więc tym zakończę wpis.. I wracam do baranków, króliczków i jajeczek.. ;)