Масштабирование с 1 веб-сервера + 1 сервер БД

Question

Мы - компания Web 2.0, которая с самого начала создала размещенное решение для управления контентом с использованием LAMP. Короче говоря, люди заходят в наш бэкэнд для управления контентом своего веб-сайта, а затем используют наш API для его извлечения. Этот API подключается к шаблонам, которые могут быть размещены в любом месте на веб-сайтах.

Масштабирование для нас продвигается следующим образом:

1. Общий хостинг (1and1)
2. Выделенный хостинг на одном сервере (Rackspace)
3. 1 веб-сервер, 1 сервер БД (Rackspace)
4. 1 бэкэнд-веб-сервер, 1 веб-сервер API, 1 сервер БД
5. Memcache, кеширование, кеширование, кеширование.

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

Это, очевидно, «следующая проблема» для любой компании, подобной нашей, и мне было интересно, не могли бы вы указать мне некоторые направления.

В настоящее время меня привлекают решения для виртуализации (например, EC2), но мне нужно несколько советов о том, что следует учитывать.

Answer 1

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

Это время поиска БД?

Объем запросов, которые веб-сервер просто не может обработать, даже если они недолговечны?

Запросы API слишком долго обрабатываются? (независимо от поиска в БД, например, для выполнения кода требуется немного времени)?

Как только вы определили, в чём проблема, у вас должна быть достаточно четкая картина того, что вам нужно делать. Если это просто объем запросов и это сервер API, вам просто нужно больше веб-серверов (и изменения кода для обеспечения горизонтального масштабирования) или более мощный веб-сервер. Если запросы API занимают слишком много времени, вы смотрите на оптимизацию кода. Там никогда не бывает один выстрел, когда речь заходит о масштабируемости.

Наиболее распространенные проблемы масштабирования связаны с медленным (2-3 секунды) выполнением фактического кода для каждого запроса, что, в свою очередь, приводит к увеличению количества веб-серверов, что приводит к большему взаимодействию с базой данных (для межсерверных сеансов, и т.д.), что приводит к проблемам с производительностью базы данных. Высокопроизводительный, независимый от сервера код с memcache (я на самом деле предпочитаю оболочку вокруг memcache, чтобы приложение не знало / не заботится, откуда оно получает данные, только то, что оно получает его, а уровень перевода обрабатывает поиск в DB / memcache, а также заполнение кэш).

Answer 2

Действительно зависит от того, является ли ваше узкое место чтением или записью. Масштабирование записей намного сложнее, чем чтение.

Это также зависит от того, сколько данных у вас есть в базе данных.

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

Если вам нужно масштабировать записи, это совершенно другая игра. Для этого вам нужно разделить данные по горизонтали (разделение / разделение) или по вертикали (функциональное разделение и т. Д.), Чтобы вы могли распределить рабочую нагрузку по нескольким серверам записи, которые не должны выполнять работу друг друга.

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

Answer 3

Какой уровень масштабирования вы ищете? Является ли это решением для остановки, например масштабировать вертикально? Если это более стратегический проект масштабирования, поддерживает ли ваша текущая архитектура горизонтальное масштабирование?