Azure API Management 인스턴스의 용량

적용 대상: 개발자 | 기본 | 표준 | 프리미엄

용량은 부하를 더 많이 수용하기 위해 정보에 근거하여 API Management 인스턴스를 확장 또는 업그레이드할지 여부에 대한 결정을 내리는 데 가장 중요한 Azure Monitor 메트릭입니다. 이러한 구성은 복잡하며 특정 동작을 적용합니다.

이 문서에서는 용량이 무엇이며 어떻게 동작하는지에 대해 설명합니다. Azure Portal에서 용량 메트릭에 액세스하는 방법을 보여주고 API Management 인스턴스에 대한 확장이나 업그레이드를 고려할 시기를 제안합니다.

Important

이 문서에서는 용량 메트릭에 따라 Azure API Management 인스턴스를 모니터링하고 크기 조정하는 방법을 설명합니다. 그러나 개별 API Management 인스턴스가 실제로 용량에 도달했을 때 어떤 일이 발생하는지 이해하는 것도 마찬가지로 중요합니다. Azure API Management는 인스턴스의 실제 오버로드를 방지하기 위해 서비스 수준 제한을 적용하지 않습니다. 인스턴스가 실제 용량에 도달하면 들어오는 요청을 처리할 수 없는 과부하된 웹 서버와 유사하게 작동합니다. 대기 시간이 증가하고 연결이 끊어지며 시간 제한 오류가 발생하는 등의 작업이 수행됩니다. 이는 API 클라이언트가 다른 외부 서비스(예: 다시 시도 정책 적용)와 마찬가지로 이러한 가능성을 처리할 준비가 되어 있어야 함을 의미합니다.

필수 조건

이 문서의 단계를 따르려면 다음이 있어야 합니다.

가용성

Important

용량 메트릭의 최대 집계는 API Management의 프리미엄 계층에서만 지원됩니다.

용량이란?

용량 메트릭에 대해 설명하는 다이어그램입니다.

용량은 API Management 인스턴스의 로드를 나타내는 지표입니다. 리소스(CPU, 메모리) 사용량 및 네트워크 큐 길이를 반영합니다. CPU 및 메모리 사용량은 다음을 통해 리소스 사용량을 나타냅니다.

  • 요청 처리와 같은 API Management 데이터 평면 서비스(요청 전달 또는 정책 실행을 포함할 수 있음)
  • Azure Portal 또는 Azure Resource Manager를 통해 적용되는 관리 작업 또는 개발자 포털에서 오는 부하와 같은 API Management 관리 영역 서비스.
  • 선택된 운영 체제 프로세스(새 연결에서의 TLS 핸드셰이크 비용을 포함하는 프로세스 포함)
  • 인스턴스의 기본 컴퓨팅 리소스에 대한 OS 업데이트와 같은 플랫폼 업데이트.
  • 추가 용량을 사용할 수 있는 활동에 관계없이 배포된 API의 수입니다.

용량은 API Management 인스턴스의 모든 단위에서 가져온 자체 값의 평균입니다.

용량 메트릭은 API Management 인스턴스의 문제를 표시하도록 설계되었지만 문제가 용량 메트릭의 변경 사항에 반영되지 않는 경우가 있습니다.

용량 메트릭 동작

용량의 구문 때문에, 실제 용량은 많은 변수의 영향을 받을 수 있습니다. 예를 들면:

  • 연결 패턴(요청 시 새 연결 대 기존 연결 재사용)
  • 요청 및 응답의 크기
  • 요청을 보내는 각 API 또는 클라이언트 수에 관해 구성된 정책

요청에 대한 작업이 복잡할수록 용량 소비는 더 많아집니다. 예를 들어, 복잡한 변환 정책은 간단한 요청 전달보다 훨씬 많은 CPU를 소비합니다. 느린 백 엔드 서비스 응답도 이것을 증가시킵니다.

Important

용량은 처리 중인 요청 수에 대한 직접 측정값이 아닙니다.

용량 메트릭 스파이크

용량도 일시적으로 급증하거나 처리 중인 요청이 없더라도 0보다 클 수 있습니다. 이런 현상은 시스템 또는 플랫폼 전용 작업으로 인해 발생하며 인스턴스 확장 여부를 결정할 때 고려하지 않아야 합니다.

용량 메트릭이 낮다고 해서 무조건 API Management 인스턴스에 문제가 발생하지 않는다는 의미는 아닙니다.

Azure Portal을 사용하여 용량 검사

용량 메트릭

  1. Azure Portal에서 API Management 인스턴스로 이동합니다.

  2. 왼쪽 메뉴의 모니터링 아래에서 메트릭을 선택합니다.

  3. 사용 가능한 메트릭에서 용량 메트릭을 선택하고 기본 평균 집계를 그대로 둡니다.

    인스턴스를 여러 위치에 배포한 경우 잘못된 해석을 피하기 위해 항상 위치별 용량 메트릭 분석을 살펴보아야 합니다.

  4. 메트릭을 위치별로 분할하려면 상단 섹션에서 분할 적용을 선택한 다음 위치를 선택합니다.

  5. 섹션 위쪽의 막대에서 원하는 시간 범위를 선택합니다.

    예상치 못한 상황이 발생할 때 알려주도록 메트릭 경고를 설정할 수 있습니다. 예를 들어 API Management 인스턴스가 예상 최대 용량을 20분 이상 초과하면 알림을 받습니다.

    서비스의 용량이 부족할 때 알려주도록 경고를 구성하거나 Azure Monitor 자동 스케일링을 사용하여 Azure API Management 단위를 자동으로 추가할 수 있습니다. 크기 조정 작업에는 30분 정도가 소요될 수 있으니 여기에 맞게 규칙을 계획해야 합니다.
    마스터 위치만 크기 조정이 허용됩니다.

용량을 사용하여 크기 조정 결정

용량은 부하를 더 많이 수용하기 위해 정보에 근거하여 API Management 인스턴스를 확장할지 여부에 대한 결정을 내리기 위한 메트릭입니다. 다음은 일반적인 고려 사항입니다.

  • 장기 추세와 평균을 살펴봅니다.
  • 부하 증가와 관련이 없을 가능성이 높은 갑작스러운 급증은 무시합니다(설명은 용량 메트릭 동작 섹션 참조).
  • 일반적으로 용량 값이 장기간(예: 30분) 60%~70%를 초과하면 인스턴스를 업그레이드하거나 크기 조정합니다. 서비스 또는 시나리오에 따라 다른 값이 더 적당할 수 있습니다.
  • 인스턴스가 1개 단위로만 구성된 경우 용량 값이 장기간 40%를 초과하면 인스턴스를 업그레이드하거나 크기 조정합니다. 이 권장 사항은 기본 서비스 플랫폼에서 게스트 OS 업데이트를 위한 용량을 예약해야 하는 필요성을 기반으로 합니다.

트래픽을 미리 예측할 수 있는 경우 예상되는 워크로드에서 API Management 인스턴스를 테스트합니다. 테넌트의 요청 로드를 점진적으로 늘리고 최대 로드에 해당하는 용량 메트릭 값을 모니터링할 수 있습니다. Azure Portal을 사용하여 특정 시간에 얼마나 많은 용량이 사용되는지 이해하려면 이전 섹션의 단계를 수행합니다.

다음 단계