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

Question

[Денис Лысенко]

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


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


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


Конкретно создать этот вопрос меня побудило желание узнать, как же все-таки зеркалируются данные на серверах и используется единая база данных, в случае, например, использования DNS Round Robin.

Answer 1

[egorinsk]

Наверно хороший способ узнать это — изучить архитектуру существующих highload проектов. Держите ссылку: www.insight-it.ru/highload/

От себя добавлю, что практически всегда необходимо предусмотреть возможность масштабирования в самом приложении (т.е. переписывать код). Нельзя просто так взять, поставить нгинкс, поменять MySQL на mongo и получить хайлоад проект (более того, поменяв mysql на mongo можно получить еще больше проблем).

Answer 2

[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 для внутреннего взаимодействия приложений, чтобы они не общались дру с другом, изменяя значения в «чужих» базах или таблицах.

Comments

[EugeneOZ]

Нет, это я про Redis Cluster, который делает автор Redis.
Если нужен именно сейчас, и Вы готовы доверять этой компании (я о них просто не знаю ничего), то вот есть сервис уже: redis-cloud.com/
У амазона вот: aws.amazon.com/elasticache/

Answer 3

[Евгений Селезнев]

Это вы, получается, вопрос про горизонтальное масштабирование задали.
Серверы приложений масштабируются с помощью балансировщика(HAproxy да или сам nginx). Они хранят только исполняемые файлы (грубо, говоря, их содержимое одинаково в любой момент времени и не содержит какого-нибудь UG-контента), поэтому тут зеркалирования данных не нужно — логгирование идет в бд или какой-нибудь централизованный сервис, статика в CDN. Серверы БД — репликация/шардинг, тут уже в зависимости от конкретной используемой СУБД, в той же Монго все из коробки, в PostgreSQL — PL/Proxy, PgPool.
Самое главное — максимально разделить и обособить части приложения, если оно прямо к себе на хост пишет логи, заливает юзерпики и еще что-то такое делает — будет весьма тяжело это все масштабировать потом.

Answer 4

[Wott]

HL это на самом деле задача по оптимизации. В первую очередь надо уменьшить времена формирования ответа, времена загрузки на клиенте, что достигается оптимизацией самого приложения (профилирование, склеивания запросов и разнесения контента) и и потом уже кеширования, которое бывает разное — тупое (ставим nginx ) или структурное ( разбиваем на блоки, которые формируем и кладем например в memcached ), управляемое ( содержимое меняется при необходимости ) и нет ( по таймауту ). Для кеширования может понадобиться изменять приложение ( обновления в данных ) или адаптировать кеширование ( сброс кеша или его игнорирование по кукам например )
Дальше, если сервер уже не справляется в одиночку или надо HA, переходим к горизонтальному масштабированию. И начинать надо с того что запросы должны быть атомарными — любые состояния, типа сессий, усложнят масштабирование ( придется расшаривать сессии на кластер или привязывать пользователя к серверу по ip например, что легко если шардинг, но HA страдает ). Какая база ( SQL или NoSQL. не говоря уже об названии ) или кластер — зависит в первую очередь от приложения, а не от моды или комментов на хабре. Лучше жить на MySQL, тем более что Percona+Galera очень даже неплохи, если вы его хорошо знаете, чем окунаться в проблемы незнакомого сервера на production. Опять же конкретная технология должна решать конкретные проблемы, которые определяются, исходя из архитектуры приложения в первую очередь. Ну и пробовать, экспериментировать.

Comments

[EugeneOZ]

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

[EugeneOZ]

«если сервер не справляется в одиночку» — вы называете это highload? И как же вы собираетесь обеспечивать fault tolerance с одним то сервером?

[Wott]

У меня кластер живой и баги я читаю :)
Не стоит все в кучу мешать — есть нагрузка и есть требования по доступности и резервированию. Иногда они приводят к похожим движениям, но в принципе это разные вещи. А так — если у кого-то сервак успешно держит 100500 конкурентных запросов, то почему бы и не HL?

[EugeneOZ]

Ну посмотрите вот на этот:
bugs.launchpad.net/codership-mysql/+bug/587170
«Adding AUTO_INCREMENT column to a table results in data inconsistency» — ну не трындец ли? Баг с 2010 года!!!

1 сервак вполне может держать очень много запросов, я не спорю, но без fault tolerance я архитектуру HighLoad не представляю — при простом обновлении софта всё приляжет. И при HighLoad это означает High-потери :)

[Wott]

Это все из разряда выстрелов в ногу

[EugeneOZ]

Добавить в таблицу поле это уже выстрел в ногу? Ну ок, называйте это «хорошей репликацией», если уж так хочется.

[Wott]

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

[EugeneOZ]

При чём тут дураки, клоуны и продакшен? Это обычное изменение таблицы. Хоть она трижды продакшен, она будет со временем изменяться. Это реальный случай из жизни — всё это было сделано не «через консоль», а миграциями, как обычно. Ок, считайте, что я Вам ничего не говорил и багов никаких нет — мне пофиг :)

Answer 5

[dshvechikov]

Помимо использования memcached очень помогает отправлять «тяжёлые» задачи в очередь. например, rabbitMq

Answer 6

[Антон Соломонов]

Когда-то передо мной вставала подобная задача. Гляньте мою статью по этому поводу.
habrahabr.ru/post/106311/

Answer 7

[Дэн]

Если в двух словах, то намного важнее решения архитектурные, чем софтовые. Т.е. плохую архитектуру не спасет использование nginx'a, может только отложить проблемы. Да и касательно использования количества технологий, я бы советовал использовать минимум, но с умом. Лучше иметь 3 хорошо отлаженых узла, чем 10. Каждая новая технология будет только усложнять инфраструктуру.

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

Также советую прочитать Что такое highload.