Лучший способ загрузить классы php в EC2 - InstanceStore, EBS или S3?

Question

Каков наилучший способ загрузки классов PHP в EC2 в следующем сценарии (# приведены в иллюстративных целях)? -> 100 экземпляров EC2, работающих под Apache и APC -> 100 php классов загружены за запрос (через __autoload) -> 100 изменений кода в день между классами (многие из классов содержат автоматически сгенерированный код, который периодически обновляется через cron).

Из того, что я понял, есть 3 способа загрузки файлов классов php в EC2:

A. InstanceStore - The local (virtual) hard drive of an EC2 instance
-> Code must be pushed separately to each instance.
-> Fastest loading since no need to go over the network

B. EBS - A volume mounted to a particular instance
-> Code must be pushed separately to each instance.
-> Slower loading since go over the network

C. S3 - A S3 bucket can be 'mounted' to 1 or more EC2 instances
-> Code only needs to be pushed once
-> Slowest loading since go over the network

Даже с включенным APC на экземплярах apache я не могу отключить fstat в APC из-за неуверенности в том, как обрабатывать аннулирование кэшированных классов на всех 100 экземплярах apache 100+ раз в день (при изменении кода) , В результате, если при каждой загрузке класса будет сгенерирован вызов файловой системы, даже если класс был кэширован с помощью apc (для выполнения вызова fstat), не было бы огромной задержки, если бы было 100 обращений по сети для выполнения fstat или читать файл по каждому запросу?

Каков наилучший вариант (или, возможно, новый способ, которого здесь нет в списке) для загрузки файлов классов в описанном сценарии?

Answer 1

Всегда используйте экземпляр EBS . Повторите: всегда используйте экземпляр EBS.

Когда необходимо применить изменения кода, раскрутите новый экземпляр с поддержкой EBS из снимка текущего. Пока не добавляйте его в свой балансировщик нагрузки.

Применить изменения кода.

Создайте новый снимок EBS. Это ваш золотой стандарт для текущего раунда изменений кода.

При необходимости запускайте новые экземпляры, поддерживаемые EBS, из нового снимка золотого стандарта.

Запустите сценарий, который запускает ваш веб-сайт на новых экземплярах, которые еще не принимают реальный трафик, чтобы согреть их (загрузить классы PHP в APC).

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

Завершить старые экземпляры.

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

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

Answer 2

Вы думали о сериализации объекта и помещении всего объекта в кэш-память apc ИЛИ помещении его в нечто вроде memcached?