company_banner

Посекундный биллинг, маркетплейс и песочницы для Big Data: что могут тестовые среды в облаке


    Любой компании, разрабатывающей софт, нужны тестовые среды, приближенные к продакшн-окружению. Особенно это актуально для коробочного ПО, у которого длинный цикл релизов.
    Многие проблемы построения тестовых сред решает их размещение в облаке. Мы расскажем про возможности тестирования на нашей облачной платформе Mail.Ru Cloud Solutions (MCS). Но часть из того, что мы расскажем, верна для любого облака.

    Сложности настройки тестового окружения


    Прежде чем говорить о возможностях тестовых сред в облаке, расскажем о сложностях, с которыми сталкиваются компании в процессе тестирования ПО.

    Разные Git-ветки — разные среды


    Большинство компаний, занятых в сфере разработки ПО, используют системы контроля версий. Наиболее распространенной из них является Git, который используют 87% разработчиков (опрос RhodeCode в Twitter).

    Best practice в Git являются так называемые feature-branches (ветви), когда для каждой новой функциональности выделяется отдельная ветвь в репозитории. Такой подход позволяет разработчикам не «толкаться локтями» и делает внесение изменений более независимым, однако требует развертывания множества выделенных сред для тестирования отдельных фич.

    Недоиспользование вычислительных ресурсов


    25% физических серверов — это «зомби», которые потребляют электроэнергию, но не делают ничего полезного. А многие IT-специалисты не могут сказать, чем заняты 15–30% установленных в их компании серверов.

    Так вот. On-premise железо под тестовые среды тут ничем не отличается от любого другого и, как правило, плохо утилизировано. И по-другому быть не может. Когда вы покупаете парк серверного оборудования, вы перезакладываетесь по ресурсам на случай роста потребления и количества тестовых сред. В итоге тестовые среды простаивают в ночное время и в выходные «на всякий случай», а вы просто платите за потребляемое электричество и охлаждение.
    Простое применение виртуализации в вашем частном облаке никак не решает проблему негибкой масштабируемости и недоиспользования оборудования.

    Сложность настройки


    Тестовая среда и среда для разработки — это не просто несколько виртуальных машин. Обычно в неё входят сервер приложений, сервер баз данных, плюс серверы очередей сообщений и серверы кеширования.

    Разработчикам сложно поднимать и настраивать такую инфраструктуру самостоятельно, если у них нет соответствующей экспертизы, на это может уйти несколько дней. Опытным админам это легко, но вообще неинтересно. Плюс накладывается бюрократия, и процесс выделения ресурсов на создание тестовой среды может сильно затянуться.

    Ещё одна проблема — в том, что у штатного системного администратора часто нет экспертизы в развертывании специфических тестовых сред, и компания вынуждена привлекать дорогостоящих консультантов извне. Пример — песочница для больших данных на базе Hadoop, Spark, HDFS или Airflow. Развертывание подобного окружения занимает минимум неделю у квалифицированного в области BigData специалиста и не меньше месяца у обыкновенного системного администратора. Аналогичная история и с кластерами Kubernetes: построение тестового кластера, приближенного к продакшн-конфигурации, занимает минимум несколько дней.

    В итоге компания вынуждена обращаться к третьей стороне — привлекать консультантов. Однако найти специалистов по большим данным достаточно сложно, а администраторов таких систем можно пересчитать чуть ли не по пальцам. Да, со всеми задачами по развертыванию тестовых сред может справится DevOps-инженер, но он тоже есть не в каждой компании, а найти хорошего эксперта в этой области ничуть не проще, чем специалиста по BigData. В 2016 году сайт по поиску работы indeed.com отметил, что компании ищут DevOps-инженера дольше любых других специалистов.

    Как облако решает эти проблемы


    Посекундный биллинг только за потребленные ресурсы и мгновенное масштабирование


    Наиболее очевидный плюс облачных сервисов — возможность арендовать облачную инфраструктуру любой конфигурации (один сервер или целый кластер) на любой срок. На нашей платформе Mail.Ru Cloud Solutions (MCS) биллинг посекундный — платить нужно только за те вычислительные ресурсы, которые реально использовались.

    В отличие от bare metal, private cloud и большинства российских облачных провайдеров, MCS не тарифицирует ресурсы остановленных виртуальных машин (RAM, CPU): оплачивать нужно лишь занятое дисковое пространство. Например, тестовая конфигурация 20 CPU, 40 ГБ RAM и 1 ТБ HDD стоит 24 800 ₽/мес, а оплата дискового места — 7 000 ₽/мес. Например, если средствами автоматизации останавливать такую среду в 21:00 и развёртывать в 9:00, вы будете платить 15 900 ₽ — в полтора раза меньше, чем при круглосуточной аренде.

    По нашему опыту итоговая экономия от тестирования в облаке может достигать 60–70%, по сравнению с тестированием в инфраструктуре on-premise.

    Возможность мгновенного масштабирования ресурсов в облаке в большую и меньшую сторону позволяет быстро развёртывать среды только на нужное время и утилизировать арендованные мощности практически на 100%. Время развертывания тестовой среды сокращается на несколько дней, а то и месяцев, по сравнению с on-premise.

    Ресурсы выделяют сами разработчики


    С помощью порталов самообслуживания настраивать тестовые среды в облаке и выделять для них ресурсы могут сами разработчики, не обращаясь к администраторам. Даже это простое действие может сократить time-to-market продукта на несколько недель.

    API для автоматического создания и уничтожения тестовых сред


    Облако позволяет создавать короткоживущие окружения по модели «точно в срок». С помощью REST API и CLI можно массово развертывать тестовые среды, останавливать, обновлять и удалять их. Таким образом, можно настроить полный жизненный цикл для тестовых сред и поддерживать в работоспособном состоянии сотни сред. Благодаря мгновенному масштабированию облака и посекундному биллингу достигается гибкость и сокращение расходов на эксплуатацию.

    Вот пример из нашего опыта
    Компания разрабатывает софт для 150 банков. Для каждого банка есть своя ветка в Git с дополнительными функциями, надстроенными над коробочным решением. Компания вынуждена поднимать две–три параллельно работающие тестовые среды для каждого клиента: тестирование с текущей версией, тестирование с новой версией, проверка обновления с текущей на новую. Итого для 150 клиентов приходится развертывать и поддерживать в работоспособном состоянии одновременно до 450 только тестовых сред — это без учёта сред разработки.

    В режиме частного облака (они используют виртуализацию в собственном ЦОД) работать с такой нагрузкой практически невозможно, так как доступного «железа» часто не хватает для параллельной работы всех сред. В итоге разработчики ждут своей очереди на тестирование и не могут быстро проверить работу новой версии приложения.

    Автоматизированное развёртывание и управление тестовыми средами в публичном облаке снимает ограничение в скорости тестирования и в итоге сокращает time to market. Кроме того, управление расходами при аренде облачных ресурсов более предсказуемо, а сами расходы ниже, чем при использовании собственного специализированного оборудования для тестовых стендов.

    Еще одно преимущество облачных тестовых сред — интеграция с CI/CD-инструментами. Эти решения (например, Jenkins) содержат плагины, которые позволяют динамически создавать тестовые окружения в облаке MCS во время билда. Тестовую среду можно активировать прямо перед запуском функциональных или регрессионных тестов. Если тесты прошли успешно, среда свернётся автоматически, если что-то не так — среда сохранится, чтобы разработчики могли переподключиться и понять причину регрессии.

    Готовые строительные блоки для тестовых окружений


    Быстро развернуть тестовое окружение платформе Mail.Ru Cloud Solutions
    помогают PaaS, например — контейнеры Kubernetes и Базы данных в облаке. На базе Kubernetes развивается сервисный каталог с сотнями приложений.

    Из каталога можно развернуть за несколько минут кластеры ActiveMQ, RabbitMQ, Kafka, системы мониторинга и анализа логов, различные CMS и базы данных. В отличие от популярного Docker Hub, который содержит только индивидуальные шаблоны приложений, в Kubernetes Service Catalog есть высокоуровневые шаблоны, упрощающие интеграцию. Из шаблонов можно развёртывать преднастроенные компоненты приложений (message queue, service discovery, базы данных, серверы приложений, CI/CD инструменты, кеширующие серверы, инструменты блокчейн и многое другое), без необходимости настраивать виртуальные машины, на которых они развёрнуты.


    Приложения, доступные в Kubeapps marketplace.

    Песочницы для Big Data


    На MCS можно разворачивать тестовые среды для приложений, работающих с большими данными. С помощью PaaS-сервиса Большие Данные можно создавать кластеры Hadoop, Spark, HBase и Airflow. Процесс развёртывания полностью автоматизирован, и это экономит недели времени по сравнению с самостоятельной настройкой.

    Дополнительное преимущество здесь дает посекундный биллинг и мгновенное масштабирование. Возможность создавать расширяемые тестовые среды на короткие периоды сокращает расходы компании на поддержание аналитической IT-инфраструктуры. Экономия может достигать 80% по сравнению с on-premise.

    Интеграция с Infrastructure-as-a-Code


    В отличие от проприетарных решений на базе VMWare, облачная платформа MCS построена на базе открытого ПО OpenStack, которое имеет полноценную интеграцию с различными инструментами: Terraform, Ansible, Puppet, Chef.

    Terraform построен в духе Infrastructure-as-Code (IaC), когда процесс настройки инфраструктуры устроен как написание кода и более привычен разработчикам. Terraform сложно использовать в частном облаке, поскольку у него отсутствует полноценная интеграция с VMware. В облаке MCS компании могут использовать готовые примеры работы с Terraform (лежат в этом GitHub-репозитории).


    Создание тестовой среды с помощью Terraform.

    Запомнить


    • Тестирование в облаке становится естественной практикой в IT-индустрии и уже применятся самыми разными организациями: от государственных университетов до крупных IT-компаний.
    • Построение тестовых сред в облаке помогает сэкономить за счёт возможности мгновенного масштабирования и автоматизации через API, которые дают практически 100% утилизацию арендованной инфраструктуры.
    • Дополнительные сервисы на облачной платформе и шаблоны на контейнерах Kuberntetes — готовые строительные блоки, которые не нужно настраивать.
    • Сложные в настройке сервисы, такие как инструменты обработки Big Data, проще арендовать в облаке в виде преднастроенных шаблонов. Вы сэкономите недели, избежав погружения в настройки.
    • MCS построена на OpenStack и полноценно интегрирована с Terraform и другими инструментами DevOps.

    Все эти инструменты можно бесплатно попробовать в платформе Mail.Ru Cloud Solutions. До конца ноября по этой ссылке с промокодом ILOVEHABR можно добавить 1000 рублей на счёт и тестировать-тестировать-тестировать.
    • +28
    • 2,7k
    • 9

    Mail.Ru Group

    1010,00

    Строим Интернет

    Поделиться публикацией

    Похожие публикации

    Комментарии 9
      0

      Вы очень сильно передергиваете в сторону собственного сервиса.


      Большинство провайдеров на базе VMware в России поддерживают как минимум почасовую тарификации, часто поминутную. Посекундно в большинстве кейсов просто не нужно.


      Terraform прекрасно поддерживает vCloud Director, vSphere, NSX-T как Major Cloud Providers. Как раз OpenStack не относится к Major.


      В плане стабильности VMware из коробки даст жару большинству поделок на OpenStack.


      Product Manager должен разбираться в рынке и в технологиях. Постеснялись бы на техническое ресурсе огульно заявлять вещи, отдалённые от реальности.

        +1
        Посекундный биллинг важен, если вы имеете дело с большим количеством ресурсов, например, HPC-кластер. Но основное преимущество нашего биллинга это тарификация за реально потребленные ресурсы, а не арендованные. Т.е. здесь все тот же пример с остановленной виртуальной машиной.

        На тему Terraform: это больше отзыв многих наших клиентов о том, что они намучались готовить Terraform c vCenter.

        Я крайне не согласен с тем, что облако на VMware — априори более стабильно, чем на OpenStack. Все определяется экспертизой и командой облачного провайдера. При этом, OpenStack хорош тем, что его можно очень быстро развивать под нужны потребителей и не зависеть от большого вендора, который если и сделает требуемый функционал, то очень нескоро
          0
          Но основное преимущество нашего биллинга это тарификация за реально потребленные ресурсы, а не арендованные.

          Вот тут не знаю примеров облачных операторов, которые делали бы по другому. От фиксированных тарифов уже даже сегмент low-cost VPS / VDS отказывается.

          На тему Terraform: это больше отзыв многих наших клиентов о том, что они намучались готовить Terraform c vCenter.

          Подозреваю, что ваши клиенты привычны к OpenStack и такие же разработчики, как и сам Mail. Я знаю хорошие отзывы о Terraform от крупных компаний, которые крутят через него три платформы — vSphere, Hyper-V, KVM (именно в такой последовательности).

          При этом, OpenStack хорош тем, что его можно очень быстро развивать под нужны потребителей и не зависеть от большого вендора, который если и сделает требуемый функционал, то очень нескоро

          Опять же обобщаете личный опыт. VMware имеет богатый базовый функционал и открытые API (причем стабильный). Вам нет необходимости завязываться на какие-то высокоуровневые вещи от вендора, если не видите в этом необходимости. А пример VMware on AWS показателен.
            0
            del дубля
          0
          посчитал халуп кластер на 600 vcpu, 10 тб хдд, примерно нашего размера. вышло 10к евро в месяц. дороговато, учитывая что от админов MCS все равно не освобождает, а арендовать чисто железячки раз в 5 дешевле выйдет. вот если бы еще спецы по хадупу к облаку прилагались…
          а еще интересно, что у гугла dataproc еще в двое дороже. у меня $24k на 600 vcpu dataproc получилось.
            +1
            Смотрите, вы посчитали эту стоимость при 100% утилизации, что для Hadoop не всегда релевантно. В Mail.Ru Cloud Solutions вы можете либо остановить кластер целиком (и заплатить за жесткий диск), либо же сжать его до минимального размера, если не постоянно требуется держать все мощности активными. Кроме того, для длительного контракта возможны большие скидки — аналог «committed use discount» в Амазоне. Ну и напоследок: у нас очень много спецов по Hadoop, которые помогут как минимум на этапе разворачивания и конфигурирования кластера
              0
              я смотрю с точки зрения корпоративного, мне кажется у корпорации разве что ресурсы uat/dev среды реально как-то не на 100% использовать. у нас на проде почти всегда 100%, лишь очередь заданий меняется во времени. ваши спецы на администрирование затраты мне кажется вы не сильно снизят, вокруг хадупа тучи систем от ldap и kerberos, до кафки, сборов логов и прочего dev хозяйства. по любому нужны админы.
              имхо вы можете кардинально ускорить разработки, через это может можно выгоду получать. я вижу что мы многое могли бы попробовать, но попробовать негде. если бы мы могли создать тестовый кластер размером с прод на пару часов, убедиться, что идея сработает это заметно бы ускорило многие наши процессы.

                +1
                Напишите мне в личку или в Telegram @lazarenkod. Мы организуем для вас тестовую среду с достаточным количеством ресурсов.
                  +1
                  я пишу с европы, gdpr. клауд в РФ пока мне грозит. может если когда нибудь сменю проект…

          Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

          Самое читаемое