Узор жеоды

Azure Cosmos DB

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

Контекст и проблема

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

Классический подход может вызвать следующие проблемы:

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

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

Решение

Разверните службу в нескольких спутниковых развертываниях, распределенных по всему миру, каждое из которых называется геодой. Шаблон геода использует ключевые функции Azure для маршрутизации трафика по кратчайшему пути к ближайшему геоду, что снижает задержку и улучшает производительность. Каждый геод находится за глобальной системой балансировки нагрузки и использует геораспределённую службу чтения и записи, такую как Azure Cosmos DB, для размещения уровня данных, обеспечивая согласованность данных между геодами. Службы репликации данных гарантируют, что хранилища данных идентичны между геодами, поэтому все запросы можно обслуживать со всех геодан.

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

Геодосы имеют следующие характеристики:

• Состоит из коллекции разрозненных типов ресурсов, часто определенных в шаблоне.
• Не имеют зависимостей за пределами структуры Geode и являются автономными решениями. Ни один геод не зависит от другого для работы, и если один выходит из строя, другие продолжают работать.
• Слабо связаны через периферийную сеть и шину репликации. Например, вы можете использовать Диспетчер трафика Azure или Azure Front Door для управления геоданными, в то время как Azure Cosmos DB может выступать в качестве основы репликации. Геоды не то же самое, что кластеры, потому что они используют общую репликационную инфраструктуру, поэтому платформа берет на себя заботу о проблемах кворума.

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

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

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

Проблемы и рекомендации

Используйте следующие методы и технологии для реализации этого шаблона:

• Современные методы и инструменты DevOps для создания и быстрого развертывания идентичных геод в большом количестве регионов или экземпляров.
• Автоматическое масштабирование для увеличения экземпляров вычислительных ресурсов и пропускной способности базы данных в геоде. Каждый геод масштабируется индивидуально в пределах ограничений общей магистрали.
• Интерфейсная служба, например Azure Front Door, которая выполняет динамическое ускорение содержимого, маршрутизацию через оптимальную точку присутствия и разделение TCP.
• Реплицируемое хранилище данных, например Azure Cosmos DB, для управления согласованностью данных.
• Бессерверные технологии, где это возможно, чтобы сократить затраты на развертывание всегда включенного сервиса, особенно если загрузка часто перераспределяется по всему миру. Эта стратегия позволяет развертывать множество геодов с минимальными дополнительными инвестициями. Бессерверные технологии и технологии выставления счетов на основе потребления сокращают потери и расходы за счет устранения дублирующихся геораспределенных развертываний.
• Управление API не требуется для реализации шаблона проектирования, но его можно добавить в каждый геод, который стоит перед приложением Azure Function App для обеспечения более надежного уровня API, что позволяет реализовать дополнительные функциональные возможности, такие как ограничение количества запросов, например.

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

• Выберите, следует ли обрабатывать данные локально в каждом регионе или распространять агрегаты в одном геоде и реплицировать результат по всему миру. Обработчик потока изменений Azure Cosmos DB предлагает этот детализированный элемент управления с использованием концепции контейнера аренды и leasecollectionprefix в соответствующем биндинге Функции Azure. Каждый подход имеет уникальные преимущества и недостатки.
• Геодимы могут работать в тандеме, используя канал изменений Azure Cosmos DB и платформу коммуникации в режиме реального времени, например SignalR. Геосети могут взаимодействовать с удаленными пользователями через другие геосети в шаблоне сетки, не зная или заботясь о расположении удаленного пользователя.
• Этот шаблон конструктора неявно отделяет все, что приводит к высоко распределенной и развязанной архитектуре. Рассмотрим, как отслеживать различные компоненты одного запроса, так как они могут выполняться асинхронно на разных экземплярах. Правильная стратегия мониторинга имеет решающее значение. Azure Front Door и Azure Cosmos DB можно легко интегрировать с Log Analytics и Функции Azure следует развертывать вместе с Application Insights, чтобы обеспечить надежную систему мониторинга на каждом компоненте в архитектуре.
• Распределенные развертывания имеют большее количество секретов и точек входа, требующих надлежащих мер безопасности. Key Vault предоставляет безопасный уровень для управления секретами, и каждый слой в архитектуре API должен быть правильно защищен, чтобы единственная точка входящего трафика для API была интерфейсной службой, такой как Azure Front Door. Azure Cosmos DB должен ограничить трафик к приложениям Azure Functions, а приложения Azure Functions — к Azure Front Door, используя Microsoft Entra ID или такие практики, как ограничение IP.
• Производительность резко зависит от количества развернутых геод и конкретных планов службы приложений, применяемых к технологии API в каждой геоде. Развертывание дополнительных геодов или переход на премиум-уровни сопровождаются увеличением затрат на дополнительную память и вычислительные ресурсы, но эти затраты не рассчитываются на каждую транзакцию отдельно. Рассмотрите возможность нагрузочного тестирования архитектуры API после развертывания и сравните увеличение числа геод с увеличением ценового уровня, чтобы выбрать наиболее экономичную модель, которая соответствует вашим потребностям.
• Определите требования к доступности данных. Azure Cosmos DB имеет необязательные флаги для включения многорегиональной записи, зон доступности и т. д. Это повышает доступность экземпляра Azure Cosmos DB и создает более устойчивый уровень данных, но при этом требует дополнительных затрат.
• Azure предлагает различные подсистемы балансировки нагрузки, предоставляющие различные функциональные возможности для распределения трафика. Используйте дерево принятия решений, чтобы выбрать подходящий вариант для внешнего интерфейса API.

Когда следует использовать этот шаблон

Используйте этот шаблон в следующих случаях:

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

Этот шаблон может не подходить для

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

Проектирование рабочей нагрузки

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

Колонна	Как этот шаблон поддерживает цели основных компонентов
Решения по проектированию надежности помогают рабочей нагрузке стать устойчивой к сбоям и обеспечить восстановление до полнофункционального состояния после сбоя.	Этот шаблон использует репликацию данных, чтобы поддержать идею о том, что любой клиент может подключиться к любому из географически распределённых экземпляров, и это помогает рабочей нагрузке выдерживать один или несколько региональных сбоев. - Проектирование нескольких регионов с высоким уровнем доступности RE:05 - Регионы и зоны доступности RE:05
Эффективность производительности помогает рабочей нагрузке эффективно соответствовать требованиям путем оптимизации масштабирования, данных, кода.	Этот шаблон можно использовать для обслуживания приложения из региона, ближайшего к базе распределенных пользователей. Это снижает задержки за счет устранения трафика на дальние расстояния и благодаря тому, что вы используете инфраструктуру совместно только с пользователями, которые в данный момент используют тот же географический узел. - PE:03 Выбор служб

Как и любое решение по проектированию, рассмотрите любые компромиссы в отношении целей других основ, которые могут быть представлены в этом шаблоне.

Примеры

• Windows Active Directory реализует ранний вариант этого шаблона. Репликация с несколькими первичными узлами означает, что теоретически все обновления и запросы могут обрабатываться с любых обслуживаемых узлов, но роли гибкой единой главной операции (FSMO) означают, что не все узлы равны.

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

Контекст и проблема

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

Классический подход может вызвать следующие проблемы:

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

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

Решение

Разверните службу в нескольких спутниковых развертываниях, распределенных по всему миру, каждое из которых называется геодой. Шаблон геода использует ключевые функции Azure для маршрутизации трафика по кратчайшему пути к ближайшему геоду, что снижает задержку и улучшает производительность. Каждый геод находится за глобальной системой балансировки нагрузки и использует геораспределённую службу чтения и записи, такую как Azure Cosmos DB, для размещения уровня данных, обеспечивая согласованность данных между геодами. Службы репликации данных гарантируют, что хранилища данных идентичны между геодами, поэтому все запросы можно обслуживать со всех геодан.

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

Геодосы имеют следующие характеристики:

• Состоит из коллекции разрозненных типов ресурсов, часто определенных в шаблоне.
• Не имеют зависимостей за пределами структуры Geode и являются автономными решениями. Ни один геод не зависит от другого для работы, и если один выходит из строя, другие продолжают работать.
• Слабо связаны через периферийную сеть и шину репликации. Например, вы можете использовать Диспетчер трафика Azure или Azure Front Door для управления геоданными, в то время как Azure Cosmos DB может выступать в качестве основы репликации. Геоды не то же самое, что кластеры, потому что они используют общую репликационную инфраструктуру, поэтому платформа берет на себя заботу о проблемах кворума.

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

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

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

Проблемы и рекомендации

Используйте следующие методы и технологии для реализации этого шаблона:

• Современные методы и инструменты DevOps для создания и быстрого развертывания идентичных геод в большом количестве регионов или экземпляров.
• Автоматическое масштабирование для увеличения экземпляров вычислительных ресурсов и пропускной способности базы данных в геоде. Каждый геод масштабируется индивидуально в пределах ограничений общей магистрали.
• Интерфейсная служба, например Azure Front Door, которая выполняет динамическое ускорение содержимого, маршрутизацию через оптимальную точку присутствия и разделение TCP.
• Реплицируемое хранилище данных, например Azure Cosmos DB, для управления согласованностью данных.
• Бессерверные технологии, где это возможно, чтобы сократить затраты на развертывание всегда включенного сервиса, особенно если загрузка часто перераспределяется по всему миру. Эта стратегия позволяет развертывать множество геодов с минимальными дополнительными инвестициями. Бессерверные технологии и технологии выставления счетов на основе потребления сокращают потери и расходы за счет устранения дублирующихся геораспределенных развертываний.
• Управление API не требуется для реализации шаблона проектирования, но его можно добавить в каждый геод, который стоит перед приложением Azure Function App для обеспечения более надежного уровня API, что позволяет реализовать дополнительные функциональные возможности, такие как ограничение количества запросов, например.

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

• Выберите, следует ли обрабатывать данные локально в каждом регионе или распространять агрегаты в одном геоде и реплицировать результат по всему миру. Обработчик потока изменений Azure Cosmos DB предлагает этот детализированный элемент управления с использованием концепции контейнера аренды и leasecollectionprefix в соответствующем биндинге Функции Azure. Каждый подход имеет уникальные преимущества и недостатки.
• Геодимы могут работать в тандеме, используя канал изменений Azure Cosmos DB и платформу коммуникации в режиме реального времени, например SignalR. Геосети могут взаимодействовать с удаленными пользователями через другие геосети в шаблоне сетки, не зная или заботясь о расположении удаленного пользователя.
• Этот шаблон конструктора неявно отделяет все, что приводит к высоко распределенной и развязанной архитектуре. Рассмотрим, как отслеживать различные компоненты одного запроса, так как они могут выполняться асинхронно на разных экземплярах. Правильная стратегия мониторинга имеет решающее значение. Azure Front Door и Azure Cosmos DB можно легко интегрировать с Log Analytics и Функции Azure следует развертывать вместе с Application Insights, чтобы обеспечить надежную систему мониторинга на каждом компоненте в архитектуре.
• Распределенные развертывания имеют большее количество секретов и точек входа, требующих надлежащих мер безопасности. Key Vault предоставляет безопасный уровень для управления секретами, и каждый слой в архитектуре API должен быть правильно защищен, чтобы единственная точка входящего трафика для API была интерфейсной службой, такой как Azure Front Door. Azure Cosmos DB должен ограничить трафик к приложениям Azure Functions, а приложения Azure Functions — к Azure Front Door, используя Microsoft Entra ID или такие практики, как ограничение IP.
• Производительность резко зависит от количества развернутых геод и конкретных планов службы приложений, применяемых к технологии API в каждой геоде. Развертывание дополнительных геодов или переход на премиум-уровни сопровождаются увеличением затрат на дополнительную память и вычислительные ресурсы, но эти затраты не рассчитываются на каждую транзакцию отдельно. Рассмотрите возможность нагрузочного тестирования архитектуры API после развертывания и сравните увеличение числа геод с увеличением ценового уровня, чтобы выбрать наиболее экономичную модель, которая соответствует вашим потребностям.
• Определите требования к доступности данных. Azure Cosmos DB имеет необязательные флаги для включения многорегиональной записи, зон доступности и т. д. Это повышает доступность экземпляра Azure Cosmos DB и создает более устойчивый уровень данных, но при этом требует дополнительных затрат.
• Azure предлагает различные подсистемы балансировки нагрузки, предоставляющие различные функциональные возможности для распределения трафика. Используйте дерево принятия решений, чтобы выбрать подходящий вариант для внешнего интерфейса API.

Когда следует использовать этот шаблон

Используйте этот шаблон в следующих случаях:

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

Этот шаблон может не подходить для

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

Проектирование рабочей нагрузки

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

Колонна	Как этот шаблон поддерживает цели основных компонентов
Решения по проектированию надежности помогают рабочей нагрузке стать устойчивой к сбоям и обеспечить восстановление до полнофункционального состояния после сбоя.	Этот шаблон использует репликацию данных, чтобы поддержать идею о том, что любой клиент может подключиться к любому из географически распределённых экземпляров, и это помогает рабочей нагрузке выдерживать один или несколько региональных сбоев. - Проектирование нескольких регионов с высоким уровнем доступности RE:05 - Регионы и зоны доступности RE:05
Эффективность производительности помогает рабочей нагрузке эффективно соответствовать требованиям путем оптимизации масштабирования, данных, кода.	Этот шаблон можно использовать для обслуживания приложения из региона, ближайшего к базе распределенных пользователей. Это снижает задержки за счет устранения трафика на дальние расстояния и благодаря тому, что вы используете инфраструктуру совместно только с пользователями, которые в данный момент используют тот же географический узел. - PE:03 Выбор служб

Как и любое решение по проектированию, рассмотрите любые компромиссы в отношении целей других основ, которые могут быть представлены в этом шаблоне.

Примеры

• Windows Active Directory реализует ранний вариант этого шаблона. Репликация с несколькими первичными узлами означает, что теоретически все обновления и запросы могут обрабатываться с любых обслуживаемых узлов, но роли гибкой единой главной операции (FSMO) означают, что не все узлы равны.