Говорят, что Twitter потерял 80% персонала. Сколько бы оттуда на самом деле ни ушло, там в любом случае должны быть целые команды, в которых не хватает программистов. При этом сайт работает, твиты появляются. Многие люди в связи с этим начали задаваться вопросом о том, зачем там нужны были все эти программисты, и не был ли штат компании раздут. Я бы хотел дать некие пояснения в связи с моим небольшим (на самом деле, не таким уж и небольшим) кругом обязанностей, которые я исполнял, работая в этой компании, и рассказать о работе, проведённой для того, чтобы вся эта штука работала без проблем.

История и предисловие

Пять лет я работал в Twitter на должности инженера по надёжности (Site Reliability Engineer, SRE). Из них четыре года я был единственным SRE-специалистом в команде, отвечавшей за кэширование. Несколько специалистов работало там ещё до меня, да и в команде достаточно много людей уходило и приходило. Однако эти четыре года именно я из всей нашей команды отвечал за автоматизацию, надёжность и работу системы. Я разработал и внедрил большую часть инструментов, поддерживающих работу сайта, поэтому, думаю, что достаточно квалифицирован для рассказа об этом (кроме меня есть, пожалуй, только один-два специалиста того же уровня).

Кэш можно использовать для ускорения работы, или для разгрузки каких-то процессов, которые будет дороже запускать. Если ваш сервер отвечает за 1 секунду, однако выдаёт в ответ одно и то же каждый раз – этот ответ можно сохранить на кэш-сервере, который способен давать ответ за несколько миллисекунд. Или если у вас есть кластер серверов, на котором 1000 запросов в секунду может стоить $1000, вместо него можно использовать кэш-сервер, где хранить ответы и выдавать их из кэша. Тогда у вас будет небольшой кластер за $100, и большой дешёвый кэш-кластер из серверов ещё за $100. Эти цифры взяты с потолка, просто чтобы объяснить принцип.

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

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

Как кэш продолжает работать

Первое, что стоит учитывать в работе кэшей – они устроены как процессы в рамках фреймворка Aurora, работающего на базе Mesos. Aurora ищет сервера для запуска приложений, Mesos связывает их вместе так, чтобы Aurora знала об их существовании. Также Aurora обеспечивает работу приложений после того, как они были запущены. Если мы говорим, что кластеру для работы кэша нужно 100 серверов, Mesos сделает всё возможное, чтобы в работе участвовало 100 серверов. Если какой-то сервер отваливается, Mesos это обнаружит, удалит его из набора серверов и сообщит Aurora о том, что теперь работает только 99 кэшей. После этого он автоматически найдёт для Aurora новый сервер, чтобы их количество увеличилось обратно до 100. Вмешательства человека не требуется.

Сервера в дата-центрах размещаются в стойках. Сервера в стойке соединяются с другими серверами в других стойках через коммутаторы. Коммутаторы соединяются друг с другом и с роутерами, в итоге выходя в интернет. В стойке может находиться от 20 до 30 серверов. Может отказать вся стойка, может сломаться коммутатор или источник питания – тогда могут отключиться сразу 20 серверов. И ещё одна задача Aurora и Mesos состоит в том, чтобы не запускать слишком много приложений на серверах одной и той же стойки. Поэтому в серверной может внезапно выйти из строя целая стойка, и это будет безопасно, поскольку Aurora и Mesos найдут для работающих приложений новые сервера.

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

К сожалению, Mesos не в состоянии отслеживать отказ каждого сервера, поэтому у нас есть и другие инструменты для отслеживания отказов оборудования. Мы отслеживаем такие вещи, как выходящие из строя жёсткие диски и память. Некоторые подобные ошибки не приводят к отключению сервера целиком, но лишь замедляют его. У нас есть специальная информационная панель с тревожными сигналами, которую мы отслеживаем на предмет сломавшихся серверов. Если один из них ломается, автоматически формируется задача на его ремонт или обслуживание для работников дата-центра.

Ещё одна важная программа отслеживает время работы кластера кэша. Если за короткий промежуток времени выключилось слишком много серверов, новые задачи, требующие работы кэша, будут отклонены, пока ситуацию не исправят. Так мы избегаем случайных отключений всего кластера кэшей и перегрузки сервисов, их защищающих. Наша система предотвращает случаи слишком быстрого отключения слишком большого количества серверов, слишком большого количества серверов в ремонте, или таких ситуаций, в которых Aurora не может найти новые сервера, чтобы перекинуть на них старые задачи. Чтобы создать задачу на ремонт сервера, который был отмечен, как сломанный, мы проверяем, можно ли удалить с него все работы. Когда все работы удалены, сервер отмечается как безопасный для ремонта – и с ним уже может работать технический специалист дата-центра. Когда специалист отмечает сервер исправленным, наша система автоматически это отслеживает и вновь позволяет использовать сервер для запуска на нём задач. Человеческое вмешательство требовалось только для самого факта ремонта (интересно, там сейчас вообще остались техники?)

Исправлялись и повторяющиеся проблемы с приложениями. Случались ошибки, при которых новые сервера кэша не включались в систему (на старте возникало состояние гонки), или иногда на старт сервера уходило до 10 минут (логика O(n^n)). Поскольку члены нашей команды благодаря всей этой автоматизации не были загружены ручной работой, мы могли исправлять подобные ошибки, не нарушая работу проектов. Были и другие автоматические системы – к примеру, когда по метрике какого-нибудь приложения выходило, что его задержка работы выходит за определенные пределы, оно автоматически перезапускалось и не дёргало инженера. Члены команды получали максимум один срочный вызов в неделю, и почти никогда это не было чем-то критическим. Частенько во время дежурства никаких тревог вообще не срабатывало.

Тщательное планирование ресурсов также стало одной из причин, по которым сайт не падал. На Twitter работают два дата-центра, каждый из которых способен тянуть весь сайт. Все важные сервисы можно запустить в любом из них. То есть ёмкость мощностей обработки данных всегда равна 200%. И это только на случай каких-то катастроф, а большую часть времени оба дата-центра занимаются передачей данных, и утилизируются максимум на 50%. На практике и такая загрузка является максимальной. Обычно при расчёте ёмкости мощностей люди прикидывают, какой им нужен дата-центр и накидывают мощность сверху для подстраховки. Обычно на случай дополнительного трафика существует довольно большой запас серверов. Отказ всего дата-центра целиком случается чрезвычайно редко. За пять лет моей работы в компании такое было только один раз.

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

И чем конкретно ты занимался?

Всем вышеперечисленным! Я общался с клиентами (командами, использовавшими кэш как сервис). После того, как всё было автоматизировано, я автоматизировал ещё больше. Также я решал интересные проблемы с быстродействием, экспериментировал с технологиями, которые могли бы улучшить работу, а также занимался проектами, призванными уменьшать траты. Я планировал ёмкость мощностей и определял, сколько серверов необходимо заказать. Работы было полно. Я не просто так получал зарплату и играл в видеоигры, покуривая травку, как думают некоторые.

Так кэши обрабатывают запросы Twitter, не отключаясь и работая. И это лишь часть ежедневной работы. Чтобы дойти до такого состояния за все эти годы, потребовалось проделать много работы. Время отойти на шаг и с благодарностью оценить то, что эта штука реально работает!

По крайней мере, пока. Уверен, что где-то там притаились ошибки.