Архитектурные подходы для управления затратами и их распределения в мультитенантном решении

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

Ключевые рекомендации и требования

Рассмотрим требования, необходимые для измерения потребления в решении. Эти требования подробно описаны в разделе "Измерение потребления каждого клиента".

Назначение измерения

Важно определить свою цель. Рассмотрим следующие примеры целей:

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

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

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

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

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

Общие компоненты

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

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

Подходы и шаблоны, которые следует учитывать

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

Распределение затрат с помощью тегов ресурсов

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

Способ использования тегов в мультитенантном решении может отличаться в зависимости от архитектуры.

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

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

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

Рассмотрим следующую стратегию тегов:

• У каждого ресурса есть тег stamp-id.
• У каждой сегментированной базы данных есть тег shard-id.
• Каждый ресурс, выделенный для конкретного клиента, имеет tenant-id тег.

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

Инструментирование приложения

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

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

• Количество запросов API, сделанных для каждого клиента с течением времени.
• Пиковые периоды активности для конкретных клиентов в течение дня.
• Различия в шаблонах использования между клиентом A и клиентом B.

В Azure Application Insights часто фиксирует эти метрики. С помощью инициализаторов телеметрии можно дополнить данные телеметрии, записываемые Application Insights, чтобы включить идентификатор клиента или другие пользовательские данные.

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

Если вам нужно отслеживать точные сведения о потреблении или использовании для выставления счетов, следует создать пользовательский конвейер для записи необходимых данных в журнал. Затем следует выполнять статистическое вычисление данных в соответствии с вашими требованиями. Службы Azure, которые могут быть полезны для этой цели, включают Центры событий Azure для записи больших объемов телеметрии и Azure Stream Analytics для обработки в режиме реального времени.

Использование резервирования Azure и плана экономии Azure для снижения затрат

Резервирования Azure позволяют сократить затраты На Azure путем предварительной фиксации на определенный уровень расходов. Резервирования применяются ко многим типам ресурсов Azure.

Резервирования можно эффективно использовать в мультитенантном решении. Обратите внимание на следующие факторы:

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

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

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

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

План экономии Azure для вычислений — это гибкий план экономии, который создает значительную экономию по сравнению с ценами по мере использования. Вы соглашаетесь с контрактом на один или три года и получаете скидки на соответствующие вычислительные службы. К этим службам относятся виртуальные машины, выделенные узлы, экземпляры контейнеров, функции Azure premium и службы приложений Azure. Экономия применяется к этим вычислительным службам независимо от региона, размера экземпляра или операционной системы. Дополнительные сведения см . в обзоре плана экономии Azure и документации по плану экономии Azure.

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

Неподходящие антишаблоны

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

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

• Overengineer для точности. Возможно, вам не нужно иметь подробный учет каждой стоимости, которую несет каждый клиент. Создание ненужных точных процессов измерения затрат и оптимизации может быть контрпродуктивным, так как они добавляют инженерную сложность и создают хрупкие процессы.

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

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

Соавторы

Корпорация Майкрософт поддерживает эту статью. Следующие авторы написали эту статью.

Основной автор:

• Джон Даунс | Главный инженер по программному обеспечению, шаблоны и практики Azure

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

• Шерри Бабилон | Старший инженер по работе с клиентами, FastTrack для Azure
• Арсен Владимирский | Главный инженер клиента, FastTrack для Azure

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

Связанный ресурс

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