Назад | Перейти на главную страницу

Мультисайт на AWS EC2

Я работаю над многосайтовым приложением, предназначенным для полноценной работы Amazon Web Services. Из-за своей природы он будет иметь значительные всплески трафика, за которыми последуют длительные периоды низкого трафика, поэтому возможность масштабирования экземпляров EC2 является обязательной.

Пока что я имею в виду следующую структуру:

                                _____________________
                                Elastic Load Balancer
                                _____________________
                                          |
                                          V
                                _____________________
                          []   []   []   []   []   []   []
                                   Autoscaling EC2
                                With Dynamic Virtual
                                        Hosts
                                Global Business Logic
                                _____________________
                                /         |          \
                               /          |           \
                       Amazon RDS         S3        Site Views?
                      One Per Site       for      
                                     static files

Теперь у меня два вопроса:

  1. Где мне хранить файлы "представлений" или "тем" для конкретного сайта? Достаточно ли быстр S3, чтобы справиться с этим? Или мне действительно следует создавать новые AMI каждый раз, когда мне нужно настроить тему определенного сайта?
  2. Файлы конфигурации. Поскольку каждый сайт подключается к отдельной базе данных, каждому из них нужны свои файлы конфигурации. Опять же, следует ли мне хранить их на S3, и все экземпляры EC2 время от времени проверяют S3 на наличие обновленных конфигураций?

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

  1. Я подумываю использовать методику создания пользовательских AMI, которые при запуске будут загружать необходимые данные для начальной загрузки. В вашем случае вы можете оставить свои сайты на S3 и загружать файлы при загрузке. Если вы используете CloudInit для Ubuntu или чего-то подобного для других дистрибутивов, вы можете легко выполнить установку своего сайта по сценарию. Я считаю, что он запускается только при первой загрузке, поэтому скользящее завершение узлов должно привести к обновлению последней версии сайта. В этом случае вам не придется постоянно обновлять AMI.

  2. Если у вас нет настройки системы управления конфигурацией, достаточно просто сохранить файл на S3 с необходимой конфигурацией. По мере роста Chef или Puppet могут стать лучше, но им потребуется время, чтобы научиться. Этот файл можно загрузить таким же образом или запустить с помощью такого инструмента, как Fabric или Capistrano.

Fabric и Capistrano могут помочь вам запускать небольшие обновления. Если вы повторно используете сценарий CloudInit, вам не придется кодировать его дважды. И Fabric, и Capistrano могут довольно легко интегрироваться с API AWS, что позволяет выполнять динамические запросы к работающим узлам, поэтому вам не придется поддерживать постоянно меняющиеся списки серверов.

Недавно запущенный инструмент для создания AMI под названием Упаковщик может быть вам полезен. В моей первой попытке мне удалось создать новый AMI за 30 минут после начала обучения. Это также может помочь создать AMI для нескольких регионов.