Июль 22

Оптимізація під час пандемії: як ІТ-компанії зменшили витрати завдяки перебудові технічних процесів

Пандемія коронавірусу по-різному вплинула на ІТ-компанії. Деякі фірми зазнали збитків і були змушені відмовитись від оренди офісів, заморозити бонуси, зменшити зарплати співробітникам, зупинити відрядження та найм. Проте ми знайшли команди, що зосередилися на технічній оптимізації, зекономивши кошти завдяки перебудові технічних процесів. Наприклад, чистка інфраструктури від застарілих компонентів, перегляд політики створення бекапів, скорочення резерву обчислювальних потужностей, ревізія сервісів дозволили оптимізували витрати. Про деталі — розповідають представники компаній.

Максим Василец, DevOps Manager в Preply

Так как мы являемся платформой для онлайн-обучения, во время СOVID-19 количество пользователей выросло больше чем в два раза и стоимость всей AWS-инфраструктуры перевалила за $50k в месяц.

Наша система построена на основе AWS + Kubernetes с настроенными параметрами автомасштабирования, что позволило быть готовыми к росту трафика и система смогла подстроиться под требуемую нагрузку. Но обратная сторона этого — резкое повышение стоимости всей инфраструктуры. Когда стоимость резко увеличилась, стало ясно, что пришло время заняться оптимизацией и анализом затрат.

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

Первым шагом стал анализ текущих параметров инфраструктуры. Поскольку вся инфраструктура описана в коде (Infrastructure as Code), после нескольких подходов мы подобрали более оптимальные конфигурации под нагрузку и убрали то, что устарело или не использовалось. Благодаря этому удалось хорошо сэкономить. Также перешли на более новый тип инстансов, с C4/M4 на С5/M5.

Разделили приложения на группы по типу нагрузки и для каждой, используя мониторинг и APM, подобрали подходящий класс инстанса и необходимое количество ресурсов CPU/Memory.

На следующем этапе проконсультировались с аккаунт-менеджером в AWS, который предложил несколько вариантов по оптимизации затрат. Основным стал Saving Plans. Это простой и понятный инструмент для экономии: при внесении авансового платежа получаете скидку, от размера платежа зависит ее размер. Для нас скидка на вычислительные ресурсы достигла порядка 25%.

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

На весь проект ушло 2,5-3 месяца. Им занималась команда DevOps из 4 человек, при необходимости подключались разработчики. В результате получили очищенную от ненужных или устаревших компонентов инфраструктуру, хорошую скидку от AWS и отличный инструмент для анализа затрат.

Алексей Асютин, Staff Engineer в thredUP

В процессе активного роста и разработки не всегда успеваешь удалять ненужное и берешь ресурсы «с запасом». На карантине появилось время все это пересмотреть. У нас есть регулярные митинги для обсуждения проблемных моментов и технического долга. На одном из таких сделали анонс, создали Slack-канал, раздел в Wiki, куда записывали все идеи. В thredUP плоская организационная структура, поэтому решения принимались на небольших встречах. Таким образом каждый сотрудник мог подать идею. Оптимизацией занимались Infrastructure team и Software Developers.

Наша инфраструктура находится преимущественно в AWS, поэтому оптимизация связана с облачными ресурсами.

Активно используем AWS RDS (Database) и Database snapshots. Мы пересмотрели все политики создания бэкапов, удалили ненужные, оптимизировали количество и частоту создания. Благодаря этому сэкономили на хранении терабайтов данных. Где-то 130 ТБ занимали удаленные snapshots RDS. Мы с командами разработки согласовали, за какой период времени и в каком количестве нужны бэкапы базы, удалили все лишние, которые RDS создает по расписанию.

В том же AWS RDS у нас находится много инстансов для staging целей, которые не потребляли все выделенные для них ресурсы. Сделали downscale таких инстансов. Почистили устаревшие и не использующиеся данные в S3.

В свое время перешли с ограниченного количества staging environments на разворачивание dynamic staging env (инженер самостоятельно создает и настраивает staging env для своих нужд).

Оптимизировали потребляемые такими staging environment ресурсы, все разворачиваем в Kubernetes, определяем более умеренные требования к ресурсам.

Решили сворачивать dynamic staging на выходные. Перед этим, конечно же, посмотрели статистику и увидели, что ими почти никто не пользуется. А сервис 98% времени потребляет в два раза меньше ресурсов, чем мы для него выделяем. Соответственно, начали давать ресурсов меньше (60% от исходного).

Для желающих делаем исключение: можно пометить dynamic staging специальным тегом, и он не будет удаляться в течение 5 дней.

Купили резервацию на некоторые из AWS-ресурсов (например, для DynamoDB), опять же, все согласно статистике. Она показала, что мы в течение 6 месяцев регулярно используем N инстансов определенного типа. Посмотрели для чего, согласовали, что будем использовать их постоянно — купили резервацию.

Все наши Kubernetes-кластеры имеют политики для автомасштабирования, настроили принципы для downscale более агрессивно. Когда кластер не под нагрузкой, мы быстрее удаляем неиспользуемые ресурсы (EC2 инстансы), в итоге получаем меньшее количество часов работы EC2 в счетах от AWS.

В результате сэкономили примерно 3-5% AWS-чека. В долгосрочной перспективе это значительные суммы. Также стоит отметить, что сократилось время некоторых билдов, это сделало процесс разработки более комфортным. Быстрее получаешь обратную связь, быстрее деплоишь.

Игорь Израйлевич, CEO и Co-founder в S-PRO

Когда начался карантин, мы не понимали, что будет дальше, но точно не были готовы кого-то сокращать. Хотя некоторые специалисты были на бенче — то бизнес-аналитики, то дизайнеры. Поэтому мы решили задействовать их для улучшения и ускорения работы — привлекли к оценке новых проектов. Также заметили, что есть слишком много заявок на оценки в CRM, которые мы бы сделали условно через две недели. При этом оставался риск того, что через две недели новые заявки не придут. Поэтому позвали еще проджект-менеджеров, у которых был опыт работы с подобными проектами, сеньоров, Head of Delivery, Head of Technology и вместе разобрали CRM.

Так сделали гибкий ресурс дизайнеров и бизнес-аналитиков. Идея была следующая: во время карантина мы поделили новые заявки от клиентов на проекты на две группы:

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

В первые проекты привлекли бизнес-аналитиков, а во вторые — дизайнеров, и это позволило сбалансировать нагрузку.

Перестройка процессов заняла неделю с вовлечением CTO, COO, Head of BA. Мы проводили воркшопы и созвоны для команд дизайнеров и PM. А также делали звонки для контролирования процесса.

В тот месяц мы поставили рекорд — 9 контрактов, раньше такого не было. Фонд оплаты труда для оценок увеличился на 23%, потому что PM и дизайнеры тратили время не на проекты, а на внутреннюю работу, то есть оценки.

Денис Убоженко, СTO в Poster

Poster — система автоматизации для кафе, ресторанов и магазинов. Это высоконагруженный SaaS-продукт: с помощью Poster ежемесячно пробивается 17 млн чеков в 11 тыс. ресторанах-клиентах в 90 странах мира. Система состоит из POS-терминала для официантов и админ-панели для владельцев. Вся инфраструктура размещается примерно на 65 dedicated и 30 виртуальных серверах.

Когда начался карантин, мы получили естественное снижение продаж продукта и решили заняться оптимизацией костов. Реализовали целый ряд антикризисных мер: отключили маркетинговые кампании с низким ROI, приостановили на пару месяцев найм по всем позициям, получили скидки, каникулы, отсрочки платежей у партнеров.

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

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

На один спринт мы объединили усилия DevOps-команды и специалистов, которые отвечают за автоматизацию внутренних процессов. Результатом их работы стало следующее решение: если клиент не заходит в аккаунт последние три месяца, а также не пробивает за это время чеки, мы создаем архив его данных и кладем на бэкап-сервер. Клиента переводим в архивный статус, а базу удаляем.

Когда в следующий раз этот клиент решит зайти в систему, получит сообщение с просьбой подождать 5-10 минут. За это время обратно создадим его базу, разархивируем старые данные и переведем клиента в обычный режим.

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

В действительности результат получился не настолько вдохновляющим, но тоже принес свои плоды. По итогам работы количество баз сократили в четыре раза, а вот объем данных — только на четверть. То есть вездесущий принцип Парето сработал и здесь: 25% клиентов заняли 75% места на дисках.

После того как мы заархивировали неиспользуемые данные, нам понадобилось еще примерно месяц на уплотнение оставшихся баз данных на серверах. После их переноса оказалось, что можем отказаться не от трех из двенадцати кластеров, а от двух. Так как первые девять уже были заполнены на допустимые 60%, пришлось десятый оставить под новых клиентов.

Что в сухом остатке? В качестве затрат вышел примерно месяц работы одного инженера, а в качестве выгоды — экономия $1000 в месяц на двух кластерах. Конечно, это не огромная денежная выгода, но, помимо этого, оптимизация привела к ускорению работы оставшихся серверов баз данных, поскольку сократилось количество мелких баз.

Павло Павловський, Chief Operating Officer в Interkassa

Ми думали про оптимізацію й раніше, але це питання було не таким пріоритетним, щоб виділяти на нього ресурс. Умовно кажучи, мали вибір: провести оптимізацію або витратити цей час команди на розгортання нового комерційного сервісу, який принесе більше коштів, ніж заощадить оптимізація. Ми обирали друге. Оптимізація — це важливо, але до кризи швидкість розробки для нас була більш важливою. Карантин трохи змінив акценти: деякі комерційні проєкти стали менш актуальними, з’явився ресурс на оптимізацію.

Ініціатива провести її йшла від СТО. Вони разом з DevOps-розробниками провели аналіз і розробили етапи оптимізації: збір даних з використання ресурсів, аналіз і створення плану внесення змін у конфігурацію та реалізація.

Програму техоптимізації затвердили в межах загальної антикризової стратегії компанії. Весь процес зайняв близько двох тижнів. Ми розробили план оптимізації витрат, що складався з трьох етапів на випадок різних сценаріїв розвитку подій.

1-й етап: оптимізувати витрати на 15%.
2-й етап: скоротити витрати на 30%, якщо кризова ситуація буде погіршуватися.
3-й етап: скоротити на 50%, жорсткі заходи в разі економічної катастрофи.

В роботу запустили лише перший етап. Він дав результат, тому в більш жорстких заходах не виникло потреби.

Щоб зменшити витрати, ми втілили такі кроки техоптимізації:

Скоротили резерв обчислювальних потужностей.
Провели ревізію сервісів і вивели деякі з них з експлуатації.
Використовували доступні інструменти Google Cloud.

Скоротили резерв обчислювальних потужностей

На випадок високих пікових навантажень у нас був гарний запас потужності віртуальних машин (на різних типах сервісів — 15-25%, проводили історичний аналіз на основі метрик, порівнюючи з навантаженням), на яких працюють сервіси. Щоб оптимізувати витрати, оцінили всі сервіси та ресурси, які вони використовують, і визначили, що за поточного навантаження можемо зменшити резерв. Скоротили обсяг пам’яті та кількість процесорів CPU. Водночас якість роботи сервісів залишилася на тому ж рівні, що й до скорочення, а це 5-10% залежно від типу.

Провели ревізію сервісів і вивели з експлуатації деякі з них

Ми постійно шукаємо і тестуємо нові сервіси, оцінюємо, наскільки вони корисні. Коли почався карантин, у нас теж деякі сервіси на зразок Dremio працювали в експериментально-тестовому режимі. Для кожного сервісу виділили групу віртуальних машин (k8s nodes), на яких він функціонує, оцінили ресурси CPU і пам’ять, патерн їх використання і кореляцію з навантаженням. Оскільки це не сервіси першої потреби, відмовилися від них. Вирішили поки зупинитися на вже перевірених, найбільш необхідних, а експерименти відклали.

Використали доступні інструменти Google Cloud

Google дає можливість використовувати сервіси Google Cloud на особливих умовах — committed use: ви отримуєте знижку, але зобов’язуєтеся платити за підтверджені ресурси один або три роки. Не має значення, користуєтеся ви цими ресурсами чи ні.

Оскільки ми не збиралися переходити з Google Cloud, вирішили взяти комітмент на три роки, і це дозволило нам заощадити.

Результат

Як і було передбачено першим етапом оптимізації, ми скоротили витрати на 15% і наразі не плануємо їх збільшувати. При цьому важливо зазначити, що оптимізація не вплинула безпосередньо на процес розробки та не позначилася негативно на роботі сервісів і продуктів. Ми змогли оптимізувати витрати та зберегти якість і стабільність роботи.

Окремо під оптимізацію кошти не виділяли, на неї витратили тільки робочий час команди.