Мультитенантные решения часто требуют особого внимания при измерении количества затрат и их распределении, а также при оптимизации затрат. На этой странице описаны некоторые ключевые рекомендации, которые архитекторам решений следует учитывать при измерении количества затрат, их распределении и оптимизации для мультитенантного приложения.
Ключевые рекомендации и требования
Рассмотрите требования к измерению объема потребления для решения. Это подробно описано в статье об измерении объема потребления каждого арендатора.
Назначение измерения
Важно определить свою цель. Ниже приведены примеры целей:
- Вычислить приблизительную себестоимость проданных товаров для каждого арендатора. Например, при развертывании значительного количества общих ресурсов вас может интересовать лишь примерная стоимость для каждого арендатора.
- Вычислить точную стоимость для каждого арендатора. Например, если арендаторы оплачивают точный объем потребления, вам необходимо иметь конкретные сведения о стоимости ресурсов каждого арендатора.
- Выявить арендаторов выбросов, которые платят значительно больше. Например, если вы предоставляете модель ценообразования с фиксированной ставкой, чтобы применить политики для использования, вам может потребоваться определить, потребляют ли какие-либо арендаторы непропорциональное количество подготовленной емкости. Во многих случаях этот вариант использования не требует точного измерения количества затрат.
- Сократить общие затраты на Azure для вашего решения. Например, вам может потребоваться рассмотреть стоимость каждого компонента, а затем определить, выполнили ли вы чрезмерную подготовку для рабочей нагрузки.
Распознав цель измерения объема потребления арендатора, можно определить, должны ли распределения затрат быть приблизительными или очень точными, что влияет на конкретные средства, которые можно использовать, и рекомендации, которые можно соблюдать.
Общие компоненты
Вы можете снизить затраты на мультитенантное решение, переместив арендаторов в общую инфраструктуру. Тем не менее вам необходимо тщательно продумать влияние совместного использования ресурсов, например не возникнет ли у арендаторов проблема шумного соседа.
Необходимо также учитывать, как измеряется и распределяется стоимость общих компонентов. Например, вы можете поровну разделить затраты между каждым арендатором, использующим общий компонент. Либо же вы можете замерить объем потребления общих компонентов для каждого арендатора, чтобы получить более точные результаты.
Подходы и шаблоны, которые следует учитывать
Распределение затрат с помощью тегов ресурсов
Azure позволяет вам применять теги к вашим ресурсам. Тег — это пара "ключ-значение". Для добавления пользовательских метаданных используются теги. Теги нужны для многих операций управления, а также они могут пригодиться для анализа затрат на использование Azure. После применения тегов можно определить затраты, связанные с каждым из них.
Способ использования тегов в мультитенантном решении может отличаться в зависимости от архитектуры.
В некоторых решениях можно развернуть выделенные ресурсы для каждого клиента, например при развертывании выделенных меток развертывания для каждого клиента. В таких случаях ясно, что этому арендатору должны быть выделены любые объемы потребления Azure для этих ресурсов, и поэтому вы можете поставить тег на ресурсы Azure с идентификатором арендатора.
В других ситуациях могут существовать наборы общих ресурсов. Например, при применении шаблона сегментирования можно развернуть несколько баз данных и распределить по ним арендаторов. Рассмотрите возможность добавления тегов к ресурсам с идентификатором для группы арендаторов. Возможно, вам не удастся легко выделить затраты на одного арендатора, но при использовании этого подхода вы сможете по крайней мере сократить затраты на набор арендаторов. Сведения о потреблении можно также использовать для перераспределения арендаторов по сегментам, если вы заметили, что в конкретном сегменте начисляются большие затраты по сравнению с другими.
Примечание.
Существует ограничение на количество тегов, которые можно применить к ресурсу. При работе с общими ресурсами не рекомендуется добавлять тег для каждого арендатора, использующего этот ресурс. Вместо этого рассмотрите возможность добавления тега с идентификатором сегмента или другой способ идентификации группы арендаторов.
Рассмотрим пример мультитенантного решения, созданного с помощью шаблона меток развертывания и модели секционирования по вертикали. Каждая метка развертывания включает в себя сегментированные базы данных и общий веб-сервер. Теги могут применяться к каждому из компонентов Azure, как показано на следующей схеме.
Применяемая здесь стратегия добавления тегов выглядит следующим образом:
- У каждого ресурса есть тег
stamp-id. - У каждой сегментированной базы данных есть тег
shard-id. - У каждого ресурса, выделенного для конкретного арендатора, есть тег
tenant-id.
Эта стратегия тегов позволяет с легкостью отфильтровать данные о затратах до одной метки. Вы также легко сможете найти затраты на ресурсы арендатора, например общую стоимость базы данных для арендатора C. У общих компонентов нет тега tenant-id, но стоимость общих компонентов для метки может быть разделена между арендаторами, которым назначено использование этой метки или сегмента.
Инструментирование приложения
В случаях отсутствия прямой связи между ресурсом Azure и арендатором, рассмотрите возможность инструментирования приложения для сбора данных телеметрии.
Уровень приложений может уже собирать журналы и метрики, которые полезны для ответа на вопросы о измерении, например:
- Сколько приблизительно запросов API выполнено для арендатора?
- В какое время суток конкретные арендаторы имеют самую большую загрузку?
- Как сравниваются шаблоны потребления арендатора А с шаблонами потребления арендатора B?
В Azure эти метрики часто захватываются с помощью Application Insights. С помощью инициализаторов данных телеметрии можно обогатить данные телеметрии, захваченные с помощью Application Insights, чтобы включить идентификатор арендатора или другие пользовательские данные.
Но Application Insights и другие решения для ведения журналов и мониторинга не подходят для точного измерения затрат или для экспозамера. Application Insights предназначен для выборки данных, особенно если приложение имеет большое количество запросов. Выборка предназначена для снижения затрат на мониторинг решения, так как захват каждого элемента данных телеметрии часто становится дорогостоящим.
Если вам нужно отслеживать точные сведения о потреблении или использовании для выставления счетов, следует создать пользовательский конвейер для записи необходимых данных в журнал. Затем следует выполнять статистическое вычисление данных в соответствии с вашими требованиями. Службы Azure, которые могут быть полезными для этой цели: Центры событий для захвата больших томов данных телеметрии и Stream Analytics для их обработки в режиме реального времени.
Использование резервирования Azure и плана экономии Azure для снижения затрат
Резервирования Azure. Резервирования Azure позволяют сократить затраты Azure путем предварительной фиксации на определенный уровень расходов. Резервирования применяются к ряду типов ресурсов Azure.
Резервирования можно эффективно использовать в мультитенантном решении. Обратите внимание на следующие моменты:
- При развертывании мультитенантного решения, включающего общие ресурсы, учитывайте базовый уровень потребления, необходимый для рабочей нагрузки. Вы можете использовать резервирование для этого базового потребления, а затем оплатить по стандартным ставкам, чтобы уровень потребления повышался при непредсказуемых пиковых нагрузках.
- При развертывании ресурсов для каждого арендатора определите, можно ли предварительно зафиксировать потребление ресурсов для определенного арендатора или в вашем портфеле арендаторов.
Резервирование Azure позволяет определить объем резервирования для применения к группе ресурсов, подписке или набору подписок. Это означает, что вы можете воспользоваться резервированием, даже если вы сегментируете свою рабочую нагрузку на несколько подписок.
Области резервирования также могут пригодиться при наличии арендаторов с непредсказуемыми рабочими нагрузками. Например, рассмотрим решение, в котором арендатору A требуется только один экземпляр определенного ресурса, но для арендаторов B и C нужны два. Затем у арендатора B уменьшается количество нагрузки, поэтому вы уменьшаете число экземпляров, а арендатор A получает нагрузку, и вы увеличиваете число экземпляров. Ваши резервирования применяются к арендаторам, которым они необходимы.
План экономии Azure для вычислений: план экономии Azure для вычислений — это гибкий план экономии, который создает значительную экономию по сравнению с ценами на оплату по мере использования. Вы соглашаетесь с контрактом на один или три года и получаете скидки на соответствующие вычислительные службы. К этим службам относятся виртуальные машины, выделенные узлы, экземпляры контейнеров, функции Azure premium и службы приложений Azure. Экономия применяется к этим вычислительным службам независимо от региона, размера экземпляра или операционной системы. Дополнительные сведения см . в обзоре плана экономии Azure и документации по плану экономии Azure.
Объединение резервирований и сберегательных планов. Для дальнейшей оптимизации затрат и гибкости можно объединить план экономии Azure с резервированиями Azure.
Неподходящие антишаблоны
- Отсутствие отслеживания затрат. Важно иметь хотя бы приблизительное представление о своих затратах и о влиянии каждого арендатора на стоимость доставки вашего решения. В противном случае, если затраты со временем изменятся, у вас не будет базовых показателей для сравнения. Вы также не сможете предсказать, как рост клиентов повлияет на ваши затраты и прибыльность.
- Предположения или угадывание. Убедитесь, что измерение затрат основано на реальных данных. Вам может быть не нужна высокая степень точности, но даже для оценочных расчетов нужно обладать реальными показателями.
- Излишняя точность. Возможно, вам не нужно иметь подробный учет каждой стоимости, которая взимается для каждого клиента. Создание ненужных точных процессов измерения затрат и оптимизации может быть контрпродуктивным, так как он добавляет инженерную сложность и создает хрупкие процессы.
- Измерение в реальном времени. Для большинства решений не требуется поминутное измерение затрат. Поскольку данные экспозамера и потребления могут быть сложными для обработки, вам сперва следует занести в журнал необходимые данные, а затем асинхронно выполнить статистическое вычисление и обработать данные позже.
- Использование средств мониторинга для выставления счетов. Согласно разделу об инструментировании приложений, убедитесь, что вы используете средства, предназначенные для мониторинга затрат и экспозамера. Решения для мониторинга приложений обычно не являются хорошим выбором для этого типа данных, особенно если вам требуется высокий уровень точности.
Соавторы
Эта статья поддерживается корпорацией Майкрософт. Первоначально он был написан следующими участниками.
Автор субъекта:
- Джон Даунс | Главный инженер программного обеспечения
Другие участники:
- Шерри Бабилон | Старший инженер по работе с клиентами, FastTrack для Azure
- Арсен Владимирский | Главный инженер клиента, FastTrack для Azure
Чтобы просмотреть недоступные профили LinkedIn, войдите в LinkedIn.