Как оптимизировать инфраструктуру, чтобы платить меньше

Автор : Михаил Вишняков, Ведущий инженер отдела администрирования сервисов Selectel

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

Бывает, просматривая счет личной банковской карты, вы понимаете, что используете все существующие у вас ресурсы. К дате выплаты зарплаты остается несколько тысяч, и откладывать деньги на черный день никак не получается. Подобное происходит и с IT-инфраструктурой: существующие ресурсы используются по максимуму, серверы справляются с привычной нагрузкой, но любое изменение этого показателя способно «свалить» систему.

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

Стартовая точка — мониторинг

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

Подобная система мониторинга необходима для IT-инфраструктуры. Прежде чем предпринимать конкретные шаги, нужно понять, в каких местах есть нерациональное переиспользование мощностей. Чем большие мощности будут покрывать системы мониторинга, тем лучше. Убедитесь, что вы можете проследить за работой сетевого оборудования, ОС, базы данных, платформ виртуализации, приложений и других компонентов IT-инфраструктуры.

Удовлетворить базовые потребности мониторинга могут такие известные системы, как Zabbix, Prometheus, Grafana, Datadogs, InfluxDB (TICK stack) и подобные. В панели управления Selectel есть верхнеуровневый мониторинг потребления ресурсов, но опираться только на него не стоит.  

В мониторинге можно посмотреть, сколько сейчас используется памяти, какова нагрузка на серверы, какие запросы тормозят систему. В идеале можно составить единый дашборд для инфраструктуры: если у вас 15 серверов, лучше видеть их состояние в нескольких окнах, чем изучать «амбулаторную карту» каждого сервера отдельно.

Сервер базы данных

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

Но базы данных склонны к росту и повышению нагрузки, поэтому есть несколько советов, как продлить срок работы действующего сервера.

Проверьте медленные и наиболее частые запросы

С помощью выбранного инструмента мониторинга выведите топ медленных запросов, или так называемый slowlog. Если у вас есть SQL-запросы, которые выполняются дольше секунды, потратьте время на их исправление. Также имеет смысл провести ревью наиболее частых запросов. Вы выиграете в производительности, даже если оптимизируете их на 50 мс. После выполнения этих нехитрых операций вам не придется выбирать более мощный сервер для переезда БД.

Разделяйте, если можете

«Есть кейс, где компания использует довольно большую базу данных PostgreSQL, примерно на 1,3 Тбайт. Примечательно, что нагрузка идет в основном на запись. Отдельный сервис читает данные с реплики и переносит в ClickHouse, в котором уже строится аналитика. Получается, компания снимает часть нагрузки со своей базы данных и продолжает использовать довольно скромный по мощности облачный сервер. К слову, обычно под нагруженные базы данных берут выделенные серверы, но в этом случае виртуальный сервер выходит дешевле», — рассказывает Михаил Вишняков.

Такое «разделение обязанностей» можно отнести к best practices. Любой компании важно оценить характер работы базы данных. Стоит ли грузить сервер под БД дополнительными операциями? Возможно, будет дешевле вынести их на небольшой недорогой виртуальный сервер (можно рассмотреть процентный инстанс) и выполнять все операции с данными по ночам, когда общая нагрузка на системы значительно снижена.

Наймите DBA

Если у вас большая нагруженная база данных, подумайте о найме специалиста (в штат или на аутсорс), который называется Database administrator, или администратор баз данных. По сути, это DevOps-специалист, который профилируется на работе с базами данных.

Где же здесь экономия, если нам придется платить зарплату сотруднику? На самом деле хороший DBA сэкономит вам деньги и принесет пользу на сумму, превышающую свой ежемесячный оклад. Помимо оптимизации, описанной выше, он может пересмотреть архитектуру баз данных: БД станет работать как часы, обработка данных не будет тормозить, ваш сервис или приложение начнет работать быстрее для конечного пользователя.

Хранение бэкапов

Оптимизация не подразумевает сваливание и утрамбовывание всех систем на одном сервере. Такой подход повышает шансы на одномоментное падение всей инфраструктуры в сопровождении длительного даунтайма.

«В моей практике был случай, когда один из клиентов арендовал очень “жирный” bare-metal-сервер под весь проект. Однажды у него одновременно отказали материнская плата и SSD-диск. И все это посреди рабочего дня. К счастью, SSD были организованы в Raid 1, а сотрудники инженерно-технического отдела оперативно помогли с диагностикой и заменой комплектующих. Данные не пострадали, и восстановление прошло достаточно быстро для подобного случая», — рассказывает Михаил Вишняков.

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

«Нередко при проведении аудита вижу, что клиенты хранят резервные копии баз данных или приложений на одном сервере, — продолжает Михаил. — Особенно на это грустно смотреть, если дисковый массив настроен без резервирования или забит совсем под завязку. Забота о бэкапах всегда кажется не такой важной до первого инцидента».

Базовые советы по бэкапированию:

1. Используйте холодное облачное хранилище для резервных копий. Хранить там бэкапы будет удобнее и надежнее, чем на выделенном сервере, а стоимость хранения редко запрашиваемых данных в два раза дешевле.
2. Используйте open source-решения. «Коробочные» программы для организации бэкапов, как правило, и дорогие, и не самые простые в использовании. Присмотритесь к Restic — это ПО, которое считается самым простым, быстрым и надежными открытым решением для бэкапов. Сценарии его использования легко найти в открытом доступе.
3. Узнайте, какие решения для бэкапов есть у вашего провайдера. В Selectel, например, есть сервис бэкапов сетевых дисков. В нем можно настроить снятие бэкапов по расписанию. Одно из преимуществ решения — в том, что платить понадобится лишь за объем бэкапов. Думать о выделении места под них не придется — снапшоты хранятся на инфраструктуре провайдера.

Увеличение трафика

Системы мониторинга могут показать увеличение трафика на сайт или сервис. Обычно это решается вертикальным масштабированием инфраструктуры — увеличением ресурсов серверов, но можно обойтись меньшей кровью.

Изучите, с каким трафиком вы имеете дело. Если пользователи забирают статику — картинки, тексты с сайта и подобный контент, есть смысл кэшировать данные через серверы CDN. Услуга сетей доставки контента может оказаться дешевле, чем заказ новой вычислительной машины.

Еще один классический способ кэширования, который используют многие компании, —передача статики через nginx. Так запросы к контенту не «тревожат» бэкенд.

«Один из клиентов Selectel — новостной сайт — столкнулся с проблемой повышения трафика. У них были серверы на базе VMware, которые буквально загибались под нагрузкой. Их проблему полностью решил Varnish — инструмент для кэширования страниц на уровне веб-сервера. Для компаний, которые работают со статическим контентом — новостные сайты, маркетплейсы, — это мастхэв. Тем более что сам инструмент бесплатный», — делится ведущий инженер Selectel.

 Виртуальные vs выделенные серверы

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

В каких случаях выгодно использовать виртуальные серверы, если у вас не cloud-native-приложение:

1. Для разворачивания тестовых сред. Если вы используете выделенные серверы под стейджинг, подумайте о виртуалках. Разворачивайте среду по шаблону на нетребовательной vds и сворачивайте ее после использования, заплатив только за потребленные ресурсы.
2. Для автоскейлинга. Если у вас хороший рабочий сервер, но иногда нужно немного экстраресурсов, можно балансировать нагрузку на несколько виртуальных машин в дополнение к выделенному серверу. Они будут разворачиваться при повышении нагрузки и отключаться при возвращении нагрузки к прежнему уровню. Профит в том, что не придется менять конфигурацию нынешнего сервера или полностью переезжать в облако.
3. Для сверхбыстрого развертывания серверов одной конфигурации. В этом облако — первый помощник. Благодаря инструменту Packer можно создавать образы системы с настроенным ПО и поднимать или обновлять их в облаке с помощью Terraform. Таким образом можно легко управлять парком из десятков и даже сотен виртуальных серверов.

Переезд — время перемен

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

Удачное время для оптимизации — это переезд инфраструктуры. Если вы переносите свои сервисы от одного провайдера к другому, заложите в план подготовки несколько пунктов, связанных с оптимизацией. Так, если мониторинг показывает, что вам не нужен такой большой сетевой диск для веб-сервера, закажите на новом месте сервер поскромнее.

Инфраструктура как код

В долгосрочной перспективе этот пункт не раз сэкономит ресурсы компании. Потратьте время, чтобы разобраться в Ansible или научиться работать с Terraform. Описанная инфраструктура, конфигурации, сохраненные в Git, значительно облегчат развертывание систем и изменение конфигураций — и на новых серверах, и на новом месте.

Время — деньги. С подходом Infrastructure-as-Code ваш переезд может свестись к простому развертыванию облачной инфраструктуры через Terraform и настройке систем с помощью набора плейбуков Ansible. А это пара часов против нескольких дней переезда инфраструктуры. Да, для этого нужен хороший DevOps-специалист, но тут как с DBA — инвестиции в людей окупаются.

Managed-решения

Если миграция требуется скорая, можно рассмотреть PaaS-решения, которые предлагают большинство крупных провайдеров. Например, облачные базы данных или Managed Kubernetes. Здесь исключается ступень взаимодействия с инфраструктурой, что сильно экономит время на старте. На развертывание базы данных на сервере может уйти больше суток, а в managed-решении вы сразу переходите к этапу выбора конфигурации кластера. Кроме того, в PaaS-решениях обычно есть встроенное автомасштабирование, что также экономит ресурсы сисадминов и компании.

Итоги

Оптимизация инфраструктуры может быть как глобальной, так и локальной. Тут как уборка в доме: можно протереть пыль с полок, а можно отважиться на разбор хлама с балкона.

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

Источник: IT-World