백엔드 서버 간 부하 분산

현재 Apigee Edge 문서가 표시되고 있습니다.
Apigee X 문서로 이동
정보

Apigee Edge는 여러 백엔드 서버 인스턴스의 부하 분산 및 장애 조치를 기본으로 지원하여 API의 가용성을 향상시킵니다.

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

TargetServer 정의는 이름, 호스트, 포트와 TargetServer의 사용 설정 여부를 나타내는 추가 요소로 구성됩니다.

동영상

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

동영상 설명
대상 서버를 이용한 부하 분산 대상 서버 전반에서 API 부하 분산
대상 서버 사용 환경에 기반한 API 라우팅 환경에 따라 다른 대상 서버로 API 라우팅
대상 서버를 사용한 API 라우팅 및 부하 분산 (Classic Edge) 환경에 따라 API를 다른 대상 서버로 라우팅하고 기본 Edge UI에서 대상 서버 간에 API 부하를 분산합니다.

샘플 대상 서버 구성

다음 코드는 대상 서버를 정의합니다.

<TargetServer  name="target1">
  <Host>1.mybackendservice.com</Host>
  <Port>80</Port>
  <IsEnabled>true</IsEnabled>
</TargetServer >

대상 서버 구성 요소

다음 표에서는 TargetServer를 만들고 구성하는 데 사용되는 요소를 설명합니다.

이름 설명 기본 계정 필수 여부
name TargetServer 구성의 이름으로, 환경 내에서 고유해야 합니다. TargetServer 이름에는 영숫자 문자만 포함할 수 있습니다. 해당 사항 없음 지원됨
Host

백엔드 서비스의 호스트 URL (프로토콜 제외)입니다.

해당 사항 없음 지원됨
Port 백엔드 서비스가 수신 대기하는 포트 해당 사항 없음 지원됨
IsEnabled TargetServer 구성의 사용 설정 또는 사용 중지 여부를 나타내는 부울입니다. 이렇게 하면 API 프록시 구성을 수정하지 않고 TargetServer를 순환에서 제외할 수 있습니다. 일반적인 용도는 예상 용량 요구사항, 유지보수 일정 등에 따라 TargetServer를 자동으로 사용 설정 또는 사용 중지하는 앱 또는 스크립트를 작성하는 것입니다. true 지원됨

UI를 사용하여 대상 서버 관리

아래에 설명된 대로 대상 서버를 관리합니다.

에지

Edge UI를 사용하여 대상 서버를 관리하려면 다음 안내를 따르세요.

  1. apigee.com/edge에 로그인합니다.
  2. 왼쪽 탐색 메뉴에서 관리자 > 환경 > 대상 서버를 선택합니다.
  3. test 또는 prod와 같이 원하는 환경을 선택합니다.
  4. 대상 서버를 만들려면 다음 안내를 따르세요.
    1. + 대상 서버를 클릭합니다.
    2. 대상 서버의 이름, 호스트, 포트를 입력합니다.

      예를 들면 다음과 같습니다.

      • 이름: target1
      • 호스트: 1.mybackendservice.com
      • 포트: 80
    3. 필요한 경우 SSL을 선택합니다.
    4. 사용 설정됨을 선택하여 대상 서버를 사용 설정합니다.
    5. Add를 클릭합니다.
  5. 대상 서버를 수정하려면 다음 안내를 따르세요.
    1. 수정하려는 대상 서버 위에 커서를 올려놓으면 작업 메뉴가 표시됩니다.
    2. 아이콘을 클릭합니다.
    3. targer 서버 값을 수정합니다.
    4. Update를 클릭합니다.
  6. 대상 서버를 삭제하려면 다음 안내를 따르세요.
    1. 삭제할 대상 서버 위에 커서를 올려 놓으면 작업 메뉴가 표시됩니다.
    2. 아이콘을 클릭합니다.
    3. 삭제를 클릭하여 작업을 확인합니다.

Classic Edge (Private Cloud)

기본 Edge UI를 사용하여 프록시 만들기 마법사에 액세스하려면 다음 안내를 따르세요.

  1. http://ms-ip:9000에 로그인합니다. 여기서 ms-ip는 관리 서버 노드의 IP 주소 또는 DNS 이름입니다.
  2. 왼쪽 탐색 메뉴에서 API > 환경 구성 > 대상 서버를 선택합니다.
  3. test 또는 prod와 같이 원하는 환경을 선택합니다.
  4. 대상 서버를 만들려면 다음 안내를 따르세요.
    1. 수정을 클릭합니다.
    2. + 대상 서버를 클릭합니다.
    3. 대상 서버의 이름, 호스트, 포트를 입력합니다.

      예를 들면 다음과 같습니다.

      • 이름: target1
      • 호스트: 1.mybackendservice.com
      • 포트: 80
    4. 사용 설정됨을 선택하여 대상 서버를 사용 설정합니다.
    5. 저장을 클릭합니다.
  5. 대상 서버를 수정하려면 다음 안내를 따르세요.
    1. 수정을 클릭합니다.
    2. targer 서버 값을 수정합니다.
    3. 저장을 클릭합니다.
  6. 대상 서버를 삭제하려면 다음 안내를 따르세요.
    1. 수정을 클릭합니다.
    2. 삭제를 클릭합니다.

API를 사용하여 대상 서버 관리

Edge API를 사용하여 대상 서버를 생성, 삭제, 업데이트, 가져오기, 나열할 수 있습니다. 자세한 내용은 TargetServers를 참조하세요.

다음 API 호출을 사용하여 대상 서버를 만듭니다.

$ curl -H "Content-Type:text/xml" -X POST -d \
'<TargetServer name="target1">
   <Host>1.mybackendservice.com</Host>
   <Port>80</Port>
   <IsEnabled>true</IsEnabled>
 </TargetServer>' \
-u email:password https://api.enterprise.apigee.com/v1/o/{org_name}/environments/test/targetservers

샘플 응답:

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

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

$ curl -H "Content-type:text/xml" -X POST -d \
'<TargetServer  name="target2">
  <Host>2.mybackendservice.com</Host>
  <Port>80</Port>
  <IsEnabled>true</IsEnabled>
</TargetServer >' \
-u email:password https://api.enterprise.apigee.com/v1/o/{org_name}/environments/test/targetservers

샘플 응답:

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

환경의 TargetServer 목록을 검색하려면 다음 API 호출을 사용합니다.

$ curl -u email:password https://api.enterprise.apigee.com/v1/o/{org_name}/environments/test/targetservers

샘플 응답:

[ "target2", "target1" ]

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

한도 주제에 설명된 대로 환경당 TargetServers 500개로 제한됩니다.

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

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

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

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

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

부하 분산기 옵션 설정

부하 분산기 및 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로 2개의 요청이 라우팅됩니다.

최소 연결

최소 연결 알고리즘을 사용하도록 구성된 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가 대상 서버로부터 어떠한 응답도 받지 못했음을 의미합니다. 이러한 경우 실패 카운터가 1회씩 증가합니다.

하지만 Apigee가 대상의 응답을 수신하면 응답이 HTTP 오류 (예: 500)인 경우에도 대상 서버의 응답으로 집계되며 실패 카운터가 재설정됩니다. 잘못된 HTTP 응답(예: 500)도 실패 카운터를 증가시켜 비정상 서버가 부하 분산 회전에서 최대한 빨리 나가도록 하려면 <ResponseCode> 하위 요소가 있는 <ServerUnhealthyResponse> 요소를 부하 분산기 구성에 추가하면 됩니다. 또한 Edge는 이러한 코드가 있는 응답을 실패로 계산합니다.

다음 예시에서 target1는 대상 서버의 일부 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입니다. 즉, Edge는 항상 각 요청에서 대상에 연결하려고 시도하며 대상 서버를 순환에서 삭제하지 않습니다.

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

또는 MaxFailures를 0보다 크게 구성하고 HealthMonitor,를 구성하지 않으면 Apigee가 오류 감지 후 TargetServer를 순환에 다시 포함하지 않습니다. 이 경우 Apigee가 TargetServer를 다시 순환에 배치하기 전 API 프록시를 다시 배포해야 합니다. API 프록시 배포를 참조하세요.

다시 시도

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

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

<RetryEnabled>false</RetryEnabled>

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>

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

경로

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

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

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

TLS/SSL용 대상 서버 구성

TargetServer를 사용하여 백엔드 서비스를 정의할 때 백엔드 서비스에서 HTTPS 프로토콜을 사용하려면 연결이 필요한 경우, TargetServer 정의에서 TLS/SSL을 사용 설정해야 합니다. 이는 <Host> 태그로는 연결 프로토콜을 지정할 수 없기 때문에 필요합니다. 다음은 Edge에서 백엔드 서비스에 HTTPS 요청을 수행하는 단방향 TLS/SSL에 대한 TargetServer 정의입니다.

<TargetServer name="target1">
  <Host>mocktarget.apigee.net</Host>
  <Port>443</Port>
  <IsEnabled>true</IsEnabled>
  <SSLInfo>
      <Enabled>true</Enabled>
  </SSLInfo> 
</TargetServer>

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

<TargetServer  name="TargetServer 1">
    <IsEnabled>true</IsEnabled>
    <Host>www.example.com</Host>
    <Port>443</Port>
    <SSLInfo>
        <Ciphers/>
        <ClientAuthEnabled>true</ClientAuthEnabled>
        <Enabled>true</Enabled>
        <IgnoreValidationErrors>false</IgnoreValidationErrors>
        <KeyAlias>keystore-alias</KeyAlias>
        <KeyStore>keystore-name</KeyStore>
        <Protocols/>
        <TrustStore>truststore-name</TrustStore>
    </SSLInfo>
</TargetServer >

<Ciphers><ClientAuthEnabled>와 같은 <SSLInfo> 속성에 대한 자세한 내용은 Private Cloud용 API에 대한 TLS 액세스 구성에서 가상 호스트에 대해 이러한 속성을 설정하는 방법을 참조하세요.

아웃바운드 TLS/SSL 구성에 대한 자세한 안내는 에지에서 백엔드로 TLS 구성 (클라우드 및 프라이빗 클라우드)을 참조하세요.

TargetServer 스키마

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

상태 모니터링

상태 모니터링을 사용 설정하면 TargetServer 구성에 정의된 백엔드 서비스 URL을 적극적으로 폴링하여 부하 분산 구성을 향상시킬 수 있습니다. 상태 모니터링이 사용 설정된 경우 HealthMonitor에서 TargetServer가 활성 상태임을 확인하면 실패한 TargetServer가 자동으로 로테이션에 복귀됩니다.

상태 모니터링은 <MaxFailures>와 함께 작동합니다. 상태 모니터링이 사용 설정되지 않은 경우 <MaxFailures>는 API 프록시에서 TargetServer에 대한 실패한 요청 수를 지정합니다. 이 요청은 다른 TargetServer로 리디렉션됩니다. 그러면 프록시를 다시 배포할 때까지 실패한 TargetServer가 로테이션에서 제외됩니다.

상태 모니터링을 사용 설정하면 실패한 TargetServer가 자동으로 로테이션에 복귀하며 프록시 재배포가 필요하지 않습니다.

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

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

성공 및 실패

상태 모니터링을 사용 설정하면 Edge에서 대상 서버로 상태 확인을 전송하기 시작합니다. 상태 확인은 대상 서버로 전송되는 요청으로 대상 서버가 정상인지 확인합니다.

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

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

    Edge에서 서버가 정상이라고 판단하면 서버에 요청 전송을 계속하거나 재개합니다.

  • 실패: 대상 서버가 확인 유형에 따라 여러 가지 방법으로 상태 점검에 실패할 수 있습니다. 대상 서버가 다음과 같은 경우 실패가 로깅될 수 있습니다.
    • Edge에서 상태 확인 포트로의 연결을 거부합니다.
    • 지정된 기간 내에 상태 확인 요청에 응답하지 않습니다.
    • 예상치 못한 HTTP 상태 코드를 반환합니다.
    • 예상 메일 본문과 일치하지 않는 메일 본문으로 응답합니다.

    대상 서버가 상태 점검에 실패하면 Edge는 해당 서버의 실패 횟수를 증가시킵니다. 해당 서버의 실패 횟수가 사전 정의된 기준(<MaxFailures>)을 충족하거나 초과하면 Edge는 해당 서버로의 요청 전송을 중지합니다.

HealthMonitor 사용 설정

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

간단한 HealthMonitor는 TCPMonitor 또는 HTTPMonitor와 결합한 IntervalInSec를 정의합니다. <MaxFailures> 요소는 API 프록시에서 TargetServer로 최대 실패 요청 수를 지정하여 요청이 다른 TargetServer로 리디렉션되게 합니다. 기본적으로 <MaxFailures>는 0입니다. 즉, Edge에서 수정 작업을 실행하지 않습니다. 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>
. . .

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 프로토콜을 사용하도록 구성된 백엔드 서비스를 지원합니다. 그러나 다음은 지원되지 않습니다.

  • 양방향 HTTPS (양방향 TLS/SSL이라고도 함)
  • 자체 서명된 인증서

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

    <HealthMonitor>
      <IsEnabled>true</IsEnabled>
      <IntervalInSec>5</IntervalInSec>
      <HTTPMonitor>
        <Request>
          <IsSSL>true</IsSSL>
          <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>
    

HTTPMonitor를 사용하는 HealthMonitor 구성 요소

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

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

HealthMonitor에서 로테이션하는 TargetServer에 전송되는 아웃바운드 요청 메시지의 구성 옵션입니다.

경로에서는 변수를 지원하지 않습니다.

해당 사항 없음 지원됨
IsSSL 연결 모니터링에 HTTPS (보안 HTTP)를 사용할지 여부를 지정합니다.

가능한 값은 다음과 같습니다.
  • true: HTTPS가 사용됩니다.
  • false: HTTP가 사용됩니다.
  • 지정되지 않음: 대상 서버 구성을 사용합니다.
false 아니요
ConnectTimeoutInSec HTTP 서비스로의 TCP 연결 핸드셰이크가 성공으로 간주되려면 완료해야 하는 시간(초)입니다. 지정된 간격에 연결하지 못하면 실패로 간주되고 TargetServer의 LoadBalancer 실패 횟수가 증가합니다. 0 아니요
SocketReadTimeoutInSec 성공으로 간주되려면 HTTP 서비스에서 데이터를 읽어야 하는 시간(초)입니다. 지정된 간격에 읽지 못하면 장애가 발생하여 TargetServer에 대한 LoadBalancer의 실패 횟수가 증가합니다. 0 아니요
Port 백엔드 서비스에 대한 HTTP 연결이 설정될 포트입니다. 해당 사항 없음 아니요
Verb 백엔드 서비스에 대한 각 HTTP 요청 폴링에 사용되는 HTTP 동사입니다. 해당 사항 없음 아니요
Path TargetServer에 정의된 URL에 추가되는 경로입니다. 경로 요소를 사용하여 HTTP 서비스에서 '폴링 엔드포인트'를 구성합니다. 해당 사항 없음 아니요

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 요청에는 이 요소가 필요하지 않습니다. 해당 사항 없음 아니요
SuccessResponse 폴링된 백엔드 서비스에서 생성한 인바운드 HTTP 응답 메시지의 일치 옵션입니다. 응답이 일치하지 않으면 실패 횟수가 1씩 증가합니다. 해당 사항 없음 아니요
ResponseCode 폴링된 TargetServer에서 수신될 HTTP 응답 코드입니다. 지정된 코드와 다른 코드를 사용하면 실패하고 폴링된 백엔드 서비스의 수가 증가합니다. 여러 ResponseCode 요소를 정의할 수 있습니다. 해당 사항 없음 아니요
Headers 폴링된 백엔드 서비스에서 수신될 수 있는 하나 이상의 HTTP 헤더 및 값의 목록입니다. 응답의 HTTP 헤더 또는 값이 특정 결과와 다른 경우에 실패하고 폴링된 TargetServer의 수가 1씩 증가합니다. 여러 헤더 요소를 정의할 수 있습니다. 해당 사항 없음 아니요