백엔드 서버 간 부하 분산

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

Apigee Edge 문서 보기

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

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

동영상

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

대상 서버 구성 정보

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

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

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

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

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

대상 서버 만들기

다음 섹션에서 설명하는 대로 Apigee UI 또는 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",
  }'
 

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

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
}

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

[ "target2", "target1" ]

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

이제 두 개의 대상 서버를 사용할 수 있으므로 대상 엔드포인트의 <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가 되고 다른 대상 서버에도 이와 같이 적용됩니다.

부하 분산기 옵션 구성

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

알고리즘

<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는 상태 모니터 구성에 따라 대상이 다시 가동되어 실행된 후 대상 서버를 다시 순환에 배치합니다. 자세한 내용은 상태 모니터링을 참조하세요.

일반 API 호출과 상태 모니터에서 시작된 호출 모두 MaxFailures 수에 포함된다는 점에 유의하세요.

또한 각 대상 서버의 실행 실패 수는 부하 분산기별로 유지됩니다. 예를 들어 프록시에 두 개의 대상 엔드포인트가 있고 각각에 부하 분산기가 있으며 두 부하 분산기가 동일한 대상 서버 집합을 활용하도록 구성되어 있다고 가정해 보겠습니다. 이 경우 한 대상 엔드포인트의 실패는 해당 부하 분산기에 대해서만 집계됩니다. 다른 대상 엔드포인트의 순환에는 영향을 미치지 않습니다.

또는 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 태그로는 연결 프로토콜을 지정할 수 없기 때문에 필요합니다.

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

상태 모니터는 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> 구성 요소를 설명합니다.

이러한 요소 외에도 상태 모니터를 사용 설정하려면 <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> 구성 요소를 설명합니다.

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

<HTTPMonitor>/<Request> 구성 요소

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

<HTTPMonitor>/<SuccessResponse> 구성 요소

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