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.

Урок №1

Положите кеш Smarty в active-active DRBD кластер под высокой нагрузкой и Ваш сайт упадет.

Пока хостер восстанавливал веб-сервера, я переписал часть CMS таким образом, чтобы кеш-файлы Smarty хранились в локальной файловой системе. Проблема была найдена и устранена и мы вернулись онлайн.

Теперь это было начало дня. Обычно пик посещаемости приходился на конец дня и до раннего вечера. Ночью посетителей практически не было. Мы опять начали наблюдать за системой. Сайт загружался, но к приближению пикового времени нагрузка все возрастала и ответы замедлялись. Я увеличил время жизни кеша Smarty, надеясь, что это поможет, но это не помогло. Скоро сервера начали выдавать ошибки таймаута или пустые страницы. Два веб-сервера не справлялись с нагрузкой.

Наш клиент был на нервах, но он понимал, что переезд обычно несет с собой некоторые проблемы.

Нам было необходимо как-то уменьшить нагрузку и мы обсудили это с хостером. Один из их админов предложил хорошую идею: «Ваши сервера сейчас на Apache+mod_php. Может перевести на Lighttpd? Это небольшой проект, но даже Википедия использует его.» Мы согласились.

Урок №2

Установите на Ваши сервера веб-сервер «из коробки», ничего не настраивайте и Ваш сайт упадет.

Администратор перенастроил наши сервера так быстро, как только мог. Он отказался от Apache и перешел на конфигурацию Lighttpd+FastCGI+Xcache. Сколько сервера протянут на этот раз?

На удивление, сервера работали хорошо. Нагрузка была значительно меньше, чем ранее, и среднее время ответа было хорошим. После этого мы решили пойти домой и отдохнуть — было уже поздно и мы сошлись во мнении, что пока нам больше делать нечего.

В следующие дни сервера справлялись с нагрузкой относительно хорошо, но в пиковое время они были близки к падению. Мы установили, что узким местом является MySQL и опять позвонили хостеру. Они посоветовали master-slave репликацию MySQL со slave на каждом веб-сервере.

Урок №3

Даже производительный сервер БД имеет ограничения — и, когда они будут достигнуты, Ваш сайт упадет.

Эту проблему было не так-то просто исправить. CMS была очень простой в этом отношении и в ней не было встроенной возможности разделения SQL-запросов. Модификация этого заняла некоторое время, но результат был стоящий.

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

Урок №4

Не планируйте ничего заранее и Ваш сайт рано или поздно упадет.

К счастью, мы продолжали наблюдать и планировать. Мы оптимизировали код, уменьшили количество SQL-запросов и неожиданно узнали о MemCached. Для начала я добавил MemCached в некоторые основные функции, которые были наиболее тяжелыми. Когда мы развернули наши изменения на продакшене мы не могли поверить результатам — как будто мы нашли Священный Грааль. Мы уменьшили количество запросов в секунду как минимум на 50%. Вместо покупки еще одного веб-сервера мы решили, что лучше использовать MemCached.

Урок №5

Не кешируйте ничего и тратьте деньги на новое железо или Ваш сайт упадет.

MemCached помог нам снизить нагрузку на MySQL на 70-80%, что повлекло за собой огромный прирост производительности. Страницу загружались еще быстрее.

Наконец, наша конфигурация казалась идеальной. Даже в пиковое время нам не надо было волноваться о возможных падениях или о большом времени ответа. Но неожиданно один из вебсерверов начал приносить нам проблемы — сообщения об ошибках, пустые страницы и т.д. С нагрузкой было все нормально и в большинстве случаев сервер работал нормально, но только в «большинстве случаев».

Урок №6

Положите несколько сотен тысяч небольших файлов в одну директорию, забудьте об Inode и Ваш сайт упадет.

Да, это так. Мы были настолько заняты оптимизацией MySQL, PHP и веб-серверов, что не уделяли должного внимания файловой системе. Кеш смарти хранился в локальной ФС в одной директории. Решением был перенос Smarty на отдельный раздел с ReiserFS. Также мы включили опцию Smarty 'use_subdirs'.

В течение следующих лет мы продолжали оптимизацию. Мы поместили кеш Smarty в memcached, установили Varnish для уменьшения нагрузки на I/O систему, перешли на Nginx (Lighttpd случайным образом выдавал ошибку 500), купили лучшее железо и так далее.

Заключение

Масштабировани веб-сайта — бесконечный процесс. Как только вы исправите одно узкое место, скорее всего вы наткнетесь на следующее. Никогда не думайте «Это все, мы закончили». Это погубит Ваши сервера и, возможно, Ваш бизнес. Оптимизация — это постоянный процесс. Если Вы не можете выполнить работу сами из-за отсутствия опыта/ресурсов — найди компетентного партнера для совместной работы. Никогда не переставайте обсуждать с Вашими командой и партнерами текущие проблемы и проблемы, которые могут появиться в будущем.

Взято тут

Эта история настойчиво напоминает старый добрый рекламный ролик: