Lock in $30 Savings on PRO—Offer Ends Soon! ⏳

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

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. 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
  2. Распределенные системы в мире • MongoDB • Apache Cassandra •

    Apache Hadoop/MapReduce • Apache ZooKeeper • Apache Kafka • ElasticSearch 4
  3. Распределенные системы в Яндексе • 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
  4. Зачем нужны распределенные системы? • Производительность — много машин могут

    сделать больше работы в единицу времени, чем одна • Отказоустойчивость — сбой одной или нескольких машин не обязательно приводит к остановке системы 6
  5. Производительность Sort benchmark (http://sortbenchmark.org/) 
 Мировой рекорд 2016 года: •

    512 машин • Сортировка 100 TB данных за 134 секунды 7
  6. Отказоустойчивость • Вероятность сбоя одного узла низкая (железо надежно) •

    Больше узлов — больше сбоев каждый день Пример: сбой одной машины раз в год, в кластере 500 машин — больше одного сбоя в день 9
  7. Отказоустойчивость: сеть 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
  8. Отказоустойчивость: диски 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
  9. Отказоустойчивость: силы природы 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
  10. Зачем нужна очередь? Очередь M … 1 Системы источники данных

    Системы потребители данных 15 N … 1 Очередь — M + N интеграций Нет очереди — M x N интеграций M + N << M x N
  11. Распределенная персистентная очередь 6 5 4 3 7 2 e

    d c b f c Топик Партиция 0 Партиция 1 Топик + партиция == FIFO 2 1 a 18
  12. Семантика распределенных очередей • At most once —можем терять данные,

    нет дублей (/dev/null) • Exactly once — нет потерь, нет дублей (наша очередь) • At least once — не теряем данные, возможны дубли (Apache Kafka) 25
  13. 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
  14. Producer • Пишет заранее известный поток данных • Соблюдает протокол

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

    протокол взаимодействия с системой • Несколько потребителей на одну пару топик + партиция 34
  16. Nemesis • Немезида — в древнегреческой мифологии богиня возмездия против

    тех, кто высокомерен перед богами • У нас — инструмент для внесения разнообразных сбоев в систему (fault injection) • Сбои могут быть внешние (black box) и внутренние (white box) 35
  17. Safety Warden Проверяет, что ничего плохого не произошло: • Очередь

    соблюдает внешние инварианты и exactly once семантику • Процесс не падает в корку • Нет out-of-memory ошибок • Нет критичных сообщений в логах 36
  18. Потеря дублей 6 5 4 3 Прокси Диск: Память: 44

    Producer Fail OK Партиция (после перезапуска)
  19. Потеря дублей: выводы • Мы научились находить дефекты консистентности •

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

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

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

    — в конце концов произойдет что-то хорошее Все свойства системы можно описать как комбинацию safety + liveness свойств 57
  23. Почему сложно проверять 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
  24. Как находить liveness дефекты системы? • Какими liveness свойствами должна

    обладать система? • Как на практике описать свойства liveness для нашей очереди? • Какими способами можно обнаружить нарушение этих свойств? 59
  25. Наш подход + Liveness Warden 6 5 4 3 7

    2 Producer Consumer Nemesis Safety Warden 60 Liveness Warden Liveness Warden
  26. Liveness Warden • Сложно проверять safety и liveness одновременно •

    Поэтому мы останавливаем Nemesis, на время проверки liveness • Проверяем идет ли прогресс записей/чтений (Producer/Consumer) • Если прогресса нет — liveness ошибка 61
  27. О залипшем кеше: выводы • При определенных сбоях на ноде

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

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

    происходить • Изучай теорию — это помогает на практике • Знай свои инварианты — они описывают систему • Помни про liveness и доступность — эти свойства делают систему полезной 70
  30. Ссылки • 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