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

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

Andrey Satarin
December 10, 2016

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

https://youtu.be/h8RV4JfSovg

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

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

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

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

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

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

Andrey Satarin

December 10, 2016
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

    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

    View Slide

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

    View Slide

  7. Производительность
    Sort benchmark (http://sortbenchmark.org/) 

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

    View Slide

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

    View Slide

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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

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

    View Slide

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

    View Slide

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

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

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

    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

    View Slide

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

    View Slide

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

    View Slide

  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

    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. Переупорядочивание данных
    7
    Прокси
    8
    46
    Producer
    6 5
    Партиция
    Диск:

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

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

    View Slide

  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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  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

    View Slide