Недавно я столкнулся с потоком трафика в приложении Facebook, которое я создал (в основном ради образования, а не с целью маркетинга).

Излишне говорить, что я не думал о масштабируемости, когда создавал приложение. Сейчас я нахожусь в положении, когда мой скудный виртуальный сервер, размещенный на MediaTemple, совсем не режет его, и на самом деле все сводится к необработанному вводу-выводу машины. Поскольку этот проект до сих пор был для меня очень образовательным, я решил, что воспользуюсь этим как возможностью понять платформу Amazon EC2.

Само приложение создано на PHP (с использованием Zend Framework) с серверной частью MySQL. По возможности я использую кеширование приложений с помощью memcached. Я провел выходные, играя с EC2, раскручивая инстансы, устанавливая нужные мне пакеты и монтируя том EBS к инстансу.

Но какой следующий логический шаг даст хорошие результаты с точки зрения масштабируемости? Должен ли я запустить экземпляр AMI для MySQL и один для службы Apache? Или я просто реплицирую экземпляры столько раз, сколько мне нужно, а затем выполняю какую-то балансировку нагрузки во внешнем интерфейсе? В идеале я хотел бы иметь централизованную базу данных, потому что я собираю статистику по всем строкам базы данных, однако это не является жестким требованием (вероятно, есть некоторые решения для конкретных приложений, которые я мог бы придумать, чтобы обойти это)

Я знаю, что это, вероятно, непростой ответ, поэтому мнения и предложения приветствуются.

30
Andy Baird 21 Окт 2009 в 03:40

2 ответа

Лучший ответ

Так много вопросов, но все они хороши.

Что касается масштабирования, у вас есть несколько вариантов.

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

Проще добавить серверы. Вы можете начать с одного экземпляра для Apache и MySQL. Затем, когда трафик возрастет, создайте отдельный экземпляр для MySQL и укажите в своем приложении этот новый экземпляр. Это создает хороший слой между приложением и базой данных. Судя по вашему трафику, это хорошая отправная точка.

Затем вам, вероятно, понадобится больше мощности приложения (веб-серверы) или больше мощности базы данных (кластер MySQL и т. Д.). У вас могут быть записи DNS, указывающие на пару фронтальных серверов, на которых запущено какое-то программное обеспечение для балансировки нагрузки (попробуйте Pound) . Эти серверы балансировки нагрузки распределяют запросы на ваши веб-серверы. EC2 имеет эластичную балансировку нагрузки, которая является альтернативой самостоятельному управлению и, вероятно, проще - я лично не использовал.

Еще кое-что, о чем следует помнить - EC2 не имеет постоянного хранилища . Вы должны сами управлять постоянными данными, используя Elastic Block Store. Это руководство - отличное руководство о том, как это сделать с помощью автоматического резервного копирования. .

Я рекомендую вам приобрести несколько зарезервированных инстансов, если вы решите, что EC2 - это путь вперед. Вы сэкономите около 50% за 3 года!

Наконец, вас могут заинтересовать такие услуги, как RightScale, которые предлагают платные услуги управления. Доступны и другие провайдеры.

14
David Snabel-Caunt 21 Окт 2009 в 16:43
Это похоже на мои первые шаги. Вопрос: можно ли подключить том EBS к нескольким экземплярам? Я думаю, что могу сохранить каталог / var / www на сервере apache в EBS, а данные mysql - на сервере mysql в EBS.
 – 
Andy Baird
21 Окт 2009 в 20:59
К сожалению нет. Думайте о EBS как о жестком диске, его можно подключать только к одному экземпляру за раз. Вы можете клонировать их, но клонированная EBS не получает никаких изменений или новых данных. Ваша задача - написать сценарий, который автоматически настраивает новые экземпляры - проверяет ваш код на предмет подрывной деятельности, настраивает apache, сообщает балансировщику нагрузки, что он готов к приему запросов. Я считаю, что такие сервисы, как RightScale, упрощают эту часть.
 – 
David Snabel-Caunt
22 Окт 2009 в 13:13

Первый шаг - разделить проблемы. Я бы выделил отдельный сервер 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, вероятно, потребует дополнительных изменений конфигурации, но если вы чувствуете, что масштабирование требует быстрого ускорения, это может стоить времени и усилий.

10
patcoll 21 Окт 2009 в 18:52
Scalr выглядит очень интересно. Хотя, вероятно, это на шаг выше моих потребностей. Я, наверное, начну с вашей первой рекомендации и перейду к ней
 – 
Andy Baird
21 Окт 2009 в 20:46