다음을 통해 공유

AWS 람다 워크로드를 Azure Functions로 마이그레이션

AWS(Amazon Web Services) 람다를 사용하는 서버리스 워크로드를 Azure Functions로 마이그레이션하려면 신중한 계획과 구현이 필요합니다. 이 문서에서는 다음을 돕기 위한 필수 지침을 제공합니다.

  • 기존 워크로드에서 검색 프로세스를 수행합니다.
  • 미리 배포 계획 및 워크로드 평가와 같은 주요 마이그레이션 작업을 수행하는 방법을 알아봅니다.
  • 마이그레이션된 워크로드를 평가하고 최적화합니다.

범위

이 문서에서는 AWS 람다 인스턴스를 Azure Functions로 마이그레이션하는 방법을 설명합니다.

이 문서에서는 다음을 다루지 않습니다.

  • Azure Container Apps를 통해 사용자 고유의 컨테이너 호스팅 솔루션으로 마이그레이션합니다.
  • Azure에서 AWS 람다 컨테이너 호스팅
  • 클라우드 채택 프레임워크 마이그레이션 방법론에서 다루는 Azure 랜딩 존 또는 기타 항목과 같은 조직의 기본 Azure 채택 접근 방식입니다.

기능 비교

이 문서에서는 호환성을 보장하기 위해 AWS 람다 기능을 Azure Functions에 매핑합니다.

중요합니다

마이그레이션 계획에 최적화를 포함하도록 선택할 수 있지만 Microsoft는 2단계 프로세스를 권장합니다. 먼저 "동등한" 기능을 마이그레이션한 다음 Azure에서 최적화 기회를 평가합니다.

최적화 작업은 워크로드 팀의 변경 제어 프로세스를 통해 지속적으로 실행되어야 합니다. 마이그레이션 중에 더 많은 기능을 추가하는 마이그레이션은 위험을 초래하고 프로세스를 불필요하게 확장합니다.

워크로드 관점

이 문서에서는 AWS Lambda 워크로드를 Azure Functions로 마이그레이션하는 방법과 서버리스 워크로드에 대한 일반적인 종속성을 중점적으로 설명합니다. 워크로드가 해당 리소스를 관리하는 많은 리소스와 프로세스로 구성되기 때문에 이 프로세스에는 여러 서비스가 포함될 수 있습니다. 포괄적인 전략을 수립하려면 이 문서에 제시된 권장 사항을 워크로드의 다른 구성 요소 및 프로세스를 포함하는 더 큰 계획과 결합해야 합니다.

기존 워크로드에서 검색 프로세스 수행

첫 번째 단계는 기존 AWS 람다 워크로드를 평가하기 위한 자세한 검색 프로세스를 수행하는 것입니다. 목표는 워크로드가 사용하는 AWS 기능 및 서비스를 이해하는 것입니다. 서비스별 SDK, API, CloudTrail 및 AWS CLI와 같은 AWS 도구를 사용하여 AWS 람다 함수의 포괄적인 인벤토리를 컴파일하여 AWS의 워크로드를 평가합니다. AWS 람다 인벤토리의 다음 주요 측면을 이해해야 합니다.

  • 사용 사례
  • 설정
  • 보안 및 네트워킹 설정
  • 도구, 모니터링, 로깅 및 관찰 메커니즘
  • 종속성
  • 안정성 목표 및 현재 안정성 상태
  • 소유 비용
  • 성능 목표 및 현재 성능

마이그레이션 전 단계 계획 수립

워크로드 마이그레이션을 시작하기 전에 호환성을 보장하고 마이그레이션 계획을 개발하려면 AWS 람다 기능을 Azure Functions에 매핑해야 합니다. 그런 다음 개념 증명을 위해 주요 워크로드를 선택할 수 있습니다.

또한 람다가 사용하는 AWS 서비스를 Azure의 동등한 종속성에 매핑해야 합니다.

AZURE Functions에 AWS 람다 기능 매핑

다음 표에서는 AWS 람다 개념, 리소스 및 속성을 Azure Functions, 특히 Flex Consumption 호스팅 계획의 해당 항목과 비교합니다.

지원되는 언어

프로그래밍 언어 AWS 람다 지원 버전 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 사용자 지정 처리기
가라 OS 전용 런타임 사용자 지정 처리기
러스트 OS 전용 런타임 사용자 지정 처리기

프로그래밍 모델

특징 AWS 람다 Azure Functions (애저 펑션)
유발 요소 이벤트 원본을 통해 다른 AWS 서비스와 통합됩니다. 람다 함수를 이벤트 원본과 연결하는 자동 및 프로그래밍 방식의 방법을 제공합니다. 데이터베이스의 업데이트 또는 큐의 새 메시지와 같은 특정 이벤트를 기반으로 함수를 트리거합니다. 예를 들어 Azure Cosmos DB 트리거를 사용하면 함수가 Azure Cosmos DB 컨테이너의 삽입 및 업데이트에 자동으로 응답할 수 있습니다. 이 작업을 통해 데이터 변경 내용을 실시간으로 처리할 수 있습니다.

또한 Functions는 Azure Event Grid와 통합되므로 Azure Storage 및 Azure Media Services와 같은 Azure 서비스 및 외부 이벤트 원본에서 이벤트를 처리할 수 있습니다. Event Grid는 Functions 트리거를 보완하고 높은 확장성과 광범위한 이벤트 원본 범위를 가능하게 하는 중앙 집중식 확장 가능한 이벤트 라우팅 서비스 역할을 합니다.
바인딩 바인딩이 없습니다. 람다 함수 내의 AWS SDK를 사용하여 다른 AWS 서비스와의 상호 작용을 수동으로 관리합니다. 입력 또는 출력으로 구성된 바인딩은 서비스에 대한 선언적 연결을 사용하도록 설정하여 명시적 SDK 코드의 필요성을 최소화합니다. 예를 들어 Blob Storage에서 읽도록 바인딩을 구성하거나, Azure Cosmos DB에 쓰거나, 수동으로 통합을 관리하지 않고 SendGrid를 통해 이메일을 보낼 수 있습니다.

이벤트 트리거 및 바인딩

AWS 람다 트리거 또는 서비스 Azure Functions 트리거 설명
API 게이트웨이: HTTP 요청 HTTP 트리거 이러한 트리거를 사용하면 HTTP 요청을 직접 처리할 수 있습니다.
SQS(Simple Queue Service) Azure Queue Storage 트리거 또는 Azure Service Bus 트리거 이러한 트리거는 큐에서 메시지를 처리할 수 있습니다.
SNS(Simple Notification Service) Event Grid 트리거 또는 Service Bus 트리거 이러한 트리거는 알림 처리를 사용하도록 설정합니다.
Kinesis(데이터 스트림) Event Hubs 트리거 이러한 트리거는 데이터 스트림을 사용합니다.
DynamoDB(테이블 변경) Azure Cosmos DB 변경 피드 트리거 이러한 트리거는 테이블의 변경 내용을 수신 대기합니다.
CloudWatch 이벤트 또는 EventBridge 스케줄러 타이머 트리거 이러한 트리거는 예약된 함수 또는 시간 기반 함수를 처리합니다.
S3(개체 이벤트) Blob Storage 트리거 이러한 트리거는 Blob Storage의 이벤트에 반응합니다.
AWS RDS(Relational Database Service) Azure SQL 트리거 이러한 트리거는 데이터베이스 변경에 반응합니다.
Apache Kafka(MSK)에 대한 관리되는 스트리밍 Apache Kafka 트리거 이러한 트리거는 Kafka 토픽 메시지에 반응합니다.
Amazon ElastiCache (아마존 엘라스티캐시) Azure Redis 트리거 이러한 트리거는 Redis의 메시지에 반응합니다.
Amazon MQ RabbitMQ 트리거 이러한 트리거는 RabbitMQ의 메시지에 반응합니다.

권한

AWS 람다 Azure Functions (애저 펑션)
람다 실행 역할은 람다 함수에게 다른 AWS 서비스와 상호 작용할 수 있는 권한을 부여합니다. 각 람다 함수에는 실행되는 동안 해당 권한을 결정하는 연결된 ID 및 액세스 관리(IAM) 역할이 있습니다. 관리 ID는 코드에 자격 증명을 저장하지 않고도 다른 Azure 서비스로 인증할 수 있는 함수 앱에 대한 ID를 제공합니다. 역할 기반 액세스 제어는 필요한 리소스에 대한 액세스 권한을 부여하기 위해 Microsoft Entra ID의 관리 ID에 적절한 역할을 할당합니다.
리소스 기반 정책 진술서

- AWSLambda_FullAccess 함수 만들기, 업데이트 및 삭제를 포함하여 모든 람다 작업에 대한 모든 액세스 권한을 제공합니다.

- AWSLambda_ReadOnlyAccess 람다 함수 및 해당 구성을 볼 수 있는 읽기 전용 액세스를 제공합니다.

- 사용자 지정 IAM 정책.		 리소스 기반 기본 제공 역할:

- 소유자 역할은 액세스 권한 관리를 포함하여 모든 권한을 부여합니다.

- 기여자 역할은 함수 앱을 만들고 삭제하고, 설정을 구성하고, 코드를 배포할 수 있습니다. 액세스를 관리할 수 없습니다.

- 모니터링 판독기 역할은 모니터링 데이터 및 설정에 대한 읽기 전용 액세스 권한을 부여할 수 있습니다. 사용자 지정 역할을 할당할 수도 있습니다.

함수 URL

AWS 람다 Azure Functions (애저 펑션)
https://<url-id>.lambda-url.<region>.on.aws - <appname>.azurewebsites.net (원래, 전역 기본 호스트 이름)

- <appname>-<randomhash>.<Region>.azurewebsites.net (새로운 고유한 기본 호스트 이름)

네트워킹

AWS 람다 Azure Functions (애저 펑션)
모든 람다 함수는 기본 시스템 관리 VPC(가상 프라이빗 클라우드) 내에서 안전하게 실행됩니다. 사용자 지정 VPC의 리소스에 액세스하도록 람다 함수를 구성할 수도 있습니다. 함수 앱은 네트워크 보안을 유지할 수 있으며 네트워크 내의 다른 서비스에 액세스할 수 있습니다. 인바운드 네트워크 액세스는 서비스 엔드포인트 또는 프라이빗 엔드포인트를 통해 IP 주소의 방화벽 목록 및 특정 가상 네트워크로만 제한될 수 있습니다. 아웃바운드 네트워크 액세스는 가상 네트워크 통합 기능을 통해 사용하도록 설정됩니다. 함수 앱은 모든 트래픽을 가상 네트워크의 서브넷으로 제한할 수 있으며 해당 가상 네트워크 내의 다른 서비스에도 액세스할 수 있습니다.

관찰 가능성 및 모니터링

AWS 람다 Azure Functions (애저 펑션)
Amazon CloudWatch는 메트릭 수집 및 추적, 로그 집계 및 분석, 경보 설정, 사용자 지정 대시보드 만들기, 리소스 성능 및 메트릭 변경에 대한 자동화된 응답 구현을 통해 모니터링 및 관찰을 지원합니다. Azure Monitor는 특히 Application Insights 기능을 통해 Azure Functions에 대한 포괄적인 모니터링 및 관찰 가능성을 제공합니다.

Application Insights는 요청 속도, 응답 시간 및 실패율과 같은 원격 분석 데이터를 수집합니다. 애플리케이션 구성 요소 관계를 시각화하고, 실시간 성능을 모니터링하고, 자세한 진단을 기록하고, 사용자 지정 메트릭 추적을 허용합니다. 이러한 기능은 사용자 지정 대시보드, 경고 및 자동화된 응답을 사용하도록 설정하면서 Azure Functions의 성능, 가용성 및 안정성을 유지하는 데 도움이 됩니다.
AWS Lambda는 함수 호출에서 원격 분석 데이터를 생성하고 OpenTelemetry 의미 체계를 사용하여 이 데이터를 내보낼 수 있습니다. 이 원격 분석 데이터를 OpenTelemetry 규격 엔드포인트로 보내도록 람다 함수를 구성할 수 있습니다. 이 작업을 통해 추적 및 로그의 상관 관계, 일관된 표준 기반 원격 분석 데이터 및 OpenTelemetry를 지원하는 다른 관찰 도구와의 통합이 가능합니다. 로그 및 추적 데이터를 OpenTelemetry 형식으로 내보내도록 함수 앱을 구성합니다. OpenTelemetry를 사용하여 모든 규격 엔드포인트로 원격 분석 데이터를 내보낼 수 있습니다. OpenTelemetry는 추적 및 로그의 상관 관계, 일관된 표준 기반 원격 분석 데이터, 다른 공급자와의 통합과 같은 이점을 제공합니다. 호스트 구성의 함수 앱 수준과 코드 프로젝트에서 OpenTelemetry를 사용하도록 설정하여 함수 코드에서 데이터 내보내기를 최적화할 수 있습니다. 자세한 내용은 Azure Functions에서 OpenTelemetry 사용을 참조 하세요.

크기 조정 및 동시성

AWS 람다 Azure Functions (애저 펑션)
AWS는 주문형 크기 조정 모델을 사용합니다. 요청에 따라 함수 작업의 크기를 자동으로 조정합니다. 동시성 또는 인스턴스에서 처리하는 요청 수는 항상 1입니다. 인스턴스는 들어오는 이벤트 수와 각 인스턴스에 대해 구성된 동시성에 따라 동적으로 추가 및 제거됩니다. 동시성 설정을 원하는 값으로 구성할 수 있습니다.
동시성은 항상 1입니다. 동시성은 구성할 수 있습니다(>1).
0으로 크기 조정을 지원합니다. 0으로 크기 조정을 지원합니다.

저온 시동 보호

AWS 람다 Azure Functions (애저 펑션)
프로비전된 동시성은 대기 시간을 줄이고 요청된 수의 함수 인스턴스를 미리 초기화하여 예측 가능한 함수 성능을 보장합니다. 프로비전된 동시성은 대기 시간에 민감한 애플리케이션에 적합하며 표준 동시성과 별도로 가격이 책정됩니다. 함수 앱을 사용하면 각 인스턴스에 대한 동시성을 구성하여 규모를 확장할 수 있습니다. 여러 작업이 앱의 동일한 인스턴스에서 병렬로 실행될 수 있으며 인스턴스의 후속 작업은 초기 콜드 시작을 발생하지 않습니다. 함수 앱에는 항상 준비된 인스턴스도 있습니다. 고객은 콜드 시작 대기 시간을 제거하고 일관된 성능을 보장하기 위해 여러 개의 미리 설치된 인스턴스를 지정할 수 있습니다. 또한 함수 앱은 항상 준비된 인스턴스를 유지하면서 수요에 따라 더 많은 인스턴스로 확장됩니다.
예약된 동시성은 함수에 있을 수 있는 최대 동시 인스턴스 수를 지정합니다. 이 제한은 계정의 동시성 할당량 중 일부가 해당 함수에 대해 단독으로 따로 설정되도록 합니다. AWS Lambda는 요청이 지정된 예약 동시성 제한을 초과하지 않는 한 예약된 동시성이 설정된 경우에도 들어오는 요청을 처리하도록 동적으로 확장합니다. AWS 람다에서 예약된 동시성에 대한 하한은 1입니다. AWS 람다에서 예약된 동시성에 대한 상한은 계정의 지역 동시성 할당량에 따라 결정됩니다. 기본적으로 이 제한은 각 지역에 대해 1,000개의 동시 작업입니다. Azure Functions에는 예약된 동시성과 동등한 기능이 없습니다. 유사한 기능을 달성하려면 특정 함수를 별도의 함수 앱으로 격리하고 각 앱에 대한 최대 스케일 아웃 제한을 설정합니다. Azure Functions는 확장 제한 집합 내에서 동적으로 스케일 아웃하거나 더 많은 인스턴스를 추가하고 인스턴스를 확장하거나 제거합니다. 기본적으로 Flex 소비 계획에서 실행되는 앱은 구성 가능한 전체 인스턴스 100개 제한으로 시작합니다. 가장 낮은 최대 인스턴스 수 값은 40이고 지원되는 최대 인스턴스 수 값은 1,000입니다. 지역 구독 메모리 할당량은 확장할 수 있는 함수 앱의 양을 제한할 수도 있지만 지원을 호출하여 이 할당량을 늘릴 수 있습니다.

가격 책정

AWS 람다 Azure Functions (애저 펑션)
- 총 호출 수 및 각 인스턴스의 GB/s에 대한 사용당 지불(고정 동시성 1)

- 1ms 단위

- 400,000 Gbps 무료 티어		 - 총 호출 수 및 각 인스턴스의 GB/s에 대한 사용당 지불(구성 가능한 동시 호출 사용)

- 100ms 증분

- 100,000Gbps 무료 계층

- 소비 기반 비용

소스 코드 스토리지

AWS 람다 Azure Functions (애저 펑션)
AWS Lambda는 자체 관리되는 스토리지 시스템에서 함수 코드의 스토리지를 관리합니다. 더 많은 스토리지를 제공할 필요가 없습니다. 함수를 사용하려면 고객이 제공한 Blob Storage 컨테이너가 앱의 코드를 포함하는 배포 패키지를 유지 관리해야 합니다. 배포에 동일하거나 다른 스토리지 계정을 사용하도록 설정을 구성하고 컨테이너에 액세스하기 위한 인증 방법을 관리할 수 있습니다.

로컬 개발

AWS 람다 기능 Azure Functions 기능
- SAM CLI

- LocalStack		 - Azure Functions 핵심 도구

- Visual Studio Code

- Visual Studio

- GitHub Codespaces

- VSCode.dev

- Maven

- Azure Functions를 로컬로 코딩 및 테스트

배치

특징 AWS 람다 Azure Functions (애저 펑션)
배포 패키지 - ZIP 파일

- 컨테이너 이미지		 ZIP 파일(컨테이너 이미지 배포의 경우 전용 또는 프리미엄 SKU를 사용합니다.)
ZIP 파일 크기(콘솔) 최대 50MB ZIP 배포의 경우 최대 500MB
ZIP 파일 크기(CLI/SDK) ZIP 배포의 경우 최대 250MB, 압축을 푼 경우 최대 500MB ZIP 배포의 경우 최대 500MB
컨테이너 이미지 크기 최대 10GB Azure를 통한 유연한 스토리지를 통한 컨테이너 지원
대규모 아티팩트 처리 더 큰 배포에 컨테이너 이미지를 사용합니다. Blob Storage 또는 Azure Files 공유를 연결하여 앱에서 큰 파일에 액세스합니다.
함수에 대한 일반적인 종속성 패키징 레이어 배포 .Zip, 스토리지 또는 컨테이너에서 필요에 따라(ACA, 전용, EP SKU만 해당)
파란색-녹색 배포 또는 함수 버전 관리 함수 한정자를 사용하여 버전 번호 또는 별칭 이름을 사용하여 함수의 특정 상태를 참조합니다. 한정자를 사용하면 버전 관리 및 점진적 배포 전략을 사용할 수 있습니다. 청록색 배포에 연속 통합 및 지속적인 업데이트 시스템을 사용합니다.

시간 초과 및 메모리 제한

특징 AWS 람다 제한 Azure Functions 제한
실행 제한 시간 900초(15분) 기본 제한 시간은 30분입니다. 최대 제한 시간은 제한되지 않습니다. 그러나 함수 실행에 지정된 유예 기간은 스케일 인 중에는 60분, 플랫폼 업데이트 중에는 10분입니다. 자세한 내용은 함수 앱 제한 시간을 참조하세요.
구성 가능한 메모리 64MB 단위로 128MB에서 10,240MB로 Functions는 2GB 및 4GB 인스턴스 크기를 지원합니다. 지정된 구독의 각 지역에는 모든 앱 인스턴스에 대해 512,000MB의 메모리 제한이 있으므로 지원을 호출하여 늘릴 수 있습니다. 지역의 모든 함수 앱에서 모든 인스턴스의 총 메모리 사용량은 이 할당량 내에 있어야 합니다.

2GB 및 4GB는 인스턴스 크기 옵션이지만 각 인스턴스의 동시성은 1보다 클 수 있습니다. 따라서 단일 인스턴스는 구성에 따라 여러 동시 실행을 처리할 수 있습니다. 동시성을 적절하게 구성하면 리소스 사용량을 최적화하고 성능을 관리하는 데 도움이 될 수 있습니다. 메모리 할당 및 동시성 설정의 균형을 조정하여 함수 앱에 할당된 리소스를 효과적으로 관리하고 효율적인 성능 및 비용 제어를 보장할 수 있습니다. 자세한 내용은 지역 구독 메모리 할당량을 참조하세요.

비밀 관리

AWS 람다 Azure Functions (애저 펑션)
AWS 비밀 관리자를 사용하면 데이터베이스 자격 증명, API 키 및 기타 중요한 정보와 같은 비밀을 저장, 관리 및 검색할 수 있습니다. 람다 함수는 AWS SDK를 사용하여 비밀을 검색할 수 있습니다. 관리 ID와 같은 비밀 없는 접근 방식을 사용하여 자격 증명을 하드 코딩하지 않고도 Azure 리소스에 안전하게 액세스할 수 있도록 하는 것이 좋습니다. 파트너 또는 레거시 시스템과 같은 비밀이 필요한 경우 Azure Key Vault는 비밀, 키 및 인증서를 저장하고 관리하는 보안 솔루션을 제공합니다.
AWS Systems Manager 매개 변수 저장소는 구성 데이터와 비밀을 저장하는 서비스입니다. 매개 변수는 AWS KMS를 사용하여 암호화하고 AWS SDK를 사용하여 람다 함수에서 검색할 수 있습니다.
람다 함수는 환경 변수에 구성 설정을 저장할 수 있습니다. 중요한 데이터는 보안 액세스를 위해 KMS 키로 암호화할 수 있습니다.		 Azure Functions는 애플리케이션 설정을 사용하여 구성 데이터를 저장합니다. 이러한 설정은 함수 내에서 쉽게 사용할 수 있도록 환경 변수에 직접 매핑됩니다. 이러한 설정은 암호화되고 Azure App Service 구성에 안전하게 저장할 수 있습니다.
고급 시나리오의 경우 Azure App Configuration은 여러 구성을 관리하기 위한 강력한 기능을 제공합니다. 기능 플래그 지정을 사용하도록 설정하고 서비스 전반에서 동적 업데이트를 지원합니다.

상태 관리

AWS 람다 Azure Functions (애저 펑션)
AWS Lambda는 개체 스토리지에 Amazon S3, 빠르고 확장 가능한 NoSQL 상태 스토리지용 DynamoDB, 메시지 큐 처리를 위한 SQS와 같은 서비스를 사용하여 간단한 상태 관리를 처리합니다. 이러한 서비스는 람다 함수 실행에서 데이터 지속성 및 일관성을 보장합니다. Azure Functions는 Blob Storage, Queue Storage 및 Table Storage와 같은 Azure Storage 서비스를 사용하여 바인딩 및 트리거를 사용하도록 설정하여 상태를 관리하는 데 사용합니다 AzureWebJobsStorage . 함수를 사용하면 상태를 쉽게 읽고 쓸 수 있습니다. 더 복잡한 상태 관리를 위해 Durable Functions는 Azure Storage를 사용하여 고급 워크플로 오케스트레이션 및 상태 지속성 기능을 제공합니다.

상태 저장 오케스트레이션

AWS 람다 Azure Functions (애저 펑션)
원시 상태의 오케스트레이션이 없습니다. 워크플로에 AWS 단계 함수를 사용합니다. Durable Functions는 지속성 워크플로 오케스트레이션 및 상태 저장 엔터티를 제공하여 복잡한 상태 관리에 도움이 됩니다. 장기 실행 작업을 가능하게 하고, 자동 검사점 및 신뢰할 수 있는 상태 지속성을 지원합니다. 이러한 기능을 사용하면 복잡한 워크플로를 빌드하여 상태 저장 애플리케이션의 내결함성과 확장성을 보장할 수 있습니다.

기타 차이점 및 고려 사항

특징 AWS 람다 Azure Functions (애저 펑션)
그룹화 함수 각 AWS 람다 함수는 독립적인 엔터티입니다. 함수 앱은 여러 함수에 대한 컨테이너 역할을 합니다. 포함된 함수에 대한 공유 실행 컨텍스트 및 구성을 제공합니다. 여러 함수를 단일 엔터티로 처리하면 배포 및 관리가 간소화됩니다. 또한 함수는 HTTP, Blob Storage 및 Durable Functions 트리거를 제외하고 각 함수의 크기를 독립적으로 조정하는 함수별 크기 조정 전략을 사용합니다. 이러한 트리거된 함수는 자체 그룹에서 확장됩니다.
사용자 지정 도메인 API 게이트웨이를 통해 사용 함수 앱 또는 Azure API Management에서 직접 사용자 지정 도메인을 구성할 수 있습니다.
사용자 지정 컨테이너 지원 람다 컨테이너 이미지를 통해 사용자 지정 컨테이너 지원 Azure Functions는 Container Apps 환경에서 실행되는 사용자 지정 컨테이너를 지원합니다.

마이그레이션 계획 만들기

  1. 개념 증명을 위해 주요 워크로드를 선택합니다.

    먼저 전체 인벤토리에서 중형의 비임계 워크로드를 1~2개 선택합니다. 이러한 워크로드는 개념 증명 마이그레이션의 기반이 됩니다. 작업에 큰 차질을 빚지 않고 프로세스를 테스트하고 잠재적인 문제를 식별할 수 있습니다.

  2. 반복적으로 테스트하고 피드백을 수집합니다.

    개념 증명을 사용하여 더 큰 워크로드로 확장하기 전에 피드백을 수집하고, 격차를 식별하고, 프로세스를 미세 조정합니다. 이 반복적인 접근 방식을 사용하면 본격적인 마이그레이션으로 이동할 때까지 잠재적인 문제를 해결하고 프로세스를 구체화할 수 있습니다.

마이그레이션 자산 빌드

이 단계는 과도기 개발 단계입니다. 이 단계에서는 Azure의 워크로드를 나타내는 소스 코드, IaC(Infrastructure as Code) 템플릿 및 배포 파이프라인을 빌드합니다. 마이그레이션을 수행하려면 먼저 호환성 및 모범 사례에 맞게 함수 코드를 조정해야 합니다.

함수 코드, 구성 파일 및 인프라를 코드 파일로 조정

Azure Functions 런타임 요구 사항에 대한 코드를 업데이트하려면 다음을 수행합니다.

다음 코드 조각은 일반적인 SDK 코드의 예입니다. AWS 람다 코드는 Azure Functions의 해당 트리거, 바인딩 또는 SDK 코드 조각에 매핑됩니다.

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 Functions 코드(트리거)

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

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

Amazon SQS(Simple Queue Service) 및 Azure Queue Storage에 쓰기

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 Functions 코드(트리거)

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 Functions 코드(트리거)

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 Functions 코드(트리거)

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 SNS(Simple Notification Service) 및 Azure Event Grid 트리거 비교

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 Functions 코드(트리거)

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

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

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

});

Amazon Kinesis와 Azure Event Hubs 트리거 비교

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 Functions 코드(트리거)

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}`);  
});  
});

AWS 람다 코드와 Azure Functions 코드를 비교하려면 다음 GitHub 리포지토리를 참조하세요.

구성 설정 조정

함수의 제한 시간 및 메모리 설정이 Azure Functions와 호환되는지 확인합니다. 구성 가능한 설정에 대한 자세한 내용은 Azure Functions에 대한host.json 참조를 참조하세요.

사용 권한, 액세스, 네트워킹 및 배포 구성에 권장되는 모범 사례를 따릅니다.

권한 구성

함수 앱에 대한 권한을 설정할 때 모범 사례를 따릅니다. 자세한 내용은 관리 ID를 사용하여 함수 앱 및 스토리지 계정 구성을 참조하세요.

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 Functions는 가상 네트워크의 리소스에 대한 함수 앱 액세스를 제공하는 가상 네트워크 통합을 지원합니다. 통합 후 앱은 가상 네트워크를 통해 아웃바운드 트래픽을 라우팅합니다. 그런 다음 앱은 특정 서브넷의 트래픽만 허용하는 규칙을 사용하여 프라이빗 엔드포인트 또는 리소스에 액세스할 수 있습니다. 대상이 가상 네트워크 외부의 IP 주소인 경우 NAT 게이트웨이를 구성하지 않는 한 원본 IP 주소는 앱의 속성에 나열된 주소 중 하나입니다.

함수 앱에 가상 네트워크 통합 을 사용하도록 설정하는 경우 웹앱 및 함수 앱에 대한 가상 네트워크 통합에 대한 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 Storage 컨테이너에 배포합니다. 시작되면 앱이 패키지를 가져오고 해당 패키지에서 함수 코드를 실행합니다. 기본적으로 내부 호스트 메타데이터(예: AzureWebJobsStorage)를 저장하는 동일한 스토리지 계정도 배포 컨테이너로 사용됩니다. 그러나 대체 스토리지 계정을 사용하거나 앱의 배포 설정을 구성하여 기본 인증 방법을 선택할 수 있습니다. 자세한 내용은 배포 기술 세부 정보 및 배포 설정 구성을 참조하세요.

IaC 파일 생성

  • Bicep, Azure Resource Manager 템플릿 또는 Terraform과 같은 도구를 사용하여 Azure 리소스를 배포하는 IaC 파일을 만듭니다.

  • IaC 파일에서 Azure Functions, 스토리지 계정 및 네트워킹 구성 요소와 같은 리소스를 정의합니다.

  • Azure Functions 권장 사항 및 모범 사례를 사용하는 샘플에는 이 IaC 샘플 리포지토리 를 사용합니다.

리팩터링에 도구 사용

VS Code의 GitHub Copilot와 같은 도구를 사용하여 코드 리팩터링, 특정 변경에 대한 수동 리팩터링 또는 기타 마이그레이션 보조 기능에 대한 도움을 받을 수 있습니다.

비고

VS Code의 GitHub Copilot에서 에이전트 모드 를 사용합니다.

다음 문서에서는 마이그레이션 프로세스를 용이하게 하기 위한 구체적인 예제와 자세한 단계를 제공합니다.

Day-0 마이그레이션을 위한 단계별 프로세스 개발

마이그레이션을 위한 장애 조치(failover) 및 장애 복구(failback) 전략을 개발하고 사전 프로덕션 환경에서 철저히 테스트합니다. AWS 람다에서 Azure Functions로 최종적으로 전환하기 전에 엔드 투 엔드 테스트를 수행하는 것이 좋습니다.

  • 기능 유효성 검사

    • Azure Functions를 로컬로 코딩하고 테스트합니다.

    • 각 함수를 철저히 테스트하여 예상대로 작동하는지 확인합니다. 이러한 테스트에는 입력/출력, 이벤트 트리거 및 바인딩 확인이 포함되어야 합니다.

    • VS Code의 curl 또는 REST 클라이언트 확장과 같은 도구를 사용하여 HTTP 트리거 함수에 대한 HTTP 요청을 보냅니다.

    • 타이머 또는 큐와 같은 다른 트리거의 경우 트리거가 올바르게 실행되고 함수가 예상대로 실행되는지 확인합니다.

  • 성능 유효성 검사

    • 성능 테스트를 수행하여 새 Azure Functions 배포를 이전 AWS 람다 배포와 비교합니다.

    • 응답 시간, 런타임 및 리소스 사용량과 같은 메트릭을 모니터링합니다.

    • Application Insights를 사용하여 테스트 단계 동안 모니터링, 로그 분석 및 문제 해결 을 수행합니다.

  • 진단 및 문제 해결 기능을 사용하여 문제 해결

    Azure Portal에서 진단 및 문제 해결 기능을 사용하여 함수 앱 문제를 해결합니다. 이 도구는 애플리케이션 충돌, 성능 저하 및 구성 문제와 같은 일반적인 문제를 신속하게 식별하고 해결하는 데 도움이 되는 진단 기능 집합을 제공합니다. 사용자가 식별하는 문제를 해결하기 위해 도구에서 제공하는 단계별 문제 해결 단계 및 권장 사항을 따릅니다.

마이그레이션된 워크로드의 최종 상태 평가

AWS에서 리소스를 해제하기 전에 플랫폼이 현재 워크로드 기대치를 충족하고 워크로드 유지 관리 또는 추가 개발을 차단하는 것은 없다는 것을 확신해야 합니다.

함수를 배포하고 테스트하여 성능 및 정확성의 유효성을 검사합니다.

Azure에 배포

VS Code 게시 기능을 사용하여 워크로드를 배포합니다. Azure Functions Core Tools 또는 Azure CLI를 사용하여 명령줄에서 워크로드를 배포할 수도 있습니다. Azure DevOps 및 GitHub Actions 도 하나의 배포를 사용합니다.

샘플 마이그레이션 시나리오 살펴보기

MigrationGetStarted 리포지토리를 템플릿으로 사용하여 개념 증명을 시작합니다. 이 리포지토리에는 시작하는 데 도움이 되는 인프라 및 소스 코드 파일이 있는 즉시 배포할 수 있는 Azure Functions 프로젝트가 포함되어 있습니다.

Terraform을 사용하려면 MigrationGetStarted-Terraform 을 대신 사용합니다.

Azure에서 애플리케이션의 성능 최적화 및 모니터링

워크로드를 마이그레이션한 후에는 Azure에서 더 많은 기능을 살펴보는 것이 좋습니다. 이러한 기능은 향후 워크로드 요구 사항을 충족하고 격차를 좁히는 데 도움이 될 수 있습니다.

Application Insights를 사용하여 모니터링 및 문제 해결

함수 앱에 Application Insights 를 사용하도록 설정하여 모니터링 및 문제 해결을 위해 자세한 원격 분석 데이터를 수집합니다. Azure Portal 또는 함수 앱의 host.json 구성 파일을 통해 Application Insights를 사용하도록 설정할 수 있습니다. Application Insights를 사용하도록 설정한 후 다음을 수행할 수 있습니다.

  • 원격 분석 데이터를 수집합니다. Application Insights는 요청 로그, 성능 메트릭, 예외 및 종속성과 같은 다양한 원격 분석 데이터를 제공합니다.

  • 로그 및 메트릭을 분석합니다. Azure Portal에서 Application Insights 대시보드에 액세스하여 로그, 메트릭 및 기타 원격 분석 데이터를 시각화하고 분석합니다. 기본 제공 도구를 사용하여 사용자 지정 쿼리를 만들고 데이터를 시각화하여 함수 앱의 성능 및 동작에 대한 인사이트를 얻습니다.

  • 경고 설정. 중요한 문제, 성능 저하 또는 특정 이벤트를 알리도록 Application Insights에서 경고를 구성합니다. 이러한 경고는 문제를 사전에 모니터링하고 신속하게 대응하는 데 도움이 됩니다.

비용 및 성능 최적화

  • 크기 조정 및 성능 최적화:

    • 자동 크기 조정 기능을 사용하여 다양한 워크로드를 효율적으로 처리합니다.

    • 런타임을 줄이고, 종속성을 최적화하고, 효율적인 코딩 방법을 사용하여 성능을 향상시키기 위해 함수 코드를 최적화합니다.

    • 자주 액세스하는 데이터에 대한 반복적인 처리 및 대기 시간을 줄이기 위한 캐싱 전략을 구현합니다.

  • 비용 관리:

    • Microsoft Cost Management 도구를 사용하여 Azure Functions 비용을 모니터링하고 분석합니다.

    • 비용을 효과적으로 관리하고 예측하도록 예산 및 비용 경고를 설정합니다.