Юрий Насретдинов, badoo

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/

@YNasretdinovy.nasretdinov@corp.badoo.com