API Management의 백 엔드

아티클
04/10/2024

적용 대상: 모든 API Management 계층

API Management의 백 엔드(또는 API 백 엔드)는 프런트 엔드 API와 해당 작업을 구현하는 HTTP 서비스입니다.

특정 API를 가져올 경우 API Management는 자동으로 API 백 엔드를 구성합니다. 예를 들어 API Management는 다음을 가져올 때 백 엔드 웹 서비스를 구성합니다.

OpenAPI 사양.
SOAP API.
HTTP 트리거 Azure Function 앱 또는 논리 앱과 같은 Azure 리소스.

API Management는 다음과 같은 다른 Azure 리소스를 API 백 엔드로 사용하는 것도 지원합니다.

Service Fabric 클러스터.
사용자 지정 서비스.

백 엔드 이점

API Management는 API의 백 엔드 서비스를 관리할 수 있도록 백 엔드 엔터티를 지원합니다. 백 엔드 엔터티는 백 엔드 서비스에 대한 정보를 캡슐화하고 API와 향상된 거버넌스에서 재사용을 승격합니다.

다음 중 하나 이상에 백 엔드를 사용합니다.

백 엔드 서비스에 대한 요청의 자격 증명 권한 부여
헤더나 쿼리 매개 변수 인증에 명명된 값이 구성된 경우 API Management 기능을 활용하여 Azure Key Vault에서 비밀을 유지합니다.
너무 많은 요청으로부터 백 엔드를 보호하기 위한 회로 차단기 규칙 정의
요청을 여러 백 엔드로 라우팅 또는 부하 분산

Azure Portal에서 또는 Azure API 또는 도구를 사용하여 백 엔드 엔터티를 구성 및 관리합니다.

set-backend-service 정책을 사용하여 백 엔드 참조

백 엔드를 만든 후 API에서 백 엔드를 참조할 수 있습니다. set-backend-service 정책을 사용하여 들어오는 API 요청을 백 엔드로 보냅니다. API에 대한 백 엔드 웹 서비스를 이미 구성한 경우 set-backend-service 정책을 사용하여 대신 백 엔드 엔터티로 요청을 리디렉션할 수 있습니다. 예시:

<policies>
    <inbound>
        <base />
        <set-backend-service backend-id="myBackend" />
    </inbound>
    [...]
<policies/>

set-backend-service 정책과 함께 조건부 논리를 사용하여 위치, 호출된 게이트웨이 또는 기타 식에 따라 유효 백 엔드를 변경할 수 있습니다.

예를 들어 호출된 게이트웨이를 기준으로 트래픽을 다른 백 엔드로 라우팅하는 정책은 다음과 같습니다.

<policies>
    <inbound>
        <base />
        <choose>
            <when condition="@(context.Deployment.Gateway.Id == "factory-gateway")">
                <set-backend-service backend-id="backend-on-prem" />
            </when>
            <when condition="@(context.Deployment.Gateway.IsManaged == false)">
                <set-backend-service backend-id="self-hosted-backend" />
            </when>
            <otherwise />
        </choose>
    </inbound>
    [...]
<policies/>

회로 차단기(미리 보기)

API 버전 2023-03-01 미리 보기부터 API Management는 백 엔드 리소스에 회로 차단기 속성을 노출하여 백 엔드 서비스가 너무 많은 요청으로 인해 과부하되지 않도록 보호합니다.

회로 차단기 속성은 정의된 시간 간격 동안의 오류 조건 수 또는 백분율, 오류를 나타내는 상태 코드 범위와 같이 회로 차단기를 발생시키는 규칙을 정의합니다.
회로 차단기가 발생되면 API Management는 정의된 시간 동안 백 엔드 서비스에 대한 요청 전송을 중지하고 클라이언트에 503 서비스를 사용할 수 없음 응답을 반환합니다.
구성된 발생 기간이 지나면 회로가 다시 설정되고 트래픽이 백 엔드로 다시 시작됩니다.

백 엔드 회로 차단기는 백 엔드가 오버로드 상황에서 복구할 수 있도록 하는 회로 차단기 패턴의 구현입니다. API Management 게이트웨이 및 백 엔드 서비스를 보호하기 위해 구현할 수 있는 일반적인 속도 제한 및 동시성 제한 정책을 보강합니다.

참고 항목

현재 백 엔드 회로 차단기는 API Management의 소비 계층에서 지원되지 않습니다.
API Management 아키텍처의 분산 특성으로 인해 회로 차단기 발생 규칙은 근사값입니다. 게이트웨이의 다른 인스턴스는 동기화되지 않으며 동일한 인스턴스의 정보에 따라 회로 차단기 규칙을 적용합니다.

예시

API Management REST API나 Bicep 또는 ARM 템플릿을 사용하여 백 엔드에서 회로 차단기를 구성합니다. 다음 예제에서는 하루에 서버 오류를 나타내는 세 개 이상의 5xx 상태 코드가 있는 경우 API Management 인스턴스 myAPIM 의 myBackend에 있는 회로 차단기가 발생합니다. 회로 차단기는 1시간 후에 다시 설정됩니다.

Bicep
ARM

회로 차단기가 있는 백 엔드 리소스에 대한 Bicep 템플릿에 다음과 유사한 코드 조각을 포함합니다.

resource symbolicname 'Microsoft.ApiManagement/service/backends@2023-03-01-preview' = {
  name: 'myAPIM/myBackend'
  properties: {
    url: 'https://mybackend.com'
    protocol: 'https'
    circuitBreaker: {
      rules: [
        {
          failureCondition: {
            count: 3
            errorReasons: [
              'Server errors'
            ]
            interval: 'P1D'
            statusCodeRanges: [
              {
                min: 500
                max: 599
              }
            ]
          }
          name: 'myBreakerRule'
          tripDuration: 'PT1H'
        }
      ]
    }
   }
 }

회로 차단기가 있는 백 엔드 리소스에 대한 ARM 템플릿에 다음과 유사한 JSON 코드 조각을 포함합니다.

{
  "type": "Microsoft.ApiManagement/service/backends",
  "apiVersion": "2023-03-01-preview",
  "name": "myAPIM/myBackend",
  "properties": {
    "url": "https://mybackend.com",
    "protocol": "https",
    "circuitBreaker": {
      "rules": [
        {
          "failureCondition": {
            "count": "3",
            "errorReasons": [ "Server errors" ],
            "interval": "P1D",
            "statusCodeRanges": [
              {
                "min": "500",
                "max": "599"
              }
            ]
          },
          "name": "myBreakerRule",
          "tripDuration": "PT1H"
        }
      ]
    }
  }
}

부하 분산 풀(미리 보기)

API 버전 2023-05-01 미리 보기부터 API Management는 API에 대한 여러 백 엔드를 구현하고 해당 백 엔드에서 요청 부하를 분산하려는 경우 백 엔드 풀을 지원합니다. 현재 백 엔드 풀은 라운드 로빈 부하 분산을 지원합니다.

다음과 같은 시나리오에 백 엔드 풀을 사용합니다.

부하를 여러 백 엔드로 분산합니다. 이 백 엔드에는 개별 백 엔드 회로 차단기가 있을 수 있습니다.
업그레이드를 위해 한 백 엔드 집합에서 다른 백 엔드 집합으로 부하를 이동합니다(파란색-녹색 배포).

백 엔드 풀을 만들려면 백 엔드의 type 속성을 pool로 설정하고 풀을 구성하는 백 엔드 목록을 지정합니다.

참고 항목

현재 백 엔드 풀에는 단일 백 엔드만 포함할 수 있습니다. 다른 백 엔드 풀에 pool 형식의 백 엔드를 추가할 수 없습니다.
API Management 아키텍처의 분산 특성으로 인해 백 엔드 부하 분산은 근사값입니다. 게이트웨이의 다른 인스턴스는 동기화되지 않으며 동일한 인스턴스의 정보에 따라 부하를 분산합니다.

예시

API Management REST API나 Bicep 또는 ARM 템플릿을 사용하여 백 엔드 풀을 구성합니다. 다음 예제에서는 API Management 인스턴스 myAPIM의 백 엔드 myBackendPool이 백 엔드 풀로 구성됩니다. 풀의 예제 백 엔드 이름은 backend-1 및 backend-2입니다.

Bicep
ARM

부하 분산 풀이 있는 백 엔드 리소스에 대한 Bicep 템플릿에 다음과 유사한 코드 조각을 포함합니다.

resource symbolicname 'Microsoft.ApiManagement/service/backends@2023-05-01-preview' = {
  name: 'myAPIM/myBackendPool'
  properties: {
    description: 'Load balancer for multiple backends'
    type: 'Pool'
    protocol: 'http'
    url: 'https://example.com'
    pool: {
      services: [
        {
          id: '/backends/backend-1'
        }
        {
          id: '/backends/backend-2'
        }
      ]
    }
  }
}

부하 분산 풀이 있는 백 엔드 리소스에 대한 ARM 템플릿에 다음과 유사한 JSON 코드 조각을 포함합니다.

{
  "type": "Microsoft.ApiManagement/service/backends",
  "apiVersion": "2023-05-01-preview",
  "name": "myAPIM/myBackendPool",
  "properties": {
    "description": "Load balancer for multiple backends",
    "type": "Pool",
    "protocol": "http",
    "url": "https://example.com",
    "pool": {
      "services": [
        {
          "id": "/backends/backend-1"
        },
        {
          "id": "/backends/backend-2"
        }
      ]
    }
  }
}

제한 사항

개발자 및 프리미엄 계층의 경우 내부 가상 네트워크에 배포된 API Management 인스턴스는 게이트웨이 엔드포인트 URL 및 백 엔드 URL이 동일할 때 HTTP 500 BackendConnectionFailure 오류가 발생할 수 있습니다. 이 제한 사항이 발생하면 기술 커뮤니티 블로그의 내부 가상 네트워크 모드에서 자체 연결 API Management 요청 제한 문서의 지침을 따릅니다.

Azure Portal을 사용하여 Service Fabric 백 엔드를 설정합니다.