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

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

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

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

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

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

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

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

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

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

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

Трио сценариев

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Масштабирование с визуализацией

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

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

Если служба запущена в плане Starter (или выше), возможность вручную масштабировать количество экземпляров так же просто, как перейти на необходимый уровень в меню Scaling панели Render Dashboard:

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

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

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

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

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

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

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

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

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

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

Заключение

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

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

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

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

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

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

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

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

Хорошего дня!