서비스 패브릭 클러스터 용량 계획 고려 사항
클러스터 용량 계획은 모든 Service Fabric 프로덕션 환경에 중요합니다. 고려해야 할 주요 사항은 다음과 같습니다.
클러스터 노드 형식의 초기 수와 속성
각 노드 형식의 내구성 수준은 Azure 인프라 내에서 Service Fabric VM 권한을 결정합니다.
클러스터의 안정성 수준은 Service Fabric 시스템 서비스의 안정성 및 전체 클러스터 기능을 결정합니다.
이 문서에서는 해당 각 영역에 관한 중요한 의사 결정 사항을 안내합니다.
클러스터 노드 형식의 초기 수와 속성
클러스터에 있는 노드(가상 머신) 세트의 크기, 번호 및 속성이 노드 형식에 정의됩니다. Service Fabric 클러스터에 정의된 모든 노드 형식은 가상 머신 확장 집합에 매핑됩니다.
각 노드 형식은 고유한 확장 집합이므로, 독립적으로 스케일 업 또는 다운하고 다른 포트의 세트를 열며 용량 메트릭이 서로 다릅니다. 노드 형식과 가상 머신 확장 집합 사이의 관계에 관한 자세한 내용은 Service Fabric 클러스터 노드 형식을 참조하세요.
각 클러스터에는 Service Fabric 플랫폼 기능을 제공하는 중요한 시스템 서비스를 실행하는 하나의 주 노드 형식이 필요합니다. 주 노드 형식을 사용하여 애플리케이션을 실행할 수도 있지만, 실행 중인 시스템 서비스에만 사용하는 것이 좋습니다.
주 노드가 아닌 노드 유형은 애플리케이션 역할(예: 프런트 엔드 및 백 엔드 서비스)을 정의하고 클러스터 내에서 서비스를 물리적으로 격리하는 데 사용할 수 있습니다. Service Fabric 클러스터에는 주 노드가 아닌 노드 유형이 0개 이상 있을 수 있습니다.
주 노드 형식은 Azure Resource Manager 배포 템플릿의 노드 형식 정의에 있는 isPrimary 특성을 사용하여 구성합니다. 노드 형식 속성의 전체 목록은 NodeTypeDescription 개체를 참조하세요. 사용 예제를 보려면 Service Fabric 클러스터 샘플에서 AzureDeploy.json 파일을 열고 페이지에서 찾기에서 nodeTypes 개체를 검색합니다.
노드 형식 계획 고려 사항
초기 노드 유형의 수는 클러스터의 목적 및 클러스터에서 실행되는 애플리케이션과 서비스에 따라 다릅니다. 다음 질문을 살펴보세요.
애플리케이션이 여러 서비스를 보유하고 해당 서비스 중 일부를 공용 또는 인터넷에 연결해야 하나요?
일반적인 애플리케이션은 클라이언트에서 입력을 받는 프런트 엔드 게이트웨이 서비스 및 프런트 엔드 서비스와 통신하는 하나 이상의 백 엔드 서비스를 포함하며, 프런트 엔드 서비스와 백 엔드 서비스 사이에 개별 네트워킹이 있습니다. 일반적으로 이 경우에는 세 개의 노드 유형이 필요합니다. 즉, 주 노드 유형 하나와 주 노드가 아닌 노드 유형 두 개(프런트 엔드 및 백 엔드 서비스에 각각 하나씩)입니다.
애플리케이션을 구성하는 서비스에는 더 큰 RAM 또는 더 높은 CPU 주기와 같이 서로 다른 인프라 요구 사항이 있나요?
프런트 엔드 서비스는 인터넷에 개방된 포트가 있는 작은 VM(D2와 같은 VM 크기)에서 종종 실행할 수 있습니다. 계산 집약적인 백 엔드 서비스는 인터넷에 연결되지 않은 큰 VM(D4, D6, D15와 같은 VM 크기)에서 실행해야 할 수도 있습니다. 해당 서비스에 서로 다른 노드 형식을 정의하면 기본 Service Fabric VM을 더 효율적이고 안전하게 사용할 수 있으며 독립적으로 스케일링할 수 있습니다. 필요한 리소스의 양을 예측하는 방법에 관한 자세한 내용은 Service Fabric 애플리케이션의 용량 계획을 참조하세요.
애플리케이션 서비스를 100개가 넘는 노드로 스케일 아웃해야 하나요?
단일 노드 형식은 Service Fabric 애플리케이션의 가상 머신 확장 집합당 100개가 넘는 노드로 안정되게 스케일링할 수 없습니다. 100개가 넘는 노드를 실행하려면 추가 가상 머신 확장 집합(따라서 추가 노드 형식)이 필요합니다.
클러스터의 범위가 가용성 영역에 걸쳐 있나요?
Service Fabric에서는 특정 영역에 고정된 노드 형식을 배포하여 가용성 영역에 걸쳐 있는 클러스터를 지원하므로, 애플리케이션의 고가용성을 보장합니다. 가용성 영역에는 추가 노드 형식 계획 및 최소 요구 사항이 있어야 합니다. 자세한 내용은 가용성 영역에서 주 노드 유형을 확장하기 위한 토폴로지를 참조하세요.
클러스터의 초기 생성에 사용할 노드 유형의 수와 속성을 결정할 때, 클러스터가 배포되고 나면 항상 주 노드가 아닌 노드 유형을 추가, 수정 또는 제거할 수 있습니다. 실행 중인 클러스터에서 주 노드 유형을 확장 또는 축소할 수도 있지만 그러기 위해서는 새 노드 유형을 만들고 워크로드를 이동한 다음, 원래 주 노드 유형을 제거해야 합니다.
노드 형식 속성의 추가 고려 사항은 Azure 인프라 내에서 노드 형식의 VM이 갖는 권한을 결정하는 내구성 수준입니다. 클러스터에 대해 선택하는 VM 크기와 개별 노드 형식에 할당하는 인스턴스 수를 사용하면 다음에 설명된 대로 각 노드 형식에 적합한 내구성 계층을 결정하는 데 도움이 됩니다.
클러스터의 내구성 특성
내구성 수준은 Service Fabric VM이 기본 Azure 인프라에 대해 갖는 권한을 지정합니다. 이 권한을 사용하면 Service Fabric이 Service Fabric 시스템 서비스 및 상태 저장 서비스에 대한 쿼럼 요구 사항에 영향을 주는 VM 수준 인프라 요청(예: 다시 부팅, 이미지로 다시 설치, 또는 마이그레이션 등)을 일시 중지할 수 있습니다.
Important
내구성 수준은 노드 형식별로 설정됩니다. 지정되지 않은 경우 Bronze 계층이 사용됩니다. 프로덕션 워크로드에는 VM 수준 인프라 요청으로 인한 데이터 손실을 방지하기 위해 Silver 또는 Gold의 내구성 수준이 필요합니다.
아래 표에는 Service Fabric 내구성 계층, 요구 사항, 어포던스가 나열되어 있습니다.
| 내구성 계층 | 필요한 최소 VM 수 | 지원되는 VM 크기 | 가상 머신 확장 집합의 업데이트 | Azure에서 시작되는 업데이트 및 유지 관리 |
|---|---|---|---|---|
| 금 | 5 | 단일 고객 전용 전체 노드 크기 - 사용 가능한 VM 크기 | Service Fabric 클러스터에서 승인될 때까지 지연될 수 있음 | 복제본이 이전 오류에서 복구될 수 있는 추가 시간을 허용하기 위해 업그레이드 도메인당 2시간 동안 일시 중지될 수 있음 |
| 은 | 5 | 최소 50GB의 로컬 SSD를 포함하는 단일 코어 이상의 VM | Service Fabric 클러스터에서 승인될 때까지 지연될 수 있음 | 상당한 기간 동안 지연될 수 없음 |
| 동 | 1 | 50GB 이상의 로컬 SSD를 포함하는 VM | Service Fabric 클러스터에 의해 지연되지 않음 | 상당한 기간 동안 지연될 수 없음 |
참고 항목
위에서 언급한 최소 VM 수는 각 내구성 수준에 필요한 요구 사항입니다. 해당 요구 사항을 충족하지 않는 기존 가상 머신 확장 집합을 만들거나 수정하지 못하게 하는 유효성 검사 기능이 마련되어 있습니다.
Warning
내구성 수준이 Bronze이면 자동 OS 이미지 업그레이드를 사용할 수 없습니다. Silver 이상의 내구성 수준에는 패치 오케스트레이션 애플리케이션(Azure가 아닌 호스트 클러스터에만 사용)이 권장되지 않지만, Service Fabric 업그레이드 도메인과 관련하여 Windows 업데이트를 자동화하는 유일한 옵션입니다.
Important
내구성 수준과 관계없이 가상 머신 확장 집합에서 할당 해제 작업을 실행하면 클러스터가 삭제됩니다.
동
Bronze 내구성으로 실행되는 노드 형식은 권한 없음이 됩니다. 즉, 상태 저장 워크로드에 영향을 주는 인프라 작업은 중지되거나 지연되지 않습니다. 브론즈 내구성은 상태 비저장 워크로드를 실행하는 노드 형식에만 사용해야 합니다. 프로덕션 워크로드의 경우 Silver 이상을 실행하는 것이 좋습니다.
실버 및 골드
스케일 인이 자주 수행될 것으로 예상되는 상태 저장 서비스를 호스트하는 모든 노드 형식과 프로세스를 간소화하기 위해 배포 작업을 지연하고 용량을 감소하려는 경우 실버나 골드 내구성을 사용합니다. 스케일 아웃 시나리오는 선택한 내구성 계층에 영향을 주지 않아야 합니다.
장점
- 스케일 인 작업에 필요한 단계 수가 줄어듭니다(노드 비활성화 및 Remove-ServiceFabricNodeState가 자동으로 호출됨).
- 가동 중인 VM 크기 변경 작업 및 Azure 인프라 작업으로 인한 데이터 손실 위험을 줄입니다.
단점
- 가상 머신 확장 집합과 기타 관련 Azure 리소스에 대한 배포 시간이 초과되거나, 클러스터 또는 인프라 수준에서 발생한 문제로 인해 완전히 차단될 수 있습니다.
- Azure 인프라 작업 중에 자동으로 수행되는 노드 비활성화로 인해 복제본 수명 주기 이벤트(예: 기본 스왑) 수가 증가합니다.
- Azure 플랫폼 소프트웨어 업데이트 또는 하드웨어 유지 관리 작업이 발생하는 기간 동안 노드를 서비스 불가능 상태로 유지합니다. 이러한 작업 중에는 노드 상태가 비활성화 중/사용 안 함으로 표시될 수 있습니다. 이로 인해 클러스터 용량이 일시적으로 감소하지만 클러스터 또는 애플리케이션의 가용성에는 영향을 주지 않아야 합니다.
실버 및 골드 내구성 노드 형식의 모범 사례
실버 또는 골드 내구성으로 노드 형식을 관리하는 데 관한 다음 권장 사항을 따르세요.
- 클러스터와 애플리케이션을 항상 정상 상태로 유지하고, 애플리케이션이 모든 서비스 복제본 수명 주기 이벤트(예: 빌드의 복제본에 문제가 있을 경우)에 제때에 응답하는지 확인하세요.
- VM 크기 변경(스케일 업/다운) 시 더 안전한 방법을 채택하세요. 가상 머신 확장 집합의 VM 크기를 변경하려면 신중한 계획과 주의가 필요합니다. 자세한 내용은 Service Fabric 노드 형식 스케일 업을 참조하세요.
- Gold 또는 Silver 내구성 수준이 활성화된 가상 머신 확장 집합의 노드 수는 최소 5개로 유지합니다. 이 임계값 아래로 스케일 인하면 클러스터가 오류 상태가 되며 제거된 노드의 상태(
Remove-ServiceFabricNodeState)를 수동으로 정리해야 합니다. - 내구성 수준이 Silver 또는 Gold인 각 가상 머신 확장 집합은 Service Fabric 클러스터에서 고유한 노드 형식에 매핑되어야 합니다. 여러 가상 머신 확장 집합을 단일 노드 형식에 매핑하면 Service Fabric 클러스터와 Azure 인프라 간의 조정이 제대로 작동하지 않습니다.
- 임의의 VM 인스턴스를 삭제하지 말고 항상 가상 머신 확장 집합 스케일 인 기능을 사용합니다. 임의의 VM 인스턴스를 삭제하면 업그레이드 도메인과 장애 도메인 전체에서 VM 인스턴스의 불균형 생성이 확산될 가능성이 있습니다. 이 불균형은 서비스 인스턴스/서비스 복제본 간에 부하를 적절하게 분산하는 시스템 기능에 부정적인 영향을 줄 수 있습니다.
- 자동 크기 조정을 사용하는 경우 한 번에 한 노드에서만 스케일 인(VM 인스턴스 제거) 작업이 수행되도록 규칙을 설정합니다. 한 번에 여러 인스턴스를 스케일 인하는 방식은 안전하지 않습니다.
- 주 노드 형식에서 VM을 삭제하거나 할당 해제하는 경우 전용 VM 수를 안정성 계층에 필요한 수 미만으로 줄여서는 안 됩니다. 이러한 작업은 내구성 수준이 Silver 또는 Gold인 확장 집합에서 무기한 차단됩니다.
내구성 수준 변경
특정 제약 조건 내에서 노드 형식 내구성 수준은 다음과 같이 조정할 수 있습니다.
- 내구성 수준이 실버 또는 골드인 노드 형식은 브론즈로 다운그레이드할 수 없습니다.
- 내구성 수준이 Gold인 노드 유형을 Silver로 다운그레이드하는 것은 지원되지 않습니다.
- Bronze에서 Silver 또는 Gold로 업그레이드하는 데 몇 시간이 걸릴 수 있습니다.
- 내구성 수준을 변경할 때는 가상 머신 확장 집합 리소스의 Service Fabric 확장 구성과 Service Fabric 클러스터 리소스의 노드 형식 정의 모두에서 업데이트해야 합니다. 이러한 값이 일치해야 합니다.
용량 계획 시 고려해야 할 또 다른 사항은 다음 섹션에 설명된 대로 시스템 서비스 및 전체 클러스터의 안정성을 결정하는 클러스터의 안정성 수준입니다.
클러스터의 안정성 특성
클러스터 안정성 수준에 따라 클러스터의 주 노드 형식에서 실행되는 시스템 서비스 복제본의 수가 결정됩니다. 복제본이 많을수록 시스템 서비스(따라서 클러스터 전체)가 더 안정적으로 됩니다.
Important
안정성 수준은 클러스터 수준에서 설정되며 주 노드 형식의 최소 노드 수를 결정합니다. 프로덕션 워크로드에는 실버(5개 이상의 노드) 이상의 안정성 수준이 필요합니다.
안정성 계층은 다음 값을 사용할 수 있습니다.
- 플래티넘 - 대상 복제본 세트 수가 9인 시스템 서비스를 실행합니다.
- 골드 - 대상 복제본 세트 수가 7인 시스템 서비스를 실행합니다.
- 실버 - 대상 복제본 세트 수가 5인 시스템 서비스를 실행합니다.
- 브론즈 - 대상 복제본 세트 수가 3인 시스템 서비스를 실행합니다.
안정성 계층 선택과 관련한 권장 사항은 다음과 같습니다. 또한 시드 노드 수는 안정성 계층의 최소 개수로 설정됩니다.
| 노드 수 | 안정성 계층 |
|---|---|
| 1 | reliabilityLevel 매개변수를 지정하지 마세요. 시스템에서 계산됩니다. |
| 3 | 동 |
| 5 또는 6 | 은 |
| 7 또는 8 | 금 |
| 9 이상 | 플래티넘 |
클러스터 크기(모든 노드 형식의 VM 인스턴스 합계)를 늘리거나 줄일 때는 클러스터의 안정성 계층을 업데이트해 보세요. 이렇게 하면 시스템 서비스 복제본 세트 수를 변경하는 데 필요한 클러스터 업그레이드를 트리거합니다. 노드를 추가하는 것처럼 클러스터를 다르게 변경하기 전에 진행 중인 업그레이드가 완료될 때까지 기다립니다. Service Fabric Explorer에서 또는 Get-ServiceFabricClusterUpgrade를 실행하여 업그레이드 진행률을 모니터링할 수 있습니다.
안정성을 위한 용량 계획
클러스터의 용량 요구 사항은 특정 워크로드와 안정성 요구 사항에 따라 결정됩니다. 이 섹션에서는 용량 계획을 시작하는 데 도움이 되는 일반 지침을 제공합니다.
가상 머신 크기 조정
프로덕션 워크로드의 경우 다음과 같은 VM 크기(SKU)를 사용하는 것이 좋습니다.
- 2개 이상의 코어.
- 최소 50GB 로컬 SSD. 그러나 Windows 컨테이너를 실행하는 워크로드와 같은 일부 워크로드에는 더 큰 디스크가 필요합니다.
기본적으로 로컬 SSD는 64GB로 구성됩니다. 클러스터 설정의 진단 섹션에 있는 MaxDiskQuotaInMB 설정에서 크기를 구성할 수 있습니다.
Azure에서 호스트되는 클러스터의 클러스터 설정을 조정하는 방법에 대한 지침은 Azure에서 클러스터 구성 업그레이드를 참조하세요.
Windows에서 호스트되는 독립 실행형 클러스터의 클러스터 설정을 조정하는 방법에 대한 지침은 독립 실행형 클러스터 구성 업그레이드를 참조하세요.
프로덕션 워크로드용으로 다른 VM 크기를 선택할 때 다음 제약 조건에 유의하세요.
- 표준 A0과 같은 부분/단일 코어 VM 크기는 지원되지 않습니다.
- A-시리즈 VM 크기는 성능상의 이유로 지원되지 않습니다.
- 우선 순위가 낮은 VM은 지원되지 않습니다.
- B 시리즈 버스트 가능 SKU는 지원되지 않습니다.
주 노드 유형
Azure의 프로덕션 워크로드에는 실버의 안정성 계층과 최소 5개의 주 노드(VM 인스턴스)가 필요합니다. 클러스터 주 노드 형식을 시스템 서비스 전용으로 지정하고 배치 제약 조건을 사용하여 보조 노드 형식에 애플리케이션을 배포하는 것이 좋습니다.
Azure의 테스트 워크로드는 최소 한 개 또는 세 개의 주 노드를 실행할 수 있습니다. 단일 노드 클러스터를 구성하려면 Resource Manager 템플릿에서 reliabilityLevel 설정이 생략되었는지 확인합니다(reliabilityLevel에 빈 문자열 값을 지정하는 것만으로는 충분하지 않음). Azure Portal을 통해 하나의 노드 클러스터 설정을 지정한 경우 구성이 자동으로 수행됩니다.
Warning
단일 노드 클러스터는 안정성이 없는 특별한 구성으로 실행되며 스케일 아웃은 지원되지 않습니다.
주 노드가 아닌 노드 유형
주 노드가 아닌 노드 유형의 최소 노드 수는 노드 유형의 특정 내구성 수준에 따라 다릅니다. 노드 형식에 대해 실행할 애플리케이션 또는 서비스의 복제본 수와 워크로드가 상태 저장인지 또는 상태 비저장인지에 따라 노드 수(및 내구성 수준)를 계획해야 합니다. 클러스터를 배포한 다음 언제든지 노드 형식의 VM 수를 늘리거나 줄일 수 있습니다.
상태 저장 워크로드
Service Fabric 신뢰할 수 있는 컬렉션 또는 신뢰할 수 있는 작업자를 사용하는 상태 저장 프로덕션 워크로드의 경우 최소 및 대상 복제본 수는 5개를 사용하는 것이 좋습니다. 각 장애 도메인 및 업그레이드 도메인에 1개의 복제본(복제본 세트 중)이 있으면 안정적입니다. 일반적으로 시스템 서비스에 설정된 안정성 수준을 상태 저장 서비스에 사용하는 복제본 수에 관한 지침으로 사용합니다.
상태 비저장 워크로드
상태 비저장 프로덕션 워크로드의 경우 지원되는 최소 주 노드가 아닌 노드 유형 크기는 쿼럼을 유지하기 위해 3개이지만, 노드 유형 크기는 5개를 사용하는 것이 좋습니다.
다음 단계
클러스터를 구성하기 전에 Not Allowed클러스터 업그레이드 정책을 검토하여 변경 불가능한 시스템 구성 설정으로 인해 나중에 클러스터를 다시 만들어야 하는 필요성을 줄입니다.
클러스터 계획에 관한 자세한 내용은 다음을 참조하세요.