В этой статье я рассказываю, какую пользу можно получить от оптимизации ИТ-инфраструктуры, а также то, как избежать распространенных трудностей в процессе. Мы неоднократно помогали клиентам с оптимизацией инфраструктуры, и все примеры, приведенные в статье — из собственного опыта.
Для удобства я разделил текст на три части:
- для чего нужна оптимизация инфраструктуры;
- какие основные этапы оптимизации;
- какие сложности могут возникнуть в процессе и как с ними справиться.
Какие преимущества оптимизации инфраструктуры
Оптимизация инфраструктуры начинается с анализа системы. В зависимости от того, где находится система: на вашем сервере (on-premise) или в облаке, преимущества оптимизации инфраструктуры отличаться.
Также существует комбинированный подход (использование и сервера, и облака), который рассмотрю позже.
Одним из преимуществ переноса инфраструктуры в облака является концепция общей ответственности — за некоторые аспекты отвечает провайдер облака, а другие — клиент. Например, облака берут на себя вопросы эксплуатации, контроля и управления компонентами. Это охватывает всё от уровня виртуализации и операционной системы узла до уровня физической безопасности объектов, где работает сервис.
Используя облако, клиент может не волноваться за поддержку физических серверов, частичную поддержку безопасности этой системы и многое другое. Но, конечно, это зависит от серверов, которые используем. В результате требуется меньше людей, которые поддерживают инфраструктуру, уменьшает расходы для клиента, а свободный ресурс можно использовать для экспериментов по оптимизации и расширения бизнеса.
Для некоторых компаний переход в облачную инфраструктуру — это замечательный путь оптимизации расходов. Например, один из наших клиентов международный стриминговий сервис — требовал решения, которое было бы дешевле содержать и выдерживало высокую нагрузку в 36000000 уникальных посетителей и более 10000000000 запросов в неделю. Мы выбрали оптимизацию путем создания Kubernetes кластера в облаке AWS. Наши разработчики создали 30 микросервисив, содержание которых обходится клиенту примерно в 2000 USD ежемесячно.
Для сравнения, неоптимизированного архитектура, состоящая из EC2 OnDemand instances, обходилась нашем в клиенту больше чем в 38000 USD в месяц.
Также у команды был такой случай: услуги клиента работали в EC2 instances через службу ECS. Однако после того, как мы проанализировали схемы использования услуг, периоды пиковой нагрузки и расходы на управление средой, предложили клиенту заменить экземпляры EC2 на Farate, безсерверное решение, которое не требует управления базовой инфраструктурой серверов. В результате решение помогло клиенту значительно сэкономить.
Также, например, имплементировать новые аппликации в облаке часто гораздо быстрее и дешевле, чем on-premise. Разработчики создают прототип, тестируют его в облаке, и если сервис не оправдал надежд, его можно просто отключить, освободив тем самым ресурсы облака и деньги на содержание. В случае же on-premise пришлось бы сначала вложить деньги в физические серверы, которые затем могли не использоваться.
Оптимизация on-premise инфраструктуры зачастую заключается в сокращении расходов за уменьшения количества машин или удешевлении машин. Нужно учитывать то, что, уменьшая расходы, вы уступаете чем-то другим. Например, из-за уменьшения количества машин в дата-центре ваш сайт или приложение может не выдержать пиковой нагрузки.
То есть, прежде чем проводить оптимизацию инфраструктуры путем уменьшения количества машин в дата-центр, уменьшение мощности процессора или объем памяти, нужно четко понимать, на что это может повлиять. Иными словами, нужно провести детальный аудит текущих бизнес-процессов.
Собственно, аудит и является первым этапом оптимизации инфраструктуры.
Какие ключевые этапы оптимизации инфраструктуры?
аудит ИТ инфраструктуры
Этот этап помогает понять, насколько целесообразно оптимизировать инфраструктуру в вашем случае.
Во время этого этапа DevOps-эксперты анализируют, как используется облако. Или администраторы анализируют, как работает сервер. Для этого обычно используют такие инструменты, как AWS Audit Manager от Amazon. Этот инструмент собирает метрики, которые затем можно проанализировать. Например, если анализ показал, что система никогда не использует более 6 Гб памяти с 16 доступных, то это повод для оптимизации путем уменьшения объема памяти.
Планирование новой или оптимизированной инфраструктуры
Поскольку есть много подходов к оптимизации инфраструктуры, планирование становится очень важным аспектом. Среди основных подходов к оптимизации — уменьшение количества машин, уменьшение памяти, объединение сервисов в кластеры и другие.
В случае с Kubernetes кластером / Doker контейнером можно, например, создать систему из пяти машин и запустить на них 10 аппликаций. Такой подход помогает удешевить хостинг и не иметь визуальных проблем при выходе машины из строя. Так, если одна из машин выйдет из строя, система автоматически перенесет сервисы с неё на остальные машины. И наоборот, если машина возвращается в систему, то и сервисы на нее тоже возвращаются.
Нужно понимать, какой подход принесет больше преимуществ именно на вашем проекте, и хорошо продумать, каким образом его следует имплементировать. Если при выполнении плана становится понятно, что необходимо что-то модернизировать или переписать, то к процессу должна присоединиться команда разработчиков.
Есть много случаев, когда не выгодно переходить с on-premise на облако, поскольку это часто не удешевляет инфраструктуру. Кроме того, перенос системы на облако без изменений часто означает ее подорожание. Поэтому я бы посоветовал идти гибридным путем и комбинировать on-premise и облачную инфраструктуры.
Например, в системе бизнес-процесс, который запускается в начале месяца и работает один день. В остальные дни он не используется. В таком случае нецелесообразно хранить его on-premise и платить за него весь месяц. Лучше хранить его в облаке и платить только за несколько дней в месяц, когда он и используется.
После детального анализа, планирования, определения функциональных требований системы, исследования нагрузки на систему можно переходить к этапу осуществления.
Имплементация плана оптимизации
Если просто, имплементация — это перенос приложений с одних машин на другие. Как я уже писал, оптимизация on-premise инфраструктуры — это преимущественно уменьшение количества машин.
Согласно классификации, есть 6 основных вариантов миграции:
- Рехостинг / Re-host (lift and shift).
- Реплатформинг / Re-platform (lift, tinker, and shift).
- Модернизация / Modernize.
- Переписывание / Rewrite.
- Выбросить и купить готовое / Drop and shop.
- Оставить как есть / Retain.
Чтобы определить лучший метод именно для вашего проекта, сначала нужно провести тщательный анализ вашего приложения . Нужно оценить, возможно ли просто перенести аппликации, или программа требует совершенствования до / после миграции. Иногда невозможно перенести данные без совершенствования программного кода.
Например, если система не поддержит многопоточность, сессионность или использования приложения во многих экземплярах, то мы навредим, запустив несколько экземпляров системы одновременно.
Рехостинг — самый простой из методов, поскольку он не требует изменения кода, а потому занимает меньше времени. Однако в долгосрочной перспективе этот метод не предусматривает быстрого масштабирования и дополнительной производительности. Обычно этот метод не дает оптимизации инфраструктуры, а возможно, и удорожит ее.
Реплатформинг охватывает некоторые дальнейшие коррективы. Например, переход на полностью управляемые услуги. Этот подход, при правильной реализации, может существенно сократить расходы на инфраструктуру.
Одна из крупнейших телеком-компаний Европы — Lebara, мигрировала свои данные в облако именно с помощью реплатформингу. В результате они смогли значительно улучшить масштабирования. Кроме того, переход на облако помог сократить расходы на инфраструктуру на 25-30%.
При модернизации некоторые компоненты программы совершенствуются до или после миграции. Таким образом этот подход требует больше времени на изменения в коде.
Переписывание — это сложный процесс преобразования приложений с адаптацией к облачной инфраструктуры. В зависимости от типа аппликации можно существенно сократить затраты на инфраструктуру.
Drop and shop — здесь все просто, если на рынке есть приложения, которые вас удовлетворяют, то лучше купить их, чем создавать свои. Обычно это так же уменьшит цену инфраструктуры.
Retain — это пассивный метод, поскольку миграция не нужна. Вы сохраняете программы как есть, где они есть.
Какие сложности могут возникнуть в процессе оптимизации
Сложности оптимизации я тоже условно делю на сложности on-premise и облака.
Если говорить об оптимизации без переноса приложений в облако, то есть on-premise, то сложной задачей является детальный анализ системы. Для этого нужно четко понимать, как действуют ее пользователи, когда происходят пиковые нагрузки, сколько нужно мощностей, чтобы эти нагрузки выдержать, и какая стратегия развития продукта на будущем.
Кроме того, сложности есть уникальность каждой инфраструктуры. Это касается и on-premise, и облачной инфраструктуры.
К примеру, один клиентов, ранее работавший с другим разработчиком программного обеспечения, имел в системе бизнес-процесс, созданный еще 10 лет назад. Этот процесс посылал мейлы пользователям системы. Так как разработчики процесса уже ушли из проекта, команда не знала, на что может повлиять его оптимизация. В результате оптимизации сообщения пользователям перестали поступать. Соответственно через оптимизацию часть системы перестала работать. Чтобы такого не происходило, важно уделять внимание сохранению знаний на проектах.
Сохранение знаний на проект в ИТ-аутсорсинга
Итак, чтобы провести успешную оптимизацию инфраструктуры, необходимо:
- Осуществить детальный аудит системы.
- Найти способ оптимизации, который наилучшим образом соответствует потребностям вашего проекту.
- Имплементировать его.
Компания ИТ для бизнеса предоставляет услуги по аудиту, планированию, оптимизации и реализации ИТ инфоаструктуры как в облаке так и на земле, обращайтесь [email protected]
Источник: Перевод статьи с DOU.