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

Привет, Вы узнаете о том , что такое тестирование распределенных систем, Разберем основные их виды и особенности использования. Еще будет много подробных примеров и описаний. Для того чтобы лучше понимать что такое тестирование распределенных систем, внедрения сбоя, fault injection, simian army, армия макак , настоятельно рекомендую прочитать все из категории Качество и тестирование программного обеспечения. Quality Assurance..

тестирование распределенных систем существенно отличается от тестирования централизованных. Немногие тестировщики могут похвастаться серьезными знаниями и опытом в этой области.

Способы и особенности тестирования распределенных систем

• – Какие методики и стратегии тестирования распределенных систем существуют? Чем они отличаются?
• – Кроме всем известных классических подходов (модульное тестирование, системное тестирование, интеграционное тестирование) для распределенных систем есть дополнительные подходы, которые призваны обнаруживать сложные дефекты.

Очень популярен подход внедрения сбоя (fault injection). Когда система работает, мы при помощи специальных программ и механизмов добавляем сбои: сбои дисков или целых машин, может быть, сетевые сбои, сбои внутренних компонентов тестируемой системы. Поскольку подавляющее большинство распределенных систем должны обладать устойчивостью к подобного рода сбоям, по крайней мере в каких-то ограниченных масштабах, то система не должна прекращать свою работу или проявлять каких-то аномалий в работе. По сути это тестирование на отказоустойчивость, поскольку это одно из важнейших нефункциональных требований к распределенным системам. Чем больше машин работает, тем выше вероятность индивидуальной проблемы на какой-то из них. Например, если задействована тысяча машин, то, условно говоря, диски будут вылетать раз в неделю. Система обязана переживать такие ситуации никоим образом их не замечая.

Есть более академические подходы, например, формальная верификация (formal verification). В распределенных системах есть внутренние алгоритмы и протоколы, которые позволяют ей работать. Они сами по себе достаточно сложные, но гарантируют некоторые инварианты, которые должны достигаться всегда, независимо от каких-либо сбоев в системе, переупорядочивания пакетов в сети и чего-либо еще. Суть подхода заключается в том, что на основе только описания алгоритма на специальном языке проверяется его корректность. Это дает уверенность в том, что тот алгоритм, который используется, при условии, что он корректно реализован, будет работать.

В 2015 году вышла академическая статья от Microsoft Research «Proving Practical Distributed Systems Correct», где они описали модель системы распределенного хранилища, после чего с помощью специальных инструментов проверили эту модель на корректность, а затем сгенерировали код, который сразу же заработал.

• – Какие особенности необходимо учитывать при тестировании распределенных систем?
• – Особенность в том, что важно понимать какие именно инварианты гарантирует тестируемая система.

Например, сейчас популярны nosql базы данных, которые могут быть более высокопроизводительными, но они не поддерживают транзакции. То есть их уровень консистентности ниже, чем у классических (MySql, PostgreSQL, Oracle). И, когда происходит тестирование такой распределенной системы, типа nosql базы данных, важно, чтобы было понимание какие именно инварианты она поддерживает. От этого зависят аномалии, которые будут наблюдаться в тестах. В сложных тестах, например, когда есть несколько конкурентных писателей и читателей, можно увидеть много различных состояний. Другими словами, нужно понимать, какие эффекты можно наблюдать в системе, а какие — нет.

Нефункциональные требования играют наиболее существенную роль

• – Какие типичные ошибки совершают сами люди при тестировании распределенных систем?
• – Самая распространенная ошибка — это проверка не всех гарантий, которые система должна предоставлять, в этом случае система становится недотестирована. Об этом говорит сайт https://intellect.icu . Вторая ошибка, которая может дорого стоить, это не тестирование на отказ какой-то части системы. По опыту, если в распределенной системе какая-то подсистема не тестировалась на fault injection, то багов там чуть более, чем очень много.
• – Какие метрики и характеристики распределенной системы важно тестировать и почему?
• – Из нефункциональных требований это, во-первых, отказоустойчивость (fault tolerance), а во-вторых, это производительность (perfomance). Для распределенных систем нефункциональные требования играют наиболее существенную роль по сравнению с функциональными требованиями. Fault tolerance на первом месте, потому что сначала система должна работать, а если она не работает, то остальное уже не так важно.
• – Насколько важна производительность тестов? Нужно ли учитывать возможные задержки сети при разработке тестов для распределенной системы?
• – Это зависит от видов тестов, о которых идет речь. Если это модульные тесты, то производительность важна. В общем случае, конечно, лучше иметь быстрые тесты (как говорится, лучше быть здоровым и богатым). Это верно для функциональных тестов. Для нефункциональных, которые проверяют, например, консистентность или устойчивость к сбоям, производительность тестов важна для более частого проявления дефектов. Например, если дефект проявляется один раз на миллион операций, то чем чаще происходят эти операции, тем чаще проявляется и дефект. Если это занимает час, то это вполне приемлемо. Если это занимает несколько дней, то поиск таких дефектов становится проблемой.
  

98% всех дефектов можно воспроизвести всего лишь на 3 нодах

– Нужно ли создавать специальные кластера для тестирования или можно использовать «боевые» кластера, которые находятся в продакшене? Как определить оптимальный размер тестового кластера?

– Чаще всего применяют именно тестовые кластера. Если говорить про тестирование на боевых серверах, то самый широко известный пример — это компания Netflix, которая активно пропагандирует свой подход, называемый «simian army», то есть « армия макак ». Он заключается в том, что они в продакшене делают fault injection. Они убивают ноды прямо в рабочее время и разработчики наблюдают за тем, чтобы система никак при этом не деградировала. Но здесь надо понимать, что такая возможность появляется только начиная с какого-то масштаба. Если система работает на 10-20 нодах, то тестирование подобным образом означает, что будет деградация на 5-10%. В продакшене не все готовы на такие жертвы. Кроме того, может быть какой-то service level agreement (SLA) и такое тестирование может быть дорого из-за его нарушения. В любом случае, даже если встречается практика тестирования на продакшене, то существует перед этим огромная тестовая инфраструктура, которая отлавливает большую часть дефектов. Преимущество тестирования в продакшене только в том, что нет необходимости повторять продуктивное окружение.

По поводу размера тестового кластера. Если система распределенная, то он должен быть больше единицы — это ограничение снизу. На тему ограничений сверху есть статья «Simple Testing Can Prevent Most Critical Failures», в которой исследуется вопрос о том, какие ошибки есть в распределенных системах. Согласно статье, исследователи пришли к выводу, что 98% всех дефектов можно воспроизвести всего лишь на 3 нодах. Конкретно в нашей работе мы используем больше, обычно тестовый кластер состоит из 8 нод, но это связано с внутренним устройством нашей системы.

– Как бороться с полными или частичными отказами распределенной системы во время тестирования?

– Каких-то особых способов борьбы с этим, наверно, нет, потому что в тестовом окружении масштабы сильно меньше. Если сбойное железо сильно мешает, его можно просто исключить из тестового окружения. У нас был случай, когда в тестовом железе происходил сбой, но мы были скорее этому рады, поскольку это позволило нам найти некоторые необычные дефекты. Так как распределенная система должна быть устойчивой к сбоям, то даже в тестах это не должно вызывать никаких проблем.

– Какие конкретно технологии и инструменты используются для создания тестового окружения? Для автоматизации тестирования?

– Тестовое окружение зависит от технологий, которые используются для разработки, и от технологий, которые знакомы команде. Мы, например, активно используем Python, потому что он хорошо подходит для таких задач и наши тестировщики его знают. Он простой в плане написания тестов, достаточно высокоуровневый, чтобы на нем можно было писать понятно. На мой взгляд, у него немного «беда» с concurrency, но эта проблема решаема. Сама система разрабатывается на C++, но его использовать для высокоуровневых тестов достаточно тяжело, так как быстро и легко разрабатывать на нем не получится, а в тестах бывает важна скорость разработки.

По поводу автоматизации тестирования. Обычно строится репозиторий тестов, которые автоматически запускаются на специальном сервере. Мы для этого используем TeamCity и некоторые наши внутренние разработки.

– У тебя есть еще что-нибудь, что ты бы хотел добавить по теме?

– Я бы хотел добавить, что на тему тестирования распределенных систем есть огромное количество материалов как академических, так и близких к индустрии, огромное множество подходов и способов тестирования. Поиск методов и их совершенствование не останавливается ни на день. Эта тема постоянно развивается – и именно этим она интересна.

Обезьяна хаоса, инструмент, который случайным образом отключает наши производственные экземпляры, чтобы убедиться, что мы сможем пережить этот распространенный тип сбоя без какого-либо воздействия на клиента.Название происходит от идеи высвободить дикую обезьяну с оружием в вашем центре обработки данных (или облачном регионе), чтобы случайным образом сбивать экземпляры и пережевывать кабели - все это время мы продолжаем беспрерывно обслуживать наших клиентов. Запустив Chaos Monkey в середине рабочего дня в тщательно контролируемой среде с инженерами, готовыми решить любые проблемы, мы все равно можем извлечь уроки о слабых местах нашей системы и создать механизмы автоматического восстановления для их устранения. Так что в следующий раз, когда произойдет сбой инстанса в 3 часа ночи в воскресенье, мы этого даже не заметим.

Вдохновленные успехом Обезьяны Хаоса, мы начали создавать новых обезьян, которые вызывают различные виды сбоев или обнаруживают ненормальные условия и проверяют нашу способность выжить в них; виртуальная обезьянья армия, обеспечивающая безопасность, надежность и высокую доступность нашего облака.

Latency Monkey вызывает искусственные задержки на нашем уровне связи клиент-сервер RESTful, чтобы моделировать ухудшение качества обслуживания, и измеряет, реагируют ли вышестоящие службы надлежащим образом. Кроме того, делая очень большие задержки, мы можем смоделировать время простоя узла или даже всего сервиса (и проверить нашу способность пережить это) без физического отключения этих экземпляров. Это может быть особенно полезно при тестировании отказоустойчивости новой службы путем моделирования сбоя ее зависимостей, не делая эти зависимости недоступными для остальной системы.

Conformity Monkey находит экземпляры, которые не соответствуют лучшим практикам, и закрывает их. Например, мы знаем, что если мы найдем экземпляры, которые не принадлежат к группе автомасштабирования, это ожидает неприятностей. Мы закрыли их, чтобы дать владельцу сервиса возможность перезапустить их должным образом.

Doctor Monkey подключается к проверкам работоспособности, которые выполняются на каждом экземпляре, а также отслеживает другие внешние признаки работоспособности (например, загрузку процессора) для обнаружения нездоровых экземпляров. После обнаружения неработоспособных экземпляров они удаляются из службы, и после предоставления владельцам службы времени для устранения основной причины проблемы в конечном итоге прекращаются.

Janitor Monkey гарантирует, что в нашей облачной среде нет беспорядка и отходов. Он ищет неиспользуемые ресурсы и избавляется от них.

Security Monkey - это расширение Conformity Monkey. Он обнаруживает нарушения безопасности или уязвимости, такие как неправильно настроенные группы безопасности AWS, и устраняет нарушающие инстансы. Это также гарантирует, что все наши сертификаты SSL и DRM действительны и не подлежат продлению.

10–18 Monkey (сокращение от Localization-Internationalization или l10n-i18n) обнаруживает проблемы конфигурации и времени выполнения в случаях, когда обслуживает клиентов в нескольких географических регионах, используя разные языки и наборы символов.

Chaos Gorilla похожа на Chaos Monkey, но имитирует отключение всей зоны доступности Amazon. Мы хотим убедиться, что наши услуги автоматически перенастраиваются в функциональные зоны доступности без видимого пользователем воздействия или ручного вмешательства.

Вау!! 😲 Ты еще не читал? Это зря!

• тестирование
• тестировщик

Исследование, описанное в статье про тестирование распределенных систем, подчеркивает ее значимость в современном мире. Надеюсь, что теперь ты понял что такое тестирование распределенных систем, внедрения сбоя, fault injection, simian army, армия макак и для чего все это нужно, а если не понял, или есть замечания, то не стесняйся, пиши или спрашивай в комментариях, с удовольствием отвечу. Для того чтобы глубже понять настоятельно рекомендую изучить всю информацию из категории Качество и тестирование программного обеспечения. Quality Assurance.