Облачный хостинг: модели и рекомендации
Для независимых поставщиков ПО
Независимые поставщики программного обеспечения (ISV) нуждаются в безопасных, масштабируемых и надежных платформенных и инфраструктурных сервисах для размещения своих приложений. Даже в большей степени, чем ИТ-организациям с бэк-офисными системами в облаке, независимым поставщикам ПО для сохранения конкурентоспособности необходимы круглосуточная работоспособность, географически распределенные развертывания, эластичное масштабирование в соответствии с динамикой клиентского трафика, а также решение проблем безопасности, обусловленных доступностью приложения через Интернет.
Любой независимый поставщик ПО, который планирует прибегнуть к услугам одного или нескольких провайдеров гипермасштабируемого облака или уже работает с такими провайдерами, должен принять во внимание множество факторов. Следует ли просто перенести приложение в облако или использовать миграцию в качестве возможности для пересмотра архитектуры в сторону приближения к "нативно облачной" и, возможно, начать использовать управляемые провайдером PaaS-сервисы? Может ли облачное развертывание кардинально изменить ваши позиции в плане высокой доступности и аварийного восстановления, позволив вам использовать домены сбоя в ЦОД, домены доступности в регионе или кросс-региональные межсоединения? Какие инструменты предлагает ваш облачный провайдер для защиты данных, внутренней сети, вычислительных хостов/контейнеров, а также взаимодействия с клиентами? Наконец, будет ли ваше приложение развернуто в виде мультиарендного решения SaaS или в виде одноарендной конфигурации для каждого из ваших клиентов?
Помимо сотен приложений, перенесенных Oracle в OCI, наши специалисты по проектированию облачных решений помогли десяткам независимых поставщиков ПО спланировать и осуществить переход в OCI. На этом микросайте вы найдете рекомендации и ряд типовых решений хостинга для независимых поставщиков ПО.
Мы рассматриваем соответствующие темы через призму различных подходов к внедрению Oracle Cloud.
Этот микросайт не следует читать линейно. На схеме ниже показана примерная схема работы с этим сайтом в зависимости от вашей специфики. Прочитав это введение, переходите к разделу Как мы работаем, а затем, в зависимости от вашей текущей модели хостинга, прочитайте раздел Рожденные в облаке или Локальный ЦОД/колокация. Затем прочитайте раздел Мультиарендная модель SaaS или Одноарендная модель SaaS – в зависимости от того, какую модель доставки приложений вы используете. И наконец, всем читателям следует прочитать общий раздел Сквозные факторы, а также Заключение.
Как мы работаем
- "Рожденные в облаке"
- Локальный ЦОД/колокация
- Мультиарендная модель доставки приложений
- Одноарендная модель доставки приложений
Многие независимые поставщики ПО, предоставляющие свои продукты по модели SaaS, "рождены в облаке". Несмотря на схожесть обозначений, это не то же самое, что "облачно нативные". Говоря "рожденный в облаке", мы обычно подразумеваем, что независимый поставщик ПО больше не привязывается к старым системам и стремится строить свои продукты с соблюдением принципов современного проектирования приложений. Современное проектирование приложений – это набор архитектурных принципов, соответствующих методологии "12-факторное приложение". Это не то же самое, что нативная облачная архитектура, но тесно связано с ней. Тем, кого интересует более детальное рассмотрение "облачной нативности" с точки зрения Oracle, рекомендуем ознакомиться с электронной книгой Облачно-нативные шаблоны, посвященной проектированию облачно-нативных приложений.
Независимо от того, создано ли SaaS-приложение по принципам современного проектирования приложений или по принципам облачной нативности, существуют некоторые ключевые факторы, которые будут одинаковыми в обоих случаях:
- Желание следовать современным принципам разработки приложений
- Желание сосредоточиться на приложении, а не на инфраструктуре
- Сокращение времени окупаемости функциональных возможностей
- Непрерывное, надежное и повторяемое развертывание
- Дистанцирование от того, что рассматривается как "старые" системы или однородные системы, построенные на продуктах одного поставщика
- Желание строить, эксплуатировать и обслуживать современную архитектуру
- Желание работать с гибкостью, возможной благодаря облачными вычислениями
Независимые поставщики ПО, которые исходят из этих целей, обычно имеют сервисную архитектуру с меньшей степенью зацепления, или связанности. Компоненты приложения в их рабочей нагрузке могут развертываться независимо друг от друга – зачастую в виде контейнеров, – причем архитектура приложения предусматривает возможность продолжения его работы в случае отказа компонента. Приложения должны обеспечивать не только целостность данных, но и доступность самого приложения.
В зависимости от выбранной архитектуры среды выполнения в систему управления инфраструктурой, скорее всего, будут интегрированы средства мониторинга и оповещения. OCI предоставляет сервисы для поддержки:
- облачных событий CNCF – посредством Cloud Events Service;
- трассировки. CNCF OpenTracing входит в состав нашей облачной платформы наблюдаемости и управления и обеспечивает полную функциональную совместимость с бессерверной платформой Cloud Functions и сервисом Notifications, что упрощает не только управление жизненным циклом парка серверов, но и решение задач стратегического управления.
Межкомпонентный обмен данными обычно реализуется по асинхронной схеме, то есть вместо непосредственных инструкций компоненты отправляют события и отвечают на них. В OCI предусмотрен сервис Streaming – совместимая с Kafka бессерверная платформа потоковой передачи событий, которую часто используют для реализации такого обмена данными. Преимущество этого подхода – защита компонентов в случае отказа: радиус поражения уменьшается за счет использования интеллектуального управления очередями или маршрутизации.
Дополнительное расцепление достигается за счет отделения приложений от инфраструктуры. Обеспечение эластичности часто достигается путем использования механизмов автомасштабирования, предоставляемых поставщиком облачных услуг (CSP). Автомасштабирование может происходить на уровне контейнера с использованием Oracle Kubernetes Engine (OKE), на уровне группирования экземпляров или на уровне серверной группы.
Со временем некоторые SaaS-приложения отклоняются от своей первоначально спланированной основанной на стандартах архитектуры, поскольку разработчики начинают использовать нативные PaaS-сервисы, предоставляемые одним CSP. Примеры включают в себя: использование службы управления данными, которая является эксклюзивной для данного облака, встраивание прямого вызова API к "заточенной" под данного поставщика платформе NoSQL без надлежащих уровней абстракции в реализации, которые позволили бы заменить этот вызов в будущем, или использование сред разработки, которые генерируют специфический для данного поставщика код. Для поддержания облачной переносимости независимым поставщикам ПО необходимо тщательно соблюдать равновесие между удобством платформенного сервиса и риском зависимости от конкретного поставщика, который возникает, когда сервис не является "вендоронейтральным". Многие независимые поставщики ПО начали ремодернизацию своих приложений, стремясь сделать их по-настоящему мультиоблачными. Для этого они пересматривают точки тесного зацепления с технологиями одного поставщика или одного назначения.
Со временем может в конфигурации инфраструктуры может возникать дрейф. Большинство независимых поставщиков ПО принимают на вооружение подход "инфраструктура как код" (IaC), причем OCI поддерживает ставшие отраслевым стандартом инструменты плюс дополнительный механизм: OCI Resource Manager. Это управляемый сервис Terraform, который может использоваться для мониторинга, отслеживания и коррекции дрейфа в инфраструктуре.
Стратегия Lift-and-Shift, или простое перемещение, заключается в переносе ваших рабочих нагрузок, запущенных локально или в ЦОД с колокацией, в Oracle Cloud Infrastructure (OCI). В некоторых случаях у вас может возникнуть желание воспользоваться нативными облачными сервисами, предлагаемыми в OCI, для обогащения своих приложений. Такой подход, в котором перенос сочетается с усовершенствованием (Move-and-Improve), – еще одна веская причина перейти в OCI. В следующих разделах мы рассмотрим процесс Lift-and-Shift и некоторые соображения, связанные с Move-and-Improve.
Этот сценарий идеально подходит для независимых поставщиков ПО, которым хотелось бы уменьшить капитальные затраты и делегировать часть связанных с доступностью, безопасностью и производительностью операционных сложностей поставщику облачных услуг (CSP) – например, Oracle. Как правило, независимый поставщик ПО реализует одну из следующих стратегий:
- Lift-and-Shift: миграция локальных или совместно размещенных приложений в OCI
- Move-and-Improve: перенос локальных или размещенных в ЦОД с колокацией приложений в OCI и их обогащение путем использования облачно нативных сервисов или миграции баз данных на облачные платформы.
Ничто не мешает вам смешивать эти стратегии – одни рабочие нагрузки переносить "как есть", а другие модифицировать для использования в них управляемых сервисов OCI (PaaS).
Lift-and-Shift
Стратегия облачной миграции Lift-and-Shift заключается в перемещении вашего локального приложения в OCI так, чтобы итоговое развертывание мало чем отличалось от локального развертывания. Первым шагом этого процесса является определение рабочих нагрузок/приложений, которые позволят вам использовать возможности OCI и достичь ваших стратегических целей. У нас есть множество вариантов хостинга, из которых вы можете выбрать наиболее соответствующий вашим требованиям к местонахождению данных, задержкам и возможностям подключения. Вне зависимости от того, какой из следующих типов хостинга вы выберете, у вас будет доступ ко всему портфелю сервисов OCI.
| Тип хостинга | Описание |
|---|---|
| Публичное облако | Универсальная платформа сервисов IaaS, PaaS и SaaS |
| Government Cloud (области с ограниченным доступом) | Универсальная платформа сервисов IaaS, PaaS и SaaS, развернутая в области с ограниченным доступом для организаций государственного сектора |
| Выделенные региональные решения Cloud@Customer | Универсальная платформа сервисов IaaS, PaaS и SaaS, развернутая в вашем центре обработки данных |
| Инфраструктура Roving Edge | Универсальная платформа сервисов IaaS, PaaS и SaaS, развернутая на устройствах Oracle Roving Edge (Oracle RED) (в защищенном исполнении), для предоставления услуг облачных вычислений и хранения на сетевой периферии и в местах без сетевых подключений |
| Oracle Cloud VMWare | Позволяет перенести в облако рабочие нагрузки на базе VMware или расширить локальный VCenter для поддержки облачных вычислений, без изменения архитектуры приложений или переоснащения операций |
При проектировании облачной архитектуры следует понимать, что Oracle поддерживает множество вариантов сетевых подключений, что дает возможность построить гибридное облачное решение, где ресурсы OCI сочетаются с компонентами, работающими в вашем центре обработки данных, или мультиоблачное решение для соединения вашей среды OCI с ресурсами другого поставщика облачных услуг. Оба эти подхода весьма распространены и способны облегчить миграцию рабочих нагрузок с зависимостями от существующих приложений, запускаемых локально или в облачных средах других поставщиков, а также соблюдение требований к хранению данных в определенном регионе, требований SLA и других требований.
Обмен данными в таких случаях OCI обеспечивает через общедоступный Интернет, через IPSec VPN или с использованием выделенного подключения (FastConnect). В следующей таблице описаны некоторые характеристики каждого из этих подходов:
| Метод | Задержка | Стоимость | Надежность | Безопасность |
|---|---|---|---|---|
| Общедоступный Интернет | Варьируется | Варьируется | Варьируется | Самая низкая |
| IPSec VPN | Варьируется | Варьируется | Варьируется | Трафик шифруется, но туннель проходит через общедоступный Интернет. |
| OCI FastConnect | Низкая и предсказуемая | Предсказуемая | Самая высокая | Самая высокая; трафик проходит через частное подключение |
Кроме того, хотя межсоединение "облако-облако" с использованием упомянутых выше технологий возможно между OCI и любым другим облаком, у Oracle есть партнерское соглашение с Microsoft Azure об обеспечении взаимодействия с малой задержкой между обоими облаками во многих регионах по всему миру.
У Oracle есть ряд партнеров, которые специализируются на автоматизации миграции в OCI из любого количества источников, включая общедоступные облака конкурентов и виртуализированные/невиртуализированные локальные среды. Полный список поставщиков, оказывающих услуги по миграции, можно найти у нас на Marketplace. В качестве заслуживающих внимания примеров можно назвать Rackware и ZConverter.
Если речь идет о миграции Oracle Database из других облаков или локальных сред, Oracle предоставляет ряд инструментов для проведения автономной миграции или миграции с нулевым временем простоя/в реальном времени. К этим инструментам относятся Zero Downtime Migration (ZDM), OCI Database Migration (DMS), GoldenGate, DataPump, RMAN и другие. Выбор инструмента зависит от характеристик исходной и целевой базы данных, а также вашей операционной среды. Более подробную информацию можно получить на странице, посвященной миграции баз данных в облако.
Move-and-Improve
Стратегия Move-and-Improve, или перемещение с улучшением, предполагает обогащение существующего сервиса или его замену облачным аналогом. При определении кандидатов на перенос в облако первое, чему стоит уделять внимание, – это возможность обогащения или замены сервисов. Например, вы можете улучшить существующие локальные приложения, перенеся локальную базу данных ключевого приложения на наш управляемый сервис Database Cloud Service, в нашу топовую самоуправляемую СУБД Autonomous Database или на Exadata Cloud Service – самую быструю платформу для баз данных Oracle в облаке.
Кроме того, переход на Oracle Cloud Infrastructure открывает вам доступ ко всему портфелю сервисов, как то:
- Data Science Cloud, в состав которого входят такие технологии, как машинное обучение, ИИ и Big Data Service;
- Applied Technologies Software, в состав которого входят цифровые помощники и блокчейн;
- Application Development, в состав которого входят Container Engine for Kubernetes, APEX (малокодовая разработка), Visual Builder Studio (непрерывная интеграция и поставка) и Mobile Hub;
- Сервисы безопасности, к которым относятся WAF, Identity & Access Management, Cloud Guard и Access Security Broker
- Analytics Cloud
Мультиарендная модель доставки для поставщиков SaaS предполагает использование программного обеспечения, работающего на общей инфраструктуре, для обслуживания отдельных конечных клиентов независимых поставщиков ПО (арендаторов).
Клиентские данные обычно хранятся в наборе общих таблиц, и все уровни приложения "знают" уникальный идентификатор клиента. Приложение само поддерживает работу с несколькими клиентами. Обычно приложение также само отвечает за управление подписками пользователей. Кроме того, инфраструктуру также необходимо разделить на серверные группы в зависимости от количества клиентов, транзакций и нормативных требований, которые она должна поддерживать.
Почему стоит выбрать эту модель
Мультиарендная модель обеспечивает независимому поставщику ПО определенные преимущества. Прежде всего это экономия, обеспечиваемая эффектом масштаба. Поскольку состав серверной группы хорошо известен, повышается эффективность управления и мониторинга инфраструктуры. Запуск новых сервисов сводится к выполнению кода автоматизации инфраструктуры и развертыванию приложения. Общий набор инфраструктуры также дает возможность использовать единую консоль для мониторинга.
Размещение клиентов на общих вычислительных ресурсах, с одним хранилищем и базой данных позволяет обходиться без сложных стратегий развертывания приложений. У использующих эту модель независимых поставщиков ПО обычно единая база кода, что упрощает развертывание обновлений для всей клиентской базы. Многие из них дают клиентам возможность активировать новые функции с помощью флагов функций.
Конечно, кроме преимуществ есть и недостатки. Для обслуживания клиентов, предъявляющих те или иные требования к местонахождению данных, необходима стратегия развертывания по регионам; также возможны сценарии, когда бизнес-требования клиентов не позволяют обрабатывать их данные на тех же серверах, что и данные конкурентов. В зависимости от архитектуры приложения клиенты также могут страдать от эффекта "шумного соседа". Когда серверная группа становится перегруженной, независимому поставщику ПО необходимо принимать решение: либо перевести клиента на новую, менее загруженную группу, либо увеличить емкость существующей.
Одно из следствий использования мультиарендной модели SaaS заключается в том, что архитектура приложения должна быть продуманной и спланированной с большей тщательностью, чем при одноарендной схеме. С самого начала в структуре приложения необходимо предусмотреть надлежащие механизмы управления доступом и модели сегрегации данных, и у независимых поставщиков ПО должны быть инженеры, способные это обеспечить.
Oracle может восполнить этот пробел: наши облачные архитекторы помогут модернизировать ваше приложение и доработать его для успешной эксплуатации в облаке. Работая с независимыми поставщиками ПО самых разных направлений, наши архитекторы обладают огромным опытом и скорее всего уже сталкивались с проблемами, которые возникнут у вас на пути в облако.
Изоляция серверных групп
Ключевой предпосылкой мультиарендной модели является общая среда для размещенных арендаторов. Соответственно, архитектура SaaS -приложения должна предусматривать надлежащую сегрегацию и защиту клиентских данных во время выполнения. Также вам как независимому поставщику ПО необходимо осуществлять мониторинг различных серверных групп, в которых размещается ваше приложение, и управлять всем, что в них происходит.
У вас могут быть особые требования – например, данные клиентов из одних регионов должны обрабатываться отдельно от данных клиентов из других регионов (или субрегионов). Такую сегрегацию можно обеспечить путем развертывания рабочих нагрузок в определенном сочетании регионов и секций OCI. В качестве примера этого можно привести поставщика SaaS в США, который обслуживает как учреждения здравоохранения, так и производственные компании. Этот поставщик может использовать регионы и секции для сегрегации соответствующих рабочих нагрузок и предоставления дифференцированных возможностей (например, обеспечение соответствия HIPAA/HITRUS для учреждений здравоохранения).
Одним из естественных направлений эволюции для независимых поставщиков ПО, предпосылкой которого стала мультиарендная модель, является совершенствование предлагаемых сервисов для улучшения изоляции клиентских данных. Обычно это происходит сначала на уровне данных, и Oracle Database поддерживает мультиарендную модель, позволяющую иметь независимые модульные базы данных в единой базе данных, играющей роль контейнера.
Одноарендная модель доставки предполагает использование для обслуживания отдельных конечных клиентов независимых поставщиков ПО, работающего на выделенной инфраструктуре. В отличие от мультиарендной модели, в которой множество клиентов используют одни и те же вычислительные циклы и данные в общих таблицах баз данных, одноарендная модель строится на отдельных виртуальных машинах, отдельных базах данных и отдельной поддерживающей инфраструктуре (балансировщиках нагрузки, очередях сообщений и т. п.) для каждого клиента.
Почему стоит выбрать эту модель
Одноарендная модель обеспечивает независимому поставщику ПО ряд преимуществ. Отдельные вычислительные ресурсы, ресурсы хранения и базы данных для каждого клиента/арендатора существенно упрощают разделение интересов как с точки зрения безопасности, так и с точки зрения производительности. Клиент А не сможет повлиять на клиента Б ни злонамеренными действиями, ни случайным потреблением ресурсов в превышающем его долю объеме. Кроме того, уменьшается радиус поражения при катастрофическом отказе: отказ одного компонента (например, базы данных или очереди сообщений) повлияет на одного клиента, а не на все SaaS-приложение. У каждого арендатора своя собственная среда с уникальными функциями и исправлениями, что обеспечивает максимальную клиентоориентированность.
Конечно, не обходится и без недостатков. Все преимущества, связанные, например, с создание персонализированных для каждого клиента сред, компенсируются дополнительным бременем управления конфигурациями и увеличением трудозатрат на мониторинг и обслуживание. Из других преимуществ этого подхода многие можно реализовать и в мультиарендной модели, хотя это потребует более скрупулезного проектирования и реализации SaaS-приложения.
В конечном итоге решение сводится к тому, готов ли независимый поставщик ПО делать инвестиции в адаптацию своего SaaS-приложения к мультиарендной модели, а значит, есть ли у него внутренние ресурсы с навыками разработки программного обеспечения. В противном случае ему имеет смысл положиться на возможности секционирования, предусмотренные его программной платформой и/или гипермасштабируемым облаком. Каждый независимый поставщик ПО принимает это решение исходя из своей уникальной ситуации.
Oracle может помочь вам сделать правильный выбор: наши архитекторы проконсультируют вас и помогут модернизировать ваше приложение, доработав его для успешной эксплуатации в облаке. Работая с независимыми поставщиками ПО самых разных направлений, наши архитекторы обладают огромным опытом и скорее всего уже сталкивались с проблемами, которые возникнут у вас на пути в облако.
Изоляция арендаторов
Ключевой предпосылкой одноарендной модели является наличие изолированной среды для каждого арендатора. Вам как независимому поставщику ПО необходимо выделить для каждого из своих клиентов отдельные вычислительные ресурсы, сетевые ресурсы, ресурсы хранения, ресурсы обмена сообщениями и ресурсы базы данных. Это нужно сделать таким образом, чтобы эти ресурсы были сегрегированы друг от друга как с точки зрения выполнения, так и с точки зрения управления.
В OCI предусмотрена уникальная функция секционирования, которая обеспечивает надежное логическое разделение любых ресурсов OCI. Вы можете поместить всю клиентскую среду – включая сетевые, вычислительные ресурсы и т. д. – в секцию и написать политики OCI, которые будут контролировать доступ к этим ресурсам. Используя эти два базовых механизма OCI, вы можете полностью отделить клиента А от клиента Б и не допустить никакого "перекрестного заражения" ресурсов, управления или информации. Секции имеют иерархическую структуру, поэтому вы можете вкладывать одни секции в другие и моделировать сложные клиентские конфигурации. Например, представьте себе компанию-клиента с несколькими бизнес-направлениями, которой хотелось бы обеспечить сегрегацию между подразделениями, но в то же время иметь некоторые общекорпоративные ресурсы.
Модель секционирования обеспечивает максимальные гарантии сегрегации, однако есть и некоторые промежуточные подходы, которые можно применять на определенных уровнях приложения для улучшения использования ресурсов, не прибегая к узкоспециализированному методу разделения арендаторов. Например, вместо того чтобы создавать отдельную систему баз данных для каждого клиента, вы можете использовать мультиарендные возможности баз данных Oracle для реализации единой контейнерной базы данных с множественными подключаемыми схемами. Такой подход исключает накладные расходы, связанные с созданием нескольких кластеров баз данных, при этом позволяя обеспечивать разделение за счет механизмов базы данных, без переписывания схемы приложения. Предлагаемая Oracle "база данных как услуга" на виртуальных машинах и серверах без операционной системы поддерживает мультиарендность уже в стандартной конфигурации, как и Autonomous Dedicated Database – СУБД, которую можно использовать для самых интенсивных рабочих нагрузок.
Использование этого промежуточного подхода поддерживается не только на уровне данных. Если ваше приложение контейнеризовано, вы можете использовать Container Engine for Kubernetes (OKE) для развертывания нескольких клиентских контейнеров в одной инфраструктуре. В этом случае вы можете использовать нативные примитивы Kubernetes, такие как пространства имен, управление доступом на основе ролей (RBAC), секреты и квоты ресурсов, для обеспечения разделения арендаторов. Как и в случае с базой данных, вместо того чтобы переписывать приложение для разделения арендаторов, вы можете просто прибегнуть к возможностям базовых облачных сервисов.
Почему независимые поставщики ПО выбирают Oracle Cloud
Благодаря широкому спектру услуг и поддержки OCI независимые поставщики ПО приносят больше пользы своим клиентам.
Сквозные факторы
Возможно, вы из числа "рожденных в облаке" независимых поставщиков ПО и разрабатываете одноарендную инфраструктуру SaaS с использованием возможностей, обеспечиваемых вашим гиперскейлером. Возможно, вы начали с локального решения и переносите свое мультиарендное SaaS-приложение, чтобы оно работало исключительно в облаке. Или, возможно, ваша ситуация представляет собой некоторое сочетание этих подходов. Вне зависимости от того, как вы пришли к облаку, каждому работающему в облаке независимому поставщику ПО необходимо учитывать так называемые сквозные факторы – например, безопасность, наблюдаемость, непрерывность бизнес-процессов и автоматизацию. В следующих разделах мы рассмотрим, как Oracle помогает решать эти функциональные задачи, и что отличает нас от наших конкурентов.
Безопасность, стратегическое управление и соблюдение нормативных требований
Подход Oracle заключается в том, что меры безопасности должны реализовываться по умолчанию, должны быть простыми и носить предписывающий характер. Также мы считаем, что клиенты не должны выбирать между стоимостью и безопасностью, и стремимся предоставлять все связанные с безопасностью сервисы бесплатно или по минимальной стоимости. (Одновременно наши партнеры предлагают альтернативные решения на Oracle Marketplace.) Мы уверены, что взломы систем защиты происходят не из-за того, что средств нейтрализации уязвимостей не существует, а из-за того, что эти средства либо слишком дорогостоящи, либо слишком сложны в эксплуатации для большинства организаций.
Oracle считает, что ответственность за безопасность несут совместно поставщик облачных услуг и независимый поставщик ПО. Мы предоставляем определенные базовые возможности, такие как изолированная виртуализация сети и аппаратный корень доверия, и дополняем их инструментами и услугами, которые независимый поставщик ПО может использовать для повышения уровня безопасности своих решений. Если вас интересует обзор наших предложений в области безопасности, начните с нашей главной страницы по безопасности и архитектуры облачной безопасности.
Безопасность начинается с продуманной реализации управления идентификацией и доступом (IAM), в которой управление доступом на основе ролей сочетается с нашей интуитивной понятной системой политик. Эта функциональность охватывает множество аспектов, включая пользователей, группы, федерацию удостоверений и авторизацию субъектов-экземпляров/субъектов-ресурсов. Еще одна базовая концепция безопасности, пусть и не охватываемая IAM, связана с определяемыми пользователем сетями и строится на правилах сетевой безопасности, группах и списках.
При разработке безопасной технической архитектуры в Oracle Cloud Infrastructure (OCI) хорошей отправной точкой является Центр интернет-безопасности (CIS) – коммерчески нейтральная организация, которая каталогизирует лучшие практики в сфере безопасности. Одной из разработок CIS является стандарт безопасности для приложений OCI, в ответ на который мы разработали средство автоматизации, которое помогает независимым поставщикам ПО обеспечивать выполнение рекомендаций CIS посредством Terraform.
В OCI предусмотрен ряд других фундаментальных сервисов для обеспечения безопасности, например:
- управление ключами шифрования и секретами;
- сканирование хостов, контейнеров и сетей на предмет уязвимостей;
- возможности управления API и обеспечения безопасности, такие как защита от DDoS-атак, управление доступом к API и интеграция идентификации;
- брандмауэр веб-приложений (WAF), поддерживающий аналитику угроз, политики соответствия требованиям безопасности и адаптивное управление ботами;
- сервис бастионов, позволяющий клиентам предоставлять ограниченный (в том числе по времени) доступ к защищенным ресурсам;
- сервис сертификатов, позволяющий хранить сертификаты криптографии с открытым ключом (PKCS) и управлять ими.
Выше в стеке находится уникальная функциональность OCI – зоны максимальной безопасности, которые обеспечивают автоматическую настройку и применение политик безопасности в OCI. Это позволяет реализовать декларативную безопасность с использованием передовых практик безопасности и обеспечивает упреждающий, а не реактивный подход к безопасности для наиболее важных ресурсов.
Наконец, ни одна система безопасной не будет полной без управления состоянием безопасности, которое обеспечивается сервисом Cloud Guard для всех ваших ресурсов OCI и сервисом Data Safe для рабочих нагрузок баз данных. Оба сервиса предоставляются клиентам OCI бесплатно и гарантируют, что все неправильно настроенные ресурсы и небезопасная активность будут быстро обнаружены и устранены – автоматически по готовым рецептам безопасности или путем отправки данных в системы SIEM/SOC.
Наблюдаемость
Всем организациям необходима возможность собирать информацию о работе своих облачных ресурсов – как для обеспечения текущих операций, так и для ИТ-планирования. Независимым поставщикам ПО требуются более широкие возможности, поскольку обычно они имеют дело с нестандартными приложениями, измерять производительность которых сложнее. Кроме того, рабочие нагрузки независимых поставщиков ПО могут запускаться в облачных масштабах с круглосуточно активной внешней клиентской базой, а значит, предъявлять более высокие требования к времени непрерывной работы, чем типовая бэк-офисная система.
На базовом уровне OCI предоставляет сервис Monitoring, который позволяет в реальном времени анализировать производительность рабочих нагрузок в OCI с помощью стандартных метрик работоспособности и производительности. Пользователи могут настраивать сигналы тревоги для выявления аномалий и реагирования на них. Этот сервис работает в паре с сервисом Logging, который обеспечивает доступ к журналам OCI в дополнение к журналам, генерируемым вашими рабочими нагрузками. Любые состояния или проблемы, выявленные с помощью упомянутых выше сервисов, могут быть обработаны сервисом Notifications, который представляет собой высокодоступную систему публикации и подписки с малой задержкой, которая отправляет сигналы бессерверным функциям (для автоматического устранения), по электронной почте, в виде SMS-сообщений или через Slack и PagerDuty.
На более высоких уровнях стека Oracle предоставляет ряд сервисов на базе машинного обучения (МО), которые обеспечивают более глубокий анализ журналов, производительности приложений, производительности баз данных и операций. Сервис Logging Analytics позволяет отслеживать, агрегировать, индексировать и анализировать все данные журналы, а также использовать МО для визуального выявления проблемных кластеров и аномалий. Application Performance Monitoring – это основанный на стандартах (таких как OpenTracing и OpenMetrics) сервис, который обеспечивает синтетический мониторинг, распределенную трассировку и анализ выполнения транзакций нестандартных приложений, включая нативную поддержку телеметрии микросервисов из сред Kubernetes/Docker, предлагаемых многими независимыми поставщиками ПО. Сервис Database Management предоставляет возможности мониторинга парков Oracle Database, а сервис Ops Insights позволяет администраторам выявлять проблемы с производительностью, прогнозировать потребление и планировать емкость с использованием машинного обучения и аналитики. Организации могут использовать эти возможности для принятия решений на основе данных с целью оптимизации использования ресурсов, упреждающего предотвращения сбоев и повышения производительности.
Вся эта связанная с наблюдаемостью функциональность предоставляется в качестве интегрированных сервисов в OCI и предусматривает обширные "бесплатные уровни", которые позволяют независимым поставщикам ПО использовать эти сервисы в ограниченных сценариях и в случае успеха расширять их применение.
Непрерывность бизнес-процессов
Требования к непрерывности бизнес-процессов, предъявляемые независимыми поставщиками ПО, зачастую бывают жестче существующих в традиционных организациях. Тогда как отказ традиционных бэк-офисных систем, таких как HCM- или ERP-системы, создает проблему для организации, большинство независимых поставщиков ПО не могут допускать даже временных перерывов в работе своих обращенных к клиентам систем, на которых полностью строится их бизнес. В этой связи огромную важность приобретают такие концепции, как высокая доступность (HA) и аварийное восстановление (DR), и независимым поставщикам ПО стоит по максимуму использовать возможности OCI в этих областях.
Высокая доступность
Регион OCI – это локализованная географическая область, состоящая из одного или нескольких доменов доступности, в каждый из которых входит три домена отказоустойчивости. Высокая доступность обеспечивается избыточностью доменов отказоустойчивости в доменах доступности.
Домен доступности – это один или несколько центров обработки данных, расположенных в пределах региона. Домены доступности изолированы друг от друга, отказоустойчивы, и их одновременный выход из строя маловероятен. Поскольку домены доступности не имеют общей физической инфраструктуры, такой как источник питания, система охлаждения или внутренняя сеть домена доступности, маловероятно, что сбой, затронувший один домен доступности, повлияет на другие.
Домен отказоустойчивости – это группа единиц оборудования и компонентов инфраструктуры в пределах домена доступности. Каждый домен доступности содержит три домена отказоустойчивости. Домены отказоустойчивости позволяют распределять экземпляры таким образом, чтобы они не находились на одном и том же физическом оборудовании в пределах одного домена доступности. В результате сбои оборудования или мероприятия обслуживания, влияющие на один домен отказоустойчивости, не влияют на экземпляры в других доменах отказоустойчивости.
Все домены доступности в регионе связаны друг с другом сетью с низкой задержкой и широкой полосой пропускания. Это шифрованное соединение между доменами доступности, обладающее предсказуемыми характеристиками, обеспечивает стандартные блоки для достижения высокой доступности и поддерживает аварийное восстановление.
Вы можете разрабатывать решения, охватывающие несколько регионов, несколько доменов доступности или несколько доменов отказоустойчивости – в зависимости от класса отказов, защиту от которых хотите реализовать.
В OCI также предусмотрено множество функций и параметров, которые вы можете использовать для защиты своих сетевых ресурсов, систем хранения и ресурсов баз данных от локализованных отказов. В качестве отправной точки рекомендуем полностью прочитать Руководство по решениям высокой доступности в Центре архитектуры OCI и выбрать решения, соответствующие вашей операционной модели.
Аварийное восстановление
Аварией может быть любое событие, которое ставит под угрозу работу ваших приложений – от сетевых сбоев и отказов оборудования до стихийных бедствий. Хорошо продуманный план аварийного восстановления (DR) позволяет быстро восстанавливаться после аварий и продолжать предоставлять услуги пользователям. Предусмотренные в OCI возможности аварийного восстановления строятся поверх механизмов высокой доступности, описанных в предыдущем разделе.
При разработке стратегии аварийного восстановления необходимо прежде всего рассмотреть целевое время восстановления (RTO) и целевую точку восстановления (RPO). RTO – это целевое время восстановления, необходимое для восстановления функциональности приложения после аварии. Как правило, чем критичнее приложение, тем меньше RTO. RPO – это период времени после аварии, потеря данных приложения в течение которого не успевает оказать негативное влияние на бизнес.
Следующий шаг – это определение того, какой аварийный сценарий должна предусматривать ваша архитектура. От чего вы пытаетесь защититься: от отказа приложения, отказа сети, отказа ЦОД, региональных отключений или всего вышеперечисленного? Ответ на этот вопрос в сочетании с вашими RTO/RPO будет определять вашу стратегию аварийного восстановления.
В OCI предусмотрены инструменты для создания отказоустойчивых архитектур на уровнях вычислительных ресурсов, сети, хранилища, приложения и базы данных. Вы можете использовать эти инструменты для построения архитектуры active-active, в которой ваши приложения работают одновременно в двух регионах, и отказ в регионе А может быть обработан регионом Б; сценария теплого резервирования,при котором вторичный регион подготовлен и готов принять на себя трафик в случае отказа основного региона; сценария холодного резервирования, когда для восстановления бизнес-операций может потребоваться сочетание ручных и/или автоматизированных действий; или некоторой гибридной комбинации всего перечисленного.
В качестве отправной точки рекомендуем полностью прочитать Руководство по решениям аварийного восстановления в Центре архитектуры OCI и выбрать решения, соответствующие вашей операционной модели.
Бюджеты и квоты
Если у вас есть SaaS-приложение, в котором для изоляции используется секционирование OCI, вам есть смысл рассмотреть несколько связанных с этой функциональностью примитивов, которые помогут вам – и вашим клиентам – эффективнее управлять своими ресурсами. Как правило, для каждой аренды в OCI настраивается определенный долларовый лимит и, хотя перерасходы не влекут за собой никаких штрафов, большинство независимых поставщиков ПО предпочитают строго контролировать использование ресурсов.
Первое, что следует рассмотреть – это квоты секций, которые можно использовать для разделения всех арендуемых ресурсов между разными секциями в аренде. При использовании того примитива общие ресурсы, такие как ЦП и блоки хранилища, или более специализированные ресурсы, такие как графические процессоры и машины Exadata, можно распределять по секциям, чтобы ни одному из арендаторов не был выделен чрезмерный объем ресурсов или чтобы специализированные ресурсы использовались там, где они необходимы.
Квоты действуют в отношении облачных ресурсов. Для контроля денежных расходов в OCI предназначены бюджеты. Этот примитив позволяет устанавливать бюджеты для каждой секции и получать уведомления, когда бюджет приближается к "мягкому" лимиту или превышает "жесткий" лимит. Используя эту функцию, независимые поставщики ПО могут управлять своими расходами на обслуживание любого количества клиентов и прогнозировать потребности в увеличении объема ресурсов.
Возвратные платежи
Несмотря на то что каждый независимый поставщик ПО устанавливает расценки на использование своего SaaS-сервиса по-своему, многие модели ценообразования строятся на концепции себестоимости реализованной продукции. Не зная, сколько вы затрачиваете на создание и доставку продукта, трудно понять, какая цена будет для него справедливой и как варьировать эту цену для разных потребителей.
В цене SaaS-сервиса учитывается множество входных факторов, включая затраты на разработку и маркетинг, однако одним из ключевых компонентов является стоимость облачного хостинга. Здесь на помощь приходит анализ затрат OCI – динамическая визуализация использования ресурсов вашими клиентами/арендаторами с сегментацией по секциям и/или тегам отслеживания затрат. Использование этих инструментов позволяет понять, сколько вы тратите на хостинг для каждого из своих клиентов, и принять решение о необходимости корректировки цен.
Если вам нужны более детальные данные, чем на визуализациях, вы можете экспортировать полностью детализированные данные об использовании в машиночитаемом формате для дальнейшего анализа с помощью выбранного вами инструмента. А если вы работаете в гибридной облачной среде, вы можете использовать сторонний мультиоблачный инструмент – например, CloudHealth – для проведения комплексного анализа.
Автоматизация инфраструктуры
Очень немногие организации создают свои среды вручную. Независимые поставщики ПО уже ощутили ценность оркестрации и управления конфигурацией инфраструктуры с помощью инструментов, реализующих принцип "инфраструктура как код" (IaC), таких как Terraform, Ansible, Puppet и т. д. Несмотря на то что IaC – идеальный вариант вне зависимости от величины вашей организации, ее технической базы или подхода к развертыванию, особое значение эта технология приобретает для растущих независимых поставщиков ПО, которые постоянно расширяют свою географию регионов и базу установленных систем. Без автоматизации ваши накладные расходы на обслуживание будут расти в геометрической прогрессии, и ими станет сложно управлять.
OCI обеспечивает поддержку ряда стандартных инструментов автоматизации, которые позволяют реализовать стратегию автоматизации, не привязанную к конкретному облаку. К ним относятся поддержка HashiCorp Terraform, Ansible и Chef. Поскольку вся функциональность OCI предоставляется через пакеты SDK и через интерфейс командной строки (CLI), OCI легко интегрировать с любым количеством других инструментов, таких как Puppet.
Кроме того, OCI позволяет использовать возможности Terraform посредством управляемого сервиса, который называется Resource Manager. Этот сервис, который предлагается клиентам OCI бесплатно, позволяет запускать Terraform непосредственно из основанной на политиках модели безопасности OCI и предоставляет готовую функциональность для управления состояниями, создания шаблонов, обнаружения ресурсов и интеграции с GitHub/GitLab.
Автоматизация жизненного цикла программного обеспечения
Независимые поставщики ПО используют инструменты автоматической сборки и развертывания для продвижения своего кода через жизненный цикл разработки программного обеспечения. В условиях одноарендной модели доставки автоматизация приобретает особую важность, так как одно развертывание может доставляться сотням экземпляров арендаторов. Кроме того, эти развертывания часто должны выполняться по скользящему принципу, чтобы исключить простои, и должны быть достаточно гибкими для работы с конкретными настройками на основе ветвей для отдельных клиентов.
OCI поддерживает большинство ведущих средств непрерывной интеграции и поставки. Что бы вы ни использовали – Jenkins, Jenkins-X, Spinnaker, TravisCI, GitHub Actions или CircleCI – скорее всего, в экосистеме разработки ПО есть кто-то, кто уже использует предпочитаемый вами инструмент в сочетании с OCI.
Кроме того, в OCI есть удобный сервис DevOps Service, который представляет собой комплексную платформу для непрерывной интеграции и поставки (CI/CD) для разработчиков. С помощью этого сервиса независимые поставщики ПО могут легко собирать, тестировать и развертывать программное обеспечение в OCI, а также управлять исходным кодом с использованием размещенных частных репозиториев Git.
Заключение
Мы понимаем, что каждому независимому поставщику ПО свойственны своя история, исходная среда, техническая архитектура и модель развертывания, а также уникальные бизнес-требования и технические требования. Не существует универсального подхода к миграции на Oracle Cloud Infrastructure (OCI), который учитывал бы все эти факторы и позволял бы задействовать соответствующие им возможности OCI.
Ключевой компонент нашего индивидуального подхода к миграции для независимого поставщика ПО – это сочетание процесса взаимодействия, который предполагает привлечение архитекторов, бизнес-консультантов и инженеров для разработки вашего облачного решения, и программы Cloud Lift Services для совместной с работы над переносом рабочих нагрузок в OCI.
Уникальной компанию Oracle в глазах независимых поставщиков ПО делают наши желание и готовность напрямую взаимодействовать с клиентами на всех уровнях – стратегическом, освоения рынка, архитектурном и уровне реализации – и объединять усилия специалистов для решения ваших задач в облаке.