Jepsen (Distributed Systems Safety Research)

Сегодня я решил вспомнить про jepsen, clojure библиотеку, которая позволяет тестировать распределенные системы. Почему именно сейчас? Потому что на этой неделе я делал ревью доклада для ArchDays на тему эмулирования сбоев. В рамках ревью я вспомнил про библиотеку Jepsen и мы немного обсудили подход Kyle Kingsbury, автора библиотеки, к тестированию гарантий и отказов в распределенных системах. В общем и целом, мне нравится подход Кайла и я считаю его полезным для применения, поэтому я решил написать этот пост:)

Кайл отлично рассказал о своем подходе в 2018 году на конференции GOTO (рекомендую посмотреть видео - оно сделано с юмором и кучей информации). На его сайте есть краткое описание работы библиотеки Jepsen analyses generally consist of running operations against a distributed system in a dedicated cluster, introducing faults into that cluster, and observing whether the results of those operations are consistent with some model. This introduces various sources for error: bugs, bounds on the search space, and the problem of induction. Jepsen’s design also limits its use as a performance benchmark.

На этом же сайте есть крутая схема моделей консистентности, соответствие которым проверяется в тестах. Плюс есть отдельный раздел с результатами анализа разных баз, которых накопилось больше 20 за 10 лет исследований.

Но если если возвращаться к выступлению 2018 года, то там Кайл сначала рассказывает по сложности работы stateful сервисов, а точнее баз данных, приводя метафору с горящей кучей покрышек, над которой развернуты приложения, которые предоставляют API клиентам, которые делают вид, что все хорошо. Дальше он рассказывает про виды проблем в распределенных системах и рассказывает про результаты исследований популярных продуктов и проблемы, найденные в них.

А в конце выпустления он доходит до практических советов по поводу выбора базы данных / очереди для вашего продукта делать следующее

• читать документацию и искать предоставляемые этим решением гарантии
• если там написано просто strong consistency, ACID, strict и ничего больше, то возможно авторы базы данных не понимают что это значит (или скрывают реальные гарантии за marketing bullshit)
• смотреть на формальные гарантии и спецификации
• думать про те инварианты и гарантии, которые важны для вашей системы (баланс между safety/consistency и performance)
• думать про модели отказа (failure modes) и конкретно про -- краши процессов (kill -9) -- откзаы машин -- clock skew -- паузы на gc/io -- разделения сети (network partition) (iptables -j DROP)
• тестировать систему end-to-end, а не только базу или очередь - это позволит проверить работоспособность пользовательских сценариев целиком
• не быть перфекционистом и остановиться в тестировании системы на good enough уровне

#DistributedSystems #QualityAssurance #SystemDesign #Engineering #Software #Architecture #SoftwareArchitecture #SoftwareDevelopment #SRE