Перенос web-приложения на Amazon за 3 шага

После недавнего обновления платформы Amazon Web Services, которое позволило оптимизировать затраты на использование ее ресурсов, перенос веб-приложений на AWS приобрел еще больший смысл. В первую очередь, для тех веб-сервисов, которые уже убедились в своей востребованности и теперь ищут способы сократить затраты и повысить надежность в условиях возрастающей нагрузки. Однако, для того, чтобы эти два ожидания от AWS действительно оправдались, нужно знать о некоторых особенностях этой платформы. Ниже приведен простой план переноса веб-приложения на AWS с рекомендациями опытных пользователей системы и ссылками на подробное описание некоторых задач.

Шаг 1. Перенос статического контента на Amazon S3

Это первая и самая простая задача. Проста и понятна и польза от Amazon S3: дешевая память, дешевый трафик, отличная надежность доставки файлов на любых нагрузках. О том, как создать аккаунт в AWS, подключить сервис S3 и работать с ним можно прочитать здесь (в конце статьи). А вот еще важные вещи, которые нужно иметь в виду:

- S3 не умеет самостоятельно архивировать файлы в GZIP, поэтому чтобы уменьшить трафик, рекомендуется закачать на S3 GZIP-архивы вместе с самими файлами

- Файлы, загружаемые на S3 становятся доступными не сразу, а через несколько секунд

- Если вы хотите получить еще более высокую скорость загрузки файлов по всему миру, вам стоит рассмотреть сервис CloudFront. Как его настроить, написано здесь

Шаг 2. Перенос серверов на Amazon EC2

С помощью сервиса EC2 вы можете настроить сервер (instance) такой же самой конфигурации, какую использовали ранее. О том, как это сделать подробно написано опять здесь. Самое сложное в этом процессе - перенос базы данных. Если вы хотите сохранить используемую СУБД, то рекомендуется использовать сервис Elastic Block Storage, который позволяет базе данных функционировать даже при глюках сервера. Кроме того, этот сервис позволяет настроить создание бэкапов базы и сохранять их на S3.

Вариант использования MySQL описан здесь, а MS SQL Server - здесь. В качестве альтернативы реляционным СУБД можно рассмотреть возможность переноса базы данных на Amazon SimpleDB. Довольно подробный анализ плюсов и минусов SimpleDB с технической точки зрения можно найти здесь.

Шаг 3. Оптимизация используемых ресурсов

Конечно, вы можете подключить достаточное количество серверов и платить за них и даже отключать некоторые из них на ночь, но это дорого и неудобно. Специалисты рекомендуют воспользоваться сервисом CloudWatch, который позволяет мониторить используемые ресурсы. На основании данных этого сервиса, настройте фичи Auto Scaling и Elastic Load Balancing, позволяющие оптимизировать используемые сервера и потоки трафика между ними. Подробнее об этих фичах лучше всего написано здесь.

Также рекомендуется, на сколько это возможно, уменьшить свою зависимость от реляционной СУБД (т.к. это самый сложный компонент для масштабирования) и постараться перенести максимум данных из нее в S3 и SimpleDB (на S3 стоит переносить большие объекты данных, а в SimpleDB - маленькие).

Важные замечания:

- Elastic Load Balancing не поддерживает SSL-трафик

- Simple DB имеет ограничение на максимальный размер строки. Если ваша база данных превышает этот лимит, то лучше в ней оставить метаданные, ссылающиеся на объекты на S3