Архитектура PHP-приложения на Amazon EC2

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

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

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

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

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

Ответ 1

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

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

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

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

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

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

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

Наконец, вы можете быть заинтересованы в таких услугах, как RightScale, которые предлагают услуги по управлению за отдельную плату. Существуют и другие поставщики услуг.

Ответ 2

Первый шаг - разделить проблемы. Я бы разделился на отдельный сервер MySQL и, возможно, выделенный memcached box, в зависимости от того, насколько высока ваша нагрузка. Затем я буду контролировать память и использование ЦП на каждом поле и посмотреть, где вы можете оптимизировать, где это возможно. Это можно сделать с откручиванием новых ящиков Media Temple. Я также предлагаю Slicehost для более дешевой, более дружественной для разработчиков альтернативы.

Некоторые более низкобюджетные оптимизации развертывания PHP:

Использование более эффективного веб-сервера, такого как nginx для обработки статического файла, а затем обратного обращения к прокси-приложениям к отдельному экземпляру Apache
Внедрите PHP с FastCGI поверх nginx, используя что-то вроде PHP-FPM, полностью избавившись от Apache. Это может быть отличной альтернативой, если ваши потребности в Apache не распространяются далеко за пределы mod_rewrite и более простые модули Apache.

Если вы предпочитаете более высокоуровневый подход, сделайте сам, вы можете проверить Scalr (код в Google Code). Стоит посмотреть видео на своем веб-сайте. Он обеспечивает масштабируемую среду хостинга с использованием Amazon EC2. Технология является открытым исходным кодом, поэтому вы можете ее загрузить и реализовать самостоятельно на своем собственном сервере управления. (Возможно, это окно с медиа-камнем?). В Scalr есть предварительно встроенные AMI (устройства EC2), доступные для некоторых распространенных случаев использования.

web. Использует nginx и его многочисленные возможности: балансировку загрузки программного обеспечения, статическую работу с файлами и т.д. Возможно, у вас есть только один из них, и он, вероятно, будет реализовывать какое-то соединение с Amazon EBS или постоянное решение для хранения данных, как упоминалось dcaunt.
приложение: сервер приложений с Apache и PHP. Вероятно, у вас их много, и они будут созданы автоматически, если потребуется больше нагрузки. Этот тип сервера будет содержать копии вашего ZF-приложения.
db: сервер базы данных с MySQL. Опять же, у вас, вероятно, будет много таких, и больше подчиненных экземпляров будет создаваться автоматически, если потребуется больше нагрузки.
memcached: выделенный сервер memcached, который вы можете использовать для централизованного кэширования, управления сеансом и т.д. во всех ваших приложениях.

Опция Scalr, вероятно, потребует еще нескольких изменений конфигурации, но если вы чувствуете, что масштабирование требует быстрого ускорения, это может стоить времени и усилий.