Выбор вычислительной платформы AWS для вашей рабочей нагрузки с точки зрения стоимости — непростая задача. Я сделал расчет для одного из проектов, над которым работаю, и решил поделиться своими выводами. В этой статье я проведу очень высокоуровневое и упрощенное сравнение, чтобы наметить способ сравнения.

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

Настройка конфигурации

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

Для простоты давайте сравним услуги с требованиями только для наличия 1 виртуального ЦП и около 2 ГБ памяти. Для Lambda виртуальный ЦП масштабируется вместе с настраиваемым объемом памяти. Lambda получает 1 виртуальный ЦП на 1,769 ГБ памяти , так что это будет наш выбор для Lambda. В Fargate можно настроить как количество виртуальных ЦП, так и объем памяти, поэтому мы можем выбрать ровно 1 виртуальный ЦП и 2 ГБ памяти, которые будут доступны. Для EC2 с таким низким значением виртуальных ЦП и памяти в текущем поколении типов инстансов EC2 наш единственный вариант — использовать семейство T, которое обеспечивает взрывную производительность.. Это создает еще один уровень сложности, поскольку стоимость экземпляра определяется исходя из использования ниже или равного базовой производительности ЦП, а дополнительные расходы возникают, когда потребление превышает базовый уровень. Однако в типах инстансов предыдущего поколения тип инстанса m1.small довольно хорошо соответствует требованиям с 1 виртуальным ЦП и 1,7 ГБ памяти, поэтому мы будем использовать его, а не тип инстанса семейства T. Кроме того, для простоты сравнения не рассматривались следующие варианты:

• Процессоры с архитектурой ARM
• Не-Linux ОС
• Выявляйте экземпляры и выявляйте задачи Fargate
• Передача и хранение данных
• Зарезервированные инстансы и планы экономии ресурсов

Интуитивно EC2 должен быть самым дешевым сервисом, за ним следуют Fargate и Lambda. Причина в том, что каждый следующий сервис требует меньше администрирования инфраструктуры, чем предыдущий, поэтому задачи по управлению инфраструктурой передаются AWS. На следующем графике показана месячная стоимость каждой услуги в зависимости от процента использования времени.

Цены на EC2 действительно самые низкие, за ними следует Fargate, в то время как цены на Lambda примерно в два раза выше, чем у Fargate. Цены на EC2 можно еще больше снизить за счет использования расширяемого типа инстанса семейства T, в зависимости от фактических потребностей вашей рабочей нагрузки.

Факторы выставления счетов и запуска

Как мы видели выше, стоимость запуска Lambda довольно высока по сравнению с Fargate и EC2. Давайте теперь рассмотрим факторы, которые могут повлиять на то, почему мы все еще можем выбирать Lambda для вычислений, несмотря на ее более высокую цену.

Первое, что нужно учитывать, это расчетный интервал услуг. EC2 оплачивается посекундно, с минимальной продолжительностью 60 секунд. Выставление счетов начинается при запуске экземпляра и прекращается, когда экземпляр завершается или останавливается. Fargate оплачивается посекундно, а также при минимальной продолжительности 60 секунд. Выставление счетов начинается, когда изображение извлекается, и останавливается, когда задача завершается. Lambda, с другой стороны, оплачивается за миллисекунду без минимального порога. Выставление счетов начинается, когда запускается ваш код инициализации или обработчика, и прекращается, когда ваш код возвращается или иным образом завершается.

Это одна из причин, по которой Lambda — хороший выбор для рабочих нагрузок, которые выполняются нечасто и недолговечны.

Во-вторых, запуск нового инстанса EC2 занимает около минуты или больше, аналогично запуску новой задачи Fargate. Для сравнения, создание нового экземпляра Lambda обычно занимает несколько сотен миллисекунд для сред выполнения с интерпретируемыми языками и до нескольких секунд для сред выполнения с скомпилированными языками.

В зависимости от вашей рабочей нагрузки может случиться так, что вы не можете ждать ни минуты, чтобы запустить инстанс EC2 или задачу Fargate, и поэтому вам необходимо поддерживать работу инстанса или задачи. Это не относится к Lambda, так как вы обычно ждете несколько секунд, чтобы запустить новый экземпляр. Вы также можете держать экземпляр Lambda в тепле по небольшой цене, отправляя ему эхо-запрос каждые несколько минут по событию CloudWatch.

Чтобы подчеркнуть два фактора, описанных выше, теперь мы можем сравнить выставление счетов за услуги для вычислений типа обработчика веб-API, где мы хотим не иметь задержки запуска и быть готовыми обслуживать трафик в любое время.

И инстанс EC2, и задача Fargate должны использоваться 100 % времени, чтобы не возникало проблем с запуском. С другой стороны, биллинг Lambda зависит от фактического времени, когда ваш код обработчика работает для обслуживания трафика веб-API. Таким образом, использование Lambda предпочтительнее до тех пор, пока Lambda не будет использоваться от 40 до 50 % времени, несмотря на более высокую цену за ту же вычислительную мощность. Это делает Lambda подходящим для задач быстрой обработки, например задач ввода-вывода, таких как чтение данных из DynamoDB и т. д.

Пример реального мира

Мы используем функцию Lambda в одном из наших проектов для обработки запросов API. Он имеет конфигурацию памяти 2 ГБ в основном для минимизации задержек при холодном запуске, в противном случае он мог бы иметь более низкую конфигурацию. Он использует библиотеку .NET, размер которой превышает 4 МБ, поэтому различия при холодном запуске между, например, 512 МБ памяти и 2 ГБ заметны.

В последние месяцы трафик на Lambda неуклонно рос, и мы хотим выяснить, не пора ли подумать о переходе на другой сервис.

Согласно ежедневным показателям использования, функция вызывается в среднем около 250 тысяч раз в день, что составляет 2,89 запроса в секунду. Средняя продолжительность выполнения составляет где-то около 250 мс. 2,89 умножить на 250 — это примерно 723. Это означает, что функция используется примерно в 70 % случаев.

Более детализированные метрики минутного интервала показывают, что шаблоны вызовов являются резкими, однако в целом нагрузка обрабатывается немногим менее чем 10 одновременными экземплярами функции.

Собранные метрики сигнализируют о том, что мы преодолели порог, при котором выставление счетов Lambda было оптимальным. Потенциально, чтобы обрабатывать трафик с той же вычислительной мощностью и иметь возможности для роста, мы могли бы использовать, например, 2 задачи Fargate в нескольких зонах доступности, каждая из которых имеет 0,5 виртуальных ЦП и 1 ГБ памяти. Судя по приведенным выше графикам, это сократит ежемесячные расходы на выставление счетов с 53,50 до 36,04 долларов США. Мы могли бы попытаться еще больше снизить затраты, используя расширяемые инстансы EC2 нужного размера и размещая там контейнер или приложение. Это, конечно, только грубая теоретическая идея, которая требует проверки на реальном приложении.

В заключение я хотел бы упомянуть, что исходные затраты на выставление счетов должны быть увеличены с учетом сложности и затрат на управление инфраструктурой. Для конкретных сценариев это может означать, что, хотя, например, стоимость выставления счетов EC2 может быть на несколько процентов ниже, чем у Fargate или Lambda, разница все же не компенсирует дополнительную сложность решения.

Мы — компания ACTUM Digital , и эта статья была написана Миланом Гатиасом , техническим руководителем .NET подразделения Apollo. Свяжитесь с нами.