«Безопасное взаимодействие в распределенных системах» — Алексей Солодкий, Badoo

Выступление на Badoo PHP Meetup 7.04.2018.

В эпоху микросервисов все острее становится проблема распределенного взаимодействия между различными частями инфраструктуры. Алексей расскажет как обеспечить безопасное синхронное общение между монолитом на PHP и кучей различных сервисов. Рассмотрим основные проблемы и решения.

Transcript

1. Солодкий Алексей · 7 апреля 2018 Безопасное взаимодействие в распределённых системах
2. About 3k серверов 600 серверов баз данных 350k запросов в секунду 50 типов самописных сервисов 2
3. • сервера падают; • сервис может затупить. Темы 3 Как выживать в мире, где… • правильно мониторить сервисы; • грамотно умирать. А также как…
4. Падение сервиса
5. • проблемы с железом; • сеть; • код; • неудачный деплой; • русские хакеры. Что может вывести из строя ваш сервис? 5
6. Failover схема 6
7. Failover схема 7
8. Failover схема 8
9. Failover распределение нагрузки 9
10. Failover распределение нагрузки 10
11. 11 Failover распределение нагрузки
12. • Async: • eventual consistency; • можно потерять часть данных; • быстрее на запись; • более простые схемы. • Sync: • данные всегда согласованы; • медленная запись; • кворумы, split-brain и прочие сложности. sync vs async репликация 12
13. • резервируйте; • проводите учения! • учитывайте падения при расчёте нагрузки; • выбирайте синхронность репликации, исходя из задач; • не кладите все яйца в одну корзину. Выводы
 раздела 13
14. Тупка сервиса
15. • чрезмерная нагрузка; • сеть; • проблемы с железом. Из-за чего сервис может затупить? 15
17. 17 Система из 10 воркеров может обработать 500 запросов в секунду (по 50 на воркер)
19. 19 Система из 10 воркеров может обработать 10 запросов в секунду. (по 1 на воркер)
20. 20 Circuit breaker принцип работы
21. 21 Circuit breaker принцип работы
22. 22 Circuit breaker принцип работы
23. 23 Circuit breaker принцип работы
24. • PHP + storage: • https://github.com/ackintosh/ganesha • https://github.com/ejsmont-artur/php- circuit-breaker • В виде отдельного демона: • Envoy • Linkerd Реализации 24
25. • не полагайтесь на сеть; • все запросы по сети должны иметь таймаут; • используете Circuit Breaker https://docs.microsoft.com/en-us/azure/ architecture/patterns/circuit-breaker Выводы
 раздела 25
26. Мониторинг
27. • прогнозирование нагрузки; • расследование инцидентов; • предотвращение аварий Зачем?
28. • Интеграционные метрики • RPS, время ответа, процентили; • количество ошибок логики; • количество системных ошибок. Что? • Внутренние метрики • портебление cpu, памяти; • количество хранимых ресурсов.
29. Что? • Очереди • EPS (Скорость прихода) • Время на разных этапах • Размер очереди в данный момент времени
30. Мониторинг memcache 30
31. Мониторинг memcache 31
32. Мониторинг memcache 32
33. Мониторинг memcache 33
34. Мониторинг memcache 34
35. Мониторинг memcache 35
36. Мониторинг memcache 36
37. Мониторинг memcache 37
38. Мониторинг memcache 38
39. Мониторинг memcache 39
40. • SaaS • datadoghq.com • rollbar.com • newrelic.com • Self-hosted • Zabbix • Grafana • ELK Как?
41. • собирайте все данные, какие можете; • не забывайте об асинхронном взаимодействии; • встраивайте в самописные сервисы отдачу статки; • настройте автоматические триггеры. Выводы
 раздела 41
42. Memento mori
43. Как умирать People near by
44. Как умирать People near by
45. Как умирать People near by
46. Как умирать People near by
47. Как умирать People near by
48. Как умирать People near by
49. • будьте готовы к полному падению сервиса; • не допускайте каскадного отказа; • отключайте некритичный функционал в случае падения сервиса. Выводы
 раздела 49
50. Итоги
51. • Балансировка нагрузки • Таймауты • Логика failover • Circuit breaker • Мониторинг • Логика авторизации • Сериализация, десериализация Слой интеграции 51
52. Спасибо! 52
53. Литература 53