Недавно я столкнулся с потоком трафика в приложении Facebook, которое я создал (в основном ради образования, а не с целью маркетинга).
Излишне говорить, что я не думал о масштабируемости, когда создавал приложение. Сейчас я нахожусь в положении, когда мой скудный виртуальный сервер, размещенный на MediaTemple, совсем не режет его, и на самом деле все сводится к необработанному вводу-выводу машины. Поскольку этот проект до сих пор был для меня очень образовательным, я решил, что воспользуюсь этим как возможностью понять платформу Amazon EC2.
Само приложение создано на PHP (с использованием Zend Framework) с серверной частью MySQL. По возможности я использую кеширование приложений с помощью memcached. Я провел выходные, играя с EC2, раскручивая инстансы, устанавливая нужные мне пакеты и монтируя том EBS к инстансу.
Но какой следующий логический шаг даст хорошие результаты с точки зрения масштабируемости? Должен ли я запустить экземпляр AMI для MySQL и один для службы Apache? Или я просто реплицирую экземпляры столько раз, сколько мне нужно, а затем выполняю какую-то балансировку нагрузки во внешнем интерфейсе? В идеале я хотел бы иметь централизованную базу данных, потому что я собираю статистику по всем строкам базы данных, однако это не является жестким требованием (вероятно, есть некоторые решения для конкретных приложений, которые я мог бы придумать, чтобы обойти это)
Я знаю, что это, вероятно, непростой ответ, поэтому мнения и предложения приветствуются.
2 ответа
Так много вопросов, но все они хороши.
Что касается масштабирования, у вас есть несколько вариантов.
Первый - начать с одной коробки. Вы можете масштабировать вверх - с более мощным ящиком. EC2 имеют экземпляры разного размера. Это включает в себя миграцию сервера каждый раз, когда вам нужен ящик побольше.
Проще добавить серверы. Вы можете начать с одного экземпляра для Apache и MySQL. Затем, когда трафик возрастет, создайте отдельный экземпляр для MySQL и укажите в своем приложении этот новый экземпляр. Это создает хороший слой между приложением и базой данных. Судя по вашему трафику, это хорошая отправная точка.
Затем вам, вероятно, понадобится больше мощности приложения (веб-серверы) или больше мощности базы данных (кластер MySQL и т. Д.). У вас могут быть записи DNS, указывающие на пару фронтальных серверов, на которых запущено какое-то программное обеспечение для балансировки нагрузки (попробуйте Pound) . Эти серверы балансировки нагрузки распределяют запросы на ваши веб-серверы. EC2 имеет эластичную балансировку нагрузки, которая является альтернативой самостоятельному управлению и, вероятно, проще - я лично не использовал.
Еще кое-что, о чем следует помнить - EC2 не имеет постоянного хранилища . Вы должны сами управлять постоянными данными, используя Elastic Block Store. Это руководство - отличное руководство о том, как это сделать с помощью автоматического резервного копирования. .
Я рекомендую вам приобрести несколько зарезервированных инстансов, если вы решите, что EC2 - это путь вперед. Вы сэкономите около 50% за 3 года!
Наконец, вас могут заинтересовать такие услуги, как RightScale, которые предлагают платные услуги управления. Доступны и другие провайдеры.
Первый шаг - разделить проблемы. Я бы выделил отдельный сервер MySQL и, возможно, выделенный модуль memcached, в зависимости от того, насколько высока ваша нагрузка. Затем я бы отслеживал использование памяти и ЦП на каждом блоке и смотрел, где можно оптимизировать, где это возможно. Это можно сделать, создав новые коробки Media Temple. Я также порекомендовал бы Slicehost в качестве более дешевой и удобной для разработчиков альтернативы.
Еще несколько оптимизаций низкобюджетного развертывания PHP:
- Использование более эффективного веб-сервера, такого как nginx для обработки статических файлов, а затем обратных запросов прокси-приложения к отдельному экземпляру Apache
- Реализуйте PHP с FastCGI поверх nginx, используя что-то вроде PHP-FPM, полностью избавившись от Apache. Это может быть отличной альтернативой, если ваши потребности Apache не выходят далеко за рамки
mod_rewriteи более простых модулей Apache.
Если вы предпочитаете более высокоуровневый подход «сделай сам», вы можете попробовать Scalr (код в Google Code). Стоит посмотреть видео на их сайте. Он предоставляет масштабируемую среду хостинга с использованием Amazon EC2. Эта технология имеет открытый исходный код, поэтому вы можете загрузить ее и реализовать самостоятельно на своем собственном сервере управления. (Возможно, ваша коробка Media Temple?) Scalr имеет готовые AMI (устройства EC2), доступные для некоторых распространенных случаев использования.
- Интернет : использует nginx и его многочисленные возможности: балансировку нагрузки программного обеспечения, обслуживание статических файлов и т. д. У вас, вероятно, будет только один из них, и он, вероятно, будет реализовывать какое-то соединение с Amazon EBS или решение для постоянного хранения, как упомянул dcaunt.
- приложение : сервер приложений с Apache и PHP. Вероятно, у вас их будет много, и они будут созданы автоматически, если потребуется обработать больше нагрузки. Этот тип сервера будет содержать копии вашего приложения ZF.
- db : сервер базы данных с MySQL. Опять же, у вас, вероятно, будет много из них, и больше подчиненных экземпляров будет создано автоматически, если потребуется обрабатывать больше нагрузки.
- memcached : выделенный сервер memcached, который можно использовать для централизованного кэширования, управления сеансами и т. д. для всех экземпляров вашего приложения .
Параметр Scalr, вероятно, потребует дополнительных изменений конфигурации, но если вы чувствуете, что масштабирование требует быстрого ускорения, это может стоить времени и усилий.
Похожие вопросы
Новые вопросы
php
PHP - это широко используемый высокоуровневый, динамический, объектно-ориентированный и интерпретируемый язык сценариев, в первую очередь предназначенный для серверной веб-разработки. Используется для вопросов о языке PHP.
En Español