워크로드를 관리하기 위한 스케일링 정책 정의

스케일링 정책은 구성 가능한 메트릭을 기반으로 동적 클러스터 멤버를 시작하고 중지하는 데 사용됩니다. 스케일링 정책은 모든 클러스터 또는 특정 클러스터에 정의할 수 있습니다. 정책이 정의되지 않으면 내장 정책이 사용됩니다.

이 태스크 정보

스케일링 제어기는 관리 중인 워크로드에 대해 결정하기 위해 스케일링 정책을 사용합니다. 기본적으로 내장 스케일링 정책은 스케일링 제어기에 임베드되어 있습니다. 선택에 따라 기본 스케일링 정책과 스케일링 정책이라는 최상위 레벨 요소 중 하나 또는 둘 다를 정의하여 내장 스케일링 정책을 대체할 수 있습니다. 내장 스케일링 정책은 다음과 같습니다.
  • 사용 가능한 경우 최소 두 개의 클러스터 멤버가 활성으로 유지됩니다. 일부 또는 전체 멤버가 메트릭 임계값을 초과하는 경우 최소 수가 충족되지 않을 수 있습니다.
  • 모든 활성 멤버의 평균 CPU, 힙 또는 메모리 사용량이 90%를 초과하는 경우 추가 클러스터 멤버가 시작됩니다.
  • 평균 CPU 및 힙 사용량이 30% 아래로 떨어지면 클러스터 멤버가 중지됩니다.

스케일링 정책은 기본 스케일링 정책을 사용하는 모든 클러스터에 대해 정의할 수 있습니다. 기본 스케일링 정책은 minmax 인스턴스 값을 포함하여 내장 스케일링 정책 메트릭을 상속합니다. 기본 스케일링 정책에 수행된, 사용자에 의해 지정된 모든 변경사항은 내장 값을 대체합니다. 기본 스케일링 정책에 지정되지 않은 값은 내장 스케일링 정책에서 상속됩니다.

기본 스케일링 정책과 달리 스케일링 정책 메트릭은 내장 또는 기본 스케일링 정책으로부터 상속되지 않습니다. 하지만, minmax 인스턴스 값은 내장 정책 값으로 초기화됩니다. 스케일링 정책 메트릭이 선택적 값으로 고려되므로 정책에 지정된 메트릭만이 스케일링 의사결정에 포함됩니다. 스케일링 정책에 포함되지 않은 메트릭은 스케일링 의사결정 시에 분석되지 않습니다.

스케일링 정책의 두 가지 레벨이 있습니다. 맨 위 레벨 요소 중 하나 또는 둘 다를 정의하여 내장 스케일링 정책을 대체할 수 있습니다. 다음은 정의할 수 있는 두 개의 레벨입니다.
  • 기본 스케일링 정책

    단일 기본 스케일링 정책을 정의하여 특정한 추가 스케일링 정책을 정의할 필요가 없는 모든 클러스터를 관리할 수 있습니다.

    다음 예제는 활성 클러스터 멤버의 최소 수를 3으로 설정하는 기본 스케일링 정책을 정의하는 방법을 보여줍니다.
    <scalingDefinitions>
     <defaultScalingPolicy min="3"/>
    </scalingDefinitions>
  • 스케일링 정책

    스케일링 정책에 지정된 대상 기준과 함께 하나 이상의 클러스터를 관리하도록 스케일링 정책을 정의할 수 있습니다. 스케일링 정책 정의가 메트릭 임계값을 상속하지 않으므로 지정된 메트릭 임계값만 모니터링됩니다. 다른 모든 임계값은 스케일링 의사결정과 관련되므로 무시됩니다. minmax 인스턴스에 대한 내장 스케일링 정책 값이 지정되지 않은 경우 이 값들이 계속 유지됩니다.

    다음 예제는 cluster1이라는 클러스터에서 서버를 시작하고 중지하기 위한 CPU 사용 임계값을 변경하는 스케일링 정책을 정의하는 방법을 보여줍니다.
    <scalingDefinitions>
      <scalingPolicy id="cluster1Policy">
      <bind clusters="cluster1"/>
      <metric name="CPU" min="10" max="70"/>
     </scalingPolicy>
    </scalingDefinitions>
    bind 요소의 clusters 속성 값은 클러스터 이름의 쉼표로 구분된 목록입니다. 별표는 0개 이상의 일치하는 문자를 나타내는 와일드카드로만 이름의 끝에 사용할 수 있습니다. 예:
    <bind clusters="west,south*"/>
    이 예제에서 스케일링 정책은 west라는 클러스터와 이름이 south로 시작하는 모든 클러스터에 적용됩니다. 클러스터 이름이 여러 정책에 일치하는 경우, 스케일링 제어기는 다음 규칙을 사용하여 정책을 선택합니다.
    • 와일드카드 일치에는 정확한 일치가 선호됩니다.
    • 여러 와일드카드 일치가 있는 경우, 접두부가 가장 긴 정책이 사용됩니다.

이 정책은 기본 minmax 값을 기반으로 스케일링됩니다. 위의 예에서 클러스터는 지정된 CPU 값을 기반으로만 스케일링되며, 여기서 min=10max=70입니다.

메트릭 기반 스케일링 의사결정은 클러스터 레벨에서 이루어집니다. 각 클러스터 멤버는 자체 메트릭을 모니터링합니다. 서버에 대한 CPU 및 메모리 메트릭 값은 실제로 서버 JVM 프로세스 또는 서버의 호스트보다 큽니다. 힙 메트릭 값은 서버 JVM 프로세스로부터만 가져옵니다. 모니터링된 메트릭의 측정 가능한 변경사항이 발견되면, 해당 메트릭이 분석을 위해 제어기로 보내집니다. 모든 클러스터 멤버 메트릭이 누적되고 클러스터 평균이 각 메트릭에 대해 계산됩니다. 그러면 각 메트릭에 대해 계산된 값은 스케일링 의사결정이 트리거되는지 여부를 판별하기 위해 정의된 상한 또는 하한 임계값과 비교됩니다.

용량 확장 의사결정은 개별 메트릭을 기반으로 이루어집니다. 모니터링된 모든 메트릭은 클러스터에서 분석되며 메트릭 중 하나라도 정책 max 임계값을 초과하면 용량 확장 이벤트가 트리거됩니다. 용량 축소 의사결정은 모니터링된 모든 메트릭을 기반으로 작성됩니다. 모니터링되는 각 메트릭의 클러스터 평균이 분석됩니다. 모든 메트릭이 정책 min 임계값 아래이면 용량 축소 이벤트가 트리거됩니다.

스케일링 의사결정이 이루어지면 스케일링 제어기가 스케일링 대상을 선택합니다. 스케일링 대상은 서버 중지(용량 축소) 또는 서버 시작(용량 확장) 조치가 실행되는 호스트입니다. 용량 확장 조치를 위한 대상을 결정할 경우 호스트 레벨 메트릭이 고려됩니다. 호스트 레벨 메트릭이 해당 메트릭의 정책 max 임계값을 초과할 경우, 스케일링 제어기가 호스트를 회피하며 용량 확장 조치를 위해 다른 호스트를 선택합니다.

스케일링 정책은 스케일링 대상의 선택에 영향을 줄 수 있습니다. 정책이 scalingPreference="horizontal"을 지정하면 스케일링 제어기가 가장 적은 수의 서버가 활성인 해당 호스트에서 서버를 시작하고 가장 많은 수의 서버가 활성인 호스트에서 서버를 중지합니다. 정책이 scalingPreference="vertical"을 지정하면 스케일링 제어기가 가장 많은 수의 서버가 활성인 해당 호스트에서 서버를 시작하고 가장 적은 수의 서버가 활성인 호스트에서 서버를 중지합니다. 스케일링 제어기는 선택한 scalingPreference에 관계없이 가능한 한 여러 호스트에서 동일한 클러스터에 서버를 배치하려 합니다.

scalingPolicy 메트릭에 대한 자세한 정보는 스케일링 제어기를 참조하십시오.

hostGroup 요소를 사용하여 새 서버를 프로비저닝하기 위해 선택할 수 있는 호스트를 제한할 수 있습니다. tags 속성은 관리 메타데이터 태그의 목록을 지정합니다. 스케일링 제어기는 서버를 프로비저닝해야 하는 경우 하나 이상의 일치하는 태그가 있는 호스트만 선택할 수 있습니다. 예를 들어, 아래의 정책에서는 tag1을 가진 호스트 또는 tag2가 연관된 호스트에서 서버를 프로비저닝할 수 있다고 규정합니다.
<scalingDefinitions>
  <scalingPolicy id="provisionPolicy">           
   <bind clusters="defaultStackGroup.deployMember"/>           
   <hostGroup tags="tag1 tag2"/>        
 </scalingPolicy>
</scalingDefinitions>
참고: hostGroup 요소를 지정하지 않는 경우 스케일링 제어기는 집합체에 등록된 모든 호스트에서 서버를 프로비저닝할 수 있습니다.

관리 메타데이터 태그 설정에 대한 자세한 정보는 Liberty 자원에 대한 관리 메타데이터 설정의 내용을 참조하십시오.

프로시저

  1. 스케일링 제어기의 server.xml 파일에 기본 스케일링 정의를 추가하십시오.
    <scalingDefinitions>
     <defaultScalingPolicy enabled="true" min="1" max="2"/>
    </scalingDefinitions>
  2. 스케일링 정책이 수정되는 경우 제어기의 server.xml도 수정됩니다. messages.log 파일에서 다음 메시지를 검사하여 제어기가 성공적으로 업데이트되었는지 확인하십시오.
    CWWKG0016I: Starting server configuration update.
    CWWKG0028A: Processing included configuration resource: /opt/IBM/Liberty/wlp/usr/
    CWWKG0017I: The server configuration was successfully updated in 0.052 seconds
    스케일링 정책에서 필수 메트릭 임계값이 누락되면 messages.log 파일에 다음 오류 메시지가 표시됩니다. 오류를 정정하려면 사용자 조치를 따르십시오.
    CWWKV0126W: 스케일링 정책 {0}의 구성에 최소 또는 최대 임계값이 없습니다.
    CWWKV0127W: 스케일링 정책 {0}의 구성에 최대 임계값이 없습니다.
    CWWKV0128W: 스케일링 정책 {0}의 구성에 최소 임계값이 없습니다.

결과

이제 스케일링 정책이 정의되었습니다.


주제의 유형을 표시하는 아이콘 태스크 주제

파일 이름: twlp_wve_definingscalingpolicies.html