Как сэкономить деньги в Amazon Web Services — выбор эффективной архитектуры

Сегодня поговорим на тему как «профессионально сэкономить» деньги при использовании облачных сервисов Amazon Web Services при размещении веб-решений, адаптированных для России. Мы активно используем сервисы данного облачного провайдера для проектов компании почти 2 года и постоянно занимаемся оптимизацией расходов. Довольно странно, что важная тема оптимизации расходов на Amazon Web Services, очищенная от маркетингового булшита, как-то не особо представлена в сети. Постараюсь предметно поделиться опытом и обозначить явные выгоды и ошибки, которые следует учесть при проектировании веб-систем.

Где запускать приложение?

В США (Virginia, Oregon) стоимость почасовой аренды виртуальных машин существенно дешевле, чем, например в Европе и других регионах AWS.
Но это еще цветочки. Ягодки — если взять виртуалки оптом на год вперед — то за виртуалки в Европе вы заплатите почти на 50% меньше, а в США — на 60% меньше (мы используем стандартные виртуалки: m1*, m2*, c*). Если брать машины на 3 года вперед — экономия еще больше.

Кроме этого, Amazon запускает в продакшн новые полезные технологии как правило сначала в США. Например диски с гарантированным и задаваемым при создании числом IOPS — поставил минимум 1500 IOPS на 4 диска в рейде 10 и забыл про производительность MySQL 🙂 Так же, облачный memcached и SMS-уведомления из облака появились сначала в американских датацентрах Amazon.

То есть если хочешь быть впереди планеты всей и платить за сервисы меньше — запускайся в датацентрах в США.

Однако, есть и минусы размещения в США для российский проектов. Один из них это latency в 150 ms — но если статические ресурсы передать в CDN Амазона или отечественный CDN — то задержка почти незаметна, т.к. клиент получает статику с ближайших к браузеру серверов с минимальной latency (единицы, максимум десятки ms). Во-вторых, датацентры в США, особенно самый большой в Вирджинии — падает, мягко сказать, чаще ближайшего к нам европейского в Ирландии. Видимо в США грозы случаются чаще 🙂

В общем, если хочется новых эффективных технологий в облаке, подешевле, вы готовы настроить CDN для отдачи статики и приложение размещено минимум в 2 локальных датацентрах региона Amazon для незаметного для клиента переключения трафика из одного ДЦ в другой при попадании молнии или другого предмета — можно смело выбирать США и размещать там свое веб-решение (это не сарказм, это минимум чтобы клиент почти ничего не заметил 🙂 ).

Экономия за счет особенностей архитектуры веб-решения

Вот тут самое интересное. Оказывается, если внимательно почитать про предлагаемые Amazon облачные кирпичики, такие как автомасштабируемые группы машин и балансировщики нагрузки, испив крепкий кофе — то видим, что можно оказывается запускать части своего веб-приложения на неиспользуемых мощностях облачного провайдера, стоимость которых в НЕСКОЛЬКО РАЗ ниже номинальной почасовой — т.е. почти даром 🙂
Т.е. если:

1. Ваше приложение не хранит файлов на диске виртуалки, а держит данные в БД и/или памяти
2. Образ виртуалки запускается контроллером автоматически масштабируемой группы — например в зависимости от нагрузки (у нас именно так)
3. Клиенты ходят на кластер машинок через облачный балансировщик

то вы совершенно спокойно, без технических рисков, можете настроить 2 группы автомасштабирования — основную и «копеечную». Нагрузку будет принимать на себя «копеечная» группа, со стоимостью машин, допустим 8 центов в час (описываю реальный пример из продакшена) — а в случае редких случаев увеличения цены Spot Instances — нагрузку автоматически возьмет на себя основная группа машин. В любом случае вы сэкономите на почасовой стоимости — в несколько раз.

Вот конкретный пример:

Стоимость виртуалки c1.xlarge в розницу в регионе us-east-1: $0.58.
Стоимость такой же виртуалки, арендуемой как Spot Instance на бирже неиспользованных ресурсов изредка поднимается выше $0.08

Т.е. если у вас кластер из 15 c1.xlarge — сделайте 2 кластера, один с «дешевыми» машинками размером 13, и один из стандартных машин по $0.58 размером в 2 машины. В случае возможного раз в несколько месяцев увеличения цены на Spot Instances выше номинальной — вы автоматически масштабируете стандартный кластер.

Однако отмечу, что подобной большой экономии можно достичь, к сожалению, только в американских регионах Amazon — в европе Spot Instances не такие дешевые, но тоже существенно дешевле обычных ($0.17 вместо $0.08 данном примере).

И важно понимать, конечно, ограничение Spot Instances — их цена колеблется и может подняться даже выше розничной почасовой (сюда по нашим наблюдениям крайне редко) — в этом случае кластер Spot Instances начинает гасить машины (понятно, mysql нельзя держать на машинках, а апачи — пожалуйста). Ваше веб-приложение должно суметь обработать этот кейс и автоматически расширить кластер обычных машин. Мы решили эту задачу соединив тест CPU usage в CloudWatch с автомасштабируемыми группами — работает из коробки без головной боли.

Итоги

Это далеко не все способы «профессионально сэкономить» в AmazonWebServices. В следующих статьях расскажу о других, не менее эффективных способах — например копировании бакета s3 в бакет s3 не сжигая трафик и др.

В статье я постарался объективно обосновать плюсы и минусы, риски использования американских регионов Amazon для российский веб-проектов, и на примере показал, что заложив масштабируемую кластерную архитектуру веб-решения — можно сэкономить в разы на аренде мощностей виртуалок.
Желаю всем удачи, побольше хороших идей и эффективных архитектурных решений и приглашаю всех 4 апреля на конференцию, посвященную отказоустойчивости веб-приложений как в обычных хостингах, так и облаках!