Мультиклауд: сценарии и задачи

Обычно переход к использованию нескольких облаков происходит стихийно и неосознанно: в подразделениях организации подключаются к различным нужным для бизнеса сервисам, которые предоставляются в разных облаках (см. рисунок). Иногда с облаками начинают работать, не ставя в известность ИТ-службы предприятия, и впоследствии приходится прилагать массу усилий, чтобы обеспечить безопасность «теневых ИТ» – несогласованных, но уже задействованных в бизнес-процессах сервисов, – и интегрировать их в существующую систему. Новые облака могут появляться в результате поглощения других компаний с их бизнес-процессами и ИТ-инфраструктурой, включая облачную составляющую. 

Переход происходит и эволюционно. Так, в 90-х в банке, где я работал, по соображениям безопасности был полностью запрещен интернет. Необходимость пользования электронной почтой и создания веб-сайта привела к возникновению в банке сети с выходом в интернет, физически изолированной от основной сети банка. Долго такое решение не просуществовало – появился интернет-банкинг, для которого нужен оперативный обмен данными с автоматизированной банковской системой, Центробанк начал запрашивать отчетные формы через интернет. По VPN-каналам через Глобальную сеть стали подключаться дополнительные офисы, кассы, банкоматы. Требовался безопасный доступ к внутренней сети, который удалось реализовать с помощью межсетевых экранов и демилитаризованных зон. В итоге сети объединились, и банк пришел к простой слабосвязанной мультиоблачной системе, которая описывается термином «мультиклауд 1.0». Дальнейшую эволюцию прервал отзыв лицензии. Но работы по переносу бизнес-процессов в облако уже шли. В облако ЦФТ отдали систему интернет-банкинга, что сильно разгрузило службу ИТ. Рассматривался вариант полного переноса банковских систем в облако ЦФТ, что уже сделали некоторые банки. Не выглядел фантастикой и дальнейший путь развития – не выступать точкой интеграции облачных сервисов, а передать ее облачному провайдеру, оставив за собой контроль и мониторинг процессов. 

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

Поэтому полный перенос, скажем, банковских систем в облако стороннего провайдера – редко встречающийся сценарий на российском рынке. Банки предпочитают эксплуатировать АБС на своих площадках, где они могут сами заниматься защитой чувствительных для бизнеса данных, сохранять тайну вкладов и контролировать состояние счетов. 

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

Предположим, мы хотим для минимизации репутационных рисков оперативно находить негативные отзывы о компании в Facebook. Отзывов бывает много, причем на разных языках. Облака предлагают разные по возможностям сервисы перевода. Для того чтобы использовать лучшие, придется заниматься интеграцией облаков. Например, в SaaS-решении компании YouScan, которое изначально базируется на Microsoft Azure, «под капотом» задействуются речевые технологии и «Яндекса», и Google, и AWS. 

Для качественного сканирования и распознавания контента пользоваться сервисами только одного провайдера неэффективно. Так, с распознаванием английского языка лучше справится Microsoft, а если нужно распознать киргизский язык, то больше подойдет Yandex SpeechKit.

Законодательные ограничения по защите данных существуют не только в России – аналогичные законы приняты и в других странах. Необходимость выполнения требований регуляторов заставляет международные компании искать локальных облачных провайдеров для размещения данных своих клиентов. Например, этим на российском рынке сейчас занимается международная компания по производству косметики Mary Kay.

Так же поступает один из клиентов «Яндекс.Облака», разработчик продуктов в сфере биоинформатики. По словам Олега Коверзнева, директора по развитию бизнеса «Яндекс.Облака», компания имеет единую архитектуру для работы во всех странах, при этом в каждом регионе выбирает местного облачного провайдера.

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

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

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

Перспективным выглядит использование мультиклауда для повышения устойчивости ИТ-систем к различным аварийным ситуациям – произошел ли в ЦОДе облачного провайдера пожар, перерубил ли экскаваторщик магистральный кабель, работоспособность бизнес-приложений пострадать не должна.

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

«Индустрия стремится к созданию мультиклауда 2.0, который должен обеспечить абсолютную отказоустойчивость. В таком решении на базе микросервисной архитектуры каждая функция реализована как отдельный контейнер, а контейнеры распределены между несколькими облачными провайдерами», – поясняет архитектор облачных решений компании Crayon Андрей Дубровин.

Пока такое решение технически невозможно из-за сложностей сетевого взаимодействия между облаками и сервисами разных провайдеров. Например, контейнеры, работающие в облаке Microsoft Azure, не будут «доверять» контейнерам облака Amazon, поскольку у каждого провайдера есть своя служба цифровых сертификатов, и эти службы между собой не взаимодействуют. Для устранения проблемы можно привлечь дополнительного участника и использовать его решение. Но этот третий участник может стать точкой отказа. Остается ждать договоренностей между лидерами облачной отрасли.

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

«К сожалению, нельзя просто взять и перевести рабочую нагрузку или приложение на рельсы мультиклауда – это комплексный, достаточно сложный и продолжительный по времени проект», – напоминает руководитель департамента R&D ActiveCloud Сергей Горлинский.

Заметили неточность или опечатку в тексте? Выделите её мышкой и нажмите: Ctrl + Enter. Спасибо!

<< Предыдущая статья   Вернуться к содержанию   Следующая статья >>