Моя компания в настоящее время переносит несколько веб-сайтов и веб-приложений PHP (стандартный стек LAMP) с трех внутренних серверов на Amazon EC2. Поскольку у нас было всего три сервера, мы сгруппировали несколько веб-сайтов с низким трафиком, возможно, с одним веб-приложением с высоким трафиком, и обслужили их с одного сервера. Администратор сервера практически полностью скопировал предыдущую архитектуру на экземпляры EC2, просто увеличив размер экземпляра, чтобы учесть самый высокий трафик клиента, который занимает этот конкретный экземпляр.
Эта архитектура могла бы быть хорошей, если бы не развертывание. Каждый раз, когда один из этих сайтов / приложений изменяется, это означает повторное развертывание всего экземпляра вместе с 30 сайтами / приложениями, которые он размещает, вместо простого обновления одного.
Как мы можем сделать наше облако более модульным? Должно ли каждое приложение получать собственный экземпляр подходящего размера? Какова наилучшая стратегия развертывания в такой ситуации?
Администратор вашего сервера фактически перенес ваши сайты из одного дата-центра в другой. Вы думаете об инстансах EC2 как о традиционных серверах. Пришло время изменить свое мышление. Думайте об экземплярах EC2 как о контейнерах для ваших веб-приложений и даже как о части вашего веб-приложения, а не просто о том, на чем вы их размещаете.
Модульность ваших сайтов - хорошая идея. Их можно разделить на один экземпляр EC2 на сайт. Таким образом, при развертывании обновления затрагивается только этот веб-сайт (хорошо или плохо).
Кроме того, вы можете разместить свои сайты за соответствующими балансировщиками нагрузки и / или группами автоматического масштабирования, чтобы приспособиться к изменениям нагрузки в зависимости от уникальных требований каждого сайта.
Взгляните на Elastic Beanstalk. Он пытается быть механизмом развертывания "из коробки" для веб-сайтов (PHP, .NET, Ruby и т. Д.). Если все пойдет хорошо, вам не нужно входить в свой экземпляр. Он использует один (или несколько) экземпляров EC2 для каждого веб-приложения в зависимости от вашей конфигурации.
Обратной стороной этого является стоимость: вы будете платить больше, потому что используете больше инстансов EC2. Но это компромисс в пользу модульности и надежности.