projektowanie wysokowydajnych i skalowalnych serwisów www - część pierwsza - warstwa aplikacji
DESCRIPTION
Część pierwsza prezentacji pochodzącej z warsztatów skupiających się na zagadnieniach projektowania i wytwarzania wysokowydajnych i skalowalnych serwisów webowych. Prezentacja opisuje problemy związane z warstwą aplikacji: - Rodzaje skalowania - Architektury nastawione na zapewnienie wysokiej wydajności i skalowalności - Zagadnienia Load-Balancingu - Metody cache'owanie - n-Tier Cache, Varnish, Redis - Service Oriented Architecture Zapraszamy również do części drugiej, poświęconej warstwie danych: http://www.slideshare.net/octivi/projektowanie-wysokowydajnych-i-skalowalnych-serwisw-www-cz-druga-warstwa-danychTRANSCRIPT
Szkolimy team leaderów i zespoły programistyczne
Projektowanie wysokowydajnych
i skalowalnych serwisów www Cześć pierwsza - Warstwa aplikacji
Antoni Orfin <[email protected]> octivi.com
.com
1. Przedstawienie pojęć ◦ Wydajność
◦ Skalowalność
2. Zapotrzebowanie biznesowe
3. Stopnie rozwoju architektury serwisów webowych ◦ Początki
◦ Skalowanie serwisu
◦ Przyszłość
4. Konkluzje
Agenda
2
.com
Wydajność – szybkość obsługi żądań HTTP Miary ◦ Liczba transakcji na sekundę (req/s) ◦ Czas obsługi żądania przez serwer ◦ Całościowy czas ładowania strony
opóźnienia sieci + obsługa przez serwer + czas renderowania w przeglądarce
Przykład ◦ Duży sklep internetowy działający w >14 krajach ◦ Statystyki: 5 000 000 odsłon dziennie ◦ Teoria:
5 000 000 / (24 * 60 * 60) = 57 req/s ◦ Praktyka:
większość ruchu w godzinach pracy – 900-1700 5 000 000 / (8 * 60 * 60) = 173 req/s
Przedstawienie pojęć
3
.com
Przykłady wyników testów wydajnościowych ◦ Usługa REST API (PHP, Symfony2, Redis, MySQL) Requests per second: 653.78 [#/sec] (mean)
Time per request: 1.530 [ms] (mean)
◦ Serwis jednej z uczelni
(PHP, Wordpress, MySQL) Requests per second: 13.28 [#/sec] (mean)
Time per request: 75.289 [ms] (mean
Przedstawienie pojęć
Wydajność
4
.com
Ta sama technologia, diametralnie różne wyniki?
◦ W dużej mierze to od programisty zależy końcowy rezultat osiągów witryny
◦ W każdej technologii można doprowadzić do „złego stanu” - pisanie w Erlangu, Node.js czy C++ nie zapewni, że aplikacja będzie demonem szybkości
Przedstawienie pojęć
Wydajność
5
.com
Skalowalność – zdolność systemu do obsługi rosnącej ilości pracy, którą musi wykonać
Rozróżniamy: ◦ Skalowanie pionowe
◦ Skalowanie poziome
Przedstawienie pojęć
Skalowalność
6
.com
Skalowanie pionowe – powiększanie systemu w obrębie jednej instancji (np. dodawanie zasobów do serwera) ◦ Proste do realizacji (w pewnym zakresie)
◦ Ograniczone możliwości
◦ Duży koszt wraz ze wzrostem wymagań
Przedstawienie pojęć
Skalowalność
Oferta http://www.ovh.pl/serwery_dedykowane/ (13 X 2013) 7
.com
Skalowanie poziome – możliwość dodania kolejnych instancji systemu (np. dokupienie kolejnych serwerów) ◦ Trudniejsze w realizacji – zmiany w architekturze
oprogramowania
◦ Tańsze w dłuższym okresie
Przedstawienie pojęć
Skalowalność
8
.com
Skalowanie pionowe + poziome - ◦ Skalujemy pionowo dopóki technologia na to pozwala i jest
to opłacalne
◦ Gdy osiągamy szczyt – zmieniamy architekturę serwisu i skalujemy poziomo
Motywacja ◦ Skalowanie pionowe jest opłacalne do pewnego stopnia
◦ Ciężko od razu przewidzieć nasze przyszłe potrzeby
Przedstawienie pojęć
Skalowalność
9
.com
Technologia nie może ograniczać biznesu
Klient musi jak najszybciej dostać żądany zasób – inaczej wybierze inną firmę
Serwis musi być wiarygodny – wysoka dostępność ◦ Wysoka dostępność wpływa na wiarygodność serwisu
Minimalizacji kosztów
Zapotrzebowanie biznesowe
10
.com
Stopnie rozwoju architektury serwisów webowych
11
Początki
Architektura
monolityczna
Skalowanie
serwisu
Architektura
warstwowa
Przyszłość
Architektura
zorientowana na
usługi (SOA)
.com
1st Tier Cache (np. Varnish)
Rozdzielanie ruchu (np. HAProxy)
Replikacja, Sharding
2nd Tier Cache (np. Redis, Memcache)
13
Stopnie rozwoju architektury serwisów webowych
Skalowanie serwisu
.com
1. Wydzielenie serwerów bazodanowych
2. Wykorzystanie mechanizmów cache’u
3. Rozdzielanie ruchu – Load Balancing ◦ Dołożenie kolejnych serwerów
aplikacyjnych
14
Stopnie rozwoju architektury serwisów webowych
Skalowanie serwisu
.com
Podstawowy krok do poprawy wydajności
Konieczność zakupu kolejnego serwera
Serwer bazodanowy o innych parametrach niż aplikacyjny (np. większe, szybsze dyski)
15
Skalowanie serwisu
Wydzielenie warstwy danych
.com
HTTP Cache ◦ Poprawne ustawianie nagłówków HTTP – wykorzystanie
przeglądarki użytkownika 304 Not Modified, Etag, Expires, Last-Modified…
1st Tier Cache – Reverse Proxy (Varnish) ◦ Najwydajniejsza metoda cache’owania (~20k req/s ) ◦ Najbliżej użytkownika, żądanie nie trafia do aplikacji
2nd Tier Cache – in-memory (Redis, Memcache) ◦ Cache’owanie wyników zapytań do bazy danych,
długotrwałych operacji ◦ Zapisywanie wyników w pamięci RAM
16
Skalowanie serwisu
Wykorzystanie cache’owania
.com
Kolejne warstwy rozdzielające ruch 1. Rozdzielanie ruchu na DNSach
2. DNS kierują na serwery LB (np. HAProxy)
3. LB kieruje na serwery aplikacyjne
Problemy Awaria jednego z serwerów –
większe obciążenie na pozostałych
Zarządzanie sesjami użytkowników
Zduplikowany cache (te same dane na wielu serwerach)
17
Skalowanie serwisu
Load Balancing
.com
Jak współdzielić sesję gdy użytkownik może zostać skierowany na dowolny serwer aplikacyjny?
Rozwiązanie: Przechowywanie sesji we współdzielonym źródle
◦ NoSQL, In-memory
Bardzo wysoka wydajność
RAM? A co jak serwer padnie? (rozwiązanie: Redis, persistance)
Możliwość wygasania sesji na podstawie wbudowanych mechanizmów (TTL)
◦ Tradycyjna baza danych (MySQL)
Mniejsza wydajność
Problem z replikacją często zmieniających się danych
18
Skalowanie serwisu
Sesje użytkowników
.com
19
Stopnie rozwoju architektury serwisów webowych
Service Oriented Architecture
.com
Cechy ◦ Wydzielenie kluczowych systemów jako osobne usługi ◦ Systemy komunikują się za pomocą API (np. REST, SOAP) ◦ Każdy system dąży do architektury „skalowalnej”
Zalety ◦ Łatwiejsze skalowanie podsystemów
(warstwa nadrzędna odpowiada za mechanizmy uwierzytelniania, sesji…)
◦ Prostszy rozwój i utrzymanie systemów dla większych zespołów IT
◦ Udostępnienie API „na zewnątrz”
Wady ◦ Zwiększenie złożoności platformy – konieczność większych
nakładów na zarządzanie
20
Stopnie rozwoju architektury serwisów webowych
Service Oriented Architecture
.com
Największe serwisy internetowe były budowane od podstawowych modeli. Dopiero wraz ze wzrostem ruchu migrowały na coraz bardziej wydajne architektury
Serwisy webowe należy tworzyć z myślą o ich późniejszej skalowalności
Przedwczesne optymalizowanie serwisu jest ryzykowne ◦ …zbyt późne – również
Konkluzje
21
.com
22
Pytania, uwagi?
Zobacz również: ◦ octivi.com
◦ whoisusing.it
W części drugiej… Omówienie zagadnień związanych z warstwą danych:
Jak zapewnić wysoką wydajność?
Jak zapewnić wysoką dostępność?
Jak rozkładać dane na wielu węzłach?
Dziękuję za uwagę