Awarią w awarię

Skoro awarie aplikacji są nie do uniknięcia, należy zrezygnować z ich doskonalenia i skupić się na szybkim odtwarzaniu - mówią twórcy koncepcji ROC - Recovery Oriented Computing.

Skoro awarie aplikacji są nie do uniknięcia, należy zrezygnować z ich doskonalenia i skupić się na szybkim odtwarzaniu - mówią twórcy koncepcji ROC - Recovery Oriented Computing.

Mimo wielkiego postępu w dziedzinie technologii, oprogramowanie nie jest dziś ani trochę mniej zawodne niż kilkanaście lat temu. Nie może jednak być inaczej - powszechne wykorzystanie informatyki to tak naprawdę zgoda na tworzenie aplikacji użytkowych pod presją czasu i niekoniecznie przez dbających o detale, zapalonych doktorantów. Na przestrzeni lat informatyka stosowana wykształciła zresztą całą paletę mechanizmów obronnych przed niską jakością kodu. Klastry, mechanizmy współdzielenia obciążenia, transakcyjne bazy danych, rozwiązania backupowe, wielkie serwery SMP, wirtualizacja i inne wynalazki pozwalają użytkownikom korzystać, a nawet czerpać wymierne korzyści z "dzieł" informatycznych, które pod względem konstrukcyjnym urągają zdrowemu rozsądkowi, a co dopiero standardom akademickim.

Tempo powstawania nowego kodu jest obecnie znacznie większe niż tempo wykrywania w nim błędów i nic nie wskazuje, by coś miało się w tej materii zmienić na lepsze. Oznacza to ni mniej ni więcej, że dotychczasowe sposoby obchodzenia złej jakości oprogramowania mogą się wkrótce okazać niewystarczające - stosunek błędów do poprawnego kodu będzie się stale pogarszać. Wiedząc to, naukowcy w czołowych ośrodkach akademickich starają się wypracować nowy model budowania i eksploatowania systemów informatycznych, w którym błędy, awarie, stany niestabilności, zapętlenia i inne przypadłości oprogramowania traktowane są nie jak tragedia, lecz jak jego naturalna cecha.

Awaria zamiast ''problemów''

Najnowsze badania prowadzone wspólnie przez University of Berkeley i Stanford University odrzucają doskonalenie oprogramowania jako sposób na podniesienie jego niezawodności. Upatrują go raczej w tym, by komponenty, które zdradzają choćby drobne symptomy niestabilności, można było bezpiecznie wyłączyć i błyskawicznie uruchomić ponownie - tak by skutki wyłączenia były niezauważalne dla użytkowników. Co ciekawe, eksperymenty i badania empiryczne wstępnie potwierdzają słuszność tego kierunku myślenia. Koncepcja ROC - Recovery Oriented Computing ma już pierwsze implementacje i jakkolwiek do jej powszechnego stosowania jeszcze długa droga, warto wiedzieć, czego można się po niej spodziewać.

Sednem koncepcji ROC nie jest technologia, lecz pewne ustalenia czynione na etapie projektowania oprogramowania. Założeniem podstawowym jest to, że działające oprogramowanie może zostać zatrzymane jedynie w trybie awaryjnym i przywrócone do pracy jedynie przez proces odtwarzania po awarii. To dość oryginalne stwierdzenie ma, wbrew pozorom, sens. Jeżeli bowiem to, że aplikacja może ulec awarii, jest uznawane za wysoce prawdopodobne, powinna ona być gotowa na awarię w każdym czasie, a to z kolei ma określone konsekwencje dla jej konstrukcji.

Aplikacja z dzienniczkiem

Współczesne aplikacje tworzy się z myślą o optymalizacji wydajności. Wydajność oznacza m.in. to, że w dowolnym czasie stan aplikacji i jej dane są przechowywane w pamięci RAM. Oznacza również, że komponenty aplikacji są ze sobą ściśle powiązane. Dzięki temu rzeczywiście jest szybciej, ale awaria może oznaczać katastrofę: problematyczne może okazać się nie tylko ponowne uruchomienie nagle wyłączonej aplikacji, ale także odzyskanie przetwarzanych przez nią danych.

Naukowcy z Berkeley i Stanforda twierdzą, że odporność aplikacji na awarie można podwyższyć, wprowadzając częstą rejestrację jej stanu w sposób trwały. Proponują przy tym, by logikę biznesową całkowicie oddzielić od mechanizmów przechowujących informacje o jej stanie, które mogą być składowane w pliku dziennika, obiektowej lub relacyjnej bazie danych itp. W zamyśle autorów koncepcji ROC awaria źle napisanej logiki nie będzie mieć wpływu na spójność danych o jej stanie, to zaś umożliwi znacząco szybsze odtworzenie jej do normalnego działania.

Postulat podziału oprogramowania na logiczne całości idzie dalej i głębiej - aż do poziomu poszczególnych obiektów, które według założeń ROC powinny być od siebie maksymalnie niezależne. Zapisywanie stanu poszczególnych obiektów oddzielnie ma fundamentalne znaczenie dla całej koncepcji - oznacza bowiem, że w każdej chwili można wyłączyć dowolny komponent aplikacji i przywrócić go do działania ze stanem zapisanym w repozytorium.

Ponieważ spójny stan komponentu jest zawsze na podorędziu, nie ma problemu, by wyłączać i odtwarzać komponent tak często, jak często będzie on zachowywać się wbrew przewidzianemu scenariuszowi, np. czas odpowiedzi na wywołanie przekroczy określony próg lub gdy zacznie zachowywać się niestabilnie itp. W skrajnym przypadku komponenty można restartować "dla zasady" po upłynięciu pewnego czasu od ich ostatniego uruchomienia.

Jedną z ważniejszych konsekwencji zastosowania koncepcji ROC w praktyce jest ograniczenie możliwych zachowań aplikacji do dwóch: pracy prawidłowej lub awarii. Tym samym zabezpieczanie aplikacji staje się prostsze, bo nie ma potrzeby przewidywania (i zawierania w kodzie funkcji na wypadek) nieprzewidywalnych stanów pośrednich.

Nic na zawsze

Twórcy koncepcji ROC przewidzieli, że pomimo skrócenia czasu wyłączania i odtwarzania, komponent będący ich przedmiotem przez pewien czas nie jest dostępny dla komunikujących się z nim innych komponentów. Proponują np., by mechanizm zarządzający włączaniem i wyłączaniem informował inne komponenty o przewidywanym czasie zakończenia restytucji uruchamianego właśnie komponentu. Czas ten może być określony w ramach ustawień globalnych aplikacji lub też dynamicznie - z uwzględnieniem historii lub aktualnego obciążenia zasobów.

Uzupełnieniem tego mechanizmu jest obowiązkowe nadawanie każdemu komunikatowi maksymalnego czasu ważności (TTL). Po jego upłynięciu komponent inicjujący może - w zależności od ustawień globalnych lub własnych - wysłać komunikat ponownie określoną liczbę razy lub poinformować swój komponent nadrzędny i/lub menedżera obiektów, że określony obiekt nie odpowiada. Dodatkowym zabezpieczeniem na wypadek "nieosiągalności" jakiegoś komponentu jest założony z góry brak przypisywania zasobów komponentom na stałe, lecz jedynie ich wypożyczanie na skończony okres czasu.

Praca wre, granty płyną

Koncepcja ROC doczekała się już pierwszych implementacji. Na środowisko eksperymentalne składają się dostępne na licencjach open source serwery aplikacji J2EE. Jako repozytorium stanów wykorzystywane są bazy danych Berkeley DB oraz PostgreSQL. Co ciekawe, prace nad koncepcją ROC finansuje IBM i Microsoft. Źródłem pogłębionej, aktualnej informacji dla Czytelnika mogą być dokumenty zamieszczone na stronie George'a Candea (http://www.stanford.edu/~candea/papers.html ).

W artykule wykorzystano informacje zawarte w pracach publikowanych przez G. Candea i A. Foxa z Uniwersytetu Stanforda oraz D. Pattersona z Uniwersytetu Berkeley.

W celu komercyjnej reprodukcji treści Computerworld należy zakupić licencję. Skontaktuj się z naszym partnerem, YGS Group, pod adresem [email protected]

TOP 200