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

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

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

Основные рекомендации и требования

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

Шкала

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

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

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

Прогнозируемость производительности

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

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

Изоляция данных

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

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

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

• При использовании Azure SQL можно использовать отдельные таблицы в общих базах данных или развертывать отдельные базы данных или серверы для каждого клиента.

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

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

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

• Арендаторы должны использовать собственные ключи шифрования
• У клиентов есть отдельные политики резервного копирования и восстановления
• Арендаторы должны хранить данные в разных географических расположениях.

Сложность реализации

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

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

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

Сложность управления и операций

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

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

• Мониторинг и измерение: Если вы отслеживаете или измеряете ваших арендаторов, рассмотрите, как ваша система предоставляет отчеты о метриках и можно ли легко связать метрики с арендатором, вызвавшим запрос.

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

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

• Требования: Учитывайте требования к высокой доступности клиентов, такие как соглашения об уровне обслуживания (СОГЛАШЕНИЯ об уровне обслуживания) и требования к аварийному восстановлению, такие как цели времени восстановления (ОСРВ) и цели точек восстановления (RPOS). Если у клиентов есть разные ожидания, убедитесь, что вы можете соответствовать требованиям каждого клиента.

• Миграция: Рассмотрите возможность перемещения клиентов в другой тип службы, другого развертывания или другого региона. Если вы планируете предложить эту возможность, создайте процессы и средства, чтобы убедиться, что это повторяемый и безопасный процесс.

Себестоимость

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

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

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

Шаблон меток развертывания (Deployment Stamps)

Дополнительные сведения об использовании шаблона меток развертывания для поддержки мультитенантного решения см. в разделе "Обзор".

Общие мультитенантные базы данных и хранилища файлов

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

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

Однако при работе с общей инфраструктурой учитывайте следующие недостатки:

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

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

• Измерение потребления клиентов: Определите, нужно ли измерять потребление каждого клиента. Некоторые службы данных, такие как Azure Cosmos DB, предоставляют отчеты об использовании ресурсов для каждой транзакции. Эти сведения можно отслеживать и агрегировать для измерения потребления для каждого клиента. Другие службы не предоставляют тот же уровень детализации. Например, при использовании Azure Files с премиальными облачными файловыми хранилищами, вы можете получить доступ к метрикам ёмкости файлов для каждого измерения файлового хранилища. Уровень "Стандартный" предоставляет метрики только на уровне учетной записи хранения.

• Требования клиента: Клиенты могут иметь различные требования к безопасности, резервному копированию, доступности или расположению хранилища. Если эти требования не соответствуют конфигурации одного ресурса, возможно, вы не сможете их разместить.

• Настройка схемы: При работе с реляционной базой данных или другим сценарием, в котором важна схема данных, настройка схемы на уровне клиента является сложной.

Шаблон сегментирования

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

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

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

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

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

Мультитенантное приложение с выделенными базами данных для каждого клиента

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

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

Затраты на этот подход могут быть выше, чем модели общего размещения, так как вы подготавливаете выделенные ресурсы данных для каждого клиента. Однако Azure предоставляет несколько вариантов, которые можно рассмотреть для распределения затрат на размещение отдельных ресурсов данных между несколькими тенантами. Например, при работе с базой данных SQL Azure можно рассмотреть эластичные пулы. Для Azure Cosmos DB можно подготовить пропускную способность для базы данных, и пропускная способность распределяется между контейнерами в этой базе данных. Однако этот подход не подходит, если требуется гарантированная производительность для каждого контейнера.

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

Шаблон геоузла

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

Azure Cosmos DB предоставляет запись в нескольких регионах для поддержки этого шаблона, а Управляемый экземпляр Azure для Apache Cassandra поддерживает кластеры в нескольких регионах. Другие службы данных обычно не могут поддерживать этот шаблон без значительной настройки.

Антипаттерны, которых следует избегать

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

Для реляционных баз данных эти антипаттерны включают:

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

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

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

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

Базы данных

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

• Безопасность на уровне строк может обеспечить изоляцию безопасности для данных конкретных клиентов в общей мультитенантной базе данных. Эта функция доступна в некоторых базах данных, таких как база данных SQL и гибкий сервер Базы данных Azure для PostgreSQL.

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

• Шифрование на уровне клиента может потребоваться для поддержки клиентов, которые предоставляют собственные ключи шифрования для своих данных. Эта функция доступна в SQL Server и Azure SQL в составе Always Encrypted. Azure Cosmos DB предоставляет управляемые клиентом ключи на уровне учетной записи, а также поддерживает Always Encrypted.

• Пул ресурсов позволяет разделять ресурсы и их затраты между несколькими базами данных или контейнерами. Эта функция доступна в эластичных пулах базы данных SQL, в Управляемом экземпляре SQL Azure и в пропускной способности базы данных Azure Cosmos DB.

• Шардирование и партиционирование имеют более развитую поддержку в одних службах, чем в других. Эта функция доступна в Azure Cosmos DB с помощью логического и физического секционирования. Хотя база данных SQL изначально не поддерживает сегментирование, она предоставляет средства сегментирования для поддержки этого типа архитектуры.

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

Хранилище файлов и BLOB-объектов

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

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

Распределение затрат

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

Как правило, облачные службы, такие как Azure Cosmos DB и Хранилище BLOB-объектов Azure, предоставляют более детализированные метрики для отслеживания и моделирования использования для конкретного клиента. Например, Azure Cosmos DB предоставляет потребляемую пропускную способность для каждого запроса и ответа.

Соавторы

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

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

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

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

• Пол Берпо | Главный инженер клиента, FastTrack для Azure
• Даниэль Скотт-Райнсфорд | Стратег технологий партнеров
• Арсен Владимирский | Главный инженер по работе с клиентами, FastTrack для Azure

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

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

Дополнительные сведения о мультитенантности и конкретных службах Azure см. в следующих ресурсах:

• Многотенантность и хранилище
• Многотенантность и база данных SQL
• Многопользовательская архитектура и Azure Cosmos DB
• Многотенантность и База данных Azure для PostgreSQL