Amazon API Gateway를 Azure API Management로 마이그레이션

Amazon API Gateway를 사용하고 워크로드를 Azure로 마이그레이션하려는 경우 이 가이드를 통해 기능 매핑, 모범 사례 및 마이그레이션 프로세스를 이해할 수 있습니다. Azure에서 Azure API Management 는 API 게이트웨이 기능을 제공합니다. 이러한 기능에는 API 요청 및 응답 라우팅, 권한 부여 및 액세스 제어, 모니터링 및 거버넌스, API 버전 관리가 포함됩니다.

수행할 작업

이 가이드에서는 다음을 수행합니다.

• 현재 Amazon API 게이트웨이 배포를 평가합니다.
• Amazon API Gateway 기능을 Azure API Management 기능에 매핑합니다.
• 성공적인 마이그레이션을 위해 Amazon 및 Azure 환경을 준비합니다.
• 가동 중지 시간을 최소화하여 마이그레이션을 계획하고 실행합니다.
• 마이그레이션된 워크로드가 성능 및 안정성 요구 사항을 충족하는지 확인합니다.
• 향후 향상된 기능을 위해 아키텍처를 반복하는 방법을 알아봅니다.

예제 시나리오: 다중 백엔드 건강 기록 시스템

건강 서비스 조직은 Amazon API Gateway를 사용하여 여러 백엔드가 있는 건강 기록 시스템에 액세스합니다. 이 예제 시나리오는 AWS(Amazon Web Services) 환경에서 Amazon API Gateway의 일반적인 구성을 제공합니다. 관련 Amazon 서비스 및 프록시된 람다 함수 및 HTTP 또는 REST API를 비롯한 몇 가지 일반적인 API 백 엔드와의 일반적인 통합을 보여 줍니다.

이 아키텍처에는 다음이 포함됩니다.

• JWT(JSON 웹 토큰)를 사용하여 Amazon Cognito를 통한 사용자 인증

• Amazon API 게이트웨이에 도달하기 전에 WAF(Amazon Web Application Firewall)를 통한 요청의 보안 필터링

• 인증서 관리자에 저장된 인증서를 통해 사용자 지정 도메인으로 구성된 Amazon API 게이트웨이입니다.

• Amazon CloudWatch를 통한 모니터링

• Amazon Virtual Private Cloud(VPC) 엔드포인트를 통해 3개의 프라이빗 서브넷으로의 프라이빗 연결을 제공합니다.

• 다음을 포함한 백 엔드 서비스:

  • 환자 레코드 업데이트를 트리거하는 람다입니다.
  • 애플리케이션 부하 분산 장치 뒤에 레거시 서비스를 호스트하는 EC2(Amazon Elastic Compute Cloud)입니다.
  • 마이크로 서비스를 통한 데이터 처리를 위한 애플리케이션 부하 분산 장치 뒤에 있는 Amazon Elastic Kubernetes Service(EKS)

다음은 Azure로 마이그레이션된 워크로드의 예제 아키텍처입니다. 이 시나리오에서는 Azure API Management가 프리미엄 계층에 배포됩니다.

이 아키텍처에는 다음이 포함됩니다.

• Azure Application Gateway에 웹 애플리케이션 방화벽(WAF)을 사용하여 보안 접근을 제공합니다. 방화벽은 인증을 위해 추가된 JWT를 사용하여 요청을 전달합니다.

• 가상 네트워크 내에서 구성된 Azure API Management입니다. Microsoft Entra ID를 사용하여 JWT의 유효성을 검사합니다.

• 마이크로 서비스 기반 백 엔드에 대한 AKS(Azure Kubernetes Service)로 트래픽을 라우팅하는 내부 부하 분산 장치입니다.

• 프라이빗 엔드포인트를 통해 Azure 함수 앱 및 Microsoft Foundry 백 엔드에 대한 연결을 보호합니다.

• Azure Monitor에서 처리하는 모니터링입니다.

• Azure Key Vault 및 Azure DNS 영역을 통해 관리되는 인증서 및 도메인입니다. 인증서는 TLS 종료를 위해 Application Gateway에서도 구성됩니다.

아키텍처 개요

이 아키텍처 예제에서는 Amazon API Gateway 및 Azure API Management의 일반적인 기능을 보여 줍니다. 이러한 기능에는 네트워크 격리, 트래픽 관리 및 다양한 백 엔드 API로 라우팅, 권한 부여 및 액세스 제어 및 모니터링이 포함됩니다.

두 아키텍처 모두 비슷한 기능을 제공합니다.

• 고가용성 배포: 리소스는 내결함성을 위해 지역의 여러 가용성 영역에 분산되며, 여러 지역에 배포하여 고가용성을 위한 옵션을 제공합니다.

• 사용자 지정 도메인 및 인증서: 플랫폼은 보안 API 통신을 위해 TLS/SSL 종료를 사용하는 사용자 지정 도메인 이름을 지원합니다.

• 네트워크 격리: 백 엔드 API에 대한 트래픽은 가상 네트워크에서 격리됩니다.

• 트래픽 필터링: 에지에서 운영되는 웹 애플리케이션 방화벽이 인바운드 트래픽을 필터링하고 보호합니다.

• API 워크로드 지원: 게이트웨이는 클라우드 컴퓨팅 서비스, Kubernetes 기반 마이크로 서비스 및 사용자 지정 백 엔드를 비롯한 다양한 백 엔드 시스템에 대한 요청의 프록시 역할을 합니다.

• API 모니터링: 기본 제공 플랫폼 서비스는 API 활동을 기록하고 서비스 메트릭을 노출합니다.

• API 변조: 서비스는 응답 캐싱, 요청 할당량 및 속도 제한, CORS(원본 간 리소스 공유) 구성 및 요청/응답 변환을 지원합니다.

• API 인증 및 권한 부여: 게이트웨이는 키, OAuth 토큰 기반 액세스 및 API 기반 정책을 비롯한 여러 액세스 방법을 지원합니다.

1단계: 평가

Amazon API Gateway에서 Azure API Management로 마이그레이션하기 전에 기존 인프라 기능, API 워크로드 및 API 구성을 평가합니다. 대체하거나 매핑할 수 있는 기능을 식별합니다. 이 평가는 원활한 마이그레이션을 보장하고 애플리케이션의 기능을 유지 관리하는 데 도움이 됩니다.

인프라 기능 평가

기능 불일치와 전략

• Amazon API Gateway의 WAF 통합은 Azure API Management에서 직접 일치하지 않습니다. Amazon API 게이트웨이에서 WAF 규칙은 REST API 단계에서 직접 적용됩니다. Azure API Management에서 WAF 규칙을 구성하려면 일반적으로 게이트웨이를 통해 업스트림 Application Gateway 인스턴스, 트래픽 전달 및 TLS 종료를 배포해야 합니다. 또는 활성/활성 다중 지역 시나리오의 경우 Azure API Management 앞에서 Azure Front Door를 사용합니다.
• 사용자 지정 도메인은 Azure API Management에서 지원됩니다. Application Gateway 및 Azure Web Application Firewall을 미리 사용하는 경우 Application Gateway 계층에서 사용자 지정 도메인 및 TLS 인증서도 구성해야 합니다.
• Amazon API Gateway의 에지 최적화 엔드포인트는 지리적으로 분산된 클라이언트를 지원합니다. Azure API Management의 유사한 기능을 사용하려면 추가 비용으로 추가 지역 게이트웨이를 배포해야 합니다.

API 워크로드 비교

평가의 일환으로 기존 서비스를 유지할지 아니면 대체할지를 고려합니다. 마이그레이션이 서비스를 현대화하거나 통합할 수 있는 기회인지 평가합니다.

기능 불일치와 전략

• 람다 백 엔드 는 Amazon API 게이트웨이에서 기본적으로 HTTP API로 지원됩니다. Azure API Management는 비교 가능한 Azure 함수 앱과 네이티브 통합을 제공하지 않습니다. Azure API Management는 함수 키 또는 관리 ID를 사용하여 HTTP를 통해 함수 앱을 호출해야 합니다.
• Amazon API 게이트웨이 REST API에서 내보낸 OpenAPI 사양에는 백 엔드 서비스가 아닌 Amazon API Gateway의 프런트 엔드 구현과 관련된 세부 정보가 포함되어 있습니다. Azure API Management로 가져오거나 마이그레이션 프로세스 중에 AWS 관련 태그를 제거하고 사양에서 세부 정보(예: 백 엔드 서비스 URL)를 구성해야 합니다.
• gRPC API와 같은 Kubernetes 마이크로 서비스 백 엔드는 다르게 처리됩니다.
  • Amazon API Gateway는 VPC의 애플리케이션 로드 밸런서에 연결되고, 이를 통해 AWS EKS로의 인그레스 트래픽을 제공합니다.
  • Azure API Management는 자체 호스팅 게이트웨이를 통해서만 액세스되는 Kubernetes 클러스터의 gRPC API를 지원합니다.
  • gRPC를 사용하면 Application Gateway를 WAF로 사용할 수 없습니다.

API 구성 비교

API 구성에 대한 마이그레이션 접근 방식은 Amazon API Gateway에서 구성 범위를 고려해야 합니다. 높은 수준에서 API 범위는 Amazon API Gateway에서 Azure API Management로 다음과 같이 매핑됩니다.

다음 표에서는 Amazon API Gateway의 API 구성과 Azure API Management의 동등한 구성을 평가합니다.

기능 불일치와 전략

• 할당량 및 제한 제한은 AWS 계정당 Amazon API Gateway에 의해 부과됩니다. Azure API Management에서 가장 높은 범위는 인스턴스당 "모든 API" 범위입니다.

• Amazon API Gateway의 API 인증 및 권한 부여 방법(예: IAM 권한 및 람다 권한 부여자)은 Azure API Management에 직접 매핑되지 않습니다. 고객은 Microsoft Entra ID 또는 외부 ID 공급자를 사용하는 등 대체 인증 및 권한 부여 방법을 평가할 수 있습니다.

• Amazon API Gateway의 캐시 관련 메트릭은 Azure API Management 메트릭에 직접 매핑되지 않습니다. 캐시 적수 및 누락은 Azure API Management의 추적 로그에서 계산할 수 있습니다.

마이그레이션을 위한 리소스 검토

• Azure API Management 랜딩 존

• Azure API Management에 대한 아키텍처 모범 사례

• Azure API Management의 API 인증 및 권한 부여

• AWS 전문가를 위한 Azure

• API Management 정책 생성을 위한 Azure의 Microsoft Copilot

• AWS 설명서 MCP 서버 및 Microsoft Learn MCP 서버

또한 API 워크로드의 경우:

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

• Amazon Elastic Kubernetes Service에서 Azure Kubernetes Service로 마이그레이션

2단계: 준비

준비 단계에서 Azure 인프라를 계획하고, 테스트 및 프로덕션에 적절한 API Management 계층을 선택하고, 원본 API 및 통합 서비스를 철저히 문서화합니다. 관련 AWS 구성을 내보내고 단계적 마이그레이션 전략을 설계하여 원활한 전환을 보장합니다.

인프라 설정 계획

수신 및 송신, 방화벽, 네트워크 격리 및 Application Gateway, Azure Front Door 또는 Azure Traffic Manager와 같은 네트워크 트래픽 진입점과의 통합을 계획합니다. 특히 DNS 및 추적 가능성과 관련된 대상 Azure API Management 시스템의 프라이빗 노출과 공개 노출의 의미를 이해합니다.

Azure API Management 랜딩 존 가속기에서 지침을 검토하고 마이그레이션 및 API 백 엔드에 적합한 시나리오를 평가합니다. 워크로드가 충분히 격리되어 이점을 누릴 수 있는 경우를 고려합니다.

Azure에서 초기 마이그레이션 및 빌드에 사용할 수 있는 기본 시나리오는 샘플 워크로드를 사용하는 보안 기준입니다.

테스트 및 프로덕션 API Management 인스턴스 계획

테스트 및 프로덕션 환경에 적합한 Azure API Management 서비스 계층을 선택합니다.

• Azure Front Door 또는 Application Gateway를 통한 트래픽 진입과 함께 인바운드 및 아웃바운드 트래픽의 네트워크 격리가 필요한 경우, 현재 Azure API Management 프리미엄 계층을 사용하는 것이 좋습니다. 프리미엄 계층을 선택하는 경우 개념 증명 마이그레이션에 개발자 계층(서비스 수준 계약에서 지원되지 않음)을 사용할 수 있습니다. 개발자 계층은 프리미엄 계층에서도 사용할 수 있는 네트워킹 기능을 지원합니다. 그러나 프로덕션에 개발자 계층을 사용하면 안 됩니다.

• 가용성, 성능 및 네트워크 격리에 대한 요구 사항에 따라 표준 v2 또는 프리미엄 v2 계층을 고려합니다. 둘 다 네트워크 격리 백 엔드와의 통합을 지원합니다. 프리미엄 v2 계층은 인바운드 트래픽을 격리하기 위해 가상 네트워크에 삽입할 수도 있습니다.

• 현재 인바운드 트래픽을 격리하는 기능이 있는 프리미엄 v2 계층은 미리 보기로 제공됩니다. 프리미엄 v2 릴리스 및 마이그레이션 경로에 대한 사용 가능한 정보와 관련하여 구현 타임라인에 따라 마이그레이션에 사용할 수 있습니다.

관리 중인 원본 API 이해 및 문서화

인증 및 권한 부여 흐름, 변환 및 캐싱 메커니즘을 포함한 API 구성을 캡처합니다.

람다 권한 부여자, 애플리케이션 부하 분산 장치, 네트워크 부하 분산 장치 및 Kubernetes 워크로드와 같은 Amazon API Gateway와 통합된 모든 서비스를 식별합니다.

관리 중인 API를 카탈로그로 만들려면 Azure API 센터를 사용하고 Amazon API Gateway에서 API 를 동기화하는 것이 좋습니다.

가능한 경우 AWS 리소스 탐색기 같은 검색 도구를 사용합니다. 그러나 수동으로 수집된 정보, 내부 설명서 및 검사 목록에 크게 의존해야 합니다.

대략적인 경우에도 데이터 흐름, 네트워크 토폴로지 및 아키텍처 다이어그램을 문서화합니다.

가능한 경우 AWS 구성 내보내기

다음과 같은 구성 내보내기:

• 백 엔드 API의 OpenAPI 사양; 예를 들어 AWS 콘솔 또는 AWS CLI를 사용합니다. 원래 OpenAPI를 통해 API를 정의한 경우 해당 사양이 이미 있을 수 있습니다.

• AWS 인증서 관리자에 저장된 SSL/TLS 인증서입니다.

• WAF 규칙을 CloudFormation으로 내보내기.

외부 도구를 통해 Terraform으로 내보낼 수 있는 CloudFormation 템플릿을 포함한 아티팩트 캡처 이러한 아티팩트에서는 Azure(Bicep, Azure Resource Manager 및 Terraform 템플릿)에 쉽게 매핑할 수 있습니다.

단계별 전략 계획

단계적 마이그레이션(API별 API 또는 도메인별 도메인)을 계획하는 것이 좋습니다. 한 도메인 또는 API 엔드포인트 집합을 Azure API Management로 업데이트하고 다른 엔드포인트는 AWS에 남아 있는 동안 나머지 엔드포인트를 점진적으로 이동합니다. 이 전략을 사용하려면 클라이언트 애플리케이션이 혼합 엔드포인트를 처리하거나 라우팅 계층을 사용해야 할 수 있습니다.

3단계: 평가

마이그레이션은 마이그레이션된 시스템이 유효성 검사 기준을 충족하고 Azure API Management가 기능 또는 성능에서 중요한 회귀 없이 모든 프로덕션 트래픽을 제공하는 경우 성공한 것으로 간주됩니다.

유효성 검사 조건에는 다음이 포함됩니다.

• 인프라 유효성 검사: 네트워크 인프라는 의도한 대로 문서화되고 액세스할 수 있습니다. 예를 들어 내부 가상 네트워크에 삽입된 경우 공용 IP가 노출되지 않는지 확인합니다.

  Azure API Management 인스턴스는 작업에 필요한 네트워크 또는 종속성에 연결할 수 있습니다.

• 모든 엔드포인트에 대한 API 기능 유효성 검사: 모든 API 엔드포인트는 유효하고 잘못된 요청 및 페이로드를 포함하여 실제 시나리오에서 예상대로 수행됩니다. 구성된 정책의 요청 또는 응답 변환이 수행되는지 확인합니다.

  • 각 API에 대해 필요한 모든 인증 및 권한 부여 구성(구독 키, OAuth 토큰, 인증서)을 확인합니다.

  • 클라이언트가 변경 없이 이전과 같이 API를 사용할 수 있는지 확인합니다(도메인 이름이 변경된 경우 엔드포인트 URL 제외).

  • 적절한 범위에서 속도 제한 및 할당량이 구성되었는지 확인합니다.

• 운영 메트릭 유효성 검사: 프로덕션 부하에서 대시보드 또는 기타 관찰 가능 도구를 사용하여 성능을 모니터링합니다. 평균 대기 시간 및 처리량과 같은 메트릭을 검토하고 Amazon API Gateway의 기록 데이터와 비교합니다. 용량 메트릭을 검토하여 Azure API Management 인스턴스의 크기가 올바르게 조정되었는지 확인합니다.

4단계: 프로세스

마이그레이션 프로세스는 서비스 인프라의 복잡성과 마이그레이션할 API의 수와 복잡성에 따라 몇 주 또는 몇 달이 걸릴 것으로 예상합니다.

기본 설정 완료

Azure 테넌트 및 핵심 인프라(핵심 네트워킹, 수신, 보안)가 아직 없는 경우 Amazon API 게이트웨이 및 API를 마이그레이션하기 전에 빌드합니다. 마이그레이션에 적합한 Azure 랜딩 존 아키텍처를 사용하여 환경을 설정할 수 있습니다.

Azure API Management 코드 기반 랜딩 존 가속기가 마이그레이션에 적합한 경우 기본 Azure API Management 배포에 대해 하나를 구현합니다. Azure API Management에 Application Gateway 및 내부 가상 네트워킹을 포함합니다. 랜딩 존 가속기는 Azure API Management의 프리미엄 계층을 사용하지만 개념 증명 마이그레이션에 개발자 계층을 사용하도록 템플릿을 조정하는 것이 좋습니다.

권한 있는 관리자만 Azure API Management 인스턴스 및 API를 관리할 수 있도록 Azure RBAC(역할 기반 액세스 제어) 역할을 만들고 할당합니다.

Azure API Management 플랫폼 설정 구성

새 Azure API Management 인스턴스에서 Amazon API Gateway와 유사한 글로벌 구성을 설정합니다.

• 사용자 지정 호스트 이름: Azure API Management에 사용자 지정 도메인을 추가하고, SSL 인증서(또는 Key Vault 참조 사용)를 업로드하고, 유효성 검사를 수행합니다. 지금 또는 프로덕션 중단 직전에 이 작업을 수행합니다. Application Gateway를 사용하는 경우(권장) 사용자 지정 도메인 및 인증서를 사용하여 수신기를 구성한 다음 Azure API Management의 내부 엔드포인트를 가리킵니다. 수신기를 구성하면 도메인 유효성 검사가 필요하지 않으므로 구성이 간소화됩니다.

• 네트워킹 및 보안: Application Gateway(또는 다른 Azure 진입점)가 Azure API Management에 요청을 전달하도록 구성되어 있는지 확인합니다. Azure API Management가 백 엔드 서비스에 연결할 수 있도록 NSG(네트워크 보안 그룹) 규칙 또는 방화벽 규칙을 설정합니다. 이러한 서비스에는 Azure 백 엔드가 포함될 수 있으며, 처음에 해당 백 엔드를 가리킨 경우 원본 AWS 백 엔드도 포함될 수 있습니다.

• 관리 ID: Azure API Management에서 관리 ID를 사용하도록 설정하여 Azure 서비스를 안전하게 호출합니다(예: 인증서 또는 함수 앱의 경우 Key Vault).

이 단계가 끝날 때까지 Azure에서 Azure API Management의 작업 셸이 연결되고 API 가져오기를 시작할 준비가 된 기본 프레임워크가 있어야 합니다.

Azure API Management에서 API 가져오기 및 다시 만들기

인프라가 준비되면 API 정의 및 구성 마이그레이션을 시작합니다.

• 간단하고 위험 수준이 낮은 API로 시작: Amazon API Gateway에서 API를 다시 만들기 전에 대표 API를 사용하여 Azure API Management에서 기본 게이트웨이 기능의 유효성을 검사합니다.

• Azure API Management로 가져오기: Azure Portal 또는 스크립트를 사용하여 Amazon API Gateway 또는 백 엔드에서 Azure API Management의 새 API로 OpenAPI 정의를 가져옵니다. 가져오는 동안 Azure API Management는 API 및 작업의 구조를 자동으로 만듭니다. Amazon API Gateway에 여러 API 단계가 있는 경우 Azure API Management에서 여러 API 버전을 만듭니다.

  처음에는 현재 백 엔드를 가리키도록 각 API에 대한 백 엔드 URL을 설정합니다. 현재 백 엔드는 여전히 AWS 엔드포인트 또는 퍼블릭 엔드포인트일 수 있습니다. 예를 들어 Amazon API Gateway가 람다로 전달된 경우 Azure API Management 백 엔드를 Amazon API Gateway의 해당 API 또는 이미 마이그레이션된 경우 해당 Azure 함수 앱으로 설정할 수 있습니다. (Azure API Management 백 엔드를 Amazon API Gateway의 해당 API로 설정하는 경우 나중에 람다 함수를 Azure로 마이그레이션하는 경우 이 구성을 변경합니다.) 백 엔드가 AWS 애플리케이션 부하 분산 장치 또는 엔드포인트인 경우 Azure API Management는 인터넷을 통해 호출할 수 있습니다.

  많은 수의 API가 있는 경우 Azure API 센터를 사용하여 시간이 지남에 따라 Azure API Management로 마이그레이션되는 API와 Amazon API Gateway에 남아 있는 API를 카탈로그로 만들 수 있습니다.

  인프라의 유효성을 검사한 후 백 엔드 서비스(예: Azure 함수 앱 또는 AKS 워크로드)를 마이그레이션하거나 리팩터링하는 것이 좋습니다. Azure 마이그레이션 허브의 지침을 참조하세요.

인증 및 권한 부여 설정

• 구독 및 제품: API에 Amazon API 게이트웨이의 API 키가 필요한 경우(x-api-key 헤더를 통해) Azure API Management에서 이를 처리하는 방법을 결정합니다. 한 가지 방법은 제품에 대한 구독이 있는 사용자만 해당 API에 액세스할 수 있도록 하는 것입니다. Azure API Management에서 AWS 사용 계획과 일대일 대응하거나 논리적으로 재구성된 초기 제품을 만듭니다.

• 사용자 그룹: Azure API Management에서 사용자 그룹을 만들어 개발자와 API를 공유하는 방법을 미러링합니다.

• 명명된 값: Amazon API Gateway 단계 변수에 있던 모든 구성 값(예: 백 엔드 서비스의 엔드포인트 또는 API 키)을 Azure API Management 명명된 값으로 가져옵니다. 중요한 값의 경우 Azure Key Vault 통합을 사용합니다.

• 토큰 검색 및 유효성 검사: API 요청의 JWT 유효성 검사를 위해 API 액세스 권한을 부여하는 Azure API Management에서 유효성 검사 정책을 구성합니다. 처음에는 기존 ID 공급자(예: AWS Cognito)를 사용하고 시간이 지남에 따라 Microsoft Entra ID로 마이그레이션하는 것을 고려할 수 있습니다.

  OAuth 백 엔드에 대한 토큰을 관리하기 위해 Azure API Management에서 자격 증명 관리자를 구성합니다. 또는 정책 조각 리포지토리의 정책을 사용하여 토큰 검색 논리를 설정합니다.

• Azure API Management의 백 엔드: 각 백 엔드 서비스(URL, 자격 증명 및 기타 정보 포함)를 등록하도록 Azure API Management에서 백 엔드를 구성합니다. 이 작업은 백 엔드 URL이 변경되는 경우 업데이트할 중앙 위치를 제공합니다. 예를 들어 처음에 AWS 엔드포인트를 가리키지만 나중에 Azure 백 엔드로 전환하는 경우 Azure API Management 백 엔드 구성을 업데이트하기만 하면 됩니다.

• 기능 패리티 검사: 각 API에서 사용하는 기능 목록을 살펴보고 해결되었는지 확인합니다.

  예를 들어 이진 페이로드(이미지 및 파일) 또는 큰 페이로드를 처리하는 API를 테스트합니다. Azure API Management가 해당 시나리오에 대한 적절한 시간 제한, 크기 또는 콘텐츠 유효성 검사 설정으로 구성되었는지 확인합니다.

  Azure API Management는 가져온 모든 API를 상당히 균일하게 처리하므로 Amazon API Gateway HTTP API (최신 경량 형식)와 REST API (클래식 형식)는 Azure API Management에서 일관되게 관리됩니다. HTTP API의 사용 계획의 부재와 같은 차이점은 API가 Azure API Management에 포함되면 더 이상 중요하지 않지만, Amazon API Gateway에 특화된 제약 조건이 해결되었는지 확인해야 합니다.

변환 및 정책 매핑 관리

특히 권한 부여 및 이전 버전과의 호환성을 위해 해당되는 경우 기존 API 구성을 Azure API Management 정책으로 복제합니다.

Amazon API Gateway의 CORS 구성을 Azure API Management의 CORS 정책에 매핑합니다.

사례별로 변환(예: 스키마 매핑 또는 강화)을 처리합니다.

Azure Portal의 Azure의 Microsoft Copilot, AWS 및 Microsoft 설명서용 MCP 서버와 같은 AI 도구는 구성 매핑 또는 기타 변환을 지원할 수 있습니다. 그러나 Azure API Management에서 수동 정책 구성 및 디버깅을 수행해야 합니다.

가시성 설정

초기 모니터링을 위해 API 메트릭 및 로그를 수집하도록 Azure Monitor를 구성합니다. Application Insights와 같은 더 많은 모니터링 또는 관찰 가능성 솔루션은 나중에 계층화할 수 있습니다.

테스트 수행

Azure API Management에서 구성된 API를 사용하면 철저한 테스트가 중요합니다. 이 단계가 반복될 것으로 예상합니다.

• 기능 테스트: 각 API에 대해 Azure Portal의 테스트 콘솔 또는 클라이언트 도구를 통해 새 Azure API Management 엔드포인트를 호출하고 Amazon API 게이트웨이 엔드포인트에 대한 응답을 비교합니다. 예상 상태 코드, 헤더 및 본문을 확인합니다. 차이점이 발견되면 그에 따라 Azure API Management 정책 또는 구성을 조정합니다.

  비고

  API Management 인스턴스가 내부 가상 네트워크 구성에 있는 경우 테스트 콘솔이 작동하지 않습니다. 네트워크에 배포된 다른 클라이언트 도구를 사용하거나 API Management 개발자 포털을 사용하여 API를 테스트할 수 있습니다(인스턴스에 사용하도록 설정하는 경우).

• 보안 테스트: API 인증 및 권한 부여가 작동하는지 확인합니다. 예를 들어 Azure API Management에 유효한 JWT 또는 구독 키를 제공합니다. Azure API Management에서 요청을 수락하고 잘못된 자격 증명이 적절한 오류 코드로 거부되었는지 확인합니다. 마이그레이션 중에 토큰을 구성한 경우 JWT 유효성 검사를 위해 토큰을 전달하는 클라이언트는 다른 ID 공급자에게 권한을 부여해야 할 수 있습니다. 구독 키를 사용하는 경우 키와 함께 또는 키 없이 테스트합니다.

• 성능 기준: 도구를 사용하여 Azure API Management 엔드포인트의 부하를 시뮬레이션하고 예상 처리량을 처리할 수 있는지 확인합니다. Azure API Management를 통한 호출 대기 시간과 Amazon API Gateway를 통한 대기 시간을 비교합니다. 개발자 계층의 Azure API Management는 프리미엄 계층 및 단일 인스턴스보다 성능이 떨어지므로 프리미엄 계층 Azure API Management 인스턴스를 배포할 때까지 성능 테스트가 많이 대기할 수 있습니다.

생산 전개 시작

프로덕션 환경에서 프리미엄 계층 또는 Azure API Management의 다른 프로덕션 준비 계층으로 업그레이드합니다. 사전 프로덕션 환경에서 만든 API 가져오기 및 구성 설정을 반복하거나 마이그레이션합니다. APIOps 프로세스를 사용하여 API를 게시하고 환경 전반에서 API 구성을 관리할 수 있습니다.

낮은 환경이나 트래픽량이 적은 곳에서 컷오버를 연습합니다. 예를 들어, 하나의 비임계 API를 선택하고 하나의 클라이언트 애플리케이션이 Azure 엔드포인트를 사용하도록 전환되도록 합니다. 이 방법은 클라이언트 쪽 문제를 표시하거나 DNS 변경 프로세스의 유효성을 검사하는 데 도움이 될 수 있습니다. API 소비자가 내부인 경우 호스트 파일을 편집하거나 테스트 DNS 영역을 사용하여 도메인을 Azure API Management로 일시적으로 가리키면 변경 내용을 시뮬레이션할 수 있습니다.

• DNS 스위치: 가장 일반적인 방법은 사용자 지정 Amazon API Gateway 도메인의 DNS 항목을 새 Azure 엔드포인트를 가리키도록 전환하는 것입니다. 예를 들어 도메인 api.example.com Amazon API Gateway에 매핑한 경우 Azure API Management 호스트 이름 또는 프런트 엔드(예: Application Gateway) 도메인을 가리키도록 CNAME 또는 A 레코드를 업데이트합니다.

• TTL(Time to Live) 고려 사항: 클라이언트가 변경 내용을 신속하게 선택할 수 있도록 DNS TTL을 미리 낮춥니다. 준비가 되면 DNS를 변경합니다. 전파는 몇 분에서 몇 시간까지 걸릴 수 있습니다. 이 기간 동안 일부 트래픽은 여전히 AWS로 이동하지만 일부는 Azure로 이동될 수 있습니다. 즉시 잘라내야 하는 경우 역방향 프록시와 같은 대체 메서드를 사용할 수 있습니다.

• 대체 커버 방법: 경우에 따라 조직은 DNS 대신 역방향 프록시 또는 게이트웨이 플립을 사용합니다. 예를 들어 조직은 공용 DNS를 동일하게 유지하지만 처음에는 Application Gateway가 URL을 통해 Amazon API 게이트웨이에 요청을 전달하도록 할 수 있습니다. 전환 중에 조직은 내부에서 Application Gateway를 Azure API Management로 연결합니다. 이 방법은 더 복잡하지만 즉각적인 전환을 달성할 수 있습니다. Azure Front Door 또는 Traffic Manager를 사용하는 경우 다른 방법은 한 백 엔드(AWS)에서 다른(Azure)로 트래픽을 점진적으로 다시 분류하는 것입니다.

• 중단 중 모니터링: 전환이 발생하는 즉시 Azure API Management 인스턴스와 Amazon API Gateway 모두에 대한 요청을 면밀히 모니터링합니다. Azure Portal 또는 설정한 대시보드를 통해 Azure API Management 메트릭(요청, 대기 시간, CPU, 용량 메모리)을 실시간으로 모니터링합니다. 또한 Azure Monitor를 사용하여 4XX/5XX 응답과 같은 오류 급증을 감시합니다.

• 롤백 계획: 롤백을 실행할 조건을 결정합니다. 예를 들어 오류율이 특정 백분율을 초과하거나 중요한 기능이 손상되면 30분 이내에 되돌릴 수 있습니다. 롤백은 사용자가 한 모든 스위치를 실행 취소하는 것을 의미합니다. 예를 들어 스위치가 DNS인 경우 DNS 레코드를 되돌려 Amazon API 게이트웨이를 다시 가리킵니다. DNS 전파로 인해 롤백에 다소 시간이 걸릴 수 있습니다. 롤백 시간은 낮은 TTL의 중요성을 강조하며 두 시스템을 계속 실행할 수 있습니다. 역방향 프록시를 사용한 경우 AWS로 다시 변경하세요.

Amazon API 게이트웨이 서비스 해제

트래픽이 0이고 Azure API Management 인스턴스가 유효성 검사 조건을 충족하는 기간 후에 Amazon API 게이트웨이를 서비스 해제합니다. 일반적으로 Azure가 모든 트래픽을 처리하는 동시에 두 시스템을 병렬로 실행하여 새 시스템이 하나 이상의 전체 비즈니스 주기 또는 최대 트래픽 기간을 처리할 수 있는지를 확인합니다.

반복적 최적화

마이그레이션 후에는 기능 격차를 해소하고 모범 사례를 구현하여 API Management 구성을 반복적으로 최적화하는 데 집중합니다. 이 반복적인 개선 프로세스는 마이그레이션된 워크로드가 평가 단계에서 설정한 모든 성공 조건을 충족하도록 합니다. 또한 마이그레이션된 워크로드가 API Management에 대한 아키텍처 모범 사례를 따르도록 합니다.

기능의 결핍을 검토 및 개선

일부 Amazon API Gateway 기능에는 Azure API Management에서 일대일 매핑이 없으며 평가 섹션의 앞부분에서 설명한 대로 해결 방법이 필요합니다. 다음은 그 예입니다.

• 웹 애플리케이션 방화벽: Azure API Management는 AWS WAF가 차단하는 잘못된 페이로드를 자동으로 차단하지 않습니다. Azure Web Application Firewall을 설정하는 경우 Azure API Management는 WAF를 통해서만 액세스할 수 있고 WAF 규칙은 AWS WAF 제한을 복제해야 합니다.

• 이벤트 스트림: CloudWatch 경보 또는 이벤트가 Amazon API Gateway에 연결된 경우(예: 특정 오류 패턴) Azure API Management용 Azure Monitor에서 동등한 경고를 설정합니다(예: Azure API Management 5XX 속도에 대한 경고).

• 자동화: CI/CD(지속적인 통합 및 지속적인 업데이트) 파이프라인이 있는 경우 Azure API Management를 통합합니다. 예를 들어 코드로서의 인프라 접근 방식을 사용하여 Azure API Management 구성(API 및 정책)을 소스 제어에 저장할 수 있습니다. 이러한 방법에는 Azure Resource Manager, Bicep 또는 Terraform 템플릿 또는 APIOps 방법론이 포함될 수 있습니다. 이 통합을 통해 API에 대한 향후 변경 내용을 제어된 버전 관리와 일관되게 배포할 수 있습니다.

모범 사례 구현

비용 최적화, 보안 강화 및 운영 향상을 비롯한 모범 사례를 반복적으로 구현합니다. 안정성, 보안, 운영 우수성, 비용 관리 및 성능의 핵심 요소를 따라 Azure API Management에 대한 아키텍처 모범 사례를 검토하고 구현합니다. Azure API Management 인스턴스에 대한 Azure Advisor 권장 사항을 해결합니다.

시간이 지남에 따라 다음과 같은 더 많은 기능을 계층화합니다.

• 외부 캐싱.
• Application Insights 또는 Datadog와 같은 비 Microsoft 솔루션과 같은 Azure Monitor 이외의 모니터링 기능
• Amazon API Gateway에서 사용할 수 없는 Azure API Management의 정책입니다.

주요 내용

Amazon API Gateway를 Azure로 마이그레이션하려면 동등한 기능 또는 대체 방법을 얻기 위해 신중한 계획과 체계적인 실행이 필요합니다. 주요 성공 요인은 다음과 같습니다.

• 철저한 평가: 모든 API, 서비스 통합 및 종속성을 포함하여 기존 Amazon API Gateway 설정에 대한 자세한 평가를 수행합니다. Amazon API Gateway와 Azure API Management 간의 기능 차이 또는 차이를 식별합니다.

• 현대화 기회: 마이그레이션을 백 엔드 서비스를 현대화 또는 마이그레이션하거나 API 디자인을 개선할 수 있는 기회로 사용합니다.

• 포괄적인 준비: 네트워킹, 보안 및 인프라 설정을 포함하여 Azure 환경을 준비합니다. 모든 구성을 문서화하고 백 엔드 서비스에 필요한 변경 내용을 계획합니다.

• 증분 마이그레이션: 덜 중요한 API 또는 서비스부터 시작하여 증분 마이그레이션 방법을 계획합니다. 이 방법을 사용하면 스위치를 완전히 커밋하기 전에 새 설치 프로그램을 테스트하고 유효성을 검사할 수 있습니다.

• 유효성 검사 및 테스트: 포괄적인 테스트 및 유효성 검사 프로세스를 구현하여 Azure API Management 인스턴스가 모든 기능 및 성능 요구 사항을 충족하는지 확인합니다. 이러한 노력에는 부하 테스트, 보안 테스트 및 사용자 승인 테스트가 포함됩니다.

• 모니터링 및 관찰성: 새 Azure API Management 인스턴스에 대한 강력한 모니터링 및 관찰 가능성을 설정하여 마이그레이션 중 또는 마이그레이션 후에 발생하는 문제를 신속하게 식별하고 해결합니다.

• 반복 최적화: 마이그레이션 후 기능 격차를 해결하고 모범 사례를 구현하여 Azure API Management 설정을 지속적으로 최적화합니다.