Дональд Файнберг, вице-президент и заслуженный аналитик группы ITL Data and Analytics (D&A) компании Gartner, рассказывает о различных видах облачных архитектур для управления данными и о том, почему руководителям подразделений D&A необходимо взвесить риски и преимущества каждой из них.

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

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

Поэтому такие решения, как облачная архитектура управления данными, имеют решающее значение. Руководители служб D&A должны знать о различных вариантах архитектуры — от онпремисных до мультиоблачных и межоблачных. Они должны понимать риски и преимущества, связанные с управлением данными в различных и распределенных средах развертывания.

Рассмотрим основные облачные архитектуры управления данными и соображения, на которые должны обратить внимание D&A-руководители.

1. От локальной до облачной среды

В модели «от онпремис до облака» (также известной как «от земли до облака») различные компоненты архитектуры приложений могут располагаться на локальных площадках и/или в одном облаке. Система управления базами данных может находиться онпремис, а приложения, которые к ней подключаются, например, приложение бизнес-аналитики (BI), — в облаке.

Существует две разновидности такой архитектуры:

  • активная (ранее «гибридное облако с разветвленной архитектурой»);
  • по требованию (ранее «гибридное облако для конкретного сценария использования»).

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

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

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

При подходе по требованию компоненты остаются раздельными. Данные перемещаются между средами только в тех случаях, когда это необходимо для поддержки бизнес-деятельности, например, планирования аварийного восстановления (DR) или функций жизненного цикла разработки. Так, любой из экземпляров СУБД для разработки, тестирования, обеспечения качества (QA), DR или производства может находиться как в локальной, так и в облачной среде. Хотя финансовые соображения и соображения задержки остаются важными, совместимость является главной проблемой в этом сценарии. Многим организациям нужна 100%-ная совместимость кода между облачной и локальной средами, что, в свою очередь, ограничивает выбор поставщиков облачных услуг (CSP) теми, кто может удовлетворить эти строгие требования.

Ключевые соображения при развертывании локальных и облачных сред включают: перемещение данных по объему и направлению (активная архитектура) и совместимость компонентов между средами (по требованию).

2. Мультиоблако

Мультиоблачная модель включает в себя один или несколько сервисов от нескольких облачных провайдеров (и опционально может включать локальные или гибридные архитектуры) — это главное отличие этого сценария. СУБД и приложения, которые на нее опираются, могут быть развернуты как онпремис, так и в одном или нескольких облаках.

Таким образом, все положения гибридного облака могут быть применимы к дополнительным соображениям о развертывании ПО в нескольких облачных средах. Исторически сложилось так, что такие предложения были доступны только от независимых поставщиков ПО (ISV), а не от нативных CSP, поскольку ISV больше заинтересованы в том, чтобы их ПО работало в максимально возможном количестве сред. Однако CSP все чаще используют сценарии мультиоблачных и межоблачных решений.

Мультиоблачный сценарий обычно привлекателен для конечных пользователей, которые обеспокоены проблемой привязки к CSP и хотят иметь возможность легко переносить свои приложения к другому облачному провайдеру. Предоставляя семантически совместимое предложение, которое одинаково работает в нескольких облаках и онпремис, СУБД с поддержкой мультиоблака обещают более легкую (хотя и не простую) миграцию, поскольку основной задачей будет перенос данных, а не переписывание приложений.

В любом случае, при развертывании СУБД в мультиоблачных средах D&A-руководителям необходимо учитывать совместимость компонентов между средами и различные возможности облачных сред по предоставлению ресурсов, управлению и контролю.

3. Интероблако

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

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

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