Базовые вычислительные сервисы в облаках
Автор статьи: Роман ШныревCloud & AI architect.
Привет, Хабр!
Сегодня поговорим о «базовых» вычислительных сервисах доступных у публичных облачных провайдеров (далее CSP). Статья ориентирована на начинающую свой путь в облака аудиторию. И так наши основные цели:
Познакомиться с основными вычислительными ресурсами/сервисами.
Понять различия между предлагаемыми способами оплаты вычислительных ресурсов .
В целом все решения строятся на 3-х основных столпах/доменах инфраструктуры:
Compute — вычислительные ресурсы.
Storage — ресурсы для хранения данных.
Network — сетевые ресурсы.
Про ресурсы, относящиеся к первому столпу, мы сегодня поговорим на примере облака AWS. Почему AWS, а не другое облако? AWS является визионером и лидером по аналитике Gartner, 11 лет занимает первое место в рейтинге Gartner Magic Quadrant for Cloud Infrastructure & Platform Services (CIPS). Знания, описанные ниже так же применимы и к другим облачным платформам, так как все они предлагают, по сути, один и тот же набор сервисов под разными шильдиками облака.
И так прежде, чем начать говорить про то какие ресурсу относятся к категории вычислительных ресурсов необходимо определиться с терминологией что такое регионы и зоны доступности.
Регион (Region) — физическое местоположение, где находятся центры обработки данных. Каждый регион AWS состоит из минимум трех изолированных и физически разделенных зон доступности в одной географической области.
Зона доступности (Availability zone) — несколько центров обработки данных с резервными источниками питания, объединенные высокоскоростной сетью. Все зоны доступности в регионе AWS объединены в полностью резервированную выделенную сеть из метроволокна с высокой пропускной способностью и низким уровнем задержек.
Локальная зона (local zone) — аналог зон доступности, но центры обработки данных расположены в местах с большой численностью населения и рядом с крупными промышленными центрами. Новый подход, который позволяет обслуживать потребности больших населенных пунктов с минимальными задержками.
Итак к категории compute относятся следующие базовые сервисы:
AWS EC2 (elastic compute cloud) — сервис для предоставления виртуальных машин (IaaS).
AWS EKS (elastic Kubernetes service) — сервис для предоставления управляемых инсталляций Kubernetes от AWS (PaaS).
AWS Lambda — сервис реализующий бессерверный (serverless) подход к вычислениям (FaaS — function as a services).
В настоящее время одним из основных кубиков для построения облачного решения является виртуальная машина (далее ВМ), основные характеристики доступные пользователям и заказчикам зависят от предполагаемого профиля нагрузки на ВМ. Как правило это:
Тип процессора
Размер оперативной памяти
Тип дисковой подсистемы и ее производительность
Пропускная способность сетевых интерфейсов
В облаке AWS присутствует достаточно большое количество различных профилей виртуальных машин или инстансев как их принято называть для удовлетворения потребностей любого заказчика. Они сгрупированы по группам:
Общего назначения (general purpose) — все показатели усреднены.
Оптимизированные под вычисления (compute optimized) — используются более производительные процессоры для задач с высокой долей расчетов.
Оптимизированные по оперативной памяти (Memory optimized) — ВМ с большим объемом оперативной памяти для приложений, оперирующих большим количеством данных в памяти.
С дополнительной аппаратной акселерацией (Accelerated optimized) — используются графические ускорители (GPU) или ASIC для обработки вычислений.
Оптимизированные для хранения (Storage optimized).
Соответственно благодаря широкому покрытию земного шара своими дата центрами AWS позволяет Вам развернуть инстансу в любом регионе, всего их на момент написания статья 31 и 99 зон доступности в составе регионов. Ориентируясь на основную целевую аудиторию Вашего облачного решения следует выбирать географическое место размещения виртуальных машин. Отказоустойчивость ВМ в рамках региона достигается за счет:
Placement group — стратегия размещения инстансов на кластерах виртуализации и стойках внутри ЦОД-ов зоны доступности.
Распределения ВМ по разным зонам доступности внутри региона, например такая схема отлично работает с фронтами/веб серверами.
Использованию Auto scaling groups — опция автоматического масштабирования инстансов при всплесках нагрузки таких как Black Friday когда к Вам на распродажи и праздники приходит огромное количество клиентов. При срабатывании заданного триггера, например на достижение утилизации процессора 90% разворачивается необходимое количество инстансов из шаблона, и обратный кейс, когда при спаде нагрузки количество инстансов уменьшается. Таким образом мы можем гибко управлять инфраструктурой в автоматическом режиме при всплесках нагрузки, так же данный подход помогает и бороться с DDOS атаками сдерживая напор паразитного трафика, конечно такое сдерживание отразится на конечном счете за новые инстансы.
Amazon EKS также использует ВМ с конфигурациями выше для worker узлов кластера Kubernetes и использует все механизмы и опции описанные выше для инстансов EC2 что позволяет использовать преимущества инфраструктуры AWS Amazon EKS автоматически управляет доступностью и масштабируемостью узлов Kubernetes, отвечающих за планирование контейнеров, управление доступностью приложений, хранение данных кластера и выполнение других важных задач, в облаке. Доступна также опция развертывания кластеров на площадках заказчиков в их локальной среде предоставляя стабильное и полностью поддерживаемое решение для Kubernetes со встроенным инструментарием и простым развертыванием в AWS Outposts (серверы с предустановленным ПО для инсталляции на площадках заказчика — в on-premise), виртуальных машинах.
Следующий сервис AWS Lambda — (бессерверные вычисления) — event driven подход при котором облако автоматически и динамически управляет выделением вычислительных ресурсов в зависимости от пользовательской нагрузки. Наши решения генерируют множество различных событий каждой из которых мы можем обрабатывать, в этом и заключается суть работы данного подхода — мы берем небольшие функции (подход function as a service)/микросервисы и вешаем их на события. Например, представьте у нас есть S3 объектное хранилище и мы предполагаем, что туда будут загружаться картинки от пользователей — мы можем сразу замаппить функцию по обработке изображений и их ресайзингу на событие по создание объекта на S3.
Пример такой реализации с сайта AWS:
Биллинг serverless осуществляется за количество вызовов функций и время их выполнения.
В общем виде подход/архитектура выглядит следующим образом:
Современные микро-сервисные приложение можно вполне перенести в парадигму FaaS, но стоит обратить внимание, что если в примере выше мы положим результирующую картинку после ресайзинга в тот же S3 бакет возникнет рекурсия, т.к. мы обрабатываем события создания новых объектов на хранилище. Поэтому нужно быть аккуратными и что называется «положить свои мысли на бумагу» описав информационные потоки в рамках Вашего микро сервисного приложение в парадигме FaaS.
Под капотом функции это микро виртуальные машины, которые исполняются в окружение AWS, существует решение Local stack которое позволяет провести эксперименты/разработку на вашем локальном ПК перед тем как перенести в облако. Это позволяет существенно сэкономить при разработке.
Мы уже затронули биллинг serverless теперь рассмотрим опции для инстансов, AWS предлагает следующие опции:
On-demand — модель pay as you go почасовая оплата за используемые ресурсы.
Reserved instances — долгосрочная аренда от 1–3 лет с существенной скидкой до 75% по сравнению с On-demand. Обеспечивает скидку на почасовую оплату и возможность резервирования мощностей для инстансов EC2 на долгосрочной основе. Подходит, когда нагрузка на ресурсы стабильная и предсказуемая.
Spot — негарантированные ресурсы, выгоднее до ~90% по сравнению с on-demand. Перепродаваемый ресурсы внутри CSP, любое облако является биржей мощностей и когда клиент арендует ресурсы, например по тарифу reserved возникают моменты, когда он не использует полностью необходимый ему объем и тогда облачный провайдер перепродает ресурсы другим участникам рынка, но перепродает как негарантированный ресурс. Например, клиент 1 оплатил гарантированный пул ресурсов, но не использует его весь, CSP перепродает часть ресурсов под spot инстанс клиента 2 и он успешно запускает свои нагрузки. Когда клиенту 1 понадобятся его ресурсы, клиент 2 получит уведомление что инстанс будет выключен и ресурсы заберут. Существует опция делать постоянные запросы на spot ресурсы чтобы приложения работали без «простоев». Подходит для не критичных фоновых задач, ошибка/прерывание работы которых не влияет на работу остальной части облачного решения. Применяется даже для ML нагрузок.
Dedicated — выделенные физические ресурсы Ваши нагрузки, иными словами выделенные инстансы физически изолированы на уровне аппаратного обеспечения хоста от инстансов, принадлежащих другим аккаунтам AWS. Наиболее дорогая и надежная опция. Можно арендовать по запросу (on-demand) или резервировать (reserved). Подходит, когда требуется физическая независимость ресурсов от других клиентов облачного провайдера.
Попробовать рассчитать стоимость инфраструктуры со всеми опциями можно в калькуляторе https://calculator.aws/#/
Обращаю внимание, что стоимость одних и тех же ресурсов меняется в зависимости от используемого региона, это обусловлено микро и макро экономическими факторами в разных странах, например, электричество стоит разных денег.
Это все что мы хотели рассказать в текущей статье, в следующих статьях расскажем про остальные сервисы. Если у Вас есть пожелания к контенту и особенно по практическим кейсам для описания в нашем блоге — пишите в комментариях.
Приходите на наши открытые вебинары, где мы на практике рассмотрим описанные сервисы и на курс «Cloud Solution Architecture» в OTUS, где Вы сможете:
Познакомиться на практике с основными элементами и сервисами, представленными облачными провайдерами на примере ведущих облаков AWS, Yandex и т.д.;
Изучить лучшие практики и основные шаблоны проектирования облачных решений на примере AWS Well architected framework;
Понять фундаментальными принципы, которым должно соответствовать облачное решение.
Познакомиться с подробной методологией миграции уже существующих решений в облако, учитывающую как трансформацию технологических процессов, так и изменение в мышлении сотрудников организации в сторону облачного подхода.
