$30 off During Our Annual Pro Sale. View Details »

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

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

"Тестирование распределенных систем" на DUMP 2017
http://dump-conf.ru/section/32/#talk_205
Видео
https://youtu.be/QXtr30paTl8

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

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

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

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

Andrey Satarin

April 14, 2017
Tweet

More Decks by Andrey Satarin

Other Decks in Technology

Transcript

  1. View Slide

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

    View Slide

  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

    View Slide

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

    View Slide

  5. Распределенные системы в Яндексе
    • YT — платформа вычислений в парадигме Map/Reduce [YT]
    • Yandex Query Language — декларативный язык запросов к системе
    обработки данных [YQL]
    • Media Storage —распределенная система хранения данных [MDS]
    • ClickHouse — открытая колоночная распределенная база
    данных [CH] [CH2]
    Подробная информация на встрече «Яндекс изнутри»
    5

    View Slide

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

    View Slide

  7. Производительность
    Sort benchmark [SRT] 

    Мировой рекорд 2016 года
    • 512 машин
    • Сортировка 100 TB данных за 134 секунды
    7

    View Slide

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

    View Slide

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

    View Slide

  10. Отказоустойчивость: сеть
    The Network is Reliable [NR]
    «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

    View Slide

  11. Отказоустойчивость: диски
    One Billion Drive Hours and Counting: Q1 2016 Hard Drive Stats [HDD]

    «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 [SND]

    «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

    View Slide

  12. Отказоустойчивость: силы природы
    Google data center loses data following four lightning strikes [LHT]


    «However, four successive lightning strikes on the electrical systems of
    its data center pushed the buffering and backups to their limits.»
    12

    View Slide

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

    View Slide

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

    View Slide

  15. Зачем нужна очередь?
    Очередь
    M

    1
    Системы
    источники
    данных
    Системы
    потребители
    данных
    N

    1
    Очередь — M + N интеграций
    Нет очереди — M x N интеграций
    M + N << M x N
    15

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  28. Netflix Chaos Monkey
    • Давно развивается компанией Netflix
    • Работает на Amazon Web Services
    • Запускается в продуктивном окружении
    • Про нее многие знают
    [CM] [CM2]
    28

    View Slide

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

    View Slide

  30. Jepsen
    30
    Kingsbury, 2015

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  50. Safety и Liveness
    Safety — ничего плохого не происходит

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  57. 57
    Заключение

    View Slide

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

    View Slide

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

    View Slide

  60. Андрей Сатарин
    Ведущий инженер по автоматизации тестирования
    https://twitter.com/asatarin
    [email protected]
    Контакты:
    60

    View Slide

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

    View Slide