Масштабируемая эффективность: рассказ об оптимизации затрат AWS
Опубликовано: 2022-07-22Недавно я запустил платформу для анализа криптовалюты, ожидая небольшого количества ежедневных пользователей. Однако, когда некоторые популярные ютуберы сочли сайт полезным и опубликовали обзор, трафик вырос так быстро, что перегрузил сервер, и платформа (Scalper.AI) стала недоступной. Моя исходная среда AWS EC2 нуждалась в дополнительной поддержке. После рассмотрения нескольких решений я решил использовать AWS Elastic Beanstalk для масштабирования своего приложения. Все выглядело хорошо и шло гладко, но я был ошеломлен расходами на панели выставления счетов.
Это не редкость. Опрос, проведенный в 2021 году, показал, что 82 % лиц, принимающих решения в области ИТ и облачных технологий, сталкивались с ненужными расходами на облачные технологии, а 86 % считают, что они не могут получить исчерпывающую информацию обо всех своих расходах на облачные технологии. Хотя Amazon предлагает подробный обзор дополнительных расходов в своей документации, модель ценообразования сложна для растущего проекта. Чтобы упростить понимание, я разберу несколько важных оптимизаций, чтобы снизить ваши затраты на облако.
Почему я выбрал AWS
Цель Scalper.AI — собирать информацию о криптовалютных парах (активы, обмениваемые при торговле на бирже), проводить статистический анализ и предоставлять криптотрейдерам информацию о состоянии рынка. Техническая структура платформы состоит из трех частей:
- Скрипты приема данных
- Веб-сервер
- База данных
Сценарии приема собирают данные из разных источников и загружают их в базу данных. У меня был опыт работы с сервисами AWS, поэтому я решил развернуть эти скрипты, настроив инстансы EC2. EC2 предлагает множество типов инстансов и позволяет выбрать процессор, хранилище, сеть и операционную систему инстанса.
Я выбрал Elastic Beanstalk из-за оставшейся функциональности, потому что он обещал плавное управление приложениями. Балансировщик нагрузки правильно распределял нагрузку между экземплярами моего сервера, а функция автоматического масштабирования обрабатывала добавление новых экземпляров для увеличения нагрузки. Развертывание обновлений стало очень простым и заняло всего несколько минут.
Scalper.AI работал стабильно, и мои пользователи больше не сталкивались с простоями. Конечно, я ожидал увеличения расходов, так как добавил дополнительные услуги, но цифры оказались намного больше, чем я предполагал.
Как я мог сократить расходы на облако
Оглядываясь назад, можно сказать, что в моем проекте с использованием сервисов AWS было много сложностей. Мы рассмотрим оптимизацию бюджета, которую я обнаружил, работая с общими функциями AWS EC2: инстансами с высокой производительностью, передачей исходящих данных, эластичными IP-адресами, а также состояниями завершения и остановки.
Экземпляры со скачкообразной производительностью
Моей первой задачей была поддержка энергопотребления процессора для моего растущего проекта. Скрипты приема данных Scalper.AI предоставляют пользователям анализ информации в режиме реального времени; сценарии запускаются каждые несколько секунд и загружают платформу самыми последними обновлениями с криптобирж. Каждая итерация этого процесса генерирует сотни асинхронных заданий, поэтому возросший трафик сайта потребовал большей мощности ЦП для сокращения времени обработки.
Самый дешевый инстанс, предлагаемый AWS, с четырьмя виртуальными ЦП, a1.xlarge, стоил бы мне в то время около 75 долларов в месяц. Вместо этого я решил распределить нагрузку между двумя экземплярами t3.micro с двумя виртуальными ЦП и 1 ГБ ОЗУ каждый. Инстансы t3.micro предлагали достаточную скорость и память для нужной мне работы за одну пятую стоимости инстанса a1.xlarge. Тем не менее, мой счет был все еще больше, чем я ожидал в конце месяца.
Пытаясь понять, почему, я просмотрел документацию Amazon и нашел ответ: когда загрузка ЦП экземпляра падает ниже определенного базового уровня, он собирает кредиты, но когда загрузка экземпляра превышает базовый уровень, он потребляет ранее заработанные кредиты. Если доступных кредитов нет, инстанс тратит предоставленные Amazon «избыточные кредиты». Благодаря этой возможности зарабатывать и тратить кредиты Amazon EC2 усредняет загрузку ЦП инстанса в течение 24 часов. Если среднее использование превышает базовый уровень, инстанс оплачивается дополнительно по фиксированной ставке за каждый виртуальный ЦП-час.
Я следил за приемом данных в течение нескольких дней и обнаружил, что настройка моего ЦП, предназначенная для сокращения расходов, привела к противоположному результату. Большую часть времени моя средняя загрузка ЦП была выше, чем базовый уровень.
Сначала я проанализировал использование ЦП для нескольких криптопар; нагрузка была небольшой, поэтому я думал, что у меня есть много места для роста. (Я использовал только один микроэкземпляр для приема данных, так как меньшее количество криптопар не требовало такой большой мощности ЦП.) Однако я осознал ограничения своего первоначального анализа, когда решил сделать свои выводы более полными и поддерживать прием данных. для сотен криптопар — анализ облачных сервисов ничего не значит, если он не выполняется в правильном масштабе.
Передача исходящих данных
Еще одним результатом расширения моего сайта стало увеличение передачи данных из моего приложения из-за небольшой ошибки. Поскольку трафик неуклонно растет, а простоев больше нет, мне нужно было как можно скорее добавить функции, чтобы привлечь и удержать внимание пользователей. Моим последним обновлением было звуковое оповещение, которое срабатывало, когда рыночные условия криптовалютной пары соответствовали предварительно заданным пользователем параметрам. К сожалению, я допустил ошибку в коде, и аудиофайлы загружались в браузер пользователя сотни раз каждые несколько секунд.
Воздействие было огромным. Моя ошибка вызывала загрузку аудио с моих веб-серверов, вызывая дополнительные исходящие передачи данных. Крошечная ошибка в моем коде привела к тому, что счет был почти в пять раз больше, чем предыдущие. (Это было не единственное последствие: ошибка могла вызвать утечку памяти на компьютере пользователя, поэтому многие пользователи перестали возвращаться.)
Затраты на передачу данных могут составлять более 30 % скачков цен на AWS. Входящие передачи EC2 бесплатны, но плата за исходящие передачи взимается за ГБ (0,09 доллара США за ГБ, когда я создавал Scalper.AI). Как я понял на собственном горьком опыте, важно быть осторожным с кодом, влияющим на исходящие данные; Сокращение загрузки или загрузки файлов, где это возможно (или тщательный мониторинг этих областей), защитит вас от более высоких комиссий. Эти копейки быстро складываются, поскольку плата за передачу данных из EC2 в Интернет зависит от рабочей нагрузки и тарифов для конкретного региона AWS. Последнее предостережение, неизвестное многим новым клиентам AWS: передача данных между разными местоположениями становится более дорогой. Однако использование частных IP-адресов может предотвратить дополнительные расходы на передачу данных между разными зонами доступности одного региона.
Эластичные IP-адреса
Даже при использовании общедоступных адресов, таких как эластичные IP-адреса (EIP), можно снизить затраты на EC2. EIP — это статические адреса IPv4, используемые для динамических облачных вычислений. «Эластичная» часть означает, что вы можете назначить EIP любому экземпляру EC2 и использовать его, пока не решите остановиться. Эти адреса позволяют беспрепятственно заменять неработоспособные экземпляры на исправные, переназначая адрес другому экземпляру в вашей учетной записи. Вы также можете использовать EIP, чтобы указать запись DNS для домена, чтобы она указывала на экземпляр EC2.
AWS предоставляет только пять EIP для каждой учетной записи в каждом регионе, что делает их ограниченным ресурсом и дорогостоящим при неэффективном использовании. AWS взимает низкую почасовую ставку за каждый дополнительный EIP и взимает дополнительную плату, если вы переназначаете EIP более 100 раз в месяц; пребывание в этих пределах снизит затраты.
Завершить и остановить состояния
AWS предоставляет два варианта управления состоянием работающих экземпляров EC2: завершить или остановить. Прекращение приведет к закрытию экземпляра, и подготовленная для него виртуальная машина больше не будет доступна. Все подключенные тома Elastic Block Store (EBS) будут отключены и удалены, а все данные, хранящиеся локально в экземпляре, будут потеряны. Плата за инстанс больше не взимается.
Остановка экземпляра аналогична, с одним небольшим отличием. Подключенные тома EBS не удаляются, поэтому их данные сохраняются, и вы можете перезапустить инстанс в любое время. В обоих случаях Amazon больше не взимает плату за использование инстанса, но если вы выберете остановку, а не терминацию, тома EBS будут генерировать затраты, пока они существуют. AWS рекомендует останавливать экземпляр только в том случае, если вы планируете повторно активировать его в ближайшее время.
Но есть функция, которая может увеличить ваш счет за AWS в конце месяца, даже если вы завершите инстанс, а не остановите его: моментальные снимки EBS. Это добавочные резервные копии ваших томов EBS, хранящиеся в Amazon Simple Storage Service (S3). Каждый снимок содержит информацию, необходимую для создания нового тома EBS с вашими предыдущими данными. Если вы завершите экземпляр, связанные с ним тома EBS будут автоматически удалены, но его моментальные снимки останутся. Поскольку S3 взимает плату за объем хранимых данных, я рекомендую вам удалить эти снимки, если вы не будете их использовать в ближайшее время. В AWS есть возможность отслеживать активность хранилища для каждого тома с помощью сервиса CloudWatch:
- Войдя в консоль AWS, в верхнем левом меню « Службы » найдите и откройте сервис CloudWatch.
- В левой части страницы в раскрывающемся меню « Метрики » нажмите « Все метрики » .
- На странице показан список сервисов с доступными метриками, включая EBS, EC2, S3 и другие. Щелкните EBS , а затем — Метрики для каждого тома . (Примечание: опция EBS будет видна только в том случае, если в вашей учетной записи настроены тома EBS.)
- Нажмите на вкладку Запрос . В режиме редактора скопируйте и вставьте команду
SELECT AVG(VolumeReadBytes) FROM "AWS/EBS" GROUP BY VolumeId
а затем нажмите Run . (Примечание. CloudWatch использует диалект SQL с уникальным синтаксисом.)
CloudWatch предлагает различные форматы визуализации для анализа активности хранилища, такие как круговые диаграммы, линии, гистограммы, диаграммы с областями с накоплением и числа. Использование CloudWatch для выявления неактивных томов и моментальных снимков EBS — это простой шаг к оптимизации затрат на облако.
Дополнительные деньги в кармане
Хотя инструменты AWS, такие как CloudWatch, предлагают достойные решения для мониторинга облачных затрат, различные внешние платформы интегрируются с AWS для более всестороннего анализа. Например, платформы управления облаком, такие как CloudHealth от VMWare, показывают подробную разбивку основных областей расходов, которые можно использовать для анализа тенденций, обнаружения аномалий, а также мониторинга затрат и производительности. Я также рекомендую вам настроить биллинговый сигнал CloudWatch, чтобы обнаруживать любые всплески расходов до того, как они станут чрезмерными.
Amazon предоставляет множество отличных облачных сервисов, которые могут помочь вам делегировать работу по обслуживанию серверов, баз данных и оборудования команде AWS. Хотя затраты на облачную платформу могут легко вырасти из-за ошибок или ошибок пользователей, инструменты мониторинга AWS предоставляют разработчикам знания, позволяющие защитить себя от дополнительных расходов.
Имея в виду эту оптимизацию затрат, вы готовы запустить свой проект и сэкономить при этом сотни долларов.