Масштабируемость системы это: Масштабируемость | это… Что такое Масштабируемость?

Масштабируемость

Масштабируемость — это способность системы адаптироваться к расширению предъявляемых требований и возрастанию объемов решаемых задач.

Работа одного прикладного решения в разных условиях

Система «1С:Предприятие 8» имеет хорошие возможности масштабирования. Она позволяет работать как в файловом варианте, так и с использованием технологии «клиент-сервер».

Персональное использование, файловый вариант работы

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

Небольшая рабочая группа, файловый вариант работы

Файловый вариант также обеспечивает возможность работы по локальной сети нескольких пользователей с одной информационной базой.

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

Крупное предприятие, клиент-серверный вариант работы

Для больших рабочих групп и в масштабах предприятия может применяться клиент-серверный вариант работы, основанный на трехуровневой архитектуре с использованием кластера серверов «1С:Предприятия 8» и отдельной системы управления базами данных. Он обеспечивает надежное хранение данных и их эффективную обработку при одновременной работе большого количества пользователей.

Холдинг, распределенная информационная база

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

Важно отметить, что одни и те же прикладные решения (конфигурации) могут использоваться как в файловом, так и в клиент-серверном варианте работы. При переходе от файлового варианта к технологии «клиент-сервер» не требуется вносить изменения в прикладное решение. Поэтому выбор варианта работы целиком зависит от потребностей заказчика и его финансовых возможностей. На начальной стадии можно работать в файловом варианте, а затем с увеличением количества пользователей и объема базы данных можно легко перейти на клиент-серверный вариант работы со своей информационной базы.

Многопользовательская работа

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

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

В модели данных, поддерживаемой системой «1С:Предприятие 8», не существует таблиц базы данных, однозначно приводящих к конкурентному доступу со стороны нескольких пользователей. Конкурентный доступ возникает только при обращении к логически связанным данным и не затрагивает данные, не связанные между собой с точки зрения предметной области.

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

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

Механизмы оптимизации

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

Управление блокировками в транзакции

Режим управляемых блокировок в транзакции позволяет управлять блокировками данных в терминах предметной области и повышает параллельность работы пользователей. Подробнее…

Выполнение на сервере

В варианте клиент-сервер использование сервера «1С:Предприятия 8» позволяет сосредоточить на нем выполнение наиболее объемных операций по обработке данных. Например, при выполнении даже весьма сложных запросов программа, работающая у пользователя, будет получать только необходимую ей выборку, а вся промежуточная обработка будет выполняться на сервере. Обычно увеличить мощность сервера гораздо проще, чем обновить весь парк клиентских машин.

Кэширование данных

Система «1С:Предприятие 8» использует механизм кэширования данных, считанных из базы данных при использовании объектной техники. При обращении к реквизиту объекта выполняется чтение всех данных объекта в кэш, расположенный в оперативной памяти. Последующие обращения к реквизитам того же объекта будут направляться уже в кэш, а не в базу данных, что значительно сокращает время, затрачиваемое на получение нужных данных.

Работа встроенного языка на сервере

При работе в клиент-серверном варианте вся работа прикладных объектов выполняется только на сервере. Функциональность форм и командного интерфейса также реализована на сервере.

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

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

Примеры технологических параметров внедрений решения «Управление производственным предприятием»

В этом разделе публикуется развернутая информация о технологических параметрах внедрений «1C:Предприятие 8. Управление производственным предприятием» на предприятиях различного масштаба и профиля деятельности.

Цель раздела — ознакомить ИТ- специалистов с данными о реально используемом оборудовании и с примерами нагрузки реальных внедрений «1С:Предприятия 8».

Также эта информация может быть полезна и для пользователей всех программ системы «1С:Предприятие 8».

1С:Центр управления производительностью — инструмент мониторинга и анализа производительности

1С:Центр управления производительностью (1С:ЦУП) — инструмент мониторинга и анализа производительности информационных систем на платформе «1С:Предприятие 8». 1С:ЦУП предназначен для оценки производительности системы, сбора подробной технической информации об имеющихся проблемах производительности и анализа этой информации с целью дальнейшей оптимизации. Подробнее…

1С:ТестЦентр — инструмент автоматизации нагрузочных испытаний

1С:ТестЦентр — инструмент автоматизации многопользовательских нагрузочных испытаний информационных систем на платформе «1С:Предприятие 8». С его помощью можно моделировать работу предприятия без участия реальных пользователей, что позволяет оценивать применимость, производительность и масштабируемость информационной системы в реальных условиях. Подробнее…

Внедрение корпоративных информационных систем на платформе «1С:Предприятие 8»

Опыт внедрения прикладных решений на платформе «1С:Предприятие 8» показывает, что система позволяет решать задачи различной степени сложности — от автоматизации одного рабочего места до создания информационных систем масштаба предприятия.

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

База знаний по технологическим вопросам крупных внедрений

Фирма «1С», совместно с сертифицированными «1С:Экспертами по технологическим вопросам» и другими техническими специалистами, ведет и регулярно обновляет базу знаний по технологическим вопросам крупных внедрений.

База знаний — это постоянно пополняемый информационный ресурс, который является основным источником информации по технологическим вопросам крупных внедрений:

• Методики и технологии, ориентированные на повышение качества крупных внедрений
• Технологические проблемы крупных внедрений и способы их решения

Подробнее…

Масштабируемые системы 101

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

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

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

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

Содержание

1. Что такое масштабируемость?
2. Задержка против пропускной способности против пропускной способности
3. Когда важна масштабируемость?
4. Механизмы достижения масштабируемости
5. Вертикальное масштабирование (увеличение)
6. Горизонтальное масштабирование (масштабирование)
7. Размеры масштабируемости
8. Выявление узких мест в производительности
9. Монолитная база данных
10. Неправильный тип базы данных
11. Архитектурные ошибки
12. Отсутствие кэширования
13. Нет балансировщиков нагрузки
14. Плохо написанный код
15. Тестирование производительности вашего приложения
16. Тестирование масштабируемости вашего приложения
17. Заключение

Что такое масштабируемость?

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

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

Задержка против пропускной способности против пропускной способности

Задержка — это время, необходимое системе для ответа на запрос пользователя.

Существует два основных типа задержки: Сетевая задержка — это время, необходимое сети для отправки пакета данных из точки А в точку Б. Задержка приложения — это время, необходимое приложению для обработки запроса пользователя.

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

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

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

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

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

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

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

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

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

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

Механизмы достижения масштабируемости

Существует два способа масштабирования приложения: по вертикали и по горизонтали.

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

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

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

То же правило действует, если на сервере с 16 гигабайтами ОЗУ размещается приложение, которое видит взрыв трафика. Одним из способов размещения этого дополнительного трафика было бы увеличение оперативной памяти до 32 гигабайт.

Вертикальное масштабирование

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

Вернемся к аналогии с нашей квартирой. В вашем высотном многоквартирном доме могут с комфортом разместиться 10 000 жильцов. Для вашего следующего проекта вас попросят построить высотное здание, способное вместить 1 000 000 арендаторов.

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

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

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

Преимущества	Ограничения
Легкий и несложный (как с административной точки зрения, так и с точки зрения разработки программного обеспечения)	Технологические ограничения препятствуют бесконечному вертикальному масштабированию
Не нужно рефакторить код	Значительно дороже купить современное оборудование
Нет необходимости менять реализацию	Может не отвечать на одновременные запросы

Горизонтальное масштабирование (масштабирование)

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

Горизонтальное масштабирование

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

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

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

Размеры масштабируемости

Существует несколько способов измерения масштабируемости, но все показатели будут измерять степень удовлетворенности от предоставления того или иного нового сервиса.

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

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

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

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

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

Выявление узких мест в производительности

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

Монолитная база данных

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

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

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

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

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

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

Неправильный тип базы данных

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

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

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

Архитектурные ошибки

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

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

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

Отсутствие кэширования

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

Исходные серверы содержат исходную версию вашего веб-сайта, которая кэшируется серверами на периферии. CDN могут кэшировать и сжимать точные копии ваших веб-страниц, чтобы уменьшить время приема-передачи (RTT) и задержку.

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

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

Нет балансировщиков нагрузки

Балансировщики нагрузки используют несколько алгоритмов для равномерного распределения интенсивного трафика между несколькими серверами.

Вот некоторые алгоритмы, используемые для балансировки нагрузки:

• Наименьшее время отклика : этот алгоритм направляет трафик на сервер с наименьшим количеством активных подключений и наименьшей задержкой.
• Round Robin : этот алгоритм чередует серверы в очереди. Трафик распределяется по очереди в зависимости от того, какой сервер стоит следующим в очереди.
• IP-хеш : IP-адрес клиента определяет, какой сервер получает его запросы.

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

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

Плохо написанный код

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

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

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

Неиспользование нотации Big O также может повредить масштабируемости вашего приложения. Big O измеряет сложность алгоритма по двум измерениям: времени (сколько времени требуется для выполнения функции) и пространству (сколько памяти требуется для выполнения функции).

Тестирование производительности вашего приложения

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

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

Тестирование масштабируемости вашего приложения

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

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

Параметры для рассмотрения:

• Использование процессора
• Потребление пропускной способности сети
• Пропускная способность
• Количество запросов, обработанных в течение x времени
• Задержка
• Использование памяти приложением
• UX во время интенсивного трафика

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

Заключение

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

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

Определение масштабируемости — Глоссарий информационных технологий Gartner

Определение масштабируемости — Глоссарий информационных технологий Gartner

• Клиент Gartner? Журнал в для персонализированных результатов поиска.

Информационные технологии

Глоссарий Gartner Глоссарий информационных технологий С Масштабируемость

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

Стать клиентом

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

Или позвоните нам

8:00 – 19:00 ET
8:00 – 17:00 время по Гринвичу
с понедельника по пятницу

Рабочий адрес электронной почты Имя Фамилия Телефон Тип человека

Должность Название компании Функция работы Аудит и рискОбслуживание и поддержка клиентовФинансыТехнология/поставщики услугКадрыСпециалист по информационным технологиямСпециалист по инвестициямПравовые вопросы и соответствие нормативным требованиямМаркетинг и коммуникацииМаркетинг у поставщика технологий/услугЗакупкиИсследования и разработкиПродажиЦепочка поставокСтрана

Пожалуйста, предоставьте согласие ниже

Я прочитал, понял и принял Gartner Отдельное письмо-согласие , тем самым я соглашаюсь (1) предоставить Gartner мою личную информацию и понимаю, что информация будет передаваться за пределы материкового Китая и обрабатываться компаниями группы Gartner и другими законными обрабатывающими сторонами, и (2) группа Gartner свяжется со мной компаний через Интернет, мобильный телефон/телефон и электронную почту в целях продаж, маркетинга и исследований.

Нажимая кнопку «», вы соглашаетесь с Условия использования Gartner и Политика конфиденциальности.

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

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

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

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

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

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

Что такое шаблон масштабируемости?

Вы когда-нибудь играли с кубиками LEGO®? Может быть, вы пытались построить конструкцию, не следуя инструкциям, только для того, чтобы она рухнула? Но когда вы следовали тщательно проиллюстрированным инструкциям, у вас получалась прочная конструкция, которая разрушилась бы, только если бы вы намеренно раздвинули кирпичи. Методы строительства, показанные в инструкциях, были протестированы и доказали свою эффективность в решении общих структурных проблем, с которыми сталкиваются многие строители.

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

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

Какие существуют общие шаблоны масштабируемости?

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

Масштабный куб AKF

Это трехмерная модель, определяющая три подхода к масштабированию по осям X, Y и Z.

Масштабирование по оси X

Ось X описывает масштабирование через несколько экземпляров одного и того же компонента. Вы делаете это путем клонирования или репликации службы, приложения или набора данных за балансировщиком нагрузки. Итак, если у вас N клонов запущенного приложения, каждый экземпляр обрабатывает 1/ N нагрузки.

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

Масштабирование по оси Y

Масштабирование по оси Y определяется разделением или сегментацией разнородных компонентов на несколько макро- или микросервисов по границам глаголов или существительных. Например, сегмент на основе глагола может определять такую ​​услугу, как проверка. Сегмент, основанный на существительном, может описывать корзину.

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

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

Масштаб по оси Z

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

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

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

Горизонтальные и вертикальные шаблоны масштабируемости

Масштабирование можно увеличивать (по вертикали) или уменьшать (по горизонтали).

Вертикальное масштабирование

Вертикальное масштабирование — это увеличение возможностей компонента, например сервера, для повышения его производительности. Например, чем больше трафика попадает на ваш сервер, тем ниже его производительность. Добавление большего количества ОЗУ и накопителей повышает производительность сервера, поэтому он может легче справляться с возросшим трафиком.

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

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

Горизонтальное масштабирование

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

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

Балансировка нагрузки

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

В задачи балансировщика нагрузки входят:

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

Общие методы (алгоритмы) балансировки нагрузки включают:

• Метод наименьшего количества соединений : Трафик направляется на сервер с наименьшим числом активных соединений.
• Метод наименьшего времени отклика : Балансировщик нагрузки измеряет количество времени, которое требуется серверу для ответа на запрос мониторинга работоспособности. Трафик отправляется на самый работоспособный сервер с наименьшим временем отклика. Некоторые балансировщики нагрузки будут учитывать активные соединения с этим алгоритмом.
• Метод циклического перебора : Трафик отправляется на первый доступный сервер независимо от его текущей рабочей нагрузки и активных подключений. После того, как этот сервер получает и обрабатывает запрос, балансировщик нагрузки перемещает его в конец очереди. Риск заключается в том, что сервер, который получает запросы с интенсивным использованием процессора, может все еще усердно работать над предыдущими запросами, когда он снова достигает вершины очереди.
• Методы хеширования : Решение о том, какой сервер получит запрос, зависит от хэша данных из входящего пакета. Эти данные могут включать такую ​​информацию, как IP-адрес, номер порта или доменное имя.

Сети кэширования и доставки контента (CDN)

CDN — это глобальная сеть серверов, которые используются для оптимизации и ускорения доступа к статическим веб-ресурсам и их распространения. Статические свойства — это такие вещи, как Javascript, CSS, изображения и другие медиафайлы, которые меняются не очень часто.

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

Микросервисы

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

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

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

Разделение

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

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

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

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

  No related posts.