Sprawny Programista
Shares

Jak dalej skalować storage gdy wykorzystałeś już możliwe opcje?

Shares

Hej, dzisiaj chciałbym Wam opowiedzieć o tym jak skalować wasze źrodło danych, gdy wykorzystaliście już wszystkie dostępne możliwości, a dalej cierpicie ze względów wydajnościowych.

Dzisiejszy wpis oparty jest na moim doświadczeniu zebranym podczas pracy z ElasticSearchem. Jednak przedstawione tu wzorce skalowania równie dobrze aplikują się do innych rodzajów systemów, więc artykuł może być dla Ciebie przydatny, nawet jeśli nie korzystałeś nigdy z ElasticSearcha.

Wyobraź sobie, że tworzysz nową aplikację internetową. Koniecznie z wyszukiwarką. Chcesz, żeby wyszukiwarka była pełnotekstowa więc zamiast swojej SQL-owej bazy danych dodajesz ElasticSearcha. Twoi klienci mogą szybko wyszukiwać obiekty w Twoim systemie. Po czasie widzisz, że czasy odpowiedzi się wydłużają. Zagłębiasz się w dokumentację, czytasz. Masz rozwiązanie! Dodanie więcej maszyn. Robisz to i bum, service time spada. Udało się.

Niedawno z Twojej aplikacji zaczęli korzystać co raz więksi klienci. Po czasie widzisz, że niektóre maszyny mają dużo więcej danych niż pozostałe. Sprawdzasz co się dzieje. Okazuje się, że dane pojedynczego klienta trafiają zawsze na jedną maszynę. No tak, przypominasz sobie, że przy małej ilości danych to było preferowane podejście, które pozwalało serwować odpowiedzi w jak najkrótszym czasie.

Postanawiasz więc zmienić ustawienia storage-a i rozproszyć dane wszystkich klientów na różne maszyny. Teraz, żeby dostać dane pojedynczego klienta zapytanie musi trafić do wszystkich maszyn. Twój nowy, duży klient performuje o wiele lepiej. Ale Ci mniejsi, o wiele gorzej – czas potrzebny na odpytanie N maszyn, połączenie odpowiedzi i odesłanie okazuje się dłuższy niż w przypadku zapytań do jednej.

Mamy problem

No i utknąłeś. Z jednej strony dla dużych klientów rozproszenie danych na wiele hostów okazuje się lepsze. Z drugiej trzymanie małych klientów na pojedynczej maszynie daje krótsze czasy odpowiedzi. Co zrobić? Widzisz już rozwiązanie… ?

Multi-tenant ElasticSearch

Rozwiązaniem jest stworzenie dwóch różnych konifugracji dla dwóch różnych typów klientów. Duzi klienci powinni trafiać pod jeden klaster – gdzie dane jednego klienta są rozproszone na wiele maszyn. Zaś mali klienci powinni trafiać pod drugi klaster – gdzie dane jednego klienta zawsze lądują na jednej maszynie.

Właśnie to rozwiązanie zastosowaliśmy w 2016 roku w Base. W momencie, gdy zaczęliśmy obsługiwać co raz większych klientów nasze problemy wydajnościowe doprowadziły nas do tego punktu. Co więc się dzieje? Serwis wołając ElasticSearcha wie, dane którego klienta znajdują się na którym klastrze. W związku z tym zapytanie trafia do odpowiedniego z nich.

Problem polega jednak na tym, że serwisów korzystających z ElasticSearcha jest więcej niż 1. Co to oznacza?

W przypadku zmiany konfiguracji klastra, przeniesienia klienta który ma dużo danych na osobny klaster wiąże się z tym, że wszystkie serwisy wołające ElasticSearcha muszą się o tym dowiedzieć. Muszą też być przygotowane na sytuację, w której z jakiegoś powodu tylko część z nich otrzyma aktualizację i nie będzie świadoma, że powinna korzystać z innych klastrów.

ElasticProxy for the win!

W tym celu aby odciążyć serwisy od logiki związanej z konfiguracją stworzyliśmy ElasticProxy. Inteligentny router z dodatkowymi możliwościami, który stoi przed klastrami ElasticSearch-a i odpowiedzialny jest za odpowiednie kierowanie żądań do odpowiednich klastrów.

Klienty ElasticSearcha nie muszą być świadome fizycznej konfiguracji i lokalizacji danych, gdyż komunikują się teraz z nimi poprzez ElasticProxy.
Logika, która nie jest z biznesowego punktu widzenia ich odpowiedzialnością jest z nich wydzielona.

Newsletter

Hej, zaciekawiło Cię to co piszę? Jeśli tak, zapisz się do Newslettera, a nie przegapisz żadnego wpisu i będziesz dostawał wszystkie nowości wprost na swoją skrzynkę. Zero spamu, maile nie częściej niż raz w tygodniu 😉

Co oprócz routingu?

ElasticProxy dostarcza również inne funkcje. Jedną z nich jest circuit breaker. Dzięki niemu w przypadku dużego load-u na Elasticu, błędnych odpowiedzi, itp. nie wysyła kolejnych żądań.
ElasticProxy jest w stanie kierować ruch do mniej obciążanych w danym momencie nodów. Dodatkowo jest jednym miejscem konfiguracji – dzięku temu w przypadku jej zmiany, mamy pewność że wszystkie serwisy wysyłają zapytania do odpowiedniego klastra.
Teraz przeniesienie dużego klienta na bardziej wydajny klaster dzieje się dla nas transparentnie. Po migracji danych jedyne miejsce, które musimy zaktualizować to ElasticProxy. Klienty ElasticSearcha nawet nie mają pojęcia o tym, że coś się stało. Dzięki temu jesteśmy w stanie szybciej i sprawniej skalować dane naszych klientów.

Lesson learnt

Czasami, gdy wykorzystałeś już wszystkie możliwości skalowania, które daje Ci dana technologia musisz popatrzeć szerzej. Czasami proste rozwiązania – jak proxy, router – mogą być odpowiedzią na Twoje problemy. Mogą dać Ci również dodatkowe benefity, których nie miałbyś w innej sytuacji. Staraj się zawsze patrzeć na big picture i jeśli to rozwiąże Twoje problemy, zduplikuj system, który jest Twoim wąskim gardłem. Czasami lepiej przygotować dwa systemy o różnych konfiguracjach, niż jeden będący ich wspólnym mianownikiem.

Feedback

Hej, jak podobał Ci się ten wpis? Był ciekawy? A może wolałbyś poczytać o czymś innym? Daj znać w komentarzu, mailu. Dzięki Twojej opinii będę mógł lepiej dopasować tematy wpisów. Każdy komentarz będzie bardzo pomocny. Dzięki!

O autorze Dariusz Mydlarz

Cześć! Jestem programistą odkąd pamiętam, a zawodowo robię to od 2012 roku. Moim głównym językiem jest Java. Chciałbym dzielić się z Tobą moim doświadczeniem w świecie IT. Prywatnie jestem fanem piłki nożnej, mężem i tatą Michałka.

śledź mnie na:

Zanim odejdziesz... ;)

Hej! Zapisałeś się już do listy mailingowej? Dzięki niej dostaniesz krótką informację o nowym wpisie wprost na swoją skrzynkę! ;)

Zostaw komentarz: