Основные мероприятия по переводу на HighLoad?

Всем привет. Мне как веб-разработчику (php, ruby) и unix-администратору, интересно, какие шаги проводят для адаптации веб-проекта под highload.


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


Например, из того, что имен известно (в плане php) — установка nginx в качестве фронтэнда, либо вообще единственного сервера вместе с php-fpm, использование php-apc, memcached, перевод узких мест на NoSQL. Но это все мероприятия в рамках одного сервера, а меня больше интересует разнесение на несколько серверов.


Конкретно создать этот вопрос меня побудило желание узнать, как же все-таки зеркалируются данные на серверах и используется единая база данных, в случае, например, использования DNS Round Robin.
  • Вопрос задан
  • 7245 просмотров
Пригласить эксперта
Ответы на вопрос 7
@egorinsk
Наверно хороший способ узнать это — изучить архитектуру существующих highload проектов. Держите ссылку: www.insight-it.ru/highload/

От себя добавлю, что практически всегда необходимо предусмотреть возможность масштабирования в самом приложении (т.е. переписывать код). Нельзя просто так взять, поставить нгинкс, поменять MySQL на mongo и получить хайлоад проект (более того, поменяв mysql на mongo можно получить еще больше проблем).
Ответ написан
Комментировать
EugeneOZ
@EugeneOZ
Вы очень поверхностно описали вопрос.
Nginx + php-fpm очень рекомендую. Но самая главная замарочка — репликация/шардинг базы данных. Рекомендую читать не только на официальных сайтах баз данных (там всегда всё «быстро надёжно автоматически»), но и на serverfault, news.ycombinator.com. MySQL очень плоха в репликации, MongoDB тоже имеет с этим косяки. Про PostgreSQL хорошо отзываются (даже master-master есть), но я сам не пробовал на практике. Пробовал Couchbase — прекрасно кластеризуется, даже ребёнок справится, умеет кросс-датацентр репликацию. Но это NoSQL — бд нужно выбирать по задаче. Если больше подходит именно rdbms, то лучше PostgreSQL, imho :)
Ещё вам понадобится кластеризация кэша — как варианты: Amazon ElastiCache, Couchbase, Riak. Через несколько месяцев будет Redis Cluster :)

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

Ещё рекомендую сделать api для внутреннего взаимодействия приложений, чтобы они не общались дру с другом, изменяя значения в «чужих» базах или таблицах.
Ответ написан
Это вы, получается, вопрос про горизонтальное масштабирование задали.
Серверы приложений масштабируются с помощью балансировщика(HAproxy да или сам nginx). Они хранят только исполняемые файлы (грубо, говоря, их содержимое одинаково в любой момент времени и не содержит какого-нибудь UG-контента), поэтому тут зеркалирования данных не нужно — логгирование идет в бд или какой-нибудь централизованный сервис, статика в CDN. Серверы БД — репликация/шардинг, тут уже в зависимости от конкретной используемой СУБД, в той же Монго все из коробки, в PostgreSQL — PL/Proxy, PgPool.
Самое главное — максимально разделить и обособить части приложения, если оно прямо к себе на хост пишет логи, заливает юзерпики и еще что-то такое делает — будет весьма тяжело это все масштабировать потом.
Ответ написан
Комментировать
Wott
@Wott
HL это на самом деле задача по оптимизации. В первую очередь надо уменьшить времена формирования ответа, времена загрузки на клиенте, что достигается оптимизацией самого приложения (профилирование, склеивания запросов и разнесения контента) и и потом уже кеширования, которое бывает разное — тупое (ставим nginx ) или структурное ( разбиваем на блоки, которые формируем и кладем например в memcached ), управляемое ( содержимое меняется при необходимости ) и нет ( по таймауту ). Для кеширования может понадобиться изменять приложение ( обновления в данных ) или адаптировать кеширование ( сброс кеша или его игнорирование по кукам например )
Дальше, если сервер уже не справляется в одиночку или надо HA, переходим к горизонтальному масштабированию. И начинать надо с того что запросы должны быть атомарными — любые состояния, типа сессий, усложнят масштабирование ( придется расшаривать сессии на кластер или привязывать пользователя к серверу по ip например, что легко если шардинг, но HA страдает ). Какая база ( SQL или NoSQL. не говоря уже об названии ) или кластер — зависит в первую очередь от приложения, а не от моды или комментов на хабре. Лучше жить на MySQL, тем более что Percona+Galera очень даже неплохи, если вы его хорошо знаете, чем окунаться в проблемы незнакомого сервера на production. Опять же конкретная технология должна решать конкретные проблемы, которые определяются, исходя из архитектуры приложения в первую очередь. Ну и пробовать, экспериментировать.
Ответ написан
dshvechikov
@dshvechikov
Помимо использования memcached очень помогает отправлять «тяжёлые» задачи в очередь. например, rabbitMq
Ответ написан
Комментировать
Wendor
@Wendor
nodejs developer / *nix admin
Когда-то передо мной вставала подобная задача. Гляньте мою статью по этому поводу.
habrahabr.ru/post/106311/
Ответ написан
Комментировать
golotyuk
@golotyuk
Если в двух словах, то намного важнее решения архитектурные, чем софтовые. Т.е. плохую архитектуру не спасет использование nginx'a, может только отложить проблемы. Да и касательно использования количества технологий, я бы советовал использовать минимум, но с умом. Лучше иметь 3 хорошо отлаженых узла, чем 10. Каждая новая технология будет только усложнять инфраструктуру.

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

Также советую прочитать Что такое highload.
Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы