Windows Administration

터미널 서비스를 통한 응용 프로그램 배포

Greg Shields

한 눈에 보기:

• RemoteApps의 이점
• 사용자에게 응용 프로그램 제공
• 터미널 서비스 구현 평가
• 사용자 만족도 제고

목차

저무는 데스크톱과 떠오르는 RemoteApp
웹에서 응용 프로그램 실행
데스크톱에서 응용 프로그램 실행
사용자 환경
성능 예측을 가능하게 하는 RemoteApp
선택은 여러분의 몫

터미널 서비스를 설치하고 사용하는 방법에 대한 자료는 인터넷과 가까운 서점에서 쉽게 구할 수 있습니다. 하지만 원격 응용 프로그램을 사용자에게 제공하는 최선의 방법에 대한 정보는 찾기가 어렵습니다. 약간의 노력만 들이면 필요한 일련의 응용 프로그램을 호스트하는 환경에 터미널 서버를 간단히 배포할 수 있지만 사용자의 요구에 맞게 터미널 서버를 배포하려면 추가로 고려해야 할 사항이 있습니다.

터미널 서버 관리자는 원격 응용 프로그램 인프라와 관련하여 몇 가지를 고려해 보아야 합니다. 응용 프로그램을 어떻게 배포할 것인가? 사용자에게 원격 데스크톱을 제공할 것인가, 아니면 TS RemoteApp를 제공할 것인가? 사용자가 정적 RDP(원격 데스크톱 프로토콜) 파일, 웹 페이지 또는 바탕 화면 바로 가기 중 무엇을 통해 응용 프로그램에 액세스할 것인가?

그리고 마지막으로 사용자가 터미널 서비스 응용 프로그램을 사용하는 환경을 평가할 방법도 생각해야 합니다. Windows Server 2008에서 터미널 서비스가 향상되면서 이러한 터미널 서버 배포 관련 질문에 대한 가장 바람직한 대답도 바뀌었습니다.

저무는 데스크톱과 떠오르는 RemoteApp

Windows Server 2008에서는 서비스와 기능이 대폭 확장되어 터미널 서비스 관리 부담이 대폭 해소되었습니다. 새로운 기능과 변경된 기능에 대해서는 TechNet Magazine 2008년 11월에 실린 Windows Server 2008의 새로운 기능에 대한 Joshua Schnoll의 칼럼("향상된 터미널 서비스로 프레젠테이션 가상화")에서 자세히 소개되었습니다. 그중에서도 사용자에게 전체 데스크톱이 아니라 개별 응용 프로그램을 배포하는 기능이 가장 주목할 만하다고 할 수 있습니다.

TS RemoteApp라고 하는 이러한 개별 응용 프로그램은 로컬 데스크톱에 직접 설치된 것처럼 사용자에게 표시됩니다. 사용자가 RemoteApp를 클릭하여 실행하면 로컬 컴퓨터에서 해당 응용 프로그램 자체만 나타나고 로컬 시스템이 아닌 시스템과 상호 작용하고 있음을 확연히 구분할 수 있는 추가적인 시작 표시줄이나 이중 바탕 화면이 표시되지 않습니다. TS Remote­App는 이러한 응용 프로그램을 로컬 데스크톱 환경의 일부처럼 보이도록 하기 때문에 구현 방법과 사용자의 요구 사항에 따라 전체 데스크톱을 배포하는 데에도 TS Remote­App가 탁월한 선택이 될 수 있습니다.

Windows Server 2008에서는 관리 도구에 있는 TS RemoteApp 관리자 콘솔을 사용하여 새 TS RemoteApp를 간단하게 만들 수 있습니다. 작업 창에서 RemoteApp 프로그램 추가 링크를 클릭하면 사용자에게 터미널 서버의 WMI(Windows Management Instrumentation) 저장소를 물어 서버에 이미 설치되어 있는 제공 가능한 응용 프로그램 목록을 식별하는 RemoteApp 마법사가 시작됩니다. 그림 1에서는 이 목록의 예를 보여 줍니다.

그림 1 터미널 서버에 설치된 응용 프로그램을 열거하는 RemoteApp 마법사

목록에서 RemoteApp로 만들 응용 프로그램을 선택하고 다음을 클릭합니다. 원하는 응용 프로그램이 목록에 없으면 찾아보기 단추를 클릭하여 기본 EXE 파일을 찾습니다. 기본 EXE 파일은 응용 프로그램을 실행하는 데 일반적으로 사용되는 파일입니다. 마법사를 완료하면 원격 응용 프로그램을 배포할 준비가 됩니다.

마우스 오른쪽 단추를 클릭하여 새 RemoteApp의 속성을 표시하면 조정할 수 있는 옵션이 몇 가지 제공됩니다. 이름, 위치, 아이콘 및 별칭 정보를 수정하는 것은 물론 명령줄 인수를 입력할 수도 있습니다. 명령줄 인수 입력 기능은 일련의 인수를 사용해야 실행 시에 정상적으로 작동되는 응용 프로그램에 특히 유용하지만 일부 응용 프로그램에서 원격 콘텐츠에 대한 링크를 만드는 데에도 사용할 수 있습니다.

잘 모르는 관리자가 많겠지만 TS RemoteApp로 전환하면 단순히 사용자의 화면에 응용 프로그램을 표시하는 이상의 기능을 구현할 수 있습니다. 즉, 약간의 수고만 더하면 RemoteApp를 사용하여 미리 구성된 콘텐츠도 자동으로 시작할 수 있습니다.

사용자에게 응용 프로그램을 배포하는 대신 특정 문서를 배포하려 한다고 가정해보겠습니다. 예를 들면 사용자에게 빈 Microsoft Office Word 또는 Access 응용 프로그램을 연결하는 RemoteApp를 만드는 대신 Word 문서나 Access 데이터베이스를 연결하려 할 수 있습니다. 이 경우 응용 프로그램의 기본 EXE 뒤에 문서 이름을 인수로 입력하면 됩니다. 즉, \\fileServer\fileShare\CompanyPTO.accdb에 저장된 Access 2007 기반 PTO(월차) 데이터베이스에 대한 연결을 만들려면 "PTO Database"라는 새 RemoteApp를 만들고 문서 위치를 명령줄 인수로 입력하면 됩니다. 이후 사용자가 PTO Database 응용 프로그램을 두 번 클릭하면 해당 데이터베이스가 미리 로드된 Access로 자동 연결됩니다.

이처럼 원격 콘텐츠에 대한 연결을 만드는 것은 RemoteApp의 용도를 확장하는 한 가지 방법이 될 수 있습니다. 그러나 RemoteApp를 사용하는 경우 사용자가 문서 사용을 시작할 수 있도록 하려면 아이콘에 대한 링크를 제공해야 합니다. 다음 섹션에서는 Windows Server 2008 터미널 서비스에서 이를 구현하는 몇 가지 방법을 설명하겠습니다.

웹에서 응용 프로그램 실행

새로운 TS 웹 액세스 역할 서비스를 사용하면 미리 구성된 웹 페이지에서 응용 프로그램 바로 가기를 호스트할 수 있습니다. 이 역할 서비스는 환경에서 터미널 서버와 통합되어 사용자가 응용 프로그램을 찾아 실행할 수 있는 단일 위치를 제공합니다. 그림 2에서는 이 웹 페이지가 사용자에게 어떻게 표시되는지를 보여 줍니다.

그림 2 배포된 RemoteApp를 열거하는 TS 웹 액세스 웹 페이지

이러한 페이지를 만들려면 기존 IIS 서버에 TS 웹 액세스 역할을 설치한 다음 TS 웹 액세스 서버의 컴퓨터 계정을 도메인의 TS Web Access Computers 글로벌 그룹에 추가합니다. 소규모 환경에서는 기존 터미널 서버에 TS 웹 액세스를 설치하여 단일 서버 솔루션을 구축할 수 있습니다.

RemoteApp를 설치한 후에는 TS RemoteApp 관리자에서 구성된 RemoteApp를 마우스 오른쪽 단추로 클릭하고 TS 웹 액세스에 표시를 선택하여 TS 웹 액세스에 사용할 수 있도록 설정합니다. 그러면 원격 데스크톱 클라이언트 버전 6.1 이상을 사용하는 사용자가 https://serverName/ts로 이동하여 응용 프로그램 바로 가기 목록을 볼 수 있습니다. 표시된 바로 가기 중 하나를 클릭하면 RemoteApp가 자동으로 실행됩니다.

TS 웹 액세스를 사용하면 응용 프로그램을 찾고 실행할 수 있는 친숙한 인터페이스를 제공할 수 있습니다. 웹 사이트를 업데이트할 때는 TS 웹 액세스에서 이전 응용 프로그램 또는 버전에 대한 링크를 숨기고 설치된 후에 새 링크를 표시하기만 하면 되기 때문에 응용 프로그램 또는 버전이 정기적으로 변경되는 경우에 특히 유용합니다.

그러나 이 도구에도 몇 가지 한계가 있습니다. 우선 사용자가 액세스할 수 있는 응용 프로그램을 제한하는 메커니즘이 기본 제공되지 않습니다. 터미널 서버에서 만들어 TS 웹 액세스에 표시한 모든 RemoteApp는 인증된 모든 사용자에게 표시됩니다.

둘째로, 사용자가 응용 프로그램에서 일반적으로 작업을 수행하는 방법과 관련한 문제가 있습니다. Word와 같은 응용 프로그램을 시작할 때 응용 프로그램 바로 가기를 클릭하는 경우가 실제로 얼마나 될까요? 아마 거의 없을 겁니다. 대개는 기존 Word 문서를 두 번 클릭하여 해당 문서가 미리 로드된 채로 응용 프로그램을 시작합니다.

아쉽게도 TS 웹 액세스는 이러한 응용 프로그램 실행 방법을 지원하지 않습니다. 문서를 두 번 클릭하여 연결된 응용 프로그램을 실행하는 데 익숙해진 사용자의 경우 TS 웹 액세스가 불편하게 느껴질 수 있습니다. 하지만 이 경우에 사용할 수 있는 훨씬 유용한 옵션이 있으니 걱정할 필요는 없습니다. 다음 섹션에서는 이에 대해 설명하겠습니다.

데스크톱에서 응용 프로그램 실행

문서를 두 번 클릭하여 응용 프로그램을 실행하려는 사용자를 위해 원격 응용 프로그램의 링크를 데스크톱에 "설치"하는 기능이 터미널 서비스에 추가되었습니다. 이 프로세스는 Remote­App의 RDP 파일을 Windows Installer 패키지(MSI 파일)에 효과적으로 래핑합니다. 이 패키지는 나중에 환경의 데스크톱에 설치됩니다.

이와 동시에 설치된 MSI는 데스크톱에서 파일 확장명 연결을 수정하여 두 번 클릭한 파일을 터미널 서버의 연결된 RemoteApp로 다시 라우팅할 수 있습니다. 그림 3에서는 Word RemoteApp를 설치한 후에 파일 확장명 연결이 어떻게 수정되는지를 보여 줍니다. 이제 일반 Word 파일 확장명을 두 번 클릭하면 원격 데스크톱 연결을 통해 Word가 실행됩니다.

그림 3 원격 데스크톱 연결을 시작하도록 변경된 파일 확장명 연결

기존 RemoteApp에서 Windows Installer 패키지를 만들려면 먼저 TS RemoteApp 관리자로 이동합니다. 원하는 RemoteApp를 마우스 오른쪽 단추로 클릭하고 Windows Installer 패키지 만들기를 선택합니다. 생성된 모든 Windows Installer 패키지는 기본적으로 C:\Program Files\Packaged Programs에 저장되지만 이 위치는 RemoteApp 마법사에서 변경할 수 있습니다. 또한 마법사에서는 서버 인증, 인증서 설정 및 TS 게이트웨이 설정 외에 RemoteApp를 호스트할 서버의 이름과 포트도 구성할 수 있습니다.

그림 4에는 설치 후 후보 데스크톱에서 응용 프로그램의 위치와 관련한 설정이 나와 있습니다. 그림에서 보듯이 시작 메뉴 폴더 내의 위치뿐만 아니라 바탕 화면에도 바로 가기를 만들 수 있습니다. 이 화면에서는 맨 아래에 있는 확인란이 가장 중요합니다. 이 확인란은 클라이언트 설정 권한을 가져오고 RemoteApp에 대한 모든 파일 확장명 연결을 로컬 데스크톱에서 터미널 서버로 다시 연결합니다. 사용자가 문서를 두 번 클릭하여 TS에서 호스트되는 응용 프로그램을 실행할 수 있도록 하려면 이 확인란을 선택해야 합니다. 다음을 클릭하고 마침을 클릭하여 마법사를 완료합니다.

그림 4 Windows Installer 패키지를 만들어 클라이언트 파일 확장명 연결 가능

데스크톱 설치를 사용하여 사용자를 응용 프로그램에 연결하는 데 따른 장점은 사용자의 동작을 변경할 필요가 없다는 점입니다. 응용 프로그램이 설치되고 나면 사용자가 평소처럼 문서를 두 번 클릭하여 응용 프로그램을 실행할 수 있습니다.

그러나 이 방법에도 추가적인 데스크톱 관리가 필요하다는 단점이 있습니다. 이 방식으로 사용할 RemoteApp는 액세스가 필요한 각 데스크톱에 설치해야 합니다. 잠시 후에 자세히 설명하겠지만 그룹 정책 소프트웨어 설치를 통해 이 프로세스를 보다 쉽게 수행할 수 있습니다. 그러나 관리 부담은 여전히 남습니다. 또한 응용 프로그램이 변경되면 각 데스크톱에 설치된 RemoteApp도 업데이트해야 할 가능성이 큽니다.

Windows Installer 패키지를 만든 후에는 그룹 정책 설치를 통해 패키지를 쉽게 설치할 수 있습니다. 먼저 그룹 정책이 액세스할 수 있는 파일 공유를 만듭니다. 단일 터미널 서버 시나리오에서 이 파일 공유 위치로는 터미널 서버의 기본 C:\Program Files\Packaged Programs 폴더가 적합합니다. 그룹 정책이 처리되는 동안 클라이언트가 공유에 액세스할 수 있도록 폴더와 공유에 권한이 적절하게 할당되었는지 확인합니다. 그런 다음 새 GPO(그룹 정책 개체)를 만들고 컴퓨터 구성|정책 |소프트웨어 설정|소프트웨어 설치로 이동합니다. 소프트웨어 설치를 마우스 오른쪽 단추로 클릭하고 새로 만들기|패키지를 선택합니다. 나타나는 대화 상자에서 Remote­App에 대해 생성된 MSI 파일을 찾습니다. 배포 방법을 묻는 메시지가 나타나면 고급을 선택합니다.

이때 원하는 옵션을 선택할 수 있습니다. RemoteApp는 RDP 파일과 아이콘 외에 약간의 항목만 C:\Program Files\RemotePackages에 설치할 정도로 설치 크기가 매우 작기 때문에 응용 프로그램이 관리 범위에서 벗어나면 제거 옵션을 선택하는 것이 좋을 수 있습니다. 이 옵션을 선택하면 GPO가 삭제되거나 GPO가 더 이상 적용되지 않는 새 OU로 컴퓨터가 이동하면 RemoteApp가 컴퓨터에서 자동으로 제거됩니다. 따라서 이 옵션을 선택하면 컴퓨터 및 응용 프로그램이 관리 범위에 추가되고 제외될 때 RemoteApp를 제거하는 프로세스가 매우 간단해집니다.

사용자 환경

이러한 메커니즘을 사용하여 응용 프로그램을 배포하는 것도 효과적이지만 터미널 서비스를 관리하기 위해서는 단순히 응용 프로그램을 만들고 배포하는 것 이상의 작업이 필요합니다. 즉, 사용자의 요구에 맞게 구현하는 것도 그만큼 중요합니다. 응용 프로그램 제공을 계획할 때는 사용자 환경의 품질을 파악할 수 있는 주관적인 성능 메트릭도 반드시 고려해야 합니다. 하드 메트릭을 사용하여 수치화하는 것이 어렵긴 하지만 효과적인 터미널 서비스 배포를 위해서는 집단적 사용자 만족도를 성공의 척도로서 고려해야 합니다.

자세히 설명하자면 특히 같은 서버의 리소스를 공유하는 경우에 사용자가 큰 문제가 될 수 있습니다. 터미널 서비스를 사용하는 사용자는 서버에 설치된 응용 프로그램을 공유하기 위해 단일 서버로 모여들게 됩니다. 대규모의 사용자가 적은 수의 서버에 연결하는 경우 응용 프로그램 수가 적어지기 때문에 관리하기가 용이합니다. 관리할 응용 프로그램 수가 적을수록 패치 횟수도 줄고 환경이 보다 효과적으로 제어되고 관리가 필요한 지점도 적습니다.

이러한 사용자 통합을 위해서는 터미널 서버 관리자가 시스템을 돌보는 역할을 해야 합니다. 뛰어난 사용자는 시스템에서 사용자의 행동을 관찰하고 사전에 필요한 사항을 변경하여 터미널 서버 팜을 관리합니다. 이러한 변경은 특정 사용자의 잘못된 행위가 다른 사용자의 사용 환경에 영향을 주지 않도록 재구성하고 제한하는 형태로 이루어집니다.

일례로 유능한 터미널 서버 관리자라면 프로세서 사용률이 급증한 후 높은 수준으로 계속 유지될 때 관리자에게 알리는 성능 경고를 구성할 것입니다. 이러한 현상은 프로세스가 프로세서를 과도하게 점유하거나 사용자가 공유 시스템의 리소스를 너무 많이 사용하는 작업을 시작했음을 나타내는 신호일 수 있습니다. 문제가 되는 프로세스를 추적하여 중단시키는 것이 문제를 해결하는 첫 단계입니다. 그리고 장기적으로는 해당 프로세스가 그러한 방식으로 작동한 이유를 찾아 문제를 근본적으로 해결해야 합니다.

핵심은 원격 응용 프로그램이 최소한 로컬 데스크톱에 설치되었을 때와 같은 수준의 성능을 제공하도록 보장하는 것입니다. 추가 기사 "주요 터미널 서비스 성능 카운터"에는 성능 문제 해결에 도움이 되는 몇 가지 PerfMon 메트릭이 나와 있습니다.

성능 예측을 가능하게 하는 RemoteApp

사실상 RemoteApp는 세션의 너비와 높이가 실행하는 응용 프로그램과 정확히 일치하는 터미널 서비스 세션이라고 할 수 있습니다. 세션의 경계가 응용 프로그램 자체의 경계를 넘어 확장되지는 않기 때문에 결과적으로 원격 응용 프로그램이 로컬에 표시되는 것입니다.

사실 Microsoft에서는 여기서 설명한 것보다 훨씬 효율적으로 Remote­App를 구현했습니다. 실행 및 작동에 필요한 리소스의 관점에서 보면 배포된 RemoteApp는 배포된 전체 데스크톱과는 확실히 다릅니다. 원격 데스크톱을 실행하려면 데스크톱 셸은 물론 시스템 트레이 응용 프로그램, 도우미 응용 프로그램, 표준 데스크톱과 함께 제공되는 모든 서비스/프로세스 등 explorer.exe를 사용하여 시작되도록 구성된 모든 프로세스가 작동하도록 explorer.exe를 인스턴스화해야 합니다.

이와 대조적으로 Remote­App를 실행하는 데는 전체 explorer.exe 셸이나 모든 추가 기능이 필요하지 않습니다. 사실 RemoteApp는 rdpshell.exe 및 rdpinit.exe라는 두 가지 프로세스로 explorer.exe를 대체합니다. 간소화된 이 두 프로세스는 RemoteApp를 부트스트랩하여 실체화하는 셸 및 셸 로그온 응용 프로그램의 대안으로 작동합니다.

그림 5에서는 2명의 사용자가 연결하여 계산기 응용 프로그램을 실행하는 간단한 터미널 서버의 예를 보여 줍니다. User1은 전체 데스크톱을 통해 로그온했고 User2는 미리 만들어진 calc.exe라는 RemoteApp 인스턴스에 연결했습니다. 그림 6에서 보듯이 User2가 계산기 RemoteApp를 시작하기 위해 실행해야 하는 프로세스 수가 더 많지만 모든 프로세스의 메모링 사용량 합계는 User1의 explorer 셸에 필요한 양보다 작습니다.

그림 5 데스크톱과 RemoteApp의 리소스 사용량 차이를 보여 주는 작업 관리자

이러한 RAM 사용량 절감은 성능과 관련하여 고려해야 할 사항 중 일부에 지나지 않습니다. 사용자의 행동이 프로세스 사용량에 미치는 영향도 고려해야 합니다. 사용자에게 전체 데스크톱을 배포한 경우 터미널 서버에 설치된 어떤 응용 프로그램이라도 실행할 수 있는 능력이 사용자에게 부여되는 셈입니다.

실행 권한을 적절히 제한하지 않으면 단순히 Word에서 문서를 작성하기 위해 터미널 서비스를 활용하는 사용자도 언제든지 리소스를 더 많이 소모하는 강력한 응용 프로그램을 실행하여 큰 부하를 발생시킬 수 있습니다. 이러한 예측할 수 없는 행위는 사용자별 리소스 계획에 있어서 장애가 됩니다. 게다가 특정 사용자의 행위가 다른 사용자의 사용 환경에 영향을 줄 가능성이 커지기 때문에 터미널 서버를 관리하기도 더 어려워집니다.

이러한 예측 불가능성을 가장 잘 보여 주는 예가 바로 Internet Explorer입니다. 모든 Windows Server 인스턴스에 설치된 Internet Explorer는 실행하는 데 많은 리소스를 필요로 하지 않습니다. 하지만 수많은 플러그 인이 필요한 잘못 작성된 웹 사이트를 렌더링하는 데 Internet Explorer를 사용하면 리소스 사용량이 급격하게 증가할 수 있습니다. 사용자가 데스크톱 세션을 실행하는 동안 부적절하고 예기치 않게 Internet Explorer를 실행하면 터미널 서버의 사용 가능한 리소스를 과도하게 소모하여 다른 사용자의 성능을 저하시킬 수 있습니다.

전체 데스크톱과는 대조적으로 RemoteApp를 사용할 경우 리소스 사용량을 효과적으로 예측할 수 있습니다. RemoteApp를 실행하는 사용자는 해당 응용 프로그램과 초기 응용 프로그램에 의해 실행된 다른 응용 프로그램만 작업에 사용할 수 있습니다. 따라서 성능의 관점에서 사용자의 행위를 예측하기가 용이합니다.

선택은 여러분의 몫

이 문서의 궁극적인 목적은 원격 응용 프로그램을 사용자에게 배포하는 여러 가지 옵션을 소개하는 것입니다. Windows Server 2008의 터미널 서비스를 기반으로 한 새로운 기능은 응용 프로그램에 연결할 수 있는 다양한 경로를 사용자에게 제공합니다. 환경에 따라 데스크톱과 웹에서 호스트되는 전체 데스크톱을 조합하는 구성이 RemoteApp보다 나을 수도 있습니다.

주요 터미널 서비스 성능 카운터

사용자의 만족도 측정은 메트릭을 사요하기 보다 개인 면담을 통해 주관적으로 이루어지는 경우가 많지만 사용자 만족도에 영향을 주는 터미널 서버 성능을 확인하는 데 도움이 되는 유용한 성능 카운터도 몇 가지 있습니다. 따라서 터미널 서버에서 다음 카운터를 측정해보는 것이 좋습니다.

Memory\Available MBytes 터미널 서버의 프로세스가 실제 메모리를 많이 소모하는 경우 이 카운터 수치가 매우 낮아집니다. 이 수치가 낮다고 해서 꼭 나쁜 것은 아니지만 그와 동시에 스레드 수가 많고 초당 페이지 전송률이 높다면 너무 많은 사용자가 터미널 서버에서 너무 많은 작업을 시도하고 있음을 나타낼 수 있습니다.

Memory\Pages/Sec 이 카운터는 디스크에서 메모리를 읽거나 쓰는 비율과 관련이 있습니다. 이 수치가 높고 Available MBytes 카운터의 수치가 낮으면 서버의 부하에 비해 사용 가능한 메모리가 부족함을 의미할 수 있으며, 따라서 사용자 환경의 성능이 저하될 수 있습니다.

Processor\% Processor Time 이 카운터는 생산적인 작업에 사용되는 프로세서의 수를 효과적으로 보여 줍니다. 다중 프로세서 시스템에서 이 수치는 중단되거나 사용률이 갑자기 증가한 프로세서를 나타낼 수 있으므로 특히 잘 살펴보아야 합니다.

System\Threads 서버에서 실행되는 각 프로세스는 여러 스레드로 이루어집니다. Threads 카운터는 시스템에서 실행되는 모든 프로세스의 합계를 나타내는 정수입니다. 터미널 서버에서는 동시에 시스템 리소스를 사용하는 사용자 수가 많기 때문에 스레드 및 프로세스 수도 많아지기 쉽습니다. 이 카운터의 수치가 높아지면 서버에서 많은 수의 작업이 동시에 시도된다고 판단할 수 있습니다. 스레드 수가 많으면 서버가 각 프로세스의 요청을 처리하려고 시도함에 따라 Context Switches 카운터 수치도 증가하는 경우가 많습니다.

System\Context Switches/Sec 컨텍스트 전환은 프로세서가 현재 처리 중인 스레드를 변경할 때마다 발생합니다. 컨텍스트 전환이 이루어질 때마다 약간의 오버헤드가 발생하기 때문에 이 수치와 스레드 카운터 수치가 높으면 많은 사용자가 동시에 많은 작업을 시도하는 것으로 볼 수 있습니다.

System\Processor Queue Length 프로세서에서 부하를 제때 처리하지 못하면 요청이 대기 상태가 됩니다. 이러한 대기 중인 요청에 대한 카운터를 Processor Queue Length라고 합니다. 이 카운터가 증가하는 경우 너무 많은 요청으로 인해 서버의 프로세서에서 과부하가 발생한 것으로 판단할 수 있습니다. 또한 이는 사용자 환경의 성능 저하를 나타낼 수도 있습니다.

Terminal Services\Active Sessions and Terminal Services\Total Sessions 이 두 메트릭은 터미널 서버에서 작업 중인 사용자 수 대비 리소스 사용량을 효과적으로 평가하는 데 도움이 됩니다. 첫 번째 카운터는 세션을 통해 현재 작업을 수행 중인 사용자 수를 나타내고 두 번째 카운터는 유휴 상태이거나 연결이 끊긴 사용자를 나타냅니다. 이 두 카운터를 다른 카운터와 함께 사용하면 과부하가 발생하여 사용자 환경의 성능이 저하되지 않으면서 서버에서 처리할 수 있는 최대 사용자 수를 파악하는 데 유용합니다.

실제 수치는 하드웨어 구성과 설치된 응용 프로그램, 시스템의 사용자 수와 유형에 따라 달라집니다. 따라서 정해진 수치를 임계값으로 제공하면 자칫 오해를 유발할 수 있습니다. 대신 자체적으로 메트릭이 일반적인 작동 상태를 많이 벗어날 때의 수치와 시간의 변화를 사용자 환경의 성능 저하를 확인하는 초기 기준으로 삼아야 합니다.

Greg Shields는 Concentrated Technology의 공동 설립자이자 IT 전문가인 MVP입니다. 최근 저서인 Windows Server 2008: What's New/What's Changed는 SAPIEN Press를 통해 구매할 수 있습니다. 질문이 있으면 www.ConcentratedTech.com으로 연락하시기 바랍니다.