다음을 통해 공유


Azure API Management의 안정성

Azure API Management는 조직이 API를 게시, 보안, 변환, 유지 관리 및 모니터링하는 데 도움이 되는 완전 관리형 서비스입니다. 이 서비스는 API 소비자와 백 엔드 서비스 사이에 배치되는 게이트웨이 역할을 하며 인증, 속도 제한, 응답 캐싱 및 요청/응답 변환과 같은 필수 기능을 제공합니다. API Management를 사용하면 조직에서 기본 백 엔드 서비스의 복잡성을 추상화하면서 일관되고 안전한 API 환경을 만들 수 있습니다.

Azure API Management는 API 인프라에 대한 고가용성 및 내결함성을 보장하도록 설계된 몇 가지 안정성 기능을 제공합니다. 이 서비스는 여러 배포 단위를 통한 기본 제공 중복성, 가용성 영역 간의 자동 장애 조치(failover) 기능 및 글로벌 API 배포를 위한 다중 지역 배포 옵션을 제공합니다. API Management에는 인프라 오류 또는 트래픽이 많은 시나리오에서도 서비스 연속성을 유지하는 데 도움이 되는 지능형 트래픽 라우팅, 상태 모니터링 및 자동 재시도 메커니즘이 포함됩니다.

이 문서에서는 가용성 영역 및 다중 지역 지원을 포함하여 Azure API Management의 안정성에 대해 설명합니다. Azure의 안정성에 대한 포괄적인 개요는 Azure 안정성을 참조하세요.

안정성 아키텍처 개요

Azure API Management는 배율 단위 기반 아키텍처를 사용하여 기본 제공 중복성 및 확장성을 제공합니다. API Management 인스턴스를 배포할 때 하나 이상의 스케일 유닛 또는 유닛을 구성합니다. 각 단위는 API 요청을 처리하는 데 필요한 컴퓨팅 리소스를 포함하는 용량의 논리적 표현입니다.

둘 이상의 단위로 인스턴스를 구성하는 경우 사용 가능한 단위가 함께 작동하여 요청을 처리하고 자동 부하 분산을 제공합니다. 단위 중 하나를 사용할 수 없게 되면 나머지 단위는 트래픽을 계속 처리하지만 용량이 감소할 수 있습니다.

높은 수준의 안정성을 얻기 위해 API Management는 지역 내의 가용성 영역과 여러 지역에 걸쳐 단위 분산을 지원합니다.

Azure API Management 서비스 계층은 다음과 같은 다양한 수준의 안정성을 제공합니다.

  • 프리미엄 계층(클래식): 최대 복원력을 위해 가용성 영역 및 지역에 분산할 수 있는 여러 단위를 지원합니다. 프리미엄 계층에서 각 단위는 API 요청을 처리하는 컴퓨팅 리소스를 제공하는 두 개의 VM(가상 머신)으로 구성됩니다.
  • 기본 v2, Standard, Standard v2 및 Premium v2(미리 보기) 계층: 모두 단일 데이터 센터 내에서 여러 단위를 지원합니다. 가용성 영역 또는 다중 지역 배포를 지원하지 않습니다.
  • 개발자 계층: 단일 단위만 지원하며 가용성 영역 또는 다중 지역 지원을 제공하지 않습니다. 이 계층은 개발 및 테스트 시나리오용으로 설계되었으며 프로덕션 워크로드에는 적합하지 않습니다.
  • 소비 계층: Azure API Management의 소비 계층에는 기본 제공 복원력 기능이 있으며 단일 Azure 데이터 센터 내의 다양한 오류에 복원력이 있습니다. 그러나 소비 계층은 가용성 영역 또는 다중 지역 배포에 대한 지원을 제공하지 않습니다. 소비 계층 Azure API Management 인스턴스의 예상 가동 시간을 이해하려면 서비스 수준 계약을 검토합니다.

인스턴스 내의 단위는 함께 작동하여 요청을 처리하고 사용 가능한 단위 간에 자동 부하 분산을 수행합니다. 단위를 사용할 수 없게 되면 나머지 단위는 트래픽을 계속 처리하지만 용량이 감소할 수 있습니다.

비고

Azure API Management의 개발자 및 프리미엄 계층은 자체 인프라에서 실행할 수 있는 자체 호스팅 게이트웨이를 지원합니다. 자체 호스팅 게이트웨이를 사용하는 경우 안정성 요구 사항을 충족하도록 구성해야 합니다. 자체 호스팅 게이트웨이는 이 문서의 범위를 벗어납니다.

프로덕션 배포 권장 사항

솔루션의 안정성 요구 사항을 지원하기 위해 Azure API Management를 배포하는 방법과 안정성이 아키텍처의 다른 측면에 미치는 영향에 대해 알아보려면 Azure Well-Architected Framework에서 Azure API Management에 대한 아키텍처 모범 사례를 참조하세요.

일시적인 오류

일시적인 오류는 구성 요소에서 짧고 간헐적인 오류입니다. 클라우드와 같은 분산 환경에서 자주 발생하며 작업의 일반적인 부분입니다. 일시적인 오류는 짧은 시간 후에 스스로 수정됩니다. 애플리케이션은 일반적으로 영향을 받는 요청을 다시 시도하여 일시적인 오류를 처리하는 것이 중요합니다.

모든 클라우드 호스팅 애플리케이션은 클라우드 호스팅 API, 데이터베이스 및 기타 구성 요소와 통신할 때 Azure 임시 오류 처리 지침을 따라야 합니다. 자세한 내용은 임시 오류 처리를 위한 권장 사항을 참조하세요.

API 앞에서 Azure API Management를 사용하는 경우 일시적인 오류로 인해 실패한 요청을 다시 시도해야 할 수 있습니다. 백 엔드 API가 너무 많은 요청에 압도되지 않도록 보호하기 위해 API Management는 재시도, 속도 제한 및 할당량 정책을 제공합니다. 백 엔드 리소스를 사용하여 부하 분산 및 회로 차단기 기능을 구성할 수도 있습니다.

가용성 영역 지원

가용성 영역은 각 Azure 지역 내에서 물리적으로 별도의 데이터 센터 그룹입니다. 한 영역이 실패하면 서비스가 나머지 영역 중 하나로 전환될 수 있습니다.

Azure API Management는 지원되는 지역에 프리미엄(클래식) API Management 인스턴스를 배포할 때 두 가지 유형의 가용성 영역 지원을 제공합니다.

  • 자동. Azure API Management는 사용할 가용성 영역을 지정하지 않을 때 자동 가용성 영역 지원을 제공합니다.

  • 수동. Azure API Management는 사용할 가용성 영역을 명시적으로 지정할 때 수동 가용성 영역 지원을 제공합니다.

가용성 영역 지원을 통해 Azure API Management는 고가용성을 위해 영역 간에 서비스 구성 요소를 복제합니다. 주 지역에서 이러한 구성 요소에는 게이트웨이(스케일 유닛), 관리 계층 및 개발자 포털이 포함됩니다. 보조 지역에서는 게이트웨이 단위만 복제됩니다. 보조 지역에 대한 자세한 내용은 다중 지역 지원을 참조하세요.

자동 가용성 영역 지원

자동 가용성 영역 지원을 사용하면 단일 단위 또는 다중 단위 인스턴스 구성을 선택하여 영역 중복성을 달성할 수 있습니다.

  • 다중 단위 구성(권장) 인스턴스에 둘 이상의 단위가 있는 경우 Azure API Management는 인스턴스의 단위를 지역의 가용성 영역 간에 분산하기 위해 최선을 다합니다. 단위가 배치되는 가용성 영역을 확인할 수 있는 방법은 없습니다. 가용성 영역의 최대 이점을 위해 최소 3개 단위를 배포하는 것이 좋습니다. 이 단위는 지역의 사용 가능한 모든 영역에 분산할 수 있습니다.

  • 단일 단위 구성. 인스턴스에 단일 단위가 있는 경우 단위의 기본 VM은 두 가용성 영역에 분산됩니다. 단위의 VM이 배치되는 가용성 영역을 확인할 수 있는 방법은 없습니다.

수동 가용성 영역 지원

사용할 가용성 영역을 명시적으로 선택하려면, 지역 중복 구성과 영역 단위 구성 중에서 선택할 수 있습니다.

  • 영역 중복: 지원되는 지역의 API Management 인스턴스에 대한 영역 중복을 수동으로 구성하여 서비스 구성 요소에 대한 중복성을 제공합니다. 사용할 둘 이상의 가용성 영역을 선택하면 Azure는 선택한 영역에 서비스 구성 요소를 자동으로 복제합니다.

  • 영역: API Management 서비스 구성 요소는 Azure 지역 내에서 선택하는 단일 영역에 배포됩니다. 모든 단위는 동일한 가용성 영역에 배치됩니다.

    중요합니다

    단일 가용성 영역에 고정하는 것은 영역 간 대기 시간이 요구 사항에 비해 너무 높고 대기 시간이 요구 사항을 충족하지 않는 것으로 확인된 경우에만 권장됩니다. 그 자체로 영역 인스턴스는 가용성 영역 중단에 대한 복원력을 제공하지 않습니다. 영역 API Management 배포의 복원력을 향상하려면 별도의 인스턴스를 여러 가용성 영역에 명시적으로 배포하고 트래픽 라우팅 및 장애 조치(failover)를 구성해야 합니다.

지역 지원

Azure API Management는 가용성 영역을 지원하는 모든 Azure 지역에서 프리미엄(클래식) 계층에 대한 가용성 영역을 지원합니다.

요구 사항

프리미엄(클래식) 계층을 사용하여 가용성 영역 지원을 구성해야 합니다. Azure API Management는 클래식 소비자, 개발자, 기본 및 표준 계층뿐만 아니라 현재 Basic v2, Standard v2, Premium v2 계층에서도 가용성 영역을 지원하지 않습니다. 인스턴스를 프리미엄(클래식) 계층으로 업그레이드하려면 프리미엄 계층으로 업그레이드를 참조하세요.

비고

엔터프라이즈 기능이 있는 프리미엄 v2 계층은 미리 보기로 제공됩니다. 디자인이 초기 액세스 기능 또는 일반 공급 기능에 의존해야 하는지 여부를 확인하려면 Premium v2의 릴리스 및 마이그레이션 경로에 대한 사용 가능한 정보와 관련하여 디자인 및 구현 타임라인을 평가합니다.

고려 사항

  • 영역 중복 인스턴스의 단위 수: 인스턴스에 대한 영역 중복성을 수동으로 구성하는 경우 선택한 모든 가용성 영역에 균등하게 분산할 수 있는 여러 API Management 단위를 구성해야 합니다. 예를 들어 두 영역을 선택하는 경우 두 개 이상의 단위를 구성해야 합니다. 대신 4개 단위 또는 두 단위의 다른 배수를 구성할 수 있습니다. 세 개의 가용성 영역을 선택하는 경우 3개 단위, 6개 단위 또는 3개 단위의 다른 배수를 구성해야 합니다.

    자동 가용성 영역 지원을 사용하는 경우 특정 수의 단위를 사용할 필요가 없습니다. 배포하는 단위는 최선의 노력을 다해 가용성 영역에 분산됩니다. 최대 영역 중복성을 위해 가용성 영역 중단이 인스턴스에 영향을 주지 않도록 3개 이상의 단위를 사용하는 것이 좋습니다.

    필요한 게이트웨이 성능을 제공하는 단위 수를 확인하려면 용량 메트릭 과 고유한 테스트를 사용합니다. 서비스 인스턴스의 크기 조정 및 업그레이드에 대한 자세한 내용은 Azure API Management 인스턴스 업그레이드 및 크기 조정을 참조하세요.

  • 자동 크기 조정: 자동 크기 조정으로 구성된 API Management 인스턴스에서 가용성 영역을 수동으로 구성하는 경우 구성 후 자동 크기 조정 설정을 조정해야 할 수 있습니다. 이 경우 자동 크기 조정 규칙 및 제한의 API Management 단위 수는 영역 수의 배수여야 합니다. 자동 가용성 영역 지원을 사용하는 경우 자동 크기 조정 설정을 조정할 필요가 없습니다.

  • IP 주소 요구 사항: 외부 또는 내부 가상 네트워크에 배포된 API Management 인스턴스에서 가용성 영역 지원을 사용하도록 설정하는 경우 현재 인스턴스에서 사용할 공용 IP 주소 리소스를 지정해야 합니다. 내부 가상 네트워크에서 공용 IP 주소는 API 요청이 아닌 관리 작업에만 사용됩니다. API Management의 IP 주소에 대해 자세히 알아봅니다.

비용

가용성 영역 구성에 관계없이 단위를 더 추가하면 비용이 더 많이 발생합니다. 자세한 내용은 API Management 가격 책정을 참조하세요.

가용성 영역 지원 구성

이 섹션에서는 Azure API Management 인스턴스에 대한 가용성 영역 지원을 구성하는 방법을 설명합니다.

비고

사용할 가용성 영역을 선택하면 실제로 논리적 가용성 영역을 선택합니다. 다른 Azure 구독에 다른 워크로드 구성 요소를 배포하는 경우 다른 논리 가용성 영역 번호를 사용하여 동일한 물리적 가용성 영역에 액세스할 수 있습니다. 자세한 내용은 물리적 및 논리적 가용성 영역을 참조하세요.

  • 가용성 영역 지원을 사용하여 API Management 인스턴스를 만듭니 다. 가용성 영역을 지원하는 지역에 프리미엄(클래식) API Management 인스턴스를 만들 때 기본적으로 가용성 영역 지원을 사용하여 생성됩니다. 자동 가용성 영역 지원을 선택하거나 영역 또는 영역 중복 지원을 수동으로 구성할 수 있습니다.

  • 가용성 영역 지원을 사용하거나 다시 구성합니다. 가용성 영역을 추가하고 가용성 영역 간에 영역 인스턴스를 이동하는 등 API Management 인스턴스에 대한 가용성 영역 구성을 변경할 수 있습니다. API Management 인스턴스에서 가용성 영역 지원을 구성하려면 Azure API Management 인스턴스에서 가용성 영역 지원 사용을 참조하세요. 구성 옵션에 대한 가동 중지 시간 요구 사항은 없습니다.

    가용성 영역 구성을 변경하는 경우 변경 내용을 적용하는 데 15~45분 이상 걸릴 수 있습니다. API Management 게이트웨이는 이 시간 동안 API 요청을 계속 처리할 수 있습니다.

    가용성 영역 구성을 변경하면 공용 및 개인 IP 주소 변경이 트리거됩니다.

용량 계획 및 관리

영역 다운 시나리오에서는 다른 가용성 영역의 추가 용량에 대한 요청이 성공한다는 보장은 없습니다. 손실된 단위의 복원이 가능한 범위 내에서 최선을 다해 수행됩니다. 가용성 영역이 손실될 때 보장된 용량이 필요한 경우 영역 손실을 고려하여 API Management 인스턴스를 만들고 구성해야 합니다. 다음을 통해 수행할 수 있습니다.

  • API Management 인스턴스의 단위를 과다할당하기
  • 자동 또는 영역 중복 가용성 영역 구성 사용

과잉 프로비저닝 원칙에 대해 자세히 알아보려면 과잉 프로비저닝을 사용하여 용량 관리를 참조하세요.

용량 메트릭 및 사용자 고유의 테스트를 사용하여 필요한 게이트웨이 성능을 제공하는 단위 수를 결정합니다. 서비스 인스턴스의 크기 조정 및 업그레이드에 대한 자세한 내용은 Azure API Management 인스턴스 업그레이드 및 크기 조정을 참조하세요.

일반 작업

이 섹션에서는 가용성 영역 지원을 사용하여 Azure API Management 인스턴스를 구성하고 모든 가용성 영역이 작동할 때 예상되는 사항에 대해 설명합니다.

  • 영역 간의 트래픽 라우팅: 정상적인 작업 중에 트래픽은 선택한 모든 가용성 영역에서 사용 가능한 모든 API Management 단위 간에 라우팅됩니다.

  • 영역 간 데이터 복제: 다음 데이터는 Azure API Management에 의해 저장 및 복제됩니다.

    • API 및 정책 정의와 같은 게이트웨이 구성은 인스턴스에 대해 선택한 가용성 영역 간에 정기적으로 동기화됩니다. 일반적으로 가용성 영역 간에 업데이트를 전파하는 데는 10초 미만이 걸립니다.
    • Azure API Management에서 제공하는 내부 캐시를 사용하는 경우 내부 캐시의 데이터입니다. 캐시 항목은 가용성 영역 간에 분산됩니다. 내부 캐시는 휘발성이며 데이터가 유지되도록 보장되지 않습니다. 캐시된 데이터를 유지해야 하는 경우 외부 캐시를 사용하는 것이 좋습니다.
    • Azure API Management에서 제공하는 속도 제한 기능을 사용하는 경우 속도 제한 카운터입니다. 속도 제한 카운터는 인스턴스에 대해 선택한 가용성 영역 간에 비동기적으로 복제됩니다.

영역 축소 경험

이 섹션에서는 가용성 영역 지원을 사용하여 Azure API Management 인스턴스를 구성하고 가용성 영역 중단이 발생할 때 예상되는 사항에 대해 설명합니다.

  • 검색 및 응답: 검색 및 응답에 대한 책임은 인스턴스에서 사용하는 가용성 영역 구성에 따라 달라집니다.

    • 자동 및 영역 중복: 자동 가용성 영역 지원을 사용하도록 구성되었거나 영역 중복성을 사용하도록 수동으로 구성된 인스턴스의 경우 Azure API Management 플랫폼은 가용성 영역에서 오류를 감지하고 응답합니다. 영역 장애 조치(failover)를 시작하기 위해 어떤 작업도 수행할 필요가 없습니다.

    • 영역 한정: 영역 한정으로 구성된 인스턴스의 경우, 가용성 영역의 손실을 감지하고 다른 가용성 영역에서 생성한 보조 인스턴스로 장애 조치(failover)를 시작해야 합니다.

  • 활성 요청: 가용성 영역을 사용할 수 없는 경우 잘못된 가용성 영역의 API Management 단위에 연결된 진행 중인 모든 요청이 종료되고 다시 시도해야 합니다.

  • 통지: 영역 수준 중단은 Azure Resource Health 및 Azure Service Health에 반영됩니다.

  • 예상 데이터 손실: 다음 데이터는 API Management에 의해 저장됩니다.

    • 게이트웨이 구성 변경- 약 10초 이내에 선택한 각 가용성 영역에 복제됩니다. 가용성 영역의 중단이 발생하면 복제되지 않은 구성 변경 내용이 손실될 수 있습니다.
    • 내부 캐시 기능을 사용하는 경우 내부 캐시의 데이터입니다. 내부 캐시는 휘발성이며 데이터가 유지되도록 보장되지 않습니다. 가용성 영역 중단 시 일부 또는 모든 캐시된 데이터가 손실될 수 있습니다. 캐시된 데이터를 유지해야 하는 경우 외부 캐시를 사용하는 것이 좋습니다.
    • 속도 제한 기능을 사용하는 경우 속도 제한 카운터입니다. 가용성 영역 중단 중에는 생존 영역에서 속도 제한 카운터가 최신 상태가 아닐 수 있습니다.
  • 예상 가동 중지 시간: 예상할 수 있는 가동 중지 시간은 인스턴스에서 사용하는 가용성 영역 구성에 따라 달라집니다.

    • 자동: 자동 가용성 영역 지원을 사용하는 인스턴스는 가용성 영역 장애가 발생해도 가동 중단이 없어야 합니다. 영향을 받지 않는 영역 또는 영역의 단위는 계속 작동합니다.

      자동 가용성 영역 지원을 사용하지만 단일 단위가 있는 인스턴스도 가동 중지 시간이 없을 것으로 예상됩니다. 이 경우 API Management는 단위의 기본 VM을 두 영역에 분산합니다. 영향을 받지 않는 영역의 VM은 계속 작동합니다.

    • 영역 중복: 영역 중복 인스턴스는 가용성 영역 중단 중에 가동 중지 시간이 없어야 합니다.

    • 영역: 영역 인스턴스의 경우 영역을 사용할 수 없는 경우 가용성 영역이 복구될 때까지 인스턴스를 사용할 수 없습니다.

  • 트래픽 경로 변경: 트래픽 경로 변경 동작은 인스턴스에서 사용하는 가용성 영역 구성에 따라 달라집니다.

    • 자동 및 영역 중복: 자동 가용성 영역 지원을 사용하도록 구성되었거나 영역 중복을 사용하도록 수동으로 구성된 인스턴스의 경우 영역을 사용할 수 없는 경우 영향을 받는 영역의 모든 단위를 사용할 수 없습니다. 인스턴스 크기를 조정하여 단위를 더 추가할 수 있습니다.

    • 영역: 영역 인스턴스의 경우 영역을 사용할 수 없는 경우 인스턴스를 사용할 수 없습니다. 다른 가용성 영역에 보조 인스턴스가 있는 경우 트래픽을 해당 보조 인스턴스로 다시 라우팅해야 합니다.

장애 복구

장애 복구 동작은 인스턴스에서 사용하는 가용성 영역 구성에 따라 달라집니다.

  • 자동 및 영역 중복: 자동 가용성 영역 지원을 사용하도록 구성되었거나 영역 중복을 사용하도록 수동으로 구성된 인스턴스의 경우 가용성 영역이 복구되면 Azure API Management는 가용성 영역의 단위를 자동으로 복원하고 단위 간의 트래픽을 정상적으로 다시 라우팅합니다.

  • 영역: 영역 인스턴스의 경우 가용성 영역이 복구된 후 원래 가용성 영역의 인스턴스로 트래픽을 다시 라우팅해야 합니다.

영역 오류 테스트

영역 오류 테스트 옵션은 인스턴스에서 사용하는 가용성 영역 구성에 따라 달라집니다.

  • 자동 및 영역 중복: 자동 가용성 영역 지원을 사용하도록 구성되거나 영역 중복성을 사용하도록 수동으로 구성된 인스턴스의 경우 Azure API Management 플랫폼은 트래픽 라우팅, 장애 조치(failover) 및 장애 복구(failback)를 관리합니다. 이 기능은 완전히 관리되므로 가용성 영역 오류 프로세스를 시작하거나 유효성을 검사할 필요가 없습니다.

  • 영역: 영역 인스턴스의 경우 Azure API Management 인스턴스를 포함하는 가용성 영역의 중단을 시뮬레이트할 방법이 없습니다. 그러나 업스트림 게이트웨이 또는 부하 분산 장치를 수동으로 구성하여 트래픽을 다른 가용성 영역의 다른 인스턴스로 리디렉션할 수 있습니다.

다중 지역 지원

다중 지역 배포를 사용하면 지원되는 하나 이상의 Azure 지역에 있는 기존 API Management 인스턴스에 지역 API 게이트웨이를 추가할 수 있습니다. 다중 지역 배포는 지리적으로 분산된 API 소비자가 인식하는 요청 대기 시간을 줄이는 데 도움이 됩니다. 또한 다중 지역 배포는 한 지역이 오프라인 상태가 될 경우 서비스 가용성을 향상시킵니다.

Azure API Management는 프리미엄(클래식) 계층의 다중 지역 배포만 지원합니다. 소비, 개발자, 기본, 기본 v2, 표준, 표준 v2 및 프리미엄 v2(미리 보기) 계층에서는 다중 지역 배포를 지원하지 않습니다. 자세한 내용은 요구 사항을 참조하세요.

지역을 추가할 때 다음을 구성합니다.

지역 지원

Azure API Management를 지원하는 모든 Azure 지역을 사용하여 프리미엄(클래식) 계층에서 다중 지역 배포를 만들 수 있습니다. 다중 지역 배포를 지원하는 지역을 보려면 지역별 제품 가용성을 참조하세요.

요구 사항

프리미엄(클래식) 계층을 사용하여 다중 지역 지원을 구성해야 합니다. 인스턴스를 프리미엄(클래식) 계층으로 업그레이드하려면 프리미엄 계층으로 업그레이드를 참조하세요.

비고

엔터프라이즈 기능이 있는 프리미엄 v2 계층은 미리 보기로 제공됩니다. 디자인이 초기 액세스 기능 또는 일반 공급 기능에 의존해야 하는지 여부를 확인하려면 Premium v2의 릴리스 및 마이그레이션 경로에 대한 사용 가능한 정보와 관련하여 디자인 및 구현 타임라인을 평가합니다.

고려 사항

  • 게이트웨이 전용: API Management 인스턴스의 게이트웨이 구성 요소만 여러 지역에 복제됩니다. 인스턴스의 관리 평면 및 개발자 포털은 원래 서비스를 배포한 주 지역에서만 호스트됩니다.

  • 네트워크 요구 사항: API Management 인스턴스가 가상 네트워크에 배포(삽입)될 때 보조 위치를 구성하려면 가상 네트워크 및 서브넷 지역이 구성 중인 보조 위치와 일치해야 합니다. 주 지역에서 가용성 영역을 추가, 제거 또는 사용하도록 설정하거나 주 지역의 서브넷을 변경하는 경우 API Management 인스턴스의 VIP 주소가 변경됩니다. 자세한 내용은 Azure API Management 서비스의 IP 주소를 참조하세요. 그러나 보조 지역을 추가하는 경우 모든 지역에 자체 프라이빗 VIP가 있기 때문에 주 지역의 VIP는 변경되지 않습니다.

  • DNS 이름: 각 지역(주 지역 포함)의 게이트웨이에는 URL 패턴을 https://<service-name>-<region>-01.regional.azure-api.net따르는 지역 DNS 이름이 있습니다( 예: https://contoso-westus2-01.regional.azure-api.net).

비용

지역을 추가하면 더 많은 비용이 발생합니다. 자세한 내용은 API Management 가격 책정을 참조하세요.

다중 지역 지원 구성

API Management 인스턴스에서 다중 지역 지원을 구성하려면 여러 Azure 지역에 Azure API Management 인스턴스 배포를 참조하세요.

API Management 인스턴스에서 지역을 제거하려면 Azure API Management 서비스 지역 제거를 참조하세요.

용량 계획 및 관리

지역 다운 시나리오에서는 다른 지역의 추가 용량에 대한 요청이 성공할 것이라는 보장은 없습니다. 지역이 손실될 때 보장된 용량이 필요한 경우 지역 손실을 고려하여 API Management 인스턴스를 만들고 구성해야 합니다. 이렇게 하려면 API Management 인스턴스의 용량을 과도하게 프로비전할 수 있습니다. 과잉 프로비저닝 원칙에 대해 자세히 알아보려면 과잉 프로비저닝을 사용하여 용량 관리를 참조하세요.

다중 지역 배포에서는 자동 크기 조정이 주 지역에만 적용됩니다. 보조 지역에는 사용자가 제어하는 수동 크기 조정 또는 사용자 지정 도구가 필요합니다.

일반 작업

이 섹션에서는 Azure API Management 인스턴스가 다중 지역 지원으로 구성되고 모든 지역이 작동할 때 예상되는 사항에 대해 설명합니다.

  • 지역 간 트래픽 라우팅: Azure API Management는 들어오는 요청을 지역 게이트웨이로 자동으로 라우팅합니다. 요청은 클라이언트에서 대기 시간이 가장 짧은 지역 게이트웨이로 라우팅됩니다. 다른 라우팅 방법을 사용해야 하는 경우 사용자 지정 라우팅 규칙을 사용하여 사용자 고유의 Traffic Manager를 구성할 수 있습니다. 자세한 내용은 API Management 지역 게이트웨이에 대한 사용자 지정 라우팅 사용을 참조하세요.

    요청이 Azure API Management 지역 게이트웨이에 도달하면 일반적으로 백 엔드 API로 라우팅됩니다(정책이 캐시된 응답 또는 오류 코드와 같은 게이트웨이에서 직접 응답을 반환하지 않는 한). 다중 지역 솔루션에서는 성능 요구 사항을 충족하는 백 엔드 API 인스턴스로 라우팅하는 데 주의해야 합니다. 자세한 내용은 지역 백 엔드 서비스에 대한 Route API 호출을 참조하세요.

  • 지역 간 데이터 복제: API 및 정책 정의와 같은 게이트웨이 구성은 추가하는 주 지역과 보조 지역 간에 정기적으로 동기화됩니다. 지역 게이트웨이에 대한 업데이트를 전파하는 데 일반적으로 10초 미만이 걸립니다.

    내부 캐시의 데이터 및 속도 제한 카운터는 지역별로 지정되며 지역 간에 복제되지 않습니다.

지역 중단 환경

이 섹션에서는 Azure API Management 인스턴스가 다중 지역 지원으로 구성되고 사용하는 지역 중 하나에서 중단이 발생할 때 예상되는 사항에 대해 설명합니다.

  • 탐지 및 응답: API Management는 지역에서 오류를 감지하고, 장애 발생 시 자동으로 설정된 다른 지역의 게이트웨이로 전환합니다.

  • 활성 요청: 잘못된 지역에서 처리 중인 모든 활성 요청은 삭제될 수 있으며 클라이언트에서 다시 시도해야 합니다.

  • 예상 데이터 손실: Azure API Management는 구성, 캐시 및 속도 제한 카운터를 제외하고 데이터를 저장하지 않습니다.

    구성 변경 내용은 약 10초 내에 각 지역에 복제됩니다. 주 지역의 중단이 발생하면 복제되지 않은 구성 변경 내용이 손실될 수 있습니다.

    내부 캐시의 데이터 및 속도 제한 카운터는 지역별로 지정되며 지역 간에 복제되지 않습니다.

  • 예상 가동 중지 시간: 게이트웨이 가동 중지 시간이 필요하지 않습니다.

    주 지역이 오프라인 상태가 되면 API Management 관리 평면 및 개발자 포털을 사용할 수 없게 되지만, 보조 지역은 최신 게이트웨이 구성을 사용하여 API 요청을 계속 처리합니다.

  • 트래픽 경로 변경: 지역이 오프라인 상태가 되면 API 요청은 실패한 지역을 중심으로 다음으로 가장 가까운 게이트웨이로 자동으로 라우팅됩니다.

장애 복구

주 지역이 복구되면 Azure API Management는 해당 지역의 단위를 자동으로 복원하고 단위 간에 트래픽을 다시 라우팅합니다.

지역 오류 테스트

예기치 않은 지역 중단에 대비하려면 지역 오류에 대한 응답을 정기적으로 테스트하는 것이 좋습니다. 지역 게이트웨이에 대한 라우팅을 사용하지 않도록 설정하여 지역 오류의 일부 측면을 시뮬레이션할 수 있습니다.

백업

Azure API Management 자체는 대부분의 런타임 데이터를 저장하지 않습니다. 그러나 Azure API Management 서비스 구성을 백업할 수 있습니다. 운영 환경(예: 개발 및 스테이징) 간에 API Management 서비스 구성을 복제하는 데 백업 및 복원 작업을 사용할 수도 있습니다.

중요합니다

백업 절차에서 사용자 및 구독과 같은 런타임 데이터가 포함되며 항상 바람직하지는 않을 수 있습니다.

백업은 개발자, 기본, 표준 및 프리미엄 계층에서 지원됩니다.

Azure API Management의 백업에 대한 자세한 내용은 Azure API Management에서 서비스 백업 및 복원을 사용하여 재해 복구를 구현하는 방법을 참조하세요.

일부 서비스 구성 요소 또는 리소스의 백업 또는 복원의 경우 APIOps 도구 및 IaC(Infrastructure as Code) 솔루션과 같은 고객 관리 옵션도 고려할 수 있습니다.

서비스 유지 관리 중 안정성

Azure API Management는 정기적인 서비스 업그레이드 및 기타 형태의 유지 관리를 수행합니다.

기본, 표준 및 프리미엄(클래식) 계층에서는 업데이트 프로세스에서 인스턴스가 업데이트를 받을 때 사용자 지정할 수 있습니다. 업그레이드가 워크로드에 미치는 영향의 유효성을 검사해야 하는 경우 업데이트 주기 초기에 업데이트를 받도록 테스트 인스턴스를 구성하고, 주기 후반에 업데이트를 받도록 프로덕션 인스턴스를 설정하는 것이 좋습니다. 또한 인스턴스에서 서비스 업데이트를 적용할 시간인 유지 관리 기간을 지정할 수도 있습니다.

유지 관리 기본 설정에 대한 자세한 내용은 API Management 인스턴스에 대한 서비스 업데이트 설정 구성을 참조하세요.

서비스 수준 약정

Azure API Management에 대한 SLA(서비스 수준 계약)는 서비스의 예상 가용성을 설명합니다. 또한 가용성 기대치를 달성하기 위해 충족해야 하는 조건에 대해서도 설명합니다. 이러한 조건을 이해하려면 온라인 서비스에 대한 SLA(서비스 수준 계약)를 검토하는 것이 중요합니다.

여러 가용성 영역 또는 지역에 API Management 인스턴스를 배포하면 SLA에 정의된 가동 시간 비율이 증가합니다.

서비스는 자체 SLA를 제공하지만 API 백 엔드와 같은 다른 워크로드 구성 요소의 예상 안정성도 고려해야 합니다.