- PVSM.RU - https://www.pvsm.ru -
Мир кардинально меняется. Многие компании ищут любые способы для сокращения расходов, просто для того, чтобы выжить. При этом усиливается нагрузка на онлайн-сервисы — особенно те, которые связаны с организацией удалённой работы, проведением видео-конференций, онлайн-обучением.
В этих условиях крайне важно с одной стороны — обеспечить надежность и масштабирование вашей инфраструктуры. С другой — не вылететь в трубу с закупкой серверов, дисков, оплатой траффика.
Мы в «Битрикс24» очень активно используем Amazon Web Services, и в этой статье я расскажу о нескольких возможностях AWS, которые помогут вам сократить ваши расходы.
«Битрикс24» — глобальный сервис, мы работаем для клиентов по всему миру. С 2015 года, с момента вступления в силу закона 242-ФЗ о локализации персональных данных, данные российских пользователей хранятся на серверах в России. А вот вся инфраструктура сервиса, обслуживающего остальных клиентов по всему миру, развёрнута в Amazon Web Services.
Экономический кризис — уже свершившийся факт. Курс доллара вырос и вряд ли вернется на прежние позиции в ближайшее время, поэтому оплата
В этих условиях, если вы продолжаете размещать ваши ресурсы в AWS, вам, скорее всего, будут интересны приёмы, которые помогут вам сэкономить на аренде инфраструктуры.
Я расскажу об основных из них, которые мы сами уже много лет используем. Если же есть какие-то еще способы, которые используете вы — пожалуйста, делитесь в комментариях.
Итак, поехали.
Самый простой и очевидный способ сэкономить в AWS — использовать зарезервированные инстансы EC2. Если вы знаете, что определенные инстансы вы совершенно точно будете использовать, как минимум, в течение года, вы можете внести за них предоплату и получить скидку от 30% до 75%.
Пример расчетов для инстансов c5.xlarge:
Все цены и расчеты — здесь [2].
Иногда выглядит сложно и запутанно, но в целом логика такая:
Для себя мы делаем резервирования на 1 год, потому что на 3 года планировать довольно сложно. И это позволяет неплохо экономить на EC2.
Использование Spot Instances — это по сути некоторая биржа ресурсов. Когда у Amazon есть много простаивающих ресурсов, вы можете для специальных «спотов» (Spot Instances) задать максимальную цену, которую вы готовы за них платить.
Если текущий спрос в определенном регионе и AZ (Availability Zone) мал, то вам предоставят эти ресурсы. При чем по цене в 3-8 раз ниже, чем цена on-demand.
В чем подвох?
Исключительно в том, что если свободной емкости не будет, запрошенные ресурсы вам не дадут. И если спрос резко вырастет, и цена на споты превысит вашу заданную максимальную цену, ваш спот будет удален (terminate).
Естественно, такие инстансы не подойдут, например, для БД в продакшене. Но для каких-то задач, которые связаны, например, с теми или иными расчетами, рендерингом, обсчетом моделей, для тестов — отличный способ сэкономить.
Посмотрим на практике, за какие суммы бьемся. И часто ли споты могут «уходить» по цене.
Вот для примера Spot Instance Pricing History прямо из консоли AWS для региона eu-central-1 (Франкфурт) для инстансов c5.4xlarge:
Что мы видим?
Как мы используем споты на практике:
— Мы используем споты для серверов приложений.
— Для них мы активно используем связку CloudWatch + Auto Scaling — для автоматического масштабирования в течение дня: нагрузка возрастает — запускаются новые инстансы, нагрузка падает — они гасятся.
— Для подстраховки у нас за балансировщиками работают две Auto Scaling группы — на тот случай, если споты закончатся. Одна AS группа — с обычными (on demand) инстансами, вторая — со спотами. Amazon через CloudWatch Events предупреждает за 2 минуты о том, что spot instance будет удален (terminate). Мы обрабатываем эти события и успеваем расширить основную группу до нужного количества инстансов, если такое происходит.
Подробности вот здесь — Spot Instance Interruption Notices [3].
— Чтобы эффективнее работать с Auto Scaling и по максимуму использовать именно машины в группе со спотами, мы применяем такой подход:
Все, кто работает с AWS, знают, что основные диски, которые используются для EC2 инстансов — это EBS (Elastic Block Store). Их можно монтировать к инстансам, отключать, монтировать к другим инстансам, делать с них снэпшоты.
Все EBS в зависимости от их типа так или иначе тарифицируются. И стоят весьма ощутимых денег.
При этом для многих типов инстансов при их создании доступно подключение локальных дисков — EC2 Instance Store [4].
Главная особенность этих дисков — если вы останавливаете (stop) инстанс с таким диском, то потом после старта эти данные теряются.
Но при этом они условно бесплатны — есть плата только за сам инстанс.
Такие диски можно отлично использовать под любые временные данные, которые не требуют постоянного сохранения — свопы, кэш, любые другие временные данные. Производительность Instance Store дисков достаточно высока: кроме уж совсем старых типов инстансов сейчас под них используются либо SSD, либо NVMe SSD.
В итоге: подключаем меньше EBS дисков, меньше платим.
Выше речь шла, в основном, о EC2. Дальше опишем несколько приемов, которые позволят сэкономить при использовании S3 (Simple Storage Service).
Если вы активно работаете с S3, то, наверняка, знаете, что и S3, и большинство клиентов для работы с этим хранилищем поддерживают Multipart Upload [5] — большой объект загружается «кусочками», которые затем «собираются» в единый объект.
Это отлично работает, но есть одна засада.
Если загрузка по каким-то причинам не завершена (связь оборвалась, например, и загрузку не возобновляли), то уже загруженные части не удаляются сами. При этом они занимают место, вы за них платите.
И неприятный сюрприз — эти неполные данные никак не видны при работе со стандартными инструментами для S3: ни через «ls» в cli, ни в программах-клиентах. Найти их можно, например, в aws cli с помощью команды list-multipart-uploads [6].
Но так с ними работать слишком утомительно…
Самым логичным было бы вынести какую-то опцию про хранение Incomplete Multipart Uploads в настройки конкретного бакета. Но почему-то Амазон так не сделал.
Тем не менее, способ облегчить себе жизнь и удалять автоматом Incomplete Multipart Uploads есть. В настройках бакета на вкладке Management есть раздел Lifecycle. Это удобный инструмент, который позволяет настраивать различные автоматические правила для работы с объектами: перемещать их в другие хранилища, удалять через какое-то время (expire) и — в том числе — управлять поведением Incomplete Multipart Uploads.
Подробная статья про это есть в блоге AWS [7] — правда, с примерами из старого интерфейса, но там всё довольно понятно.
Важно то, что настроенный на удаление неполных данных Lifecycle сработает не только для новых объектов, но и для уже имеющихся.
За реальным объемом занятого в S3 места можно следить через CloudWatch. Когда мы настроили удаление Incomplete Multipart Uploads, с удивлением обнаружили, что освободили не один десяток терабайт…
В S3 есть несколько разных классов хранилищ:
Все они имеют разные условия использования и разные цены. Их можно и нужно комбинировать — в зависимости от ваших разных задач.
Но относительно недавно появился еще один очень любопытный тип хранилища — Intelligent Tiering.
Суть его работы в следующем: за небольшую дополнительную плату осуществляется мониторинг и анализ ваших данных в S3, отслеживаются обращения к ним, и, если обращений нет в течение 30 дней, объект автоматически перемещается в хранилище нечастого доступа, которое стоит значительно дешевле стандартного. Если через какое-то время к объекту опять обращаются — никакого снижения производительности при этом не происходит — он опять перемещается в хранилище стандартного доступа.
Самое главное удобство: вам самим не надо ничего делать.
Amazon все сделает «по-умному» сам — разберется, какие объекты куда сложить.
Мы, включив Intelligent Tiering, на некоторых бакетах получили экономию до 10-15%.
Всё звучит слишком хорошо и волшебно. Но не может же не быть каких-то подводных камней? Они есть, и их, конечно, надо учитывать.
Как включить Intelligent Tiering?
Можно в явном виде указать класс хранения INTELLIGENT_TIERING в S3 API или CLI.
А можно настроить правило Lifecycle, по которому, например, все объекты после определенного времени хранения будут автоматически перемещаться в Intelligent Tiering.
Подробнее — в том же блоге AWS [8].
Если уж мы заговорили о разных классах хранилищ в S3, то, конечно же, стоит упомянуть и Glacier [9].
Если у вас есть данные, которые надо хранить месяцы и годы, но доступ к которым нужен крайне редко — например, логи, бэкапы — то обязательно рассмотрите возможность использования Glacier. Цена его использования — в разы меньше, чем стандартный S3.
Для удобной работы с Glacier можно использовать все те же правила Lifecycle.
Например, можно задать правило, по которому объект будет какое-то время храниться в обычном хранилище, например, 30-60 дней (обычно доступ нужен к наиболее близким по времени логам или бэкапам, если мы говорим об их хранении), затем будет перемещаться в Glacier, а по истечение 1-2-3… лет — полностью удаляться.
Это будет в разы дешевле, чем хранение просто в S3.
* * *
Я рассказал о некоторых приемах, которые мы сами активно используем. AWS — огромная инфраструктурная платформа. Наверняка, мы не рассказали о каких-то сервисах, которые используете именно вы. Если есть какие-то еще способы экономии в AWS, которые пригодились именно вам — пожалуйста, делитесь в комментариях.
Автор: Александр Демидов
Источник [10]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/amazon-web-services/350801
Ссылки в тексте:
[1] хостинга: https://www.reg.ru/?rlink=reflink-717
[2] здесь: https://aws.amazon.com/ru/ec2/pricing/reserved-instances/pricing/
[3] Spot Instance Interruption Notices: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/spot-interruptions.html#spot-instance-termination-notices
[4] EC2 Instance Store: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/InstanceStorage.html
[5] Multipart Upload: https://aws.amazon.com/ru/blogs/aws/amazon-s3-multipart-upload/
[6] list-multipart-uploads: https://docs.aws.amazon.com/cli/latest/reference/s3api/list-multipart-uploads.html
[7] блоге AWS: https://aws.amazon.com/ru/blogs/aws/s3-lifecycle-management-update-support-for-multipart-uploads-and-delete-markers/
[8] блоге AWS: https://aws.amazon.com/ru/blogs/aws/new-automatic-cost-optimization-for-amazon-s3-via-intelligent-tiering/
[9] Glacier: https://aws.amazon.com/ru/glacier/
[10] Источник: https://habr.com/ru/post/493938/?utm_source=habrahabr&utm_medium=rss&utm_campaign=493938
Нажмите здесь для печати.