Service Fabric 애플리케이션의 용량 계획

이 문서에서는 Azure Service Fabric 애플리케이션을 실행하는 데 필요한 리소스(CPU, RAM, 디스크 스토리지) 양을 추정하는 방법을 배웁니다. 대부분의 경우 시간이 지나면서 리소스 요구 사항도 변합니다. 일반적으로 서비스를 개발/테스트하는 단계에서는 리소스가 적게 필요하고, 프로덕션 단계로 넘어가서 애플리케이션의 인기가 높아지면 더 많은 리소스가 필요하게 됩니다. 애플리케이션을 설계할 때에는 현재의 장기 요구 사항을 고려하고 고객의 높은 요구 사항에 따라 서비스를 확장할 수 있도록 선택을 내리도록 합니다.

서비스 패브릭 클러스터를 만들 때 클러스터를 구성할 VM(가상 머신) 종류를 결정합니다. 각 VM과 함께 제한된 양의 리소스가 CPU(코어 및 속도), 네트워크 대역폭, RAM 및 디스크 스토리지의 형태로 제공됩니다. 시간이 지나면서 서비스가 성장하면 더 많은 리소스를 제공하는 VM으로 업그레이드하거나 클러스터에 더 많은 VM을 추가할 수 있습니다. 후자를 선택하려면 클러스터에 동적으로 추가되는 새 VM을 활용할 수 있도록 처음부터 서비스를 설계해야 합니다.

일부 서비스는 VM 자체에서 데이터를 거의 또는 전혀 관리하지 않습니다. 따라서 이러한 서비스에 대한 용량 계획은 주로 성능에 초점을 맞춥니다. 즉, VM의 해당 CPU(코어 및 속도)를 선택해야 합니다. 또한 네트워크 대역폭을 고려해야 하고 네트워크 전송 빈도와 전송되는 데이터 양을 고려해야 합니다. 서비스 사용량이 증가하더라도 서비스가 원활하게 수행될 수 있도록 클러스터에 더 많은 VM을 추가하여 모든 VM에 네트워크 요청을 분산할 수 있습니다.

VM에서 많은 양의 데이터를 관리하는 서비스의 경우 용량 계획의 초점을 크기에 집중해야 합니다. 따라서 VM의 RAM 및 디스크 스토리지 용량을 신중하게 고려해야 합니다. Windows의 가상 메모리 관리 시스템은 디스크 공간을 애플리케이션 코드의 RAM처럼 표시합니다. 또한 서비스 패브릭 런타임에서는 핫 데이터만 메모리에 저장하고 콜드 데이터는 디스크로 이동하여 스마트 페이징을 제공합니다. 따라서 애플리케이션에서는 VM에 실제로 제공되는 것보다 더 많은 메모리를 사용할 수 있습니다. RAM이 늘어나면 VM에서 RAM에 더 많은 디스크 스토리지를 보관할 수 있기 때문에 성능이 향상됩니다. 선택한 VM에는 원하는 데이터를 VM에 저장하기에 충분히 큰 디스크가 있어야 합니다. 마찬가지로 VM에는 사용자가 원하는 성능을 제공하기에 충분한 RAM이 있어야 합니다. 시간이 지나면서 서비스의 데이터가 늘어나면 클러스터에 더 많은 VM을 추가하고 모든 VM에 데이터를 분할할 수 있습니다.

필요한 노드 수를 결정합니다.

서비스를 분할하여 서비스의 데이터를 확장할 수 있습니다. 분할에 대한 자세한 내용은 Service Fabric 분할을 참조하세요. 각 파티션은 단일 VM에 맞는 크기여야 합니다. 하지만 여러(작은) 파티션을 단일 VM에 배치할 수도 있습니다. 따라서 큰 파티션을 몇 개만 두는 것보다 작은 파티션을 여러 개 두는 것이 훨씬 유연합니다. 하지만 파티션이 늘어날수록 서비스 패브릭 오버헤드도 증가하기 때문에 파티션 간에 트랜잭션 처리된 작업을 수행할 수 없다는 단점이 있습니다. 뿐만 아니라 서비스 코드에서 여러 파티션의 데이터에 자주 액세스해야 하는 경우 네트워크 트래픽 가능성이 있습니다. 서비스를 설계할 때에는 이러한 장단점을 신중하게 고려하여 효과적인 분할 전략을 세워야 합니다.

애플리케이션에 상태 저장 서비스가 하나 있는데 이 서비스의 저장 크기가 1년 후 DB_Size GB로 늘어날 것으로 예상된다고 가정해 봅시다. 만약 그 해에 성장세가 예상치를 뛰어넘으면 애플리케이션(및 파티션)을 추가할 생각입니다. 서비스에 대한 복제본 수를 결정하는 RF(복제 계수)는 총 DB_Size에 영향을 미칩니다. 모든 복제본에서 총 DB_Size는 복제 계수를 DB_Size에 곱한 값입니다. Node_Size는 서비스에 사용할 노드당 디스크 공간/RAM을 나타냅니다. 최상의 성능을 위해서는 DB_Size가 클러스터의 메모리에 맞아야 하고, VM의 RAM에 가까운 Node_Size를 선택해야 합니다. RAM 용량보다 큰 Node_Size를 할당하면 서비스 패브릭 런타임이 제공하는 페이징에 의존하게 됩니다. 따라서 전체 데이터가 핫 데이터로 간주될 경우(데이터가 페이징 인/페이징 아웃됨) 성능이 최적화되지 않을 수 있습니다. 그러나 데이터의 일부만 핫 데이터인 많은 서비스에서는 이 방식이 좀 더 비용 효과적입니다.

최대 성능을 얻기 위해 필요한 노드 수는 다음과 같이 계산할 수 있습니다.

Number of Nodes = (DB_Size * RF)/Node_Size

성장 고려

사용자 입장에서는 처음 시작할 DB_Size와 향후 예상되는 DB_Size 성장 추정치를 기반으로 노드 수를 계산하고 싶을 것입니다. 그런 다음 서비스가 성장하는 만큼 노드 수를 늘려서 노드 수를 과도하게 프로비전하는 일이 없도록 하고 싶을 것입니다. 하지만 파티션 수는 최대 성장 속도에서 서비스를 실행할 때 필요한 노드 수를 기반으로 해야 합니다.

모든 예기치 않은 스파이크 또는 오류(예: 일부 VM이 작동 중단됨)를 처리할 수 있도록 언제든지 추가 컴퓨터를 사용할 수 있게 준비하는 것이 좋습니다. 예비 용량은 고객의 스파이크 예상치에 따라 결정되겠지만, 처음에는 약간의 예비 VM(5-10%)으로 시작하는 것이 좋습니다.

위에서는 상태 저장 서비스가 하나라고 간주합니다. 상태 저장 서비스가 여러 개 있으면 다른 서비스와 관련된 DB_Size를 방정식에 추가해야 합니다. 또는 각 상태 저장 서비스에 대해 별도로 노드 수를 계산할 수 있습니다. 분산되지 않은 복제본 또는 파티션이 서비스 내에 존재할 수 있습니다. 파티션이 다른 파티션보다 더 많은 데이터를 포함할 수도 있습니다. 분할에 대한 자세한 내용은 모범 사례의 분할 문서을 참조하세요. 하지만 위의 방정식은 서비스 패브릭이 최적화된 방식으로 복제본을 여러 노드에 분산시키므로 어떤 파티션 및 복제본에도 관계없이 적용됩니다.

비용 계산을 위한 스프레드시트 사용

이제 공식에 실제 숫자를 대입해 보겠습니다. 예제 스프레드시트는 세 가지 유형의 데이터 개체가 포함된 애플리케이션의 용량을 계획하는 방법을 보여줍니다. 각 개체에 대해 크기 그리고 예상되는 개체 수를 추정합니다. 또한 각 개체 유형에 대해 원하는 복제본 수를 선택합니다. 스프레드시트가 클러스터에 저장될 총 메모리 양을 계산해줍니다.

그런 다음 VM 크기와 월간 비용을 입력합니다. 스프레드시트에서는 이 VM을 기반으로 노드와 물리적으로 맞추기 위해 데이터를 분할하는 데 사용해야 하는 최소 파티션 수를 알려줍니다. 애플리케이션의 특정 계산 및 네트워크 트래픽 요구 사항을 수용할 수 있도록 파티션 수를 많이 늘리고 싶은 분들도 있을 것입니다. 스프레드시트에서는 사용자 프로필 개체를 관리하는 파티션 수를 1~6개로 늘려가면서 보여줍니다.

이제 이 모든 정보를 기반으로, 파티션 및 복제본 수를 원하는 만큼 두고 모든 데이터를 26노드 클러스터에 물리적으로 저장할 수 있다는 정보가 스프레드시트에 제공됩니다. 그러나 이 클러스터는 밀도가 높기 때문에 노드 장애 및 업그레이드를 대비하여 노드를 좀 더 추가해야 할 수도 있습니다. 또한 노드 수가 57개를 초과하면 빈 노드만 남게 되므로 더 이상의 가치가 없다는 정보가 스프레드시트에 제공됩니다. 마찬가지로, 노드 장애 및 업그레이드를 대비하여 위의 57노드를 선택하는 분들도 있을 것입니다. 애플리케이션의 특정 요구에 맞게 스프레드시트를 조정할 수 있습니다.

다음 단계

서비스 분할에 대한 자세한 내용은 Service Fabric 서비스의 분할을 참조하세요.