Нагрузочное тестирование во многом схоже с учениями по ГО и ЧС. Лучше заранее понимать, как будет выглядеть та или иная ситуация, чем пытаться в панике сориентироваться. Помимо собственных тестов и собранных на production проблем, можно перенять опыт коллег по индустрии. Специально для проекта «Календарь тестировщика» Дмитрий Воротников, тестировщик Контура, на примере ЧП крупных IT-компаний вывел несколько простых, но важных правил тестирования сервиса.
Изменившийся профиль нагрузки
Когда говорят о нагрузочном тестировании обычно имеют ввиду capacity testing. У онлайн-магазинов есть Black Friday и Cyber Monday — время распродаж и экстремального увеличения нагрузки на все сервисы. В Контуре похожие скачки трафика бывают в последние дни отчетности в контролирующие органы. По какой бы причине ни выросло число посетителей, нельзя допустить недоступности операций, ошибки или увеличения времени ответа. С помощью тестирования емкости сервиса мы убедимся, что пользователи не будут злобно дергать мышкой или уходить к конкурентам, а смогут комфортно и продуктивно работать.
Проводя тестирование с профилем нагрузки, повторяющим типовой за последние месяц, год или два, можно столкнуться с проблемой, какая была у Amazon Simple Storage Service 15 февраля 2008 года. Доступ к данным в S3 регулируется AWS Authentication service. Запросы к нему зашифрованы и требуют на обработку больших вычислительных ресурсов. Amazon поддерживали столько серверов, сколько было необходимо для обработки нагрузки предыдущих двух лет. В отчетный день в 3:30 утра инженеры заметили, что количество аутентификационных запросов увеличилось. Это перегрузило инфраструктуру AWS и стало невозможно обрабатывать все запросы. Чтобы обработать возросшую нагрузку, пришлось вводить дополнительные мощности. До 6:48 все проекты, использовавшие S3, были недоступны.
Учитывайте возможное изменение профиля нагрузки, когда планируете емкость сервиса и при нагрузочных тестах.
Нерегулярность
Недостаточно проводить единичное или эпизодическое тестирование, даже с учетом возможного изменения профиля нагрузки. Особенно если у вас постоянно растет количество пользователей или новых интеграций.
В среду, 22 декабря 2010 мессенджер Skype начал работать с ошибками. Чтобы установить соединение требовалось все больше и больше времени, пока наконец сервис совсем не прекратил работу. Триггером проблемы стала перегрузка ряда серверов, обрабатывающих мгновенные сообщения. Обработка их стала занимать заметно больше времени. Это замедление столкнулось с ошибкой в клиенте для Windows, что привело к их падениям. Значительная часть клиентов (суперноды) поддерживала P2P обмен между другими клиентами. Из-за отказа 25—30% супернод, оставшиеся оказались перегружены и отказывали, еще больше увеличивая нагрузку. В результате такого каскадного отказа сеть Skype была недоступна около суток.
Проводите тестирование и пересматривайте возможности вашего сервиса регулярно.
Побочный эффект
Когда вы планируете регулярное тестирование и разрабатываете его сценарии, учитывайте, что и форс-мажоры могут увеличить нагрузку. Разнесение сервиса по нескольким дата-центрам не прибавит отказоустойчивости, если один выйдет из строя, а оставшиеся не смогут обработать его нагрузку. Планирование емкости должно учитывать подобные сценарии. Еще один вариант повышения нагрузки — намеренно вносить в систему изменения, например, обновления софта или проведение работ.
24 февраля 2009 года к проблемам с GMail привела новая фича, которая позволяла хранить письма географически ближе к отправителям. Во время технических работ пользователей одного дата-центра перенаправили в другой, перегрузив его. Это вызвало каскад отказов от дата-центра к дата-центру, каждый из которых принимал все большую нагрузку. Сервис был недоступен два с половиной часа. Эта история получила прозвище Gfail.
Из этого постмортема можно сделать два связанных вывода. Первый — сервис и его окружение постоянно меняются, значит, нужно тестировать сценарии проведения технических работ или отключения сервисов и серверов. Второй — учитывайте результаты тестов при работах и актуализируйте их перед изменениями и отключениями.
Неготовность к отказу
Чтобы избежать downtime'a и добавить девяток в метрику availability, нужно знать какую нагрузку может выдержать ваш сервис, регулярно актуализировать это знание, поддерживать его доступность и пользоваться им при внесении различных изменений. Проектируя и разрабатывая сервис, мы применяем множество мер, которые обеспечивают защиту от перегрузок, каскадных отказов, отключения электроэнергии, выхода из строя оборудования и потери данных. Это многообразие, к сожалению, не панацея от ошибок в реализации, конфигурации и человеческого фактора.
19 июля 2010 сайт крупного американского онлайн-ритейлера American Eagle Outfitters стал недоступен из-за отказа основного хранилища. Не беда, ведь есть же бэкапы! Однако, переключение на резервное хранилище привело и к его отказу. Не страшно, ведь были еще бэкапы на магнитной ленте. Их долго восстанавливали, потом попытались запустить сайт на резервной площадке, но и она провалилась. Резервная площадка оказалась не готова, хотя ее должны были подготовить заранее. Несмотря на широкий спектр защитных мер, восстановить возможность принимать заказы удалось за 4 дня. Еще 4 дня потребовалось на полное восстановление.
Проведя нагрузочное тестирование и выявив возможности сервиса, не забудьте протестировать защитные механизмы, failover и ваши резервные копии.
И напоследок, храните в доступном месте информацию обо всех падениях сервиса, хронологию падения и анализ причин, которые к нему привели. Это поможет всей команде разработчиков и тестировщиков лучше изучить фейл и найти новые подходы к его решению.
Автор: ylian_demakova
