Projektowanie aplikacji internetowych Wykad 7 Projektowanie duych skalowalnych

Projektowanie aplikacji internetowych Wykład 7 Projektowanie dużych skalowalnych aplikacji internetowych q Skalowalność q Skalowanie platformy sprzętowej q Równoważenie obciążeń q Replikacja baz danych q Partycjonowanie q Skalowanie pamięci masowej q Pamięć podręczna Projektowanie aplikacji internetowych 1

Potrzeby projektowania skalowalnych aplikacji internetowych (1) q Projektowanie skalowalnych aplikacji internetowych – wciąż jest problemem q Technologie stosowane do aplikacji niewielkich, często są niewłaściwe w stosunku do większych aplikacji Należy mieć na uwadze rozwój aplikacji już na wstępnym etapie jej projektu Projektowanie aplikacji internetowych 2

Potrzeby projektowania skalowalnych aplikacji internetowych (2) q Uwzględnienie wielkiej liczby generowanych stron przez aplikację (setki tysięcy dziennie) q Uwzględnienie wielkiej liczby wykonywanych zapytań (kilkadziesiąt zapytań w ciągu sekundy) Istnieje potrzeba takiego projektowania systemów internetowych, aby w razie osiągnięcia obciążenia przekraczającego możliwości pojedynczego komputera, była możliwość ich skalowania w sposób gwarantujący niezawodność i bezpieczeństwo. Projektowanie aplikacji internetowych 3

Problematyka skalowania q Pojawienie się problematyki skalowania aplikacji internetowych (np. serwisy społecznościowe) q Konieczność obsługi ogromnej liczby użytkowników. - Jak należy implementować obsługę setek użytkowników? Jak powinno się obsługiwać tysiąc użytkowników? Co zrobić z milionem użytkowników? Jak obsłużyć sto milionów? Co oznacza termin SKALOWANIE ? ? ? Projektowanie aplikacji internetowych 4

Skalowalność (1) Często spotykana ale nieprecyzyjna definicja skalowalności: „Łatwość modyfikowania systemu bądź komponentu celem dostosowania do dziedziny problemu” Warunki, które musi spełniać skalowalny system: q musi radzić sobie z większą liczbą żądań; q musi prawidłowo przetwarzać poszerzony zbiór danych; q musi stale zapewniać możliwość utrzymywania i konserwacji. Projektowanie aplikacji internetowych 5

Skalowalność (2) Mity na temat skalowalności: 1) Skalowalność = wydajność oprogramowania Wydajny system nie musi być skalowalny (odwrotnie zawsze prawdziwe). Poprawa efektywności skalowalnych systemów jest możliwa i polega na zwiększeniu ich skali. 2) Aplikacje napisane w Javie są skalowalne Cechę skalowalności może posiadać system napisany w dowolnym języku programowania z wykorzystaniem dowolnych narzędzi (niekoniecznie w Javie). Projektowanie skalowalnych systemów nie wymaga stosowania języków kompilowanych. Projektowanie aplikacji internetowych 6

Skalowalność (2) 3) Format XML = aplikacja skalowalna Aplikacja może być skalowalna, mimo że nie odczytuje ani nie zapisuje danych w formacie XML. 4) Skalowalność = odseparowanie logiki stron i biznesowej Odseparowanie logiki stron i logiki biznesowej jest korzystne, ale nie jest warunkiem koniecznym ani wystarczającym skalowalności. <? echo "Witaj świecie!"; ? > Tego typu system można łatwo dostosować do obsługi większej liczby użytkowników – dodając większą ilość serwerów WWW. Projektowanie aplikacji internetowych 7

Skalowanie platformy sprzętowej Jedna z najważniejszych strategii skalowania architektury systemów internetowych – rozbudowa platformy sprzętowej. Propozycja: należy budować aplikacje internetowe tak, aby nie ingerować w kod źródłowy (przy zwiększaniu skali oprogramowania), a jedynie dokupywać i doinstalowywać dodatkowy sprzęt. Budować aplikację internetową z myślą o skalowaniu pionowym czy poziomym? q Pionowe skalowanie systemu informatycznego wymaga instalacji sprzętu bardziej wydajnego od stosowanego dotychczas. q Skalowanie poziome polega na dodawaniu urządzeń podobnych jak urządzenia tworzące dotychczasową platformę sprzętową. Projektowanie aplikacji internetowych 8

Skalowanie pionowe - rozpoczynamy od prostej konfiguracji sprzętowej (np. jeden serwer WWW i jeden serwer bazy danych). Kiedy wydajność jakiegoś komputera okaże się niewystarczająca, zastępujemy go innym, bardziej efektywnym , itd. Wada: koszty skalowania systemu nie rosną liniowo (rys. – pojedyncze serwery). Zaleta: projektowanie takiego modelu jest proste. Zwiększanie wydajności platformy sprzętowej ogranicza się tylko do wymiany sprzętu na lepszy. Projektowanie aplikacji internetowych 9

Skalowanie poziome (1) Skalowanie poziome - w kolejnych cyklach dodajemy zwykłe komputery. Do jednego komputera dostawiamy drugi komputer, w dalszej kolejności trzeci, czwarty, itd. Decyzja: Wybór komputerów dla tworzonej platformy sprzętowej, tzn. więcej komputerów o słabszej konfiguracji, czy mniej mocniejszych? W obu przypadkach koszty utrzymania i konserwacji pojedynczego komputera są podobne Projektowanie aplikacji internetowych 10

Skalowanie poziome (2) q Poszukiwanie złotego środka pomiędzy całkowitym kosztem pozyskania (TCO) i mocą obliczeniową komputerów (możliwie wysoka wydajność, przy najmniejszych kosztach). q Wada - wyższe koszty administracyjne niż w modelu skalowania pionowego Koszty administracji systemów skalowanych poziomo nie rosną liniowo Np. konserwacja 10 identycznych komputerów może być przeprowadzana równolegle, łatwiejsza instalacja i konfigurowanie gdyż znamy już wszelkie potencjalne utrudnienia, itp. Projektowanie aplikacji internetowych 11

Skalowanie poziome (3) q Inne koszty pozyskania większej liczby komputerów: pobieranie dodatkowego prądu, wymóg posiadania odpowiedniej przestrzeni na umiejscowienie komputerów (złożone serwery zajmują mniej miejsca niż większa liczba komputerów prostych), itp. q Problem ze skalowaniem poziomym: Niepełne wykorzystanie potencjału kupowanego i instalowanego sprzętu Należy właściwe dobierać charakterystyki wydajnościowe komputerów na etapie projektu platformy sprzętowej. Projektowanie aplikacji internetowych 12

Skalowanie poziome (4) q Wydajność oprogramowania nie musi rosnąć liniowo nawet wtedy, gdy liniowo skalujemy platformę sprzętową. Rozwiązanie: projektowanie oprogramowania w sposób gwarantujący możliwość liniowego skalowania niezależnie od bieżących rozmiarów platformy sprzętowej. q Gdy zakup nowego sprzętu zdaje się zbyt kosztowny - zmiana modelu skalowania na pionowy. Łącząc model skalowania poziomego z modelem skalowania pionowego można wykorzystać najlepsze cechy obu strategii Projektowanie aplikacji internetowych 13

Przewidywanie sytuacji kryzysowych Uwzględnianie zdarzeń losowych, np. awaria komponentu czy komputera. q Na końcu cyklu projektowania architektury powinniśmy dysponować dokumentami opisującymi procedury postępowania w sytuacjach kryzysowych. q Dokumentacja zarządzania kryzysowego i scenariuszy awaryjnych powinna obejmować procedury opisujące sposoby przywracania właściwego stanu systemu, np. co należy robić w razie awarii dysku, komputera, itp. q Celem pisania dokumentacji jest stanu, w którym znane są procedury postępowania w razie występowania typowych i zupełnie nowych problemów. q Tworzenie dokumentacji ułatwia identyfikację potencjalnych źródeł problemów i sposobów radzenia sobie w sytuacjach kryzysowych. Projektowanie aplikacji internetowych 14

Nadmiarowość (1) Komputery ulegają awarii niezależnie od zastosowanej strategii skalowania (Google – na 10 000 komputerów – awaria jednego dziennie). Projekt musi uwzględniać procedury postępowania z awarią wykorzystywanych komponentów. Sprzęt zapasowy (rezerwowy) dzielimy na trzy kategorie: q Zimny q Ciepły q Gorący Projektowanie aplikacji internetowych 15

Nadmiarowość (2) q Zimny - urządzenia sieciowe, np. przełączniki. W razie awarii wymieniamy uszkodzone urządzenie na nowe, instalujemy, powielamy oryginalną konfigurację i uruchomiamy. q Ciepły - w pełni skonfigurowane urządzenia. Instalacja sprowadza się tylko do wymiany starych urządzeń na nowe i uruchomieniu sprzętu zastępczego. Przykład: system My. SQL obejmujący główny serwer i gotowy do włączenia system zapasowy. q Gorący - utrzymywanie tzw. gorących komponentów zastępczych. Kiedy komponent ulegnie awarii, pozostałe komponenty automatycznie przejmą jego zadania (bez udziału użytkownika). Projektowanie aplikacji internetowych 16

Nadmiarowość (3) Minimalny poziom nadmiarowości – eliminacja wszelkich punktów, dla których nie dysponujemy przynajmniej po jednym zimnym urządzeniu zapasowym lub na początek nadmiarowe egzemplarze tylko dla tych komponentów, które ulegają awarii najczęściej. Dla każdego urządzenia, dla którego nie dysponujemy gorącym, ciepłym ani zimnym zamiennikiem należy określić maksymalny czas wymiany. q W przypadku dysków twardych (częste awarie) powinny być zawsze urządzenia zapasowe tego typu. q Zastępowanie dysków bardzo podobnymi urządzeniami jest niezwykle ważne w konfiguracjach obejmujących mocno obciążone macierze dyskowe RAID. Projektowanie aplikacji internetowych 17

Skalowanie sieci komputerowych - technologie i protokoły sieciowe od początku były zaprojektowane z myślą o przyszłych zmianach skali. Przesyłanie dużej ilości danych może obciążyć nawet sieć o najwyższej przepustowości, jednak nie powinno blokować pozostałej komunikacji, gdy oba węzły pracują w sieci z przełącznikami. q Pojedyncza sieć z przełącznikami może obsługiwać sporą liczbę komputerów. q Łącząc wiele przełączników można stworzyć sieć obejmującą tysiące komputerów. q Łącząc przełączniki, routery można uzyskać sieć obsługującą dziesiątki tysięcy komputerów. Dobre przełączniki oferują możliwość tworzenia tzw. sieci wirtualnych (VLAN), czyli konstrukcji pozwalających na konstruowanie wielu rozłącznych sieci w ramach tych samych urządzeń. Projektowanie aplikacji internetowych 18

Skalowanie aplikacji napisanych w PHP (1) Czy aplikacje pisane w języku PHP spełniają trzy kryteria systemów skalowanych? 1. Możliwość utrzymywania i konserwacji? Przy konsekwentnym stosowaniu zaleceń opisujących właściwą strukturę i styl programów pisanych w PHP (rozszerzając o bardziej dowolne elementy), konserwacja aplikacji nie powinna sprawiać problemów. 2. Możliwość rozszerzania zbioru danych? W aplikacjach internetowych pisanych w PHP magazyny danych są oddzielone od logiki przetwarzania. Ilość danych składowanych w bazie danych nie ma większego znaczenia. PHP przenosi odpowiedzialność za skalowanie zbioru danych do warstwy ich składowania, zatem sama logika przetwarzania nie jest uzależniona od ilości danych. 3. Możliwość efektywnego przesyłania coraz większej ilości danych? PHP nie stwarza żadnych ograniczeń – zbudowany jest na bazie architektury, którą sam twórca PHP określił mianem architektury „nic wspólnego". PHP jest technologią bezstanową (wszystkie informacje o stanie są składowane na niższym poziomie). Model pozawala skutecznie izolować poszczególne żądania i wyklucza możliwość współdzielenia czegokolwiek przez dwa żądania lub procesy. Projektowanie aplikacji internetowych 19

Skalowanie aplikacji napisanych w PHP (2) Sytuacje, w których założenia odnośnie skalowalności okazują się nieprawdziwe. q Istnieje wiele rozszerzeń PHP, które nie tylko nie są bezstanowe, ale też nie oferują możliwości kierowania żądań użytkowników do dowolnych serwerów. Przykładowo, rozszerzenie „sessions” składuje informacje o bieżącej sesji użytkownika na dysku lokalnym - na czas sesji trwale wiąże użytkownika z serwerem WWW. q Niektóre rozszerzenia języka PHP umożliwiają procesom rezerwowanie obszarów wspólnej pamięci do wykorzystania ich podczas komunikacji międzyprocesowej. Nie stosując wyspecjalizowanych rozszerzeń, spełnianie kryteriów skalowalności przez aplikacje PHP będzie możliwe (możliwość zmiana skali warstwy odpowiedzialnej za komunikację, możliwość rozbudowy zbioru danych, zapewnienie łatwości utrzymania oraz konserwacji). Projektowanie aplikacji internetowych 20

Równoważenie obciążeń Skalowanie pionowe – nie ma problemu kierowania żądań użytkownika do właściwego węzła (jeden serwer). Rozkładanie obciążenia pomiędzy procesory odpowiadają mechanizmy harmonogramowania zadań. q Serwer Apache - środowisko wieloprocesowe, możliwość przypisania każdemu procesowi innego procesora, równoległa obsługa wielu żądań. Skalowanie poziome - system będzie się składał z wielu procesorów, ale bez równomiernego rozdzielanie żądań pomiędzy procesory. Do systemu (na jeden adres IP) będzie docierało wiele żądań, które powinny być obsługiwane przez wiele komputerów. Metody rozwiązywania tego problemu są określane jako równoważenie obciążeń. q Najprostszy sposób równoważenia obciążenia kilku serwerów WWW - utworzenie dla domeny aplikacji więcej niż jednego rekordu „A” w strefie DNS-a (przypadkowe porządkowanie przez serwery DNS i odsyłanie do węzłów generujących żądania w losowej kolejności). q Po podaniu adresu systemu, przeglądarka zażąda od serwera DNS listy rekordów dla tego adresu - serwer DNS wysyła listę adresów – klient próbuje wykorzystać pierwszy adres. q Równoważenie obciążeń za pośrednictwem serwerów DNS ma też pewne wady, np. utrudnia zapewnianie nadmiarowości i wychodzenie z sytuacji awaryjnych. Projektowanie aplikacji internetowych 21

Sprzętowe równoważenie obciążeń Najprostszym sposobem równoważenia obciążeń wielu komputerów jest stosowanie odpowiednich urządzeń. Instalacja ich polega na podłączeniu, włączeniu i dostosowaniu kilku ustawień konfiguracyjnych. Wady stosowania urządzeń równoważących obciążenia: q Trudności w konfigurowaniu i zarządzaniu dużymi zbiorami adresów IP, reprezentowanymi przez pojedyncze adresy VIP (przestarzałe interfejsy użytkownika oparte na stronach WWW lub nieprzyjazne interfejsy obsługiwane w wierszu poleceń). q Wysoka cena (od kilkudziesięciu tysięcy złotych). Urządzenia równoważące obciążenia oferują wiele innych usług: buforowanie stron, mechanizmy przyspieszające komunikację z użyciem protokołu HTTPS, rozwiązania chroniące system przed atakami Do. S. Zalety stosowania urządzeń równoważących obciążenia: q Dodawanie i usuwanie serwerów rzeczywistych z listy adresów reprezentowanych przez adres VIP urządzenia przebiega błyskawicznie. q Możliwość dużo łatwiejszego usuwania usterek. Jeśli jeden z rzeczywistych serwerów wchodzący w skład puli VIP ulegnie awarii, urządzenie wykryje ten fakt automatycznie i wstrzyma wysyłanie żądań do tego serwera. Projektowanie aplikacji internetowych 22

Programowe równoważenie obciążeń Obciążenia serwerów można również równoważyć programowo. q Zapewnienie sprzętu, na którym to oprogramowanie będzie mogło efektywnie pracować. q Wymagania systemów są na tyle niskie, że koszty niezbędnego sprzętu będą niższe od kosztów dedykowanych urządzeń równoważących obciążenia. q Awaryjność typowego komputera jest większa niż awaryjność urządzeń sprzętowych do równoważenia obciążeń, dlatego należy rozważyć zakup i instalację nadmiarowej liczby serwerów równoważących. q Możliwość wykorzystania do równoważenia obciążeń tego samego rodzaju komputerów co do generowania stron internetowych aplikacji (w razie awarii można wykorzystać któryś z komputerów należących do puli serwerów WWW (i odwrotnie). Projektowanie aplikacji internetowych 23

Replikacja baz danych q Pojedynczy serwerem bazy danych (np. My. SQL) – niemożliwy wzrost wydajności bez rozbudowy konfiguracji. q Aplikacje internetowe wykonują więcej operacji odczytu niż zapisu. q Z myślą o skalowaniu baz danych (głównie do odczytu) została zaimplementowana obsługa techniki nazywana replikacją. q Replikacja polega na replikowaniu danych na wielu serwerach, czyli na zwiększaniu liczby punktów, z których można te dane odczytywać. q System My. SQL oferuje możliwość stosowania replikacji typu nadrzędny-podległy q Każdy egzemplarz tego systemu może być stroną podległą dokładnie jednego egzemplarza nadrzędnego (albo żadnego) oraz stroną nadrzędną dla zera, jednego lub wielu egzemplarzy podległych. Projektowanie aplikacji internetowych 24

Replikacja typu nadrzędny-podległy (1) Korzystając z jednego serwera bazy danych, najprostszą konfigurują docelową będzie jedna para nadrzędny-podległy (ang. master-slave replication). Dotychczasowy serwer bazy danych staje się komputerem nadrzędnym (wszystkie operacje zapisu będą wykonywane na tym serwerze). q Wierne powielanie zdarzeń po stronie serwera nadrzędnego powoduje, że zbiór danych utrzymywany przez serwer podległy jest modyfikowany w dokładnie ten sam sposób (zawiera w pełni spójną kopię zawartości serwera nadrzędnego). q Dane składowane na serwerze podległym nie mogą być modyfikowane. q Zaletą tego modelu jest wydajność operacji odczytu. Projektowanie aplikacji internetowych 25

Replikacja typu nadrzędny-podległy (2) q Dokładając do istniejącego serwera dodatkowy serwer podległy (konfiguracja nadrzędnypodległy), można dwukrotnie zwiększyć liczbę możliwych do wykonania operacji odczytu. q Wszystkie operacje zapisu muszą być wykonywane przez oba komputery (serwer podległy nie oferuje większej efektywności operacji odczytu niż serwer nadrzędny). q Serwer podległy powinien dysponować mocą nie mniejszą niż serwer nadrzędny (musi realizować wszystkie operacje zapisu wykonywane przez serwer nadrzędny). q Gdy efektywność operacji odczytu jest niewystarczająca można dodać kolejne serwery podległe: Wadą tego modelu jest konieczność wykonywania żądań zapisu na wszystkich komputerach, co uniemożliwia skalowanie efektywności tych operacji. Projektowanie aplikacji internetowych 26

Drzewo replikacji Przekształcając część podległych serwerów w serwery nadrzędne kolejnych serwerów podległych, tworzymy drzewo replikacji. Komunikaty o zdarzeniach przechodzą przez pojedynczy interfejs sieciowy serwera nadrzędnego. Wada - jeśli serwer podrzędny pracujący w warstwie środkowej tej architektury ulegnie awarii, serwery podrzędne znajdujące się poniżej, przypisane do tego serwera nie będą otrzymywały informacji o zmianach , będą udostępniały nieaktualne dane. . Projektowanie aplikacji internetowych 27

Replikacja typu nadrzędny-nadrzędny Tworzona jest para serwerów, z których każdy pełni funkcję serwera podległego drugiej stronie. Jest to strategia nazywana replikacja typu nadrzędny-nadrzędny (ang. master-master replication). Serwery nie muszą informować o generowanych zdarzeniach. serwera nadrzędnego znajdującego się naprzeciw Wada - brak możliwości wykonywania na dowolnym serwerze operacji zapisu powodujących automatyczne inkrementowanie wartości kluczy głównych. Projektowanie aplikacji internetowych 28

Partycjonowanie bazy danych Uzyskanie skalowania bazy danych pod kątem maksymalnej efektywności (odczyt i zapis) należy dokonać podobnych zabiegów jak w przypadku serwerów WWW. Każda część uzyskana w wyniku podziału będzie oferowała podobną wydajność jak oryginalna, monolityczna baza danych. Dane można dzielić na dwa sposoby: q stosując techniki partycjonowania poziomego q stosując techniki partycjonowania pionowego Partycjonowanie pionowe (podział na klastry) umożliwia łatwe, ale ograniczone skalowanie. Partycjonowanie poziome jest rozwiązaniem bardziej uniwersalnym. Umożliwia tworzenie dowolnej liczby partycji, ale wymaga dużo większych nakładów pracy. Projektowanie aplikacji internetowych 29

Podział na klastry (1) Podział na klastry jest określany mianem partycjonowania pionowego. Tworzenie klastrów polega na podziale bazy danych na mniejsze fragmenty (klastry), z których każdy zawiera jakiś podzbiór wszystkich tabel. Wielka baza danych obejmująca sześć tabel q Podział na klastry zwykle wymaga sporych zmian w samej aplikacji. Po zidentyfikowaniu zapytania operującego na poszczególnych tabelach, można zmodyfikować warstwę odpowiedzialną za kierowanie tych zapytań do bazy danych, aby wybierała właściwe klastry serwerów w zależności od tabel wymaganych do realizacji żądań. q Struktura samych klastrów zależy tylko i wyłącznie od nas (pojedynczy serwer, para nadrzędny-podległy lub para nadrzędny-nadrzędny). W różnych klastrach można stosować różne modele. Projektowanie aplikacji internetowych 30

Podział na klastry (2) Wielka baza danych obejmująca sześć tabel 1. Przed przystąpieniem do podziału bazy danych należy wygenerować listę wszystkich tabel. 2. Należy przeanalizować wszystkie zapytania języka SQL zapisane w kodzie źródłowym i określić, których tabel dotyczą. Złączane tabele nie mogą się znajdować w różnych klastrach. Wynikiem tej fazy powinna być lista możliwych klastrów wraz z tabelami, które należy w tych klastrach umieścić. Ograniczenie podziału na klastry - pojedyncze tabele lub zbiór złączanych tabel będących przedmiotem wielu operacji zapisu zawsze musi być przypisany do jednego klastra. Zarządzanie klastrami jest trudniejsze niż zarządzanie pojedynczą bazą danych - różne zbiory danych są składowane na różnych serwerach o innych wymaganiach. Projektowanie aplikacji internetowych 31

Federacja (1) q Federacja jest odpowiednikiem skalowania poziomego w świecie baz danych. q Skalowanie platformy sprzętowej do dowolnych rozmiarów jest możliwe, gdy rozbudowując konfigurację o kolejne serwery zwiększamy jej potencjał w obszarze odczytu i zapisu. q Dla największych tabel musi być możliwość dzielenia składowanych tam danych na mniejsze fragmenty. Zmieniając rozmiar zbioru danych i liczbę zapytań należy stopniowo zwiększać liczbę tych fragmentów, aby utrzymywać stałą ilość danych i zapytań wykonywanych na fragmencie. q Fragmenty danych wraz z serwerami są nazywane odłamkami lub komórkami. Logika aplikacji Logika federacji Odłamek Projektowanie aplikacji internetowych 32

Federacja (2) q Samodzielne tworzenie federacyjnych baz danych jest trudne. Odczytywanie całych przedziałów danych składowanych w tabelach, które rozproszono pomiędzy wieloma serwerami, z reguły wymaga wielokrotnego przeszukiwania, scalania i sortowania rekordów. q Wykonywanie złączeń pomiędzy federacyjnymi tabelami jest skomplikowane. q Wyeliminowanie zapytań obejmujących więcej niż jeden odłamek polega na takim podziale danych, aby wszystkie rekordy odczytywane w ramach jednego zapytania wchodziły w skład tego samego odłamka. Projektowanie aplikacji internetowych 33

Skalowanie pamięci masowej q Pliki składające się na przestrzeń pamięciową zajmują również coraz więcej pamięci dyskowej. q Problemem związanym ze składowaniem baz danych na dyskach twardych jest ich zawodność (awaryjność dysku wzrasta wraz z rosnącą liczbą wykonywanych operacji zapisu i odczytu). q Rozwiązaniem tego problemu jest zapewnienie odpowiedniej nadmiarowości. q Nadmiarowość można zapewnić na poziomie całych serwerów (wysokie koszty). q Gdyby udało się mniejszym kosztem ograniczyć ryzyko awarii poszczególnych serwerów, system byłby zabezpieczony równie dobrze mimo mniejszej liczby komputerów. q Skalowalność platformy składowania danych wymaga zagwarantowania obsługi odpowiedniej liczby i objętości plików z jednoczesnym zapewnieniem właściwego poziomu nadmiarowości. Projektowanie aplikacji internetowych 34

Pamięć podręczna q Przyspieszenie dostępu do komponentu aplikacji często sprowadza się do instalacji i konfiguracji pamięci podręcznej usytuowanej przed tym komponentem (ograniczenie liczby żądań operacji odczytu). q Dołączanie kolejnych komponentów jest skutecznym sposobem rozszerzania skali systemu. q Niemal każdy komponent, z którego odczytujemy dane, można skalować instalując pamięć podręczną. q Ograniczając obciążenie komponentów i projektując skalowalne pamięci podręczne stwarzamy możliwość prostego zwiększania pojemności (przepustowość) danego komponentu. q Pamięć podręczną można stosować na dowolnym poziomie, mamy do dyspozycji szeroką gamę rozmaitych produktów i technik tworzenia skalowalnych buforów. Projektowanie aplikacji internetowych 35