Вступление

Сопровождение и аудит существующих систем - задача не менее важная (а зачастую гораздо более сложная), чем разработка новых. Мы начали работу с заказчиком (японской компанией Sairis) в непростой ситуации: заказчик уже сменил несколько команд разработчиков, поэтому от нас ожидали ощутимых результатов уже через один-два месяца работы.

Мы унаследовали систему от предыдущих разработчиков в плачевном состоянии. Нужно было любыми средствами ее стабилизировать, при этом весьма экономно расходуя серверные ресурсы (которые у заказчика далеко не безграничны).

Описание системы

Проект представляет собой одну из крупнейших в Японии систем видео-хостинга (фактически, японский аналог YouTube). Сервис предоставляет пользователям возможность бесплатно загружать и просматривать видеоролики, комментировать и голосовать за них. Существует развернутая система рейтингов и рекомендаций. Помимо этого, заказчик планировал организовать платный доступ, предоставляющий дополнительные возможности (например, возможность скачивать видео в формате DivX).

Для отслеживания эффективности видео-роликов ведется статистика по просмотрам. Имеется также система модерации видео и комментариев.

Концептуально система представлена на диаграмме ниже:

Архитектура системы

Проблемы, проблемы, проблемы

В процессе роста посещаемости сервис столкнулся с типичными проблемами масштабируемости и сопровождаемости.

— Отсутствие полноценной тестовой среды. К сожалению, сопровождавшие сервис аутсорсинговые команды не акцентировали внимание заказчика на этом чрезвычайно важном моменте и не сочли нужным потратить на это время.

— Отсутствие исходного кода некоторых компонентов системы (в частности, видео-плейера).

— Отсутствие мониторинга - определить, что происходит с production-системой, практически невозможно.

— Классическая проблема "энтропии" исходного кода - при отсутствии процедуры постоянного улучшения и "очистки" кода он постепенно переходит в хаотическое состояние, блокируя развитие и наращивание функционала сервиса. Все это ухудшается последовательной сменой нескольких команд разработчиков и полным отсутствием документации.

Задачи

Для бесплатного сервиса такого масштаба очень важно поддерживать высокую посещаемость и минимизировать расходы на сопровождение. В середине 2009 года это "магическое" соотношение стремительно ухудшалось: падал уровень доступности сервиса (а следовательно и число посещений), при этом система удерживалась на плаву поистине титаническими усилиями.

Что делать?

— Привести сервис в состояние, из которого его можно развивать и монетизировать.

— Минимизировать поддержку - все должно "работать само". Понятно, что идеал недостижим, однако очень хочется к нему приблизиться.

Как делать?

Для начала мы отклонили типовые студенческие решения вроде "все выкинуть и переписать". Это решение наиболее популярное и одновременно в большинстве случаев провальное (вспомним хотя бы грустную судьбу браузера Netscape).

Мы условно поделили план развития системы на три параллельных процесса:

— Production-мониторинг

— Рефакторинг и новый функционал

— Оптимизация производительности

Мониторинг

Для мониторинга использовался open-source продукт Zenoss Core. Мы добавили в Zenoss большое число различных параметров, выход которых за допустимые пределы означает что-то плохое. Например, это CPU consumption ключевых страниц, длина входящей видео-очереди и т.п.

Помимо Zenoss, мы использовали Tenshi для анализа лог-файлов, а также набор самодельных скриптов для замера тех параметров, которые сам Zenoss измеряет не очень хорошо (это, например, CPU).

Поскольку система в целом не находится под надзором 24 часа в сутки, мы постарались максимально автоматизировать восстановление в результате разного рода мелких сбоев.

Рефакторинг и новый функционал

Рефакторинг в нашем случае был сильно усложнен отсутствием документации и хаотическим способом написания кода. Поэтому в первую очередь нам пришлось с нуля создать в Москве свою собственную тестовую среду. При этом пришлось срочно адаптировать практически весь код системы к работе в разных средах. В дальнейшем мы создали еще одну отдельную тестовую среду в Японии.

Большую проблему представлял собой сервис кодирования видео. Написанный на PHP, он отличался особой нечитабельностью кода, нестабильной работой и полным отсутствием нормальной обработки ошибок. Это был как раз тот случай, когда проще "выкинуть все". Однако избавлялись от старого сервиса очень осторожно:

— Сначала по ключевым сценариям был написан набор unit-тестов на Python.

— Полностью (в некоторых случаях буквально построчно) воспроизведена ключевая функциональность PHP-скрипта на языке Python.

— Добавлен логгинг, обработка ошибок, работа с FTP и кодировщиком видео (Flix Engine).

Потратив на разработку три недели, мы получили ощутимый результат - новый Python-скрипт в течение многих месяцев работал стабильно, без ошибок, позволял легко распараллеливать нагрузку, спокойно переносил любые проблемы с БД и ошибки Flix Engine. Для сравнения - старый скрипт приводил к полной остановке очереди видео-кодирования и зависанию Flix Engine до 2-3 раз в неделю.

Оптимизация производительности

Проблемы с производительностью наблюдались в двух направлениях:

— База данных. Суммарный объем данных в БД был не так уже велик (порядка 8-10 Гб включая индексы), поэтому причина "проседания" БД заключалась скорее в плохо написанных SQL-запросах. Мы провели несколько циклов оптимизации, выяснив, что основной проблемой является использование рекурсивных функций и избыточные JOIN-ы. В итоге 80% запросов в системе были постепенно переписаны, что совместно с тюнингом PostgreSQL и дисковой подсистемы сервера дало хороший результат: сервер успешно работал в пиковые часы, причем его резервы по нагрузке позволяли БД в ближайшем будущем вырасти еще вдвое без ощутимых проблем.

— PHP страницы. Обычно для замеров производительности используется "тестовый стенд", однако его создание в нашем случае было довольно дорогостоящим, поэтому мы старались проводить как можно больше замеров в production-системе (что следовало делать чрезвычайно аккуратно). Для определения узких мест мы использовали сервис статистики Pinba, который потом был подключен к нашему централизованному мониторингу на базе Zenoss. Статистика от Pinba хороша тем, что позволяет достаточно точно определить наиболее удобное место "вмешательства" в PHP-код, при этом она практически не нагружает production-систему. Затем (в тестовой среде) с помощью профилировщика xhprof мы анализировали код уже на уровне отдельных вызовов и проводили точечную оптимизацию. Результат был довольно впечатляющий: переписыванием всего каких-то 50 строчек мы добились уменьшения загрузки CPU на 30-40%. При этом production-сервер получил хороший резерв для роста посещаемости, что дало заказчику еще минимум полгода до покупки новых серверов.

Результат

Каков итог нашей работы и как это отразилось на бизнесе заказчика?

Эффект можно отметить, например, по статистике роста посещаемости. По данным 2009 года, число посетителей стабильно сокращалось (в лучшем случае, посещаемость оставалась на прежнем уровне). Уже через два месяца после начала нашей работы посещаемость начала расти. За полгода сайт показал более чем 50% рост посещаемости; для бесплатного сервиса, зарабатывающего на рекламе, это весьма и весьма существенно.

В результате переделки системы заказчик получил возможность расширять и наращивать ее функционал. В частности, на базе новой видео-платформы были успешно реализованы: сервис фото-хостинга, поддержка видео на iPhone и мобильных телефонах, интеграция с CDN (что дало существенную экономию по стоимости трафика).