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

Slide 1

Slide 1 text

No content

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

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

Slide 4

Slide 4 text

Распределенные системы в мире • MongoDB • Apache Cassandra • Apache Hadoop/MapReduce • Apache ZooKeeper • Apache Kafka • ElasticSearch 4

Slide 5

Slide 5 text

Распределенные системы в Яндексе • 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

Slide 6

Slide 6 text

Зачем нужны распределенные системы? • Производительность — много машин могут сделать больше работы в единицу времени, чем одна • Отказоустойчивость — сбой одной или нескольких машин не обязательно приводит к остановке системы 6

Slide 7

Slide 7 text

Производительность Sort benchmark (http://sortbenchmark.org/)   Мировой рекорд 2016 года: • 512 машин • Сортировка 100 TB данных за 134 секунды 7

Slide 8

Slide 8 text

Больше не буду говорить про производительность 8

Slide 9

Slide 9 text

Отказоустойчивость • Вероятность сбоя одного узла низкая (железо надежно) • Больше узлов — больше сбоев каждый день Пример: сбой одной машины раз в год, в кластере 500 машин — больше одного сбоя в день 9

Slide 10

Slide 10 text

Отказоустойчивость: сеть 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

Slide 11

Slide 11 text

Отказоустойчивость: диски 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

Slide 12

Slide 12 text

Отказоустойчивость: силы природы 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

Slide 13

Slide 13 text

https://twitter.com/mathiasverraes/status/632260618599403520 13

Slide 14

Slide 14 text

Распределенная персистентная очередь 14

Slide 15

Slide 15 text

Зачем нужна очередь? Очередь M … 1 Системы источники данных Системы потребители данных 15 N … 1 Очередь — M + N интеграций Нет очереди — M x N интеграций M + N << M x N

Slide 16

Slide 16 text

Очередь 6 5 4 3 7 2 First In First Out (FIFO) 16

Slide 17

Slide 17 text

Персистентная очередь 6 5 4 3 7 2 1 Алиса Боб 17

Slide 18

Slide 18 text

Распределенная персистентная очередь 6 5 4 3 7 2 e d c b f c Топик Партиция 0 Партиция 1 Топик + партиция == FIFO 2 1 a 18

Slide 19

Slide 19 text

Распределенная персистентная очередь: запись 6 5 Партиция Диск: 19 Producer 7 Прокси

Slide 20

Slide 20 text

Распределенная персистентная очередь: запись 7 6 5 Прокси Партиция Диск: 20 Producer OK

Slide 21

Slide 21 text

Распределенная персистентная очередь: запись 6 5 Прокси Партиция Диск: 21 Producer 7

Slide 22

Slide 22 text

Распределенная персистентная очередь: запись 6 5 Прокси Партиция Диск: 22 Producer Fail

Slide 23

Slide 23 text

Распределенная персистентная очередь: запись 6 5 Прокси Партиция Диск: 23 Producer 7 Fail

Slide 24

Slide 24 text

Распределенная персистентная очередь: запись ? ? 6 5 Прокси Партиция Диск: 24 Producer Fail OK

Slide 25

Slide 25 text

Семантика распределенных очередей • At most once —можем терять данные, нет дублей (/dev/null) • Exactly once — нет потерь, нет дублей (наша очередь) • At least once — не теряем данные, возможны дубли (Apache Kafka) 25

Slide 26

Slide 26 text

https://twitter.com/mojavelinux/status/751595888435294209 26

Slide 27

Slide 27 text

Подходы к тестированию (что уже сделано до нас) 27

Slide 28

Slide 28 text

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

Slide 29

Slide 29 text

Jepsen http://jepsen.io/ Kingsbury, 2015 29

Slide 30

Slide 30 text

Jepsen 30 Kingsbury, 2015

Slide 31

Slide 31 text

Наш подход к тестированию 31

Slide 32

Slide 32 text

Наш подход 6 5 4 3 7 2 Producer Consumer Nemesis Safety Warden 32

Slide 33

Slide 33 text

Producer • Пишет заранее известный поток данных • Соблюдает протокол взаимодействия с системой • Соблюдает single writer principle 33

Slide 34

Slide 34 text

Consumer • Читает данные и проверяет их корректность • Соблюдает протокол взаимодействия с системой • Несколько потребителей на одну пару топик + партиция 34

Slide 35

Slide 35 text

Nemesis • Немезида — в древнегреческой мифологии богиня возмездия против тех, кто высокомерен перед богами • У нас — инструмент для внесения разнообразных сбоев в систему (fault injection) • Сбои могут быть внешние (black box) и внутренние (white box) 35

Slide 36

Slide 36 text

Safety Warden Проверяет, что ничего плохого не произошло: • Очередь соблюдает внешние инварианты и exactly once семантику • Процесс не падает в корку • Нет out-of-memory ошибок • Нет критичных сообщений в логах 36

Slide 37

Slide 37 text

Баги и выводы 37

Slide 38

Slide 38 text

Потеря дублей 6 5 7 Прокси Партиция Диск: Память: 38 Producer

Slide 39

Slide 39 text

Потеря дублей 7 6 5 Прокси Партиция Диск: Память: 39 Producer OK

Slide 40

Slide 40 text

Потеря дублей 6 5 7 Прокси Партиция Диск: Память: 40 Producer

Slide 41

Slide 41 text

Потеря дублей 6 5 4 3 Прокси Партиция Диск: Память: 41 7 Producer Fail

Slide 42

Slide 42 text

Потеря дублей 6 5 4 3 Прокси Партиция Диск: Память: 42 7 Producer 7 Fail

Slide 43

Slide 43 text

Потеря дублей 6 5 4 3 Прокси Диск: Память: 43 7 Producer Fail 7 OK Партиция

Slide 44

Slide 44 text

Потеря дублей 6 5 4 3 Прокси Диск: Память: 44 Producer Fail OK Партиция (после перезапуска)

Slide 45

Slide 45 text

Потеря дублей: выводы • Мы научились находить дефекты консистентности • Данные должны попасть на диск — только тогда запись прошла успешно • Потеря данных требует несколько скоординированных сбоев 45

Slide 46

Slide 46 text

Переупорядочивание данных 7 Прокси 8 46 Producer 6 5 Партиция Диск:

Slide 47

Slide 47 text

Переупорядочивание данных Прокси 47 Producer 8 7 6 5 Партиция Диск: OK OK

Slide 48

Slide 48 text

Переупорядочивание данных 7 Прокси 8 48 Producer 6 5 Партиция Диск:

Slide 49

Slide 49 text

Переупорядочивание данных 7 Прокси 8 49 Producer 6 5 Партиция Диск:

Slide 50

Slide 50 text

Переупорядочивание данных Прокси 50 Producer 8 6 5 Партиция Диск: 7

Slide 51

Slide 51 text

Переупорядочивание данных Прокси 51 Producer 8 6 5 Партиция Диск: OK OK

Slide 52

Slide 52 text

Переупорядочивание данных: выводы • Проблема в клиентском протоколе — он недостаточно жесткий • «Хороший» клиент, никогда не получит эту багу • Мы поменяли протокол — добавили упорядоченный внутри сессии номер записи 52

Slide 53

Slide 53 text

История о потерянном логе Партиция Распределенное хранилище Лог транзакций 3 4 5 6 2 1 53

Slide 54

Slide 54 text

История о потерянном логе Партиция Лог транзакций 3 4 6 2 1 54 Распределенное хранилище

Slide 55

Slide 55 text

История о потерянном логе Партиция Статус — запускается Лог транзакций 3 4 6 2 1 55 Распределенное хранилище

Slide 56

Slide 56 text

История о потерянном логе: выводы • Есть класс дефектов, которые проявляются как потеря доступности • Дефекты доступности невозможно обнаружить через нарушение инвариантов • Доступность системы — важная характеристика для реальных систем 56

Slide 57

Slide 57 text

Safety и Liveness Safety — ничего плохого не происходит  Liveness — в конце концов произойдет что-то хорошее Все свойства системы можно описать как комбинацию safety + liveness свойств 57

Slide 58

Slide 58 text

Почему сложно проверять 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

Slide 59

Slide 59 text

Как находить liveness дефекты системы? • Какими liveness свойствами должна обладать система? • Как на практике описать свойства liveness для нашей очереди? • Какими способами можно обнаружить нарушение этих свойств? 59

Slide 60

Slide 60 text

Наш подход + Liveness Warden 6 5 4 3 7 2 Producer Consumer Nemesis Safety Warden 60 Liveness Warden Liveness Warden

Slide 61

Slide 61 text

Liveness Warden • Сложно проверять safety и liveness одновременно • Поэтому мы останавливаем Nemesis, на время проверки liveness • Проверяем идет ли прогресс записей/чтений (Producer/Consumer) • Если прогресса нет — liveness ошибка 61

Slide 62

Slide 62 text

О залипшем кеше П1 П2 П3 Кеш данных Node Producer Consumer 62

Slide 63

Slide 63 text

О залипшем кеше П1 П2 П3 Кеш данных Node Producer Consumer 63

Slide 64

Slide 64 text

О залипшем кеше: выводы • При определенных сбоях на ноде залипал кеш и чтения всегда возвращали ошибку. Записи при этом успешно проходили • Оптимизации производительности это хорошо, если они не нарушают гарантий системы • Новый компонент — новые баги • Возможна частичная потеря доступности 64

Slide 65

Slide 65 text

Забывчивый координатор К Координатор П1 — запущена Партиция Статус — запущена Consumer 65 Producer П

Slide 66

Slide 66 text

Забывчивый координатор К П Координатор П1 — запущена Партиция Статус — остановлена Consumer 66 Producer

Slide 67

Slide 67 text

Забывчивый координатор: выводы • При определенной комбинации сбоев координатор запуска партиций считал, что партиция запущена, но она была остановлена • Сложно обнаружить проблему, потому что перезапуск партиции или ноды устранял «залипание» • Главная проблема — полная недоступность партиции 67

Slide 68

Slide 68 text

68 Заключение

Slide 69

Slide 69 text

69 https://twitter.com/CompSciFact/status/791389830420762624

Slide 70

Slide 70 text

Выводы • Будь готов к сбоям — они неизбежно будут происходить • Изучай теорию — это помогает на практике • Знай свои инварианты — они описывают систему • Помни про liveness и доступность — эти свойства делают систему полезной 70

Slide 71

Slide 71 text

Андрей Сатарин Ведущий инженер по автоматизации тестирования https://twitter.com/asatarin asatarin@yandex-team.ru Контакты:

Slide 72

Slide 72 text

Ссылки • 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