Тезисы

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

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

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

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

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