모바일 기능 용량 계획
마지막으로 수정된 항목: 2011-12-05
모바일 기능에 필요한 용량을 결정하는 작업은 모바일 기능 사용량을 예상하고, 현재 용량을 측정하고, 추가 용량을 계획하고, 핵심 성과 지표를 모니터링하는 반복적인 과정입니다. 아래 그림에는 용량 계획에서 수행하는 단계 및 각 단계에 적용되는 요인이 나와 있습니다.
모바일 기능 용량 계획 워크플로
.jpg "015701c0-77a2-4622-9c01-76576dea0140")
이 섹션에서는 모바일 기능 사용량을 예측할 때 고려해야 하는 요인에 대해 설명하고, 모바일 기능을 배포하는 데 필요한 용량의 규모를 결정하는 지침을 제공합니다.
사용량 및 성과 지표 모니터링에 대한 자세한 내용은 다음 항목을 참조하십시오.
서버 메모리 모니터링에 대한 자세한 내용은 서버 메모리 용량 제한 모니터링을 참조하십시오.
모바일 기능 사용량 모니터링에 대한 자세한 내용은 Mobility Service 사용량 모니터링을 참조하십시오.
IIS 추적 로그 파일 모니터링에 대한 자세한 내용은 IIS 요청 추적 로그 파일 모니터링을 참조하십시오.
모바일 기능을 모니터링하는 데 사용할 수 있는 성능 카운터에 대한 자세한 내용은 모바일 기능 성능 카운터를 참조하십시오.
높은 성능을 제공하도록 Mobility Service를 구성하는 방법에 대한 자세한 내용은 높은 성능을 위해 Mobility Service 구성을 참조하십시오.
용량에 영향을 주는 요인
Microsoft Lync Server 2010 Mobility Service를 실행하는 프런트 엔드 서버의 용량 계획에 영향을 주는 요인은 다음의 세 가지입니다.
사용자 모델
모바일 장치의 특성
사용 가능한 RAM
사용자 모델
이 섹션에서 설명하는 사용자 모델은 모바일 기능에 대한 용량 계획 측정 및 권장 사항의 기준이 됩니다.
사용자당 평균 대화 상대 수
| 대화 상대 범주 | 사용자당 평균 수 |
|---|---|
모든 대화 상대 |
80 |
엔터프라이즈 대화 상대 |
64 |
페더레이션 대화 상대 |
8 |
PIC 대화 상대 |
6 |
메일 그룹 |
2 |
가장 자주 대화하는 대화 상대 |
15 |
가장 최근에 대화한 대화 상대 |
10 |
사용자당 일별 작업
| 일별 작업 | 근무 시간 중의 수 | 근무 시간 외의 수 |
|---|---|---|
모바일 응용 프로그램 로그인 |
10 |
2 |
전화 통화(횟수) |
10 |
2 |
전화 통화(시간) |
통화당 2분 |
통화당 2분 |
회의 |
매주 1회 |
0 |
회의당 참가자 수 |
10명 미만 |
0 |
상태 메모 변경 |
1 |
0 |
대화 상대 카드 보기 |
6 |
1 |
대화 상대 목록 보기 |
9 |
1 |
대화 상대 목록 스크롤 |
3 |
0 |
GAL(전체 주소 목록) 검색 |
5* |
- |
수동 현재 상태 업데이트 |
0.5 |
0 |
대화 상대당 총 현재 상태 업데이트 횟수 |
6 |
0 |
착신 전환 |
0.5 |
0 |
IM(인스턴트 메시징) 세션(횟수) |
3 |
1 |
IM 세션(시간) |
세션당 6분/30초당 메시지 1개 |
세션당 6분/30초당 메시지 1개 |
일정 조회(Exchange 웹 서비스에 연결) |
11 |
3 |
* GAL 검색 횟수 = 매일 수동 검색 1회 + 보내는 인스턴트 메시지 및 발신 통화 중 절반에 대한 자동 검색. 즉, 1 + 2(인스턴트 메시지) + 2(통화) = 5입니다.
모바일 장치의 특성
모바일 기능이 지원되는 모바일 장치에서는 다양한 운영 체제를 실행합니다. 사용자가 다른 응용 프로그램으로 전환할 때 운영 체제에서 응용 프로그램을 관리하는 방식이 용량 계획에 영향을 줍니다. 용량 계획 시에는 운영 체제를 다음의 두 범주로 나눌 수 있습니다.
백그라운드 사용 가능 운영 체제 Apple 및 Windows Phone 모바일 장치에서는 사용자가 다른 모바일 응용 프로그램으로 전환하면 Lync 2010 모바일 응용 프로그램이 백그라운드로 전환되며 Lync Server 2010과의 연결이 끊어집니다. 모바일 응용 프로그램은 푸시 알림을 통해 또는 사용자가 수동으로 응용 프로그램을 포그라운드로 전달하는 경우 다시 활성화됩니다.
항상 연결된 운영 체제 Android 및 Nokia 모바일 장치에서는 사용자가 다른 모바일 응용 프로그램으로 전환해도 계속 로그인해 있으면 Lync 2010 모바일 응용 프로그램과 Lync Server 2010의 연결이 유지됩니다.
Android 및 Nokia 모바일 장치의 경우 사용자가 모바일 응용 프로그램을 사용하고 있지 않아도 서버와의 연결을 유지하므로 서버의 부하가 더 커집니다.
사용 가능한 메모리
이 섹션 뒷부분에서 설명하는 용량 규모 지정 지침을 참고하여 모바일 기능에 필요한 메모리 양을 정의할 수 있습니다. 서버에서 사용 가능한 실제 메모리의 양을 확인하려면 메모리, 사용 가능한 MB 성능 카운터를 사용합니다. 이 성능 카운터는 실행 중인 프로세스에 사용할 수 있는 실제 메모리의 양을 MB 단위로 표시합니다. 실행 중인 프로세스에 사용 가능한 메모리의 양이 총 실제 메모리의 5% 미만이면 서버의 메모리가 부족한 것이므로 페이징이 증가할 수 있습니다.
용량 규모 지정 지침
Mobility Service는 프런트 엔드 서버에서 메모리, 프로세서 리소스 및 네트워크 리소스를 추가로 사용합니다. 따라서 용량을 계획할 때는 모바일 기능을 로드하는 경우 프런트 엔드 풀에 대한 영향을 파악하고 모바일 기능 로드를 위해 하드웨어가 추가로 필요한지 여부를 결정해야 합니다. 아래 표에 나와 있는 규모 지정 예제를 참고하여 추가 하드웨어 필요 여부 및 필요한 하드웨어의 수를 결정할 수 있습니다.
표에 나와 있는 예제는 몇 가지 수식과 전제를 기반으로 하며, 이러한 수식과 전제에서는 다음 정의를 사용합니다.
AC: 사용자 모델에서 항상 연결된 상태로 유지되는 모바일 응용 프로그램의 수를 의미합니다.
BE: 사용자 모델에서 백그라운드 사용 가능 모바일 응용 프로그램의 수를 의미합니다.
예제에 사용되는 수식 및 전제는 다음과 같습니다.
TM(대상 메모리, MB) = 164 + (AC * 534 + BE * 400) / 1024.
TM은 필요한 최소 메모리입니다.
위에서 설명한 사용자 모델의 경우 프런트 엔드 풀에 대한 연결 수는 AC * 2 + BE * 0.20입니다.
서버에서 메모리에 대한 부담이 없는 경우에는 측정되는 메모리 수치가 더 높을 수 있습니다(끝점당 최대 1MB). 또한 A/V(음성/화상) 통화나 대화 상대의 수가 많은 등 보다 활발하게 사용되는 사용자 모델의 경우 대상 메모리 값이 더 높을 수 있습니다.
초당 생성되는 연결 수는 사용자 1천 명당 30개 이하입니다. 이 값은 하드웨어 부하 분산 장치의 연결 풀링 설정과 연결 유지 설정에 따라 달라집니다.
아래 표에는 사용자 모델에서 항상 연결되어 있는 50%의 사용자에 대해 용량 규모를 지정하는 예제가 나와 있습니다.
용량 규모 지정 예제
| 사용자 수 | 메모리(MB) | 평균 CPU | 최대 CPU |
|---|---|---|---|
1,000 |
620.05 |
1% |
2.5% |
2,000 |
1076.11 |
6% |
8% |
3,000 |
1532.16 |
14% |
18% |
4,000 |
1988.22 |
14% |
18% |
5,000 |
2444.27 |
14% |
18% |
시나리오 예제
다음 예제에서는 가상의 대기업 Contoso와, 서버 2대가 포함된 프런트 엔드 풀에 용량 규모 지정 지침이 적용되는 방식을 보여 줍니다.
대기업
Contoso에는 3개 풀에 7만 5천 명의 사용자가 배포되어 있으며 각 풀에는 프런트 엔드 서버가 4대 있습니다. Contoso에서는 3만 명의 사용자에 대해 Mobility Service를 사용하도록 설정하고자 합니다.
계획 단계 중에 Contoso 관리자는 다음 데이터를 파악했습니다.
각 프런트 엔드 서버의 사용 가능한 메모리는 3GB입니다.
CPU 사용률이 60% 미만입니다.
모든 사용자가 iPhone 또는 Windows Phone 모바일 장치를 사용합니다.
Contoso의 사용자 모델은 이 섹션 앞부분에서 설명한 용량 계획 사용자 모델과 비슷합니다.
각 서버에 필요한 최소 메모리는 164 + 2500 * 400 / 1024 = 1133MB입니다. 메모리는 필요에 따라 2.7GB까지 확보할 수 있으므로, 사용 가능한 메모리가 더 있는 경우에는 모바일 응용 프로그램에 더 많은 메모리를 할당할 수 있습니다. 어떤 상황에서든 Contoso는 프런트 엔드 서버 하드웨어를 업그레이드할 필요가 없습니다.
참고
모바일 기능의 CPU 사용률 목표는 평균 10%입니다. Contoso의 CPU 프로세서 시간이 서버 제한인 70%에 근접했으므로, Contoso는 해당 시간을 모니터링해야 합니다.
서버 2대가 포함된 프런트 엔드 풀
Contoso에서는 서버 2대가 포함된 프런트 엔드 풀에 8천 명의 사용자를 배포했으며, 모든 사용자에게 Mobility Service를 사용하도록 설정하고자 합니다.
계획 단계 중에 Contoso 관리자는 다음 데이터를 파악했습니다.
각 프런트 엔드 서버의 사용 가능한 메모리는 2.5GB입니다.
CPU 사용률이 60% 미만입니다.
모든 사용자가 Nokia 또는 Android 모바일 장치를 사용합니다.
Contoso의 사용자 모델은 이 섹션 앞부분에서 설명한 용량 계획 사용자 모델과 비슷합니다.
각 서버에 필요한 최소 메모리는 164 + 4000 * 534 / 1024 = 2242MB입니다. 이론상으로는 서버가 부하를 지원할 수 있지만, 두 서버 간에 장애 조치(failover)가 수행되는 경우에는 부하가 지원되지 않습니다. 또한 이 경우 모바일 기능 CPU 사용률이 10%를 초과하고 서버의 CPU 제한인 70%에 도달하게 됩니다.
이 시나리오에서는 풀에 서버를 추가하는 것이 좋습니다. 서버 추가 시의 새로운 부하 분산은 프런트 엔드 서버당 사용자 2667명(8000/3)이며 모바일 기능 사용을 위한 추가 비용(메모리)은 2667 * 534 / 1024 = 1390MB입니다.
서버 한 대를 추가하는 경우 특정 서버에서 오류가 발생하면 풀의 세 서버는 각각 1,300명의 사용자를 더 수락하며 이로 인해 600MB의 부하가 증가합니다. 이처럼 부하가 새롭게 분산되면 CPU 사용률도 서버 제한인 70% 미만으로 유지됩니다.