Тестирование распределенных систем

https://youtu.be/h8RV4JfSovg

http://2016.heisenbug-moscow.ru/talks/testirovanie-raspredelennyh-sistem/

https://asatarin.github.io/talks/testing-distributed-systems/

Распределенные системы всё чаще встречаются нам на профессиональном пути. Современные популярные сайты и приложения содержат у себя «под капотом» распределенную систему — они бросают вызов разработчикам в силу фундаментальной сложности их создания и огромного диапазона возможных компромиссов в дизайне.

Андрей расскажет о той части этих вызовов, что присутствуют в тестировании, о существующих ограничениях и их влиянии на функциональность.

Будут освещены вопросы:
- чем распределенные системы отличаются от централизованных систем;
- что все это значит для тестирования;
- какие свойства и характеристики нужно проверять в распределенных системах и как это делать;
- какие подходы к тестированию распределенных систем есть и какие проблемы они решают;
- какие проблемы остаются не решенными.

Примером в докладе выступит персистентная распределенная очередь, которая разрабатывается в Яндексе. Слушатели узнают, что и как тестировали Андрей с командой Яндекс и какие результаты получили.

Transcript

2. Тестирование распределенных систем Андрей Сатарин
3. A distributed system is one in which the failure of a computer you didn't even know existed can render your own computer unusable Leslie Lamport 3
4. Распределенные системы в мире • MongoDB • Apache Cassandra • Apache Hadoop/MapReduce • Apache ZooKeeper • Apache Kafka • ElasticSearch 4
5. Распределенные системы в Яндексе • YT — платформа вычислений в парадигме Map/Reduce
 https://habrahabr.ru/company/yandex/blog/311104/ • Yandex Query Language — декларативный язык запросов к системе обработки данных
 https://habrahabr.ru/company/yandex/blog/312430/ • Media Storage —распределенная система хранения данных
 https://habrahabr.ru/company/yandex/blog/311806/ • ClickHouse — открытая колоночная распределенная база данных
 https://clickhouse.yandex/
 https://habrahabr.ru/company/yandex/blog/303282/ Подробнее тут https://events.yandex.ru/events/meetings/15-oct-2016/ 5
6. Зачем нужны распределенные системы? • Производительность — много машин могут сделать больше работы в единицу времени, чем одна • Отказоустойчивость — сбой одной или нескольких машин не обязательно приводит к остановке системы 6
7. Производительность Sort benchmark (http://sortbenchmark.org/) 
 Мировой рекорд 2016 года: • 512 машин • Сортировка 100 TB данных за 134 секунды 7
8. Больше не буду говорить про производительность 8
9. Отказоустойчивость • Вероятность сбоя одного узла низкая (железо надежно) • Больше узлов — больше сбоев каждый день Пример: сбой одной машины раз в год, в кластере 500 машин — больше одного сбоя в день 9
10. Отказоустойчивость: сеть The Network is Reliable
 http://queue.acm.org/detail.cfm?id=2655736 «They found an average failure rate of 5.2 devices per day and 40.8 links per day, with a median time to repair of approximately five minutes (and a maximum of one week)» «Median incident duration of 2 hours and 45 minutes for the highest- priority tickets and a median duration of 4 hours and 18 minutes for all tickets» 10
11. Отказоустойчивость: диски One Billion Drive Hours and Counting: Q1 2016 Hard Drive Stats
 https://www.backblaze.com/blog/hard-drive-reliability-stats-q1-2016/
 «The overall Annual Failure Rate of 1.84% is the lowest quarterly number we’ve ever seen.» Loud Sound Just Shut Down a Bank’s Data Center for 10 Hours
 http://www.techworm.net/2016/09/banks-data-center-shut-10-hours-loud-sound.html
 «The HDD cases started to vibrate, and the vibration was transmitted to the read/write heads, causing them to go off the data tracks.» 11
12. Отказоустойчивость: силы природы Google data center loses data following four lightning strikes
 http://www.extremetech.com/computing/212586-google-data-center-loses-data-following-four- lightning-strikes
 
 «However, four successive lightning strikes on the electrical systems of its data center pushed the buffering and backups to their limits.» 12
13. https://twitter.com/mathiasverraes/status/632260618599403520 13
14. Распределенная персистентная очередь 14
15. Зачем нужна очередь? Очередь M … 1 Системы источники данных Системы потребители данных 15 N … 1 Очередь — M + N интеграций Нет очереди — M x N интеграций M + N << M x N
16. Очередь 6 5 4 3 7 2 First In First Out (FIFO) 16
17. Персистентная очередь 6 5 4 3 7 2 1 Алиса Боб 17
18. Распределенная персистентная очередь 6 5 4 3 7 2 e d c b f c Топик Партиция 0 Партиция 1 Топик + партиция == FIFO 2 1 a 18
19. Распределенная персистентная очередь: запись 6 5 Партиция Диск: 19 Producer 7 Прокси
20. Распределенная персистентная очередь: запись 7 6 5 Прокси Партиция Диск: 20 Producer OK
21. Распределенная персистентная очередь: запись 6 5 Прокси Партиция Диск: 21 Producer 7
22. Распределенная персистентная очередь: запись 6 5 Прокси Партиция Диск: 22 Producer Fail
23. Распределенная персистентная очередь: запись 6 5 Прокси Партиция Диск: 23 Producer 7 Fail
24. Распределенная персистентная очередь: запись ? ? 6 5 Прокси Партиция Диск: 24 Producer Fail OK
25. Семантика распределенных очередей • At most once —можем терять данные, нет дублей (/dev/null) • Exactly once — нет потерь, нет дублей (наша очередь) • At least once — не теряем данные, возможны дубли (Apache Kafka) 25
26. https://twitter.com/mojavelinux/status/751595888435294209 26
27. Подходы к тестированию (что уже сделано до нас) 27
28. Netflix Chaos Monkey • Давно развивается компанией Netflix • Работает на Amazon Web Services • Запускается в продуктивном окружении • Про нее многие знают http://techblog.netflix.com/2011/07/netflix-simian-army.html
 http://techblog.netflix.com/2016/10/netflix-chaos-monkey-upgraded.html 28
29. Jepsen http://jepsen.io/ Kingsbury, 2015 29
30. Jepsen 30 Kingsbury, 2015
31. Наш подход к тестированию 31
32. Наш подход 6 5 4 3 7 2 Producer Consumer Nemesis Safety Warden 32
33. Producer • Пишет заранее известный поток данных • Соблюдает протокол взаимодействия с системой • Соблюдает single writer principle 33
34. Consumer • Читает данные и проверяет их корректность • Соблюдает протокол взаимодействия с системой • Несколько потребителей на одну пару топик + партиция 34
35. Nemesis • Немезида — в древнегреческой мифологии богиня возмездия против тех, кто высокомерен перед богами • У нас — инструмент для внесения разнообразных сбоев в систему (fault injection) • Сбои могут быть внешние (black box) и внутренние (white box) 35
36. Safety Warden Проверяет, что ничего плохого не произошло: • Очередь соблюдает внешние инварианты и exactly once семантику • Процесс не падает в корку • Нет out-of-memory ошибок • Нет критичных сообщений в логах 36
37. Баги и выводы 37
38. Потеря дублей 6 5 7 Прокси Партиция Диск: Память: 38 Producer
39. Потеря дублей 7 6 5 Прокси Партиция Диск: Память: 39 Producer OK
40. Потеря дублей 6 5 7 Прокси Партиция Диск: Память: 40 Producer
41. Потеря дублей 6 5 4 3 Прокси Партиция Диск: Память: 41 7 Producer Fail
42. Потеря дублей 6 5 4 3 Прокси Партиция Диск: Память: 42 7 Producer 7 Fail
43. Потеря дублей 6 5 4 3 Прокси Диск: Память: 43 7 Producer Fail 7 OK Партиция
44. Потеря дублей 6 5 4 3 Прокси Диск: Память: 44 Producer Fail OK Партиция (после перезапуска)
45. Потеря дублей: выводы • Мы научились находить дефекты консистентности • Данные должны попасть на диск — только тогда запись прошла успешно • Потеря данных требует несколько скоординированных сбоев 45
46. Переупорядочивание данных 7 Прокси 8 46 Producer 6 5 Партиция Диск:
47. Переупорядочивание данных Прокси 47 Producer 8 7 6 5 Партиция Диск: OK OK
48. Переупорядочивание данных 7 Прокси 8 48 Producer 6 5 Партиция Диск:
49. Переупорядочивание данных 7 Прокси 8 49 Producer 6 5 Партиция Диск:
50. Переупорядочивание данных Прокси 50 Producer 8 6 5 Партиция Диск: 7
51. Переупорядочивание данных Прокси 51 Producer 8 6 5 Партиция Диск: OK OK
52. Переупорядочивание данных: выводы • Проблема в клиентском протоколе — он недостаточно жесткий • «Хороший» клиент, никогда не получит эту багу • Мы поменяли протокол — добавили упорядоченный внутри сессии номер записи 52
53. История о потерянном логе Партиция Распределенное хранилище Лог транзакций 3 4 5 6 2 1 53
54. История о потерянном логе Партиция Лог транзакций 3 4 6 2 1 54 Распределенное хранилище
55. История о потерянном логе Партиция Статус — запускается Лог транзакций 3 4 6 2 1 55 Распределенное хранилище
56. История о потерянном логе: выводы • Есть класс дефектов, которые проявляются как потеря доступности • Дефекты доступности невозможно обнаружить через нарушение инвариантов • Доступность системы — важная характеристика для реальных систем 56
57. Safety и Liveness Safety — ничего плохого не происходит
 Liveness — в конце концов произойдет что-то хорошее Все свойства системы можно описать как комбинацию safety + liveness свойств 57
58. Почему сложно проверять Liveness • Свойство liveness проявляется только на бесконечной истории событий в системе (в конце концов произойдет что-то хорошее) • «Impossibility of Distributed Consensus with One Faulty Process» Fisher, Lynch, Paterson (1985) aka «FLP result»
 http://the-paper-trail.org/blog/a-brief-tour-of-flp-impossibility/ • «FLP proves that any fault-tolerant algorithm solving consensus has runs that never terminate»
 http://www.cs.cornell.edu/courses/CS5412/2016sp/slides/XII%20- %20Consensus%20and%20FLP.pdf 58
59. Как находить liveness дефекты системы? • Какими liveness свойствами должна обладать система? • Как на практике описать свойства liveness для нашей очереди? • Какими способами можно обнаружить нарушение этих свойств? 59
60. Наш подход + Liveness Warden 6 5 4 3 7 2 Producer Consumer Nemesis Safety Warden 60 Liveness Warden Liveness Warden
61. Liveness Warden • Сложно проверять safety и liveness одновременно • Поэтому мы останавливаем Nemesis, на время проверки liveness • Проверяем идет ли прогресс записей/чтений (Producer/Consumer) • Если прогресса нет — liveness ошибка 61
62. О залипшем кеше П1 П2 П3 Кеш данных Node Producer Consumer 62
63. О залипшем кеше П1 П2 П3 Кеш данных Node Producer Consumer 63
64. О залипшем кеше: выводы • При определенных сбоях на ноде залипал кеш и чтения всегда возвращали ошибку. Записи при этом успешно проходили • Оптимизации производительности это хорошо, если они не нарушают гарантий системы • Новый компонент — новые баги • Возможна частичная потеря доступности 64
65. Забывчивый координатор К Координатор П1 — запущена Партиция Статус — запущена Consumer 65 Producer П
66. Забывчивый координатор К П Координатор П1 — запущена Партиция Статус — остановлена Consumer 66 Producer
67. Забывчивый координатор: выводы • При определенной комбинации сбоев координатор запуска партиций считал, что партиция запущена, но она была остановлена • Сложно обнаружить проблему, потому что перезапуск партиции или ноды устранял «залипание» • Главная проблема — полная недоступность партиции 67
68. 68 Заключение
69. 69 https://twitter.com/CompSciFact/status/791389830420762624
70. Выводы • Будь готов к сбоям — они неизбежно будут происходить • Изучай теорию — это помогает на практике • Знай свои инварианты — они описывают систему • Помни про liveness и доступность — эти свойства делают систему полезной 70
71. Андрей Сатарин Ведущий инженер по автоматизации тестирования https://twitter.com/asatarin asatarin@yandex-team.ru Контакты:
72. Ссылки • Testing Distributed Systems
 https://asatarin.github.io/testing-distributed-systems/ • Simple Testing Can Prevent Most Critical Failures
 https://www.usenix.org/conference/osdi14/technical-sessions/ presentation/yuan • Яндекс изнутри: инфраструктура хранения и обработки данных
 https://events.yandex.ru/events/meetings/15-oct-2016/ • Презентации Kyle Kingsbury
 http://jepsen.io/talks.html