Поделиться через

Перенос рабочих нагрузок AWS Lambda в Функции Azure

Миграция бессерверной рабочей нагрузки, использующей AWS Lambda от Amazon Web Services (AWS), в Azure Functions требует тщательного планирования и реализации. В этой статье приведены основные рекомендации, которые помогут вам:

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

Область действия

В этой статье описывается миграция экземпляра AWS Lambda в Azure Functions.

В этой статье не рассматриваются:

  • Миграция в собственное решение для размещения контейнеров, например с помощью приложений контейнеров Azure.
  • Размещение контейнеров AWS Lambda в Azure.
  • Основные подходы к внедрению Azure вашей организации, такие как целевые зоны Azure или другие темы, рассмотренные в методологии миграции Cloud Adoption Framework.

Сравнение функциональных возможностей

Эта статья сопоставляет функции AWS Lambda с эквивалентами Функций Azure, чтобы обеспечить совместимость.

Это важно

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

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

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

В этой статье рассматривается перенос рабочей нагрузки AWS Lambda в Функции Azure и общие зависимости для бессерверных рабочих нагрузок. Этот процесс может включать несколько служб, так как рабочие нагрузки составляют множество ресурсов и процессов для управления этими ресурсами. Чтобы иметь комплексную стратегию, необходимо объединить рекомендации, представленные в этой статье, с более крупным планом, который включает другие компоненты и процессы в рабочей нагрузке.

Выполните процесс обнаружения в вашей существующей рабочей нагрузке.

Первым шагом является проведение подробного процесса обнаружения для оценки существующей рабочей нагрузки AWS Lambda. Цель состоит в том, чтобы понять, какие функции и службы AWS зависят от рабочей нагрузки. Составьте полный список ваших функций AWS Lambda, используя такие инструменты AWS, как SDK для каждой службы, API, CloudTrail и интерфейс командной строки AWS, чтобы оценить нагрузку на функции AWS Lambda. Вы должны понимать следующие ключевые аспекты инвентаризации AWS Lambda:

  • Случаи использования
  • Конфигурации
  • Настройка безопасности и сети
  • Механизмы инструментирования, мониторинга, ведения журнала и наблюдаемости
  • Зависимости
  • Цели надежности и текущее состояние надежности
  • Стоимость владения
  • Целевые показатели производительности и текущая производительность

Выполнение планирования предварительной подготовки

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

Кроме того, необходимо сопоставить службы AWS, от которых зависит Lambda, с эквивалентными зависимостями в Azure.

Сопоставление лямбда-функций AWS с функциями Azure

В следующих таблицах сравниваются понятия, ресурсы и свойства AWS Lambda с их соответствующими эквивалентами в Azure Functions, в частности, с планом размещения Flex Consumption.

Поддерживаемые языки

Язык программирования Поддерживаемые версии AWS Lambda Поддерживаемые версии Azure Functions
Node.js 20, 22 20, 22
Питон 3.9, 3.10, 3.11, 3.12, 3.13 3.9, 3.10, 3.11
Ява 8, 11, 17, 21 8, 11, 17, 21
PowerShell Не поддерживается 7,4
.СЕТЬ .NET 8 .NET 8, .NET 9, .NET Framework 4.8.1
Руби 3.2, 3.3 Пользовательские обработчики
Иди Среда выполнения только для ОС Пользовательские обработчики
Ржавчина Среда выполнения только для ОС Пользовательские обработчики

Модель программирования

Функция AWS Лямбда Функции Azure
Триггеры Интегрируется с другими сервисами AWS через источники событий. Обеспечивает автоматические и программные способы связывания функций Lambda с источниками событий. Запускает функцию на основе определённых событий, таких как обновления в базе данных или новое сообщение в очереди. Например, триггер Azure Cosmos DB позволяет функциям автоматически реагировать на вставки и обновления в контейнере Azure Cosmos DB. Это действие позволяет обрабатывать изменения данных в режиме реального времени.

Функции также интегрируются с Azure Event Grid, поэтому они могут обрабатывать события из служб Azure, таких как Azure Storage и Azure Media Services, а также из внешних источников событий. Event Grid служит централизованной и расширяемой службой маршрутизации событий, которая дополняет триггеры Functions и обеспечивает высокую масштабируемость и широкое покрытие источников событий.
Привязки Нет привязок. Использует AWS SDK в функциях Lambda для ручного управления взаимодействиями с другими сервисами AWS. Связи, настроенные в качестве ввода или вывода, позволяют создавать декларативные подключения к службам, что минимизирует необходимость в явном использовании кода SDK. Например, вы можете настроить связывания для чтения из Blob Storage, записи в Azure Cosmos DB или отправки электронных писем через SendGrid без необходимости вручную управлять интеграциями.

Триггеры событий и связывания

Триггер или служба AWS Lambda триггер Azure Functions Описание
API Gateway: HTTP-запросы Триггер HTTP Эти триггеры позволяют напрямую обрабатывать HTTP-запросы.
Простой сервис очередей (SQS) Триггер Azure Queue Storage или Триггер Azure Service Bus Эти триггеры могут обрабатывать сообщения в очередях.
Простая служба уведомлений (SNS) Триггер Event Grid или триггер Service Bus Эти триггеры позволяют обрабатывать уведомления.
Kinesis (потоки данных) Триггер Центров событий Эти триггеры потребляют потоки данных.
DynamoDB (изменения таблицы) Триггер изменения потока данных в Azure Cosmos DB Эти триггеры отслеживают изменения в таблицах.
CloudWatch Events или EventBridge Scheduler (планировщик) Триггер таймера Эти триггеры обрабатывают запланированные или основанные на времени функции.
S3 (события объектов) Триггер хранилища объектов BLOB Эти триггеры реагируют на события в хранилище блобов.
Amazon Relational Database Service (RDS) Триггер SQL Azure Эти триггеры реагируют на изменения в базе данных.
Управляемый стрииминг для Apache Kafka (MSK) Триггер Apache Kafka Эти триггеры реагируют на сообщения из тем Kafka.
Amazon ElastiCache Триггер Azure Redis Эти триггеры реагируют на сообщения в Redis.
Amazon MQ Триггер RabbitMQ Эти триггеры реагируют на сообщения в RabbitMQ.

Разрешения

AWS Лямбда Функции Azure
Роль выполнения Lambda предоставляет функциям Lambda разрешения на взаимодействие с другими сервисами AWS. Каждая функция Lambda имеет связанную с ней роль управления идентификацией и доступом (IAM), которая определяет её разрешения во время выполнения. Управляемые идентификации предоставляют идентификацию для вашего приложения-функции, что позволяет ему аутентифицироваться с другими службами Azure без хранения учетных данных в коде. Управление доступом на основе ролей (RBAC) назначает соответствующие роли управляемой идентичности в Microsoft Entra ID, чтобы предоставить доступ к необходимым ресурсам.
Заявления о политике, основанные на ресурсах

- AWSLambda_FullAccess предоставляет полный доступ ко всем операциям Lambda, включая создание, обновление и удаление функций.

- AWSLambda_ReadOnlyAccess предоставляет доступ только для чтения для просмотра функций Lambda и их конфигураций.

- Пользовательские политики IAM.		 Встроенные роли на базе ресурсов

- Роль владельца обеспечивает полный доступ, включая управление разрешениями на доступ.

- Роль Участника может создавать и удалять приложения функций, настраивать параметры и размещать код. Он не может управлять доступом.

- Роль "Читатель мониторинга" может предоставлять доступ только для чтения к данным и настройкам мониторинга. Он также может назначать настраиваемые роли.

URL-адрес функции

AWS Лямбда Функции Azure
https://<url-id>.lambda-url.<region>.on.aws - <appname>.azurewebsites.net (оригинальное, глобальное имя узла по умолчанию)

- <appname>-<randomhash>.<Region>.azurewebsites.net (новое, уникальное имя хоста по умолчанию)

Нетворкинг

AWS Лямбда Функции Azure
Все функции Lambda безопасно выполняются внутри виртуальной частной сети (VPC) по умолчанию, управляемой системой. Вы также можете настроить свою функцию Lambda для доступа к ресурсам в пользовательском VPC. Приложения Function могут быть защищены сетью и иметь доступ к другим сервисам внутри сети. Входящий сетевой доступ может быть ограничен только списком IP-адресов в межсетевом экране и определенной виртуальной сетью через служебные конечные точки или частные конечные точки. Доступ к исходящей сети включен через функцию интеграции виртуальной сети. Приложение функции может ограничивать весь свой трафик до подсети виртуальной сети и также может получать доступ к другим сервисам внутри этой виртуальной сети.

Наблюдаемость и мониторинг

AWS Лямбда Функции Azure
Amazon CloudWatch помогает в мониторинге и обеспечении наблюдаемости, собирая и отслеживая метрики, агрегируя и анализируя журналы, устанавливая оповещения, создавая пользовательские панели мониторинга и реализуя автоматические реакции на изменения в производительности ресурсов и метриках. Azure Monitor предоставляет всесторонний мониторинг и наблюдаемость для Azure Functions, особенно через свою функцию Application Insights.

Application Insights собирает такие данные телеметрии, как частота запросов, время отклика и показатели отказов. Он визуализирует взаимоотношения компонентов приложения, отслеживает производительность в реальном времени, ведет подробный журнал диагностики и позволяет отслеживать пользовательские метрики. Эти возможности помогают поддерживать производительность, доступность и надежность Azure Functions, а также позволяют создавать пользовательские панели мониторинга, оповещения и автоматические реакции.
AWS Lambda генерирует телеметрические данные при вызовах ваших функций и может экспортировать эти данные, используя семантику OpenTelemetry. Вы можете настроить функции Lambda для отправки этих данных телеметрии на любой совместимый с OpenTelemetry конечный пункт. Это действие позволяет коррелировать трассировки и журналы, обеспечивать согласованные стандартизированные телеметрические данные и интеграцию с другими инструментами наблюдения, поддерживающими OpenTelemetry. Настройте ваше приложение с функциями для экспорта данных журналов и трассировки в формате OpenTelemetry. Вы можете экспортировать телеметрические данные на любой соответствующий конечный пункт, используя OpenTelemetry. OpenTelemetry предоставляет такие преимущества, как корреляция трассировок и журналов, согласованные стандарты телеметрических данных и интеграция с другими поставщиками. Вы можете включить OpenTelemetry на уровне приложения функции в конфигурации хоста и в вашем проекте кода, чтобы оптимизировать экспорт данных из вашего кода функции. Для получения дополнительной информации см. Использование OpenTelemetry с Azure Functions.

Масштабирование и параллелизм

AWS Лямбда Функции Azure
AWS использует модель масштабирования по запросу. Автоматически масштабируйте работу ваших функций в соответствии с потребностями. «Конкурентность», или количество запросов, обрабатываемых одним экземпляром, всегда равна 1. Экземпляры динамически добавляются и удаляются в зависимости от количества входящих событий и настроенной параллельности для каждого экземпляра. Вы можете настроить параметр concurrency setting на желаемое значение.
Параллелизм всегда равен 1. Параллельность настраивается (>1).
Поддерживает масштабирование до 0. Поддерживает масштабирование до 0.

Защита при холодном запуске

AWS Лямбда Функции Azure
Выделенная параллельность уменьшает задержку и обеспечивает предсказуемую производительность функции, предварительно инициализируя запрошенное количество экземпляров функции. Конфигурируемая параллельность подходит для приложений с высокой чувствительностью к задержкам и оплачивается отдельно от стандартной параллельности. Приложения Function позволяют настроить параллелизм для каждого экземпляра, что определяет его масштабируемость. Несколько задач могут выполняться параллельно в одном экземпляре приложения, и последующие задачи в экземпляре не требуют начальной задержки запуска. Приложения функций также имеют всегда готовые экземпляры. Клиенты могут указать количество предварительно разогретых экземпляров, чтобы устранить задержки холодного запуска и обеспечить стабильную производительность. Функциональные приложения также масштабируются на большее количество экземпляров в зависимости от спроса, сохраняя при этом всегда готовые экземпляры.
Резервирование параллелизма указывает максимальное количество одновременных экземпляров, которые может иметь функция. Этот лимит гарантирует, что часть квоты одновременных операций вашего аккаунта выделена исключительно для этой функции. AWS Lambda автоматически масштабируется для обработки входящих запросов, даже если установлена зарезервированная параллельность, при условии, что количество запросов не превышает указанное ограничение зарезервированной параллельности. Нижний предел зарезервированной параллельности в AWS Lambda составляет 1. Верхний предел для зарезервированной одновременности в AWS Lambda определяется региональной квотой на одновременность для аккаунта. По умолчанию этот лимит составляет 1 000 одновременных операций для каждого региона. Azure Functions не имеет аналогичной функции для зарезервированной параллельности. Чтобы достичь аналогичной функциональности, изолируйте конкретные функции в отдельные приложения функций и установите максимальный предел масштабирования для каждого приложения. Azure Functions автоматически увеличивает количество экземпляров или добавляет больше экземпляров и уменьшает количество, или удаляет экземпляры, в пределах установленного лимита масштабирования. По умолчанию приложения, работающие на плане Flex Consumption, начинают с настраиваемого ограничения в 100 общих экземпляров. Наименьшее значение максимального количества экземпляров равно 40, а наибольшее поддерживаемое значение максимального количества экземпляров равно 1,000. Региональные квоты на память подписки также могут ограничивать масштабирование приложений функций, но вы можете увеличить эту квоту, обратившись в службу поддержки.

Ценообразование

AWS Лямбда Функции Azure
- Оплата за использование по общему количеству вызовов и за гигабайты в секунду (GB/s) для каждого экземпляра (с фиксированной параллельностью 1).

шаги 1 мс

- 400,000 Gbps бесплатный уровень		 - Платите за использование в зависимости от общего числа вызовов и за каждый экземпляр с учетом скорости обмена данными в ГБ/с (с возможностью настройки одновременных вызовов).

- интервалы по 100 мс

- 100,000 Gbps бесплатный уровень

- Затраты, основанные на потреблении

хранение исходного кода

AWS Лямбда Функции Azure
AWS Lambda управляет хранением кода вашей функции в своей собственной управляемой системе хранения. Вам не нужно предоставлять больше места для хранения данных. Функции требуют контейнера Blob Storage, предоставленного клиентом, для поддержания пакета развертывания, содержащего код вашего приложения. Вы можете настроить параметры, чтобы использовать тот же или другой аккаунт хранилища для развертываний и управлять методами аутентификации для доступа к контейнеру.

Локальная разработка

Лямбда-функция AWS Функция Azure Functions
— SAM CLI

- LocalStack		 - Инструменты Azure Functions Core

— Visual Studio Code

— Visual Studio

— GitHub Codespaces

- VSCode.dev

- Maven

- Локальное кодирование и тестирование функций Azure

Развертывание

Функция AWS Лямбда Функции Azure
Пакет развертывания - ZIP-файл

- Образ контейнера		 ZIP-файл (Для развертывания контейнерного образа используйте выделенный или премиум SKU.)
Размер файла ZIP (консоль) Максимум 50 МБ Максимальный размер для развертывания ZIP — 500 МБ.
Размер файла ZIP (CLI/SDK) Максимальный размер 250 МБ для развертывания ZIP, 500 МБ для распакованных данных. Максимальный размер для развертывания ZIP — 500 МБ.
Размер образа контейнера Максимум 10 ГБ Поддержка контейнеров с гибким хранением через Azure
Обработка крупных артефактов Используйте образы контейнеров для более крупных развертываний. Подключите хранилище Blob или общие ресурсы Azure Files, чтобы получить доступ к большим файлам из приложения.
Упаковка общих зависимостей для функций Слои Развертывание .Zip, по запросу из хранилища или контейнеров (ACA, dedicated, EP SKUs only)
"Развертывание в синей и зеленой среде или версионирование функций" Используйте квалификаторы функций, чтобы ссылаться на определенное состояние вашей функции, используя либо номер версии, либо имя псевдонима. Квалификаторы позволяют управлять версиями и осуществлять стратегию постепенного развертывания. Используйте системы непрерывной интеграции и непрерывной доставки для blue-green деплойментов.

Тайм-аут и ограничения памяти

Функция Ограничения AWS Lambda Ограничения Функций Azure
Время завершения выполнения 900 секунд (15 минут) Значение времени ожидания по умолчанию составляет 30 минут. Максимальный тайм-аут не ограничен. Однако льготный период, предоставляемый для выполнения функции, составляет 60 минут при уменьшении масштаба и 10 минут при обновлениях платформы. Для получения дополнительной информации см. Время ожидания функции приложения.
настраиваемая память От 128 МБ до 10 240 МБ с шагом в 64 МБ Функции поддерживают размеры экземпляров 2 ГБ и 4 ГБ. В каждой зоне данной подписки установлен лимит памяти в 512,000 МБ для всех экземпляров приложений, который можно увеличить, обратившись в службу поддержки. Общий объем использования памяти всеми экземплярами во всех функциональных приложениях в данном регионе должен оставаться в пределах этой квоты.

Хотя 2 ГБ и 4 ГБ являются вариантами размера экземпляра, параллельность для каждого экземпляра может быть выше 1. Следовательно, один экземпляр может обрабатывать несколько параллельных исполнений в зависимости от конфигурации. Правильная настройка параллелизма может помочь оптимизировать использование ресурсов и управлять производительностью. Балансируя распределение памяти и настройки параллелизма, вы можете эффективно управлять ресурсами, выделенными для ваших функциональных приложений, обеспечивая их эффективную работу и контроль затрат. Дополнительные сведения см. в статье о квотах памяти региональной подписки.

Управление секретами

AWS Лямбда Функции Azure
AWS Secrets Manager позволяет хранить, управлять и извлекать секреты, такие как учетные данные баз данных, API-ключи и другая конфиденциальная информация. Функции Lambda могут получать секреты с использованием AWS SDK. Мы рекомендуем использовать подходы без секретов, такие как управляемые идентичности, для обеспечения безопасного доступа к ресурсам Azure без жёсткой кодировки учетных данных. Когда требуются секреты, например, для партнерских или устаревших систем, Azure Key Vault предоставляет безопасное решение для хранения и управления секретами, ключами и сертификатами.
AWS Systems Manager Parameter Store — это сервис, который хранит данные конфигурации и секреты. Параметры могут быть зашифрованы с помощью AWS KMS и получены функциями Lambda с использованием AWS SDK.
Функции Lambda могут сохранять настройки конфигурации в переменных окружения. Конфиденциальные данные могут быть зашифрованы с помощью ключа управления ключами (KMS) для безопасного доступа.		 Azure Functions использует настройки приложения для хранения данных конфигурации. Эти настройки напрямую сопоставляются с переменными среды для удобства использования внутри функции. Эти настройки могут быть зашифрованы и безопасно сохранены в конфигурации службы приложений Azure.
Для более сложных сценариев Azure App Configuration предоставляет надежные функции для управления несколькими конфигурациями. Она позволяет использовать фичи-флаги и поддерживает динамические обновления в разных сервисах.

Управление состоянием

AWS Лямбда Функции Azure
AWS Lambda выполняет простое управление состоянием с помощью таких сервисов, как Amazon S3 для хранения объектов, DynamoDB для быстрого и масштабируемого хранения состояния в NoSQL, и SQS для обработки очередей сообщений. Эти сервисы обеспечивают сохранность и согласованность данных во время выполнения функций Lambda. Azure Functions использует AzureWebJobsStorage, чтобы управлять состоянием, позволяя привязкам и триггерам работать с такими службами хранения Azure, как Blob Storage, Queue Storage и Table Storage. Это позволяет функциям легко читать и записывать состояние. Для более сложного управления состоянием Durable Functions предлагает усовершенствованные возможности оркестрации рабочих процессов и сохранения состояния с использованием хранилища Azure.

Оркестрация с сохранением состояния

AWS Лямбда Функции Azure
Нет нативной оркестрации состояния. Используйте AWS Step Functions для рабочих процессов. Durable Functions помогает управлять сложным состоянием, обеспечивая оркестровку долговременных рабочих процессов и состояния. Это обеспечивает выполнение продолжительных операций, автоматическую контрольную точку и надежное сохранение состояния. Эти функции позволяют создавать сложные рабочие процессы, чтобы обеспечить отказоустойчивость и масштабируемость для приложений с состоянием.

Другие различия и соображения

Функция AWS Лямбда Функции Azure
Функции группировки Каждая функция AWS Lambda является независимым объектом. Приложение для функций служит контейнером для нескольких функций. Он предоставляет общий контекст выполнения и конфигурацию для функций, которые он содержит. Обработка нескольких функций как единого объекта упрощает развертывание и управление. Функции также используют стратегию масштабирования по отдельным функциям, где каждая функция масштабируется независимо, за исключением триггеров HTTP, Blob Storage и Durable Functions. Эти триггерные функции масштабируются в своих собственных группах.
Личные домены Включено через API Gateway Вы можете настроить собственные домены непосредственно в приложении функции или в Azure API Management.
Поддержка пользовательских контейнеров Поддерживает пользовательские контейнеры с помощью Lambda Container Image Функции Azure поддерживают пользовательские контейнеры, которые запускаются в среде Container Apps.

Создайте план миграции

  1. Выберите ключевые нагрузки для проверки концепции.

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

  2. Тестируйте итерационно и собирайте отзывы.

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

Создание ресурсов миграции

Этот шаг является переходным этапом разработки. На этом этапе вы создаете исходный код, шаблоны инфраструктуры как код (IaC) и конвейеры развертывания для представления рабочей нагрузки в Azure. Перед выполнением миграции необходимо адаптировать код функции для обеспечения совместимости и передовых практик.

Адаптация кода функции, файлов конфигурации и инфраструктуры в виде файлов кода

Чтобы обновить код для требований среды выполнения Функций Azure, выполните следующие действия.

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

  • Используйте пакет расширений Azure Functions для обработки различных привязок и триггеров, аналогичных службам AWS. Для приложений .NET следует использовать соответствующие пакеты NuGet вместо пакета расширений.

  • Используйте пакет расширений для интеграции с другими службами Azure, такими как служба хранилища Azure, служебная шина Azure и Azure Cosmos DB без необходимости вручную настраивать каждую привязку с помощью пакетов SDK. Дополнительные сведения см. в статьях Подключение функций к службам Azure с помощью привязок и шаблонам выражений привязки для Azure Functions.

Ниже приведены примеры кода общего пакета SDK. Лямбда-код AWS сопоставляется с соответствующими триггерами, привязками или фрагментами кода SDK в Функциях Azure.

чтение из Amazon S3 в сравнении с Azure Blob Storage

Лямбда-код AWS (ПАКЕТ SDK)

const AWS = require('aws-sdk');
const s3 = new AWS.S3();

exports.handler = async (event) => {
const params = {
Bucket: 'my-bucket',
Key: 'my-object.txt',
};
const data = await
s3.getObject(params).promise();
console.log('File content:',
data.Body.toString());
};

Код функций Azure (триггер)

import { app } from '@azure/functions';

app.storageblob('blobTrigger', { 
path: 'my-container/{blobName}',
connection: 'AzureWebJobsStorage',
}, async (context, myBlob) => { 
context.log(`Blob content:
${myBlob.toString()}`);
});

Работа с Службой очередей Amazon Simple Queue Service (SQS) в сравнении с хранилищем очередей Azure

Лямбда-код AWS (ПАКЕТ SDK)

const AWS = require('aws-sdk');
const sqs = new AWS.SQS(); 

exports.handler = async (event) => {
const params = {
QueueUrl:
'https://sqs.amazonaws.com/123456789012/MyQueue',
MessageBody: 'Hello, world!',
};
await
sqs.sendMessage(params).promise();
};

Код функций Azure (триггер)

import { app } from '@azure/functions';

app.queue('queueTrigger', { 
queueName: 'myqueue-items',
connection: 'AzureWebJobsStorage',
}, async (context, queueMessage) => {
context.log(`Queue message: 
${queueMessage}`);
});

Запись в DynamoDB по сравнению с Azure Cosmos DB

Лямбда-код AWS (ПАКЕТ SDK)

const AWS = require('aws-sdk'); 
const dynamoDb = new AWS.DynamoDB.DocumentClient();   

exports.handler = async (event) => { 
const params = { 
TableName: 'my-table', 
Key: { id: '123' }, 
}; 
const data = await dynamoDb.get(params).promise(); 
console.log('DynamoDB record:', data.Item); 
};

Код функций Azure (триггер)

import { app } from '@azure/functions';  

app.cosmosDB('cosmosTrigger', { 
connectionStringSetting: 'CosmosDBConnection', 
databaseName: 'my-database', 
containerName: 'my-container', 
leaseContainerName: 'leases', 
}, async (context, documents) => { 
documents.forEach(doc => { 
context.log(`Cosmos DB document: ${JSON.stringify(doc)}`); 
}); 
});

События Amazon CloudWatch против триггера таймера Azure

Лямбда-код AWS (ПАКЕТ SDK)

exports.handler = async (event) => {
console.log('Scheduled event:', event); 
};

Код функций Azure (триггер)

import { app } from '@azure/functions'; 

app.timer('timerTrigger', { schedule: '0 */5 * * * *', // Runs every 5 minutes }, async (context, myTimer) => { if (myTimer.isPastDue) { context.log('Timer is running late!'); } context.log(Timer function executed at: ${new Date().toISOString()}); });

Amazon Simple Notification Service (SNS) и триггер сетки событий Azure

Лямбда-код AWS (ПАКЕТ SDK)

const AWS = require('aws-sdk'); 
const sns = new AWS.SNS();   

exports.handler = async (event) => { 
const params = { 
Message: 'Hello, Event Grid!', 
TopicArn: 'arn:aws:sns:us-east-1:123456789012:MyTopic', 
}; 
await sns.publish(params).promise(); 
};

Код функций Azure (триггер)

import { app } from '@azure/functions'; 

app.eventGrid('eventGridTrigger', {}, 
async (context, eventGridEvent) => { 

context.log(`Event Grid event: 
${JSON.stringify(eventGridEvent)}`); 

});

Amazon Kinesis против триггера Центров событий Azure

Лямбда-код AWS (ПАКЕТ SDK)

const AWS = require('aws-sdk'); 
const kinesis = new AWS.Kinesis();   

exports.handler = async (event) => { 
const records = 
event.Records.map(record => 
Buffer.from(record.kinesis.data, 
'base64').toString()); 
console.log('Kinesis records:', records); 
};

Код функций Azure (триггер)

import { app } from '@azure/functions'; 
app.eventHub('eventHubTrigger', {  
connection: 'EventHubConnection',  
eventHubName: 'my-event-hub',  
}, async (context, eventHubMessages) => 
{  
eventHubMessages.forEach(message => 
{  
context.log(`Event Hub message: 
${message}`);  
});  
});

Ознакомьтесь со следующими репозиториями GitHub, чтобы сравнить лямбда-код AWS и код Функций Azure:

Настройка параметров конфигурации

Убедитесь, что параметры времени ожидания и памяти вашей функции совместимы с Azure Functions. Дополнительные сведения о настраиваемых параметрах см. в host.json справочнике по функциям Azure.

Следуйте рекомендациям по разрешениям, доступу, сети и конфигурациям развертывания.

Настройка разрешений

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

main.bicep

// User-assigned managed identity that the function app uses to reach Storage and Service Bus
module processorUserAssignedIdentity './core/identity/userAssignedIdentity.bicep' = {
  name: 'processorUserAssignedIdentity'
  scope: rg
  params: {
    location: location
    tags: tags
    identityName: !empty(processorUserAssignedIdentityName) ? processorUserAssignedIdentityName : '${abbrs.managedIdentityUserAssignedIdentities}processor-${resourceToken}'
  }
}

Для получения дополнительной информации см. rbac.bicep.

Настройка доступа к сети

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

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

main.bicep

// Virtual network and private endpoint
module serviceVirtualNetwork 'app/vnet.bicep' = {
  name: 'serviceVirtualNetwork'
  scope: rg
  params: {
    location: location
    tags: tags
    vNetName: !empty(vNetName) ? vNetName : '${abbrs.networkVirtualNetworks}${resourceToken}'
  }
}  

module servicePrivateEndpoint 'app/storage-PrivateEndpoint.bicep' = {
  name: 'servicePrivateEndpoint'
  scope: rg
  params: {
    location: location
    tags: tags
    virtualNetworkName: !empty(vNetName) ? vNetName : '${abbrs.networkVirtualNetworks}${resourceToken}'
    subnetName: serviceVirtualNetwork.outputs.peSubnetName
    resourceName: storage.outputs.name
  }
}

Дополнительные сведения см. в разделе VNet.bicep и storage-PrivateEndpoint.bicep.

Настройка параметров развертывания

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

Создание файлов IaC

  • Используйте такие средства, как Bicep, шаблоны Azure Resource Manager или Terraform, чтобы создать файлы IaC для развертывания ресурсов Azure.

  • Определите ресурсы, такие как Функции Azure, учетные записи хранения и сетевые компоненты в файлах IaC.

  • Используйте этот репозиторий примеров IaC для примеров, использующих рекомендации и лучшие практики по функциям Azure.

Использование средств для рефакторинга

Используйте такие средства, как GitHub Copilot в VS Code, чтобы помочь в рефакторинге кода, ручном рефакторинге для конкретных изменений или других средств миграции.

Замечание

Используйте режим агента в GitHub Copilot в VS Code.

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

Разработка пошагового процесса для миграции day-0

Разработайте стратегии аварийного переключения и возврата к основному режиму для вашей миграции и тщательно протестируйте их в предпроизводственной среде. Мы рекомендуем выполнить сквозное тестирование, прежде чем, наконец, перейти с AWS Lambda на Функции Azure.

  • Проверка функциональности

    • Код и проверка функций Azure локально.

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

    • Используйте такие средства, как curl или расширения REST Client в VS Code, чтобы отправлять HTTP-запросы для функций, запускаемых HTTP.

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

  • Проверка производительности

    • Провести тестирование производительности для сравнения нового развертывания Функций Azure с предыдущим развертыванием AWS Lambda.

    • Отслеживайте метрики, такие как время отклика, время выполнения и потребление ресурсов.

    • Используйте Application Insights для мониторинга , анализа журналов и устранения неполадок на этапе тестирования.

  • Устранение неполадок с помощью функции диагностики и решения проблем

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

Оценка конечного состояния перенесенной рабочей нагрузки

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

Развертывание и тестирование функций для проверки их производительности и правильности.

Развертывание в Azure

Разворачивайте рабочие нагрузки с помощью функции публикации VS Code. Вы также можете развертывать задачи из командной строки с помощью основных средств Azure Functions или Azure CLI. Azure DevOps и GitHub Actions также используют One Deploy.

Изучение примеров сценариев миграции

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

Если вы предпочитаете использовать Terraform, используйте вместо этого MigrationGetStarted-Terraform.

Оптимизация и мониторинг производительности приложения в Azure

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

Использование Application Insights для мониторинга и устранения неполадок

Включите Application Insights для вашего функционального приложения, чтобы собирать подробные данные телеметрии для управления и устранения неполадок. Application Insights можно включить на портале Azure или в файле конфигурации host.json приложения-функции. После включения Application Insights вы можете:

  • Сбор данных телеметрии. Application Insights предоставляет различные данные телеметрии, такие как журналы запросов, метрики производительности, исключения и зависимости.

  • Анализ журналов и метрик. Доступ к панели мониторинга Application Insights с портала Azure для визуализации и анализа журналов, метрик и других данных телеметрии. Используйте встроенные средства для создания пользовательских запросов и визуализации данных для получения аналитических сведений о производительности и поведении приложения-функции.

  • Настройка оповещений. Настройте оповещения в Application Insights, чтобы уведомить вас о критических проблемах, снижении производительности или конкретных событиях. Эти оповещения помогают заранее отслеживать и быстро реагировать на проблемы.

Оптимизация затрат и производительности

  • Оптимизация масштабирования и производительности:

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

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

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

  • Управление затратами:

    • Используйте средства microsoft Cost Management для мониторинга и анализа затрат на функции Azure.

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