Architektura systemów webowych wysokiej przepustowości. na przykładzie Wikia

Transkrypt

1

2 Architektura systemów webowych wysokiej przepustowości na przykładzie Wikia

3 Agenda Czym jest Fandom powered by Wikia Ogólny zarys architektury - warstwy systemu Ścieżka obsługi przykładowego żądania Monolit vs Mikroserwisy Omówienie wybranych komponentów Mesos oraz Consul Stos ELK Monitorowanie wydajności Alerting Proces zmiany kodu i wydania wersji Continuous Integration & Deployment

4

5

6 17 jesteśmy 17-stą najczęściej odwiedzaną stroną w USA 4 Czwarci pod względem odwiedzin z urządzeń mobilnych 1 Jesteśmy największą na świecie bazą artykułów o grach video

7 Ogólny zarys architektury Desktop Web Users Static HTML+JS Mobile Web Users SPA - JS Android + ios Users API: HTML+JS Fastly Content Delivery Network San Jose Main Data Center Reston Backup Data Center

8 San Jose Data Center MediaWiki Stack (głównie PHP) Np. fallout.wikia.com HTML + API New Microservice Stack (głównie Java) Np. services.wikia.com/discussions API Border Varnish - Load Balancer API Gateway Nginx MediaWiki Apache + PHP 80 Servers Mesos + Marathon Container Orchestration 4 Servers Service X MySQL Master + Slave 10 Clusters, 4 Servers per cluster Helios OAuth Golang Consul Service Discovery

9 Ścieżka obsługi przykładowego żądania Fastly CDN Edge - zwróć z pamięci podręcznej, jeśli istnieje Fastly CDN Shield - zwróć z pamięci podręcznej, jeśli istnieje Wikia Border (load balancer) - wybierz jeden z serwerów apache z puli Apache+PHP - generuj HTML Pobierz zawartość artykułu z bazy Sprawdź czy wynik zapytania jest w memcached, jeśli tak zwróć Znajdź cluster z bazą danych i wyszuk hosta slave z bazą Pobierz dane z bazy i zaktualizuj pamięć podręczną w memcached Pobierz inne dane konieczne do generowania artykułu z mikroserwisów Zapisz logi oraz dane o wydajności w Elasticsearch u oraz InfluxDB Zapisz wynik w pamięci podręczne Fastly (Shield + Edge) oraz zwróć wynik użytkownikowi Przez JavaScript pobierz reklamy od zewnętrznych partnerów Pobierz obrazki (optymalizacja formatów np. WebP)

10 Monolit vs Mikroserwisy Monolit Nasz ma 4 miliony linii kodu Problemy Trudność w zarządzaniu i rozwijaniu Liczba powiązań wewnętrznych modułów Mikroserwisy Domain Driven Design Zoptymalizowane pod zastąpienie a nie pod ponowne użycie (replace v. reuse) - można napisać od zera w tydzień Autonomiczne zespoły odpowiedzialne za cały cykl życia serwisu Skalowalność Chmura, większa elastyczność w użyciu sprzętu

11 Zalety dynamicznego zarządzania usługami i użycia kontenerów Łatwiejsze i szybsze skalowanie - brak konieczności fizycznego konfigurowania serwerów pod konkretne usługi. Łatwiejsze uruchomienie nowych usług przez programistów, bez interakcji z administratorami systemu. Możliwość automatycznego skalowania usług w zależności od ruchu w danym momencie Kontrola zdrowia usług, możliwość automatycznego zrestartowania (fault recovery) Bardziej efektywne wykorzystanie fizycznych zasobów i tym samym obniżenie kosztów Możliwość użycia dostępnych w internecie kontenerów z komponentami np. Bazami danych

12

13 Service Discovery API DNS Zarządzanie konfiguracją

14 Logi - Stos ELK Zarządzanie Logami ElasticSearch - Document Storage Zoptymalizowane pod wyszukiwanie tekstu Brak sztywnej struktury Shardowanie i sterowanie retencją danych Logstash Zbiera Logi i zapisuje do ElasticSearch Kibana - UI Napisany w JavaScript

15

16 Monitorowanie wydajności Dlaczego wydajność jest ważna? Różne obszary pomiaru Frontend Backend Poziom aplikacji Baza danych A/B Testy

17

18

19 Alerting Kapacitor PagerDuty

20 27 unikalnych serwisów, większość w więcej niż jednej instancji

21 50 percentyl czasu odpowiedzi

22 Proces zmiany kodu i wydania wersji Jira - Tickety Github - kontrola wersji kodu Pull Request - code review TDD - testy jednostkowe, integracyjne oraz Selenium Jenkins SonarQube - statyczna analiza kodu Ponowne uruchomienie testów Deployment Manualny Cykliczny Continuous Deployment

23

24

25 Pytania?

26 Thank you!