백엔드 서버 간 부하 분산

<ph type="x-smartling-placeholder"></ph> 현재 Apigee Edge 문서를 보고 있습니다.
Apigee X 문서. 정보

Apigee Edge는 부하에 대한 기본 지원을 제공하여 API의 가용성을 향상시킵니다. 분산 및 장애 조치를 수행합니다

TargetServer 구성이 TargetEndpoint에서 구체적인 엔드포인트 URL을 분리 구성할 수 있습니다 각 TargetServer는 TargetEndpoint에서 이름으로 참조됨 HTTP 연결입니다. 구성에서 구체적인 URL을 정의하는 대신 하나 이상의 명명된 TargetServers에 연결 TargetEndpoint를 가져올 수 있습니다.

TargetServer 정의는 이름, 호스트 및 포트로 구성되며 TargetServer의 사용 설정 또는 사용 중지 여부를 나타냅니다.

동영상

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

샘플 TargetServer 구성

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

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

TargetServer 구성 요소

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

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

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

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
}

다음 API 호출을 사용하여 환경의 TargetServer 목록을 가져옵니다.

$ 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 프록시에서 백엔드 서버로 보내는 아웃바운드 요청은 타겟 2와 타겟 2가 있습니다.

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

부하 분산기 옵션 설정

부하 시 부하 분산 및 장애 조치 옵션을 사용하여 가용성을 조정할 수 있습니다. 대상 서버 수준을 지정합니다 이 섹션에서는 이러한 옵션에 대해 설명합니다.

알고리즘

<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에 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는 5회 후에 순환게재에서 삭제됩니다. 대상 서버의 일부 5XX 응답을 포함하여 실패한 요청 수

<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가 준비되면 Apigee가 자동으로 타겟이 다시 실행된 후 구성하겠습니다 상태 모니터링을 참조하세요. 를 참조하세요.

또는 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> 태그로는 연결 프로토콜을 지정할 수 없기 때문에 필요합니다. 다음은 단방향에 대한 TargetServer 정의입니다. Edge에서 백엔드 서비스에 HTTPS 요청을 하는 TLS/SSL:

<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 >

<SSLInfo> 속성에 대한 정보 <Ciphers> 및 <ClientAuthEnabled>의 경우 가상 호스트의 속성 설정에 대한 자세한 내용은 API에 대한 TLS 액세스 구성 (Private Cloud용)

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

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