백엔드 서버 간 부하 분산

이 페이지는 Apigee 및 Apigee Hybrid에 적용됩니다.

Apigee Edge 문서 보기

참고: 보관 파일 배포가 사용 설정된 환경에서는 Apigee UI, API, gcloud를 사용하여 대상 서버를 관리할 수 없습니다. VS Code에서 Apigee를 사용하여 보관 파일 배포용 대상 서버를 관리하려면 대상 서버(targetservers.json) 구성을 참조하세요.

Apigee는 여러 백엔드 서버 인스턴스에서 부하 분산 및 장애 조치를 기본 지원하여 API의 가용성을 높입니다.

TargetServer는 TargetEndpoint 구성에서 구체적인 엔드포인트 URL을 분리합니다. 구성에서 구체적인 URL을 정의하는 대신 이름이 지정된 TargetServer를 하나 이상 구성할 수 있습니다. 그러면 TargetEndpoint HTTPConnection에서 각 TargetServer가 이름으로 참조됩니다.

동영상

대상 서버를 이용한 API 라우팅 및 부하 분산에 대해 자세히 알아보려면 다음 동영상을 시청하세요.

동영상	설명
대상 서버를 이용한 부하 분산	대상 서버 전반에서 API 부하 분산
대상 서버 사용 환경에 기반한 API 라우팅	환경에 따라 다른 대상 서버로 API 라우팅

TargetServer 구성 정보

TargetServer 구성은 이름, 호스트, 프로토콜, 포트로 구성되며, TargetServer의 사용 설정 또는 사용 중지 여부를 나타내는 추가 요소가 포함됩니다.

다음 코드는 TargetServer 구성의 예시입니다.

{
  "name": "target1",
  "host": "1.mybackendservice.com",
  "protocol": "http",
  "port": "80",
  "isEnabled": "true"
}

TargetServers API에 대한 자세한 내용은 organization.environments.targetservers를 참조하세요.

GitHub에서 TargetServer 및 기타 항목의 스키마를 참조하세요.

TargetServer 만들기

다음 섹션에서 설명하는 대로 Apigee UI 또는 API를 사용하여 TargetServer를 만듭니다.

참고: Google Cloud 콘솔과 통합된 Apigee UI의 새 버전이 있습니다. 새 UI는 Cloud 콘솔의 Apigee라고 합니다. 아래 처음 두 탭의 안내에서는 Cloud 콘솔에서 Apigee를 사용하는 방법 또는 기본 Apigee를 사용하는 방법을 설명합니다.

Cloud 콘솔의 Apigee

Cloud 콘솔에서 Apigee를 사용하여 TargetServer를 만들려면 다음 안내를 따르세요.

1. Cloud 콘솔에서 Apigee UI에 로그인합니다.
2. 관리 > 환경 > TargetServers를 선택합니다.
3. 새 TargetServer를 정의할 환경을 선택합니다.
4. 창 상단에서 대상 서버를 클릭합니다.
5. + 대상 서버 만들기를 클릭합니다.

6. 제공된 필드에 이름, 호스트, 프로토콜, 포트를 입력합니다. 프로토콜 옵션은 REST 기반 대상 서버의 경우 HTTP이고, gRPC 기반 대상 서버의 경우 gRPC - 대상 또는 gRPC - 외부 콜아웃입니다. gRPC 프록시 지원에 대한 자세한 내용은 gRPC API 프록시 만들기를 참조하세요.

   필요한 경우 SSL 사용 설정을 선택할 수 있습니다. SSL 인증서 개요를 참조하세요.

7. 만들기를 클릭합니다.

기본 Apigee

기본 Apigee UI를 사용하여 TargetServer를 만들려면 다음 안내를 따르세요.

1. Apigee UI에 로그인합니다.
2. 관리자 > 환경 > TargetServers를 선택합니다.
3. 환경 드롭다운 목록에서 새 TargetServer를 정의할 환경을 선택합니다.

   Apigee UI는 선택한 환경의 최신 TargetServer 목록을 표시합니다.

   

4. +대상 서버를 클릭하여 선택한 환경에 새 TargetServer를 추가합니다.

   대상 서버 추가 대화상자가 표시됩니다.

   

5. 사용 설정을 클릭하여, 새 TargetServer를 생성한 직후에 정의가 적용되게 하세요.

6. 제공된 필드에 이름, 호스트, 프로토콜, 포트를 입력합니다. 프로토콜 옵션은 HTTP 또는 GRPC입니다.

   필요한 경우 SSL 체크박스를 선택할 수 있습니다. 필드에 대한 자세한 내용은 TargetServer(4MV4D 동영상)를 참조하세요.

7. 추가를 클릭합니다.

   Apigee가 새로운 TargetServer 정의를 생성합니다.

8. 새 TargetServer를 만든 후 API 프록시를 수정하고 <HTTPTargetConnection> 요소를 변경하여 새 정의를 참조할 수 있습니다.

Apigee API

다음 섹션에서는 Apigee API를 사용하여 TargetServer를 만들고 나열하는 예시를 보여줍니다.

• API를 사용하여 환경에서 TargetServer 만들기
• API를 사용하여 환경에서 TargetServer 나열

자세한 내용은 TargetServers API를 참조하세요.

API를 사용하여 환경에서 TargetServer 만들기

포트 80에서 1.mybackendservice.com에 연결되는 target1이라는 TargetServer를 만들려면 다음 API 호출을 사용합니다.

curl "https://apigee.googleapis.com/v1/organizations/$ORG/environments/$ENV/targetservers" \
  -X POST \
  -H "Content-Type:application/json" \
  -H "Authorization: Bearer $TOKEN" \
  -d '
  {
  "name": "target1",
  "host": "1.mybackendservice.com",
  "protocol": "http",
  "port": "80",
  "isEnabled": "true",
  }'
 

$TOKEN를 OAuth 2.0 액세스 토큰 가져오기에 설명된 대로 OAuth 2.0 액세스 토큰으로 설정합니다. 이 예시에서 사용된 curl 옵션에 대한 자세한 내용은 curl 사용을 참조하세요. 사용된 환경 변수에 대한 설명은 Apigee API 요청에 대한 환경 변수 설정을 참조하세요.

다음은 응답의 예시입니다.

{
  "host" : "1.mybackendservice.com",
  "protocol": "http",
  "isEnabled" : true,
  "name" : "target1",
  "port" : 80
}

다음 API 호출을 사용하여 두 번째 TargetServer를 만듭니다. 두 개의 TargetServer를 정의하여 TargetEndpoint가 부하 분산에 사용할 수 있는 두 개의 URL을 제공합니다.

curl "https://apigee.googleapis.com/v1/organizations/$ORG/environments/$ENV/targetservers" \
  -X POST \
  -H "Content-Type:application/json" \
  -H "Authorization: Bearer $TOKEN" \
  -d '
  {
  "name": "target2",
  "host": "2.mybackendservice.com",
  "protocol": "http",
  "port": "80",
  "isEnabled": "true",
  }'

다음은 응답의 예시입니다.

{
  "host" : "2.mybackendservice.com",
  "protocol": "http",
  "isEnabled" : true,
  "name" : "target2",
  "port" : 80
}

API를 사용하여 환경에서 TargetServer 나열

환경에 TargetServer를 나열하려면 다음 API 호출을 사용합니다.

curl https://apigee.googleapis.com/v1/organizations/$ORG/environments/$ENV/targetservers \
  -H "Authorization: Bearer $TOKEN"

다음은 응답의 예시입니다.

[ "target2", "target1" ]

이제 test 환경에 배포된 API 프록시에서 사용할 수 있는 TargetServer가 2개 존재합니다. 이러한 TargetServer 간에 트래픽 부하를 분산하려면 TargetServer를 사용하도록 API 프록시 대상 엔드포인트의 HTTP 연결을 구성합니다.

참고: 한도 주제에 설명된 것처럼 환경별로 1000개의 TargetServers 한도를 가집니다.

명명된 TargetServer에 부하를 분산하도록 TargetEndpoint 구성

이제 두 개의 TargetServer를 사용할 수 있으니 이 두 TargetServer를 이름으로 참조할 수 있도록 TargetEndpoint HTTP 연결 설정을 수정할 수 있습니다.

<TargetEndpoint name="default">
  <HTTPTargetConnection>
    <LoadBalancer>
      <Server name="target1" />
      <Server name="target2" />
    </LoadBalancer>
    <Path>/test</Path>
  </HTTPTargetConnection>
</TargetEndpoint>

참고: TargetServers를 호출하고 ServiceCallout 정책에서 부하 분산을 사용할 수도 있습니다. 자세한 내용은 ServiceCallout 정책을 참조하세요.

위 구성은 가장 기본적인 부하 분산 구성입니다. 부하 분산기는 3가지 부하 분산 알고리즘인 라운드 로빈, 가중치 적용, 최소 연결을 지원합니다. 라운드 로빈은 기본 알고리즘입니다. 위 구성에는 지정된 알고리즘이 없으므로 API 프록시에서 백엔드 서버로의 아웃바운드 요청이 target1와 target2 사이에 하나씩 폴백됩니다.

<Path> 요소는 모든 TargetServer에 대한 TargetEndpoint URI의 기본 경로를 형성합니다. <LoadBalancer>가 사용되는 경우에만 사용됩니다. 그렇지 않으면 무시됩니다. 위 예시에서는 target1에 도달하는 요청은 http://target1/test가 되고 다른 TargetServer에 대해서는 요청이 됩니다.

I/O 예외 및 HTTP 타임아웃에 의해 재시도가 트리거됩니다. 재시도는 HTTP 오류 코드(4xx ,5xx)에 의해 트리거되지 않습니다.

자세한 내용은 TargetEndpoint를 참조하세요.

부하 분산기 옵션 구성

다음 섹션에 설명된 대로 부하 분산기 및 TargetServer 수준에서 부하 분산 및 장애 조치 옵션을 구성하여 가용성을 조정할 수 있습니다.

알고리즘

<LoadBalancer>에서 사용하는 알고리즘을 설정합니다. 사용 가능한 알고리즘은 아래에 설명된 RoundRobin, Weighted, LeastConnections입니다.

라운드 로빈

기본 알고리즘인 라운드 로빈은 대상 HTTP 연결에 서버가 나열된 순서대로 요청을 각 TargetServer로 전달합니다. 예를 들면 다음과 같습니다.

<TargetEndpoint name="default">
  <HTTPTargetConnection>
      <LoadBalancer>
        <Algorithm>RoundRobin</Algorithm>
        <Server name="target1" />
        <Server name="target2" />
      </LoadBalancer>
      <Path>/test</Path>
  </HTTPTargetConnection>
</TargetEndpoint>

가중치 적용

가중치가 적용된 부하 분산 알고리즘을 사용 설정하여 TargetServer에 대한 비례 트래픽 부하를 구성할 수 있습니다. 가중치가 적용된 LoadBalancer는 각 TargetServer의 가중치에 비례하여 요청을 TargetServer에 직접 배포합니다. 따라서 가중치가 적용된 알고리즘을 사용하려면 각 TargetServer에 weight 속성을 설정해야 합니다. 예를 들면 다음과 같습니다.

<TargetEndpoint name="default">
  <HTTPTargetConnection>
    <LoadBalancer>
      <Algorithm>Weighted</Algorithm>
      <Server name="target1">
        <Weight>1</Weight>
      </Server>
      <Server name="target2">
        <Weight>2</Weight>
      </Server>
    </LoadBalancer>
    <Path>/test</Path>
  </HTTPTargetConnection>
</TargetEndpoint>

이 예시에서는 target1로 라우팅되는 요청 하나마다 요청 두 개가 target2로 라우팅됩니다.

최소 연결

최소 연결 알고리즘을 사용하도록 구성된 LoadBalancer는 열린 HTTP 연결이 가장 적은 TargetServer로 아웃바운드 요청을 라우팅합니다. 예를 들면 다음과 같습니다.

<TargetEndpoint name="default">
  <HTTPTargetConnection>
      <LoadBalancer>
        <Algorithm>LeastConnections</Algorithm>
        <Server name="target1" />
        <Server name="target2" />
      </LoadBalancer>
  </HTTPTargetConnection>
  <Path>/test</Path>
</TargetEndpoint>

최대 실패

API 프록시에서 TargetServer로의 요청이 실패하여 요청이 다른 TargetServer로 리디렉션된 최대 요청 수입니다.

응답이 실패하면 Apigee가 TargetServer에서 응답을 수신하지 않습니다. 이러한 경우 실패 카운터가 1회씩 증가합니다.

하지만 Apigee에서 대상의 응답을 수신하면 응답이 HTTP 오류(예: 500)이더라도 TargetServer의 응답으로 집계되고 실패 카운터는 재설정됩니다. 잘못된 HTTP 응답(예: 500)이 발생하는 경우 장애 카운터를 증분하여 가능한 한 빨리 비정상 서버가 부하 분산 순환에서 제외될 수 있도록 부하 분산기 구성에 <ResponseCode> 하위 요소와 함께 <ServerUnhealthyResponse> 요소를 추가할 수 있습니다. 또한 Apigee는 이러한 코드가 포함된 응답을 실패로 카운트합니다.

다음 예시에서는 target1이 TargetServer의 일부 5XX 응답이 포함된 요청 5개가 실패하면 순환에서 삭제됩니다.

<TargetEndpoint name="default">
  <HTTPTargetConnection>
      <LoadBalancer>
        <Algorithm>RoundRobin</Algorithm>
        <Server name="target1" />
        <Server name="target2" />
        <MaxFailures>5</MaxFailures>
        <ServerUnhealthyResponse>
            <ResponseCode>500</ResponseCode>
            <ResponseCode>502</ResponseCode>
            <ResponseCode>503</ResponseCode>
        </ServerUnhealthyResponse>
      </LoadBalancer>
      <Path>/test</Path>
  </HTTPTargetConnection>
</TargetEndpoint>

MaxFailures(최대 실패 횟수)의 기본값은 0입니다. 즉, 이 경우 Apigee는 항상 각 요청의 대상에 연결을 시도하며, 로테이션에서 TargetServer를 절대 삭제하지 않습니다.

HealthMonitor에는 0보다 큰 MaxFailures를 사용하는 것이 가장 좋습니다. MaxFailures를 0보다 크게 구성하는 경우 대상이 지정한 횟수만큼 실패하면 TargetServer가 순환에서 삭제됩니다. HealthMonitor가 배치되었을 때 Apigee는 HealthMonitor 구성에 따라 대상이 작동되어 다시 실행된 후 TargetServer를 다시 순환에 배치합니다. 자세한 내용은 상태 모니터링을 참조하세요.

또는 MaxFailures를 0보다 크게 구성하고 HealthMonitor를 구성하지 않으면 Apigee가 첫 번째 오류 감지 후 자동으로 TargetServer를 순환에서 제외합니다. Apigee는 5분마다 TargetServer의 상태를 점검하고 정상적으로 응답하면 순환에 다시 포함합니다.

재시도

재시도를 사용 설정하면 응답 실패(I/O 오류 또는 HTTP 시간 제한)가 발생하거나 수신되는 응답이 <ServerUnhealthyResponse>에서 설정한 값과 일치할 때마다 요청을 재시도합니다. <ServerUnhealthyResponse> 설정에 대한 자세한 내용은 위의 최대 실패 횟수를 참조하세요.

기본적으로 <RetryEnabled>는 true로 설정됩니다. 재시도를 사용 중지하려면 false로 설정하세요. 예를 들면 다음과 같습니다.

<RetryEnabled>false</RetryEnabled>

참고: 재시도가 작동하려면 대상 엔드포인트 구성에 최소 2개 이상의 TargetServer가 정의되어 있어야 합니다.

IsFallback

TargetServer 하나를(단 하나만) 대체 서버로 설정할 수 있습니다. 대체 TargetServer는 부하 분산기에서 사용할 수 없는 다른 모든 TargetServer를 식별할 때까지 부하 분산 루틴에 포함되지 않습니다. 부하 분산기가 모든 TargetServers를 사용할 수 없다고 확인하면 모든 트래픽이 대체 서버로 라우팅됩니다. 예를 들면 다음과 같습니다.

<TargetEndpoint name="default">
  <HTTPTargetConnection>
      <LoadBalancer>
        <Algorithm>RoundRobin</Algorithm>
        <Server name="target1" />
        <Server name="target2" />
        <Server name="target3">
          <IsFallback>true</IsFallback>
        </Server>
      </LoadBalancer>
      <Path>/test</Path>
  </HTTPTargetConnection>
</TargetEndpoint>

위 구성에서는 target1과 target2를 모두 사용할 수 없을 때까지 target1과 target2 간에 라운드 로빈 부하 분산이 발생합니다. target1 및 target2를 사용할 수 없으면 모든 트래픽이 target3으로 라우팅됩니다.

경로

경로는 TargetServer가 백엔드 서버에 실행한 모든 요청에 추가될 URI 프래그먼트를 정의합니다.

이 요소는 리터럴 문자열 경로 또는 메시지 템플릿을 허용합니다. 메시지 템플릿을 사용하면 런타임에 변수 문자열 대체를 수행할 수 있습니다. 예를 들어 다음 대상 엔드포인트 정의에서 {mypath} 값이 경로에 사용됩니다.

<HTTPTargetConnection>
    <SSLInfo>
      <Enabled>true</Enabled>
    </SSLInfo>
    <LoadBalancer>
      <Server name="testserver"/>
    </LoadBalancer>
    <Path>{mypath}</Path>
</HTTPTargetConnection>

TLS/SSL의 TargetServer 구성

TargetServer를 사용하여 백엔드 서비스를 정의할 때 백엔드 서비스에서 HTTPS 프로토콜을 사용하려면 연결이 필요한 경우, TargetServer 정의에서 TLS/SSL을 사용 설정해야 합니다. 이는 host 태그로는 연결 프로토콜을 지정할 수 없기 때문에 필요합니다. 아래는 Apigee에서 백엔드 서비스에 HTTPS를 요청하는 단방향 TLS/SSL의 TargetServer 정의를 보여줍니다.

{
  "name": "target1",
  "host": "mocktarget.apigee.net",
  "protocol": "http",
  "port": "443",
  "isEnabled": "true",
  "sSLInfo": {
    "enabled": "true"
  }
}

참고: TargetEndpoint와 TargetServer 정의 모두에서 sSLInfo 블록을 정의하는 경우 TargetServer의 블록이 우선 적용됩니다.

백엔드 서비스에 양방향 또는 상호 TLS/SSL을 요구하는 경우, TargetEndpoints와 동일한 TLS/SSL 구성 설정을 사용하여 TargetServer를 구성하세요.

{
  "name": "TargetServer 1",
  "host": "www.example.com",
  "protocol": "http",
  "port": "443",
  "isEnabled": "true",
  "sSLInfo": {
    "enabled": "true",
    "clientAuthEnabled": "true",
    "keyStore": "keystore-name",
    "keyAlias": "keystore-alias",
    "trustStore": "truststore-name",
    "ignoreValidationErrors": "false",
    "ciphers": []
  }
}

API 호출을 사용하여 SSL로 TargetServer를 만들려면 다음을 실행합니다.

curl "https://apigee.googleapis.com/v1/organizations/$ORG/environments/$ENV/targetservers" \
  -X POST \
  -H "Content-Type:application/json"  \
  -H "Authorization: Bearer $TOKEN" \
  -d '
  {
    "name": "TargetServer 1",
    "host": "www.example.com",
    "protocol": "http",
    "port": 443,
    "isEnabled": true,
    "sSLInfo":
    {
      "enabled":true,
      "clientAuthEnabled":true,
      "keyStore":"keystore-name",
      "keyAlias":"keystore-alias",
      "ciphers":[],
      "protocols":[],
      "clientAuthEnabled":true,
      "ignoreValidationErrors":false,
      "trustStore":"truststore-name"
    }
  }'

상태 모니터링

상태 모니터링을 사용 설정하면 TargetServer 구성에 정의된 백엔드 서비스 URL을 적극적으로 폴링하여 부하 분산 구성을 향상시킬 수 있습니다. 상태 모니터링을 사용 설정하면 연결할 수 없거나 오류 응답을 반환하는 TargetServer가 비정상으로 표시됩니다. 실패한 TargetServer는 HealthMonitor에서 TargetServer가 활성 상태임을 확인하면 자동으로 로테이션에 복귀됩니다. 프록시 재배포는 필요하지 않습니다.

HealthMonitor를 사용할 때 <MaxFailures>를 0 이상으로 설정해야 합니다. <MaxFailures> 값이 0이면 Apigee에서 항상 각 요청의 대상에 연결을 시도하며 로테이션에서 TargetServer를 절대 삭제하지 않습니다.

HealthMonitor는 TCP 또는 HTTP를 통해 백엔드 서비스를 호출하는 간단한 클라이언트 역할을 수행합니다.

• TCP 클라이언트는 단순히 소켓을 열 수 있는지 여부만 확인합니다.
• 백엔드 서비스에 유효한 HTTP 요청을 제출하도록 HTTP 클라이언트를 구성합니다. HTTP GET, PUT, POST 또는 DELETE 작업을 정의할 수 있습니다. HTTP 모니터 호출 응답은 <SuccessResponse> 블록에 구성된 설정과 일치해야 합니다.

성공 및 실패

상태 모니터링을 사용 설정하면 Apigee가 대상 서버에 상태 확인을 전송하기 시작합니다. 상태 확인은 TargetServer가 정상인지 여부를 확인하기 위해 TargetServer에 전송되는 요청입니다.

상태 확인 결과는 두 가지 중 하나일 수 있습니다.

• 성공: 상태 확인에 성공하면 TargetServer가 정상으로 간주됩니다. 이는 일반적으로 다음 중 하나 이상에 따른 결과입니다.
  • TargetServer가 지정된 포트에 대한 새 연결을 수락하고 해당 포트의 요청에 응답한 다음 지정된 기간 내에 포트를 닫습니다. TargetServer의 응답에 Connection: close가 포함됩니다.
  • TargetServer가 200 (OK) 또는 다른 HTTP 상태 코드가 허용되는 상태 확인 요청에 응답합니다.
  • TargetServer가 예상 메시지 본문에 일치하는 메시지 본문으로 상태 확인 요청에 응답합니다.

  Apigee에서 서버가 정상임을 확인하면 Apigee는 서버에 계속해서 전송을 요청하거나 재개합니다.

• 실패: TargetServer는 확인 유형에 따라 다양한 방법으로 상태 확인에 실패할 수 있습니다. TargetServer 다음에 해당하면 오류가 로깅될 수 있습니다.
  • Apigee에서 상태 확인 포트로의 연결을 거부
  • 지정된 기간 내에 상태 확인 요청에 응답하지 않음
  • 예상치 못한 HTTP 상태 코드를 반환
  • 예상 메시지 본문과 일치하지 않는 메일 본문으로 응답함

  TargetServer가 상태 확인에 실패하면 Apigee가 해당 서버의 실패 횟수를 증분합니다. 해당 서버에 대한 실패 횟수가 사전 정의된 임계값(<MaxFailures>)에 도달하거나 초과하면 Apigee가 해당 서버에 대한 요청 전송을 중지합니다.

HealthMonitor 사용 설정

HealthMonitor를 만들려면 프록시에 대한 TargetEndpoint의 HTTPConnection 구성에 <HealthMonitor> 요소를 추가합니다. UI에서는 이 작업을 수행할 수 없습니다. 대신 프록시 구성을 만들고 ZIP 파일로 Apigee에 업로드합니다. 프록시 구성은 API 프록시의 모든 측면에 대한 구조화된 설명입니다. 프록시 구성은 사전 정의된 디렉터리 구조의 XML 파일로 구성됩니다. 자세한 내용은 API 프록시 구성 참조를 확인하세요.

참고: HealthMonitor는 프록시별로 구성해야 합니다. 동일한 TargetServer를 호출하는 프록시가 여러 개인 경우 프록시마다 HealthMonitor를 구성해야 합니다.

간단한 HealthMonitor는 TCPMonitor 또는 HTTPMonitor와 결합한 IntervalInSec를 정의합니다. <MaxFailures> 요소는 API 프록시에서 TargetServer로의 최대 실패 요청 수를 지정하여 요청이 다른 TargetServer로 리디렉션되게 합니다. <MaxFailures>의 기본값은 0이며 이 경우 Apigee는 수정 작업을 수행하지 않습니다. Health Monitor를 구성할 때는 <TargetEndpoint> 태그의 <HTTPTargetConnection> 태그에서 <MaxFailures>를 0이 아닌 값으로 설정하세요.

TCPMonitor

아래 구성은 포트 80에서 5초에 한 번씩 연결을 열어 각 TargetServer를 폴링하는 HealthMonitor를 정의합니다. (포트는 선택사항입니다. 지정되지 않으면 TCPMonitor 포트는 TargetServer 포트입니다.)

• 연결에 실패하거나 연결하는 데 10초 이상 걸리면 해당 TargetServer에 대해 실패 횟수가 1씩 증가합니다.
• 연결에 성공하면 TargetServer의 실패 횟수가 0으로 재설정됩니다.

아래와 같이 HealthMonitor를 TargetEndpoint의 HTTPTargetConnetion 요소에 대한 하위 요소로 추가할 수 있습니다.

<TargetEndpoint name="default">
  <HTTPTargetConnection>
      <LoadBalancer>
        <Algorithm>RoundRobin</Algorithm>
        <Server name="target1" />
        <Server name="target2" />
        <MaxFailures>5</MaxFailures>
      </LoadBalancer>
      <Path>/test</Path>
      <HealthMonitor>
        <IsEnabled>true</IsEnabled>
        <IntervalInSec>5</IntervalInSec>
        <TCPMonitor>
            <ConnectTimeoutInSec>10</ConnectTimeoutInSec>
            <Port>80</Port>
        </TCPMonitor>
      </HealthMonitor>
  </HTTPTargetConnection>
</TargetEndpoint>

TCPMonitor 구성 요소를 사용하는 HealthMonitor

다음 표에서는 TCPMonitor 구성 요소를 설명합니다.

이름	설명	기본값	필수 여부
IsEnabled	HealthMonitor를 사용 설정하거나 중지하는 부울 값입니다.	false	아니요
IntervalInSec	각 폴링 TCP 요청 사이의 시간 간격(초)입니다.	0	예
ConnectTimeoutInSec	성공으로 간주되려면 TCP 포트 연결이 설정되어야 하는 시간입니다. 지정된 간격에 연결하지 못하면 실패로 간주되고 TargetServer의 부하 분산기 실패 횟수가 증가합니다.	0	예
Port	선택사항. TCP 연결이 이루어지는 포트입니다. 지정되지 않으면 TCPMonitor 포트는 TargetServer 포트입니다.	0	아니요

HTTPMonitor

HTTPMonitor를 사용하는 샘플 HealthMonitor는 5초마다 한 번씩 GET 요청을 백엔드 서비스에 제출합니다. 아래 샘플에서는 HTTP 기본 승인 헤더를 요청 메시지에 추가합니다. 응답 구성은 백엔드 서비스의 실제 응답과 비교할 설정을 정의합니다. 다음 예시에서 예상 응답은 HTTP 응답 코드 200 및 값이 YourOK인 커스텀 HTTP 헤더 ImOK입니다. 응답이 일치하지 않으면 요청이 부하 분산기 구성에 의해 실패로 간주됩니다.

HTTPMonitor는 HTTP 및 편도 HTTPS 프로토콜을 사용하도록 구성된 백엔드 서비스를 지원합니다. 그러나 양방향 TLS/SSL 또는 자체 서명 인증서라고도 하는 양방향 HTTPS는 지원하지 않습니다.

HTTP 모니터의 모든 요청 및 응답 설정은 호출해야 하는 백엔드 서비스에만 적용됩니다.

    <TargetEndpoint name="default">
      <HTTPTargetConnection>
        <LoadBalancer>
          <Algorithm>RoundRobin</Algorithm>
          <Server name="target1" />
          <Server name="target2" />
          <MaxFailures>5</MaxFailures>
        </LoadBalancer>
        <Path>/test</Path>
        <HealthMonitor>
          <IsEnabled>true</IsEnabled>
          <IntervalInSec>5</IntervalInSec>
          <HTTPMonitor>
            <Request>
              <ConnectTimeoutInSec>10</ConnectTimeoutInSec>
              <SocketReadTimeoutInSec>30</SocketReadTimeoutInSec>
              <Port>80</Port>
              <Verb>GET</Verb>
              <Path>/healthcheck</Path>
              <Header name="Authorization">Basic 12e98yfw87etf</Header>
              <IncludeHealthCheckIdHeader>true</IncludeHealthCheckIdHeader>
            </Request>
            <SuccessResponse>
              <ResponseCode>200</ResponseCode>
              <Header name="ImOK">YourOK</Header>
            </SuccessResponse>
          </HTTPMonitor>
        </HealthMonitor>
      </HTTPTargetConnection>
    </TargetEndpoint>
  

<HTTPMonitor> 구성 요소

다음 표에서는 최상위 <HTTPMonitor> 구성 요소를 설명합니다.

이름	설명	기본값	필수 여부
IsEnabled	HealthMonitor를 사용 설정하거나 중지하는 부울 값입니다.	false	아니요
IntervalInSec	각 폴링 요청 사이의 시간 간격(초)입니다.	0	예

<HTTPMonitor>/<Request> 구성 요소

HealthMonitor에서 순환되는 TargetServer에 전송되는 아웃바운드 요청 메시지의 구성 옵션입니다. <Request>는 필수 요소입니다.

이름	설명	기본값	필수 여부
ConnectTimeoutInSec	HTTP 서비스로의 TCP 연결 핸드셰이크가 성공으로 간주되려면 완료해야 하는 시간(초)입니다. 지정된 간격에 연결하지 못하면 실패로 간주되고 TargetServer의 LoadBalancer 실패 횟수가 증가합니다.	0	아니요
SocketReadTimeoutInSec	성공으로 간주되려면 HTTP 서비스에서 데이터를 읽어야 하는 시간(초)입니다. 지정된 간격에 읽지 못하면 장애가 발생하여 TargetServer에 대한 LoadBalancer의 실패 횟수가 증가합니다.	0	아니요
Port	백엔드 서비스에 대한 HTTP 연결이 설정될 포트입니다.	대상 서버 포트	No
Verb	백엔드 서비스에 대한 각 HTTP 요청 폴링에 사용되는 HTTP 동사입니다.	해당 사항 없음	아니요
Path	TargetServer에 정의된 URL에 추가되는 경로입니다. Path 요소를 사용하여 HTTP 서비스에서 '폴링 엔드포인트'를 구성합니다. Path 요소는 변수를 지원하지 않습니다.	해당 사항 없음	아니요
IncludeHealthCheckIdHeader	업스트림 시스템에서 상태 확인 요청을 추적할 수 있습니다. IncludeHealthCheckIdHeader는 부울 값을 사용하며 기본값은 false입니다. 이를 true로 설정하면 상태 확인 요청에 삽입되는 X-Apigee-Healthcheck-Id라는 Header가 있습니다. 헤더 값은 동적으로 할당되며 ORG/ENV/SERVER_UUID/N 형식을 사용합니다. 여기서 ORG은 조직 이름이고 ENV는 환경 이름이고 SERVER_UUID는 MP를 식별하는 고유 ID이며 N은 1970년 1월 1일 이후 경과된 밀리초 수입니다. 결과 요청 헤더의 예시는 다음과 같습니다. X-Apigee-Healthcheck-Id: orgname/envname/E8C4D2EE-3A69-428A-8616-030ABDE864E0/1586802968123	false	아니요
Payload	각 폴링 HTTP 요청에 대해 생성되는 HTTP 본문입니다. GET 요청에는 이 요소가 필요하지 않습니다.	해당 없음	No

<HTTPMonitor>/<SuccessResponse> 구성 요소

(선택사항) 폴링된 백엔드 서비스에서 생성한 인바운드 HTTP 응답 메시지의 일치 옵션입니다. 응답이 일치하지 않으면 실패 횟수가 1씩 증가합니다.

이름	설명	기본값	필수 여부
ResponseCode	폴링된 TargetServer에서 수신될 HTTP 응답 코드입니다. 지정된 코드와 다른 코드를 사용하면 실패하고 폴링된 백엔드 서비스의 수가 증가합니다. 여러 ResponseCode 요소를 정의할 수 있습니다.	해당 없음	아니요
Headers	폴링된 백엔드 서비스에서 수신될 수 있는 하나 이상의 HTTP 헤더 및 값의 목록입니다. 응답의 HTTP 헤더 또는 값이 특정 결과와 다른 경우에 실패하고 폴링된 TargetServer의 수가 1씩 증가합니다. 여러 헤더 요소를 정의할 수 있습니다.	해당 없음	아니요