Share via

stv1 플랫폼에서 호스트되는 VNet 삽입 API Management 인스턴스를 stv2로 마이그레이션

  • 아티클

적용 대상: 개발자 | 프리미엄

이 문서에서는 인스턴스가 외부 또는 내부 VNet에 삽입(배포)될 때 현재의 stv1 컴퓨팅 플랫폼에서 호스트되는 API Management 인스턴스를 stv2 플랫폼으로 마이그레이션하는 단계를 제공합니다. 이 시나리오에서는 VNet 구성 설정을 업데이트하여 인스턴스를 마이그레이션합니다. 이 작업을 수행해야 하는지 알아봅니다.

stv1 플랫폼에 호스트된 VNnet이 삽입되지 않은 API Management를 마이그레이션해야 하는 경우 VNet이 삽입되지 않은 API Management 인스턴스를 stv2 플랫폼으로 마이그레이션을 참조하세요.

Important

stv1 플랫폼에서 호스트되는 API Management 인스턴스에 대한 지원은 2024년 8월 31일에 사용 중지됩니다. stv1 플랫폼에서 호스트되는 인스턴스가 있는 경우 서비스 중단을 방지하려면 해당 날짜 전에 인스턴스를 stv2 플랫폼으로 마이그레이션합니다. 자세히 알아보기.

주의

  • API Management 인스턴스를 stv2 플랫폼으로 마이그레이션하는 것은 장기 실행 작업입니다.
  • 인스턴스의 VIP 주소가 변경됩니다. 마이그레이션 후에는 새 VIP 주소를 사용하도록 DNS, 방화벽 규칙 및 VNet을 비롯한 모든 네트워크 종속성을 업데이트해야 합니다. 그에 따라 마이그레이션을 계획합니다.
  • stv2로의 마이그레이션은 되돌릴 수 없습니다.

마이그레이션 중 발생하는 작업

stv1에서 stv2로의 API Management 플랫폼 마이그레이션은 기본 컴퓨팅만 업데이트해야 하며 스토리지 계층에 유지되는 서비스/API 구성에는 영향을 주지 않습니다.

  • 업그레이드 프로세스에는 이전 컴퓨팅과 병렬로 새 컴퓨팅을 만드는 작업이 포함되며, 이 작업에는 최대 45분이 걸릴 수 있습니다.
  • Azure Portal의 API Management 상태는 업데이트 중입니다.
  • 인스턴스의 VIP 주소(또는 다중 지역 배포의 경우 주소)가 변경됩니다.
  • Azure는 관리 엔드포인트 DNS를 관리하며, 마이그레이션이 성공하며 즉시 새 컴퓨팅으로 업데이트됩니다.
  • 사용자 지정 도메인이 사용 중인 경우 게이트웨이 DNS는 여전히 이전 컴퓨팅을 가리킵니다.
  • 사용자 지정 DNS를 사용하지 않는 경우 게이트웨이 및 포털 DNS는 새 컴퓨팅을 즉시 가리킵니다.
  • 내부 VNet 모드의 인스턴스에서 고객은 DNS를 관리하므로 DNS 항목은 고객이 업데이트할 때까지 이전 컴퓨팅을 계속 가리킵니다.
  • 새 컴퓨팅 또는 이전 컴퓨팅을 가리키는 DNS이므로 API에 대한 가동 중지 시간이 없습니다.
  • 새 컴퓨팅 서브넷이 백 엔드에 도달할 수 있도록 하려면 방화벽 규칙(있는 경우)을 변경해야 합니다.
  • 마이그레이션이 성공적으로 완료되면 기본적으로 약 15분 후에 기존 컴퓨팅이 자동으로 해제되며, 최대 48시간까지 지연할 수 있는 옵션도 있습니다. 48시간 지연 옵션은 VNet 삽입 서비스에만 사용할 수 있습니다.

필수 조건

  • stv1 컴퓨팅 플랫폼에 API Management 인스턴스를 호스트해야 합니다. 인스턴스가 stv1 플랫폼에 호스트되어 있는지 확인하려면 내 API Management 인스턴스를 호스트하는 플랫폼을 알려면 어떻게 할까요?를 참조하세요. 인스턴스는 가상 네트워크에 삽입되어야 합니다.

  • API Management 인스턴스가 배포된 각 지역의 현재 가상 네트워크에 있는 새 서브넷입니다. (또는 API Management 인스턴스와 동일한 지역 및 구독의 다른 가상 네트워크에 서브넷을 설정합니다.) 네트워크 보안 그룹을 서브넷에 연결해야 하며 API Management에 대한 NSG 규칙을 구성해야 합니다.

  • (선택 사항) API Management 인스턴스와 동일한 지역 및 구독에 있는 신규 표준 SKU 퍼블릭 IPv4 주소 리소스. 자세한 내용은 네트워크 연결에 대한 필수 조건을 참조하세요.

    Important

    • 2024년 5월부터 내부 모드의 VNet에 API Management 인스턴스를 배포(삽입)하거나 내부 VNet 구성을 새 서브넷으로 마이그레이션할 때 공용 IP 주소가 더 이상 필요하지 않습니다. 외부 VNet 모드에서 공용 IP 주소 지정은 선택 사항입니다. 제공하지 않으면 Azure 관리 공용 IP 주소가 자동으로 구성됩니다. 외부 VNet 모드에서는 공용 IP 주소가 런타임 API 트래픽에 사용됩니다.
    • 현재 내부 모드 또는 외부 모드에서 VNet의 API Management 인스턴스에 대해 영역 중복을 사용하도록 설정하는 경우 새 공용 IP 주소를 지정해야 합니다.

  • (선택 사항) 마이그레이션 성공 후 최대 48시간 동안 원래 서비스 인프라가 병렬로 유지되도록 요청하려면 Azure 지원에 문의하세요. 이 옵션은 마이그레이션 후 마이그레이션 인프라를 사용할 수 있는 기간을 제거 전 기본값인 15분 이상으로 연장합니다. 이 옵션은 서비스 소유자가 네트워크 설정을 업데이트하고 애플리케이션을 테스트하여 새 인프라를 사용할 수 있도록 VNet 삽입 서비스에만 사용할 수 있습니다. 이 확장 요청은 구독의 모든 API Management 인스턴스에 적용됩니다.

    참고 항목

    마이그레이션 후 VNet 삽입 API Management 인스턴스를 다시 원래 서브넷으로 마이그레이션하려는 경우 48시간 확장을 요청하지 않는 것이 좋습니다.

네트워크에 삽입된 API Management 인스턴스의 마이그레이션 트리거

인스턴스가 배포된 각 지역에서 새 네트워크 설정을 사용하도록 기존 네트워크 구성을 업데이트하여 네트워크 삽입 API Management 인스턴스를 stv2 플랫폼으로 마이그레이션합니다. 해당 업데이트가 완료된 후 선택적 단계로 사용했던 원래 VNet 및 서브넷으로 다시 마이그레이션할 수 있습니다.

프리미엄 계층에서 제공되는 영역 중복을 사용하도록 설정하여 stv2 플랫폼으로 마이그레이션할 수도 있습니다.

Important

API Management 인스턴스의 VIP 주소가 변경됩니다. 그러나 API 요청은 마이그레이션 중에 응답성을 유지합니다. 인프라 구성(예: 사용자 지정 도메인, 위치 및 CA 인증서)은 30분 동안 잠깁니다. 마이그레이션 후에는 새 VIP 주소를 사용하도록 DNS, 방화벽 규칙 및 피어링된 VNet을 포함한 모든 네트워크 종속성을 업데이트해야 합니다.

네트워크 구성 업데이트

Azure Portal 또는 다른 Azure 도구(예: 동일하거나 다른 VNet의 새 서브넷으로 마이그레이션)를 사용할 수 있습니다. 다음 이미지는 새 서브넷으로 마이그레이션하는 동안 발생하는 상황에 대한 높은 수준의 개요를 보여 줍니다.

새 서브넷으로의 현재 위치 마이그레이션 다이어그램.

예를 들어, 포털을 사용하려면 다음을 수행합니다.

  1. 포털에서 API Management 인스턴스로 이동합니다.
  2. 왼쪽 메뉴에서 네트워크>가상 네트워크를 차례로 선택합니다.
  3. 업데이트하려는 위치에서 네트워크 연결을 선택합니다.
  4. 구성하려는 가상 네트워크와 서브넷을 선택합니다. 선택적으로 새 공용 IP를 선택합니다. 적용을 선택합니다.
  5. API Management 인스턴스의 나머지 위치에 대한 VNet 설정을 계속 구성합니다.
  6. 상단 탐색 모음에서 저장을 선택합니다.

VNet 구성을 업데이트하면 API Management 인스턴스의 상태가 업데이트 중으로 변경됩니다. 마이그레이션 프로세스를 완료하는 데 약 45분이 소요됩니다. 상태가 온라인으로 변경되면 마이그레이션이 완료된 것입니다.

(선택 사항) 원래 서브넷으로 다시 마이그레이션

선택적으로 stv2 플랫폼으로 마이그레이션하기 전에 각 지역에서 사용한 원래 서브넷으로 다시 마이그레이션할 수 있습니다. 이렇게 하려면 VNet 구성을 다시 업데이트하고 이번에는 각 지역의 원래 VNet과 서브넷을 지정합니다. 이전 마이그레이션과 마찬가지로 장기 실행 작업이 예상되며 VIP 주소가 변경되어야 합니다.

다음 이미지는 원래 서브넷으로 다시 마이그레이션하는 동안 발생하는 상황에 대한 높은 수준의 개요를 보여 줍니다.

원래 서브넷으로의 전체 마이그레이션 다이어그램.

Important

VNet과 서브넷이 잠겨 있거나 원래 VNet이 배포된 리소스 그룹에 리소스 잠금이 있는 경우, 다른 stv1 플랫폼 기반 API Management 인스턴스가 여기에 배포되었으므로 원래 서브넷으로 다시 마이그레이션하기 전에 잠금을 제거해야 합니다. 원래 서브넷으로 마이그레이션을 시도하기 전에 잠금 제거가 완료될 때까지 기다립니다. 자세히 알아보기.

참고 항목

원래 서브넷으로 다시 마이그레이션하려는 경우 기존 인프라 유지 관리를 위해 구독 48시간 확장을 요청하지 않는 것이 좋습니다. 그렇지 않으면 마이그레이션이 지연됩니다. 확장을 취소해야 하는 경우 Azure 지원에 문의하세요.

추가 필수 조건

  • API Management 인스턴스가 배포된 각 지역의 잠금 해제된 원래 서브넷입니다. 네트워크 보안 그룹을 서브넷에 연결해야 하며 API Management에 대한 NSG 규칙을 구성해야 합니다.

  • (선택 사항) API Management 인스턴스와 동일한 지역 및 구독에 있는 신규 표준 SKU 퍼블릭 IPv4 주소 리소스.

    Important

    • 2024년 5월부터 내부 모드의 VNet에 API Management 인스턴스를 배포(삽입)하거나 내부 VNet 구성을 새 서브넷으로 마이그레이션할 때 공용 IP 주소가 더 이상 필요하지 않습니다. 외부 VNet 모드에서 공용 IP 주소 지정은 선택 사항입니다. 제공하지 않으면 Azure 관리 공용 IP 주소가 자동으로 구성됩니다. 외부 VNet 모드에서는 공용 IP 주소가 런타임 API 트래픽에 사용됩니다.
    • 현재 내부 모드 또는 외부 모드에서 VNet의 API Management 인스턴스에 대해 영역 중복을 사용하도록 설정하는 경우 새 공용 IP 주소를 지정해야 합니다.

VNet 구성 업데이트

  1. 포털에서 원래 VNet으로 이동합니다.
  2. 왼쪽 메뉴에서 서브넷을 선택한 다음, 원래 서브넷을 선택합니다.
  3. 원래 IP 주소가 API Management에서 해제되었는지 확인합니다. 사용 가능한 IP에서 서브넷에 사용할 수 있는 IP 주소 수를 적어 둡니다. 모든 주소(Azure 예약 주소 제외)를 사용할 수 있어야 합니다. 필요한 경우 IP 주소가 해제될 때까지 기다립니다.
  4. 이전 섹션의 마이그레이션 단계를 반복합니다. 각 지역에서 원래 VNet 및 서브넷을 지정합니다. 선택적으로 새 공용 IP를 선택합니다.
  5. 상단 탐색 모음에서 저장을 선택합니다.

VNet 구성을 업데이트하면 API Management 인스턴스의 상태가 업데이트 중으로 변경됩니다. 마이그레이션 프로세스를 완료하는 데 약 45분이 소요됩니다. 상태가 온라인으로 변경되면 마이그레이션이 완료된 것입니다.

마이그레이션 확인

마이그레이션이 성공했는지 확인하려면 상태가 온라인으로 변경되면 API Management 인스턴스의 플랫폼 버전을 확인합니다. 마이그레이션에 성공하면 값은 stv2 또는 stv2.1입니다.

이전 게이트웨이가 제거되기 전에 설정 확인

VNet 삽입 API Management 인스턴스를 성공적으로 마이그레이션한 후 마이그레이션 중에 만들어진 마이그레이션 컴퓨팅과 새 컴퓨팅은 짧은 시간(약 15분) 동안 공존합니다. 이는 배포의 유효성을 검사하는 데 사용할 수 있는 짧은 시간이며 애플리케이션이 예상대로 작동합니다. (미리 Azure 지원팀에 문의하면 이 기간을 48시간까지 연장할 수 있습니다.)

  • 이 기간 동안 이전 게이트웨이와 새 게이트웨이는 모두 온라인 상태이며 트래픽을 처리합니다. 이 기간 동안에는 비용이 청구되지 않습니다.
  • 이 창을 사용하면 새 VIP 주소와 서브넷 주소 공간을 사용하도록 DNS, 방화벽 규칙 및 VNet을 포함한 모든 네트워크 종속성을 업데이트할 수 있습니다.
  • 또한 업데이트된 인스턴스의 네트워크 상태를 확인하여 종속성에 대한 인스턴스의 연결을 확인합니다. 포털의 왼쪽 메뉴에 있는 배포 및 인프라에서 네트워크>네트워크 상태를 선택합니다. 필요한 경우 UDR 및 NSG 규칙과 같은 설정을 업데이트합니다.
  • 해당 기간이 지나면 이전 게이트웨이는 해제되고 새 게이트웨이가 트래픽을 제공하는 유일한 게이트웨이가 됩니다.

마이그레이션이 실패할 경우 자동으로 되돌리기

마이그레이션 프로세스 중에 오류가 발생할 경우 인스턴스가 자동으로 stv1 플랫폼으로 되돌아갑니다. 마이그레이션이 성공적으로 완료되면(인스턴스의 플랫폼 버전이 stv2 또는 stv2.1로 표시되고 상태가 온라인으로 표시됨) stv1 플랫폼으로 롤백할 수 없습니다.

마이그레이션이 실패하는 경우 도움을 받으려면 Azure 지원에 문의하세요.

수동으로 롤백하는 기능이 필요한 경우 새 stv2 인스턴스를 원본 API Management 인스턴스와 병렬 배포하는 것이 좋습니다.

도움말 및 지원 

서비스 중단을 최소화하면서 stv2 플랫폼으로 마이그레이션할 수 있도록 도와드리겠습니다.

질문이 있는 경우 Microsoft Q&A에서 커뮤니티 전문가로부터 빠른 답변을 가져오세요. 지원 계획이 있고 기술 지원이 필요한 경우 지원 요청을 만드세요.

  1. 요약의 경우 문제에 대한 설명(예: "stv1 사용 중지")을 입력합니다.
  2. 문제 형식에서 기술적을 선택합니다.
  3. 구독 아래에서 구독을 선택합니다.
  4. 서비스에서 내 서비스를 선택한 다음, API Management 서비스를 선택합니다.
  5. 리소스에서 지원 요청을 만드는 Azure 리소스를 선택합니다.
  6. 문제 유형에 대해 운영 및 관리를 선택합니다.
  7. 문제 하위 형식의 경우 업그레이드, 크기 조정 또는 SKU 변경 내용을 선택합니다.

자주 묻는 질문

  • 마이그레이션 경로를 선택하려면 어떤 정보가 필요한가요?

    • API Management 인스턴스의 네트워크 모드는 무엇인가요?
    • 사용자 지정 도메인이 구성되어 있나요?
    • 방화벽이 관련되어 있나요?
    • 관련된 IP의 업스트림/다운스트림에서 사용하는 알려진 종속성이 있나요?
    • 다중 지역 배포인가요?
    • 기존 인스턴스를 수정할 수 있나요, 아니면 병렬 설정이 필요한가요?
    • 가동 중지 시간이 있을 수 있나요?
    • 업무 외 시간에 마이그레이션을 수행할 수 있나요?

  • 마이그레이션의 필수 조건은 무엇인가요?

    VNet 삽입 인스턴스의 경우 각 VNet(외부 또는 내부 모드)에서 마이그레이션하려면 새 서브넷이 필요합니다. 외부 모드에서는 선택적으로 공용 IP 주소 리소스를 제공합니다. 서브넷에는 여기에 설명된 대로 stv2 플랫폼에 대한 규칙에 따라 NSG가 연결되어 있어야 합니다.

  • 마이그레이션으로 인해 가동 중지 시간이 발생하나요?

    이전 게이트웨이는 새 컴퓨팅이 정상이고 온라인 상태인 후에만 제거되므로 기본 호스트 이름을 사용하는 경우 가동 중지 시간이 없어야 합니다. 영향을 받은 API가 작동하려면 모든 네트워크 종속성을 미리 처리해야 합니다. 그러나 사용자 지정 도메인이 사용 중인 경우 업데이트될 때까지 제거된 컴퓨팅을 가리키며 이로 인해 가동 중지 시간이 발생할 수 있습니다. 또는 Azure 지원 티켓을 미리 만들어서 이전 게이트웨이가 최대 48시간 동안 유지되도록 요청할 수 있습니다. 이전 컴퓨팅과 새 컴퓨팅이 공존하면 유효성 검사가 쉽게 진행되며, 사용자 지정 DNS 항목을 원하는 대로 업데이트할 수 있습니다.

  • 내 트래픽은 방화벽을 통해 강제로 터널됩니다. 무엇을 변경해야 하나요?

    • 우선 마이그레이션을 위해 만든 새 서브넷이 다음 구성을 유지하는지 확인합니다(현재 서브넷에 미리 구성되어 있어야 함).
      • 여기에 설명된 대로 서비스 엔드포인트 사용
      • UDR(사용자 정의 경로)에는 ApiManagement의 홉이 있으며 서비스 태그가 방화벽 주소뿐만 아니라 "인터넷"으로 설정됩니다.
    • stv2에 대한 NSG 구성 요구 사항은 방화벽이 있는지 여부에 관계없이 동일하게 유지됩니다. 새 서브넷에 방화벽이 있는지 확인합니다.
    • 새 서브넷의 IP 주소 범위를 사용하도록 API Management 인스턴스의 현재 IP 주소 범위를 참조하는 방화벽 규칙을 업데이트해야 합니다.

  • 마이그레이션 중에 데이터 또는 구성이 손실될 수 있나요?

    stv1을 stv2로 마이그레이션하려면 컴퓨팅 플랫폼만 업데이트해야 하며 내부 스토리지 계층은 변경되지 않습니다. 따라서 마이그레이션 프로세스 중에는 모든 구성이 안전합니다. 여기에는 사용하도록 설정된 경우 유지되는 시스템 할당 관리 ID가 포함됩니다.

  • 마이그레이션이 완료되고 성공했는지 확인하려면 어떻게 해야 하나요?

    개요 페이지의 상태가 플랫폼 버전 stv2 또는 stv2.1과 함께 온라인으로 표시되는 경우 마이그레이션은 완전하고 성공적인 것으로 간주됩니다. 또한 네트워크 블레이드의 네트워크 상태가 모든 필수 연결에 대해 녹색으로 표시되는지 확인합니다.

  • 포털을 사용하여 마이그레이션을 수행할 수 있나요?

    예, VNet 삽입 인스턴스는 네트워크 블레이드에서 서브넷 구성을 변경하여 마이그레이션할 수 있습니다.

  • 인스턴스의 IP 주소를 유지할 수 있나요?

    인스턴스가 VNet에 삽입된 경우 현재 IP 주소를 보존할 방법이 없습니다.

  • 기존 인스턴스를 수정하지 않는 마이그레이션 경로가 있나요?

    예, 병렬 마이그레이션이 필요합니다. 즉, 현재 인스턴스와 병렬로 새 API Management 인스턴스를 만들고 구성을 새 인스턴스에 복사합니다.

  • 마이그레이션이 실패하면 어떻게 되나요?

    마이그레이션을 시작한 후 API Management 인스턴스가 플랫폼 버전을 stv2 또는 stv2.1로, 상태를 온라인으로 표시하지 않으면 실패했을 수 있습니다. 서비스는 자동으로 이전 인스턴스로 롤백되며 변경되지 않습니다.

  • 마이그레이션 중에 사용할 수 없는 기능은 무엇인가요?

    API 요청은 마이그레이션 중에도 응답 상태를 유지합니다. 인프라 구성(예: 사용자 지정 도메인, 위치 및 CA 인증서)은 30분 동안 잠깁니다. 마이그레이션 후에는 새 VIP 주소를 사용하도록 DNS, 방화벽 규칙 및 VNet을 비롯한 모든 네트워크 종속성을 업데이트해야 합니다.

  • 마이그레이션은 얼마나 걸리나요?

    새 VNet 구성으로 마이그레이션하는 데 예상되는 기간은 약 45분입니다. 마이그레이션이 이미 수행되었는지 확인하는 표시기는 인스턴스 상태가 업데이트 중이 아닌 온라인으로 복귀되었는지 확인합니다.

  • 마이그레이션을 시도하기 전에 VNet 구성의 유효성을 검사하는 방법이 있나요?

    실제 마이그레이션에 사용하는 새 VNet, 서브넷 및(선택 사항) IP 주소 리소스를 사용하여 새 API Management 인스턴스를 배포할 수 있습니다. 배포가 완료된 후 네트워크 상태 페이지로 이동하여 모든 엔드포인트 연결 상태가 녹색인지 확인합니다. 그렇다면 이 새 API Management 인스턴스를 제거하고 원래 stv1 호스팅 서비스를 사용하여 실제 마이그레이션을 진행할 수 있습니다.

  • 필요한 경우 마이그레이션을 롤백할 수 있나요?

    마이그레이션 프로세스 중에 오류가 발생하면 인스턴스가 자동으로 stv1 플랫폼으로 롤백됩니다. 그러나 서비스가 성공적으로 마이그레이션된 후에는 stv1 플랫폼으로 롤백할 수 없습니다.

    VNet 삽입 서비스가 성공적으로 마이그레이션된 후 마이그레이션 게이트웨이가 계속해서 트래픽을 처리하고 네트워크 설정을 확인할 수 있는 기간은 짧습니다. 이전 게이트웨이를 제거하기 전에 설정 확인 참조

  • 사용자 지정 도메인/프라이빗 DNS 영역을 변경해야 하나요?

    내부 모드의 VNet 삽입 인스턴스를 사용하면 프라이빗 DNS 영역을 마이그레이션 후 얻은 새 VNet IP 주소로 업데이트해야 합니다. 비 Azure DNS 영역도 업데이트해야 합니다(예: API Management 개인 IP 주소를 가리키는 온-프레미스 DNS 서버). 그러나 외부 모드에서 기본 도메인을 사용 중인 경우 마이그레이션 프로세스 중에 자동으로 업데이트합니다.

  • 내 stv1 인스턴스는 여러 Azure 지역(다중 지역)에 배포됩니다. stv2로 업그레이드하려면 어떻게 해야 하나요?

    다중 지역 배포에는 다른 위치에 배포된 더 많은 관리 게이트웨이가 포함됩니다. 각 위치는 새 서브넷과 새 공용 IP(영역 중복을 사용하도록 설정할 때 필요함)를 제공하여 별도로 마이그레이션해야 합니다. 위치 블레이드로 이동하여 나열된 각 위치에서 변경을 수행합니다. 인스턴스는 모든 위치가 마이그레이션된 경우에만 새 플랫폼으로 마이그레이션된 것으로 간주됩니다. 모든 지역 게이트웨이는 마이그레이션 프로세스 전반에 걸쳐 계속해서 정상적으로 작동합니다.

  • stv1 인스턴스를 동일한 서브넷으로 업그레이드할 수 있나요?

    • 가동 중지 시간 없이 단일 패스로 stv1 인스턴스를 동일한 서브넷으로 마이그레이션할 수 없습니다. 그러나 필요에 따라 마이그레이션된 인스턴스를 원래 서브넷으로 다시 이동할 수 있습니다. 자세한 내용은 여기를 참조하세요.
    • 이전 게이트웨이는 서브넷을 비우는 데 15분~45분 정도 걸리므로 이동을 시작할 수 있습니다. 그러나 지원 티켓으로 이 시간을 48시간까지 늘리도록 요청할 수 있습니다.
    • stv2 종속성에 대해 NSG 및 방화벽에 대한 이전 서브넷의 네트워킹이 업데이트되었는지 확인합니다.
    • 서브넷 IP 주소 할당은 비결정적이므로 원래 서브넷으로 다시 이동할 때 "내부 모드" 배포에 대한 원래 ILB(수신) IP가 변경될 수 있습니다. A 레코드를 사용하는 경우 DNS 변경이 필요합니다.

  • 라이브 트래픽을 전환하기 전에 새 게이트웨이를 테스트할 수 있나요?

    • 기본적으로 이전 게이트웨이와 새 관리형 게이트웨이는 15분 동안 공존하며 배포의 유효성을 검사하는 데 약간의 시간이 소요됩니다. Azure 지원 티켓을 통해 이 시간을 최대 48시간까지 늘리도록 요청할 수 있습니다. 이 변경으로 인해 이전 및 새 관리형 게이트웨이가 활성 상태를 유지하므로 트래픽을 수신할 수 있으며 유효성 검사가 용이해집니다.
    • 마이그레이션 프로세스는 기본 도메인 이름을 자동으로 업데이트하고, 해당 이름이 사용될 경우 트래픽은 즉시 새 게이트웨이로 라우팅됩니다.
    • 사용자 지정 도메인 이름을 사용 중인 경우 CNAME을 사용하지 않는 경우 해당 DNS 레코드를 새 IP 주소로 업데이트해야 할 수 있습니다. 고객은 전환하기 전에 hosts 파일을 새 API Management IP로 업데이트하고 인스턴스의 유효성을 검사할 수 있습니다. 이 유효성 검사 프로세스 중에 이전 게이트웨이는 라이브 트래픽을 계속 제공합니다.

  • 기본 도메인 이름을 사용할 때 고려해야 할 사항이 있나요?

    외부 모드에서 기본 DNS 이름을 사용하는 인스턴스에는 마이그레이션 프로세스를 통해 DNS가 자동으로 업데이트됩니다. 또한 항상 기본 도메인 이름을 사용하는 관리 엔드포인트는 마이그레이션 프로세스를 통해 자동으로 업데이트됩니다. 성공적인 마이그레이션 시 전환이 즉시 수행되므로 새 인스턴스는 즉시 트래픽을 수신하기 시작하며, 영향을 받는 API를 사용할 수 없도록 네트워킹 제한/종속성을 미리 처리해야 합니다.

  • 자체 호스팅 게이트웨이에 대해 무엇을 고려해야 하나요?

    자체 호스팅 게이트웨이에서는 아무 것도 수행할 필요가 없습니다. stv1 플랫폼 사용 중지의 영향을 받는 Azure에서 실행되는 API Management 인스턴스를 마이그레이션하기만 하면 됩니다. API Management 인스턴스의 구성 엔드포인트에 대한 새 IP가 있을 수 있으며 IP에 고정된 네트워킹 제한을 업데이트해야 합니다.

  • 개발자 포털은 마이그레이션 시 어떻게 영향을 받나요?

    개발자 포털에는 영향을 주지 않습니다. 사용자 지정 도메인을 사용하는 경우 마이그레이션 후에 DNS 레코드를 유효한 IP로 업데이트해야 합니다. 그러나 기본 도메인이 사용 중인 경우 마이그레이션 성공 시 자동으로 업데이트됩니다. 마이그레이션하는 동안 개발자 포털에 대한 가동 중지 시간이 없습니다.

  • stv2로 마이그레이션한 후 비용이 영향을 받나요?

    stv2에 대한 청구 모델은 동일하게 유지되며 마이그레이션 도중과 마이그레이션 후에 더 이상 비용이 발생하지 않습니다.

  • stv1에서 stv2로 마이그레이션하려면 어떤 RBAC 권한이 필요하나요?

    마이그레이션을 수행하는 사용자/프로세스에는 API Management 인스턴스에 대한 쓰기 권한이 필요합니다. 또한 다음 두 가지 권한이 필요합니다.

    • Microsoft.Network/virtualNetworks/subnets/join/action
    • Microsoft.Network/publicIPAddresses/join/action

동영상

관련 콘텐츠