[Перевод] Падение Slack 4 января 2021
4 января 2021 года для многих людей во всем мире, также как и для большинства работников Slack был первым рабочим днем после нового года (за исключением специалистов горячей линии и службы поддержки, которые никогда не спят). В день Азии и утро в Европе прошло спокойно, но когда забрезжил рассвет в Америке мы стали получать сообщения от внешней службы мониторинга о росте количества ошибок. Мы начали разбираться, в чем дело. Ситуация с ошибками ухудшалась и мы инициировали процесс расследования инцидентов (о том, как у нас устроено управление инцидентами подробнее можно почитать в статье Райана Каткова (Ryan Katkov) All Hands on Deck https://slack.engineering/all-hands-on-deck/).
Как будто нам этого было недостаточно для того, чтобы окончательно испортить первый рабочий день нового года, в тот момент, мы пытались понять, что происходит, упали сервисы панелей мониторинга и оповещений. Мы связались с группой мониторинга, чтобы они попытались восстановить их как можно быстрее.
Чтобы сократить список возможных причин мы по-быстрому откатили некоторые изменения, которые были сделаны сегодня (забегая вперед — дело было не в них). Также мы подключили еще нескольких человек из инфраструктурных групп, потому что процесс поиска сбоя шел медленно из-за того, что не работали панели мониторинга и оповещения. У нас сохранялся доступ к различным внутренним консолям и страницам статуса, к некоторым консольным утилитам, а также к системе сбора логов. Система сбора метрик тоже функционировала и мы могли запускать запросы к ней напрямую, но это было и совсем не так результативно, как как использование наших панелей мониторинга с преднастроенными запросами. Хотя наша инфраструктура в целом функционировала, мы видели признаки деградации сети, о чем мы сообщили AWS, нашему основному облачному провайдеру. На тот момент Slack работал — в 6:57 по тихоокеанскому стандартному времени 99% сообщений успешно доставлялись (хотя это не было нормой, поскольку наше обычное значение этого параметра 99.999%).
Трафик в Slack имеет характерные всплески в начале и середине каждого часа, когда уведомления и другие типы автоматически создаваемых сообщений (большая часть из них внешняя — это задачи cron со всего мира). У нас настроено масштабирование звена веб-служб и бэкэнда для того, чтобы подстроится под эти пики. Тем не менее всплеск нагрузки в 7 утра в сочетании с проблемами сетевой инфраструктуры привел к перегрузке звена веб-служб. С ростом нагрузки стали расти потери пакетов. Это, в свою очередь, привело к большим задержкам обращений веб-служб к бэкэнду, и их перегрузке. Slack упал.
В это время независимо друг от друга происходили две вещи. Во-первых, некоторые инстансы были автоматически помечены системой как проблемные, потому что они не могли достучаться до служб бэкэнда, от которых они зависели. Система попыталась заменить их новыми. Во-вторых, наша система автоматического масштабирования уменьшила размеры звена веб-сервисов. Так как мы работали без панелей мониторинга, некоторые инженеры, которые вели работы по данному инциденту подключались напрямую к сервисам, работающим на проде. У многих из них начали прерываться сессии SSH, потому что инстансы, с которыми они работали были отключены системой. Это еще больше затрудняло наши попытки разобраться в ситуации, поэтому мы отключили автоматическое уменьшение размеров системы. Это упростило работу по поиску сбоя и позволило стабилизовать производительность системы.
Наше звено веб-сервисов масштабируется на основании двух видов сигналов. Один из них, это загрузка процессоров (метрика, которая используется для масштабирования практически везде), а другой, это загрузка доступных рабочих потоков Apache. Проблемы с сетью до 7:00 означали, что потоки находились больше времени в режиме ожидания, что приводило к уменьшению загрузки процессоров, а это инициировало автоматическое уменьшения количества инстансов. Поскольку состояние сети продолжало ухудшаться, из-за чего звено веб-служб больше времени находилось в ожидании ответа от бэкэнда, что приводило к увеличению загрузки рабочих потоков, и система автоматически увеличила количество инстансов веб-служб. Между 7:01 и 7:15 мы попытались добавить 1200 серверов в наше звено веб-сервисов.
К сожалению, наше масштабирование не отработало как полагается. У нас работает сервис, удачно названный «службой обеспечения» (в оригинале «provision-service» — прим. пер.) и его название полностью отражает его функционал, в который входит настройка и тестирование новых инстансов, а также выполнение роли управляющего для инфраструктуры. Службе обеспечения нужно взаимодействовать с внутренними системами Slack и c API AWS, а поскольку это взаимодействие происходило по той же нестабильной сети и поскольку, как и большинство систем Slack на тот момент, он тратил больше времени на соединение и получение ответа, и использовал больше ресурсов, чем обычно. Пиковая нагрузка, связанная с необходимостью ввести одновременно большое число инстансов в условиях нестабильной сети привело к тому, что служба обеспечения уперлась в системные ограничения (наиболее значимым из которых было ограничение количества открытых файлов в Linux, но также были превышены и квоты AWS).
Пока мы пытались восстановить работу службы обеспечения, производительность звена веб-сервисов оставалась недостаточной для восстановления нормальной работы из-за того, что масштабирование системы не работало как надо. У нас было запущено большое число инстансов, но большая часть из них не была до конца настроена службой обеспечения и не работала. Большое количество сбойных инстансов привели к тому, что мы достигли предварительно установленного лимита автомасштабирования для нашего звена веб-сервисов, который кратен количеству инстансов, обычно требующихся для того, чтобы справиться с пиковым трафиком. Часть специалистов, работающих над данным инцидентом, занялись тем, что вручную удаляли неработающие инстансы, остальные продолжали искать источник проблемы. Ко всему этому у нас до сих пор не работала служба панелей мониторинга, мы не могли ее запустить из-за того, что служба обеспечения была перегружена.
В один прекрасный момент служба обеспечения заработала (было около 8:15) и начала запускать работающие инстансы. Ситуация стала понемногу улучшаться. У нас по-прежнему были некоторые проблемы с продом, часть из которых удалось смягчить, а другая была в процессе решения. Также мы до сих пор испытывали проблемы связанные с повышенным уровнем потери пакетов в сети. Несмотря на это в 9:15 у нашего звена веб-сервисов было достаточно работающих узлов чтобы переваривать входящий трафик. Из-за проблем с сетью балансировщики нагрузки показывали большое число проблемных узлов, но к счастью у них был режим «panic mode» https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/upstream/load_balancing/panic_threshold в котором балансеры начинают распределять нагрузку на все узлы независимо от результатов проверки их состояния. Это, плюс повторные соединения и паттерн circuit breaking, помогли нам возобновить работу сервиса. Да, Slack был медленнее, чем обычно, и частота ошибок была выше, но в 9:15 он уже работал, а не лежал, как до этого. Целый час ушел на то, чтобы снизить частоту ошибок до приемлемого уровня по двум причинам. Во-первых, из-за нестабильности сети нам требовалось больше инстансов, чем обычно, чтобы нормально обслуживать входящий трафик. Во-вторых, больше времени ушло на процесс развертывания опять же из-за проблем с сетью.
К тому времени, как Slack восстановился, инженеры AWS нашли причину сбоя: часть нашей сетевой инфраструктуры AWS действительно была перегружена, что и приводило к потерям пакетов.
Чтобы было проще понять, что же произошло, стоит рассказать немного подробней о некоторых архитектурных особенностях Slack. На старте, не так уж много лет назад, все, что касается работы Slack работало в одном аккаунте AWS. По мере роста размера, сложности и количества специалистов, задействованных в обслуживании системы, мы отказались от этого решения и разнесли сервисы по различным аккаунтам и VPC (Virtual Private Clouds). Это решение позволило нам добиться большей изолированности между различными сервисами, и позволяло более точно контролировать привилегии операторов. Для того, чтобы связать наши VPC, в качестве хаба мы использовали AWS Transit Gateways (TGWs).
4 января наши TGWs оказались перегружены. TGWs обслуживаются AWS и предполагается, что они должны масштабироваться незаметно для нас. Но в первые дни после нового года трафик Slack имеет необычную структуру, он ниже в выходные дни, поскольку все отвлекаются от работы (молодцы, что поддерживаете баланс работы и лично жизни, пользователи Slack, так держать!). В первый рабочий день кэши клиентов не прогреты и при первом подключении они подгружают больше данных, чем обычно, после нескольких дней затишья нагрузка растет до самых больших значений за год буквально в течении одной ночи.
Наши системы позволяют быстро отмасштабировать производительность систем, чтобы переварить нагрузку такого рода (и в прошлые годы мы всегда хорошо с ней справлялись). Но наши TGWs не смогли отмасштабироваться достаточно быстро. В ходе данного инцидента специалисты AWS были оповещены о нашей проблеме с потерей пакетов их внутренним мониторингом и вручную увеличили емкость TGWs. К 10:40 это изменение вступило в силу во всех зонах доступности (Availability Zones) и наша сеть вернулась к нормальному режиму работы, а с ним вернулись обычные уровни ошибок и задержки.
AWS заверили нас, в процессе разбора данного инцидента ими были пересмотрены алгоритмы масштабирования TGW для резких скачков объема трафика. А мы поставили себе напомнание (конечно же это было напоминание Slack slack.com/intl/en-ie/help/articles/208423427-Set-a-reminder) превентивно увеличить емкость TGWs в конце следующих новогодних каникул.
Выводы
Мониторинг является одним из наших наиболее критичных сервисов — благодаря ему мы узнаем в порядке ли службы, с которыми взаимодействуют пользователи, а помимо этого это один из наших наиболее важных инструментов для выявления проблем. Мы прилагаем все усилия, чтобы наши инструменты мониторинга были как можно более независимыми от инфраструктуры Slack, чтобы они были доступны тогда, когда мы нуждаемся в них больше всего. В данной ситуации наши панели мониторинга и оповещения упали, поскольку базы данных, из которых они брали информацию оказались расположены в другом VPC, что привело к зависимости от TGWs. Запуск их в одном VPS позволит избавиться от этой зависимости.
Также мы приняли решение в дальнейшем регулярно проводить нагрузочное тестирование службы обеспечения, для того чтобы исключить проблемы с масштабированием (мы делали это и раньше, но в данном случае превысили параметры наших предыдущих испытаний). Также мы пересмотрим наши конфигурации контроля здоровья сервисов, а также конфигурации автомасштабирования для того, чтобы в дальнейшем избежать подобной перегрузки службы обеспечения даже в случае экстремальных условий, как, например, нестабильного сетевого соединения.
Мы глубоко сожалеем о перебоях в работе нашего приложения. Каждый инцидент — это возможность учиться и незапланированный вклад в повышение надежности сервиса в будущем. Мы многое узнали благодаря данному сбою и, как всегда, мы намерены использовать эти незапланированные инвестиции чтобы улучшить нашу инфраструктуру в 2021 и последующие годы.
Облачные серверы от Маклауд быстрые и безопасные.
Зарегистрируйтесь по ссылке выше или кликнув на баннер и получите 10% скидку на первый месяц аренды сервера любой конфигурации!
