производительность

6 способов убить Ваши сервера — познаем масштабируемость трудным путем

Публикую статью, написанную it-специалистом.
Учитывайте чужой опыт, господа. Думайте мозгом сразу, а не кидайтесь от технологии к технологии.

---
Узнать, как отмасштабировать Ваше приложение, не имея при этом никакого опыта, — это очень нелегко. Сейчас есть много сайтов, посвященных этим вопросам, но, к сожалению, не существует решения, которое подходит для всех случаев. Вам по-прежнему необходимо самому находить решения, которые подойдут под Ваши требования. Так же, как и мне.

Несколько лет назад ко мне пришел мой босс и сказал: «У нас есть новый проект для тебя. Это перенос сайта, который уже имеет 1 миллион посетителей в месяц. Тебенеобходимо его перенести и убедиться, что посещаемость может вырасти в будущем без всяких проблем.» Я уже был опытным программистом, но не имел никакого опыта в области масштабируемости. И мне пришлось познавать масштабируемость трудным путем.

ПО сайта представляло собой CMS на PHP, с применением MySQL и Smarty. Первым делом была найдена хостинговая компания, которая имела опыт высоконагруженных проектов. Мы предоставили им свою требуемую конфигурацию:
Балансировка нагрузки (с запасом)
2 веб-сервера
MySQL сервер (с запасом)
машина для разработки

Что мы получили (хостер сказал, что этого будет достаточно):
Балансировка нагрузки — Single core, 1 Гб RAM, Pound
2 веб-сервера — Dual core, 4 Гб RAM, Apache
MySQL сервер — Quad core, 8 Гб RAM
машина для разработки — Single core, 1 Гб RAM

Для синхронизации файлов хостер установил DRBD в конфигурации active-active.

Наконец, время переноса пришло. Рано утром мы переключили домен на новые IP и начали мониторить наши скрипты. Трафик мы получили практически сразу и казалось, что все работает хорошо. Страницы загружались быстро, MySQL обрабатывал кучу запросов и все были счастливы.

Затем неожиданно прозвонил телефон: «Мы не можем зайти на веб-сайт, что происходит?!» Мы посмотрели в наше ПО для мониторинга и увидели, что сервера упали и сайт не работал. Конечно, первым делом мы позвонили хостеру и сказали: «все наши сервера упали. Что происходит?!» Они пообещали проверить сервера и перезвонить после этого. Спустя некоторое время они позвонили: «Ваша файловая система безнадежно испорчена. Что Вы делали?!» Они остановили балансер и и сказали мне посмотреть на один из веб-серверов. Открыв index.php, я был шокирован. Он содержал непонятные куски кода на Си, сообщения об ошибках и что-то, похожее на лог-файлы. После небольшого расследования мы установили, что причиной этому была наша DRBD.