Данные часто считаются наиболее ценными частью решения, так как она представляет вашу - и ваших клиентов - ценную бизнес-информацию. Поэтому важно тщательно управлять данными. При планировании хранения или компонентов данных для мультитенантной системы необходимо принять решение о подходе к совместному использованию или изоляции данных клиентов.
В этой статье мы предоставляем рекомендации по ключевым соображениям и требованиям, необходимым для архитекторов решений при принятии решения о подходе к хранению данных в мультитенантной системе. Затем мы предлагаем некоторые распространенные шаблоны применения мультитенантности к службам хранения и данных, а также некоторые антипаттерны, чтобы избежать. Наконец, мы предоставляем целевое руководство для некоторых конкретных ситуаций.
Ключевые рекомендации и требования
Важно учитывать подходы, которые используются для служб хранилища и данных с нескольких перспектив, которые приблизительно соответствуют основам платформы Azure Well-Architected Framework.
Масштабировать
При работе со службами, которые хранят данные, следует учитывать количество клиентов, которые у вас есть, и объем данных, которые вы храните. Если у вас есть небольшое количество клиентов (например, пять или меньше), и вы храните небольшие объемы данных для каждого клиента, то, скорее всего, это будет неотратыми усилиями, чтобы спланировать высокомасштабируемый подход к хранилищу данных или создать полностью автоматизированный подход к управлению ресурсами данных. Но по мере роста вы все чаще выигрываете от четкой стратегии масштабирования ресурсов данных и хранилища и применения автоматизации к управлению. Если у вас есть 50 клиентов или более, или если вы планируете достичь этого уровня масштабирования, то особенно важно разработать подход к данным и хранилищу с учетом масштаба в качестве ключевого подхода.
Рассмотрим масштабируемую степень масштабирования и четко спланируйте архитектурный подход к хранилищу данных для удовлетворения этого уровня масштаба.
Прогнозируемость производительности
Мультитенантные данные и службы хранилища особенно подвержены проблеме шумного соседа. Важно учитывать, могут ли ваши клиенты повлиять на производительность друг друга. Например, с течением времени клиенты перекрывают пики их использования? Используют ли все ваши клиенты решение одновременно каждый день или равномерно распределяют запросы? Эти факторы влияют на уровень изоляции, для которого необходимо разработать, объем ресурсов, необходимых для подготовки, и степень совместного использования ресурсов между клиентами.
Важно учитывать ресурсы Azure и запрашивать квоты в рамках этого решения. Например, предположим, что вы развертываете одну учетную запись хранения для хранения всех данных клиентов. Если вы превышаете определенное количество операций хранения в секунду, служба хранилища Azure отклонит запросы приложения, и все ваши клиенты будут затронуты. Это называется поведением регулирования . Важно отслеживать регулирование запросов. Подробнее см. в разделе Повторная попытка в службах Azure.
Изоляция данных
При разработке решения, содержащего мультитенантные службы данных, обычно существуют различные варианты и уровни изоляции данных, каждый из которых имеет собственные преимущества и компромиссы. Например:
- При использовании Azure Cosmos DB можно развертывать отдельные контейнеры для каждого клиента, а также совместно использовать базы данных и учетные записи между несколькими клиентами. Кроме того, можно рассмотреть возможность развертывания разных баз данных или даже учетных записей для каждого клиента в зависимости от требуемого уровня изоляции.
- При использовании служба хранилища Azure для данных BLOB-объектов можно развернуть отдельные контейнеры BLOB-объектов для каждого клиента или развернуть отдельные учетные записи хранения.
- При использовании SQL Azure можно использовать отдельные таблицы в общих базах данных или развертывать отдельные базы данных или серверы для каждого клиента.
- Во всех службах Azure можно рассмотреть возможность развертывания ресурсов в одной общей подписке Azure или использовать несколько подписок Azure, возможно, даже один на клиент.
Существует ни одно решение, которое работает для каждой ситуации. Выбранный вариант зависит от ряда факторов и требований клиентов. Например, если клиенты должны соответствовать определенным стандартам соответствия или нормативным требованиям, может потребоваться применить более высокий уровень изоляции. Аналогичным образом, у вас могут быть коммерческие требования для физической изоляции данных клиентов или может потребоваться применить изоляцию, чтобы избежать проблемы с шумным соседом. Кроме того, если арендаторы должны использовать собственные ключи шифрования, у них есть отдельные политики резервного копирования и восстановления, или они должны хранить данные в разных географических расположениях, вам может потребоваться изолировать их от других клиентов или сгруппировать их с клиентами, имеющими аналогичные политики.
Сложность реализации
Важно учитывать сложность реализации. Рекомендуется как можно проще сохранить архитектуру, но по-прежнему соответствовать вашим требованиям. Избегайте фиксации архитектуры, которая становится все более сложной по мере масштабирования или архитектуры, у вас нет ресурсов или опыта для разработки и обслуживания.
Аналогичным образом, если решение не требует масштабирования до большого количества клиентов, или если у вас нет проблем с производительностью или изоляцией данных, лучше сохранить решение простым и избежать ненужной сложности.
Особое внимание уделяется мультитенантным решениям данных— это уровень поддержки настройки. Например, клиент может расширить модель данных или применить пользовательские правила данных? Убедитесь, что вы разрабатываете это требование заранее. Избегайте вилки или предоставления пользовательской инфраструктуры для отдельных клиентов. Настраиваемая инфраструктура препятствует масштабированию, тестированию решения и развертыванию обновлений. Вместо этого рекомендуется использовать флаги компонентов и другие формы конфигурации клиента.
Сложность управления и операций
Рассмотрим, как вы планируете работать с решением, а также как подход к мультитенантности влияет на операции и процессы. Например:
- Управление. Рассмотрим операции управления между клиентами, такие как регулярные операции обслуживания. Если вы используете несколько учетных записей, серверов или баз данных, как инициировать и отслеживать операции для каждого клиента?
- Мониторинг и измерение. Если вы отслеживаете или измеряете ваши клиенты, рассмотрите метрики отчетов о решении и можете ли они легко связаться с клиентом, активировав запрос.
- Отчеты. Для создания отчетов между изолированными клиентами может потребоваться, чтобы каждый клиент публиковал данные в централизованном хранилище данных, а не выполнял запросы к каждой базе данных по отдельности, а затем агрегировать результаты.
- Обновления схемы. Если вы используете базу данных, которая применяет схему, запланируйте развертывание обновлений схемы в пределах вашего имущества. Рассмотрим, как приложение знает, какая версия схемы используется для запросов к базе данных конкретного клиента.
- Требования. Учитывайте требования к высокой доступности клиентов (например, соглашения об уровне обслуживания и соглашения об уровне обслуживания) и требования к аварийному восстановлению (например, целевые показатели времени восстановления или осРВ, а также цели точки восстановления или RPOS). Если у клиентов есть разные ожидания, вы сможете удовлетворить требования каждого клиента?
- Миграция: как перенести клиентов, если им нужно перейти в другой тип службы, другое развертывание или другой регион?
Себестоимость
Как правило, чем выше плотность клиентов в инфраструктуре развертывания, тем ниже затраты на подготовку этой инфраструктуры. Однако общая инфраструктура повышает вероятность таких проблем, как шумный сосед, поэтому тщательно рассмотрите компромиссы.
Подходы и шаблоны, которые следует учитывать
Несколько шаблонов проектирования из Центра архитектуры Azure относятся к мультитенантным хранилищам и службам данных. Вы можете последовательно следовать одному шаблону. Кроме того, можно рассмотреть возможность смешивания и сопоставления шаблонов. Например, можно использовать мультитенантную базу данных для большинства клиентов, но развертывать метки с одним клиентом для клиентов, которые платят больше или имеют необычные требования. Аналогичным образом, часто рекомендуется масштабировать с помощью меток развертывания, даже если вы используете мультитенантную базу данных или сегментированные базы данных в метках.
Шаблон меток развертывания
Дополнительные сведения о том, как можно использовать шаблон меток развертывания для поддержки мультитенантного решения, см. в обзоре.
Общие мультитенантные базы данных и хранилища файлов
Возможно, вы можете развернуть общую мультитенантную базу данных, учетную запись хранения или общую папку и предоставить общий доступ ко всем клиентам.
Такой подход обеспечивает максимальную плотность клиентов к инфраструктуре, поэтому она, как правило, имеет наименьшую стоимость любого подхода. Это также часто снижает затраты на управление, так как существует отдельная база данных или ресурс для управления, резервного копирования и защиты.
Однако при работе с общей инфраструктурой существует несколько предостережения, которые следует учитывать:
- Ограничения масштабирования. При использовании одного ресурса учитывайте поддерживаемый масштаб и ограничения этого ресурса. Например, максимальный размер одной базы данных или хранилища файлов или максимальное ограничение пропускной способности в конечном итоге станет жестким блокировщиком, если архитектура зависит от одной базы данных. Тщательно рассмотрите максимальный масштаб, который необходимо достичь, и сравните его с текущими и будущими ограничениями, прежде чем выбрать этот шаблон.
- Шумные соседи:Проблема шумного соседа может стать фактором, особенно если у вас есть клиенты, которые особенно заняты или создают более высокие рабочие нагрузки, чем другие. Учитывая применение шаблона регулирования или шаблона ограничения скорости для устранения этих последствий.
- Мониторинг каждого клиента. Возможно, у вас возникли трудности с мониторингом активности и измерением потребления для одного клиента. Некоторые службы, такие как Azure Cosmos DB, предоставляют отчеты об использовании ресурсов для каждого запроса, поэтому эти сведения можно отслеживать для измерения потребления для каждого клиента. Другие службы не предоставляют тот же уровень детализации. Например, метрики Файлы Azure для емкости файлов доступны для измерения общей папки только при использовании общих папок класса Premium. Однако уровень "Стандартный" предоставляет метрики только на уровне учетной записи хранения.
- Требования к клиенту: клиенты могут иметь различные требования к безопасности, резервному копированию, доступности или расположению хранилища. Если они не соответствуют конфигурации одного ресурса, возможно, вы не сможете их разместить.
- Настройка схемы. При работе с реляционной базой данных или другой ситуацией, когда важна схема данных, настройка схемы на уровне клиента является сложной.
Шаблон сегментирования
Шаблон сегментирования включает развертывание нескольких отдельных баз данных, называемых сегментами, которые содержат данные одного или нескольких клиентов. В отличие от меток развертывания, сегменты не подразумевают дублирование всей инфраструктуры. Вы можете сегментировать базы данных, не дублируя или сегментируя другую инфраструктуру в решении.
Сегментирование тесно связано с секционированием, и термины часто используются взаимозаменяемо. Рассмотрим руководство по секционирование горизонтальных, вертикальных и функциональных данных.
Шаблон сегментирования может масштабироваться до очень большого количества клиентов. Кроме того, в зависимости от рабочей нагрузки вы можете достичь высокой плотности клиентов для сегментов, чтобы затраты могли быть привлекательными. Шаблон сегментирования также можно использовать для решения квот подписки Azure и служб, ограничений и ограничений.
Некоторые хранилища данных, такие как Azure Cosmos DB, обеспечивают встроенную поддержку сегментирования или секционирования. При работе с другими решениями, такими как SQL Azure, может быть сложнее создавать инфраструктуру сегментирования и направлять запросы к правильному сегменту для данного клиента.
Сегментирование также затрудняет поддержку различий конфигурации на уровне клиента и позволяет клиентам предоставлять собственные ключи шифрования.
Мультитенантное приложение с выделенными базами данных для каждого клиента
Другой распространенный подход заключается в развертывании одного мультитенантного приложения с выделенными базами данных для каждого клиента.
В этой модели данные каждого клиента изолированы от других, и вы можете поддерживать некоторую степень настройки для каждого клиента.
Так как вы подготавливаете выделенные ресурсы данных для каждого клиента, стоимость этого подхода может быть выше, чем модели общего размещения. Однако Azure предоставляет несколько вариантов, которые можно рассмотреть, чтобы поделиться затратами на размещение отдельных ресурсов данных в нескольких клиентах. Например, при работе с SQL Azure можно рассмотреть эластичные пулы. Для Azure Cosmos DB можно подготовить пропускную способность для базы данных и пропускную способность совместно используется между контейнерами в этой базе данных, хотя этот подход не подходит, если требуется гарантированная производительность для каждого контейнера.
В этом подходе, так как только компоненты данных развертываются по отдельности для каждого клиента, вероятно, вы можете достичь высокой плотности для других компонентов в решении и сократить затраты на эти компоненты.
При подготовке баз данных для каждого клиента важно использовать подходы к автоматическому развертыванию.
Шаблон геообъектов
Шаблон Geode предназначен специально для географически распределенных решений, включая мультитенантные решения. Он поддерживает высокую нагрузку и высокий уровень устойчивости. Если вы реализуете шаблон Geode, уровень данных должен иметь возможность реплика управлять данными в разных географических регионах, и он должен поддерживать операции записи с несколькими географическими областями.
Azure Cosmos DB предоставляет многомездные записи для поддержки этого шаблона, а Cassandra поддерживает кластеры с несколькими регионами. Другие службы данных обычно не могут поддерживать этот шаблон без значительной настройки.
Неподходящие антишаблоны
При создании мультитенантных служб данных важно избежать ситуаций, которые препятствуют масштабированию.
К реляционным базам данных относятся следующие:
- Изоляция на основе таблиц. При работе в одной базе данных не создавайте отдельные таблицы для каждого клиента. Одна база данных не сможет поддерживать очень большое количество клиентов при использовании этого подхода, и становится все труднее запрашивать, управлять и обновлять данные. Вместо этого рекомендуется использовать один набор мультитенантных таблиц со столбцом идентификатора клиента. Кроме того, можно использовать один из шаблонов, описанных выше, для развертывания отдельных баз данных для каждого клиента.
- Настройка клиента на уровне столбца. Избегайте применения обновлений схемы, которые применяются только к одному клиенту. Например, предположим, что у вас есть одна мультитенантная база данных. Избегайте добавления нового столбца в соответствии с требованиями конкретного клиента. Это может быть приемлемо для небольшого количества настроек, но это быстро становится неуправляемым, если у вас есть большое количество настроек для рассмотрения. Вместо этого рекомендуется пересмотреть модель данных для отслеживания пользовательских данных для каждого клиента в выделенной таблице.
- Изменения схемы вручную. Избегайте обновления схемы базы данных вручную, даже если у вас есть только одна общая база данных. Легко потерять отслеживание примененных обновлений, и если вам нужно увеличить масштаб до дополнительных баз данных, сложно определить правильную схему для применения. Вместо этого создайте автоматизированный конвейер для развертывания изменений схемы и последовательно его использования. Отслеживайте версию схемы, используемую для каждого клиента в выделенной базе данных или таблице подстановки.
- Зависимости версий. Избегайте того, чтобы приложение было зависимо от одной версии схемы базы данных. При масштабировании может потребоваться применить обновления схемы в разные времена для разных клиентов. Вместо этого убедитесь, что версия приложения совместима по крайней мере с одной версией схемы и избегайте разрушительных обновлений схемы.
Databases
Существуют некоторые функции, которые могут быть полезны для мультитенантности. Однако они недоступны во всех службах баз данных. Рассмотрите, требуется ли вам это, если вы решите использовать службу для вашего сценария:
- Безопасность на уровне строк может обеспечить изоляцию безопасности для данных конкретных клиентов в общей мультитенантной базе данных. Эта функция доступна в SQL Azure и Postgres Flex, но она недоступна в других базах данных, таких как MySQL или Azure Cosmos DB.
- Шифрование на уровне клиента может потребоваться для поддержки клиентов, которые предоставляют собственные ключи шифрования для своих данных. Эта функция доступна в SQL Azure в составе Always Encrypted. Azure Cosmos DB предоставляет управляемые клиентом ключи на уровне учетной записи, а также поддерживает Always Encrypted.
- Пул ресурсов обеспечивает возможность совместного использования ресурсов и затрат между несколькими базами данных или контейнерами. Эта функция доступна в эластичных пулах SQL Azure и управляемых экземплярах, а также в пропускной способности базы данных Azure Cosmos DB, хотя каждый вариант имеет ограничения, которые следует учитывать.
- Сегментирование и секционирование имеют более строгую поддержку в некоторых службах, чем другие. Эта функция доступна в Azure Cosmos DB с помощью логического и физического секционирования и гипермасштабирования PostgreSQL. Хотя SQL Azure изначально не поддерживает сегментирование, он предоставляет средства сегментирования для поддержки этого типа архитектуры.
Кроме того, при работе с реляционными базами данных или другими базами данных на основе схем следует активировать процесс обновления схемы при сохранении парка баз данных. В небольшом пространстве баз данных можно использовать конвейер развертывания для развертывания изменений схемы. По мере роста уровень приложений может оказаться лучше, чтобы определить версию схемы для определенной базы данных и инициировать процесс обновления.
Хранилище файлов и BLOB-объектов
Рассмотрим подход, используемый для изоляции данных в учетной записи хранения. Например, можно развернуть отдельные учетные записи хранения для каждого клиента или предоставить общий доступ к учетным записям хранения и развернуть отдельные контейнеры. Кроме того, можно создать общие контейнеры BLOB-объектов, а затем использовать путь к большому двоичному объекту для разделения данных для каждого клиента. Рассмотрите ограничения и квоты подписки Azure и тщательно спланируйте рост, чтобы обеспечить масштабирование ресурсов Azure для поддержки ваших будущих потребностей.
Если вы используете общие контейнеры, тщательно спланируйте стратегию проверки подлинности и авторизации, чтобы убедиться, что клиенты не смогут получать доступ к данным друг друга. При предоставлении клиентам доступа к ресурсам служба хранилища Azure следует учитывать шаблон ключа valet.
Распределение затрат
Рассмотрим, как измерять потребление и выделять затраты клиентам для использования общих служб данных. По возможности старайтесь использовать встроенные метрики вместо вычисления собственных. Однако при использовании общей инфраструктуры становится трудно разделить данные телеметрии для отдельных клиентов, и следует рассмотреть возможность пользовательского измерения на уровне приложения.
Как правило, облачные службы, такие как Azure Cosmos DB и Хранилище BLOB-объектов Azure, предоставляют более детализированные метрики для отслеживания и моделирования использования для конкретного клиента. Например, Azure Cosmos DB предоставляет потребляемую пропускную способность для каждого запроса и ответа.
Соавторы
Эта статья поддерживается корпорацией Майкрософт. Первоначально он был написан следующими участник.
Автор субъекта:
- Джон Даунс | Главный инженер клиента, FastTrack для Azure
Другие участник:
- Пол Берпо | Главный инженер клиента, FastTrack для Azure
- Даниэль Скотт-Райнсфорд | Стратег технологий партнеров
- Арсен Владимирский | Главный инженер клиента, FastTrack для Azure
Чтобы просмотреть недоступные профили LinkedIn, войдите в LinkedIn.
Следующие шаги
Дополнительные сведения о мультитенантности и конкретных службах Azure см. в следующем разделе: