백엔드 서버 간 부하 분산

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

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

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

동영상

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

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

대상 서버 구성 정보

대상 서버 구성은 이름, 호스트, 프로토콜, 포트로 이루어지며, 대상 서버의 사용 설정 또는 사용 중지 여부를 나타내는 추가 요소도 포함됩니다. 대상 서버에 선택적인 <sSLInfo> 객체가 있을 수도 있습니다.

다음 코드는 대상 서버 구성의 예시입니다.

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

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

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

대상 서버 만들기

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

Cloud 콘솔의 Apigee

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

Cloud 콘솔에서 Apigee UI에 로그인합니다.
관리 > 환경을 선택합니다.
새 대상 서버를 정의할 환경을 선택합니다.
창 상단에서 대상 서버를 클릭합니다.
+ 대상 서버 만들기를 클릭합니다.
제공된 필드에 이름, 호스트, 프로토콜, 포트를 입력합니다. 프로토콜 옵션은 REST 기반 대상 서버의 경우 HTTP이고, gRPC 기반 대상 서버의 경우 gRPC - 대상 또는 gRPC - 외부 콜아웃입니다. gRPC 프록시 지원에 대한 자세한 내용은 gRPC API 프록시 만들기를 참조하세요.
필요한 경우 SSL 사용 설정을 선택할 수 있습니다. SSL 인증서 개요를 참조하세요.
만들기를 클릭합니다.

기본 Apigee

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

Apigee UI에 로그인합니다.
관리자 > 환경 > TargetServers를 선택합니다.
환경 드롭다운 목록에서 새 대상 서버를 정의할 환경을 선택합니다.
Apigee UI에서 선택한 환경의 최신 대상 서버 목록을 표시합니다.
+대상 서버를 클릭하여 선택한 환경에 새 대상 서버를 추가합니다.
대상 서버 추가 대화상자가 표시됩니다.
사용 설정됨을 클릭하여 새 대상 서버를 사용 설정합니다. 생성한 직후에 정의가 적용되게 하세요.
제공된 필드에 이름, 호스트, 프로토콜, 포트를 입력합니다. 프로토콜 옵션은 HTTP 또는 GRPC입니다.

필요한 경우 SSL 체크박스를 선택할 수 있습니다. 필드에 대한 자세한 내용은 TargetServers(4MV4D 동영상)를 참조하세요.
추가를 클릭합니다.
Apigee가 새로운 대상 서버 정의를 생성합니다.
새 대상 서버를 만든 후 API 프록시를 수정하고 <HTTPTargetConnection> 요소를 변경하여 새 정의를 참조할 수 있습니다.

Apigee API

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

API를 사용하여 환경에서 대상 서버 만들기
API를 사용하여 환경에서 대상 서버 나열

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

API를 사용하여 환경에서 대상 서버 만들기

포트 80에서 1.mybackendservice.com에 연결되는 target1이라는 대상 서버를 만들려면 다음 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 호출을 사용하여 두 번째 대상 서버를 만듭니다. 두 개의 대상 서버를 정의하여 대상 엔드포인트가 부하 분산에 사용할 수 있는 두 개의 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를 사용하여 환경에서 대상 서버 나열

환경의 대상 서버를 나열하려면 다음 API 호출을 사용합니다.

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

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

[ "target2", "target1" ]

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

이름이 지정된 대상 서버에 부하를 분산하도록 대상 엔드포인트 구성

이제 두 개의 대상 서버를 사용할 수 있으므로 대상 엔드포인트의 <HTTPTargetConnection> 요소를 수정하여 두 대상 서버를 이름으로 참조할 수 있습니다.

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

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

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

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

부하 분산기 옵션 구성

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

알고리즘

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

라운드 로빈

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

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

가중치가 적용된

가중치가 적용된 부하 분산 알고리즘을 사용 설정하여 대상 서버에 대한 비례 트래픽 부하를 구성할 수 있습니다. 가중치가 적용된 LoadBalancer는 각 대상 서버의 가중치에 정비례하도록 요청을 대상 서버에 분산합니다. 따라서 가중치가 적용된 알고리즘을 사용하려면 각 대상 서버에 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 연결이 가장 적은 대상 서버로 아웃바운드 요청을 라우팅합니다. 예를 들면 다음과 같습니다.

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

최대 실패

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

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

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

다음 예시에서는 대상 서버의 404 및 일부 5XX 응답이 포함된 요청 5개가 실패한 후에 target1이 순환에서 삭제됩니다.

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

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

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

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

재시도

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

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

<RetryEnabled>false</RetryEnabled>

IsFallback

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

<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으로 라우팅됩니다.

대체 서버가 비정상이면 Apigee에서 트래픽을 서버로 라우팅하지 않습니다. 대신 API 호출에서 503 '서비스를 일시적으로 사용할 수 없음' 오류를 반환합니다.

경로

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

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

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

TLS/SSL의 대상 서버 구성

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

참고: 대상 엔드포인트와 대상 서버 정의 모두에서 sSLInfo 블록을 정의하는 경우 대상 서버의 블록이 우선 적용됩니다.

단방향 TLS/SSL 구성

다음 구성을 사용하여 단방향 TLS/SSL로 대상 서버를 정의합니다. 이 예시에서는 Apigee가 백엔드 서비스에 대해 HTTPS 요청을 수행합니다.

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

엄격한 SSL 시행 구성

대상 서버 정의에 엄격한 SSL 시행을 지정하려면 다음 예시와 같이 sSLInfo 블록에서 enforce를 true로 설정합니다.

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

양방향 TLS/SSL 구성

백엔드 서비스에 양방향 또는 상호 TLS/SSL이 필요한 경우 대상 엔드포인트와 동일한 TLS/SSL 구성 설정으로 대상 서버를 구성하면 됩니다.

{
  "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 구성

API 호출을 사용하여 엄격한 SSL 시행으로 대상 서버를 만들려면 다음을 사용합니다.

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,
      "enforce":true,
      "clientAuthEnabled":true,
      "keyStore":"keystore-name",
      "keyAlias":"keystore-alias",
      "ciphers":[],
      "protocols":[],
      "clientAuthEnabled":true,
      "ignoreValidationErrors":false,
      "trustStore":"truststore-name"
    }
  }'

상태 모니터링

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

상태 모니터를 사용할 때 <MaxFailures>를 0 이상으로 설정해야 합니다. <MaxFailures> 값이 0으로 설정되면 Apigee는 항상 각 요청의 대상에 대한 연결을 시도하고 순환에서 대상 서버를 삭제하지 않습니다.

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

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

성공 및 실패

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

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

성공: 상태 점검에 성공하면 대상 서버가 정상으로 간주됩니다. 이는 일반적으로 다음 중 하나 이상에 따른 결과입니다.
- 대상 서버는 지정된 포트에 대한 새 연결을 수락하고 해당 포트의 요청에 응답한 다음 지정된 기간 내에 포트를 닫습니다. 대상 서버의 응답에 Connection: close가 포함됩니다.
- 대상 서버가 200 (OK) 또는 사용자가 허용한 다른 HTTP 상태 코드로 상태 점검 요청에 응답합니다.
- 대상 서버가 예상 메시지 본문과 일치하는 메시지 본문으로 상태 점검 요청에 응답합니다.
Apigee에서 서버가 정상임을 확인하면 Apigee는 서버에 계속해서 전송을 요청하거나 재개합니다.
실패: 점검 유형에 따라 다양한 방식으로 대상 서버가 상태 점검에 실패할 수 있습니다. 대상 서버가 다음에 해당하면 오류가 로깅될 수 있습니다.
- Apigee에서 상태 확인 포트로의 연결을 거부
- 지정된 기간 내에 상태 확인 요청에 응답하지 않음
- 예상치 못한 HTTP 상태 코드를 반환
- 예상 메시지 본문과 일치하지 않는 메일 본문으로 응답함
대상 서버가 상태 점검에 실패하면 Apigee가 해당 서버의 실패 횟수를 증분합니다. 해당 서버에 대한 실패 횟수가 사전 정의된 임계값(<MaxFailures>)에 도달하거나 초과하면 Apigee가 해당 서버에 대한 요청 전송을 중지합니다.

상태 모니터 사용 설정

API 프록시의 상태 모니터를 만들려면 프록시에 대한 대상 엔드포인트의 <HTTPTargetConnection 요소 구성에 <HealthMonitor> 요소를 추가합니다.

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

`<HealthMonitor>` 구성 요소

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

이름	설명	기본값	필수 여부
`IsEnabled`	상태 모니터를 사용 설정하거나 중지하는 불리언 값입니다.	false	No
`IntervalInSec`	각 폴링 TCP 또는 HTTP 요청 사이의 시간 간격(초)입니다.	0	예
`HTTPMonitor` 또는 `TCPMonitor`	대상 서버를 폴링하는 데 사용할 TCP 또는 HTTP 클라이언트의 정의입니다.	해당 사항 없음	예

이러한 요소 외에도 상태 모니터를 사용 설정하려면 <TargetEndpoint> 요소의 <HTTPTargetConnection> 블록에 있는 <MaxFailures> 요소를 0보다 큰 값으로 설정해야 합니다. <MaxFailures>는 요청이 다른 대상 서버로 리디렉션되기 전에 발생할 수 있는 API 프록시에서 대상 서버로의 실패한 최대 요청 수를 지정하는 데 사용됩니다.

<MaxFailures>의 기본값은 0이며 이 경우 Apigee는 수정 작업을 수행하지 않습니다. 상태 모니터를 구성할 때는 <MaxFailures>를 0이 아닌 값으로 설정해야 합니다.

TCP 모니터를 사용한 상태 모니터

다음 구성에 설명된 샘플 상태 모니터는 TCP 모니터를 사용하여 5초마다 포트 80에서 연결을 열어 각 대상 서버를 폴링합니다. (포트는 선택사항입니다. 지정되지 않으면 TCP 모니터 포트는 대상 서버 포트입니다.

이 샘플 상태 모니터 구성은 다음과 같습니다.

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

아래와 같이 상태 모니터를 대상 엔드포인트 <HTTPTargetConnection> 요소의 하위 요소로 추가할 수 있습니다.

<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>` 구성 요소

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

이름	설명	기본값	필수 여부
`ConnectTimeoutInSec`	성공으로 간주되려면 TCP 포트 연결이 설정되어야 하는 시간입니다. 지정된 간격에 연결하지 못하면 실패로 집계되고 대상 서버의 부하 분산기 실패 횟수가 증가합니다.	0	예
`Port`	선택사항. TCP 연결이 이루어지는 포트입니다. 지정되지 않으면 TCP 모니터 포트는 대상 서버 포트입니다.	0	No

HTTP 모니터를 사용한 상태 모니터

다음 구성에서 설명하는 샘플 상태 모니터는 5초마다 한 번씩 GET 요청을 백엔드 서비스에 제출하고 HTTP 기본 승인 헤더를 요청 메시지에 추가하는 HTTP 모니터를 사용합니다.

이 샘플 상태 모니터 구성은 다음과 같습니다.

백엔드 서비스의 예상 응답은 HTTP 응답 코드 200입니다.
커스텀 HTTP 기본 승인 헤더 ImOK의 예상 값은 YourOK입니다.
대상 서버의 <SSLInfo> 블록에 있는 SSL 매개변수를 사용하도록 <UseTargetServerSSLInfo> 요소가 true로 설정됩니다.

이 구성을 사용하면 예상 응답 코드와 헤더 값이 백엔드 서비스의 실제 응답과 비교됩니다. 응답이 일치하지 않으면 요청이 부하 분산기 구성에 의해 실패로 간주됩니다.

기본적으로, 상태 모니터는 대상 서버에서 키 저장소, 트러스트 저장소 또는 기타 SSL 매개변수에 액세스할 수 없습니다. 상호 TLS를 지원하기 위해 상태 모니터에서 이러한 매개변수에 대한 액세스를 사용 설정하려면 예를 들어 <Request> 블록에 <UseTargetServerSSLInfo>true</UseTargetServerSSLInfo>를 추가합니다.

    <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>
              <UseTargetServerSSLInfo>true</UseTargetServerSSLInfo>
              <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> 구성 요소를 설명합니다.

이름	설명	기본값	필수 여부
`Request`	상태 모니터에서 순환 중인 대상 서버로 전송하는 아웃바운드 요청 메시지입니다.	해당 사항 없음	예
`SuccessResponse`	(선택사항) 폴링된 백엔드 서비스에서 생성한 인바운드 HTTP 응답 메시지의 일치 옵션입니다.	해당 사항 없음	No

<HTTPMonitor>/<Request> 구성 요소

상태 모니터에서 순환 중인 대상 서버에 전송되는 아웃바운드 요청 메시지의 구성 옵션입니다. <Request>는 필수 요소입니다.

이름	설명	기본값	필수 여부
`ConnectTimeoutInSec`	HTTP 서비스로의 TCP 연결 핸드셰이크가 성공으로 간주되려면 완료해야 하는 시간(초)입니다. 지정된 간격에 연결하지 못하면 실패로 집계되고 대상 서버의 LoadBalancer 실패 횟수가 증가합니다. 참고: 지정된 값이 0이면 Apigee에서 기본 제한 시간 30초를 사용합니다.	0	아니요
`SocketReadTimeoutInSec`	성공으로 간주되려면 HTTP 서비스에서 데이터를 읽어야 하는 시간(초)입니다. 지정된 간격에 읽지 못하면 실패로 집계되고 대상 서버에 대한 LoadBalancer의 실패 횟수가 증가합니다. 참고: 지정된 값이 0이면 Apigee에서 기본 제한 시간 30초를 사용합니다.	0	아니요
`Port`	백엔드 서비스에 대한 HTTP 연결이 설정될 포트입니다.	대상 서버 포트	No
`Verb`	백엔드 서비스에 대한 각 HTTP 요청 폴링에 사용되는 HTTP 동사입니다.	해당 사항 없음	No
`Path`	대상 서버에 정의된 URL에 추가되는 경로입니다. `Path` 요소를 사용하여 HTTP 서비스에서 '폴링 엔드포인트'를 구성합니다. `Path` 요소는 변수를 지원하지 않습니다.	해당 사항 없음	No
`UseTargetServerSSLInfo`	`UseTargetServerSSLInfo`가 true이면 대상 서버에 대한 상태 모니터 요청이 대상 서버의 SSLInfo('sSLInfo') 블록에 있는 SSL 매개변수를 사용합니다. 그 밖의 경우에는 상태 모니터에서 프로토콜, 키 저장소, 트러스트 저장소 등의 SSL 매개변수를 사용할 수 없습니다.	false	No
`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
`Header`	폴링된 백엔드 서비스에서 수신될 수 있는 하나 이상의 HTTP 헤더 및 값입니다. 응답의 HTTP 헤더 또는 값이 지정된 것과 다른 경우에 실패하고 폴링된 대상 서버의 수가 1씩 증가합니다. 여러 헤더 요소를 정의할 수 있습니다.	해당 없음	No
`IsSSL`	true인 경우 HTTPS를 사용하여 상태 모니터 요청이 전송되도록 지정합니다.	거짓	No
`TrustAllSSL`	HTTP 모니터 검사에서 모든 SSL 인증서를 자동으로 신뢰할지 여부를 지정합니다.	거짓	No

<HTTPMonitor>/<SuccessResponse> 구성 요소

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

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

백엔드 서버 간 부하 분산

동영상

대상 서버 구성 정보

대상 서버 만들기

Cloud 콘솔의 Apigee

기본 Apigee

Apigee API

API를 사용하여 환경에서 대상 서버 만들기

API를 사용하여 환경에서 대상 서버 나열

이름이 지정된 대상 서버에 부하를 분산하도록 대상 엔드포인트 구성

부하 분산기 옵션 구성

알고리즘

라운드 로빈

가중치가 적용된

최소 연결

최대 실패

재시도

IsFallback

경로

TLS/SSL의 대상 서버 구성

단방향 TLS/SSL 구성

엄격한 SSL 시행 구성

양방향 TLS/SSL 구성

API를 사용하여 엄격한 SSL 구성

상태 모니터링

성공 및 실패

상태 모니터 사용 설정

<HealthMonitor> 구성 요소

TCP 모니터를 사용한 상태 모니터

<TCPMonitor> 구성 요소

HTTP 모니터를 사용한 상태 모니터

<HTTPMonitor> 구성 요소

<HTTPMonitor>/<Request> 구성 요소

<HTTPMonitor>/<SuccessResponse> 구성 요소

`<HealthMonitor>` 구성 요소

`<TCPMonitor>` 구성 요소

`<HTTPMonitor>` 구성 요소