Перенос банковской системы в облако Azure

В этой статье описаны процесс и компоненты, которые использовала команда разработки коммерческого программного обеспечения Майкрософт, чтобы создать решение для клиента в банковской сфере. Для сохранения анонимности клиент упоминается в статье как банк Contoso. Это крупная международная организация индустрии финансовых услуг (FSI), которая хотела модернизировать одну из своих финансовых систем транзакций.

Архитектура

Скачайте файл Visio для этой архитектуры.

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

Контейнеры микрослужб Contoso были отправлены вручную в кластер Kubernetes с помощью Docker. Этот кластер содержит:

• Azure Red Hat OpenShift (ARO) в средстве горизонтального автомасштабирования подов (HPA) Kubernetes/OpenShift для следующих компонентов:

  • Хранилище канала.

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

• Службы Azure Kubernetes (AKS) для автомасштабирования узлов для хранилища канала.

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

Рабочий процесс

В основном серверные службы обеспечивают необходимую логику для выполнения EFT:

1. Электронный перевод средств начинается с HTTP-запроса, полученного службой хранилища канала.

   Служба создает синхронизированные ответы инициаторам запросов с помощью шаблона публикации и подписки через кэш Azure для Redis и ожидает ответа от сервера.

2. Решение проверяет начальный запрос с помощью службы ЭПС Pilot Password.

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

3. Затем служба хранилища канала запускает асинхронный поток.

   Она вызывает контроллер ЭПС, оперативный оркестратор, который координирует поток транзакций. Это происходит за счет создания команд и использования событий из других микрослужб через Центры событий Azure или Kafka.

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

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

   KEDA поддерживается в AKS и приложениях контейнеров Azure

5. Далее выполняется нагрузочное тестирование. Нагрузочное тестирование Azure — это полностью управляемая служба нагрузочного тестирования, которая позволяет создавать высокомасштабную нагрузку. Служба имитирует трафик для приложений без необходимости развертывания дополнительных ресурсов. Azure Load Testing также предоставляет возможность принять существующий скрипт Apache JMeter и использовать его для запуска нагрузочного теста.

6. Наконец, благодаря мониторингу можно интегрировать результаты нагрузочного тестирования, инфраструктуру и метрики приложения.

   Команда связала запуск нагрузочного тестирования с побочными эффектами, вызванными микрослужбами на уровнях оркестрации хранилища и контейнера. Это позволило создать цикл быстрой обратной связи для настройки приложения. Prometheus, Grafana и Application Insights в Azure Monitor являются ключевыми компонентами, которые обеспечивают мониторинг и наблюдаемость. Автомасштабирование событий поддерживает проверку сценария, при котором приложения масштабируются на основе полученной нагрузки сообщений. Чтобы реализовать это поведение, команда разработки коммерческого ПО адаптировала KEDA для поддержки масштабирования приложений Java.

Возможности решения

Решение содержит три основные возможности:

• Горизонтальное автомасштабирование подов для хранилища канала

• Автомасштабирование узлов для хранилища канала

• Масштабируемость и производительность для конечных результатов моделирования транзакций

Горизонтальное автомасштабирование подов для хранилища канала

В этом решении команда воспользовалась механизмом горизонтального автомасштабирования подов (HPA) Kubernetes/OpenShift. HPA автоматически масштабирует количество подов на основе выбранной метрики. Таким образом реализуется эффективный механизм горизонтального увеличения и уменьшения масштаба для контейнеров. Так как REST API хранилища канала ограничен производительностью ЦП, команда решила воспользоваться HPA для ЦП, чтобы реплики службы могли увеличиваться с появлением новых ЭПС.

Этот компонент запускает службу под названием "Хранилище канала" в Azure Red Hat OpenShift. Он выполняет проверку автомасштабирования подов в этой службе. Компоненту необходимо выполнить следующие задачи:

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

• Обеспечить мониторинг кластера OpenShift с помощью панели мониторинга Grafana.

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

• Обеспечить наблюдаемость службы хранилища канала, активировав сбор метрик (например, потребления) с помощью Prometheus и Grafana.

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

Автомасштабирование узлов для хранилища канала

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

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

• Обеспечить мониторинг кластера AKS с помощью панели мониторинга Grafana.

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

• Обеспечить наблюдаемость службы хранилища канала, активировав сбор метрик с помощью Prometheus и Grafana.

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

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

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

Этот компонент предназначен для запуска служб хранилища канала, контроллера ЭПС и обработчика ЭПС в ARO и AKS. Кроме того, он выполняет автомасштабирование подов и узлов, а также тесты производительности во всех службах. Ему необходимо выполнить следующие задачи:

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

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

• Обеспечить наблюдаемость службы хранилища канала, активировав сбор метрик с помощью Prometheus и Grafana.

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

Компоненты

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

• Azure

  • Azure Pipelines

  • Службы Azure Kubernetes (AKS)

  • Azure Red Hat OpenShift

  • База данных SQL Azure

  • Центры событий Azure - (Kafka)

  • Azure Monitor

  • Реестр контейнеров Azure;

  • Экземпляры контейнеров Azure

  • Кэш Azure для Redis

• Сторонний производитель

  • Службы серверной части банка Contoso

  • Docker

  • Grafana

  • Прометей

• Открытый исходный код

  • Jenkins

  • КЕДА

  • Apache JMeter

  • Redis

Подробности сценария

Contoso Bank является крупной международной организацией по финансовым услугам (FSI), которая хотела модернизировать одну из своих финансовых систем транзакций.

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

Потенциальные варианты использования

Банку Contoso нужно использовать моделирование для следующих задач:

• Определение воздействия масштабируемости инфраструктуры.

• Определение реагирования на сбои в существующей архитектурной разработке конкретного программного обеспечения мейнфрейма.

Предлагаемое решение задействует виртуальное приложение для моделирования функциональных сценариев. Его задачей станет отслеживание производительности и масштабируемости инфраструктуры. Цель заключается в определении воздействия сбоев в рабочих нагрузках системы электронного перевода средств (ЭПС) мейнфрейма с помощью моделирования.

Кроме того, требовалось осуществить плавный переход DevOps из локальной среды в облако. Он должен включать в себя процесс и методологию банка, а также использовать существующие инструменты банка Contoso. Использование существующих технологий сократит необходимость повышения квалификации разработчиков. Этот переход поможет банку Contoso при оценке текущих и будущих решений по разработке. Также он сможет подтвердить, что среда Azure достаточно надежна, чтобы разместить новые распределенные системы.

Рекомендации

Условия успеха

Команда Contoso и команда разработки коммерческого ПО определили следующие критерии успешного выполнения этой задачи.

Общие критерии

Банк Contoso определил следующие факторы успешной реализации компонентов:

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

  • Предоставила необходимые инструменты и процессы в Azure.

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

• Каждый компонент предоставляется с документом, в котором содержатся следующие сведения:

  • Результаты проверки масштабируемости и производительности.

  • Параметры и метрики, исследуемые в каждой проверке.

  • Любое изменение кода или инфраструктуры, совершенное во время каждой проверки.

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

  • Рекомендации по использованию стратегий секционирования Kafka.

  • Общие рекомендации по архитектуре и инструкции на основе изучения конечных результатов.

Критерии конечных результатов

Техническое решение

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

Стоит отметить, что из-за функционального ограничения на Azure Red Hat OpenShift 3.11 банк Contoso запросил Службу Azure Kubernetes для проверки сценариев автомасштабирования узлов.

Команде разработки коммерческого ПО необходимо учесть ряд ограничений по проектированию:

• Из-за внутренних требований банк Contoso запросил использование следующих технологий:

  • OpenShift 3.11 в качестве платформы оркестрации контейнеров.

  • Java и Spring Boot для разработки микрослужб.

  • Kafka в качестве платформы потоковой передачи событий с реестром схем Confluent.

• Решение не должно зависеть от облака.

• Необходимо использовать инструменты мониторинга и DevOps, которые уже задействованы Contoso в локальной среде разработки.

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

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

• Смоделированный сценарий проверки должен использовать подмножество рабочих нагрузок ЭПС мейнфрейма в качестве образца потока.

• Все HPA и тесты производительности банку Contoso необходимо выполнить в ARO.

Комплексные задачи решения

Потоковая передача сообщений

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

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

Скорость непрерывной поставки и непрерывной интеграции

Для DevOps банк Contoso уже использовал локальный экземпляр GitLab в качестве репозитория кода. Они создали конвейеры непрерывной интеграции и непрерывной доставки (CI/CD) для сред разработки с помощью пользовательского решения на основе Jenkins, разработанного внутри них. Это решение не обеспечивало оптимальную работу DevOps.

Чтобы улучшить работу DevOps для Contoso команда разработки коммерческого ПО использовала Azure Pipelines в Azure DevOps для управления жизненным циклом приложения. Конвейер непрерывной интеграции запускается при каждом запросе на вытягивание, а конвейер непрерывной поставки запускается при каждом успешном слиянии с главной ветвью. Каждый член команды разработчиков отвечал за управление репозиториями и конвейерами для отдельной службы. Им также требовалось выполнить проверки кода, модульные тесты и анализ кода (анализ статического исходного кода).

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

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

Разработать стратегию развертывания

Команда развернула решение в среде разработки с помощью Azure Pipelines. Для каждой службы имеются свои конвейеры сборки и развертывания. Также был задействован конвейер развертывания, который можно активировать вручную. Он должен запускать полное развертывание среды и контейнеров в конкретной версии ветви.

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

Аварийное восстановление

В решении используются сценарии Terraform и Azure Pipelines для всех служб. В случае сбоя банк Contoso может заново создать всю среду с помощью сценариев Terraform или повторного запуска конвейера выпуска. Terraform распознает изменение среды и повторно создает ее. Решение динамически подготавливает и уничтожает инфраструктуру в Azure по мере необходимости. Учетные записи хранения — это хранилище, избыточное между зонами (ZRS). Стратегия резервного копирования не рассматривалась для этого решения.

Безопасность и конфиденциальность

• В частном реестре (Реестре контейнеров Azure) хранятся все образы контейнеров.

• В решении используются секреты ARO и AKS для включения конфиденциальных данных в поды, например строк подключения и ключей.

• Для доступа к серверу API Kubernetes требуется проверка подлинности с помощью идентификатора Microsoft Entra для ARO и AKS.

• Для доступа к Jenkins требуется проверка подлинности с помощью идентификатора Microsoft Entra.

Заключения

В конце проекта команда разработки коммерческого ПО предоставила следующие сведения.

• Результаты реализации решения

  • Команда отметила высокий уровень совместимости между AKS и ARO для развертывания служб.

  • Application Insights без написания кода упрощает наблюдаемость, внедряя облачные технологии в миграциях lift-and-shift.

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

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

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

• Основные выводы

  • Можно плавно перенести приложения из ARO в AKS.

  • Во время создания решения использовалась служба Red Hat OpenShift версии 3.11, в которой недоступна возможность автомасштабирования узлов. Поэтому команда разработки коммерческого ПО выполнила проверку автомасштабирования узлов с помощью AKS.

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

  • При создании этой статьи команда CSE создала решение для нагрузочного тестирования, интегрирующее ACI и JMeter в Azure DevOps Pipeline. С тех пор нагрузочное тестирование Azure было доступно как полностью управляемая служба нагрузочного тестирования без необходимости развертывания дополнительных вычислительных ресурсов.

  • Для Kafka рекомендуется использовать Центры событий Azure, но для банка Contoso важным компонентом был реестр схем. Чтобы найти решение для банка Contoso в указанный срок, команде пришлось рассмотреть использование реестра схем в другом экземпляре AKS.

  • Протокол Kafka с реестром схем не поддерживается масштабировщиком центров событий в KEDA.

Следующие шаги

• Автомасштабирование приложений Java в KEDA с помощью Центров событий Azure: KEDA для примера Java

• Шаблон Saga: сведения о шаблоне Saga на сайте Microservices.io

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

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

• Шаблоны и реализации