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

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

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

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

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

Концепция облачного масштабирования

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

В то же время у владельцев решений есть ожидания, в том числе:

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

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

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

Три сценария

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

1. Масштабирование вручную
2. Автомасштабирование
3. Автоматическое уменьшение

Давайте рассмотрим каждый вариант использования на примере сценария.

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

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

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

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

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

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

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

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

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

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

Автоматическое уменьшение

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

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

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

Масштабирование с помощью визуализации

В этом году я несколько раз писал о платформе Render. Вот ссылки на некоторые другие мои публикации на эту тему:**n**

• Первое использование Render and Go
• Под капотом: рендеринг Unified Cloud
• Целевая разработка микрослужб
• Запустите идею стартапа за день< /li>

Я узнал, что они очень серьезно относятся к своему обещанию Zero DevOps. Как и следовало ожидать, масштабирование с помощью Render осуществляется легко и благодаря простому пользовательскому интерфейсу.

n Если служба запущена в плане "Начальный" (или выше), возможность вручную масштабировать количество экземпляров так же просто, как перейти на нужный уровень в меню "Масштабирование" на панели визуализации:

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

• Выберите количество экземпляров
• Включить и установить целевое использование ЦП
• Включить и задать целевое использование памяти

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

n После реализации автоматического масштабирования панель визуализации сообщает об изменениях количества запущенных экземпляров:

Кроме того, предоставляются показатели для обоснования реализации автоматического масштабирования:

С точки зрения выставления счетов изменения в структуре затрат основаны на количестве времени, в течение которого новые экземпляры находятся в наличии в данном месяце. Это означает, что если вы удвоите количество экземпляров на семь часов в один день платежного цикла, стоимость этого платежного цикла не удвоится; вместо этого он удвоится только за те семь часов, когда количество экземпляров удвоилось.

Другие доступные интеграции

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

• Datadog – передает метрики Postgres и потоки журналов на платформу обсерватории Datadog.
• Scout APM — обеспечивает мониторинг производительности приложений (APM) для Ruby, PHP, Python, Node.js, и сервисы на базе Elixir.

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

Заключение

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

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

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

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

Для тех, кто использует облачные сервисы от Amazon, Google или Microsoft, такие фирмы, как CleanSlate Technology Group предложить услуги, которые помогут вам решить эти проблемы.

n С 2021 года я стараюсь придерживаться следующей миссии, которую, как мне кажется, можно применить к любому специалисту в области технологий: