Service Fabric에서 크기 조정

아티클
08/25/2024

Azure Service Fabric을 사용하면 클러스터 노드의 서비스, 파티션 및 복제본을 관리하여 확장 가능한 애플리케이션을 쉽게 빌드할 수 있습니다. 동일한 하드웨어에서 많은 워크로드를 실행하면 리소스를 최대한 활용할 수 있을 뿐만 아니라 워크로드의 크기를 조정하기 위해 선택하는 방법에 유연성도 제공합니다. 이 채널 9 비디오에서는 확장 가능한 마이크로 서비스 애플리케이션을 구축하는 방법을 설명합니다.

Service Fabric에서 크기를 조정하는 경우 다음과 같은 여러 가지 방법으로 수행됩니다.

크기 조정: 상태 비저장 서비스 인스턴스 만들기 또는 제거
크기 조정: 명명된 새 서비스 만들기 또는 제거
크기 조정: 명명된 새 애플리케이션 인스턴스 만들기 또는 제거
크기 조정: 분할된 서비스 사용
크기 조정: 클러스터에서 노드 추가 및 제거
크기 조정: 클러스터 리소스 관리자 메트릭 사용

크기 조정: 상태 비저장 서비스 인스턴스 만들기 또는 제거

Service Fabric 내에서 크기를 조정하는 가장 간단한 방법 중 하나는 상태 비저장 서비스를 사용하는 것입니다. 상태 비저장 서비스를 만들 때 InstanceCount를 정의할 수 있습니다. InstanceCount는 서비스를 시작할 때 만들어지는 서비스 코드의 실행 복사본 수를 정의합니다. 예를 들어 클러스터에 100개의 노드가 있고, InstanceCount가 10인 서비스를 만든다고 가정해 보겠습니다. 런타임 중에 코드 실행 중인 10개 복사본이 모두 바쁘게 사용될 수 있거나 충분히 사용되지 않을 수 있습니다. 해당 워크로드의 크기를 조정하는 한 가지 방법은 인스턴스 수를 변경하는 것입니다. 예를 들어 일부 모니터링 또는 관리 코드는 로드에 기반하여 워크로드를 확장 또는 축소해야 하는지 여부에 따라 기존 인스턴스 수를 50 또는 5로 변경할 수 있습니다.

C#:

StatelessServiceUpdateDescription updateDescription = new StatelessServiceUpdateDescription(); 
updateDescription.InstanceCount = 50;
await fabricClient.ServiceManager.UpdateServiceAsync(new Uri("fabric:/app/service"), updateDescription);

PowerShell:

Update-ServiceFabricService -Stateless -ServiceName $serviceName -InstanceCount 50

동적 인스턴스 수 사용

특히 상태 비저장 서비스의 경우 Service Fabric에서 인스턴스 수를 자동으로 변경하는 방법을 제공합니다. 이렇게 하면 사용 가능한 노드 수를 통해 서비스의 크기를 동적으로 조정할 수 있습니다. 이 동작을 선택하는 방법은 인스턴스 수를 -1로 설정하는 것입니다. InstanceCount = -1은 "모든 노드에서 이 상태 비저장 서비스 실행합니다."라는 Service Fabric에 대한 지침입니다. 노드 수가 변경되는 경우 Service Fabric에서 일치하도록 인스턴스 수가 자동으로 변경되어 서비스가 유효한 모든 노드에서 실행되고 있는지 확인합니다.

C#:

StatelessServiceDescription serviceDescription = new StatelessServiceDescription();
//Set other service properties necessary for creation....
serviceDescription.InstanceCount = -1;
await fc.ServiceManager.CreateServiceAsync(serviceDescription);

PowerShell:

New-ServiceFabricService -ApplicationName $applicationName -ServiceName $serviceName -ServiceTypeName $serviceTypeName -Stateless -PartitionSchemeSingleton -InstanceCount "-1"

크기 조정: 명명된 새 서비스 만들기 또는 제거

명명된 서비스 인스턴스는 클러스터의 명명된 특정 애플리케이션 인스턴스 내에 있는 서비스 유형의 특정 인스턴스입니다(Service Fabric 애플리케이션 수명 주기참조).

서비스가 더 많거나 적게 사용됨에 따라 명명된 새 서비스 인스턴스가 만들어지거나 제거될 수 있습니다. 이렇게 하면 더 많은 서비스 인스턴스에서 요청을 분산할 수 있으므로 대개 기존 서비스에 대한 로드를 줄일 수 있습니다. 서비스를 만들 때 Service Fabric 클러스터 리소스 관리자에서 클러스터에 서비스를 분산 방식으로 배치합니다. 정확한 결정은 클러스터 및 다른 배치 규칙의 메트릭으로 관리됩니다. 서비스는 여러 가지 방법으로 만들 수 있지만 가장 일반적인 방법은 New-ServiceFabricService를 호출하는 사람이나 CreateServiceAsync를 호출하는 코드와 같은 관리 작업을 사용하는 것입니다. CreateServiceAsync는 클러스터에서 실행되는 다른 서비스에서도 호출할 수 있습니다.

서비스를 동적으로 만들면 모든 종류의 시나리오에서 사용할 수 있으며 일반적인 패턴입니다. 예를 들어 특정 워크플로를 나타내는 상태 저장 서비스를 고려합니다. 작업을 나타내는 호출이 이 서비스에 표시되며, 이 서비스에서는 해당 워크플로에 대한 단계를 실행하고 진행 상황을 기록합니다.

이 특정 서비스의 규모를 어떻게 만들까요? 서비스는 어떤 형태로든 다중 테넌트가 될 수 있으며, 동일한 워크플로의 다양한 여러 인스턴스에 대한 호출을 모두 수락하고 단계를 동시에 시작할 수 있습니다. 그러나 이제는 서로 다른 단계와 다른 고객으로부터 동일한 워크플로의 다양한 여러 인스턴스를 걱정해야 하기 때문에 코드를 더욱 복잡하게 만들 수 있습니다. 또한 여러 워크플로를 동시에 처리해도 규모 문제가 해결되지 않습니다. 이는 특정 시점에 이 서비스에서 너무 많은 리소스를 소비하여 특정 컴퓨터에 적합하지 않기 때문입니다. 첫 번째 위치에서 이 패턴에 맞게 빌드되지 않은 많은 서비스에서는 코드의 고유한 병목 현상 또는 속도 저하로 인해 어려움을 겪기도 합니다. 이러한 유형의 문제로 인해 추적 중인 동시 워크플로의 수가 커지면 서비스가 제대로 작동하지 않습니다.

해결 방법은 추적하려는 워크플로의 다른 모든 인스턴스에 대해 이 서비스의 인스턴스를 만드는 것입니다. 이는 훌륭한 패턴이며 서비스가 상태 비저장 또는 상태 저장인지의 여부에 관계 없이 작동합니다. 이 패턴이 작동하기 위해 일반적으로 "워크로드 관리자 서비스" 역할을 하는 또 다른 서비스가 있습니다. 이 서비스의 작업은 요청을 받고 이러한 요청을 다른 서비스로 라우팅하는 것입니다. 메시지를 받은 관리자에서 워크로드 서비스의 인스턴스를 동적으로 만든 다음 해당 서비스에 요청을 전달할 수 있습니다. 관리자 서비스는 지정된 워크플로 서비스에서 작업을 완료할 때 콜백을 받을 수도 있습니다. 관리자에서 이러한 콜백을 받으면 워크플로 서비스의 해당 인스턴스를 삭제하거나 더 많은 호출이 예상되는 경우 관리자에게 남겨 둘 수 있습니다.

이 유형의 관리자의 고급 버전에서는 관리하는 서비스의 풀을 만들 수도 있습니다. 풀을 사용하면 새 요청이 들어올 때 서비스가 회전될 때까지 기다릴 필요가 없습니다. 대신 현재 풀에서 사용되지 않거나 무작위로 라우팅되는 워크플로 서비스를 관리자에서 선택할 수 있습니다. 서비스 풀을 사용할 수 있도록 유지하면 새 서비스가 회전될 때까지 요청이 대기해야 할 가능성이 낮기 때문에 새 요청을 더 빠르게 처리할 수 있습니다. 새 서비스를 만드는 것은 빠르지만 자유롭거나 즉각적이지는 않습니다. 풀을 사용하면 요청에 서비스를 제공하기 전에 대기해야 하는 시간을 최소화할 수 있습니다. 응답 시간이 가장 중요한 경우 이 관리자와 풀 패턴을 자주 보게 됩니다. 요청을 큐에 넣고 백그라운드에서 서비스를 만든 후에 해당 요청을 전달하는 것도 현재 서비스에서 보류 중인 작업량을 추적하여 이에 따라 서비스를 만들거나 삭제하는 것과 같이 널리 사용되는 관리자 패턴입니다.

크기 조정: 명명된 새 애플리케이션 인스턴스 만들기 또는 제거

전체 애플리케이션 인스턴스를 만들고 삭제하는 것은 서비스를 만들고 삭제하는 패턴과 비슷합니다. 이 패턴에는 보고 있는 요청과 클러스터 내부의 다른 서비스에서 받는 정보에 따라 결정하는 관리자 서비스가 있습니다.

어떤 기존 애플리케이션에서 명명된 새 서비스 인스턴스를 만드는 대신 명명된 새 애플리케이션 인스턴스를 만들어야 하나요? 여기에는 다음 몇 가지 경우가 있습니다.

새 애플리케이션 인스턴스는 특정 ID 또는 보안 설정에 따라 코드를 실행해야 하는 고객을 위한 것입니다.
- Service Fabric에서는 특정 ID로 실행되는 여러 코드 패키지를 정의할 수 있습니다. 서로 다른 ID로 동일한 코드 패키지를 실행하려면 여러 애플리케이션 인스턴스에서 활성화 작업을 수행해야 합니다. 기존 고객의 워크로드가 배포되는 경우를 고려합니다. 이러한 워크로드는 원격 데이터베이스 또는 다른 시스템과 같은 다른 리소스에 대한 액세스를 모니터링하고 제어할 수 있도록 특정 ID로 실행될 수 있습니다. 이 경우 새 고객이 등록할 때 동일한 컨텍스트(프로세스 공간)에서 코드를 활성화하지 않으려고 합니다. 가능하더라도 이는 특정 ID의 컨텍스트 내에서 서비스 코드가 작동하는 것을 더 어렵게 만듭니다. 일반적으로 더 많은 보안, 격리 및 ID 관리 코드가 있어야 합니다. 동일한 애플리케이션 인스턴스 내에서 명명된 다른 서비스 인스턴스를 사용하고 이에 따라 동일한 프로세스 공간을 사용하는 대신, 명명된 다른 Service Fabric 애플리케이션 인스턴스를 사용할 수 있습니다. 이렇게 하면 다른 ID 컨텍스트를 더 쉽게 정의할 수 있습니다.
새 애플리케이션 인스턴스는 구성 수단으로도 사용됩니다.
- 기본적으로 애플리케이션 인스턴스 내의 특정 서비스 유형의 명명된 서비스 인스턴스는 모두 지정된 노드에서 동일한 프로세스로 실행됩니다. 즉 각 서비스 인스턴스마다 다르게 구성할 수 있지만 이 방법은 복잡합니다. 서비스에는 구성 패키지 내에서 구성을 조회하는 데 사용하는 토큰이 있어야 합니다. 일반적으로 이 토큰은 서비스의 이름입니다. 이는 정상적으로 작동하지만 해당 애플리케이션 인스턴스 내의 명명된 개별 서비스 인스턴스 이름에 구성을 연결합니다. 이렇게 하면 구성이 일반적으로 애플리케이션 인스턴스별 특정 값이 있는 디자인 타임 아티팩트이므로 관리하기가 혼란스럽고 어려울 수 있습니다. 더 많은 서비스를 만들면 항상 구성 패키지 내의 정보를 변경하거나 새 패키지를 배포하여 더 많은 애플리케이션을 업그레이드할 수 있으므로 새 서비스에서 특정 정보를 조회할 수 있습니다. 종종 완전히 새로운 명명된 애플리케이션 인스턴스를 만드는 것이 더 쉽습니다. 그런 다음, 애플리케이션 매개 변수를 사용하여 서비스에 필요한 구성을 설정할 수 있습니다. 명명된 해당 애플리케이션 인스턴스 내에서 이러한 방식으로 만든 모든 서비스는 특정 구성 설정을 상속할 수 있습니다. 예를 들어 모든 고객에 대한 설정 및 사용자 지정(예: 비밀 또는 고객 리소스 제한별)이 포함된 단일 구성 파일을 갖추는 대신, 각 고객에 대해 이러한 설정이 재정의된 별도의 애플리케이션 인스턴스를 대신 갖출 수 있습니다.
새 애플리케이션은 업그레이드 경계 역할을 합니다.
- Service Fabric 내에서 명명된 다른 애플리케이션 인스턴스는 업그레이드를 위한 경계 역할을 합니다. 하나의 명명된 애플리케이션 인스턴스를 업그레이드해도 명명된 다른 애플리케이션 인스턴스에서 실행되는 코드에는 영향을 주지 않습니다. 다른 애플리케이션은 동일한 노드에서 동일한 코드의 다른 버전을 실행하게 됩니다. 새 코드에서 다른 서비스와 동일한 업그레이드를 수행하는지 여부를 선택할 수 있으므로 이는 크기 조정을 결정해야 할 때 필요한 요소일 수 있습니다. 예를 들어 서비스를 동적으로 만들고 삭제하여 특정 고객의 워크로드 크기를 조정하는 작업을 담당하는 관리자 서비스에 호출이 도착했다고 가정합니다. 그러나 이 경우 호출은 새 고객과 관련된 워크로드에 대한 호출입니다. 대부분의 고객은 이전에 나열된 보안 및 구성상의 이유뿐만 아니라 특정 버전의 소프트웨어를 실행하고 업그레이드 시점을 선택하는 측면에서 더 많은 유연성도 제공하기 때문에 서로 격리되는 것을 선호합니다. 또한 새 애플리케이션 인스턴스를 만들고 여기에 서비스를 간단히 만들어 하나의 업그레이드에서 사용할 서비스의 양을 더 자세히 분할할 수도 있습니다. 별도의 애플리케이션 인스턴스에서 애플리케이션 업그레이드를 수행할 때 더 자세한 세분성을 제공하며, A/B 테스트 및 파랑/녹색 배포도 가능하게 합니다.
기존 애플리케이션 인스턴스가 가득 찼습니다.
- Service Fabric에서 애플리케이션 용량은 특정 애플리케이션 인스턴스에 사용할 수 있는 리소스의 양을 제어하는 데 사용할 수 있는 개념입니다. 예를 들어 지정된 서비스에서 크기 조정을 위해 다른 인스턴스를 만들어야 한다고 결정할 수 있습니다. 그러나 이 애플리케이션 인스턴스에는 특정 메트릭에 대한 용량이 부족합니다. 이러한 특정 고객 또는 워크로드에 더 많은 리소스를 계속 부여해야 하는 경우 해당 애플리케이션의 기존 용량을 늘리거나 새 애플리케이션을 만들 수 있습니다.

파티션 수준에서 크기 조정

Service Fabric은 파티션을 지원합니다. 분할은 서비스를 여러 논리적 및 물리적 섹션으로 나누며, 각 섹션은 독립적으로 작동합니다. 어떤 복제본 집합에서도 모든 호출을 처리하고 모든 상태를 한 번에 조작할 수 없기 때문에 이 기능은 상태 저장 서비스에 유용합니다. 분할 개요 는 지원되는 분할 체계의 유형에 대한 정보를 제공합니다. 각 파티션의 복제본은 클러스터의 노드에 분산되어 해당 서비스의 로드를 분산하고 전체 또는 일부 파티션의 서비스가 단일 실패 지점을 갖지 않도록 합니다.

서비스가 0개의 하위 키, 99개의 상위 키 및 4개의 파티션 개수를 가진 범위 지정 파티션 구성표를 사용한다고 가정합니다. 3노드 클러스터에서 서비스는 다음과 같이 각 노드에서 리소스를 공유하는 4개의 복제본으로 배치될 수 있습니다.

3개의 노드가 있는 파티션 레이아웃

노드 수를 늘리면 Service Fabric에서 기존 복제본 일부를 이 위치로 이동합니다. 예를 들어 노드 수가 4개로 늘어나고 복제본이 다시 배포된다고 가정해 보겠습니다. 이제 서비스에는 각 노드에서 실행되는 3개의 복제본이 있으며, 각 복제본은 각각 다른 파티션에 속합니다. 이렇게 하면 새 노드가 콜드가 되지 않기 때문에 리소스를 더 효율적으로 사용할 수 있습니다. 일반적으로 각 서비스에서 더 많은 리소스를 사용할 수 있게 됨에 따라 성능도 향상됩니다.

4개의 노드가 있는 파티션 레이아웃

크기 조정: Service Fabric 클러스터 리소스 관리자 및 메트릭 사용

메트릭은 서비스에서 Service Fabric으로 리소스 사용량을 표현하는 방법입니다. 메트릭을 사용하면 클러스터 리소스 관리자에서 클러스터 레이아웃을 다시 구성하고 최적화할 수 있습니다. 예를 들어 클러스터에는 많은 리소스가 있을 수 있지만 현재 작업 중인 서비스에는 할당되지 않을 수 있습니다. 메트릭을 사용하면 클러스터 리소스 관리자에서 서비스가 사용 가능한 리소스에 액세스할 수 있도록 클러스터를 다시 구성할 수 있습니다.

크기 조정: 클러스터에서 노드 추가 및 제거

Service Fabric을 사용하여 크기를 조정하는 또 다른 옵션은 클러스터의 크기를 변경하는 것입니다. 클러스터의 크기를 변경하면 클러스터에서 하나 이상의 노드 형식에 대한 노드를 추가하거나 제거합니다. 예를 들어 클러스터의 모든 노드가 핫인 경우를 고려합니다. 이는 클러스터의 리소스가 거의 모두 사용된다는 것을 의미합니다. 이 경우 클러스터에 더 많은 노드를 추가하는 것이 가장 좋은 크기 조정 방법입니다. 새 노드가 클러스터에 조인하면 Service Fabric 클러스터 리소스 관리자에서 서비스를 이 노드로 이동하므로 기존 노드에 대한 총 로드가 줄어듭니다. 인스턴스 수가 -1인 상태 비저장 서비스의 경우 더 많은 서비스 인스턴스가 자동으로 만들어집니다. 이렇게 하면 일부 호출이 기존 노드에서 새 노드로 이동할 수 있습니다.

자세한 내용은 클러스터 크기 조정을 참조하세요.

플랫폼 선택

운영 체제 간의 구현 차이로 인해 Windows 또는 Linux에서 Service Fabric를 사용하도록 선택하는 것은 애플리케이션을 스케일링하는 데 중요한 부분이 될 수 있습니다. 한 가지 잠재적인 장애물은 단계적 로깅을 수행하는 방법입니다. Windows의 Service Fabric은 상태 저장 서비스 복제본 간에 공유되는 머신별 로그에 커널 드라이버를 사용합니다. 이 로그의 무게는 약 8GB입니다. 반면 Linux는 각 복제본에 대해 256MB의 준비 로그를 사용하므로 지정된 노드에서 실행되는 경량 서비스 복제본의 수를 최대화하려는 애플리케이션에는 적합하지 않습니다. 임시 스토리지 요구 사항의 이러한 차이는 Service Fabric 클러스터 배포에 적합한 플랫폼을 잠재적으로 알려줄 수 있습니다.

모든 항목 요약

여기서 설명한 모든 아이디어를 이용하여 예를 통해 설명해 보겠습니다. 이름 및 연락처 정보를 가지고 주소록의 역할을 하는 서비스를 빌드하려고 하는 다음 예제를 고려합니다.

바로 앞에서 크기 조정과 관련된 질문이 많았습니다. 얼마나 많은 사용자가 있나요? 각 사용자가 연락처를 얼마나 많이 저장하나요? 서비스를 처음 사용할 때 이러한 모든 사실을 파악하기는 어렵습니다. 특정 파티션 수를 통해 단일 정적 서비스를 이동하려고 한다고 가정해 보겠습니다. 잘못된 파티션 개수를 선택한 결과로 나중에 확장 문제가 발생할 수 있습니다. 마찬가지로, 올바른 수를 선택하더라도 필요한 모든 정보를 얻지 못할 수도 있습니다. 예를 들어 노드 수와 크기 측면에서 클러스터의 크기를 가장 먼저 결정해야 합니다. 일반적으로 서비스에서 수명 동안 사용할 리소스의 양을 예측하는 것은 어렵습니다. 또한 서비스에서 실제로 표시하는 트래픽 패턴을 미리 파악하는 것도 어려울 수 있습니다. 예를 들어 사람들이 아침에 가장 먼저 연락처만 추가하거나 삭제할 수 있으며, 아니면 하루 종일 균등하게 배포할 수도 있습니다. 이 정보에 따라 규모를 동적으로 확장하거나 축소해야 할 수도 있습니다. 규모를 확장하고 축소해야 하는 시기를 예측하기 위해 알아볼 수는 있지만, 어느 쪽이든 서비스를 통해 변화하는 리소스 사용량에 대응해야 할 것입니다. 이에 따라 기존 리소스의 사용을 다시 구성하는 것만으로는 충분하지 않은 경우 더 많은 리소스를 제공하기 위해 클러스터의 크기를 변경해야 할 수도 있습니다.

그러나 모든 사용자에 대해 단일 파티션 구성표를 선택하려는 이유는 무엇인가요? 하나의 서비스와 하나의 정적 클러스터로 제한하는 이유는 무엇인가요? 실제 상황은 일반적으로 더 동적입니다.

규모에 맞게 빌드하는 경우 다음 동적 패턴을 고려합니다. 상황에 맞게 조정해야 할 수도 있습니다.

모든 사용자에 대한 파티션 구성표를 선택하지 않고 "관리자 서비스"를 빌드합니다.
관리자 서비스의 작업은 서비스에 등록할 때 고객 정보를 확인하는 것입니다. 그런 다음, 해당 정보에 따라 관리자 서비스는 ‘해당 고객만을 위한 실제’ 연락처 스토리지 서비스의 인스턴스를 만듭니다. 특정 구성, 격리 또는 업그레이드가 필요한 경우 이 고객에 대한 애플리케이션 인스턴스를 회전하도록 결정할 수도 있습니다.

이 동적 만들기 패턴은 다음과 같은 많은 이점을 제공합니다.

모든 사용자에 대해 올바른 파티션 수를 추측하거나 자체적으로 무한하게 확장할 수 있는 단일 서비스를 빌드하려는 것은 아닙니다.
다른 사용자가 서비스 수준 또는 애플리케이션 수준에서 지정된 동일한 파티션 수, 복제본 수, 배치 제약 조건, 메트릭, 기본 로드, 서비스 이름, DNS 설정 또는 다른 속성을 가지고 있을 필요가 없습니다.
추가 데이터 조각화를 구성할 수 있습니다. 각 고객이 서비스의 고유한 복사본을 갖고 있기 때문에 데이터 구분이 가능합니다.
- 각 고객 서비스마다 예상되는 규모에 따라 필요한 만큼 더 많거나 적은 파티션 또는 복제본으로 다르게 구성되어 더 많거나 적은 리소스가 허용될 수 있습니다.
  - 예를 들어 고객이 "골드" 계층에 대한 요금을 지불한 경우 더 많은 복제본 또는 더 큰 파티션 수를 얻을 수 있으며, 잠재적으로 메트릭 및 애플리케이션 용량을 통해 서비스 전용 리소스를 얻을 수 있습니다.
  - 또는 필요한 계약 수가 "소량"임을 나타내는 정보를 제공한 경우 몇 개의 파티션만 얻거나 다른 고객과 공유하는 서비스 풀에 넣을 수도 있습니다.
고객이 나타나기를 기다리는 동안 다양한 서비스 인스턴스 또는 복제본을 실행하지 않습니다.
고객이 떠난 경우 서비스에서 해당 정보를 제거하는 작업은 관리자에서 만든 해당 서비스 또는 애플리케이션을 삭제하는 것만큼 간단합니다.

다음 단계

Service Fabric 개념에 대한 자세한 내용은 다음 문서를 참조하세요.

다음을 통해 공유