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

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