По некоторым оценкам, Twitter потерял примерно 80% сотрудников. Каким бы ни было реальное число, в компании есть команды, в которых полностью пропали разработчики. Тем не менее, веб-сайт продолжает работать, а твиты продолжают публиковаться. Из-за этого многие задаются вопросом, что происходит со всеми этими разработчиками, и не был ли штат компании попросту раздут. Я бы хотел рассказать о собственном маленьком уголке в Twitter (впрочем, он был не таким уж и маленьким), а также о работе, которая выполнялась для того, чтобы система продолжала функционировать.
Краткая информация и история
В течение пяти лет я работал инженером по надёжности сервиса (Site Reliability Engineer, SRE) в Twitter. Из них четыре года я был единственным SRE в команде, занимавшейся кэшами. До меня было несколько человек, и ещё я работал с целой командой, в которую приходило и из которой уходило множество людей. Но в течение четырёх лет я единственный в команде отвечал за автоматизацию, надёжность и эксплуатацию. Я спроектировал и реализовал большинство инструментов, благодаря которым поддерживалась работа, поэтому мне кажется, я имею достаточную квалификацию, чтобы говорить об этом. (Наверно, подобным опытом обладают один-два человека)
Кэш может использоваться для ускорения работы или для снижения объёма запросов к подсистеме, работа которой обходится дороже. Если у вас есть сервер, ответ которого занимает 1 секунду, но каждый раз это один и тот же ответ, то вы можете сохранить этот ответ на кэш-сервер, где ответ может отправляться за миллисекунды. Или если у вас есть кластер серверов, на котором обработка 1000 запросов в секунду может стоить $1000, то вместо него можно использовать кэш для хранения запросов и их возврата с этого кэш-сервера. Тогда у вас получится кластер меньшего размера за $100 и большой и дешёвый кластер серверов для кэша ещё примерно за $100. (Приведённые числа — это лишь примеры для демонстрации принципа.)
Кэши получают большую часть трафика, который приходит на сайт. Твиты, все ленты пользователей, личные сообщения, реклама, аутентификация — всё это выдаётся из серверов команды, занимающейся кэшем. Если с кэшем возникнут проблемы, то вы как пользователь это сразу заметите.
Когда я присоединился к команде, моим первым проектом была замена старых машин на новые. Для этого не существовало ни инструментов, ни автоматизации, мне просто дали электронную таблицу с именами серверов. Могу с удовольствием сказать, что теперь работа в этой команде ведётся совершенно иначе!
Как поддерживается работа кэша
Первый важный пункт в поддержании работы кэшей заключается в том, что они выполняются, как задачи Aurora в Mesos. Aurora находит серверы для выполнения на них приложений, а Mesos агрегирует все серверы, чтобы Aurora знала о них. Также Aurora поддерживает работу приложений после их запуска. Допустим, если кластеру кэша нужно 100 серверов, то он сделает всё возможное, чтобы работали все 100. Если сервер по какой-то причине полностью ломается, Mesos обнаруживает это и удаляет сервер из агрегированного пула; благодаря этому Aurora будет знать, что работает только 99 кэшей и что ей нужно найти новый сервер из Aurora для запуска. Она автоматически находит сервер и общее количество снова становится равным 100. Вмешательство человека при этом не требуется.
В дата-центре серверы помещаются в так называемые стойки. Серверы в стойках подключаются к другим серверам в стойках при помощи серверного коммутатора. Далее идёт целая сложная система присоединений коммутаторов к другим коммутаторам и маршрутизаторам, в конечном итоге подключённая к Интернету. В стойке может содержаться примерно 20-30 серверов. У стойки может случиться неполадка, коммутатор может поломаться или у него перегорит блок питания, что приведёт к отключению всех 20 серверов. Ещё одно удобство Aurora и Mesos заключается в том, что они делают так, чтобы в одну стойку не помещалось слишком много приложений. Благодаря этому, если целая стойка внезапно отключится, Aurora и Mesos найдут новые серверы, которые станут новым домом для приложений, работавших в стойке.
В вышеупомянутой электронной таблице также отслеживалось количество серверов в стойках; составитель таблицы стремился к тому, чтобы их было не слишком много. Благодаря новым инструментам при вводе новых серверов в эксплуатацию мы можем всё это отслеживать автоматически. Эти инструменты гарантируют, что у команды не будет слишком много физических серверов в одной стойке и что всё распределено так, чтобы случайные сбои не вызывали проблем.
К сожалению, Mesos не выявляет сбои каждого из серверов, поэтому нам нужен дополнительный мониторинг аппаратных проблем. Мы отслеживаем такие аспекты, как дефектные диски и сбойная память. Некоторые из этих проблем не приводят к отказу всего сервера, но могут замедлить его работу. У нас есть дэшборд алертов, который сканируется на наличие поломанных серверов. Если обнаруживается, что один сервер сломан, мы автоматически создаём заявку на ремонт для сотрудника дата-центра, чтобы он решил проблему.
Ещё одно важное ПО, которое есть у команды — это сервис, отслеживающий период работоспособности (аптайм) кластеров кэша. Если в короткий период времени слишком большое количество серверов оказывается отключённым, то новые задачи, требующие удаления кэша, будут отклоняться, пока ситуация не окажется безопасной. Так мы защищаемся от внезапного отключения целых кластеров кэша и от чрезмерной нагрузки на сервисы, которыми мы их защищаем. У нас настроены ограничения на такие случаи, когда слишком много серверов быстро отключатся, слишком много находится одновременно в ремонте или когда Aurora не может найти новые серверы для размещения в них старых задач. Чтобы создать заявку на ремонт сервера, у которого выявлена поломка, мы сначала проверяем, безопасно ли удалять задачи из него, проверяя этот сервис; если он пуст, то создаётся пометка, что техник дата-центра может безопасно с ним работать. После того, как техник дата-центра пометит сервер как починенный, наши специальные инструменты, которые занимаются отслеживанием этого, автоматически активируют сервер, чтобы он мог выполнять задачи. Единственный человек, который при этом необходим — это тот, кто чинит сервер в дата-центре. (Интересно, действительно ли это по-прежнему люди?)
Также мы устранили повторяющиеся проблемы с приложениями. У нас возникали баги, когда новые кэш-серверы не добавлялись обратно в пул (состояние гонки при запуске) или когда для добавления обратно сервера требовалось до 10 минут (логика O(n^n)). Поскольку благодаря всей этой работе по автоматизации мы не утопали в ручной работе, нам удалось создать в команде культуру, позволяющую устранять подобные проблемы, не препятствуя выполнению проектов. У нас были и другие автоматические решения проблем, например, если происходил выброс каких-то метрик приложения (скажем, задержки), мы автоматически перезапускали задачу, чтобы заявка на устранение неполадки не поступала инженеру. Команда получала примерно по одной заявке в неделю, и почти никогда она не была критически важной. В смены дежурства у нас часто случалось так, что не было ни одной заявки.
Также одной из самых важных причин того, что сайт не «лёг», стало планирование мощностей. У Twitter работало два дата-центра, которые могли выдержать нагрузку при полном переносе на них работы целого сайта. Каждый важный работающий сервис мог выполняться из одного дата-центра. Суммарные доступные мощности в любой момент времени составляли 200%. Это было необходимо только для катастрофических сценариев, а в основную часть времени оба дата-центра обслуживали трафик. Дата-центры заняты максимум на 50%. На самом деле, на практике это даже можно считать высокой нагрузкой. При вычислении потребностей в мощностях определяется, что нужно для того, чтобы один дата-сервер обрабатывал весь трафик, а затем поверх этого обычно добавляется резерв! Если нагрузку не нужно аварийно переносить, то для дополнительного трафика есть большой резерв серверов. Авария целого дата-центра — довольно редкое событие, которое произошло за пять лет моей работы только один раз.
Кроме того, мы обеспечивали разделение кластеров кэша. У нас не было мультиарендных (multi tenant) кластеров, занимавшихся обработкой всего и имевших изолирование на уровне приложений. Благодаря этому при возникновении проблем у одного кластера «радиус поражения» накрывал только этот кластер и, может быть, несколько соседних серверов на той же машине. Этому способствует Aurora, обеспечивая распределение кэшей: проблема затрагивает малую часть устройств, а мониторинг со временем позволяет устранить неполадку.
Так чем же я там занимался?
Всем тем, что описал выше! А ещё я общался с клиентами (командами, использовавшими кэш в качестве сервиса). После того, как завершил автоматизацию, я автоматизировал дальше. Также я работал над интересными проблемами производительности, экспериментировал с технологиями, которые могли улучшить систему, и руководил несколькими крупными проектами по сокращению трат. Я выполнял планирование мощностей и определял, сколько серверов нужно заказать. Я не просто получал зарплату за то, что весь день играл в видеоигры и пил кофе, как может показаться.
Вот так мы поддерживали работоспособность кэшей, обслуживающих запросы к Twitter. Это лишь часть того, в чём заключалась повседневная работа. Чтобы достичь такого положения, требовалось много работы в течение долгих лет. И сейчас мы можем отдать должное тому, что вся система продолжает работать!
По крайней мере, пока — я уверен, что где-то внутри таятся баги…
