Масштабирование приложений: Масштабирование нагрузки web-приложений / Хабр

Масштабирование нагрузки web-приложений / Хабр

С ростом популярности web-приложения его поддержка неизбежно начинает требовать всё больших и больших ресурсов. Первое время с нагрузкой можно (и, несомненно, нужно) бороться путём оптимизации алгоритмов и/или архитектуры самого приложения. Однако, что делать, если всё, что можно было оптимизировать, уже оптимизировано, а приложение всё равно не справляется с нагрузкой?

Оптимизация

Первым делом стоит сесть и подумать, а всё ли вам уже удалось оптимизировать:

• оптимальны ли запросы к БД (анализ EXPLAIN, использование индексов)?
• правильно ли хранятся данные (SQL vs NoSQL)?
• используется ли кеширование?
• нет ли излишних запросов к ФС или БД?
• оптимальны ли алгоритмы обработки данных?
• оптимальны ли настройки окружения: Apache/Nginx, MySQL/PostgreSQL, PHP/Python?

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

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

И так, допустим, что оптимизация уже проведена, но приложение всё равно не справляется с нагрузкой. В таком случае решением проблемы, очевидно, может послужить разнесение его по нескольким хостам, с целью увеличения общей производительности приложения за счёт увеличения доступных ресурсов. Такой подход имеет официальное название – «масштабирование» (scale) приложения. Точнее говоря, под «масштабируемостью» (scalability) называется возможность системы увеличивать свою производительность при увеличении количества выделяемых ей ресурсов. Различают два способа масштабирования: вертикальное и горизонтальное. Вертикальное масштабирование подразумевает увеличение производительности приложения при добавлении ресурсов (процессора, памяти, диска) в рамках одного узла (хоста).

Горизонтальное масштабирование характерно для распределённых приложений и подразумевает рост производительности приложения при добавлении ещё одного узла (хоста).

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

Архитектура приложения

Большинство web-приложений априори являются распределёнными, так как в их архитектуре можно выделить минимум три слоя: web-сервер, бизнес-логика (приложение), данные (БД, статика).

Каждый их этих слоёв может быть масштабирован. Поэтому если в вашей системе приложение и БД живут на одном хосте – первым шагом, несомненно, должно стать разнесение их по разным хостам.

Узкое место

Приступая к масштабированию системы, первым делом стоит определить, какой из слоёв является «узким местом» — то есть работает медленнее остальной системы. Для начала можно воспользоваться банальными утилитами типа top (htop) для оценки потребления процессора/памяти и df, iostat для оценки потребления диска. Однако, желательно выделить отдельный хост, с эмуляцией боевой нагрузки (c помощью AB или JMeter), на котором можно будет профилировать работу приложения с помощью таких утилит как xdebug, oprofile и так далее. Для выявления узких запросов к БД можно воспользоваться утилитами типа pgFouine (понятно, что делать это лучше на основе логов с боевого сервера).

Обычно всё зависит от архитектуры приложения, но наиболее вероятными кандидатами на «узкое место» в общем случае являются БД и код. Если ваше приложение работает с большим объёмом пользовательских данных, то «узким местом», соответственно, скорее всего будет хранение статики.

Масштабирование БД

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

Снизить нагрузку на БД можно разнеся её на несколько хостов. При этом остро встаёт проблема синхронизации между ними, решить которую можно путём реализации схемы master/slave с синхронной или асинхронной репликацией. В случае с PostgreSQL реализовать синхронную репликацию можно с помощью Slony-I, асинхронную – PgPool-II или WAL (9.0). Решить проблему разделения запросов чтения и записи, а так же балансировки нагрузку между имеющимися slave’ами, можно с помощью настройки специального слоя доступа к БД (PgPool-II).

Проблему хранения большого объёма данных в случае использования реляционных СУБД можно решить с помощью механизма партицирования (“partitioning” в PostgreSQL), либо разворачивая БД на распределённых ФС типа Hadoop DFS.

Об обоих решениях можно почитать в замечательной книге по настройке PostgreSQL.

Однако, для хранения больших объёмов данных лучшим решением будет «шардинг» (sharding) данных, который является встроенным преимуществом большинства NoSQL БД (например, MongoDB).

Кроме того, NoSQL БД в общем работают быстрее своих SQL-братьев за счёт отсутствия overhead’а на разбор/оптимизацию запроса, проверки целостности структуры данных и т.д. Тема сравнения реляционных и NoSQL БД так же довольно обширна и заслуживает отдельной статьи.

Отдельно стоит отметить опыт Facebook, который используют MySQL без JOIN-выборок. Такая стратегия позволяет им значительно легче масштабировать БД, перенося при этом нагрузку с БД на код, который, как будет описано ниже, масштабируется проще БД.

Масштабирование кода

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

Далее необходимо настроить балансировку нагрузки/запросов между этими хостами. Сделать это можно как на уровне TCP (haproxy), так и на HTTP (nginx) или DNS.

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

Файлы статики можно смонтировать с некого общего файлового хранилища по NFS/CIFS или использовать распределённую ФС (HDFS, GlusterFS, Ceph).

Так же можно хранить файлы в БД (например, Mongo GridFS), решая тем самым проблемы доступности и масштабируемости (с учётом того, что для NoSQL БД проблема масштабируемости решена за счёт шардинга).

Отдельно стоит отметить проблему деплоймента на несколько хостов. Как сделать так, что бы пользователь, нажимая «Обновить», не видел разные версии приложения? Самым простым решением, на мой взгляд, будет исключение из конфига балансировщика нагрузки (web-сервера) не обновлённых хостов, и последовательного их включения по мере обновления.

Так же можно привязать пользователей к конкретным хостам по cookie или IP. Если же обновление требует значимых изменений в БД, проще всего, вообще временно закрыть проект.

Масштабирование ФС

При необходимости хранения большого объёма статики можно выделить две проблемы: нехватка места и скорость доступа к данным. Как уже было написано выше, проблему с нехваткой места можно решить как минимум тремя путями: распределённая ФС, хранение данных в БД с поддержкой шардинга и организация шардинга «вручную» на уровне кода.

При этом стоит понимать, что раздача статики тоже не самая простая задача, когда речь идёт о высоких нагрузках. Поэтому в вполне резонно иметь множество серверов предназначенных для раздачи статики. При этом, если мы имеем общее хранилище данных (распределённая ФС или БД), при сохранении файла мы можем сохранять его имя без учёта хоста, а имя хоста подставлять случайным образом при формировании страницы (случайным образом балансирую нагрузку между web-серверами, раздающими статику).

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

Мониторинг

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

Заключение

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

Оптимизация приложений | Масштабирование приложений ASP.NET

87

C# и .NET Framework — Оптимизация приложений .NET Framework — Масштабирование приложений ASP.NET

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

Далее вы развертываете приложение, вводите его в эксплуатацию и оно работает замечательно в течение нескольких первых недель, но с увеличением количества пользователей увеличивается и количество запросов, которые требуется обработать вашему серверу, и вдруг, ваш сервер начинает захлебываться. Сначала это может проявляться в увеличении времени обработки запросов, затем рабочий процесс начинает использовать все больше памяти и вычислительных ресурсов и в конечном итоге веб сервер просто перестает успевать обрабатывать все запросы и в файлах журналов начинают все чаще появляться сообщения HTTP 500 («Internal Server Error»).

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

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

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

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

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

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

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

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

Механизмы масштабирования в ASP.NET

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

Служба управления состоянием (State Service)

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

SQL Server

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

Для нужд кеширования в большинстве случаев можно с успехом использовать один из механизмов распределенного кеширования, таких как Microsoft AppFabric Cache, NCache или Memcached, последний из которых является открытой реализацией распределенного кеша.

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

Некоторые распределенные кеши, такие как AppFabric Cache и Memcached, также имеют собственные реализации службы управления состоянием и провайдеров кеша для ASP.NET.

Ловушки горизонтального масштабирования

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

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

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

Управлять генерацией этих ключей в ASP.NET можно путем настройки параметров в разделе machineKey, в файле web.config. Когда веб-приложение выполняется на нескольких серверах, вам необходимо настроить все серверы так, чтобы они использовали один и тот же предварительно сгенерированный ключ.

Другой проблемой, связанной с горизонтальным масштабированием и уникальными ключами, является возможность шифрования разделов в файлах web.config. Закрытая информация в файлах web.config часто шифруется, когда приложение развертывается на серверах. Например, раздел connectionString можно зашифровать, чтобы предотвратить утечку имени пользователя и пароля к базе данных. Вместо того, чтобы шифровать файл web.config на каждом сервере отдельно, усложняя процесс развертывания, можно сгенерировать один зашифрованный файл web.config и развернуть его на всех серверах. Для этого следует создать RSA-контейнер ключей и импортировать его на все веб-серверы.

Более полную информацию о создании уникальных ключей и включения их в настройки приложений можно получить в базе знаний Microsoft Knowledge Base. За дополнительной информацией о создании RSA-контейнера ключей обращайтесь к статье «Импорт и экспорт защищенных контейнеров ключей RSA для конфигурации» на сайте MSDN.

Масштабирование контейнеров и бессерверных приложений

Twitter LinkedIn Facebook Адрес электронной почты

• Статья
• 09/22/2022
• Чтение занимает 2 мин

Совет

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

Загрузить PDF-файл

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

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

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

Бессерверные приложения масштабируемся, выбрав план Функций уровня «Премиум » или «Премиум» из выделенного плана службы приложений.

Масштабирование облачных приложений

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

Кластеры AKS могут выполнять автомасштабирование одним из двух способов:

Во-первых, средство горизонтального автомасштабирования pod отслеживает спрос на ресурсы и автоматически масштабирует реплики POD для удовлетворения его потребностей. При увеличении трафика дополнительные реплики автоматически подготавливаются для масштабирования служб. Аналогичным образом, когда спрос уменьшается, они удаляются для масштабирования служб. Вы определяете метрику, для которой требуется масштабировать, например использование ЦП. Можно также указать минимальное и максимальное количество выполняемых реплик. AKS отслеживает эти метрики и масштабирует их соответствующим образом.

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

На рисунке 3–11 показана связь между этими двумя службами масштабирования.

Рис. 3-11. Масштабирование плана Служба приложений.

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

Масштабирование Функций Azure

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

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

НазадВперед

Что такое масштабирование приложений и почему это важно

Что такое масштабирование приложений?

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

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

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

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

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

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

Сделайте ваше приложение масштабируемым

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

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

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

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

Выбор подходящей технологии

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

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

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

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

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

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

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

Тестирование масштабируемости

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

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

Тестирование производительности выполняется для наблюдения за производительностью приложения (включая стабильность, быстродействие, надежность и скорость) при определенной рабочей нагрузке.

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

Почему важна масштабируемость?

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

Улучшение взаимодействия с пользователем

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

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

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

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

Экономит деньги

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

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

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

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

Для любого опубликованного приложения (т. е. не созданного для внутренних бизнес-целей) потеря пользователей означает потерю денег.

Стабильность приложений

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

Настройка функций

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

Обеспечьте лучшую производительность приложения

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

Обработка всплесков использования

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

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

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

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

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

Положительные отзывы и отзывы пользователей

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

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

Зарабатывайте больше

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

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

Долгосрочный рост и успех

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

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

Масштабируемость приложения без кода

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

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

Backendless, с другой стороны, масштабируется.

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

Бесконечно масштабируемая серверная часть

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

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

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

Заключение

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

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

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

Масштабируемость приложений — Как сделать эффективное масштабирование

Нравится (5)

Твитнуть

29,90К Просмотров

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

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

Масштабируемость приложения — это возможность приложения расти во времени, способного эффективно обрабатывать все больше и больше запросов в минуту (RPM). Это не просто настройка, которую вы можете включить/выключить; это длительный процесс, который затрагивает почти каждый отдельный элемент в вашем стеке, включая как аппаратную, так и программную части системы.

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

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

Довольно часто вы сталкиваетесь с множеством проблем с масштабируемостью, когда ваше приложение становится слишком большим, но масштабируемость приложения больше связана со всей архитектурой системы. Создание проекта с использованием The Rails Way, безусловно, не лучший подход, когда ваше приложение быстро развивается, но это не означает, что масштабирование приложения Rails всегда является проблемой. Конечно, Twitter перешел с Rails на Scala, но, с другой стороны, Shopify постоянно растет с Rails в качестве серверной части уже около десяти лет, с более чем 50 000 запросов в минуту и ​​временем отклика 45 мс. Опять же, многие фреймворки являются узкоспециализированными, но выбор фреймворка зависит от потребностей приложения, популярности фреймворка, стоимости, поддержки и других факторов и т. д.

Источник: https://trends.builtwith.com/framework

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

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

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

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

Держите свой код в чистоте

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

Leverage 12factor (https://12factor.net/)

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

Позаботьтесь о своей базе данных

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

Предотвращение проблем с запросами

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

Выберите правильный хостинг

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

Подготовка к балансировке нагрузки

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

Разгрузить серверную часть

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

Проверка и мониторинг

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

Оптимизировать

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

Отдельный код

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

Обновление на регулярной основе

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

Веб-приложение Масштабируемость Масштабирование (геометрия) Механизм базы данных IT

Мнения участников DZone являются их собственными.

Руководство разработчика по масштабированию приложения

Рон Пауэлл

Рон имеет опыт работы в космической физике, работая в команде Кассини, анализируя плазму, запертую в магнитосфере Сатурна. Сейчас он работает в компании CircleCI в Сан-Франциско, штат Калифорния, в качестве защитника разработчиков, создавая контент, который позволяет разработчикам быстрее создавать, тестировать и развертывать свои проекты. Ранее он был разработчиком-евангелистом в Samsung Electronics, Америка, где специализировался на производстве 360-градусного видео и разработке приложений для оборудования виртуальной реальности, носимых устройств и IoT.

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

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

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

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

Что масштабировать и насколько далеко?

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

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

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

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

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

Именно здесь использование микросервисного подхода становится ценным: вы можете разделить свое приложение на несколько выделенных сервисов, которые затем докеризуются и развертываются в кластере Kubernetes.

Сначала автоматизируйте

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

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

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

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

Вы также можете автоматизировать настройку ресурсов. Если вы применяете подход «инфраструктура как код» (IaC) с такими инструментами, как Terraform от HashiCorp или AWS CloudFormation от Amazon Web Services, для автоматической подготовки и настройки серверов, вы даже можете протестировать и проверить код конфигурации, используемый для создания вашей инфраструктуры. Миграции также могут быть как минимум полуавтоматическими, что обеспечивает высокую степень гибкости.

Масштабирование хранилища данных

Одной из самых сложных для масштабирования вещей в любом приложении является база данных. Основная проблема объясняется теоремой CAP:

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

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

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

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

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

Масштабирование хранилища файлов

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

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

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

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

Оптимизация трафика

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

Ротация DNS устраняет ситуацию, когда только один IP-адрес получает все запросы, идущие к нашему домену. Однако даже в этом случае у вас есть несколько точек входа, но за ними по-прежнему стоят отдельные экземпляры приложения.

Другой метод заключается в использовании балансировщика нагрузки для разделения трафика между несколькими работающими экземплярами. Это еще одно из преимуществ использования облачного провайдера. У них есть сервисы, которые неявно используют балансировщик нагрузки, а также предлагают явный балансировщик нагрузки. Например, на AWS вы можете использовать Amazon Elastic Load Balancer для распределения входящего трафика.

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

Непрерывное масштабирование

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

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

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