Назад | Перейти на главную страницу

Масштабирование стека LAMP

Как только вы выйдете за пределы 100 000 обращений в месяц, что люди в этом сообществе сочтут самым большим препятствием?

Моя ситуация: тонны статических носителей (аудио / видео / изображения) обслуживаются вне S3 / CDN, но хранятся локально в качестве резервных копий (хотя не обслуживаются). Все, что можно кэшировать, кэшируется, примерно с 8 гигабайтами памяти с возможностью увеличения до 32.

В настоящее время мы без проблем обрабатываем около 100 000 обращений и хотели бы знать, с какими проблемами сталкивались другие: балансировка нагрузки? проблемы с памятью? дисковый ввод / вывод?

Спасибо за любые советы. Я просмотрел связанные вопросы, и они хорошо на них ответили, но просто хотел получить больше отзывов.

В наши дни оборудование настолько дешево, что все меньше людей даже доходят до того, что им требуется более одной машины. За 10 000 долларов вы купите:

  • 16-32 ГБ оперативной памяти;
  • 2 четырехъядерных процессора Xeon;
  • Дисковый массив RAID5.

Такой тип машины может обслуживать более 10 000 одновременных пользователей даже на слегка оптимизированном сайте для всех приложений, кроме наиболее ресурсоемких.

В основном есть два подхода к масштабируемости:

  • Вертикальный: в основном покупка самой большой машины, поэтому вам не нужно больше одной;
  • По горизонтали: делать вещи способом, который поддается параллелизму. Требуется только для самых интенсивных приложений.

Посмотрите на StackOverflow: он в основном работает на веб-сервере плюс сервер базы данных и делает более 6 миллионов обращений в месяц.

При этом масштабируемость - это поиск и устранение узких мест.

  • Если ваша база данных замедляет работу, либо дайте ей больше ресурсов, либо используйте какую-либо форму кэширования в памяти, чтобы снять нагрузку;
  • Если дисковый ввод-вывод является вашей проблемой, то применимо то же самое;
  • Если вам не хватает памяти до такой степени, что это вызывает слишком много ошибок страниц и, таким образом, вызывает проблемы с дисковым вводом-выводом, добавьте больше памяти;
  • Поддается ли ваше приложение и его данные разделению между серверами? Если да, то это один из способов масштабирования по горизонтали;
  • Если пропускная способность является проблемой, и вы доставляете большие файлы, то, возможно, решением будет CDN;
  • И так далее.

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

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

Использовать Лак или Кальмар. Оба являются веб-ускорителями и отлично подходят для статических мультимедийных файлов.

При горизонтальном масштабировании у вас даже может быть 1 машина для веб-кеша и 1 машина для динамического контента.

В качестве альтернативы вы можете попробовать настроить apache с помощью модов: mod_expires, mod_headers, mod_cache, mod_file_cache, mod_mem_cache.

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

Учитывая, что ваш контент включает видео, я бы предположил, что вашей первой проблемой будет пропускная способность сети, за которой последуют запросы ввода-вывода, когда у вас будет достаточно одновременных запросов для больших объектов. Если у вас больше ОЗУ, чем данных, то ввод-вывод будет меньшей проблемой, как только все будет помещено в кеш (хотя для заполнения кеша после любого выключения сервера потребуется время).

Одна вещь, которую вы должны указать при попытке установить такие требования к размеру, - это то, какое распределение имеют ваши обращения. Распределяются ли они равномерно в течение месяца или более скачкообразно? Например, сайт, на котором размещена информация о национальной лотерее, может видеть 80% или более своего еженедельного трафика в двухчасовом окне после времени розыгрыша - 80% 100K запросов за два часа составляют 2,7 в секунду (при условии, что 4 недели в месяц) все еще не массово, но доставляется в зависимости от размера / сложности или ответов. Возможны и другие, менее предсказуемые всплески, например, что произойдет, если видео на вашем сайте попадет на первую страницу Digg или аналогичного.

Как только вы выйдете за пределы 100 000 обращений в месяц

НИЧЕГО !!! Если у вас проблемы с обслуживанием 100 тысяч обращений в месяц, значит, у вас проблемы. Как правило, у вас не должно возникнуть проблем с большинством самых глупых систем, обслуживающих 100К в день.

Это про LAMP ... и CMS системы

Моя ситуация: тонны статических носителей (аудио / видео / изображения) обслуживаются с S3 / CDN

Для этих целей есть очень хорошие веб-серверы: lighttpd - он обслуживает потоковую передачу мультимедиа YouTuble, nginx тоже хорош.

Это легкие веб-серверы, которые очень хорошо масштабируются при высоких нагрузках.

Помогло бы даже переключение модуля Apache с mod-prefork на mod-worker (даже lighttpd по-прежнему намного лучше).

Нижняя граница: эти нагрузки далеки от высоких.

Немного зависит от того, какая база данных обрабатывает ваши действия - обслуживаете ли вы статический контент или почти статический контент; вы сможете масштабироваться далеко за пределы 100K / мес с очень скромным оборудованием.

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

Хотя, честно говоря, я думаю, что вы, вероятно, переоцениваете спрос прямо сейчас - 100 тысяч - это вполне приемлемо для обработки на одной машине. После того, как вы превысите 10M, вам нужно будет рассмотреть более сложные решения, такие как те, которые я описал выше.

Мой личный совет - всегда отдавать предпочтение параллельным машинам над отдельными сложными - это не только в конечном итоге дешевле, но и дает вам гораздо больше возможностей для роста, когда придет время. Расширяя и без того дорогое оборудование, вы попадаете в область серверов за 25 000 долларов, где «цена за деньги» исчезает.

Вероятно, самые большие препятствия

  • приведение вашего приложения в форму для слабосвязанной архитектуры, которая отбрасывает ACID и другие строгие ограничения, чтобы обеспечить асинхронную работу и краткосрочные несоответствия. Видеть Теорема Брюера CAP для широкого обзора этой темы.

  • Разберитесь с правильным управлением множеством узлов. Сюда входят основные задачи системного администрирования, такие как управление пакетами, а также тестирование и развертывание запросов на изменение. Когда у вас есть 50 веб-серверов, вы не можете просто «перезапустить все серверы apache»; некоторые мысли должны быть внесены в эти задачи

  • что подводит меня к моему последнему пункту - понять эффекты, которые можно увидеть в больших системах. Громовое стадо это одна из вещей, которые вы собираетесь увидеть. Эта статья на Аудиогалактике также описывают несколько проблем больших систем.

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

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

Все, что нельзя исправить, потратив деньги, не имеет фиксированного `` времени на решение '', поэтому всегда пытайтесь кодировать / конфитировать свой выход из проблемы, но всегда оставляйте себе возможность выбросить ядра / циклы / память / хранилище / пропускную способность / что бы там ни было - их всегда можно заказать в FedEx :)

Как только вы выйдете за пределы 100 000 обращений в месяц, что люди в этом сообществе сочтут самым большим препятствием?

Из-за обдумывания проблемы, из-за разработки платформы и из-за усложнения системы.

100к / месяц это ничего. Вся ваша цель на этом этапе должна заключаться в том, чтобы уделять как можно меньше времени сосредоточению на ней внимания.