Юрий Насретдинов, badoo
DESCRIPTION
HighLoad++ 2013TRANSCRIPT
Badoo в облаках(решение для запуска cli-скриптов в облаке собственной разработки)
!Юрий Насретдинов, Badoo
Badoo• 195+ млн пользователей
• PHP-FPM: 40+ тыс запросов в сек
• 160 тыс регистраций в день
• 4 млн фото / видео в день
• 50 языков интерфейса
• 2 000+ серверов
О чём этот доклад• Как мы запускали cron-задания до введения «облака»
• Требования к новому «облаку»
• Существующие решения
• Общая архитектура
• Концепция «заданий»
• Распределение нагрузки
• Отказоустойчивость
Cron• 1 000 различных скриптов (cron-заданий)
• Время работы — от 0,1 сек до нескольких суток
• Мало CPU-bound скриптов (в основном нужна память или сеть)
• Параллельная обработка с помощью fork()
• 2 000 000 строк кода
Cron: mcron
sendSMS.php anonChat.php #1 moderation.php
config
scripts1 scripts2
facebook.php anonChat.php #2
errorlogs.php
translate.php anonChat.php #9
cleanup.php
scripts50
…
Cron: mcron
sendSMS.php anonChat.php #1 moderation.php
config
scripts1 scripts2
facebook.php anonChat.php #2
errorlogs.php
translate.php anonChat.php #9
cleanup.php
scripts50
…
Cron: mcron
sendSMS.php facebook.php
anonChat.php #1 moderation.php
config*
scripts1 scripts3
google.php anonChat.php #2 anonChat.php #3
migration.php
translate.php errorlogs.php
anonChat.php #9 cleanup.php
scripts50
…
Cron: недостатки• Жесткая привязка скриптов к конкретным
машинам
• «Ручная» балансировка нагрузки
• Сложный мониторинг запуска заданий
• Ручной перенос скриптов в случае «падения»
• Downtime — несколько часов
«Облако»• Равномерное распределение нагрузки
по серверам
• Отказоустойчивость
• Понятный мониторинг
• Запуск заданий по расписанию
Существующие решения:• Gearman
• SLURM
• Mesos
• ZooKeeper
• Beanstalk
• Scalr
Существующие решения:
• SLURM мы больше всего исследовали
• 2 базовых алгоритма балансировки: round-robin и последовательная полная загрузка машины
• Заточен под математические расчеты, MPI
• Не учитывает нагрузку на машине?
SLURM
Существующие решения:
• Создан для синхронной обработки событий
• Непрозрачный failover
• Предполагает наличие фиксированных worker’ов
• Нам придется переписывать весь наш код
Gearman
Решили писать своё решение
Общая архитектура
phproxyd phproxyd phproxyd phproxyd
Heartbeat
каждые 10 секунд
phproxyd phproxyd phproxyd phproxyd
Введение в строй новой машины• Админ: Поставить сервер в стойку
• Админ: Поставить ОС (xCAT)
• Админ: Поставить PHP и phproxyd (puppet)
• Админ: Прописать heartbeat в cron
• Программист: радоваться
Добавление нового скрипта
Никакой консоли, никакого SVN, никаких mcron через SSH!
«Задания»• Задание — запуск скрипта (!)
• Генерируются с заданной периодичностью или добавляются через специальный API
• Должно обрабатываться строго одним потребителем
• CAP-теорема (Consistency, Availability, Partition Tolerance)
• «Поколения» заданий
Распределение нагрузки• «Попугаи»
• Round-robin (по машинам с наибольшим количеством свободных «попугаев»)
• Виртуальное потребление ресурсов
• Учитывается только свободные CPU и память на машине
Распределение нагрузки
1000 300
600 250
2000 230
1000 200
2000 180
round-robin
обновляется каждые 10 секунд
Распределение нагрузки• Много «облачных» машин (около 100)
• Хотим добавить все машины (около 1000)
• Если машина загружена выше 70% — новые задания на неё не попадают
• Алгоритм постоянно улучшается с учётом потребностей и полученных результатов
Реализация• Java?
• Erlang?
• C?
• Go?
• PHP !
Реализация: phproxyd• Демон на C, писался для других целей
• Умеет запускать PHP-скрипты
• А также следить за ними
• Пишется на Go примерно за 2 дня
• Что мы и сделали
Реализация: управляющая логика• Несколько процессов, работающих в while(true)
• Раз в 10 минут всем посылается SIGTERM
• Максимальное время простоя «облака» — 10 минут
• Генерация заданий — один процесс
• Запуск заданий — N процессов, зависит от общего числа машин в облаке
Пример скрипта (до «облака»)
Пример скрипта (наше время)
Отказоустойчивость• «Падение» машины в облаке
• Проблемы с сетью
• Проблемы с конфигурацией машин
• «Падение» базы данных
• «Падение» мастер-узла
Падение «облачной» машины• Машина не отвечает нам по сети, но может продолжать
выполнять отданные ей задания
• Решение — alarm(2), SIGALRM
• Если задание выполняется больше отведенного времени, благодаря alarm(2) мы можем быть уверены, что оно завершилось
• Максимальный простой определяется временем работы скрипта
Проблемы с сетью• Heartbeat перестанет работать — мониторинг
это увидит
• Жесткие таймауты на обращения к phproxyd
• PHP-скрипты «зависнут» — через 10 минут придет SIGTERM
• Нарушение связности сети: alarm(2) нас спасет
Проблемы с конфигурацией
Проблемы с конфигурацией машин решает мониторинг
Падение управляющей машины
Вручную переносим все скрипты на другую машину (5 минут)
«Падение» базы данных• Задания генерируются по расписанию!
• Заливаем «чистую» базу (только настройки скриптов)
• Убиваем все запущенные задания в «облаке»
• Перезапускаем управляющие скрипты
• Downtime — 30 минут
ВопросыЮрий Насретдинов, Badoo (http://badoo.com/)
!http://habrahabr.ru/company/badoo/http://habrahabr.ru/users/yourock/