Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Projektowanie wysokowydajnych i skalowalnych serwisów WWW - Warstwa aplikacji

1,626 views

Published on

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

Published in: Technology
  • Login to see the comments

Projektowanie wysokowydajnych i skalowalnych serwisów WWW - Warstwa aplikacji

  1. 1. 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
  2. 2. .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
  3. 3. .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
  4. 4. .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
  5. 5. .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
  6. 6. .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
  7. 7. .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
  8. 8. .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
  9. 9. .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
  10. 10. .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
  11. 11. .com Stopnie rozwoju architektury serwisów webowych 11 Początki Architektura monolityczna Skalowanie serwisu Architektura warstwowa Przyszłość Architektura zorientowana na usługi (SOA)
  12. 12. .com 12 Stopnie rozwoju architektury serwisów webowych Początki
  13. 13. .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
  14. 14. .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
  15. 15. .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
  16. 16. .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
  17. 17. .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
  18. 18. .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
  19. 19. .com 19 Stopnie rozwoju architektury serwisów webowych Service Oriented Architecture
  20. 20. .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
  21. 21. .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
  22. 22. .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ę

×