История весенней загрузки и приложения MongoDB
ОБНОВЛЕНИЕ: есть продолжение этого поста здесь
Это сообщение в блоге взято из обсуждения с клиентом, который широко использует JHipster для создания микросервисов Spring Boot с использованием баз данных MongoDB. Поскольку он является клиентом Azure, у нас возникло несколько вопросов:
- Может ли он разместить всю свою архитектуру “как услугу”? Приложения Spring Boot будут автоматически управляться и масштабироваться с помощью Веб-приложения Azure , а также его базы данных, использующие CosmosDB . Это означает для него намного меньше работы, стрессов и проблем!
- CosmosDB поддерживает API MongoDB, но насколько хороша эта поддержка? Может ли он просто использовать свои текущие приложения с CosmosDB?
- Какова производительность Cosmos и какова ожидаемая цена?
Поэтому я создал образец приложения Spring Boot + MongoDB, доступный по адресу https://github.com/jdubois/jhipster-cosmosdb-mongodb . Это приложение построено с помощью JHipster и использует одну из наших образцов моделей, называемую “отслеживание ошибок”, и которая доступна здесь .
Переход с MongoDB на CosmosDB
Наше приложение не тривиально: в нем есть несколько коллекций с взаимосвязями между ними. Однако все эти вызовы API поддерживаются CosmosDB, поэтому переход на CosmosDB чрезвычайно прост: просто используйте правильную строку подключения, и все!
Сначала я создал экземпляр CosmosDB с помощью портала Azure и убедился, что он использует API MongoDB:
Затем я выбрал этот экземпляр, чтобы получить строку подключения к моему экземпляру CosmosDB:
И все, что мне нужно было сделать в этом коммите , это использовать эту строку подключения с Spring Boot.
Пожалуйста, обратите внимание, что здесь мы используем Spring Data MongoDB и что он отлично работает с CosmosDB.
Количество коллекций и ценовые соображения
Сгенерированная база данных содержит 8 коллекций:
Пожалуйста, обратите внимание, что 2 из этих коллекций, журнал изменений бд и mongobeelock используются JHipster для автоматического обновления базы данных (если вы пришли из мира баз данных SQL, вы можете знать Liquibase, которая делает то же самое). Кроме того, у нас есть 2 коллекции, созданные хипстером, jhi_авторитет и jhi_persistent_audit_event , которые не являются полезными на 100%.
С CosmosDB вы можете оплачивать либо по коллекции, либо по базе данных: конфигурация по умолчанию – оплата по коллекции, и это также рекомендуется, если у вас нет проблем с ценами, так как это поможет вашему приложению лучше масштабироваться. Но в этом случае 4 коллекции, которые мы только что заметили, которые на самом деле бесполезны, будут стоить вам денег.
Поэтому, если вы перейдете с MongoDB на CosmosDB, одна из важных вещей, над которой нужно поработать, – это количество коллекций: сохраняйте только те, которые действительно полезны, иначе это будет стоить вам денег без какой-либо ценности для бизнеса.
Развертывание в веб-приложениях Azure
Как объяснено в документации JHipster , это всего лишь вопрос добавления правильного плагина, который выполняется в этот коммит .
Мы используем здесь Azure Web Apps поскольку мы хотим иметь полностью управляемые приложения. Пожалуйста, обратите внимание, что это позволяет “масштабировать” больший сервер) или “масштабировать” больше серверов на лету), и мы будем использовать эту более позднюю опцию для масштабирования без кодирования чего-либо.
Первые тесты, с участием 100 пользователей
Развернуть наше приложение было на удивление легко, но хорошо ли оно масштабируется? Для этого давайте воспользуемся инструментом нагрузочного тестирования Gatling , так как JHipster автоматически сгенерировал конфигурацию нагрузочного тестирования в src/test/gatling .
Мы сосредоточимся на Продукте сущности:
- Как только объект будет использован, CosmosDB создаст для него коллекцию. Будьте осторожны, так как по умолчанию он будет иметь 1000 RU/s, поэтому он стоит определенных денег.
- У этого объекта также есть проблема: он не разбит на страницы! Разбивка на страницы полезна с точки зрения бизнеса (если у нас 10 000 проектов, показать их все конечному пользователю невозможно), но также и с точки зрения производительности. Поскольку у нас ограниченное количество единиц запроса в секунду, давайте не будем тратить их впустую, запрашивая слишком много данных! Поэтому мы ограничили запрос 20 проектами в этом коммите .
В нашем первом тесте используется только 100 одновременных пользователей, и у нас был пик в 21 запрос в секунду. Это не большая нагрузка, так что все прошло нормально:
Собирается 500 пользователей
Поскольку первый тест был слишком простым, мы решили расширить систему до 500 пользователей. Все прошло хорошо, и мы получили пик в 136 запросов в секунду, но в приложении начали появляться некоторые проблемы.
На самом деле, в системе возникают некоторые медленные запросы, потому что процесс аутентификации занимает слишком много времени:
Охват 1000 пользователей
Чтобы подняться выше, мы решили обновить наш RU/seconds до 5000 для коллекций аутентификации и коллекции Project . В этом и заключается преимущество оплаты за коллекцию: вы можете выбрать, какой коллекции отдать предпочтение, в зависимости от потребностей вашего бизнеса.
Это позволяет нам охватить 1000 пользователей, но у нас все еще есть проблема с аутентификацией, вероятно, потому, что этот процесс слишком затратен только для одного экземпляра веб-приложения. Вот почему первые запросы идут медленно, а затем мы идем намного быстрее, с пиком в 308 запросов в секунду:
До 10 000 пользователей
В предыдущей конфигурации было невозможно увеличить число пользователей выше 2500, так как сервер приложений не справлялся с такой нагрузкой. Преимущество Azure Web App в том, что вы можете использовать его для автоматического масштабирования своего веб-приложения с помощью простого экрана:
Это решает проблему аутентификации, для которой требуется некоторая вычислительная мощность, поскольку мы распределяем ее между несколькими серверами. Это также позволяет нам поддерживать больше одновременных запросов.
Используя эту настройку, мы можем охватить 10 000 активных пользователей:
Кроме того, у нас был пик в 1029 запросов в секунду:
Однако здесь у нас было 2% ошибок, так как мы достигли 10 000 пользователей слишком быстро, чтобы система могла правильно обработать их всех.
Достижение 900 запросов в секунду без каких-либо проблем
Поскольку наша проблема здесь заключается в процессе аутентификации, и в нем использовалась только исходная мощность веб-приложения, мы снова провели аналогичный тест с 1000 пользователями, но на этот раз выполнили в 10 раз больше запросов каждый. И здесь мы имеем очень плавное и стабильное приложение, которое стабильно выдает 900 запросов в секунду:
Выводы и мысли
Наши тесты показывают, что:
- Запуск CosmosDB с API MongoDB очень хорошо работает на уровне API и полностью способен масштабироваться для обработки нагрузки
- Веб-приложения Azure позволяют легко размещать и масштабировать Приложения с пружинной загрузкой
Мы без особых проблем увеличили число пользователей со 100 до 10 000, за исключением того, что нам пришлось увеличить количество единиц запросов для CosmosDB и настроить автоматическое масштабирование для веб-приложений Azure. Это позволило нам продолжать использовать Spring Boot и Spring Data MongoDB как обычно: оба имеют удобный для разработчиков, лаконичный API, который нравится многим людям. Если бы нам было нужно, мы, вероятно, могли бы пойти дальше и обслуживать еще больше пользователей, если мы готовы платить за это: хорошей новостью является то, что масштабируемость работает хорошо и кажется линейной.
Оригинал: “https://dev.to/azure/deploying-a-spring-boot-mongodb-application-to-azure-web-apps-cosmosdb-52ki”