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

Каков наилучший способ загрузки PHP-классов в EC2 в следующем сценарии (#s для иллюстративных целей)? -> 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 или прочитать файл по каждому запросу?

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

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

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

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

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

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

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

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

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

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

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

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