«Облако» в Badoo год спустя: работа над ошибками
Архитектуры

Доклад принят в Программу конференции
Badoo

Ведущий разработчик в Badoo, работаю в отделе «платформы». Один из основных разработчиков «облака» (системы для распределенного запуска cli-скриптов по расписанию). Также занимался deployment и системой переводов. В веб-разработке около 10 лет, из которых 3 года в Badoo.

Облако в Badoo год спустя - работа над ошибками, Юрий Насретдинов (Badoo) from Ontico

Тезисы

Тезисы
· Общая архитектура: история создания, распределение нагрузки, отказоустойчивость.
· Логи скриптов: сбор, индексация, различные виды просмотра.
· Влияние Google App Engine — «облачный» разборщик очередей.
· Проблемы, с которыми мы столкнулись.
· Планы на будущее: phproxyd на PHP, управляющая логика на Go.
· Как мы бы реализовали «облако» сейчас: Go, Tarantool, ...

Описание
В прошлом году мы рассказывали о новой системе, которую мы назвали «облаком для скриптов» или «облачным cron'ом». Система служит для распределенного запуска скриптов по расписанию с автоматической балансировкой нагрузки и устойчивостью к «падениям» отдельных машин. Изначально система была построена на PHP, MySQL и легковесном самописном демоне — phproxyd, который «умеет» запускать скрипты на машине и отдавать информацию о статусе их исполнения.

Я кратко повторю содержимое предыдущего доклада, где была описана архитектура «облака» и его основные компоненты, после чего оставшаяся часть будет посвящена граблям, на которые мы наступили и планам на будущее.

Главные демоны нашего «облака» всё ещё работают на немного модифицированном прототипе, который был написан в первые недели разработки, при этом за год суммарный простой составил 3 часа, что дает uptime 99,97%. Тем не менее, у нас есть много идей для улучшения:
- перевод управляющей логики с PHP на Go;
- перевод phproxyd с Си на PHP (!), для экономии на запуске интерпретатора;
- возможный переход на Tarantool для хранения текущего состояния скриптов;
- длительное хранение логов, индексирование .gz-файлов для просмотра информации даже по очень старым запускам;
- улучшения в балансировщике (итеративное «уточнение» весов вместо использования «попугаев»).

В конце я постараюсь рассказать о том, как бы мы проектировали нашу систему сейчас, учитывая накопленный опыт. Будет сказано о недостатках MySQL (InnoDB) для хранения часто меняющегося состояния, о том, как сломать встроенную репликацию, и, что не менее важно, починить ее обратно на «живой» системе с очень высокой нагрузкой.

Другие доклады секции
Архитектуры

LiteSpeed Technologies
Pivotal Inc.
Positive Technologies
Hailo (hailoapp.com)
LinkedIn
ПЕТЕР-СЕРВИС