Измерение потребления каждого арендатора

  • Статья

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

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

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

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

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

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

Примечание.

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

Показательные метрики потребления

Современные приложения (созданные для облака) обычно состоят из множества различных служб, каждый из которых имеет различные меры потребления. Например, учетная запись хранения измеряет потребление на основе объема хранимых данных, передаваемых данных и количества транзакций. Однако приложение Azure потребление служб измеряется по количеству вычислительных ресурсов, выделенных с течением времени. Если у вас есть решение, включающее учетную запись хранения и Служба приложений ресурсы, то объединение всех этих измерений вместе для вычисления фактического COGS (стоимость проданных товаров) может оказаться очень сложной задачей. Часто проще использовать одно показательное измерение для представления потребления в решении.

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

Примечание.

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

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

Метрики транзакций

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

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

Метрики для каждого запроса

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

Примечание.

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

Предупреждение

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

Оценка потребления

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

Вы можете рассмотреть возможность оценки COGS для клиента в следующих случаях:

  • Вы не используете цены на основе потребления.
  • Шаблоны использования и затраты для каждого клиента похожи независимо от размера.
  • Каждый клиент потребляет низкий процент (например, <2%) общих ресурсов в развертывании.
  • Стоимость каждого клиента низка.

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

Плата за затраты

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

Примечание.

Некоторые службы Azure не поддерживают теги. Для этих служб необходимо атрибутировать затраты клиенту на основе имени ресурса, группы ресурсов или подписки.

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

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

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

Соавторы

Эта статья поддерживается корпорацией Майкрософт. Первоначально он был написан следующими участник.

Автор субъекта:

Другие участник:

Чтобы просмотреть недоступные профили LinkedIn, войдите в LinkedIn.

Следующие шаги

Рассмотрим модель развертывания обновления, которую вы будете использовать.