Aplikacje biznesowe

Dobre perspektywy dla optymalizacji aplikacji

Dobre perspektywy dla optymalizacji aplikacji

Niezawodność i wydajność środowisk aplikacyjnych można osiągać na wiele sposobów. W krótkiej perspektywie zwykle wystarczy rekonfiguracja. W średniej trzeba trzeźwo ocenić architekturę i nie bronić się przed jej poważniejszą optymalizacją. W dłuższej perspektywie opłaca się wykorzystywać dorobek świata open source oraz nowatorskie platformy bazodanowe i serwerowe, zoptymalizowane pod kątem konkretnych typów przetwarzania i scenariuszy skalowania.

 
Architektury środowisk aplikacyjnych ewoluują pod wpływem zmieniających się wymagań użytkowych. Jeszcze nie tak dawno środowiska aplikacyjne miały prawo do okien serwisowych czy backupowych. To już jednak historia. Aplikacje, tak jak serwisy w Internecie, mają działać non stop, a do tego wydajnie – nawet jeśli liczba użytkowników lub ilość danych zwiększy się w krótkim czasie o kilka rzędów wielkości. Dostosowanie się do tych okoliczności wymaga zmian we wszystkich warstwach środowisk: aplikacjach, bazach danych, narzędziach, a nawet w samej infrastrukturze. Nie chodzi wyłącznie o technologię. Świeżego spojrzenia wymagają także modele licencjonowania oprogramowania oraz warunki usług wsparcia i serwisu. Z punktu widzenia klientów, środowiska aplikacyjne stanowią całość, dlatego ich optymalizacja również musi być całościowa.

Skalowanie i dostępność zawsze w duecie

Większość aplikacji biznesowych opiera się na relacyjnych bazach danych. Niezawodność takim środowiskom zapewniały dotychczas mechanizmy klastrowe, łączące funkcje działające na poziomie systemu operacyjnego i serwera bazy danych. Taka metoda zapewnienia wysokiej dostępności ma jednak poważne ograniczenia w dziedzinie skalowania, związane m.in. właśnie z brakiem wyraźnej separacji warstw. Przy średniej skali z pomocą przychodzi wirtualizacja, pozwalająca wykonywać spójne kopie nie tylko baz danych, ale całych środowisk, i nie raz dziennie, a np. co 10 minut. Wirtualizacja stawia jednak określone wymagania wobec infrastruktury serwerowej.


„Większość aplikacji biznesowych opiera się na relacyjnych bazach danych. Niezawodność takim środowiskom zapewniały dotychczas mechanizmy klastrowe (…). Taka metoda zapewnienia wysokiej dostępności ma jednak poważne ograniczenia w dziedzinie skalowania (…). Przy średniej skali z pomocą przychodzi wirtualizacja (…), [która] stawia jednak określone wymagania wobec infrastruktury serwerowej”


Wysoka dostępność realizowana za pomocą wirtualizacji wymaga serwerów o większych zasobach. Na jednym, standardowym serwerze dwuprocesorowym można realnie zmieścić kilka maszyn wirtualnych, nie ma jednak specjalnie miejsca na wzrost. Większe maszyny pozwalają na budowanie partycji logicznych, wydajnych klastrów wirtualnych i innych „konstrukcji”, zapewniając jednocześnie przestrzeń niezbędną z punktu widzenia wzrostu potrzeb. Wirtualizacja pociąga za sobą także potrzebę stosowania dużej ilości pamięci RAM. To najtańszy sposób na zwiększenie wydajności, wspierający jednocześnie cel w postaci wysokiej dostępności, np. wydajne wykonywanie klonów logicznych.

Oprócz tego, z praktyki projektowej wiadomo, że serwery baz danych działające w środowiskach zwirtualizowanych dobrze jest konfigurować w taki sposób, by mogły wykorzystać wiele procesorów logicznych wydzielonych z odrębnych procesorów fizycznych. W ten sposób wielowątkowe z natury serwery baz danych są w stanie lepiej wykorzystać dostępne zasoby sprzętowe, osiągając większą wydajność. Jak widać, jedna decyzja dotycząca architektury pociąga za sobą bardzo wiele konsekwencji. Zachęcam do prowadzenia tego rodzaju analiz przed podejmowaniem decyzji projektowych. Patrząc na środowiska całościowo, środki na optymalizację środowisk można spożytkować znacznie lepiej.

Z myślą o prawdziwej megaskali

Wirtualizacja to coś, co sprawdza się w środowiskach średniej wielkości. Duża skala aplikacji wymaga poważniejszego przemyślenia architektury. Przede wszystkim, trzeba zastanowić się, czy duża skala usprawiedliwia wykorzystanie dotychczasowej technologii bazodanowej, zarówno od strony technicznej, jak i kosztowej. W ostatnich latach nastąpił gwałtowny rozwój platform bazodanowych do zastosowań transakcyjnych, analitycznych, oraz składowania dużych ilości danych obiektowych. Większość z nich dostępnych jest na zasadach open source, co umożliwia obniżenie kosztów skalowania, a jednocześnie kosztów wsparcia. Kwoty za wsparcie są niższe o całe rzędy wielkości, a jednocześnie możliwości funkcjonalne i wydajność tych platform są naprawdę imponujące.


„Trzeba zastanowić się, czy duża skala usprawiedliwia wykorzystanie dotychczasowej technologii bazodanowej, zarówno od strony technicznej, jak i kosztowej. W ostatnich latach nastąpił gwałtowny rozwój platform bazodanowych do zastosowań transakcyjnych, analitycznych, oraz składowania dużych ilości danych obiektowych. Większość z nich dostępnych jest na zasadach open source”


Migrowanie tradycyjnych baz danych do środowisk otwartych – i nie zawsze relacyjnych – zaczyna wyglądać na trend. Z moich doświadczeń wynika, że projekty tego rodzaju mają kilka etapów. Pierwszy z nich to zwykle „ucieczka” ze starej wersji bazy danych działającej na od dawna już nie wspieranej platformie – do tej samej lub nowszej wersji, działającej w środowisku bardziej „bieżącym”. Gdy obawy związane z pierwszą migracją zostają opanowane, klienci nabierają apetytu na dalsze optymalizacje. W kolejnym etapie baza zostaje zastąpiona platformą open source. Mało osób w Polsce wie, że Bull stworzył wiele unikalnych narzędzi do migracji baz danych między różnymi silnikami i platformami. One są bardzo pomocne w tego rodzaju projektach. W kolejnym kroku całość lub część danych można przenieść do dowolnej innej bazy, np. jednej z wielu baz klasy NoSQL, zoptymalizowanej pod kątem szybkiego dostępu, analiz czy innych potrzeb.

Efektywne skalowanie jest jednym z kluczowych celów migracji baz danych. Na poziomie szczegółowym celem może być uruchomienie przetwarzania na znacznie większej liczbie procesorów, bez potrzeby wnoszenia wysokich opłat licencyjnych i opłat za wsparcie, naliczanych właśnie na podstawie liczby procesorów i rdzeni. Celem migracji może być zmiana modelu danych z wierszowego na kolumnowy, z relacyjnego na obiektowy, a w zasadnych przypadkach np. na grafowy. Może nim być także przeniesienie przetwarzania do pamięci RAM, np. w celu uwolnienia się od wysokich kosztów starej platformy pamięci masowych. Na rynku są platformy pozwalające zmieścić w pamięci bazy rzędu nawet powyżej 20 Terabajtów, i to bez kompresji danych.

Aplikacje pod lupą

Kolejnym scenariuszem zwiększania niezawodności i wydajności środowisk aplikacyjnych jest wykorzystanie technologii i platform superkomputerowych. Znając charakterystykę działania aplikacji, jej fragmenty można przepisać w taki sposób, by potrafiła wykonywać przetwarzanie na wielu serwerach jednocześnie. Przetwarzanie równoległe sprawdza się w przypadku masowego wielodostępu do danych, złożonych obliczeń, przeszukiwania lub analizy bardzo dużych zbiorów danych, a także wtedy, gdy ważna jest natychmiastowa reakcja lub uruchomienie procesu na podstawie automatycznego monitorowania. Chodzi w szczególności o subskrypcję zdarzeń, wykrywanie nieprawidłowości, analizy czasu rzeczywistego itp. wzorce.


„Precyzyjne rozpoznanie charakterystyki aplikacji jest kluczowe dla powodzenia wszelkich działań migracyjnych. Dokumentacja dostarcza zwykle jedynie wstępnych wskazówek. Jedynym sposobem przejścia od podejrzeń do precyzyjnej wiedzy jest profilowanie aplikacji za pomocą dedykowanych narzędzi”


Precyzyjne rozpoznanie charakterystyki aplikacji jest kluczowe dla powodzenia wszelkich działań migracyjnych. Dokumentacja dostarcza zwykle jedynie wstępnych wskazówek. Jedynym sposobem przejścia od podejrzeń do precyzyjnej wiedzy jest profilowanie aplikacji za pomocą dedykowanych narzędzi. Na przestrzeni ostatnich 30 lat Bull stworzył liczne pakiety oprogramowania do aktywnego generowania obciążeń i obserwowania działania aplikacji pod ich wpływem. W ten sposób można badać limity obciążeń, połączeń, szacować możliwości  istniejącego środowiska pod kątem wydajności i stabilności, wykrywać nieefektywności kodu i implementacji. Dzięki temu, że dysponujemy dużym laboratorium, możemy testować nowe wersje aplikacji i całych środowisk, także w różnych konfiguracjach architektury, np. klastrów, jak i dużych maszyn SMP. Efekty takich testów bywają bardzo pouczające, zarówno dla administratorów, jak i deweloperów.

Najciekawsze są jednak porównania wynikające z wprowadzania nowoczesnych silników do zarządzania danymi. Pokazują, że w dziedzinie technologii postęp potrafi czasem zdziałać prawdziwe „cuda”. To, co wydawało się niemożliwe, staje się nagle możliwe. Zastosowanie nowoczesnej architektury aplikacji w połączeniu z dedykowaną dla określonego zastosowania bazą danych oraz odpowiednio dobraną architekturą serwerowo-sieciowo-dyskową pozwala zwiększyć wydajność nawet o kilka rzędów wielkości. I wcale nie oznacza konieczności wydania na ten cel wielkich kwot. Pod względem stosunku nakładów do efektów, inwestycja w czas inżyniera to najlepiej wydane środki. Jak na razie, w rozwiązywaniu złożonych zagadek optymalizacyjnych ludzie wciąż są mocniejsi, niż komputery.

Krzysztof Mikołajczyk, inżynier odpowiedzialny za projekty migracyjne i architekturę systemów w Bull Sp. z o.o.
Krzysztof Mikołajczyk

 
Autor jest inżynierem odpowiedzialnym za projekty migracyjne i architekturę systemów w Bull Polska Sp. z o.o.