Отключение Braze 29 апреля: что произошло, почему это произошло и как мы реагируем

Понимание архитектуры сервисов платформы Braze

Braze поддерживает отдельные наборы серверов для каждого из наших восьми кластеров в США. Кластеры Braze US 01–07 размещаются на Amazon Web Services (AWS), а кластер Braze US 08 — на Microsoft Azure. В каждой из этих сред Braze использует несколько зон доступности и имеет резервирование для каждой части нашей системы. В случае сбоя зоны доступности мы регулярно и прозрачно отключаем маршрутизацию и обработку нарушенных зон доступности. Это позволяет нам надежно поддерживать работоспособность услуг во время сбоев у поставщика облачных услуг.

За некоторыми исключениями, каждый из кластеров США имеет собственную выделенную инфраструктуру, и, за исключением нескольких компонентов, которые используются во всех средах в данном облачном регионе, эти кластеры сильно изолированы друг от друга, чтобы снизить риск. что сбой в одном кластере повлияет на другие кластеры.

Из-за интенсивности рабочей нагрузки обработки в реальном времени на платформе Braze с 2013 года мы дополнили использование AWS и Azure партнерством с Rackspace для размещения специально настроенного оборудования для запуска баз данных MongoDB. Наши среды AWS и Azure настроены с помощью соединителей частного облака AWS Direct Connect и Azure ExpressRoute, которые связывают облачную среду с нашей внутренней сетью, поддерживаемой в центрах обработки данных Rackspace, по выделенному оптоволоконному кабелю. Это зашифрованное соединение, основанное на сетевых каналах, поддерживающих несколько интерфейсов, передающих более 100 гигабит сетевого трафика в секунду, обеспечивает высокопроизводительный доступ между нашим облаком и средами Rackspace.

Наша специализированная среда в Rackspace является домом для сотен физических серверов, размещенных в шкафах, предназначенных для Braze. Эта установка включает в себя резервные источники питания и резервные коммутаторы, устанавливаемые на верхнюю часть стойки. Верхние коммутаторы — это сетевые устройства, которые располагаются в серверной стойке и соединяют устройства и серверы в одной серверной стойке. Эти коммутаторы проверяются не реже одного раза в год на безотказное переключение при сбое; прошлогоднее тестирование было успешно проведено 3 августа 2023 года. В этой специальной среде мы поддерживаем десятки тысяч виртуализированных контейнеров для баз данных MongoDB. Как и в наших облачных средах, мы поддерживаем высокий уровень физической изоляции между контейнерами в разных кластерах США, чтобы минимизировать сбои и снизить риск того, что один контейнер может повлиять на другие контейнеры в наших базах данных.

Причина отключения электроэнергии 29 апреля и как мы отреагировали

Начальный частичный отказ переключателя

29 апреля в 09:15 UTC произошел частичный сбой основного сетевого коммутатора Cisco Nexus, подключенного к нашим серверным шкафам Rackspace. Неисправный коммутатор вышел из строя таким образом, что не активировался автоматически вторичный сетевой коммутатор посредством аварийного переключения, а вместо этого оставался неисправный коммутатор в качестве основного.

Сетевые коммутаторы маршрутизируют трафик, пересылая сетевые пакеты, называемые «фреймами», к месту назначения. Чтобы сделать это эффективно, эти коммутаторы поддерживают понимание топологии сети, которая соединяет устройства вместе. Сетевые маршруты обычно динамически изменяются в ответ на сбои или замедление работы отдельных компонентов. Когда происходят эти изменения, коммутаторы и другие сетевые устройства взаимодействуют друг с другом, чтобы поддерживать точное понимание топологии сети.

В больших сетях между устройствами часто существует более одного пути, что может вызвать «петли» маршрутизации (т. е. состояние, при котором пакеты не могут остановиться в намеченном пункте назначения и вместо этого возвращаются туда, где они были отправлены). Петли могут создавать «широковещательные штормы», когда трафик зацикливается на неопределенный срок, перегружая сетевые каналы и вызывая сбои в работе. Чтобы этого не произошло, коммутаторы запрограммированы на отправку сообщений, помогающих идентифицировать избыточные каналы. Эти сообщения называются блоками данных протокола моста связующего дерева (BPDU) и являются частью сетевого протокола, называемого протоколом связующего дерева (STP). Затем коммутаторы используют эту информацию для блокировки портов трафика, чтобы предотвратить возникновение петель при маршрутизации трафика. В случае сбоя физического канала или коммутатора STP помогает обеспечить избыточность, поскольку его можно использовать для идентификации других физических каналов, по которым может передаваться трафик, и сделать ранее пассивный (т. е. заблокированный) канал активным для поддержания соединений.

В начале инцидента 29 апреля, когда коммутатор начал работать со сбоями, он начал непрерывно пересылать уведомления об изменении топологии и BPDU, наводняя сеть этими уведомлениями об изменениях. Эти пакеты распространялись на распределительные коммутаторы и другие коммутаторы, вызывая цикл коммутации связующего дерева, который приводил к полному отключению сети. Несмотря на то, что STP используется для уменьшения количества петель в сети путем блокировки сетевых портов, где обнаружено образование петель, во время инцидента 29 апреля неправильно перенаправленный трафик связующего дерева от неисправного коммутатора заставил другие коммутаторы в сети повторно проанализировать свою топологию связующего дерева. Затем, поскольку эти другие коммутаторы обнаружили, что пакет BPDU с высоким приоритетом поступает от неисправного коммутатора, распределительные коммутаторы начали пересылку на ранее заблокированные порты, что привело к образованию цикла коммутации, который перегрузил сеть и отключил ее.

Исправление Rackspace

В результате этой деятельности инженеры центра обработки данных Rackspace примерно в 09:20 UTC получили предупреждения о непредвиденных проблемах с сетевым подключением и приступили к их устранению. Между 09:39 и 10:03 UTC инженеры центра обработки данных Rackspace приостановили работу сетевого коммутатора, выключили и включили основной коммутатор и принудительно переключили сетевые карты (NIC) в серверном шкафу на резервный коммутатор. После аварийного переключения сетевого адаптера подключение к физическим серверам в среде Braze было восстановлено.

Как работают базы данных Braze MongoDB

Базы данных MongoDB, используемые Braze, позволяют хранить данные на нескольких серверах баз данных, которые называются «осколками». MongoDB предоставляет службу маршрутизации под названием «mongoS», которая обрабатывает запросы от служб платформы Braze, определяет расположение соответствующих данных в сегментированном кластере, а затем направляет запрос в соответствующую базу данных MongoDB. Braze имеет сотни различных баз данных MongoDB, включающих более 15 000 процессов «mongoD», которые представляют собой программы, которые запускают базу данных и хранят данные для определенного сегмента MongoDB.

Каждый шард базы данных состоит из одного основного процесса mongoD и как минимум двух вторичных процессов mongoD, что обеспечивает высокую доступность в случае сбоя. Каждый сервер mongoS поддерживает сетевое соединение с каждым mongoD, к которому он может направлять запросы. Эти процессы mongoD также подключаются к первичному и вторичному серверам в его конфигурации; это известно как набор реплик. Если mongoS не может подключиться к данному mongoD, он пометит этот процесс как автономный и запланирует повторную попытку. Аналогичным образом, если mongoD не может подключиться к другим членам своего набора реплик mongoD в течение одной секунды, он истечет по тайм-ауту, пометит эти процессы как автономные и запланирует повторную попытку.

Влияние сетевого цикла на наши процессы MongoDB и как мы отреагировали

Во время сетевого цикла, поскольку наши процессы MongoDB не могли нормально подключиться, каждый из них помечал все связанные с ним процессы как отключенные. То есть каждый процесс mongoS помечал все связанные с ним процессы mongoD как автономные, а каждый процесс mongoD помечал связанные с ним элементы набора реплик как автономные. Однако даже после того, как Rackspace восстановил сетевое подключение к нашим физическим серверам, ни процессы mongoS, ни mongoD не восстановили все соединения с другими процессами, которые были помечены как автономные.

На этом этапе, чтобы помочь нашей команде администраторов баз данных (DBA) Rackspace в усилиях по исправлению ситуации, команды Braze DevOps начали быструю отладку и тестирование методов восстановления этого подключения. Наше расследование показало, что единственным доступным вариантом был перезапуск каждого из почти 16 000 процессов mongoD и более 6 000 mongoS в их виртуализированных контейнерах. Учитывая масштабы этого предприятия и тот факт, что не существовало средств автоматизации, позволяющих быстро перезапустить такое количество контейнеров, инженеры Rackspace во время инцидента написали новый код, чтобы создать возможность автоматизации на лету.

К сожалению, по мере ускорения процесса перезапуска в системе системы доменных имен (DNS) возникла еще одна проблема. Когда процессы mongoS и mongoD подключаются к сети, они запрашивают информацию у преобразователей DNS в процессе, известном как поиск DNS. Из-за непрерывного поиска DNS, обусловленного скоростью перезапусков, DNS-серверы подвергались большой нагрузке, что приводило к тайм-аутам подключения на уровнях mongoS при повторном подключении к процессам mongoD. Чтобы справиться с этой растущей нагрузкой, наша команда Rackspace увеличила мощность ЦП DNS, но затем была вынуждена перезапустить уровень mongoS во второй раз, чтобы создать работоспособные соединения между каждым mongoS и связанными с ним процессами mongoD.

Около 17:05 UTC процесс перезапуска позволил некоторым кластерам начать возвращаться в режим онлайн. Когда производительность базы данных восстановилась, а кластеры стабилизировались, Braze продолжил наращивать мощности обработки данных и отправки сообщений; однако эти усилия осложнялись огромным отставанием в работе из-за предшествующего отсутствия.

Учитывая масштаб и сложность нашей среды баз данных Rackspace, которая состоит из сотен отдельных баз данных, продолжительность простоя и полученный объем нашего невыполненного журнала (представляющего миллиарды сообщений и миллиарды принятых точек данных), процесс восстановления, требуемый в - мгновенная адаптация наших обычных процессов восстановления. Это было необходимо для того, чтобы ресурсы базы данных оставались в балансе с текущими потребностями в обработке, включая введение огромного количества общих вычислительных мощностей.

Однако при этом Braze достиг ограничения AWS на количество виртуальных процессоров, которые мы могли предоставить, что лишило нас возможности добавлять какие-либо дополнительные мощности сервера. Команда Braze быстро обсудила это обстоятельство с нашей командой AWS и получила повышение, что позволило нашим инженерам масштабировать вычислительную мощность нашего сервера до рекордного уровня, который более чем на 50 % превышал нашу предыдущую максимальную мощность, достигнутую на Black Пятница 2023.

К 20:30 UTC все наши кластеры в США, за исключением US 01, US 03 и US 08, завершили обработку своих невыполненных задач, а оставшиеся кластеры обрабатывали с максимальной скоростью или выше, начиная со дня, предшествовавшего инциденту. В течение нескольких часов все кластеры были снова переведены в режим обработки в реальном времени, и мы объявили об устранении инцидента.

Как Braze передает обновления во время инцидентов

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

В подобных ситуациях руководящими принципами нашей коммуникационной стратегии являются честность, прозрачность и доверие. Мы знаем, что у нас есть только одна возможность честно и откровенно рассказать о том, что происходит, и что прозрачность инцидентов — как в данный момент, так и после их разрешения — необходима для поддержания доверия. В конце концов, мы хотим, чтобы наши клиенты были уверены, что Braze всегда сделает все, что в наших силах, чтобы объяснить, исправить и предотвратить повторение любого инцидента.

Во время инцидентов мы используем нашу страницу статуса для управления связью и регулярного предоставления обновлений о том, как обстоят дела; Я настоятельно рекомендую клиентам подписаться на обновления на этой странице, чтобы быть в курсе событий. Во время сбоя 29 апреля мы дополнили эти частые обновления страницы статуса электронным письмом от моего коллеги-соучредителя и нашего генерального директора Билла Магнусона. Это сообщение было отправлено всем пользователям информационной панели Braze и предоставлено нашим командам по работе с клиентами, чтобы при необходимости поделиться ими с другими заинтересованными сторонами.

Как Брайз отреагировал на инцидент и планы на будущее

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

После инцидента Braze и Rackspace заменили неисправный коммутатор, а команда инженеров Rackspace завершила полный аудит сетевой инфраструктуры, на которую полагаются службы Braze. Хотя сбои оборудования невероятно трудно предсказать, особенно если оборудование находится на гарантии, существует мониторинг для обнаружения отклонений и обеспечения быстрого реагирования. Обе команды сейчас сотрудничают, чтобы внести изменения, которые предотвратят возникновение сетевых петель в будущем даже в случае неисправности оборудования. Для реализации некоторых сетевых изменений потребуется время, поскольку мы планируем внести существенные изменения в топологию нашей сети для дальнейшего улучшения защиты от петель. Мы также открыли заявки на поддержку как в Cisco, так и в MongoDB, чтобы лучше понять сценарии сбоев, с которыми мы столкнулись, а также улучшить способность процессов mongoD и mongoS к самовосстановлению после сетевых сбоев.

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

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

— Джон