Что такое масштабируемость программного обеспечения и почему ваша компания должна относиться к этому серьезно?

Опубликовано: 2023-08-01

Даже у опытных и успешных компаний могут возникнуть проблемы с масштабируемостью. Вы помните приложение Disney Applause? Это позволило пользователям взаимодействовать с различными шоу Disney. Когда приложение появилось в Google Play, оно пользовалось огромной популярностью. Однако не так масштабируемо. Он не мог справиться с большим количеством поклонников, что приводило к ухудшению пользовательского опыта. Люди были в ярости, оставляя негативные отзывы и оценку в одну звезду в Google Play. Приложение так и не оправилось от этой негативной рекламы.

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

Итак, что такое масштабируемость в программном обеспечении? Как убедиться, что ваше решение масштабируемо? И когда нужно начинать масштабирование?

Что такое масштабируемость программного обеспечения?

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

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

Много пользователей одновременно обращаются к системе
Расширение требований к емкости хранилища
Увеличено количество обрабатываемых транзакций

Типы масштабируемости программного обеспечения

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

Горизонтальная масштабируемость программного обеспечения (масштабирование)

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

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

Преимущества:

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

Ограничения:

Добавленная сложность. Вам необходимо определить, как рабочая нагрузка распределяется между узлами. Вы можете использовать Kubernetes для управления нагрузкой
Более высокие затраты. Добавление новых узлов стоит дороже, чем обновление существующих.
Общая скорость программного обеспечения может быть ограничена скоростью связи узла.

Вертикальная масштабируемость программного обеспечения (расширение)

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

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

Преимущества:

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

Ограничения:

В процессе обновления есть время простоя
Модернизированная машина по-прежнему представляет собой единую точку отказа.
Существует ограничение на количество обновлений одного устройства.

Вертикальная и горизонтальная масштабируемость программного обеспечения

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

Когда вам абсолютно необходима масштабируемость?

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

Когда масштабируемость программного обеспечения не требуется:

Если программное обеспечение является доказательством концепции (PoC) или прототипом
При разработке внутреннего ПО для небольших компаний используется только сотрудниками
Мобильное/десктопное приложение без серверной части

В остальном настоятельно рекомендуется изучить варианты масштабируемости, чтобы быть готовыми, когда придет время. И как понять, что пора масштабироваться? Когда вы заметите снижение производительности. Вот некоторые показания:

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

Советы по созданию масштабируемого программного обеспечения

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

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

Совет № 1. Выбирайте хостинг в облаке для лучшей масштабируемости программного обеспечения.

У вас есть два варианта размещения приложений: в облаке или локально. Или вы можете использовать гибридный подход.

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

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

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

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

Совет № 2: используйте балансировку нагрузки

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

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

Совет № 3: кэшируйте как можно больше

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

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

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

Совет № 4. Включите доступ через API

Конечные пользователи будут получать доступ к вашему программному обеспечению через множество клиентов, и будет удобнее предложить интерфейс прикладного программирования (API), который каждый может использовать для подключения. API похож на посредника, который позволяет двум приложениям взаимодействовать. Убедитесь, что вы учитываете разные типы клиентов, включая смартфоны, настольные приложения и т. д.

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

Совет № 5. Получите выгоду от асинхронной обработки

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

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

Асинхронная обработка достигается на уровне кода и инфраструктуры, а асинхронная обработка запросов — на уровне кода.

Совет № 6. По возможности выбирайте типы баз данных, которые легче масштабировать

Некоторые базы данных легче масштабировать, чем другие. Например, базы данных NoSQL, такие как MongoDB, более масштабируемы, чем SQL. Вышеупомянутая MongoDB имеет открытый исходный код и обычно используется для анализа больших данных в реальном времени. Другими вариантами NoSQL являются Amazon DynamoDB и Google Bigtable.

SQL хорошо работает, когда дело доходит до масштабирования операций чтения, но останавливается при операциях записи из-за соответствия принципам ACID (атомарность, согласованность, изоляция и надежность). Итак, если эти принципы не являются основной проблемой, вы можете выбрать NoSQL для упрощения масштабирования. Если вам нужно полагаться на реляционные базы данных, для обеспечения согласованности или по другим причинам, все еще возможно масштабирование с использованием сегментирования и других методов.

Совет № 7. Выбирайте микросервисы, а не монолитную архитектуру, если это применимо

Монолитная архитектура

Монолитное программное обеспечение строится как единое целое, объединяющее клиентские и серверные операции, базу данных и т. д. Все тесно связано и имеет единую кодовую базу для всей своей функциональности. Вы не можете просто обновить одну часть, не повлияв на остальную часть приложения.

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

Архитектура микросервисов

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

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

Совет № 8. Отслеживайте производительность, чтобы определить, когда масштабировать

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

Чтобы иметь возможность выявлять эти и другие проблемы, связанные с масштабируемостью программного обеспечения, вам необходимо внедрить систему мониторинга телеметрии в свое приложение на этапе кодирования. Эта система позволит вам отслеживать:

Среднее время отклика
Пропускная способность, которая представляет собой количество запросов, обработанных в данный момент времени.
Количество одновременных пользователей
Показатели производительности базы данных, например время ответа на запрос.
Использование ресурсов, таких как ЦП, использование памяти, ГП
Частота ошибок
Стоимость на пользователя

Вы можете воспользоваться существующими решениями для мониторинга и платформами агрегации журналов, такими как Splunk. Если ваше программное обеспечение работает в облаке, вы можете использовать решение облачного поставщика. Например, Amazon предлагает для этой цели AWS CloudWatch.

Примеры масштабируемых программных решений из портфолио ITRex

Умное фитнес-зеркало с личным тренером

Описание Проекта

Клиент хотел построить настенное фитнес-зеркало в полный рост, которое помогало бы пользователям во время тренировок. Он может отслеживать форму пользователя во время тренировки, подсчитывать повторения и многое другое. Эта система должна была включать в себя программное обеспечение, позволяющее тренерам создавать и загружать видео, а пользователям записывать и управлять своими тренировками.

Что мы сделали для обеспечения масштабируемости программного обеспечения

Мы выбрали микросервисную архитектуру
Реализована горизонтальная масштабируемость для распределения нагрузки. Новый узел добавлялся всякий раз, когда на существующие оказывалась слишком большая нагрузка. Таким образом, всякий раз, когда загрузка ЦП превышала 90% его мощности и оставалась на этом уровне в течение определенного периода времени, для снижения нагрузки добавлялся новый узел.
Нам пришлось развернуть реляционные базы данных, т. е. SQL и PostgreSQL, по архитектурным причинам. Несмотря на то, что реляционные базы данных сложнее масштабировать, все же есть несколько вариантов. Вначале, поскольку пользовательская база была еще относительно небольшой, мы выбрали вертикальное масштабирование. Если аудитория росла, мы планировали внедрить подход master-slave — распределить данные по нескольким базам данных.
Кэширование значительно выиграло, поскольку эта система содержит много статической информации, такой как имена тренеров, названия тренировок и т. д.
Используется RestAPI для асинхронной обработки запросов между приложением для тренировок и сервером.
Использование бессерверной архитектуры, такой как AWS Lambda, для других типов асинхронной обработки. Одним из примеров является асинхронная обработка видео. После того, как тренер загружает новое видео тренировки и разделяет его на разные упражнения, он нажимает «сохранить», и сервер начинает обрабатывать это видео для потоковой передачи в реальном времени по HTTP, чтобы создать четыре версии исходного видео с разным разрешением. Тренер может одновременно загружать новые видео.
В другом примере система асинхронно выполняет интеллектуальную обрезку пользовательских видео, чтобы удалить все части, в которых пользователь не проявлял активности.

Система кибербезопасности на основе биометрии

Описание Проекта

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

Как мы обеспечили масштабируемость этого программного обеспечения

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

Проблемы, с которыми вы можете столкнуться при масштабировании

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

Накопленный технический долг . Заинтересованные стороны проекта могут по-прежнему пытаться отказаться от масштабируемости в пользу более низких затрат, скорости и т. д. Масштабируемость не является функциональным требованием и может быть омрачена более ощутимыми характеристиками. В результате приложение будет накапливать технические функции, которые не будут совместимы с масштабируемостью.
Масштабирование с помощью методологии разработки Agile . Методология Agile направлена на принятие изменений. Однако, когда клиент хочет слишком часто вносить слишком много изменений, масштабируемость программного обеспечения может быть отложена в сторону в угоду изменяющимся требованиям.
Тестирование масштабируемости . Трудно выполнить реалистичное нагрузочное тестирование. Допустим, вы хотите проверить, как поведет себя система, если вы увеличите размер базы данных в 10 раз. Вам нужно будет сгенерировать большой объем реалистичных данных, которые соответствуют исходным характеристикам данных, а затем сгенерировать реалистичную рабочую нагрузку как для записи, так и для чтения.
Масштабируемость сторонних сервисов . Убедитесь, что ваш сторонний поставщик услуг не ограничивает масштабируемость. При выборе технического поставщика убедитесь, что он может поддерживать предполагаемый уровень масштабируемости программного обеспечения, и правильно интегрировать свое решение.
Понимание использования вашего приложения . Вам необходимо иметь четкое представление о том, как будет работать ваше программное обеспечение и сколько людей будет его использовать, что редко возможно точно оценить.
Архитектурные ограничения . Иногда вы ограничены в своем архитектурном выборе. Например, вам может понадобиться использовать реляционную базу данных, и вам придется иметь дело с ее масштабированием как по горизонтали, так и по вертикали.
Наличие правильного таланта . Чтобы спроектировать масштабируемое решение, которое не доставит вам головной боли в будущем, вам нужен опытный архитектор, который уже работал над подобными проектами и понимает масштабируемость программного обеспечения как с точки зрения кодирования, так и с точки зрения инфраструктуры. Здесь, в ITRex Group, мы работали над многими проектами и всегда помним о масштабируемости при разработке программного обеспечения.

Подводить итоги

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

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

Планируете развертывание нового корпоративного программного обеспечения или обновление существующей системы, но опасаетесь, что она не будет соответствовать быстро растущим потребностям бизнеса? Связаться! Мы позаботимся о том, чтобы ваше программное обеспечение не только обладало всей необходимой функциональностью, но и могло масштабироваться с минимальными инвестициями и временем простоя.

Первоначально опубликовано на https://itrexgroup.com 24 июля 2023 г.