Проблемы масштабируемости всегда были характерны для вычислительных и сетевых систем, но сейчас среды стали еще сложнее и требуют больше усилий. Опрошенные порталом InformationWeek эксперты объясняют, почему по мере роста бизнеса и усложнения технологических стеков масштабируемость остается одной из главных проблем. А также рассказывают об областях ИТ, которые нуждаются в лучшей масштабируемости.
«Компании сталкиваются с серьезными проблемами масштабируемости как в физических, так и в виртуальных пространствах. Хотя целостный подход к операциям дает преимущества, он также привносит сложность, — говорит Дастин Джонсон, технический директор компании Seeq, предоставляющей ПО расширенной аналитики. — Облако может помочь, но оно не всегда является универсальным решением, особенно в отношении вычислительных потребностей. Специализированные ресурсы, такие как GPU для ИИ-нагрузок и CPU для стандартных процессов, необходимы в первую очередь, а такие технологии, как Kubernetes, позволяют эффективно осуществлять кластеризацию и масштабирование. Однако приложения должны быть разработаны таким образом, чтобы в полной мере использовать эти возможности, иначе они не смогут реализовать свои преимущества».
Разнообразие задействованных технологий значительно повышает сложность.
«Сегодня вертикально интегрированный технологический стек непрактичен, поскольку компании используют различные приложения, инфраструктуру, инструменты ИИ/МО и системы сторонних разработчиков, — говорит Джонсон. — Интеграция всех этих компонентов — обеспечение совместимости, безопасности и масштабируемости — требует тщательной координации всего технологического ландшафта».
Распространенной ошибкой является отношение к масштабируемости как к узкому технологическому вопросу, а не как к основополагающему аспекту системного дизайна. Сиюминутный подход к решению этой проблемы ограничивает долгосрочную гибкость и может затруднить реагирование на растущие потребности.
Ниже перечислены некоторые аспекты ИТ, которые должны лучше масштабироваться в 2025 г.
1. Процессы
Во многих организациях до сих пор существуют ручные процессы, которые препятствуют скорости и масштабированию. Например, если пользователю нужно отправить тикет на новый сервер для реализации нового проекта, кто-то должен написать этот тикет, кто-то его получить, кто-то активировать, а затем что-то с ним сделать. Это целая последовательность шагов.
«Такой способ управления средой нельзя назвать масштабируемым, поэтому я считаю, что масштабирование процессов за счет автоматизации — очень важная тема, — говорит Хиллери Хантер, технический директор и руководитель направления инноваций IBM. — Существует множество различных ответов на этот вопрос, начиная от автоматизации и заканчивая тем, о чем говорят люди, например, ITOps или технологии оркестровки. Если у вас есть CIO, который пытается что-то масштабировать и должен получить отдельные разрешения от директоров по информационной безопасности, рискам или данным, такая последовательность согласований блокирует скорость и масштабируемость».
Организации, которые хотят достичь более высоких скоростей, должны сделать это совместной обязанностью членов высшего руководства.
«Вы же не хотите просто автоматизировать неэффективные вещи в своей организации. На самом деле вы хотите преобразовать бизнес-процесс, — говорит Хантер. — Когда вы собираете руководителей по ИТ, информации и безопасности за одним столом, вы устраняете сериализацию процесса принятия решений, исключаете импульс сказать „нет“ и создаете коллективный импульс сказать „да“, потому что все понимают, что преобразования являются взаимными и являются командной целью».
2. ИТ-операции
ИТ-отдел всегда находится под давлением, от него требуют более быстрой работы без ущерба для качества, однако необходимость делать больше при меньших затратах приводит к тому, что ИТ-руководители и их сотрудники оказываются перегруженными.
«Масштабирование должно осуществляться за счет повышения эффективности и автоматизации, а также использования таких вещей, как AIOps, для контроля за средой и обеспечения того, чтобы при масштабировании поддерживались стандарты безопасности и отказоустойчивости, — говорит Хантер. — Я думаю, что переосмысление степени автоматизации в управлении ИТ и приложениями не произойдет до тех пор, пока эти процессы не сломаются. Возможно, инвестирование здесь происходит недостаточно быстро, чтобы обеспечить способность масштабироваться».
3. Архитектуры
Стремясь быстро выйти на рынок, стартапы могут поддаться искушению построить новый сервис из уже готовых компонентов, которые можно соединить между собой так, чтобы они «более-менее подходили», но демонстрировали бизнес-идею. Это может привести к созданию непреднамеренно сложных систем, которые невозможно масштабировать. Хотя такой подход может хорошо работать на начальном этапе, позже получить одобрение бизнеса на полную перестройку работающего сервиса, который демонстрирует признаки успеха, может быть очень сложно.
«Прежде всего, будьте очень осторожны на этапе разработки архитектурного решения, потому что сложность убивает. Это не только аргумент в пользу надежности или безопасности, но и в пользу масштабируемости, — говорит Якоб Эстергаард, технический директор облачной платформы резервного копирования и восстановления Keepit. — Сложная структура легко порождает ситуации, когда нельзя просто „залить проблему железом“, что может привести к разочарованию как со стороны бизнеса, так и со стороны инженеров».
Он советует начинать с критического мышления, понимая, что предварительные инвестиции в хорошую архитектуру многократно окупятся.
4. Видимость данных
Организации постоянно стремятся монетизировать данные. Для этого им необходимо активно управлять этими данными на протяжении всего жизненного цикла в масштабе.
«Несмотря на то что облачные вычисления приобрели популярность за последние несколько десятилетий, в них до сих пор много путаницы, что приводит к проблемам, в том числе к отсутствию понимания того, где находятся ваши облачные данные, что они содержат и как обеспечить их надлежащую защиту, — говорит Арвинд Нитракашьяп, соучредитель и технический директор компании Rubrik, специализирующейся на защите данных. — Когда речь идет о масштабируемости, одним из „слепых пятен“ являются неструктурированные и полуструктурированные данные».
Неструктурированные данные представляют собой угрозу безопасности, поскольку они могут содержать конфиденциальные бизнес-данные или персональную информацию. А поскольку все неструктурированные данные передаются конечным пользователям с помощью стандартных протоколов по сетям TCP/IP, они являются главной мишенью для злоумышленников. Поскольку большинство компаний внедряют гибридные и мультиоблачные системы, ИТ-специалистам необходимо понимать, где находятся конфиденциальные данные, куда они направляются и как обеспечивается их защита.
«Одна из самых сложных задач для организаций, чей портфель неструктурированных данных включает миллиарды файлов и/или петабайты данных, — это ведение точного, актуального учета этих наборов данных и моделей их использования, — говорит Нитракашьяп. — Нужно знать такие вещи, как количество файлов, их местонахождение, возраст и то, активно ли они еще используются. Без надежной и актуальной информации обо всем спектре критически важных бизнес-файлов ваша организация может быть просто ошеломлена масштабами ваших данных, не зная, где находятся критически важные наборы данных, какие наборы данных продолжают расти и какие наборы данных вышли из употребления».
5. API для SaaS-сервисов
API — это клей, скрепляющий наш современный мир, основанный на ПО. По словам Эстергаарда, его компания сталкивается с узкими местами в API, предлагаемых поставщиками SaaS для общего пользования, — от явного дросселирования до медленных ответов и откровенных периодических сбоев. Для более качественной и тесной интеграции между системами API должны масштабироваться до больших объемов использования.
«По сути, API, который не масштабируется, не имеет смысла, — говорит он. — Чтобы API были полезными, необходимо, чтобы их можно было использовать. Не понемногу, не иногда, а постоянно и столько, сколько нам нужно. Иначе в чем смысл?».
Хотя бывает трудно определить ограничивающий фактор, некоторые сервисы, если судить по опыту пользователей, построены на архитектуре, которую вендору сложно масштабировать до больших объемов использования.
«Это классическая проблема в информатике — если сервис построен, например, на основе центральной базы данных, то добавление большего количества внешних узлов API может ничего не дать для улучшения масштабируемости API, потому что узкое место может находиться в этой базе, — говорит Эстергаард. — Если система построена так, что центральная база данных является ядром ее функциональности, то замена этого центрального компонента на что-то, что лучше распределено по многим системам, может потребовать полного переписывания сервиса с нуля. С практической точки зрения масштабирование сервиса до больших объемов использования часто отличается от простого нажатия кнопки „эластичное масштабирование“ на облачной платформе, на которой он работает».
Чтобы масштабировать решение, оно должно быть построено на «максимально простой» архитектуре, поскольку именно сложность архитектуры обычно является основным препятствием. Сложная архитектура может сделать неэффективным добавление аппаратного обеспечения в решение.
6. Искусственный интеллект
По мере ускорения использования ИИ масштабируемость облачных вычислений и кибербезопасности становится еще более важной.
«Большинство компаний все еще находятся на стадии открытия ИИ, поэтому им до конца не ясно, что нужно для его масштабирования с точки зрения возможностей, затрат и т. д. Для того чтобы правильно расставить приоритеты, необходим подход, основанный на постоянном обучении и экспериментах и ориентированный на конечные результаты», — говорит Орла Дейли, CIO компании Skillsoft, специализирующейся на цифровой трансформации рабочей силы.
ИТ-руководители должны согласовывать с бизнес-лидерами желаемые результаты и критические факторы успеха. Им также необходимо понять, какими навыками и ресурсами располагает организация, определить KPI и заполнить ключевые пробелы.
«Команды, которые не занимаются активным управлением потребностью в масштабировании, могут столкнуться с неоптимальными решениями и непомерными затратами, с одной стороны, или с отсутствием прогресса, поскольку не определены факторы, способствующие масштабированию, и пути к нему, — говорит Дейли. — Масштабирование технологий в конечном счете направлено на достижение бизнес-результатов, поэтому важно продолжать увязывать инициативы с приоритетами компании. Легко увлечься новыми и захватывающими возможностями, и инновации по-прежнему важны, но когда дело доходит до масштабирования, важнее использовать продуманный и взвешенный подход».
7. Генеративный ИИ
Организации испытывают трудности с экономически эффективным масштабированием генеративного ИИ (GenAI). Большинство поставщиков выставляют счета за свои модели на основе токенов — числовых представлений слов или символов. Стоимость входных и выходных токенов различна. Например, модель Claude 3.5 Sonnet от Anthropic стоит 3 долл. за миллион входных токенов и 15 долл. за миллион выходных, а модель gpt-4o от OpenAI — 2,5 долл. и 10 долл. соответственно. Эти две модели не равны и поддерживают разные функции, поэтому выбор не сводится к тому, какая модель дешевле.
«Потребители моделей GenAI должны найти баланс между ценой, возможностями и производительностью. Все хотят получить токены высочайшего качества по минимальной цене и как можно быстрее», — говорит Рэндалл Хант, технический директор облачного провайдера Caylent.
Дополнительная плата взимается за «векторизацию» данных, например за преобразование изображений, текста или другой информации в числовой формат, называемый вложением, который отражает семантическое значение базовых данных, а не их конкретное содержание.
«Модели, оперирующие вложениями, обычно дешевле, чем большие языковые модели (LLM). Например, модель Cohere стоит 0,1 долл. за миллион лексем. Поиск по вложениям может быть вполне эффективным благодаря использованию таких методов, как поиск ближайших соседей на основе графов (HNSW) и косинусное сходство, но это требует использования расширений базы данных или специализированных хранилищ данных, оптимизированных для такого рода поиска, что еще больше увеличивает стоимость. Все эти затраты вызывают привыкание, и это может повлиять на экономичность различных проектов ИИ».
8. Данные об операционных технологиях
Компании наводнены данными. Это касается большинства организаций, но особенно актуально для промышленных компаний, которые постоянно собирают данные об операционных технологиях (OT) от оборудования, датчиков, машин и т. д. Промышленные компании стремятся интегрировать ОТ- и ИТ-данные, чтобы принимать решения, основываясь на целостном видении бизнеса.
«В
По его словам, без ткани (fabric) OT-данных организации, имеющей 100 источников данных и 100 программ, использующих эти источники, придется написать и поддерживать 10 000 соединений «точка-точка». При ее наличии это число сокращается до 200 соединений. Кроме того, многие из этих соединений будут основаны на одном и том же драйвере, а значит, их будет гораздо проще поддерживать и защищать.
