Szkolimy team leaderów i zespoły programistyczne

Projektowanie wysokowydajnych

i skalowalnych serwisów www Cześć pierwsza - Warstwa aplikacji

Antoni Orfin <aorfin@imagin.pl> 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

12

Stopnie rozwoju architektury serwisów webowych

Początki

.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ę