다음을 통해 공유

Azure Service Fabric 클러스터 크기 조정

  • 아티클

Service Fabric 클러스터는 마이크로 서비스가 배포되고 관리되는 네트워크로 연결된 가상 또는 실제 머신 집합입니다. 클러스터의 일부인 머신 또는 VM을 노드라고 합니다. 클러스터는 잠재적으로 수천 개의 노드를 포함할 수 있습니다. Service Fabric 클러스터를 만든 후에 수평으로(노드 수 변경) 또는 수직으로(노드의 리소스 변경) 클러스터 크기를 조정할 수 있습니다. 클러스터에서 워크로드가 실행되는 경우에도 언제든지 클러스터의 크기를 조정할 수 있습니다. 클러스터의 크기를 조정하면 애플리케이션 크기도 자동으로 조정됩니다.

클러스터 크기를 조정하는 이유 애플리케이션 수요는 시간이 지남에 따라 달라집니다. 늘어난 애플리케이션 워크로드나 네트워크 트래픽을 충족하기 위해 클러스터 리소스를 늘리고, 수요가 줄어들면 클러스터 리소스를 줄여야 할 수 있습니다.

스케일 인/스케일 아웃 또는 수평적 크기 조정

클러스터의 노드 수를 변경합니다. 새 노드가 클러스터에 조인하면 클러스터 리소스 관리자에서 서비스를 이 노드로 이동하므로 기존 노드의 부하가 감소합니다. 클러스터의 리소스가 효율적으로 사용되지 않을 경우에도 노드 수를 줄일 수 있습니다. 노드가 클러스터를 떠나면 서비스는 해당 노드를 외부로 이동하므로 나머지 노드에서 부하가 늘어납니다. 해당 VM의 워크로드가 아닌 사용하는 VM 수에 따라 비용을 지불하게 되므로 Azure에서 실행되는 클러스터의 노드 수를 줄이면 비용을 절약할 수 있습니다.

  • 장점: 이론적으로는 제한없이 확장할 수 있습니다. 애플리케이션이 확장 가능하게 디자인된 경우, 더 많은 노드를 추가하여 제한없이 증가할 수 있습니다. 클라우드 환경의 도구를 사용하면 노드를 손쉽게 추가 또는 제거할 수 있으므로 용량을 쉽게 조정할 수 있고, 사용한 리소스에 대해서만 비용을 지불하게 됩니다.
  • 단점: 애플리케이션을 확장 가능하게 디자인해야 합니다. 애플리케이션 데이터베이스 및 지속성도 확장하려면 추가적인 아키텍처 작업이 필요할 수 있습니다. 그렇지만 Service Fabric 상태 저장 서비스의 신뢰할 수 있는 컬렉션을 사용하면 애플리케이션 데이터를 훨씬 더 쉽게 확장할 수 있습니다.

가상 머신 확장 집합은 가상 머신의 컬렉션을 집합으로 배포하고 관리하는 데 사용할 수 있는 Azure 컴퓨팅 리소스입니다. Azure 클러스터에 정의된 모든 노드 유형은 별도의 확장 집합으로 설정됩니다. 각 노드 형식은 독립적으로 확장 또는 축소되고, 다른 포트의 집합을 열며 다른 용량 메트릭을 가질 수 있습니다.

Azure 클러스터 크기를 조정할 때는 다음 지침에 유의하세요.

  • 프로덕션 워크로드를 실행하는 주 노드 형식에는 항상 5개 이상의 노드가 있어야 합니다.
  • 상태 저장 프로덕션 워크로드를 실행하는 주가 아닌 노드 형식에는 항상 5개 이상의 노드가 있어야 합니다.
  • 상태 비저장 프로덕션 워크로드를 실행하는 주가 아닌 노드 형식에는 항상 2개 이상의 노드가 있어야 합니다.
  • 내구성 수준이 골드 또는 실버인 모든 노드 형식에는 항상 5개 이상의 노드가 있어야 합니다.
  • 노드 형식에서 임의의 VM 인스턴스/노드를 삭제하지 말고 항상 가상 머신 확장 집합 스케일 인 기능을 사용하세요. 임의 VM 인스턴스를 삭제하면 부하를 적절히 분산하는 시스템 기능에 부정적인 영향을 줄 수 있습니다.
  • 자동 크기 조정 규칙을 사용하는 경우 스케일 인(VM 인스턴스 제거)을 한 번에 한 노드에서 수행하도록 규칙을 설정합니다. 한 번에 여러 인스턴스의 규모를 축소하는 방식은 안전하지 않습니다.

클러스터의 Service Fabric 노드 형식은 백 엔드에서 가상 머신 확장 집합으로 구성되므로 각 노드 형식/가상 머신 확장 집합에 대한 자동 크기 조정 규칙을 설정하거나 수동으로 크기를 조정해야 합니다.

프로그래밍 방식으로 크기 조정

많은 시나리오에서 수동으로 또는 자동 크기 조정 규칙을 통해 클러스터 크기를 조정하는 것은 적절한 해결 방법입니다. 그러나 고급 시나리오에서는 이 방법이 적절하지 않을 수 있습니다. 이러한 접근 방식의 잠재적 단점은 다음과 같습니다.

  • 수동으로 스케일링하려면 로그인하여 스케일링 작업을 명시적으로 요청해야 합니다. 크기 조정 작업을 자주 또는 예기치 않은 시점에 수행해야 하는 경우에는 이 방법이 좋지 않을 수 있습니다.
  • 자동 크기 조정 규칙은 가상 머신 확장 집합에서 인스턴스를 제거할 때 노드 형식의 내구성 수준이 Silver 또는 Gold가 아닌 한 연결된 Service Fabric 클러스터에서 해당 노드의 지식을 제거하지 않습니다. 자동 크기 조정 규칙은 Service Fabric 수준이 아닌 확장 집합 수준에서 작동하기 때문에 Service Fabric 노드를 정상적으로 종료하지 않아도 자동 크기 조정 규칙이 Service Fabric 노드를 제거할 수 있습니다. 이 강제 노드 제거는 규모 감축 작업 후 'ghost' Service Fabric 노드 상태를 남깁니다. 개인(또는 서비스)은 Service Fabric 클러스터에서 제거된 노드 상태를 주기적으로 정리해야 합니다.
  • 내구성 수준이 Gold 또는 Silver인 노드 유형은 제거된 노드를 자동으로 정리하므로 추가 정리가 필요하지 않습니다.
  • 자동 크기 조정 규칙이 지원되는 여러 메트릭이 있지만 아직은 제한된 집합입니다. 이 집합에 포함되지 않는 일부 메트릭을 기반으로 하는 크기 조정이 필요한 시나리오의 경우 자동 크기 조정 규칙은 좋은 옵션이 아닐 수 있습니다.

Service Fabric 크기 조정에 접근하는 방식은 시나리오에 달렸습니다. 크기 조정을 자주 하지 않는다면 노드를 수동으로 추가 또는 제거할 수만 있으면 충분할 것입니다. 좀 더 복잡한 시나리오의 경우 프로그래밍 방식으로 확장하는 기능을 노출하는 자동 크기 조정 규칙과 SDK가 강력한 대안이 될 수 있습니다.

애플리케이션이 가상 머신 확장 세트 및 Service Fabric 클러스터를 프로그래밍 방식으로 작업할 수 있는 Azure API가 있습니다. 기존 자동 크기 조정 옵션이 시나리오에 적합하지 않은 경우 이러한 API를 사용하여 사용자 지정 크기 조정 논리를 구현할 수 있습니다.

이 '홈 수행 '수제작' 자동 크기 조정 기능을 구현하는 한 가지 방법은 크기 조정 작업을 관리하는 새로운 상태 비저장 서비스를 Service Fabric 애플리케이션에 추가하는 것입니다. 사용자 고유의 크기 조정 서비스를 만들면 애플리케이션 동작을 최대한 원하는 대로 제어하고 사용자 지정할 수 있습니다. 애플리케이션을 규모 감축 또는 규모 확장하는 시기와 방법을 정교하게 제어해야 하는 시나리오에는 이 방법이 유용할 수 있습니다. 그러나 이 제어 방법은 코드가 복잡해지는 단점이 있습니다. 이 방법을 사용하려면 특수한 크기 조정 코드가 필요합니다. 서비스의 RunAsync 메서드 내에서 트리거 집합은 크기 조정이 필요한지 여부(최대 클러스터 크기 및 크기 조정 휴지 시간 같은 매개 변수 확인 포함)를 확인할 수 있습니다.

가상 머신 확장 집합 상호 작용(현재 가상 머신 인스턴스의 수를 확인하고 수정하는 작업 포함)에 사용되는 API는 fluent Azure Management Compute 라이브러리입니다. fluent compute 라이브러리는 가상 머신 확장 집합과 상호 작용하는 간편한 API를 제공합니다. Service Fabric 클러스터 자체와 상호 작용하려면 System.Fabric.FabricClient를 사용하세요.

그렇지만 크기를 조정하기 위해 클러스터에서 크기 조정 코드를 서비스로 실행할 필요는 없습니다. IAzure 및 FabricClient는 각각 연결된 Azure 리소스에 원격으로 연결하기 때문에 Service Fabric 애플리케이션 외부에서 실행되는 콘솔 애플리케이션 또는 Windows 서비스는 손쉽게 크기 조정 서비스가 될 수 있습니다.

이러한 제한에 따라 보다 사용자 지정된 자동 크기 조정 모델을 구현하고자 할 수 있습니다.

규모 확장 및 축소 또는 수직적 크기 조정

클러스터에 있는 노드의 리소스(CPU, 메모리 또는 스토리지)를 변경합니다.

  • 이점: 소프트웨어 및 애플리케이션 아키텍처가 동일하게 유지됩니다.
  • 단점: 개별 노드에서 늘릴 수 있는 리소스 양이 제한되어 있으므로 확장 한계가 있습니다. 리소스를 추가하거나 제거하기 위해 물리적 컴퓨터 또는 가상 머신을 오프라인으로 전환해야 하므로 가동 중지 시간이 발생합니다.

가상 머신 확장 집합은 가상 머신의 컬렉션을 집합으로 배포하고 관리하는 데 사용할 수 있는 Azure 컴퓨팅 리소스입니다. Azure 클러스터에 정의된 모든 노드 유형은 별도의 확장 집합으로 설정됩니다. 각 노드 형식을 별도로 관리할 수 있습니다. 노드 형식을 스케일 업 또는 다운하려면 새 노드 형식(업데이트된 VM SKU 포함)을 추가하고 이전 노드 형식을 제거해야 합니다.

Azure 클러스터 크기를 조정할 때는 다음 지침에 유의하세요.

  • 주 노드 형식의 규모를 축소하는 경우에는 안정성 계층에서 허용하는 범위 이상으로 규모를 축소하면 안 됩니다.

노드 형식 규모 확장 또는 축소 프로세스는 주 노드 형식인지 아닌지에 따라 달라집니다.

주가 아닌 노드 형식 크기 조정

필요한 리소스를 사용하여 새 노드 형식을 만듭니다. 새 노드 형식을 포함하도록 실행 중인 서비스의 배치 제약 조건을 업데이트합니다. 클러스터의 안정성에 영향을 주지 않도록 점진적으로(한 번에 하나씩) 이전 노드 형식 인스턴스의 수를 0까지 줄입니다. 이전 노드 형식이 서비스 해제되면 서비스는 점차 새 노드 형식으로 마이그레이션됩니다.

주 노드 형식 크기 조정

업데이트된 VM SKU를 사용하여 새로운 주 노드 형식을 배포한 뒤 시스템 서비스를 새 확장 집합으로 마이그레이션하기 위해 기존의 주 노드 형식 인스턴스를 사용하지 않도록 한 번에 하나씩 설정합니다. 클러스터 및 새 노드가 정상인지 확인하고 삭제된 노드에 대한 원래 확장 집합 및 노드 상태를 제거합니다.

이것이 불가능한 경우 새 클러스터를 만들고 구 클러스터에서 애플리케이션 상태를 복원할 수 있습니다(해당하는 경우). 시스템 서비스 상태를 복원할 필요는 없습니다. 애플리케이션을 새 클러스터에 배포하면 다시 만들어집니다. 클러스터에서 상태 비저장 애플리케이션을 실행한 경우에만 애플리케이션을 새 클러스터에 배포하기만 하면 되며 복원은 필요하지 않습니다.

다음 단계