Czy IT ma szanse być “Green”?

Data: 2013-02-05
Autor: Sebastian Konkol

Ostatnia dekada charakteryzowała się zwiększeniem nacisku na ekologię. Podwyższanie restrykcyjności norm emisji spalin, niemalże wymuszanie wykorzystywania odnawialnych źródeł energii, budownictwo pasywne, a nawet Green IT. O ile w sferze motoryzacji i budownictwa widać rzeczywiste zmiany, o tyle w sferze IT mam poważne wątpliwości. I nie chodzi o brak podejmowania rzeczywistych działań, ale o nakładanie się dwóch trendów rozwoju informatyki, od sprzętu po aplikacje.

Wpływ pierwszego trendu jest oczywisty – o Green IT mówi się wiele i robi się wiele. Sprzęt komputerowy zmierza do minimalizacji zapotrzebowania na energię elektryczną. Zmieniają się standardy pracy urządzeń w centrach przetwarzania danych – podwyższane są dopuszczalne temperatury pracy obniżając znacznie zapotrzebowanie na klimatyzację. Duże centra przetwarzania danych budowane są w miejscach, w których właściwą temperaturę i wilgotność pracy urządzeń udaje się uzyskać bardziej naturalnymi metodami – chłodniejsze tereny, dostęp do chłodzenia w rzekach górskich czy dzięki wiatrowi. Można powiedzieć, że zapotrzebowanie na energię elektryczną w przeliczeniu na MIPS (milion instrukcji na sekundę) maleje. Czyli dobrze.

Drugi trend jest jednak znacznie mniej oczywisty, a jego wpływ subtelny jakościowo, ale znaczący ilościowo. Ten drugi trend polega na generalizacji infrastruktury i specjalizacji aplikacji. W dużym uproszczeniu – jeśli przyjąć, że systemy informatyczne tworzone są warstwowo (sprzęt, systemy operacyjne, platformy aplikacyjne i aplikacje) – warstwy niższe stają się bardziej ogólne, aby móc wypełniać coraz bardziej zróżnicowane zapotrzebowania warstw wyższych. Ekonomicznie ma to głębokie uzasadnienie – potencjalna zmienność lokowana jest w oprogramowaniu, gdzie koszty wprowadzania zmian są znacznie niższe, niż w sprzęcie. Czyli niby też dobrze. Dlaczego „niby”? Posłużę się kilkoma przykładami wprowadzającymi.

  • Karta graficzna. Jest w każdym komputerze, w zasadzie bez względu na to, czy jest to terminal użytkownika, czy serwer. W rzeczywistości jest to procesor arytmetyczny o mocy obliczeniowej wielokrotnie przewyższającej moc obliczeniową tzw. procesora centralnego. Dlaczego tak jest? Bo obróbka grafiki, gdyby zrzucić ją na ten procesor centralny, zamuliłaby tenże procesor dowolnej konstrukcji. Tu jest specjalizacja, bo inaczej nie dałoby się obrabiać grafiki.
  • Deep Blue. To ten superkomputer, który wygrał turniej szachowy z Kasparowem. A jednak mało ludzi wie, że jego konstrukcja miała bardzo niewiele wspólnego z konstrukcją systemów komputerowych powszechnie stosowanych. W jego skład wchodziło 256 specjalizowanych modułów sprzętowych zaprojektowanych wyłącznie w celu gry w szachy (co znaczące, wcale nie przez IBM). Gdyby Deep Blue skonstruować tak, jak współczesne systemy komputerowe, czyli stosując obliczenia realizowane przez generyczny procesor centralny, partia szachów trwałaby tysiące lat – tak niewydolne byłoby to rozwiązanie dla problemu „wygrać w szachy z człowiekiem”.
  • Sprzęt sieciowy. Switch, router, load balancer to takie urządzenia, które realizują określone zadania w komunikacji między komputerami. Oczywiście, dla każdego z nich daje się wytworzyć rozwiązanie działające na generycznym sprzęcie komputerowym – implementacje w oprogramowaniu dla routera, load balancera są dostępne. Jednak świat korzysta z implementacji sprzętowych, bo – w odróżnieniu od tych w oprogramowaniu – dają sobie one radę z rosnącą skalą wymiany danych.
  • Specjalizowane peryferia. W czasie studiów (to już dwie dekady temu…) miałem zaszczyt uczestniczyć w projekcie tworzenia systemu kryptograficznego, którego celem była sprzętowa implementacja RSA w oparciu o krzywe eliptyczne. Pomijając skalę trudności tego projektu oraz moją dumę z jego efektów i mojego w nim udziału, całość systemu kryptograficznego zapewniającego bezpieczeństwo znacznie wyższe, niż obecnie osiągalne w implementacjach oprogramowania, mieściła się w 16 kB pamięci ROM i była w stanie szyfrować z taką sprawnością, że nawet współczesne wymogi przesyły potokowego nie były dla niej straszne.

Wszystkie te przykłady pokazują, że „ślepe” dążenie do rozwiązywania problemów w modelach uogólnionych, przy wykorzystaniu systemów generycznych skutkują wzrostem zapotrzebowania na moc obliczeniową o rzędy wielkości, a czasami wręcz nie dają się rozwiązać przy wykorzystaniu takich modeli i systemów. Te przykłady nie są wcale odizolowane – reguły generalizacji są wprowadzane do wszystkich warstw tworzenia rozwiązań informatycznych, a każde takie wprowadzenie, poza ułatwieniem dla programistów czy administratorów lub skróceniem time-to-market skutkuje utratą kolejnej porcji mocy obliczeniowej.

  • Wirtualizacja. Współczesne systemy informatyczne są oddzielane od sprzętu, na którym działają za pomocą narzędzi wirtualizacji. Taki krok zapewnia wygodę zarządzania, bo można przydzielać zasoby sprzętowe pomiędzy wiele różnych instancji systemów operacyjnych. Stanowi także ułatwienie i przyspieszenie reakcji na zmiany zapotrzebowania na zasoby obliczeniowe. Dzieje się to jednak kosztem ok 20% mocy obliczeniowej, która jest wykorzystywana przez oprogramowanie do wirtualizacji.
  • Systemy operacyjne. Podstawowym elementem ich konstrukcji, zarówno w przypadku terminali użytkownika, jak i serwerów, jest graficzny interfejs użytkownika. Takie GUI potrafi pochłonąć nawet 80% mocy obliczeniowej sprzętu. Nie widzimy tego, dzięki istnieniu karty graficznej. Kiedy zaczynałem moją przygodę z Unixem, pracowałem na serwerze mojej Wspaniałej Uczelni (liszt.tele.pw.edu.pl). Obsługiwał on serwer relacyjnej bazy danych, na której niemalże ciągle pracowało 20 studentów żądnych tworzenia i kasowania tabel oraz testowania szybkości wyszukiwania. Mój obecny notebook ma bez wątpienia większą moc obliczeniową, skutecznie „wykorzystywaną” przez wingrozę.
  • Platformy aplikacyjne. Systemy informatyczne tworzy się teraz w oparciu o platformy aplikacyjne, które zapewniają programistom komfort niemyślenia – „dbają” o cały szereg aspektów tworzenia oprogramowania, od zarządzania pamięcią operacyjną po frameworki GUI. Takie rozwiązania to jednak nie tylko języki programowania ogólnego zastosowania, nie tylko składnia ale także środowisko wykonawcze. Kiedy pisałem kod w C++ sam musiałem zadbać o to, żeby nie mieć „wycieków” pamięci operacyjnej (trzeba było dużo myśleć), ale wykonanie takiego kodu generowało minimalny narzut wykonawczy (operatory new i delete realizujące sprawnie funkcje systemu operacyjnego). W środowisku wykonawczym Java programista nie musi troszczyć się o takie „duperele”, jak gospodarka zasobami systemu. Jest to możliwe, gdyż – dla jego wygody – w środowisko wykonawcze Javy został wbudowany specjalizowany proces porządkujący po programiście (garbage collector) – dodatkowy, stały „wyciek” mocy obliczeniowej.
  • Relacyjne bazy danych. Jeszcze dekadę temu stosowanie ich było wyznacznikiem wagi systemu – dołączenie RDBMS do architektury systemu oznaczało, że jest to ważny system realizujący ważne zadania. Dzisiaj MySQL, PostgreSQL, SQLite stosowane są niemal w każdym przypadku danych strukturalnych, bo tak jest łatwiej. Co prawda koszt (w znaczeniu wykorzystywanych zasobów) dostępu do takich danych jest o kilka rzędów wielkości większy, niż do pliku płaskiego, ale tak jest wygodniej dla programisty.

Co gorsza, wydaje się, że informatyka stosowana przeżywa okres wtórnego analfabetyzmu. Obecnie niemal wszystko pisze się w środowiskach Java lub .NET. To bardzo wygodne dla programisty, bo znana składnia i zasady tworzenia aplikacji, a także wygodne dla inwestującego w oprogramowanie, bo może skorzystać z dużej puli programistów znanych języków, a skoro ich dużo, to stawki są niższe. Efekt skumulowany jest jednak taki, że kultowa najprostsza aplikacja „Hello World!” wymaga dzisiaj mocy obliczeniowej porównywalnej z kompilatorem sprzed 20 lat. Pomijam już wielkość przestrzeni dyskowej i pamięci operacyjnej koniecznych dla uruchomienia takiej trywialnej aplikacji.

Żeby nie operować przykładami trywialnymi, przytoczę przykład bardzo profesjonalny. Mój dobry znajomy „po fachu” uczestniczył w tworzeniu oprogramowania zarządzającego najlepszą obecnie implementacją urządzenia SGSN (Leszek, szacun!). Ta implementacja realizowana była w języki programowania, który nazywa się Erlang. To specjalizowany język do tworzenia systemów współbieżnych z silnie komunikującymi się procesami. Dlaczego? Bo sposób wykorzystania zasobów sprzętowych przez oprogramowanie utworzone w Erlangu jest o kilka rzędów wielkości efektywniejszy, niż realizacja dokładnie tej samej logiki aplikacji w języku ogólnego zastosowania, np. Java. Mówiąc w skrócie, taka aplikacja w Javie po prostu nie działałaby.

Do czego zmierzam? Ten drugi trend powoduje, że jakość wykorzystania mocy obliczeniowej spada dramatycznie. Gdyby przyjąć miarę liczby MIPS na „standaryzowaną” operację aplikacji rośnie wykładniczo, a powodami są uogólnienia i generalizacje w każdej z warstw połączone z brakiem refleksji nad doborem narzędzi do rozwiązania problemu. W konsekwencji Green IT staje się raczej fikcją, bo wszelkie wysiłki zmierzające do obniżenia zapotrzebowania na energię elektryczną są zaprzepaszczane w związku z rozrzutnością wykorzystania mocy obliczeniowej przez wszystkie warstwy wyższe.

Podobne wnioski dotyczą wszystkich zasobów, jakie wykorzystywane są przez współczesne systemy informatyczne – pamięć operacyjna, przestrzeń dyskowa, transfer sieciowy, żeby wymienić tylko te podstawowe. Języki programowania C/C++ czy Erlang, realizacja części funkcji w sprzęcie to nie przeżytki, stali rezydenci muzeum techniki – to bardzo rozsądne rozwiązania dla klas problemów wymagających innego podejścia.

Współczesna informatyka stosowana charakteryzuje się marnotrawstwem zasobów obliczeniowych na skalę przewyższającą nawet rozrzutność bankierów odpowiedzialnych za globalny kryzys finansowy z roku 2008. Green IT to fikcja, choć marketingowo sprzedaje się całkiem nieźle. I pozostanie nią, dopóki informatyka stosowana będzie traktowana jak rzemiosło, bo – przynajmniej po części – jest sztuką. Jeśli więc dbałość o ekologię ma rzeczywiście wpłynąć także na IT, to myślenie o systemach informatycznych nie może się sprowadzać do wyboru takiego, czy innego komponentu w Javie, a prawdziwy architekt powinien umieć dobrać właściwe środki do rozwiązywanego problemu. Wachlarz możliwości jest duży i oby wtórny analfabetyzm nie wymazał tej wiedzy z pamięci architektów i projektantów systemów informatycznych.

Pozostaw komentarz