Существует множество способов работы с клиентами в решении. Выбор подхода зависит от того, следует ли предоставлять общий доступ к ресурсам между клиентами. Интуитивно вам может потребоваться избежать совместного использования ресурсов , но этот подход быстро становится дорогостоящим, так как бизнес-масштабируется, и вы можете подключить больше клиентов.
При рассмотрении различных моделей мультитенантности рекомендуется сначала учитывать, как вы определяете клиентов для вашей организации, какие бизнес-драйверы и как вы планируете масштабировать решение. В этой статье приводятся рекомендации по оказанию технической помощи лицам, принимающим решения, оценивать модели аренды и их компромиссы.
Определение клиента
Сначала необходимо определить клиент для вашей организации. Рассмотрим, кто ваш клиент. Другими словами, кто вы предоставляете свои услуги? Есть две распространенные модели:
- Бизнес для бизнеса (B2B). Если клиенты являются другими организациями, скорее всего, вы сопоставляете клиентов с этими клиентами. Однако учитывайте, имеют ли ваши клиенты подразделения (команды или отделы) и наличие присутствия в нескольких странах или регионах. Может потребоваться сопоставить одного клиента с несколькими клиентами, если существуют различные требования для этих подгрупп. Аналогичным образом, клиент может сохранить два экземпляра службы, чтобы они могли хранить свои среды разработки и рабочей среды отдельно друг от друга. Как правило, один клиент имеет несколько пользователей. Например, все сотрудники клиента являются пользователями в одном клиенте.
- Бизнес для потребителей (B2C). Если вашими клиентами являются потребители, часто бывает сложнее связать клиентов, арендаторов и пользователей. В некоторых сценариях каждый потребитель может быть отдельным клиентом. Тем не менее, рассмотрите, может ли ваше решение использоваться семьями, группами друзей, клубов, ассоциаций или другими группами, которые могут потребоваться для совместного доступа к данным и управления ими. Например, служба потоковой передачи музыки может поддерживать как отдельных пользователей, так и семьи, и она может обрабатывать каждую из этих типов учетных записей по-разному, когда она отделяет их от клиентов.
Определение клиента влияет на некоторые аспекты, которые необходимо учитывать или подчеркивать при разработке решения. Например, рассмотрим следующие типы клиентов:
- Если ваши клиенты являются отдельными людьми или семьями, вам может потребоваться особенно беспокоиться о том, как вы обрабатываете персональные данные, и о законах о суверенитете данных в каждой юрисдикции, которую вы обслуживаете.
- Если ваши клиенты являются предприятиями, вам может потребоваться учитывать требования клиентов к соответствию нормативным требованиям, изоляцию своих данных и обеспечение соответствия заданной цели уровня обслуживания (SLO), например доступности времени простоя или службы.
Как решить, какую модель следует использовать?
Выбор модели аренды — это не просто техническое решение. Это также коммерческое решение. Вам нужно рассмотреть такие вопросы:
- Каковы ваши бизнес-цели?
- Будут ли ваши клиенты принимать все формы мультитенантности? Как каждая модель мультитенантности влияет на требования соответствия требованиям или требования к соответствию вашим клиентам?
- Будет ли решение с одним клиентом масштабироваться в будущих целях роста?
- Насколько большой объем вашей группы операций и сколько можно автоматизировать управление инфраструктурой?
- Ваши клиенты ожидают, что вы будете соответствовать соглашениям об уровне обслуживания (SLA), или у вас есть соглашения об уровне обслуживания, которые вы стремитесь?
Если вы ожидаете, что бизнес масштабируется до большого количества клиентов, важно развернуть общую инфраструктуру. В противном случае потребуется поддерживать большой и растущий парк экземпляров ресурсов. Развертывание отдельных ресурсов Azure для каждого клиента, скорее всего, будет непристойным, если вы не подготавливаете и не используете выделенную подписку для каждого клиента. При совместном использовании одной и той же подписки Azure в нескольких клиентах квоты ресурсов Azure и ограничения могут применяться, а операционные затраты на развертывание и перенастройку этих ресурсов увеличиваются с каждым новым клиентом.
И наоборот, если вы ожидаете, что у вашего бизнеса будет только несколько клиентов, вам может потребоваться использовать ресурсы с одним клиентом, выделенные каждому клиенту. Кроме того, если требования к изоляции клиентов являются высокими, подход к инфраструктуре с одним клиентом может оказаться подходящим, хотя это более затратно.
Клиенты и развертывания
Затем необходимо определить, какой клиент означает для конкретного решения, и следует ли различать логические клиенты и развертывания.
Например, рассмотрим службу потоковой передачи музыки. Изначально можно создать решение, которое может легко обрабатывать тысячи (или даже десятки тысяч) пользователей. Однако по мере роста может возникнуть необходимость дублировать решение или некоторые компоненты, чтобы масштабироваться до нового спроса на клиентов. Это означает, что необходимо определить, как назначать конкретных клиентов определенным экземплярам решения. Вы можете назначить клиентов случайным образом или географически или заполнить один экземпляр, а затем запустить другой (упаковка корзины). Тем не менее, вероятно, вам нужно сохранить запись клиентов и инфраструктуру своих данных и приложений, чтобы можно было направлять свой трафик в правильную инфраструктуру. В этом примере вы можете представить каждого клиента в качестве отдельного клиента, а затем сопоставить пользователей с развертыванием, содержащим их данные. У вас есть сопоставление "один ко многим" между клиентами и развертываниями, и вы можете перемещать клиентов между развертываниями по своему усмотрению.
В отличие от этого, рассмотрим компанию, которая создает облачное программное обеспечение для юридических фирм. Клиенты могут настаивать на наличии собственной выделенной инфраструктуры для поддержания своих стандартов соответствия. Поэтому необходимо подготовиться к развертыванию и управлению различными экземплярами решения с самого начала. В этом примере развертывание всегда содержит один клиент, а клиент сопоставляется с собственным выделенным развертыванием.
Ключевое различие между клиентами и развертываниями заключается в том, как применяется изоляция. Если несколько клиентов совместно используют одно развертывание (набор инфраструктуры), обычно используется код приложения и идентификатор клиента, который находится в базе данных для разделения данных каждого клиента. Если у вас есть клиенты с собственными выделенными развертываниями, у них есть собственная инфраструктура, поэтому вам может быть менее важно знать, что она работает в мультитенантной среде.
Развертывания иногда называются супертенантами или метками.
При получении запроса для конкретного клиента необходимо сопоставить его с развертыванием, в котором хранятся данные этого клиента, как показано ниже:
Дополнительные сведения см. в статье "Сопоставление запросов к клиентам".
Изоляция арендаторов
Одним из самых больших соображений в проектировании мультитенантной архитектуры является уровень изоляции, необходимый каждому клиенту. Изоляция может означать разное:
- Наличие одной общей инфраструктуры с отдельными экземплярами приложения и отдельными базами данных для каждого клиента.
- Совместное использование некоторых общих ресурсов, но сохранение других ресурсов отдельно для каждого клиента.
- Хранение данных на отдельной физической инфраструктуре. В облаке эта конфигурация может потребовать отдельных ресурсов Azure для каждого клиента. В чрезвычайных ситуациях это может даже означать развертывание отдельной физической инфраструктуры с помощью выделенных узлов.
Вместо того чтобы думать об изоляции как дискретном свойстве, следует думать об этом как о том, что он находится на континууме. Вы можете развернуть компоненты своей архитектуры, которые более или менее изолированы, чем другие компоненты той же архитектуры, в зависимости от ваших требований. На следующей диаграмме показан спектр возможностей изоляции:
Уровень изоляции влияет на многие аспекты архитектуры, включая следующие:
- Безопасность. При совместном использовании инфраструктуры между несколькими клиентами необходимо быть особенно осторожным, чтобы не получать доступ к данным из одного клиента при возврате ответов другому. Вам нужен надежный фундамент для стратегии идентификации, и вам необходимо рассмотреть как клиент, так и удостоверение пользователя в процессе авторизации.
- Стоимость. Общая инфраструктура может использоваться несколькими клиентами, поэтому это менее дорого.
- Производительность. Если вы предоставляете общий доступ к инфраструктуре, производительность вашей системы может снизиться, так как ее используют больше клиентов, так как ресурсы могут быть использованы быстрее. Проблемы с производительностью могут быть усугубиться клиентами с необычными шаблонами использования.
- Надежность. Если вы используете один набор общей инфраструктуры, проблема с одним компонентом может привести к сбою для всех клиентов.
- Скорость реагирования на потребности отдельного клиента. При развертывании инфраструктуры, выделенной для одного клиента, вы можете адаптировать конфигурацию для ресурсов в соответствии с требованиями конкретного клиента. Вы даже можете рассмотреть эту возможность в модели ценообразования, позволяя клиентам платить больше за изолированные развертывания.
Архитектура решения может повлиять на доступные варианты изоляции. Например, рассмотрим трехуровневую архитектуру решения:
- Уровень пользовательского интерфейса может быть общим мультитенантным веб-приложением, при этом все клиенты получают доступ к одному имени узла.
- Средний уровень может быть общим уровнем приложения с общими очередями сообщений.
- Уровень данных можно изолировать базы данных, таблицы или контейнеры БОЛЬШИХ двоичных объектов.
Вы можете использовать различные уровни изоляции на каждом уровне. Вы должны принять решение о общих и изолированных возможностях, включая затраты, сложность, требования клиентов и количество ресурсов, которые можно развернуть, прежде чем достичь квот и ограничений Azure.
Общие модели аренды
После установки требований оцените их по некоторым общим моделям аренды и соответствующим шаблонам развертывания.
Автоматизированные развертывания с одним клиентом
В модели автоматического развертывания с одним клиентом развертывается выделенный набор инфраструктуры для каждого клиента, как показано в этом примере:
Ваше приложение отвечает за инициирование и координацию развертывания ресурсов каждого клиента. Как правило, решения, использующие эту модель, используют инфраструктуру в качестве кода (IaC) или API Azure Resource Manager. Этот подход можно использовать, когда необходимо подготовить полностью отдельные инфраструктуры для каждого клиента. При планировании развертывания рекомендуется использовать шаблон меток развертывания.
Преимущества. Ключевым преимуществом этого подхода является изоляция данных для каждого клиента, что снижает риск случайной утечки. Эта защита может быть важной для некоторых клиентов, имеющих высокие расходы на соответствие нормативным требованиям. Кроме того, клиенты вряд ли влияют на производительность системы друг друга, проблема, которая иногда называется шумной проблемой соседа . Обновления и изменения можно развертывать постепенно по всем клиентам, что снижает вероятность сбоя всей системы.
Риски. Если вы используете этот подход, экономичность низка, так как вы не разделяете инфраструктуру между клиентами. Если для одного клиента требуется определенная стоимость инфраструктуры, 100 клиентов, вероятно, требуют 100 раз, что стоит. Кроме того, текущее обслуживание (например, применение новых обновлений конфигурации или программного обеспечения), вероятно, займет много времени. Рассмотрите возможность автоматизации рабочих процессов и рассмотрите возможность постепенного применения изменений в средах. Кроме того, следует рассмотреть другие операции кросс-развертывания, такие как отчеты и аналитика по всему флоту. Аналогичным образом, обязательно спланируйте, как можно запрашивать и управлять данными в нескольких развертываниях.
Полностью мультитенантные развертывания
Напротив, можно рассмотреть полностью мультитенантное развертывание, где все компоненты совместно используются. У вас есть только один набор инфраструктуры для развертывания и обслуживания, а все клиенты используют ее, как показано на следующей схеме:
Преимущества. Эта модель является привлекательной, так как операционная система с общими компонентами является менее дорогой, чем использование отдельных ресурсов для каждого клиента. Даже если необходимо развернуть более высокие уровни или номера SKU ресурсов для учета повышенной нагрузки, общая стоимость развертывания часто ниже стоимости набора ресурсов с одним клиентом. Кроме того, если пользователю или клиенту необходимо переместить данные в другой клиент, возможно, вы сможете обновить идентификаторы и ключи клиента, и вам может не потребоваться перенести данные между двумя отдельными развертываниями.
Риски:
Не забудьте разделить данные для каждого клиента и не утечь данные между клиентами. Может потребоваться управлять сегментированием данных. Кроме того, может потребоваться беспокоиться о последствиях, которые могут иметь отдельные клиенты в общей системе. Например, если крупный клиент пытается выполнить тяжелый запрос или операцию, это может повлиять на другие клиенты.
Определите, как отслеживать и связывать затраты Azure с клиентами, если это важно для вас.
Обслуживание может быть проще с одним развертыванием, так как необходимо обновить только один набор ресурсов. Однако это также часто рискованно, так как изменения могут повлиять на всю клиентскую базу.
Вам также может потребоваться рассмотреть возможность масштабирования. Вы, скорее всего, достигнете ограничений масштабирования ресурсов Azure, если у вас есть общий набор инфраструктуры. Например, если вы используете учетную запись хранения в рамках решения по мере увеличения масштаба, количество запросов к этой учетной записи хранения может достичь ограничения того, что может обрабатывать учетная запись хранения. Чтобы избежать достижения ограничения квоты ресурсов, можно рассмотреть возможность развертывания пула нескольких экземпляров ресурсов (например, нескольких кластеров AKS или учетных записей хранения). Вы даже можете рассмотреть возможность распространения клиентов между ресурсами, развернутыми в нескольких подписках Azure.
Вероятно, существует ограничение на то, как далеко можно масштабировать одно развертывание, и затраты на это могут увеличиться нелинейно. Например, если у вас есть одна общая база данных, при выполнении в очень большом масштабе может быть исчерпана пропускная способность и необходимо платить все больше для повышения пропускной способности, чтобы обеспечить соответствие требованиям.
Развертывания с вертикальной секционированием
Вам не нужно выбирать одну из крайностей этих масштабов. Вместо этого можно рассмотреть возможность вертикальной секционирования клиентов, выполнив следующий подход:
- Используйте сочетание однотенантных и мультитенантных развертываний. Например, у вас может быть большинство данных клиентов и уровней приложений в мультитенантных инфраструктурах, но развертывание инфраструктуры с одним клиентом для клиентов, которым требуется более высокая производительность или изоляция данных.
- Разверните несколько экземпляров решения географически и сопоставите каждый клиент с определенным развертыванием. Этот подход особенно эффективен, если у вас есть клиенты в разных географических регионах.
Ниже приведен пример, демонстрирующий общее развертывание для некоторых клиентов и однотенантное развертывание для другого:
Преимущества. Так как вы по-прежнему предоставляете общий доступ к какой-то инфраструктуре, вы можете получить некоторые из преимуществ использования общих мультитенантных развертываний. Вы можете развернуть более дешевые общие ресурсы для определенных клиентов, таких как клиенты, которые оценивают службу с помощью пробной версии. Вы даже можете выставлять счета клиентам с более высокой ставкой, чтобы использовать развертывание с одним клиентом, что помогает восстановить некоторые затраты.
Риски. База кода должна быть разработана для поддержки мультитенантных и однотенантных развертываний. Если вы планируете разрешить миграцию между развертываниями, необходимо рассмотреть возможность переноса клиентов из мультитенантного развертывания в собственное развертывание с одним клиентом. Кроме того, необходимо знать, какие из клиентов находятся в каждом развертывании, чтобы вы могли обмениваться информацией о проблемах системы или обновлениях соответствующим клиентам.
Горизонтально секционированные развертывания
Вы также можете рассмотреть возможность горизонтального секционирования развертываний. В горизонтальном развертывании есть некоторые общие компоненты, но поддерживают другие компоненты с развертываниями с одним клиентом. Например, можно создать один уровень приложений, а затем развернуть отдельные базы данных для каждого клиента, как показано на этой схеме:
Преимущества. Горизонтально секционированные развертывания помогают устранить шумную проблему соседа: если определить, что большая часть нагрузки в системе вызвана определенными компонентами, можно развернуть отдельные компоненты для каждого клиента. Например, базы данных могут поглощать большую часть нагрузки системы, так как нагрузка запроса высока. Если один клиент отправляет в решение большое количество запросов, производительность базы данных может негативно повлиять на производительность базы данных, но другие базы данных клиентов (и общие компоненты, такие как уровень приложений), остаются не затронутыми.
Риски. При горизонтально секционированных развертываниях необходимо учитывать автоматическое развертывание и управление компонентами, особенно компонентами, используемыми одним клиентом.
Тестирование модели изоляции
Независимо от выбранной модели изоляции обязательно протестируйте решение, чтобы убедиться, что данные одного клиента не случайно утечки в другой и что любые шумные последствия соседей допустимы. Рассмотрите возможность использования Azure Chaos Studio , чтобы намеренно вводить ошибки, которые имитируют реальные сбои и проверяют устойчивость решения даже при сбоях компонентов.
Соавторы
Эта статья поддерживается корпорацией Майкрософт. Первоначально он был написан следующими участниками.
Автор субъекта:
- Джон Даунс | Главный инженер программного обеспечения
Другие участники:
- Чад Киттель | Главный инженер программного обеспечения
- Паоло Сальватори | Главный инженер клиента, FastTrack для Azure
- Арсен Владимирский | Главный инженер клиента, FastTrack для Azure
Чтобы просмотреть недоступные профили LinkedIn, войдите в LinkedIn.
Следующие шаги
Рассмотрите жизненный цикл клиентов