Привет, форумчане! Хочу поделиться историей, которая началась с довольно неприятного письма от бухгалтерии. Наш месячный счёт за облако перевалил за отметку, которую я сам себе обещал не переходить, и стало понятно: либо мы что-то меняем в инфраструктуре, либо начинаем экономить на людях. Второй вариант я отбросил сразу, поэтому сел разбираться с тем, что вообще происходило на наших серверах. Честно говоря, я ожидал пары быстрых правок, но получилась целая кампания длиной в три месяца, которая в итоге дала минус 40% к расходам без потери производительности.
Первое, что я сделал — включил нормальный мониторинг и просто неделю смотрел на графики. Это скучно, но именно там вылезли все скелеты. Выяснилось, что треть наших инстансов жила с загрузкой процессора около пяти процентов, а память была забита под завязку из-за утечек в одном из сервисов. Мы годами покупали железо под пиковую нагрузку, которая случалась раз в сутки на пятнадцать минут. Осознание этого факта было почти физически болезненным, потому что мы платили за страховку от события, которого можно было избежать архитектурно.
Второй шаг — мы начали с самых простых вещей, и они дали неожиданно большой эффект. Перенесли статические файлы и картинки в объектное хранилище вместо того, чтобы гонять их через приложение. Отключили несколько резервных копий, которые дублировали друг друга и лежали в горячем хранилище, хотя нужны были раз в год. Переписали пару тяжёлых запросов в базе, из-за которых разработчики ставили слишком мощные инстансы «на всякий случай». Только эти три вещи сократили счёт примерно на двенадцать процентов, и это почти ничего нам не стоило, кроме пары дней работы.
Дальше была самая интересная часть — автоскейлинг и правильные типы инстансов. Раньше у нас все сервисы крутились на одинаковых универсальных машинах, потому что так было проще настраивать. Когда мы разнесли нагрузку по профилям и подобрали под каждый сервис подходящий класс, картина изменилась радикально. База данных получила больше памяти и быстрые диски, а веб-слой наконец уехал на дешёвые вычислительные ноды. Плюс мы настроили масштабирование по расписанию для тех сервисов, где нагрузка предсказуема, и по метрикам — для остальных. Это добавило немного сложности в конфигурацию, но экономия того стоила.
Отдельно хочу сказать про контейнеры и упаковку ресурсов. Мы довольно долго жили с контейнерами, у которых лимиты были выставлены «от балды» — с большим запасом. После того как мы собрали реальные метрики потребления и подрезали лимиты, на тех же самых серверах стало помещаться в полтора раза больше подов. Это не потребовало ни переписывания кода, ни смены облачного провайдера. Просто аккуратная работа с цифрами, которую многие команды откладывают на потом, потому что она не выглядит как «настоящая разработка».
Ещё один урок, который я вынес, касается организационной части. Самая большая экономия случилась не тогда, когда я придумал хитрую схему, а когда мы ввели правило: каждый новый ресурс в инфраструктуре должен иметь владельца и дату пересмотра. До этого в облаке плодились тестовые окружения, забытые эксперименты и диски от удалённых машин, за которые мы исправно платили. Мы прошлись по всему этому хламу, удалили лишнее и настроили автоматические напоминания. Это не про технологии, это про дисциплину, и именно дисциплина дала нам ещё процентов десять экономии.
Если вы сейчас смотрите на свои счета и думаете, что оптимизация — это сложно и долго, поверьте моему опыту: начинать надо не с покупки инструментов, а с честного аудита. Посмотрите, что у вас реально работает, какие ресурсы простаивают и где вы платите за страх, а не за нагрузку. Заведите привычку проверять графики раз в неделю, заведите владельцев у каждого сервиса и не бойтесь резать лимиты — увеличить их обратно всегда проще, чем годами переплачивать. И да, не пытайтесь сделать всё за один спринт, иначе выгорите и бросите на полпути.
А теперь вопрос к вам, друзья: какие приёмы оптимизации инфраструктуры сработали лично в вашем проекте и сколько процентов от счёта вам удалось отыграть? Делитесь кейсами в комментариях, будет очень интересно сравнить подходы и, может быть, подсмотреть что-то новое друг у друга!
Первое, что я сделал — включил нормальный мониторинг и просто неделю смотрел на графики. Это скучно, но именно там вылезли все скелеты. Выяснилось, что треть наших инстансов жила с загрузкой процессора около пяти процентов, а память была забита под завязку из-за утечек в одном из сервисов. Мы годами покупали железо под пиковую нагрузку, которая случалась раз в сутки на пятнадцать минут. Осознание этого факта было почти физически болезненным, потому что мы платили за страховку от события, которого можно было избежать архитектурно.
Второй шаг — мы начали с самых простых вещей, и они дали неожиданно большой эффект. Перенесли статические файлы и картинки в объектное хранилище вместо того, чтобы гонять их через приложение. Отключили несколько резервных копий, которые дублировали друг друга и лежали в горячем хранилище, хотя нужны были раз в год. Переписали пару тяжёлых запросов в базе, из-за которых разработчики ставили слишком мощные инстансы «на всякий случай». Только эти три вещи сократили счёт примерно на двенадцать процентов, и это почти ничего нам не стоило, кроме пары дней работы.
Дальше была самая интересная часть — автоскейлинг и правильные типы инстансов. Раньше у нас все сервисы крутились на одинаковых универсальных машинах, потому что так было проще настраивать. Когда мы разнесли нагрузку по профилям и подобрали под каждый сервис подходящий класс, картина изменилась радикально. База данных получила больше памяти и быстрые диски, а веб-слой наконец уехал на дешёвые вычислительные ноды. Плюс мы настроили масштабирование по расписанию для тех сервисов, где нагрузка предсказуема, и по метрикам — для остальных. Это добавило немного сложности в конфигурацию, но экономия того стоила.
Отдельно хочу сказать про контейнеры и упаковку ресурсов. Мы довольно долго жили с контейнерами, у которых лимиты были выставлены «от балды» — с большим запасом. После того как мы собрали реальные метрики потребления и подрезали лимиты, на тех же самых серверах стало помещаться в полтора раза больше подов. Это не потребовало ни переписывания кода, ни смены облачного провайдера. Просто аккуратная работа с цифрами, которую многие команды откладывают на потом, потому что она не выглядит как «настоящая разработка».
Ещё один урок, который я вынес, касается организационной части. Самая большая экономия случилась не тогда, когда я придумал хитрую схему, а когда мы ввели правило: каждый новый ресурс в инфраструктуре должен иметь владельца и дату пересмотра. До этого в облаке плодились тестовые окружения, забытые эксперименты и диски от удалённых машин, за которые мы исправно платили. Мы прошлись по всему этому хламу, удалили лишнее и настроили автоматические напоминания. Это не про технологии, это про дисциплину, и именно дисциплина дала нам ещё процентов десять экономии.
Если вы сейчас смотрите на свои счета и думаете, что оптимизация — это сложно и долго, поверьте моему опыту: начинать надо не с покупки инструментов, а с честного аудита. Посмотрите, что у вас реально работает, какие ресурсы простаивают и где вы платите за страх, а не за нагрузку. Заведите привычку проверять графики раз в неделю, заведите владельцев у каждого сервиса и не бойтесь резать лимиты — увеличить их обратно всегда проще, чем годами переплачивать. И да, не пытайтесь сделать всё за один спринт, иначе выгорите и бросите на полпути.
А теперь вопрос к вам, друзья: какие приёмы оптимизации инфраструктуры сработали лично в вашем проекте и сколько процентов от счёта вам удалось отыграть? Делитесь кейсами в комментариях, будет очень интересно сравнить подходы и, может быть, подсмотреть что-то новое друг у друга!