Как сэкономить деньги в 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 апреля на конференцию, посвященную отказоустойчивости веб-приложений как в обычных хостингах, так и облаках!

    Comments 19

      +2
      Хороший пост.

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

      Насколько я знаю, никто из российской топовой тройки CMS так пока не делает. А у вас как?
        +2
        Спасибо. Так будет еще быстрее — отдавать все что можно как статику через CDN, а динамику дергать параллельно используя nginx как сборщик кусков от серверов приложений за ним (обратный прокси) с SSI.
          +1
          Не думаю, что предложенный вами способ генерации страниц в обозримом будущем будет массово использоваться, все-таки традиционная схема — сгенерированный каркас и контент плюс статика в CDN лучше подходит для большинства сколь-либо сложных веб-проектов.

          Хотя как нишевое решение для кого-то, конечно, подойдет.
            0
            Думаю обращений к сайтам, особенно с мобильных устройств станет все больше и разработчики будут вынуждены заюзать по максимуму ресурсы облаков, CDN — иначе не справятся с нагрузкой.
              +1
              Безусловно, CDN — очень полезна, но все же классическое взаимодействие с ней (для отдачи статики в динамически сгенерированный шаблон) выглядит более очевидным, и имеет понятные плюсы.
                0
                С CDN нет так страшно машины держать в США, где все новое появляется быстрее и впервые :-) Пускай там PHP работает, чисто бизнес-логика — а весь контент как по трубам отдается с ближайших серверов CDN к клиенту. Я тестил ради любопытства скорость загрузки ресурсов на серверах в Бразилили из США через CDN — скорость песня, латенси несколько ms :-)
                  +1
                  Я с вами полностью согласен.

                  У меня есть весьма в итоге успешный опыт перевода highload проекта 24/7 на CDN от этих известных ребят — level3.com.
                  Я лишь хочу сказать, что схема предложенная dgstudio, которую вы поддержали, вряд ли получит массовое распространение.

                  А вот традиционный вариант со статикой на CDN, как я уже говорил, очень хорош, при этом месторасположение серверов приложений действительно в такой конфигурации не играет решающей роли.
                    0
                    level3 это крутые ребята :-) Мы столкнулись с тем, что CDN Амазона не имеет точек раздачи в России. Для отечественных проектов решили раздавать через CDNVideo. Еще хвалят Ngenix. Интересно, когда гиганты выйдут на наш рынок и откроют точки раздачи трафика в России, те же level3 ;-)
                      0
                      Ну то, что их нет в России, не так уж и страшно. В моем случае это была онлайн-игра, где статика обновлялась раз в неделю, да и то небольшая ее часть. Поэтому основной задачей CDN было быстро отдать новые файлы пользователям.

                      Кстати, для сайтов можно реализовать механизм, запускающийся после полной загрузки запрошенной страницы, загружающий статику, которая не используется на данной странице, но может пригодиться впоследствии, чтобы браузер спокойно, пока пользователь изучает уже загруженный контент, клал ее в кэш. Отображать, конечно, ее не нужно.
            +1
            Мы часто делаем приложения, которые имеют возможности кэширования страниц целиком (например, это может указываться в конкретном Action контроллера). Далее NGINX раздаёт такие страницы статически для пользователей, не вошедших в систему. Метод подсмотрен в плагине W3TC для Wordpress.

            Также кэшируются на диске и/или в памяти кусочки страниц, из которых легко и быстро собрать страницу.
              0
              А теперь начните раздавать этот закэшированных контент через CDN — нгинкс будет загружен значительно меньше, клиенты начнут закачивать статику с латенси в 2-7 мс, а не 50-150 как часто бывает. Рулить устареванием файлов в CDN — через «file?123453». На форумах веб-сервисов Амазона часто встретишь как уже сами клиенты требуют чтобы разработчики убирали максимум статики и файлов в облако и CDN.
              0
              Знать бы хоть одну CMS, которая бы из коробки готова была к такому разделению. Просто потому, что CMS — понятие массового рынка, и рассчитываются на «массовые» хостинги. А там CDN, SSI, множества бекэндов, балансировщиков и прочего не то чтобы нет — даже если и есть, массовый покупатель этого не использует, ибо не понимает и боится. А так — купил аккаунт на LAMP-сервере, установил Wordpress, обвешал плагинами — работает себе. Только такой «чересчур динамический» сайт нормально «разбить» под технологичный хостинг — проще повеситься…

              Т.е. здесь речь надо вести о AWS-заточенной CMS, а это все же товар уникальный, поскольку этот хостинг выбирают уже те, кто понимает, что хочет, и требования такого заказчика устроит не CMS, а сайт на основе CMF.

              Пока же массовые CMS имеют модули для работы с CloudFlare (честно сказать, который «и так», без модулей, работает), где хоть что-то делается «как бы автоматом». Как бы, поскольку такой кеш подходит не всем, но многим тексто-ориентированным сайтам подходит вполне.
                0
                Наш продукт поддерживает несколько облачных технологий «из коробки». Мы хорошо понимаем что это так востребовано и идем навстречу:

                1) CDN — не меняя код вы включаете замену ссылок на ресурсы и клиенты начинают загружать картинки, стили и скрипты с ближйший серверов CDN. Я думаю это как раз то, что будет востребовано большинством типовых проектов — сайт становится рядом с клиентом :-)

                2) Облачные хранилища файлов — вы можете переместить свои файлы через админку в облако: s3, google и другие. Удобно если файлов у вас много, они тяжелые. А раздавать их конечно нужно… через CDN.

                3) Облачный бэкап — можно переносить свои бэкапы в облако, они шифруются.

                4) Поддержка технологий кластеризции — (мастер-мастер репликация, мастер-слейв и др.) можно развернуться практически из коробоки как кластер в облаке, многие наши партнеры запускают решения в Амазоне, других, отечественных облаках.

                  0
                  Темы кеша вообще и кеша в битриксе в частности — поле благодатное )

                  Хорошо, что вы есть. Плохо, что даже партнеры, делая сайты, не всегда думают о производительности (девиз — «а вы возьмите сервер помощнее»), а потом страницы с 300 запросами в БД при любом кешировании отнюдь не «мгновенны» оказываются.

                  Все руки не дойдут ваше новое ядро пощупать, так что ничего не скажу.

                  Anybody else? )
              0
              Немного не в тему экономии, но — как вы обновляете билды приложения на машинках, которые разворачиваются из AMI? Обновляете образ или с помощью какой-то стартовой автоконфигурации?

              Скоро предстоит подобную штуку делать, и мы пока не понимаем, что будет лучше. (Если что, у нас Windows+IIS).
                +1
                Спасибо за интересный вопрос. :-) Как мы обновляем кластер, например, на Битрикс24:

                — Имеется скрипт на «великом своей могучестью» языке bash.
                — Имеется эталонная EC2 машинка, на которую выгружается стабильная версия релиза.
                — Скрипт через АПИ Амазона снимает снепшот с эталона — который сохраняется в виде образа виртуалки — AMI. Если рейд — нужно весь рейд фризить, например с fsfreeze на момент создания AMI.
                — Скрипт создает LaunchConfiguration, в которой проставляет ссылку на новое AMI.
                — Затем обновляет свойство AutoScaling группы — указывая новый LaunchConfig.
                — Переключаем оригины CDN с кластера/балансера на эталонную машину. Догадайтесь зачем :-)
                — По одной машинки тушим и ждем пока на их смену запустятся с нового AMI.
                — Возвращаем оригины CDN обратно на балансировщик.
                — Процесс обновления занимает минут 40 — из-за небыстрого переключения CDN туда обратно.

                На самом деле процедура совершенно простая, прозрачная. После начала использования SpotInstances мы так обновляем 2 кластера сразу.
                  +1
                  Спасибо за подробный ответ :)
                  Чувствую, скоро и у себя такую процедуру запилим.
                0
                Правильно ли я понимаю, что для Spot Instance можно задать максимальную цену, например в $20-$50, изредка платить эту цену за час и не бояться, что однажды инстанс будет неожиданно выключен?
                  0
                  Да, платить будете текущую цену, а не максимальную — т.е. обычно значительно, в несколько раз, ниже номинала. Но — если цена машинки вырастет больше заданных $50 баксов — она будет вырублена. Но по графикам я таких цен не наблюдал :-)

                Only users with full accounts can post comments. Log in, please.