Это большой вопрос :) У нас есть небольшой веб-сайт с LAMP, 5 веб-серверов с балансировкой нагрузки LVS, 3 сервера MySQL с репликацией и разделением чтения и записи, и мы используем Memcached для кеширования и некоторого полнотекстового поиска. инструменты. Пока это работает хорошо, потому что у нас пока нет большого трафика.
Но когда количество пользователей будет быстро расти, нам придется масштабировать нашу архитектуру, чтобы удовлетворить потребности. Возможно, будут представлены распределенная файловая система и база данных (и параллельные вычисления?), А также некоторые методы кластеризации и обслуживания (например, Gearman и Pshell).
В сети есть несколько статей, которые я могу просмотреть. Но мне действительно нужен практический опыт, чтобы подготовиться к этому вопросу целесообразно и эффективно.
Существует множество методов масштабирования веб-приложений и поддерживающей инфраструктуры. Кэл Хендерсон написал хорошую книгу на эту тему под названием «Создание масштабируемых веб-сайтов». Это было основано на его опыте работы с Flickr. Если вы не будете расти медленно, вы столкнетесь с теми же проблемами роста, с которыми сталкивались многие другие. Масштабирование, как и многие другие предметы, - это путешествие, а не пункт назначения.
Первые шаги - сделать все повторяемым, измеримым и управляемым. Под повторяемостью я подразумеваю использование таких инструментов, как FAI или kickstart, для установки ОС и что-то вроде puppet или cfengine для настройки машин после установки базовой ОС. Под измеримыми я подразумеваю использование чего-то вроде кактусов, сверчков или ганглиев, чтобы отслеживать, как сейчас работает ваш кластер. Измеряйте не только такие вещи, как средняя загрузка, но и то, сколько времени требуется для отображения страницы или обслуживания запроса. Ни один из них не кажется критичным при запуске, но должен сообщить вам об этом до того, как ваша система упадет из-за нагрузки, и может упростить одновременное добавление 10 или сотни машин. Основывайте свои планы роста на данных, а не на предположениях.
Управляемость означает установку инструментов, позволяющих автоматически создавать и тестировать как можно большую часть своей конфигурации. Начни с того, что у тебя есть, и развивай это. Если вы храните информацию о машине в базе данных, отлично. Если нет, у вас, вероятно, есть таблица, которую вы можете экспортировать. Поместите свою конфигурацию в какой-то элемент управления версиями, если вы еще этого не сделали. Автоматическое создание конфигураций из вашей базы данных позволяет вам расти с меньшим стрессом. Их тестирование до того, как они появятся на ваших серверах, может спасти вас от того, что служба не запустится из-за опечаток или других ошибок.
Горизонтальные методы предполагают, что вы можете правильно повторять вещи. Подумайте о своем приложении. Какие области имеет смысл разделить? Какие области могут обрабатываться несколькими машинами параллельно? Влияет ли задержка на ваше приложение. Насколько велика вероятность того, что вы столкнетесь с ограничениями на количество подключений или другими узкими местами? Вы просите, чтобы ваши веб-серверы также выполняли доставку почты, базу данных или другие обязанности?
Я работал в средах с сотнями веб-серверов. Вещи должны разделяться по-разному для разных типов нагрузки. Если у вас есть большие коллекции файлов данных, которые редко меняются, их разделение от активно меняющегося «материала» может дать больше места для обслуживания как статических, так и динамических данных. Разные инструменты лучше подходят для разных нагрузок. Apache и Lighttpd хорошо работают для одних вещей, Nginx - для других.
Посмотри прокси и кеши. Как между вашими пользователями и приложением, так и между частями приложения. Я читал, что вы уже используете memcache, это помогает. Размещение обратного прокси-сервера, такого как perlbal или pound, между вашим балансировщиком нагрузки и веб-серверами может иметь смысл в зависимости от трафика вашего приложения.
В какой-то момент вы можете обнаружить, что репликация MySQL master <-> (N * slave) не справляется и что вам нужно разделить базы данных. Разделение ваших баз данных может потребовать настройки другого уровня управления данными. Многие люди используют для этого другую базу данных с кэшем памяти. В одном месте, где я работал, мы использовали реплицированные пары master <-> master для большинства данных, а другую пару с 10 ведомыми устройствами чтения для указателей на данные.
Это всего лишь краткое описание некоторых проблем, с которыми я столкнулся при работе на сайтах с сотнями компьютеров. Нет конца тому, что подкрадывается от нескольких машин до нескольких сотен. Я уверен, что то же самое можно сказать и о росте до тысяч.
В последнее время появилось много хорошей литературы по этой теме. Начать с Высокая масштабируемость, многие из лучших вещей нравятся оттуда. Вы можете взглянуть на Технический блог Digg для понимания того, как мы делаем что-то, и вы также можете обратиться к таким ресурсам, как SAGE - люди из списков SAGE - отличный ресурс.
Быстрый рост пользовательской базы большинства веб-приложений требует от разработчиков использования кэша памяти перед базами данных. Данные должны быть вычислены и сохранены в кеше. Это поможет сократить время, необходимое для передачи данных на страницу по запросу пользователя.