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

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

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

Виды масштабирования

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

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

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

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

Горизонтальное масштабирование серверов осуществляется на двух уровнях:

  1. Разбиение системы на более мелкие структурные компоненты по функциям и разнесение их по отдельным серверам.
  2. Масштабирование в рамках функции:
    • увеличение количества серверов, параллельно выполняющих одну и ту же функцию;
    • использование современных технологий. Например, при масштабировании сервера баз данных (БД) используется репликация, партицирование и шардирование.

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

Разнесение серверов

Система SimpleOne разделена по функциям на четыре группы: клиентский сервер, сервер приложений, сервер БД и сервер файлового хранилища.

Разбиение системы SimpleOne по функциям

Клиентский сервер

Клиентский сервер отвечает за первичную коммуникацию пользователя с приложением. Этот сервер позволяет запустить приложение, загружая необходимый для работы код: CSS, JS, ReactJS, ConfigJS.

Сервер приложений

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

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

Сервер БД обслуживает и управляет БД, отвечает за целостность и сохранность данных.

Сервер БД является «узким» местом производительности. Чтобы снизить нагрузку на него, в SimpleOne файлы хранятся на отдельном сервере.

Сервер файлового хранилища

Файлы хранятся в хранилище, доступном по протоколу S3.

Amazon Simple Storage Service (Amazon S3) — это сервис хранения объектов, предлагаемый поставщиками облачных услуг. Основное преимущество решения — возможность хранить файлы любого типа, любого объёма, с высоким уровнем надёжности и доступности.

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

В основном компании-разработчики не выносят объёмные файлы (видео, картинки и т. д) на отдельный сервер, а хранят их на сервере баз данных. Разнесение хранения данных и файлов по разным серверам даёт преимущества:

  • Снижение нагрузки на сервер баз данных.
  • Файловое хранилище позволяет работать с файлами даже при масштабировании сервера приложений. За счёт использования токенов загрузка файлов на клиенте не приводит к существенному росту нагрузки на сервер приложений.

Заключение

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

Горизонтальное и вертикальное масштабирование в ЛЕТОГРАФ

Возможность масштабирования информационной системы – как горизонтальное , так и вертикальное  – является одним из самых важных факторов, на которые стоит обращать при выборе средства автоматизации деятельности любой организации. Если выбранное решение невозможно будет масштабировать, или каждая стадия роста бизнеса будет приводить к сложностям с сопровождением и развитием такого программного продукта, то не следует даже начинать его использовать. Мы разрабатывали СЭД ЛЕТОГРАФ с учетом высоких требований к масштабированию.

Необходимость в горизонтальном или вертикальном масштабировании возникает в связи с созданием корпоративных высоконагруженных  ИТ-систем, в которых работают тысячи или даже десятки тысяч пользователей. Однако поддерживать одновременную работу большого числа пользователей могут далеко не все СЭД. Только если в СЭД на уровне архитектуры заложены возможности по наращиванию количества пользователей без потери производительности – только в этом случае масштабирование будет успешным. Созданная нами система ЛЕТОГРАФ была разработана таким образом, чтобы идеально масштабироваться как горизонтально, так и вертикально. Это достигается как за счет архитектуры самой системы и того прикладного кода, который мы разработали, так и за счет функционала СУБД InterSystems Caché, на которой наша СЭД построена.

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

При этом аппаратные требования системы остаются довольно скромными.

СУБД Caché сохраняет высокую производительность даже при работе с огромными массивами данных и большим числом серверов в распределенных системах. При этом доступ к данным осуществляется через объекты, высокопроизводительные SQL-запросы и путем прямой обработки многомерных структур данных.

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

Вертикальное масштабирование предполагает наращивание мощности сервера и его возможностей, связанных с дисковой подсистемой. ЛЕТОГРАФ поддерживает современную процессорную архитектуру, что позволяет обрабатывать большие объемы данных в несколько потоков. При этом сами данные в СЭД организованы таким образом, чтобы их можно было легко разносить по СХД  на разные диски. Такой подход позволяет равномерно распределить нагрузку на хранилища данных и минимизировать ее при чтении данных непосредственно из базы, а значит и падения производительности системы удастся избежать даже при одновременной работе большого количества пользователей.

Еще на этапе разработки платформы мы понимали, что вертикальное масштабирование – одна из ключевых возможностей системы, потребность в которой со временем будет только увеличиваться. Мы разработали систему таким образом, чтобы процессы работы каждого пользователя были выделены в отдельные системные процессы, которые между собой не пересекаются благодаря тому, что базы данных эффективно делят доступ к информации. При этом количество блокировок данных в СЭД ЛЕТОГРАФ минимизировано и нет «узкого горла» ни при чтении данных, ни при их записи.

Архитектура СЭД ЛЕТОГРАФ позволяет распределять данные на несколько физических или виртуальных серверов. Благодаря такому распределению каждый из пользователей работает в изолированном процессе, а требуемые данные эффективно кэшируются с использованием технологий СУБД Caché. Время блокировки данных минимизировано: все транзакции выстроены таким образом, чтобы переводить данные в эксклюзивный режим доступа лишь на очень короткое время. При этом даже такие высоконагруженные с точки зрения количества обращений к диску данные, как журналы, индексы, данные объектов, потоки, логи действий пользователей, распределены таким образом, что средняя нагрузка на подсистему остается равномерной и не приводит к задержкам.

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

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

Горизонтальное масштабирование – это распределение сессий пользователей по разным серверам (равномерная загрузка серверов приложений и возможность подключать дополнительные сервера приложений), а также распределение данных по разным серверам БД, что обеспечивает высокую производительность системы, при этом не приводя к снижению отказоустойчивости. Для горизонтального масштабирования в системе ЛЕТОГРАФ предусмотрен целый ряд возможностей.

Прежде всего, это масштабирование нагрузки благодаря Enterprise Cache Protocol (ECP, протокол распределенного кэша), протоколу, используемому в СУБД InterSystems Caché. Преимущество ECP заключается в инновационном подходе к кэшированию данных. В рамках данного протокола пользовательские процессы, которые работают на серверах приложений (или ECP-клиентах) СУБД и обслуживают запросы, получают доступ к локальному кэшу недавно использованных данных.

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

Фактически использование технологий СУБД Caché позволяет легко и быстро масштабировать нагрузку по серверам приложений, обеспечив таким образом подключение большого числа пользователей к одному серверу базы данных благодаря использованию ECP-протокола.

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

Технологическая особенность СУБД Caché заключается в том, что она поддерживает корректность транзакций в рамках одного ECP-сервера вне зависимости от количества ECP-клиентов, которые к ней подключены. В случае, когда у нас один ECP-сервер и множество ECP-клиентов, эта задача великолепно решается, потому что все транзакции идут на одном сервере базы данных. 

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

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

В СЭД ЛЕТОГРАФ реализован механизм шардинга , благодаря которому мы на уровне настроек системы (без применения программирования), даем возможность описать правила и принципы разнесения самих данных по разным серверам БД. Несмотря на то, что с точки зрения структуры баз данных информация, хранящаяся на каждом сервере одинакова, сама информация отличается принципиально в зависимости от организации или каких-либо других признаков, которые являются значимыми для конкретной задачи. Используя технологию шардинга можно добиться, что в 95-99 % случаев пользователи будут работать только со своей «порцией данных», и не потребуется в рамках сессии обращаться к разным серверам БД.

На возможности масштабирования СЭД ЛЕТОГРАФ влияет и то, данные могут по разному обрабатываться. Например, в документы (даже созданные несколько лет назад) могут вноситься изменения, а в журнал действий пользователей записи только добавляются (ни одна запись не может быть ни удалена, ни изменена). Механизмы, которые используются в СЭД ЛЕТОГРАФ, позволяют дополнительно повысить производительность системы и улучшить масштабирование за счет ведения таких журналов на отдельных серверах БД – причем, как в случае односерверной, так и многосерверной конфигурации. Такой подход ориентирован на снижение нагрузки на основные сервера БД. 

Аналогичная ситуация возникает и контентом (“информационным содержанием” СЭД). Так как система ЛЕТОГРАФ работает с большим объемом контента – это терабайты данных, миллионы файлов и документов – разумно предположить, что контент, который попадает в систему, ни при каких условиях не должен пострадать. Поэтому мы также выносим хранение файлов на отдельные сервера баз данных и обеспечиваем таким образом дополнительно горизонтальное масштабирование. 

Программное обеспечение фронт-энда

В качестве фронт-энда в СЭД ЛЕТОГРАФ используются Apache и HAProxy. HAProxy отвечает за балансировку нагрузки между веб-серверами Apache. HAProxy, как показал опыт работы системы, зарекомендовал себя как наиболее эффективное решение, способное обеспечить поддержку работы большого числа пользователей и необходимый контроль за отказоустойчивостью.

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

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

Пример реализации проекта

Архитектура ЛЕТОГРАФ позволяет добиться существенных результатов в сокращении времени отклика и повышении производительности системы. В рамках одного из наших проектов в СЭД хранится 23,5 Тбайт данных. Из них 14,7 Тбайт (63%) приходится на потоки (“прикрепленные к карточкам файлы”), 3,5 Тбайт (15%) – на отчетные формы, такие как таблицы отчетов, которые формируются в асинхронном режиме, могут запускаться как по расписанию, так и по требованию пользователя и представляют собой сводную таблицу, любые данные в которой можно детализировать до объекта. Еще 1,6 Тбайт (7%) – это протокол пользовательских операций, а все остальное (16%) – данные карточек и индексы.

В данной системе работает более 11 тыс. пользователей, 2 тыс. из них работают одновременно, а в дни пиковой нагрузки число одновременно работающих в СЭД сотрудников превышает 3 тыс. Количество записей в журнале уже превысило 5,5 млрд, а учетных карточек – почти достигло полумиллиарда.

В качестве сервера базы данных в данном проекте установлен отказоустойчивый кластер из двух физических серверов с тремя инсталляциями СУБД, а также резервный сервер. Десять серверов приложений (и один резервный) обрабатывают пользовательские сессии и обеспечивают формирование асинхронных отчетов. 2 сервера HAProxy выполняют функции балансировщиков. В случае проблем с одним из серверов, выполняется автоматическая передача его IP-адреса на другой сервер. Также предусмотрены сервер индексации файлов и сервер распознавания (обеспечивающий распознавание текста отсканированных бумажных документов при размещении электронных образов в систему).

Резюме

В СЭД ЛЕТОГРАФ предусмотрено большое количество разнообразных механизмов масштабирования. Мы предлагаем своеобразный пирог, в основе которого лежит сервер (физический или виртуальный), на который устанавливается операционная система. Поверх нее стоит СУБД InterSystems Caché, внутри которой располагается код платформы. А уже над ним – настройки системы ЛЕТОГРАФ, благодаря которым СЭД полностью конфигурируется. И такой пирог размещен на каждом сервере. Сервера между собой связаны определенным образом за счет выбранных конфигураций. И последний слой – это HAProxy, распределяющий между серверами запросы пользователей. Такая архитектура позволяет нам поддерживать масштабирование и обеспечивать все необходимые механизмы мониторинга. В результате конечные пользователи получают быстро работающую СЭД, а ИТ-специалисты – простую в управлении и обслуживании, унифицированную систему, без огромного числа составляющих, которые в случае высоконагруженных приложений приходится постоянно контролировать и администрировать. Кроме того, в зависимости от изменения потребностей организации СЭД ЛЕТОГРАФ легко переконфигурировать, добавив новые серверы или дисковые возможности.


Данный материал является частной записью члена сообщества Club.CNews.
Редакция CNews не несет ответственности за его содержание.

6 лет назад | категории: Безопасность: Техническая защита СЭД — Системы Электронного Документооборота

Масштабирование по горизонтали и масштабирование по вертикали

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

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

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

Масштабируемость приложения можно измерить количеством запросов, которые оно может эффективно поддерживать одновременно. Точка, в которой приложение больше не может эффективно обрабатывать дополнительные запросы, является пределом его масштабируемости. Этот предел достигается, когда заканчивается критический аппаратный ресурс, требующий других или большего количества компьютеров. Масштабирование этих ресурсов может включать любую комбинацию настроек ЦП и физической памяти (другие или несколько компьютеров), жесткого диска (жесткие диски большего размера, меньше «живых» данных, твердотельные накопители) и/или пропускной способности сети (несколько контроллеров сетевых интерфейсов). , большие сетевые карты, оптоволокно и т. д.).

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

В чем основное отличие?

Горизонтальное масштабирование означает масштабирование путем добавления дополнительных машин к вашему пулу ресурсов (также называемое «масштабированием»), тогда как вертикальное масштабирование означает масштабирование путем добавления большей мощности (например, ЦП, ОЗУ) к существующей машине (также называемой « масштабирование»).

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

Горизонтальное масштабирование
(масштабирование)		 Вертикальное масштабирование
(увеличение масштаба)
Базы данных В мире баз данных горизонтальное масштабирование обычно основано на разделении данных (каждый узел содержит только часть данных). При вертикальном масштабировании данные хранятся на одном узле, а масштабирование выполняется через многоядерный, т.е. распределение нагрузки между ресурсами ЦП и ОЗУ машины.
Время простоя Теоретически, добавление большего количества компьютеров в существующий пул означает, что вы не ограничены мощностью одного устройства, что позволяет выполнять масштабирование с меньшим временем простоя. Вертикальное масштабирование ограничено мощностью одной машины, масштабирование за пределы этой емкости может привести к простою и имеет верхний жесткий предел, т. е. масштаб оборудования, на котором вы работаете в данный момент.
Параллелизм Также описывается как распределенное программирование, так как включает в себя распределение заданий между машинами по сети. Несколько шаблонов, связанных с этой моделью: Master/Worker*, Tuple Spaces, Blackboard, MapReduce. Модель актера: параллельное программирование на многоядерных машинах часто выполняется посредством многопоточности и внутрипроцессной передачи сообщений.
Передача сообщений В распределенных вычислениях отсутствие общего адресного пространства усложняет совместное использование данных. Это также делает процесс обмена, передачи или обновления данных более дорогостоящим, поскольку вам приходится передавать копии данных. В многопоточном сценарии можно предположить существование общего адресного пространства, поэтому совместное использование данных и передача сообщений могут выполняться путем передачи ссылки.
Примеры Кассандра, MongoDB, Google Cloud Spanner MySQL, Amazon RDS
* См. продолжающееся обсуждение необходимости изменения терминологии Master/Slave, что привело к ее удалению в 2018 году из языка программирования Python.

Решение о масштабировании или масштабировании

При выборе между двумя вариантами необходимо учитывать различные факторы. К ним относятся:

  • Производительность — Горизонтальное масштабирование позволяет объединить мощность нескольких машин в одну виртуальную машину с объединенной мощностью всех из них. Это означает, что вы не ограничены мощностью одного устройства. Однако сначала стоит выяснить, достаточно ли у вас ресурсов на одной машине для удовлетворения ваших потребностей в масштабируемости.
  • Гибкость — Если ваша система предназначена исключительно для масштабирования, вы фактически привязаны к минимальной цене, установленной аппаратным обеспечением, которое вы используете. Если вам нужна гибкость для выбора оптимальной настройки конфигурации в любое время для оптимизации затрат и производительности, лучшим вариантом может быть горизонтальное масштабирование.
  • Регулярность обновлений — Опять же, здесь важна гибкость. Построение приложения как единой большой единицы затруднит добавление или изменение фрагментов кода по отдельности без отключения всей системы. Чтобы обеспечить более непрерывный процесс обновления, проще отделить ваше приложение и выполнить горизонтальное масштабирование.
  • Избыточность — Горизонтальное масштабирование предлагает встроенную избыточность по сравнению с наличием только одной системы в вертикальном масштабировании и, следовательно, единой точкой отказа.
  • Географическое распределение — если вам нужно распределить приложение по географическим регионам или центрам обработки данных, чтобы уменьшить географическую задержку, соответствовать нормативным требованиям или справиться со сценариями аварийного восстановления, у вас нет возможности разместить свое приложение в одной коробке. Вы должны его раздать.
  • Стоимость — по мере того, как все больше больших многоядерных машин выходит на рынок по значительно более низким ценам, подумайте, есть ли случаи, когда ваше приложение (или части вашего приложения) можно с пользой упаковать в одну коробку, чтобы оно соответствовало вашей производительности. и цели масштабируемости. Это может привести к снижению затрат.

В заключение: плавный переход между двумя моделями?

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

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

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

Что подходит для вашего приложения?

Подумайте о долгосрочной жизнеспособности

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

Другими словами, горизонтальное масштабирование или вертикальное масштабирование – правильная стратегия для вашего бизнеса?

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

Полезная аналогия для понимания этого различия состоит в том, чтобы думать о масштабировании, как если бы оно улучшало вашу машину. Вертикальное масштабирование похоже на снятие с производства вашей Toyota и покупку Ferrari, когда вам нужно больше лошадиных сил. В своем сверхбыстром автомобиле вы можете перемещаться на высокой скорости с опущенными окнами и выглядеть потрясающе. Но, несмотря на то, что Феррари потрясающие, они не очень практичны — они дорогие, и, в конце концов, они могут довезти вас только до того момента, пока у них не кончится бензин (не говоря уже о том, что всего два места! ).

Горизонтальное масштабирование работает аналогичным образом в том смысле, что оно дает вам дополнительную мощность, но это не означает отказ от Toyota в пользу Ferrari. Вместо этого это похоже на добавление еще одного транспортного средства в автопарк. Вы можете думать о горизонтальном масштабировании как о нескольких транспортных средствах, которыми вы можете управлять одновременно. Может быть, ни одна из этих машин не является Феррари, но не , а из них должны быть: во всем автопарке у вас есть все лошадиные силы, которые вам нужны.

Почему масштабирование лучше, чем увеличение

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

В сценарии обмена Toyota на Ferrari вы заменяете более медленный сервер на более крупный и быстрый.

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

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

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

Amazon Elastic Compute Cloud (EC2), например, действует как виртуальный сервер с неограниченной емкостью. Вы выбираете процессор, емкость хранилища, сетевые параметры и операционную систему, которые вам нужны, и настраиваете свою емкость по мере роста ваших вычислительных потребностей.

При контейнеризации приложений можно использовать Amazon Elastic Container Service (ECS) или Amazon Elastic Kubernetes Service (EKS). Вы можете использовать службы оркестрации контейнеров для развертывания, управления и масштабирования приложений. Эти сервисы автоматизируют подготовку узлов, исправление и обновление, чтобы вы могли сосредоточиться на других аспектах своего приложения.

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

Если вы разрабатываете свои приложения с помощью интерфейсов прикладного программирования (API) GraphQL, AWS AppSync подключается к Lambda и другим источникам данных. AppSync автоматически масштабируется вверх и вниз в зависимости от объема запросов.

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

Другие преимущества масштабирования в облачной среде включают:

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

Как добиться эффективного горизонтального масштабирования

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

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

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

Наслаждайтесь лучшим из обоих решений

Увеличение масштаба или уменьшение масштаба не обязательно означает выбор «или-или». Пока вы разбиваете свои монолитные приложения на микросервисы, вы также можете масштабироваться, чтобы тем временем справляться с возросшей нагрузкой.

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

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

Ваше облачное приложение с автоматическим масштабированием и DevOps

Вы усердно работали над созданием своего приложения.

No related posts.