Windows Server AppFabric 캐싱 용량 계획 가이드

Jason Roth, Rama Ramani, Jaime Alva Bravo

2011년 3월

이 백서에서는 Windows Server AppFabric 캐싱 용량 계획을 위한 지침을 제공합니다.

1. 소개

2. AppFabric 캐싱 성능 평가

3. 용량 계획 방법

   1. 1단계: 병목 상태 이해 및 캐싱 후보 파악

   2. 2단계: 현재 작업 패턴 평가

   3. 3단계: 실제 인프라 및 하드웨어 리소스 이해

   4. 4단계: 모든 응용 프로그램에 대해 필요한 성능 SLA 완성

   5. 5단계: 적절한 AppFabric 기능 및 구성 설정 파악

4. 용량 계획 도구

5. 용량 계획 다음 단계

6. 진행 중인 캐싱 용량 요구 사항 모니터링

소개

Windows Server AppFabric 캐싱에서는 분산형 메모리 내 캐시 클러스터를 제공합니다. 이 백서에서는 Windows Server AppFabric 캐싱의 온-프레미스 배포를 위한 용량 계획 지침을 제공합니다.

Windows Server AppFabric 캐싱 아키텍처에 대한 자세한 설명은 설명서를 참조하십시오. 자세한 내용은 Windows Server AppFabric 캐싱 기능을 참조하십시오. 간단하게 설명하자면, AppFabric 캐시 클러스터는 캐시 호스트라고도 하는 하나 이상의 캐시 서버로 구성됩니다. 캐시는 여러 캐시 호스트에 분산되며 메모리 내에 저장됩니다.

참고

클라우드에서 캐싱을 사용할 수 있도록 하는 Windows Azure AppFabric 캐싱 릴리스도 있습니다. 이 백서에 나와 있는 메모리 요구 사항 측정과 관련한 일부 단계는 클라우드 기반 솔루션에도 적용되지만, 이 백서에서는 온-프레미스 캐시 클러스터 시나리오에 대해 중점적으로 설명합니다. Azure AppFabric 캐싱 기능 사용에 대한 자세한 내용은 Windows Azure AppFabric 캐싱을 참조하십시오.

이 백서의 정보는 Microsoft에서 고객과 함께 진행한 계획 작업을 기반으로 합니다. AppFabric 캐싱 고객이라면 누구나 자신의 시나리오에 필요한 서버 수를 Microsoft에 질문합니다. 대부분의 경우, Microsoft에서는 '시나리오에 따라 필요한 서버 수가 다르다'는 일반적인 답변부터 시작합니다. 그런 후에 각 시나리오의 다양한 세부 사항을 신속하게 드릴다운하여 작업을 시작하기에 적절한 서버 수를 파악한 다음 고객에게 안내합니다. 이 프로세스 중에 다음과 같은 보다 구체적인 질문이 제기될 수 있습니다.

• 응용 프로그램에 필요한 캐싱 메모리

• 단일 캐시 클러스터에서 사용해야 하는 컴퓨터 수

• 각 컴퓨터에 필요한 메모리 용량과 구성 방법

• 네트워크 대역폭이 캐시 클러스터 성능에 주는 영향

이 백서의 목표는 이러한 유형의 고객 논의에서 확인된 정보를 포착하여 각 고객이 용량 계획에 사용할 수 있는 방법을 제공하는 것입니다.

고객이 이 백서를 읽고 있다면 백서에 설명되어 있는 다양한 개발 단계 중 하나를 수행하는 중일 수 있습니다.

1. 분산 캐싱을 처음으로 사용하며 혼합된 작업, 성능 요구 사항 또는 서버 배포 토폴로지에 대한 드릴다운 데이터가 없는 상태일 경우, AppFabric 캐싱의 일부 성능 데이터를 먼저 확인할 수 있습니다.

2. AppFabric 캐싱의 기능 및 성능을 이미 조사했다면 이제 구체적인 시나리오와 상세한 요구 사항을 면밀하게 살펴볼 수 있습니다. 이 시점에서는 용량 계획의 세부 사항을 확인하게 됩니다.

3. 끝으로, 이미 프로덕션을 진행 중인 상태라면 성능 데이터 분석 방법을 파악하여 용량이 충분한지를 확인할 수 있습니다. 또한 AppFabric 캐시의 런타임 동작을 기반으로 하여 주요 지표와 모범 사례를 파악함으로써 향후 작업 증가량을 계획할 수도 있습니다.

이 백서의 내용은 이러한 단계를 순서대로 수행하도록 구성되어 있습니다. AppFabric 성능만 평가하려는 경우에는 Microsoft 파트너인 Grid Dynamics에서 작성한 포괄적인 백서를 참조할 수 있습니다. 여기서는 해당 백서에 나와 있는 데이터가 간편하게 확인할 수 있는 방식으로 그룹화되어 있으므로, 쉽게 평가를 수행하고 용량 계획 프로세스를 확인할 수 있습니다.

용량 계획 프로세스를 진행할 준비가 된 고객의 경우에는 각 시나리오에 적용할 수 있는 방법을 형식화하는 일련의 단계를 제공합니다.

캐시 클러스터를 테스트하거나 사용하는 경우에는 핵심 성과 지표 집합을 파악하여 용량 계획 프로세스의 유효성을 검사하면 용량이 적절한지를 확인할 수 있습니다. 이 백서에서는 몇 가지 모범 사례에 대해서도 설명합니다.

AppFabric 캐싱 성능 평가

Microsoft의 파트너인 Grid Dynamics에서는 최근 AppFabric 캐싱 성능에 대한 일련의 테스트를 완료했으며, 그 결과를 Windows Server AppFabric 캐시: 자세한 성능 및 확장성 데이터시트라는 백서에 게시했습니다.

각 테스트에서는 캐시 크기, 캐시 클러스터의 서버 수 등 특정 변수를 중점적으로 테스트했습니다. Grid Dynamics의 연구 결과를 사용하여 AppFabric 캐싱의 성능 및 확장성을 평가할 수 있습니다. 다양한 테스트 시나리오 및 토폴로지의 처리량 및 대기 시간 수치를 개별 응용 프로그램 요구 사항과 비교할 수 있습니다. 일반적으로 각 테스트에서는 성능에 대한 영향을 집중적으로 확인하기 위해 하나 또는 두 개의 매개 변수만 변경되었습니다. 전체 매개 변수 집합은 다음과 같습니다.

부하 패턴	'Get', 'Put', 'BulkGet', 'GetAndLock', 'PutAndUnlock' 작업 비율 등의 캐시 사용 패턴
캐시된 데이터 크기	테스트 중에 캐시에 저장된 데이터의 양
클러스터 크기	캐시 클러스터의 서버 수
개체 크기	serialization 후 캐시에 저장되는 개체의 크기
유형 복잡성	byte, string[] 등 캐시에 저장되는 다양한 .NET 개체 유형
보안	캐시 클러스터의 보안 설정

Grid Dynamics에서는 AppFabric 캐싱의 성능과 확장성을 확인하는 것 외에도, 고객이 고유한 데이터 및 작업으로 테스트를 반복할 수 있도록 테스트 도구를 제공했습니다. 이 도구는 고객의 특정 시나리오에 대한 캐싱 성능을 평가하기 위한 또 다른 옵션입니다.

전체 연구 내용과 해당 결론을 확인하는 것이 좋지만, 여기서는 이 백서의 나머지 부분에서 설명하는 모범 사례를 보여 주는 일부 연구 결과를 간략하게 설명합니다.

• 캐시 클러스터에 컴퓨터가 더 추가되면 AppFabric 캐싱은 선형 확장됩니다.

• 쓰기 비율이 높은 큰 캐시를 제외하면 캐시 크기는 큰 영향을 주지 않습니다. 관리되는 힙 크기가 큰 경우에는 여러 요인 중에서 많은 쓰기 작업이 .NET 가비지 수집에 보다 큰 부담을 줍니다.

• 높은 유형 복잡성은 serialization으로 인해 클라이언트 측 성능에만 영향을 줍니다.

• BulkGet 호출의 경우 네트워크 사용률이 향상됩니다. 직접 캐시 액세스가 프록시(ASP.NET, WCF)보다 훨씬 속도가 빠르지만, 이는 캐싱 성능이 아닌 중간 레이어의 성능 때문입니다.

• 낙관적 및 비관적 잠금은 성능이 비슷하므로, 응용 프로그램 디자인에 가장 적합한 기술을 사용해야 합니다. 충돌 비율이 낮아지면 대기 시간과 처리량이 향상됩니다.

• 캐시 클러스터 보안은 성능 저하를 유발하며, 기본적으로 사용하도록 설정됩니다. 보안을 해제하면 처리량을 최대화하고 대기 시간을 최소화할 수 있지만, 데이터의 중요성과 비즈니스 요구 사항으로 인해 보안을 해제하는 것이 적절하지 않을 수도 있습니다.

• 응용 프로그램 서버와 캐시 서버 간에 전용 네트워크를 사용하면 네트워크 병목 상태가 감소합니다.

Grid Dynamics 백서는 AppFabric 캐싱 평가를 시작하기에 적합한 출발점입니다. 이 백서에서는 용량 계획 프로세스를 통지하는 데 사용할 수 있는 원시 데이터와 관찰 패턴도 포함되어 있습니다.

용량 계획 방법

응용 프로그램에서 AppFabric 캐싱과 같은 분산형 메모리 내 캐시를 활용하는 것이 좋다고 결정하면 용량 계획 단계를 수행합니다. AppFabric 캐시 클러스터를 직접 테스트하여 일부 용량 계획 단계를 수행할 수도 있지만, 이러한 유형의 테스트를 수행하지 않고 예상치를 작성해야 할 수도 있습니다. 이 섹션에서는 이 사항에 대해 중점적으로 설명합니다. 아래에 나와 있는 단계를 통해 AppFabric 캐싱 요구 사항을 체계적으로 검토할 수 있습니다.

1. 병목 상태 이해 및 캐싱 후보 파악

2. 현재 작업 패턴 평가

3. 실제 인프라 및 하드웨어 리소스 이해

4. 모든 응용 프로그램에 대해 필요한 성능 SLA 완성

5. 적절한 AppFabric 기능 및 구성 설정 파악

이 백서에서는 샘플 온라인 상점 응용 프로그램의 요구 사항을 파악하여 이러한 단계의 예제를 제공합니다. 그러나 모든 .NET 응용 프로그램 유형에서 캐싱을 사용할 수 있으며, 여러 응용 프로그램이 같은 캐시 클러스터에 액세스하도록 할 수 있습니다. 이 시나리오에서는 각 응용 프로그램에 대해 아래 단계를 수행한 다음 결과를 집계하여 정확한 용량 예상치를 작성해야 합니다.

1단계: 병목 상태 이해 및 캐싱 후보 파악

먼저, 캐시할 데이터를 파악합니다. 이렇게 하려면 SQL Server 프로파일러, 성능 모니터, Visual Studio 테스트 등의 다양한 성능 분석 도구를 사용합니다. 이러한 도구는 자주 액세스하는 데이터베이스 개체 또는 웹 서비스에 대한 저속 호출을 식별할 수 있습니다. 이러한 백엔드 저장소에서 반환되는 데이터 집합은 캐싱 후보가 될 수 있습니다. 이 데이터를 임시로 캐시에 저장하면 성능을 개선하고 백엔드 데이터 저장소에 대한 부담을 줄일 수 있습니다.

캐싱 가능한 후보를 식별한 후에는 해당 개체를 세 가지 기본 범주, 즉 활동 데이터, 참조 데이터 및 리소스 데이터 중 하나로 분류하면 유용합니다. 아래에서 예제를 통해 이러한 분류에 대해 자세하게 설명합니다.

• 활동 데이터에는 개별 사용자와 관련된 읽기/쓰기 데이터가 포함되어 있습니다. 예를 들어 온라인 상점에서는 사용자의 장바구니가 활동 데이터입니다. 이는 사용자의 현재 세션에 적용되며, 자주 변경될 수 있습니다. 언제든지 장바구니를 사용할 수 있도록 유지 관리하는 것이 중요하기는 하지만, 장바구니는 백엔드 데이터베이스에서 반드시 영구적으로 저장할 필요는 없는 데이터입니다. 이와 같은 일시적인 특성으로 인해 활동 데이터는 캐싱의 논리적 후보가 됩니다.

• 참조 데이터는 여러 사용자 또는 여러 응용 프로그램 인스턴스에서 공유하는 읽기 전용 데이터로, 자주 액세스하지만 변경되는 빈도는 낮습니다. 예를 들어 온라인 상점 예제에서는 제품 카탈로그가 참조 데이터입니다. 카탈로그는 하루 이상의 기간에 대해 유효하지만, 여러 사용자가 수천 번 액세스할 수 있습니다. 이러한 유형의 데이터 역시 캐싱에 적합한 후보입니다. 특정 유형의 캐싱을 수행하지 않는 경우 제품 카탈로그를 보는 각 사용자가 데이터베이스에서 데이터에 액세스해야 합니다. 캐싱을 사용하면 반정적 데이터에 대한 반복 요청으로 인한 백엔드 데이터베이스의 부담을 줄일 수 있습니다. 이와 같은 영구적인 특성으로 인해 참조 데이터 역시 캐싱의 논리적 후보가 됩니다.

• 리소스 데이터는 여러 사용자가 공유하는 읽기/쓰기 데이터입니다. 예를 들어 지원 포럼에는 이러한 유형의 데이터가 포함되어 있습니다. 모든 사용자는 포럼 게시물에 대한 답변을 읽을 수 있습니다.

캐시되는 각 데이터 형식의 사용 패턴은 서로 다르므로, 데이터를 이러한 범주로 분류하면 유용할 수 있습니다. 예를 들어 개체가 참조 데이터로 식별되면 해당 개체가 읽기 전용 작업일 가능성이 높음을 자동으로 확인할 수 있습니다. 또한, 만료 정책(자주 변경되는 데이터의 경우 더 짧음)을 결정하는 데도 도움이 됩니다. 개발 시 이와 같은 논리적 분류를 통해 코드에 캡슐화할 수 있는 영역을 파악할 수 있습니다.

개별 개체에 대해 예상치를 작성한 다음 해당 데이터를 집계하는 것이 좋습니다. 다음 표에서는 이 단계에서 수집되는 정보의 예를 보여 줍니다.

캐시할 개체	캐싱 분류	영구 저장 위치
장바구니 개체	활동 데이터	없음
사용자 기본 설정 개체	활동 데이터	백엔드 데이터베이스
제품 카탈로그	참조 데이터	백엔드 데이터베이스
사용자 포럼 스레드	리소스 데이터	백엔드 데이터베이스

캐싱 후보 데이터를 파악할 때는 각 범주에서 캐시할 데이터를 찾을 필요가 없습니다. 응용 프로그램의 장바구니만 캐시해도 성능 및 확장성을 개선할 수 있습니다. 이 단계에서 중요한 점은 사용 가능한 정보를 사용하여 캐시할 가장 적합한 항목을 식별하는 것입니다.

2단계: 현재 작업 패턴 평가

캐시하기에 적합한 데이터를 결정한 후에는 응용 프로그램에서 현재 데이터에 액세스하는 방법 및 관련 작업 패턴을 이해해야 합니다. 이 단계가 완료되면 캐싱 메모리 요구 사항의 대략적인 예상치가 계산됩니다. 또한 이후 단계에서 중요한 데이터 액세스 및 사용 방법도 보다 확실하게 이해해야 합니다.

예를 들어 제품 카탈로그를 캐싱 후보로 지정하는 경우에는 응용 프로그램에서 카탈로그 데이터를 검색하는 시기와 이러한 요청의 빈도를 파악해야 합니다. 이전 단계를 통해 카탈로그 데이터는 참조 데이터이며 기본적으로 읽기 전용 작업임이 확인되었습니다. 서로 다른 개체에 대한 작업 패턴을 철저하게 파악하면 이후에 용량을 결정하는 데 도움이 됩니다. 이 단계에서 수행되는 작업을 좀 더 자세히 살펴보겠습니다.

다양한 방식을 통해 현재 데이터 액세스 패턴을 보다 명확하게 이해할 수 있습니다.

1. 코드를 철저하게 검토하여 데이터에 액세스하는 위치와 액세스 빈도를 확인합니다.

2. 메서드 호출 빈도와 관련 성능 데이터를 제공할 수 있는 코드 프로파일러를 사용합니다.

3. 특정 데이터 액세스 섹션에 대한 계측을 코드에 작성합니다. 데이터 액세스 시도와 데이터 작업의 관련 성능을 기록합니다.

4. SQL Server 프로파일러와 같은 데이터베이스 프로파일러를 사용하여 데이터베이스 작업의 횟수와 기간을 관찰합니다.

이러한 대부분의 기술을 이전 단계에서 사용하여 캐싱 대상 데이터를 결정할 수 있습니다. 그러나 이 단계의 사용자는 이후의 용량 계획 계산에 사용할 수 있는 보다 상세한 수치를 필요로 합니다.

이 평가 과정에서는 쓰기에 대한 읽기 비율을 파악해야 합니다. 읽기/쓰기 작업은 이후의 용량 관련 결정에 영향을 줄 수 있습니다. 예를 들어 쓰기 비율이 높은 작업의 경우 .NET 가비지 수집을 더 많이 트리거합니다. 여기에 대해서는 이후 단계에서 설명합니다.

또 다른 요인은 최대 부하 중의 읽기 및 쓰기 빈도입니다. 다음 표에서는 예제 장바구니 개체에 대해 이 단계에서 수집된 샘플 데이터를 보여 줍니다.

분석할 개체	장바구니
읽기 비율	50%
쓰기 비율	50%
초당 읽기 작업(최대값)	250
초당 쓰기 작업(최대값)	250

여기서도 동일한 분석을 각 개체 유형에 대해 수행해야 합니다. 각 개체 유형의 액세스 패턴과 부하 하의 초당 최대 읽기 및 쓰기 값은 서로 다릅니다.

캐싱 요구 사항을 이해하려면 지정된 시간에 캐시에서 각 유형의 최대 활성 개체 수에 대한 예상치를 구해야 합니다. 이 예상치는 개체 삽입 빈도 및 이러한 개체의 예상 수명의 평균입니다. 다음 예제를 통해 이러한 사항을 명확하게 이해할 수 있습니다.

ASP.NET 웹 응용 프로그램 예제에서는 운영 데이터에 동시 사용자가 25000명인 피크 시간이 표시될 수 있습니다. 각 사용자는 세션 상태 정보를 필요로 하므로, 이는 캐시된 개체가 25000개라는 의미입니다. 그러나 이러한 개체의 만료 시간이 30분으로 설정되었을 수 있습니다. 피크 시간 중에 운영 데이터는 시간당 5000명의 새 사용자가 추가됨을 표시할 수 있습니다. 이는 만료 기간인 30분 동안 2500명의 새 사용자가 데이터에 액세스한다는 의미입니다. 또한, 일부 사용자는 브라우저를 닫고 새 세션을 시작할 수 있습니다. 이 경우 사용자는 같지만 다른 세션을 사용합니다. 따라서 추가로 채울 경우 이를 고려해야 합니다. 마지막으로, 향후 6-12개월 동안 예상되는 사용자 증가 수를 계획해야 합니다. 최종적으로 캐시의 최대 활성 개체 수는 다음과 같이 계산됩니다.

분석할 개체:	장바구니
최대 동시 사용자	25000
만료 기간(30분) 중의 새 사용자	2500
새 브라우저 세션을 시작하는 기존 사용자	250
향후 예상 증가량(25%)	6940
총 활성 개체(최대값):	최대 35000개 활성 개체

만료 기간 등의 입력이 변경되는 경우에는 최대 부하 중에 캐시에 있는 만료되지 않은 개체의 수가 변경됩니다. 이는 계획 프로세스의 한 가지 예일 뿐이며, 개체 유형마다 계산에 적용되는 패턴과 변수는 달라집니다. 예를 들어 공유 제품 카탈로그가 하루 종일 유효한 경우, 하루 동안 캐시의 최대 제품 카탈로그 개체 수는 1개여야 합니다.

그러나 평균 개체 크기도 알고 있어야 캐시의 최대 개체 수를 활용할 수 있습니다. 이 정보는 기본적으로 파악하기가 어렵습니다. 장바구니 예제에서는 장바구니에 항목 하나를 추가하는 사용자도 있는 반면 10~20개 항목을 추가하는 사용자도 있습니다. 이와 같이 사용자별로 크게 다른 항목 수의 평균을 파악해야 합니다. 이 프로세스에서 사용되는 대부분의 수치와 같이 평균 역시 완벽할 수는 없습니다. 그러나 최종 결과는 단순한 추정치가 아니라, 신중하게 계산되며 캐시 클러스터에서 기준으로 사용할 수 있는 적절한 값입니다.

개체는 serialize된 형식으로 캐시에 저장됩니다. 따라서 평균 개체 크기를 파악하려면 serialize된 평균 개체 크기를 계산해야 합니다. AppFabric에서는 항목을 캐시에 저장하기 전에 NetDataContractSerializer 클래스를 serialization에 사용합니다. 평균 개체 크기를 확인하려면 개체를 serialize하는 응용 프로그램에 계측 코드를 추가하고 serialize된 크기를 기록합니다.

다음 코드 예제에서는 단일 개체의 평균 크기 예상치를 계산합니다. serialize되는 개체의 이름은 obj입니다. length 변수를 사용하여 길이를 기록합니다. NetDataContractSerializer를 사용하여 크기를 구할 수 없는 경우에는 BinaryFormatter가 대신 사용됩니다. 보다 쉽게 사용할 수 있도록 이 항목을 메서드에 래핑할 수 있습니다. 이 경우에는 obj가 매개 변수로 전달되며, 메서드에서는 length가 반환됩니다.

// requires following assembly references:
//
//using System.Xml;
//using System.IO;
//using System.Runtime.Serialization;
//using System.Runtime.Serialization.Formatters.Binary;
//
// Target object “obj”
//
long length = 0;

MemoryStream stream1 = new MemoryStream();
using (XmlDictionaryWriter writer = 
    XmlDictionaryWriter.CreateBinaryWriter(stream1))
{
    NetDataContractSerializer serializer = new NetDataContractSerializer();
    serializer.WriteObject(writer, obj);
    length = stream1.Length; 
}

if (length == 0)
{
    MemoryStream stream2 = new MemoryStream();
    BinaryFormatter bf = new BinaryFormatter();
    bf.Serialize(stream2, obj);
    length = stream2.Length;
}

참고

테스트 캐시 클러스터를 설치한 경우에는 캐시에 항목을 추가하고 Get-CacheStatistics Windows PowerShell 명령을 사용하여 캐시에 추가된 하나 이상의 개체 크기를 확인할 수 있습니다. 또는 캐시에 있는 여러 개체의 크기를 캐시의 개체 개수로 나눌 수도 있습니다. 코드 또는 테스트를 통해 예상치를 수집하도록 선택할 수 있습니다.

세션 상태에 대해 AppFabric 캐싱을 사용하려는 경우, ASP.NET 세션 상태에 대한 SQL Server 공급자가 항상 NetDataContractSerializer 대신 BinaryFormatter를 사용함을 이해해야 합니다. NetDataContractSerializer 클래스를 통해 serialize되는 개체의 크기가 BinaryFormatter를 사용하는 개체의 serialize된 크기보다 몇 배 더 큰 경우가 있습니다. 이는 SQL Server에서 세션 상태 개체의 크기를 확인하는 경우 중요합니다. 해당 크기를 통해서는 캐시에서도 개체 크기가 같을 것으로 예상할 수 없기 때문입니다. 해당 크기에 6을 곱하면 대략적인 예상치를 계산할 수 있습니다. 보다 정확한 예상치를 구하려면 세션 상태에 저장된 개체에 위의 코드를 사용합니다. 이 시점에서 수집된 데이터를 사용하면 총 메모리 요구 사항을 구하는 공식을 작성할 수 있습니다. 이 단계에서는 다음과 같은 부수적인 작업을 수행합니다.

1. 개체 유형(예: 장바구니 개체)을 명확하게 확인합니다.

2. 해당 개체에 대해 먼저 serialized된 평균 개체 크기를 구합니다.

3. 그런 다음 평균 크기에 500바이트를 더하여 캐싱 오버헤드를 추가합니다.

4. 해당 크기에 최대 활성 개체 수를 곱합니다. 그러면 해당 개체 유형에 대한 총 캐싱 메모리 요구 사항이 계산됩니다.

5. 내부 캐싱 구조에 대한 예상 오버헤드(5%)를 더합니다.

6. 식별된 각 개체 유형에 대해 이 단계를 반복합니다.

7. 결과를 집계하여 총 캐싱 메모리 요구 사항을 구합니다.

이 프로세스에서는 개체당 약 0.5KB의 오버헤드를 크기 예상치에 더해야 합니다. 또한, 캐시에서 메모리를 필요로 하는 다른 내부 데이터 구조도 있습니다. 영역과 태그, 알림에는 모두 관리를 위한 추가 메모리가 필요합니다. 예제 계산에서는 이러한 내부 구조용으로 총 메모리 값에 5%를 더합니다. 그러나 이러한 캐싱 기능을 사용하는 범위에 따라서는 값이 5%보다 클 수도 있고 작을 수도 있습니다.

이 시점에서는 특정 AppFabric 캐싱 기능, 즉 고가용성의 영향을 고려해야 합니다. 이 기능은 캐시된 항목의 복사본을 보조 서버에 만듭니다. 즉, 단일 캐시 서버가 다운되면 보조 캐시 서버가 작업을 계속하므로 데이터가 손실되지 않습니다. 고가용성을 사용하도록 선택하는 경우에는 메모리 예상치를 2배로 늘려야 합니다. 또한 Windows Server 2008 Enterprise 이상 버전을 사용해야 합니다. 고가용성 기능은 명명된 캐시 수준에서 작성됩니다. 즉, 동일한 클러스터에 명명된 캐시를 두 개 만들려는 경우 각 캐시에 대해 고가용성을 사용하지 않아도 됩니다. 응용 프로그램에서 고가용성을 사용하는 명명된 캐시와 사용하지 않는 명명된 캐시에 각각 항목을 자동으로 배치합니다. 따라서 메모리 리소스를 최대한 활용할 수 있습니다. 요약하자면, 고가용성을 사용하는 경우 해당 캐시의 메모리 요구 사항은 두 배가 되므로 고가용성 사용 여부 결정의 중요성을 이해해야 합니다.

아래에는 동일한 응용 프로그램에서 활동 데이터와 참조 데이터의 요구 사항을 평가하는 표가 예로 나와 있습니다. 시나리오에 따라 이 예상치를 개체 수준이나 응용 프로그램 수준에서 구할 수 있습니다. 각 수준에 따라 이 예에 열만 몇 개 더 추가하고 적절한 레이블을 지정하면 됩니다.

분석할 개체:	활동 데이터	참조 데이터
serialize되는 평균 개체 크기:	250KB	60KB
개체당 캐시 클러스터 오버헤드:	0.5KB	0.5KB
조정된 serialize되는 개체 평균 크기:	250.5KB	60.5KB
최대 활성 개체:	최대 35000개	최대 68000개
캐싱 메모리 요구 사항:	8.4GB	3.9GB
고가용성 사용 여부	16.8GB	아니요
내부 데이터 구조 오버헤드(5%):	0.8GB	0.2GB
총 메모리 요구 사항:	17.6GB	4.1GB

이러한 예상치를 집계하면 캐시 클러스터의 초기 메모리 요구 사항을 확인할 수 있습니다. 이 예에서 총 메모리 요구 사항은 21.7GB입니다. 이제 이 예상치를 사용하여 실제 인프라, SLA 요구 사항, AppFabric 캐시 구성 설정 등의 다른 고려 사항을 확인할 수 있습니다.

3단계: 실제 인프라 및 하드웨어 리소스 이해

실제 인프라 및 리소스 가용성을 이해해야 합니다. 이 과정에서 다음과 같은 몇 가지 일반 사항을 파악해야 합니다.

1. 실제 컴퓨터 또는 가상 컴퓨터를 구축할 수 있는지 여부

2. 기존 하드웨어를 사용하는 경우의 컴퓨터 구성(예: 8GB RAM, 쿼드 코어)

3. 캐시 클러스터를 응용 프로그램 서버와 같은 데이터 센터에 배치할지 여부

4. 네트워크 기능

캐시 서버에 가상 컴퓨터 사용을 고려 중인 경우에는 다양한 사항을 고려해야 합니다. 예를 들어 같은 실제 컴퓨터에 대해 여러 가상 컴퓨터를 사용하는 경우의 영향을 고려해야 합니다. 여러 가상 컴퓨터가 같은 네트워크 카드를 공유하면 네트워크 병목 상태가 발생할 가능성이 높아집니다. 또한, 같은 실제 컴퓨터에 있는 가상 컴퓨터인 기본 캐시 호스트와 보조 캐시 호스트 간에 고가용성을 설정할 수 있습니다. 이 경우 실제 컴퓨터가 다운되면 데이터 복사본이 남아 있지 않게 됩니다. 자세한 내용은 가상 컴퓨터에서 AppFabric 캐시를 실행하는 지침을 참조하십시오.

기존 컴퓨터의 경우에는 권장 사양이 없습니다. 그러나 대규모 캐시 클러스터의 경우에는 16GB RAM 쿼드 코어 컴퓨터가 효율적으로 작동합니다. 일반적으로, 정확한 실제 메모리 및 네트워크 부하의 양을 계획하는 것이 가장 중요한 고려 사항입니다.

실제 컴퓨터 및 가상 컴퓨터 둘 다에 대해, 캐시를 사용하는 웹 서버 또는 응용 프로그램에 대한 캐시 클러스터 위치를 확인해야 합니다. 캐시 클러스터가 별도의 데이터 센터에 있는 경우에는 이러한 데이터 센터 간의 대기 시간으로 인해 성능이 저하되지 않도록 해야 합니다. 이 단계에서는 캐시 서버에 대해 응용 프로그램 또는 웹 서버를 사용하는 경우가 있습니다. 이는 가능하기는 하지만 지원되지는 않습니다. 먼저, 이러한 컴퓨터에서 IIS 등의 서비스에 의해 리소스 사용이 급증하여 캐시 클러스터에 영향을 줄 수 있습니다. 둘째로, 캐싱 서비스에서는 캐시 클러스터가 전용 서버에 있다고 가정하므로 지정된 것보다 훨씬 많은 메모리를 사용할 가능성이 있습니다.

네트워크 기능의 경우에는 예상 네트워크 부하를 평가한 후에 사용 중인 인프라와 비교해야 합니다. 먼저, 각 캐시 서버에서 처리할 것으로 예상되는 데이터의 양과 네트워크 카드의 기능이 충분한지를 확인해야 합니다. 기능이 부족한 경우에는 추가 캐시 서버가 필요할 수 있습니다. 예를 들어 캐시되는 평균 개체 크기가 500.5KB이고 캐시 클러스터에서 초당 240개의 작업이 수행되는 시나리오를 가정해 보겠습니다. 단일 캐시 호스트를 사용하는 경우의 결과는 다음과 같습니다.

초당 개체 읽기/쓰기 횟수:	240
캐시 클러스터의 컴퓨터 수:	1
초당 컴퓨터별 캐시 작업 수:	240
평균 개체 크기:	500.5KB
초당 전송되는 데이터 크기:	240 * 500.5 = 117.3MBps

각 컴퓨터의 네트워크 카드가 1Gbps인 경우 최대 처리량은 약 119Mbps입니다. 계산된 값이 117.3MBps이므로 해당 단일 서버의 처리량이 모두 소진될 수 있습니다. 따라서 네트워크에서 병목 상태가 발생할 가능성이 훨씬 높아집니다. 그러나 캐시 클러스터에서 3대의 컴퓨터를 사용하는 경우에는 캐시 요청이 균일하게 분산되어 각 서버의 부하가 1/3로 감소합니다.

캐시 클러스터에 액세스하는 응용 프로그램 서버의 네트워크 사용률도 고려해야 합니다. 이러한 응용 프로그램 서버가 다른 시스템과 큰 볼륨의 데이터를 교환하는 경우에는 응용 프로그램 서버와 캐시 클러스터 간에 전용 네트워크를 만들지를 고려해야 합니다. 이렇게 하려면 이러한 용도로 각 응용 프로그램 서버에 추가 네트워크 카드를 탑재해야 합니다.

네트워크와 관련한 마지막 고려 사항은 네트워크가 전체 경로에서 요청 부하를 처리할 수 있는지 여부입니다. 각 캐시 서버에 1Gbps의 네트워크 카드가 있는 것만으로는 부족합니다. 스위치 및 네트워크의 기타 지점에서도 부하를 처리할 수 있어야 합니다. 관련 작업을 통해 이러한 요구 사항이 충족되도록 하십시오.

4단계: 모든 응용 프로그램에 대해 필요한 성능 SLA 완성

최종 구성을 결정하기 전에, 성능 및 안정성 SLA(서비스 수준 계약)를 비롯한 비즈니스 요구 사항도 이해해야 합니다. 실제로 이 단계는 캐시 클러스터의 수와 각 클러스터의 캐시 호스트 수에 대한 결정에 영향을 줍니다.

예를 들어 중요 업무용 응용 프로그램에서 캐시 클러스터를 사용하는 경우에는 해당 캐시 클러스터를 우선 순위가 낮은 다른 응용 프로그램에서 분리할 수 있습니다. 이와 같이 우선 순위가 낮은 응용 프로그램은 메모리, 네트워크 또는 CPU 리소스를 더 많이 사용할 가능성이 있으며, 이로 인해 중요 업무용 응용 프로그램의 성능이 저하될 수 있습니다.

다음은 이 결정에 영향을 주는 특정 요인입니다.

• 보안은 캐시 클러스터 수준에서 유지 관리됩니다. 캐시 클러스터 액세스 권한이 있는 사용자는 캐시 클러스터의 모든 데이터에 액세스할 가능성이 있습니다(해당 사용자가 캐시 이름과 요청 키를 알고 있다고 가정함). 각 데이터 형식에 대해 서로 다른 보안 설정이 필요한 경우에는 캐시 클러스터를 분리하는 것이 좋습니다. 자세한 내용은 보안 관리를 참조하십시오.

• 메모리가 상위 워터마크 수준에 도달하면 만료되지 않은 항목이 제거됩니다. 단일 캐시에 필요한 메모리의 양을 너무 적게 예측하면 클러스터의 모든 캐시에 영향을 줄 수 있습니다. 메모리에 대한 부담으로 인해 항목이 제거되는 경우에는 원인이 되는 캐시가 하나뿐이더라도 모든 캐시에서 제거가 수행됩니다. 제거가 불가능한 캐시를 만들면 이 문제를 다소 완화할 수는 있지만, 이 작업은 주의 깊게 수행해야 합니다. 자세한 내용은 만료 및 제거를 참조하십시오.

• 특정 지점에 대해 캐시 클러스터를 분리하면 관리가 보다 쉬워집니다. 서로 다른 100개의 캐시가 있는 경우 각 캐시에 대해 별도의 클러스터를 관리하기는 어렵습니다. 그러나 큰 캐시 2개가 있는 경우에는 별도의 캐시 클러스트를 지정하면 유용합니다. 이들 캐시를 각각 따로 관리, 확장 및 모니터링할 수 있기 때문입니다.

마지막으로, 일부 요구 사항에서는 대기 시간과 처리량을 고려할 수 있습니다. 이 결정 사항을 알리려면 Grid Dynamics 백서에서 지침과 테스트 결과를 참조하십시오. 예를 들어 캐시 클러스터에 대한 처리량 요구 사항을 Grid Dynamics 백서에 게시된 테스트 결과와 비교할 수 있습니다. 예를 들어 Grid Dynamics의 연구 결과를 통해 처리량 목표에 비해 서버 수가 너무 적음을 확인할 수 있습니다. 이 연구 결과는 각 사용자의 개체 유형, 개체 크기 및 실제/논리 인프라와 정확하게 일치하지 않을 수도 있습니다. 그러나 적절한 결정을 내리는 데 도움이 되는 검증된 테스트 결과를 확인할 수는 있습니다.

5단계: 적절한 AppFabric 기능 및 구성 설정 파악

프로세스의 이 부분에서는 AppFabric 캐싱의 특정 구성 설정과 AppFabric 캐시 클러스터의 아키텍처를 고려합니다. 적절한 실제 비즈니스 데이터를 모두 수집했다 하더라도, 이러한 AppFabric 캐싱 설정을 무시하면 부적절한 계획을 세울 가능성이 있습니다.

아래 표에는 다양한 AppFabric 캐싱 기능과 용량 계획을 위한 관련 고려 사항이 나와 있습니다.

영역	여러 영역을 만들 수 있지만, 각 영역은 단일 캐시 호스트에 존재합니다. 분산 캐시를 활용하려면 응용 프로그램에서 여러 영역을 사용해야 합니다. 영역을 지정하지 않는 모든 호출이 내부에서 기본 영역을 자동으로 사용하는 것은 아닙니다. 캐시 클러스터의 각 캐시 호스트는 가장 큰 영역의 최대 크기를 호스팅할 수 있어야 합니다.
알림	캐시는 알림을 사용하도록 설정할 수 있으며, 캐시 클라이언트는 이러한 알림을 받을 수 있습니다. 이로 인해 서버 측에 네트워크 트래픽과 프로세서 사용률이 추가됩니다. 그로 인한 효과는 알림 간격과 보낸 알림 수에 따라 달라집니다. 매우 짧은 간격 동안 알림 수가 많으면 성능 및 확장성에 영향을 줄 수 있습니다. 이러한 영향을 측정하는 명확한 지침은 없으므로, 테스트 중에 영향을 관찰해야 합니다.
로컬 캐시	로컬 캐시는 클라이언트와 서버 둘 다에서 개체를 캐시하여 성능을 향상시킵니다. 로컬 캐시를 사용할 때는 클라이언트 컴퓨터에 대한 메모리 영향을 고려해야 합니다. 이 기능은 서버 측의 메모리에 대한 용량 계획에는 영향을 주지 않습니다. 로컬로 캐시되는 모든 항목은 서버에도 있기 때문입니다. 그러나 로컬 캐시를 무효화하는 데 알림을 사용하는 경우에는 서버 측에서 알림 처리에 의해 영향을 받을 수 있습니다.
클라이언트 측 응용 프로그램 디자인 및 구성	클라이언트 측 응용 프로그램 디자인은 전체 성능에 영향을 줄 수 있습니다. 예를 들어 DataCacheFactory 개체는 각 호출에 대해 다시 만드는 대신 한 번 만들어서 다시 사용할 수 있도록 저장해야 합니다. 또한 DataCacheFactory 개체를 스레드당 하나씩 만들어서 활용할 수도 있습니다. 여러 스레드에 대해 단일 DataCacheFactory 개체를 공유하는 경우에는 MaxConnectionsToServer 설정을 높일 수도 있습니다. 이렇게 하면 DataCacheFactory당 캐시 서버에 대한 연결 수가 증가합니다.
고가용성	앞서 설명한 것처럼, 고가용성을 사용하는 캐시의 경우 계산된 메모리 요구 사항의 두 배에 해당하는 메모리가 필요합니다. 그러나 이 기능을 사용하는 경우 서버가 최소 3대 필요합니다. 한 서버가 다운되는 경우 나머지 두 서버가 오류 후 각 항목의 기본 및 보조 복사본을 지원할 수 있어야 합니다. 뿐만 아니라, 이 기능을 사용하는 경우 모든 서버에 Windows Server 2008 Enterprise 이상 버전이 필요합니다.
명명된 캐시	현재 명명된 캐시는 128개로 제한됩니다. 따라서 응용 프로그램에서 이 설정된 개수보다 명명된 캐시가 더 많이 필요한 경우에는 용량 계획 시 해당 사항을 결정해야 합니다. 즉, 둘 이상의 캐시 클러스터를 사용하거나 응용 프로그램에서 캐시를 더 적게 사용하도록 디자인해야 합니다. 명명된 캐시 내에 프로그래밍 방식으로 영역을 만드는 전략도 있습니다.
XML 구성 저장소	캐시 클러스터 구성 저장소에 대해 공유 네트워크 위치를 사용하는 경우에는 리드 호스트로 지정된 서버가 클러스터에 최소 3대 이상 있어야 합니다. 그 이유에 대한 자세한 내용은 캐시 서버 업데이트를 참조하십시오.

일반적으로, 계획 과정에서 이해해야 하는 가장 중요한 사항 중 하나는 각 캐시 호스트의 메모리 설정입니다. Get-CacheHostConfig Windows PowerShell 명령을 사용하여 각 캐시 호스트의 기본 메모리 설정을 확인할 수 있습니다.

참고

캐싱 Windows PowerShell 명령을 사용하는 방법에 대한 자세한 내용은 일반 캐시 클러스터 관리 작업을 참조하십시오.

아래 스크린샷에는 4GB RAM 컴퓨터에서 Get-CacheHostConfig 명령을 실행한 출력이 나와 있습니다.

기본적으로 지정된 서버에서 캐시에 대해 예약되는 메모리의 양은 총 RAM의 50%입니다. 이 예에서는 RAM의 절반에 해당하는 2GB가 예약됩니다. 나머지 메모리를 운영 체제와 서비스에서 사용할 수 있습니다. 메모리가 훨씬 더 많은 컴퓨터에서도 이 기본 설정을 유지하는 것이 좋습니다. 앞서 설명한 것처럼, 캐싱 서비스는 전용 컴퓨터에서 실행된다고 가정하며 캐시에 대해 할당된 것보다 훨씬 더 많은 메모리를 사용할 수 있습니다. 이 메모리 사용 중 일부분은 캐싱 서비스의 내부 디자인으로 인한 것이지만, .NET 메모리 관리 및 가비지 수집과 관련하여 사용되는 메모리도 있습니다. .NET 응용 프로그램에서 메모리가 해제되더라도, 프로세스 메모리에서 가비지 수집이 해제될 때까지 대기해야 합니다. 이 프로세스에서는 가비지 수집의 비결정적 특성을 설명하기 위한 실제 메모리 버퍼가 필요합니다.

가비지 수집의 영향을 이해하면, 쓰기 비율과 빈도가 높은 작업의 경우 가비지 수집 주기를 설명하는 데 보다 큰 메모리 버퍼가 필요함을 알 수 있습니다. 대부분 읽기 전용인 작업에서는 이 사항을 고려하지 않습니다. 이러한 작업에서는 일부 경우에 캐싱용으로 예약되는 메모리의 양을 늘릴 수 있습니다. 예를 들어 16GB 컴퓨터에서는 캐시 크기 설정에 대해 기본값인 8GB가 아닌 12GB를 예약할 수 있습니다. 그러면 운영 체제 및 서비스에 대해 4GB의 오버헤드가 제공됩니다. 여기서는 컴퓨터가 캐싱 서비스 전용이라고 가정합니다. 현재 지원되는 구성은 이 구성뿐입니다. 이 예에서는 예상 부하를 적용하여 이 메모리 구성을 테스트해야 합니다. 메모리를 너무 많이 할당하는 경우, 테스트를 수행하면 제거나 조정 등의 메모리 관련 문제가 발생하므로 이러한 실수를 확인할 수 있습니다. 자세한 내용은 서버 문제 해결(Windows Server AppFabric 캐싱)을 참조하십시오. 다음 예에서는 Set-CacheHostConfig 명령을 사용하여 Server1 서버에서 캐시 크기를 12GB로 설정합니다.

Set-CacheHostConfig -HostName Server1 -CachePort 22233 -CacheSize 12288

Get-CacheHostConfig 출력의 워터마크 값 항목도 관찰해야 합니다. LowWatermark 값의 기본값은 캐시 크기 설정의 70%입니다. 캐시된 메모리가 LowWatermark에 도달하면 캐싱 서비스에서는 이미 만료된 개체를 제거하기 시작합니다. 이러한 개체는 액세스할 수 없기 때문에 제거해도 문제가 없습니다.

HighWatermark 값의 기본값은 캐시 크기 설정의 90%입니다. HighWatermark 수준에서는 메모리가 다시 LowWatermark 수준으로 돌아갈 때까지 만료 여부에 관계없이 개체를 제거합니다. 이로 인해 성능이 저하될 가능성이 높으며, 사용자 환경에도 문제가 발생할 수 있습니다.

메모리가 HighWatermark에 도달할 가능성을 방지하기 위해, 캐시 사용을 LowWatermark 수준으로 계획하는 것이 좋습니다. 자세한 설명은 만료 및 제거를 참조하십시오.

팁

전체 가비지 수집 주기에서는 약간의 대기 시간이 발생할 수 있으며, 다시 시도 오류에서 이러한 현상을 자주 확인할 수 있습니다. 따라서 각 캐시 호스트에 대해 16GB 이하의 메모리를 지정하는 것이 좋습니다. 메모리가 16GB RAM을 초과하는 컴퓨터의 경우 전체 가비지 수집 주기에서 보다 오랜 시간 동안 수집이 일시 중지될 수 있습니다. 실제로 캐시 호스트당 더 많은 메모리를 사용하지 못하도록 하는 제한은 없습니다. 읽기 전용 항목이 많은 작업의 경우 전체 가비지 수집 주기가 수행되는 빈도가 낮습니다. 부하 테스트를 통해 이러한 작업을 가장 잘 확인할 수 있습니다.

이전 예에서는 총 캐싱 메모리 요구 사항의 예상치가 21.7GB로 계산되었습니다. 고가용성을 사용할 것이므로 서버가 3대 이상 있어야 합니다. 각 서버의 메모리는 16GB RAM이라고 가정합니다. 이 예에서는 각 서버에서 기본 캐시 크기 설정인 8GB를 유지합니다. 앞서 설명한 것처럼, 각 서버에서 사용 가능한 대상 메모리는 LowWatermark(70%)여야 합니다. 즉, 각 캐시 서버의 메모리 예상치는 5.6GB입니다. 아래 표에서는 이러한 요인을 사용하여 4대의 서버가 22.4GB의 캐싱 메모리를 제공하므로 요구 사항인 21.7GB를 충족함을 보여 줍니다.

총 메모리 요구 사항	21.7GB
초기 메모리(캐시 호스트)	16GB
캐시 크기 설정(캐시 호스트)	8GB
하위 워터마크(캐시 호스트)	70%
캐시 호스트당 조정된 메모리 대상	5.6GB
캐시 클러스터의 총 메모리(컴퓨터 3대)	5.6GB * 4개 서버 = 22.4

여기서도 Grid Dynamics 백서에 게시된 결과를 사용하여, 처리량 및 대기 시간 목표와 관련하여 이 예상치를 확인할 수 있습니다. 이러한 테스트 결과를 참조하여 캐시 서버를 더 추가하는 등 이 초기 예상치를 약간 수정할 수 있습니다. 여기서 중요한 점은 이와 같이 사용 가능한 리소스를 사용하여 적절한 결정을 내리는 것입니다.

용량 계획 도구

스프레드시트는 이전 섹션의 용량 계획 단계에 적합한 논리적 도구입니다. Microsoft에서 제공하는 샘플 스프레드시트를 여기에서 다운로드할 수 있습니다. 별표가 있는 항목은 각 사용자가 계획과 리소스를 기반으로 수정해야 하는 항목입니다. 나머지 계산은 스프레드시트에서 자동으로 수행됩니다.

스프레드시트의 첫 부분에서는 각 캐시 호스트에 대한 서버 구성이 지정됩니다. 계획 프로세스의 일부분으로 이 구성을 변경하고 최종 계산에서 차이를 관찰할 수 있습니다. 다음 스크린샷에 이 첫 번째 섹션이 나와 있습니다.

중요

기본 설치 값을 사용하는 경우가 아니면 각 캐시 호스트에서 Set-CacheHostConfig 명령을 사용하여 CacheSize 및 LowWatermark 설정을 적용해야 합니다.

두 번째 섹션에서는 서로 다른 개체 유형에 대해 예상치를 채울 수 있습니다. 예제 스프레드시트에서는 "활동 데이터" 및 "참조 데이터"에 대해 두 섹션만 사용됩니다. 그리고 일련의 빈 열이 제공됩니다. 계획에서 사용하는 세분성 수준에 따라 이러한 열의 이름을 바꿀 수 있습니다(개체, 범주, 응용 프로그램 등). 다음 스크린샷에 이 두 번째 섹션이 나와 있습니다.

세 번째 섹션에서는 네트워크 요구 사항의 예상치를 계산합니다. 평균 읽기/쓰기 개체 크기와 초당 최대 읽기/쓰기 작업을 입력합니다. 이 섹션에서는 해당 개체 유형에 대한 최대 네트워크 대역폭 요구 사항을 계산합니다. 이렇게 계산된 값을 사용하여 컴퓨터 및 네트워크 카드 그룹화를 통해 부하를 처리할 수 있는지 여부를 대략적으로 확인할 수 있습니다. 이전 섹션에서 설명한 것처럼, 네트워크 경로를 따른 대역폭을 확인할 수도 있습니다. 다음 스크린샷에 이 세 번째 섹션이 나와 있습니다.

마지막 섹션에서는 메모리 및 네트워크 섹션의 요구 사항이 집계됩니다. 그런 후에 첫 번째 섹션에서 지정된 컴퓨터 구성을 사용하여 서버 수 계산을 수행합니다. 필요한 경우 "추가 서버" 필드에서 이 계산된 총계를 늘릴 수 있습니다. 예를 들어 서버가 두 개만 필요하도록 계산에서 지정한 경우에는 고가용성을 적절하게 지원하기 위해 최종 총계에 서버를 하나 더 추가할 수 있습니다. 다음 스크린샷에 이 마지막 섹션이 나와 있습니다.

참고

위의 스크린샷에서는 이 백서에 나와 있는 예제와 비슷한 수치가 사용되지만 예상 서버는 4개가 아닌 3개입니다. 그 이유는, 이 사용자 지정 설정을 보여 주기 위해 스프레드시트에서 Cache Size Setting(Set-CacheHostConfig) 값이 12 GB로 설정되기 때문입니다. 이 값을 8 GB로 변경하면 이 백서의 이전 섹션에 나와 있는 것과 유사한 결과를 얻을 수 있습니다.

용량 계획 다음 단계

이전 섹션에서는 캐시된 클러스터의 수, 각 클러스터의 캐시 호스트 수, 그리고 이러한 캐시 호스트의 구성에 대한 초기 예상치를 결정하는 방법을 설명했습니다. 그러나 이러한 예상치는 테스트 및 진행 중인 모니터링에 따라 변경될 수 있다는 점을 염두에 두어야 합니다.

이 계획에 따라 AppFabric 캐싱을 사용하도록 결정하는 경우에는 개념 증명을 작성하여 솔루션에서 AppFabric 캐싱이 작동하는 방법을 파악할 수 있습니다. 그 이후에는 테스트 캐시 클러스터를 설치하여 사용자 환경에서 테스트를 실행할 수 있습니다. 테스트 결과에 따라 용량, 성능 및 확장성 요구 사항을 충족하기 위해 구성을 더 변경할 수 있습니다. 다음 섹션에서는 테스트와 프로덕션 중에 확인할 수 있으며 진행 상태에 있는 특정 메트릭에 대해 설명합니다.

진행 중인 캐싱 용량 요구 사항 모니터링

캐싱 용량 계획에서는 정확한 수치를 계산하지는 않습니다. 최종적으로 계산되는 대부분의 수치는 예상치 그 자체입니다. 또한, 응용 프로그램 사용과 패턴도 시간에 따라 변경될 수 있습니다. 따라서 성과 지표를 모니터링하여 캐시 클러스터가 용량 요구 사항을 충족하는지 확인해야 합니다. 성공적인 용량 계획은 테스트 및 프로덕션 환경에서 계속되는 진행 상태의 프로세스입니다.

지속적으로 용량을 모니터링하려면 성능 모니터 도구를 사용하는 것이 가장 좋습니다. 각 캐시 호스트에서 다음 카운터를 모니터링하는 것이 좋습니다.

모니터링 범주	성능 모니터 카운터
메모리	AppFabric Caching:Host\Total Data Size Bytes AppFabric Caching:Host\Total Evicted Objects AppFabric Caching:Host\Total Eviction Runs AppFabric Caching:Host\Total Memory Evicted AppFabric Caching:Host\Total Object Count .NET CLR Memory(DistributedCacheService)\# Gen 0 Collections .NET CLR Memory(DistributedCacheService)\# Gen 1 Collections .NET CLR Memory(DistributedCacheService)\# Gen 2 Collections .NET CLR Memory(DistributedCacheService)\# of Pinned Objects .NET CLR Memory(DistributedCacheService)\% Time in GC .NET CLR Memory(DistributedCacheService)\Large Object Heap size .NET CLR Memory(DistributedCacheService)\Gen 0 heap size .NET CLR Memory(DistributedCacheService)\Gen 1 heap size .NET CLR Memory(DistributedCacheService)\Gen 2 heap size Memory\Available MBytes
네트워크	Network Interface(*)\Bytes Received/sec Network Interface(*)\Bytes Sent/sec Network Interface(*)\Current Bandwidth
CPU	Process(DistributedCacheService)\% Processor Time Process(DistributedCacheService)\Thread Count Process(DistributedCacheService)\Working Set Processor(_Total)\% Processor Time
처리량	AppFabric Caching:Host\Total Client Requests AppFabric Caching:Host\Total Client Requests /sec AppFabric Caching:Host\Total Get Requests AppFabric Caching:Host\Total Get Requests /sec AppFabric Caching:Host\Total Get Requests AppFabric Caching:Host\Total Get Requests /sec AppFabric Caching:Host\Total GetAndLock Requests AppFabric Caching:Host\Total GetAndLock Requests /sec AppFabric Caching:Host\Total Read Requests AppFabric Caching:Host\Total Read Requests /sec AppFabric Caching:Host\Total Write Operations AppFabric Caching:Host\Total Write Operations /sec
기타	AppFabric Caching:Host\Cache Miss Percentage AppFabric Caching:Host\Total Expired Objects AppFabric Caching:Host\Total Notification Delivered

여기에 나와 있는 카운터의 대부분은 용량 계획 프로세스에 직접적으로 연결됩니다. 예를 들어 메모리 관련 카운터가 여러 개 있는데, 그 중 "Memory\Available Mbytes"에는 컴퓨터에 남아 있는 실제 메모리의 양을 MB 단위로 표시합니다. 이 카운터의 수치가 총 실제 메모리의 10% 아래로 내려가면 조정이 크게 변경됩니다. 자세한 내용은 정체 문제 해결을 참조하십시오. 기타 카운터는 캐싱 기능에 따라 달라집니다. "AppFabric Caching:Host\Total Eviction Runs"는 메모리를 제거하는 빈도를 나타냅니다. 메모리 수준이 상위 워터마크를 초과하면 이 카운터는 메모리가 최저 워터마크로 돌아가는 동안 이러한 제거 실행을 가리킵니다. 마찬가지로, 기타 카운터는 이 백서의 이전 섹션에 나와 있는 용량 계획 검토 프로세스와 연관됩니다.

서비스용 프로세스 카운터인 DistributedCacheService와 컴퓨터용 Processor 카운터도 캡처됩니다. 프로세서 사용률이 높으면 캐시 클러스터 성능이 저하될 수 있습니다. 프로세서 사용률이 높은 기간이 검색되는 경우에는 해당 기간이 캐싱 서비스(DistributedCacheService.exe) 또는 컴퓨터의 기타 프로세스와 관련되어 있는지 여부를 파악해야 합니다.

성능 모니터 도구 외에도, AppFabric과 함께 설치되는 Windows PowerShell 명령을 사용할 수 있습니다. 이러한 명령 중 대부분은 캐시 클러스터의 상태를 모니터링하는 데 사용할 수 있습니다. 자세한 내용은 상태 모니터링 도구 및 AppFabric 캐시의 로깅 및 카운터를 참조하십시오.

참고 항목

다른 리소스

Windows Server AppFabric 설치
MSDN Windows Server AppFabric 캐싱 설명서
AppFabric 캐싱용 프로그래밍 가이드
ASP.NET 세션 상태 공급자 구성
캐시 클러스터 구성 저장소 옵션
Windows Server AppFabric 캐싱 배포 및 관리 가이드
Windows Server AppFabric 및 Windows Azure AppFabric 링크 및 리소스

  2011-12-05