인터넷 트랜잭션에 대한 용량 모델

이장의 내용
down요약
down소개
down기존의 용량 계획과 TCA 비교
down트랜잭션 비용 분석 요구 사항
down트랜잭션 비용 분석 방법
down트랜잭션 비용 분석을 사용한 용량 계획
down결론
down부록 A - 참조 자료

요약 Back to Top

인터넷 서비스를 위한 용량 계획은 다음 목표를 달성할 수 있는 인터넷 사이트를 구축하도록 도와주기 위한 것입니다.

  • 호스트 플랫폼 소유로 인한 총 비용 최소화
  • 트랜잭션 처리량 목표 지원
  • 적절한 응답 시간 유지

기존의 용량 계획 방식에서는 일반적인 벤치마크 측정 결과에 따라 인터넷 서비스 비용을 추정합니다. 제시된 용량 계획 목표에 보다 근접할 수 있도록 Microsoft에서는 TCA(트랜잭션 비용 분석)에 따라 시스템 용량 요구 사항을 예상하는 방법을 개발하였습니다.

TCA 방법은 표준 네트워크 프로토콜을 지원하는 로드 생성 도구를 통해 호스트 서버에서 클라이언트 트랜잭션을 시뮬레이트합니다. 클라이언트 로드가 변함에 따라 트랜잭션 처리량은 리소스 활용도와 연관되어 선형 작동 범위에서 변합니다. 그런 다음 검색 습관과 같은 사용자의 예상 동작에 따라 사용 프로필이 정의됩니다. 이러한 사용 프로필에 따라 목표 처리량 및 기타 중요한 트랜잭션 매개 변수가 결정되며 다시 이 결과에 따라 리소스 활용도 및 용량 요구 사항이 계산됩니다.

소개 Back to Top

TCA 방법은 모든 클라이언트/서버 시스템에 적용할 수 있지만 여기서는 인터넷 서비스에 TCA를 적용하는 경우에 한해 설명합니다.

"기존의 용량 계획과 TCA 비교" 절에서는 기존의 용량 계획 방법을 대략적으로 설명하고 TCA(트랜잭션 비용 분석)에 따른 방법과 비교합니다. "트랜잭션 비용 분석 방법" 절에서는 사용 프로필, 조사 도구, 성능 측정, 리소스 비용 계산 및 모델 확인을 포함하여 TCA 방법에 대해 자세히 설명합니다. "트랜잭션 비용 분석을 사용한 용량 계획" 절에서는 TCA 결과를 사용하여 용량 계획을 세우는 절차를 간단히 소개합니다. "트랜잭션 비용 분석 요구 사항" 절에서는 TCA 및 용량 계획을 수행하기 위한 요구 사항에 대해 설명합니다.

기존의 용량 계획과 TCA 비교 Back to Top

그림 1에 나타난 것처럼 기존의 접근 방법과 TCA 접근 방법의 두 가지 용량 계획 방법을 사용할 수 있습니다.


현재 사용하는 브라우저가 인라인 프레임을 지원하지 않을 경우 여기 를 누르면 새 창에서 볼 수 있습니다.

그림 1 기존의 접근 방법과 TCA 방법 비교

기존의 접근 방법

기존의 용량 계획 방법에서는 특정 사용 프로필을 갖는 특정 하드웨어에서 여러 서비스의 특정 조합에 대한 최대 작업 로드를 벤치마킹합니다. 가능한 모든 하드웨어, 서비스 및 사용 프로필 조합에 대해 이 작업을 반복하는 것은 현실적으로 불가능하므로 이 과정은 불완전하며 시간이 많이 걸립니다. 이러한 제한을 극복하기 위해 대표적인 몇 가지 구축 시나리오에 대해서만 벤치마크를 수행한 후 이러한 벤치마크를 각각의 특정 구축 시나리오에 맞게 추정하여 비용을 예측합니다. 또한 이러한 벤치마크는 최대 작업 로드만 캡처하도록 디자인되어 있으므로 이 방법을 사용하면 하드웨어를 과다하게 산정할 수 있습니다.

트랜잭션 비용 분석 방법

TCA(트랜잭션 비용 분석)는 각 리소스 비용을 사용 프로필, 서비스 조합 또는 하드웨어 구성의 함수로서 산출하는 프레임워크를 제공하여 비용 분석 프로세스에서 나타나는 불확실성을 되도록 줄이려고 합니다. 하드웨어 리소스에는 CPU, 캐시, 시스템 버스, RAM, 디스크 하위 시스템 및 네트워크 등이 포함됩니다. TCA 방법을 사용하면 전체적인(선형) 작업 로드 범위가 측정되므로 하드웨어를 과다하게 산정할 가능성이 줄어듭니다. 또한, TCA는 일부 코드 프로파일링 기법과는 달리 운영 체제 오버헤드를 비롯하여 런타임 중에 발생하는 모든 비용을 캡처합니다.

TCA 방법은 어떠한 클라이언트/서버 시스템에도 적용할 수 있지만 본 백서에서는 인터넷 서비스에 TCA를 적용하는 경우에 대해 설명합니다. 용량 계획 및 성능과 관련된 기타 참조 자료에 대해서는 부록 A를 참조하십시오.

트랜잭션 비용 분석 요구 사항Back to Top

TCA(트랜잭션 비용 분석)를 수행하기 위한 요구 사항은 다음과 같습니다

  • 사용 프로필, 확장성 제한 및 대기 시간 요구 사항을 성공 기준으로 설정합니다.
  • 서비스를 모니터링할 수 있도록 측정되는 서비스에 도구가 내장되어야 합니다.
  • Windows 2000 시스템 모니터와 같은 데이터 수집 및 분석을 위한 성능 모니터링 도구가 필요합니다.
  • Microsoft Visual Studio .NET 또는 Mercury Interactive LoadRunner의 일부로 제공되는 ACT(Application Center Test) 도구와 같이, 사용자의 서비스 시뮬레이션을 지원하는 로드 생성 도구가 필요합니다.
  • 로드를 시뮬레이트하기 위한 하드웨어와 로드 생성 및 사용 프로필 스크립트가 필요합니다.

평가되는 서비스 구성 요소를 실행하기 위해, 프로덕션 서버로 구축될 하드웨어와 같은 급의 하드웨어가 필요합니다.

트랜잭션 비용 분석 방법 Back to Top

TCA(트랜잭션 비용 분석)는 용량 계획을 세울 때 사용될 수 있으며 인터넷 서비스에서 발생하는 성능 병목 현상도 감지할 수 있습니다. 대부분의 경우 TCA는 이러한 두 가지 용도로 동시에 사용됩니다. 그러나 본 문서에서는 용량 계획의 용도로 TCA를 사용하는 경우에 대해서만 설명합니다.

편의상 여기 제시된 방법에서는 다음과 같이 가정합니다.

  • 분석되는 서비스에서는 코드 병목 현상이 없습니다.
  • 구현할 경우 서비스는 대략 선형적으로 확장됩니다.
  • 하드웨어 병목 현상은 서비스가 실행되는 컴퓨터에서 나타납니다.

용량 관련 정보에 정확하게 액세스하기 위해 이러한 가정이 필요합니다.

사용 프로필

용량 계획 모델의 효율성과 융통성은 평가되는 각 서비스의 예상되는 사용 프로필을 얼마나 신중하게 평가하느냐에 따라 좌우됩니다. 이러한 사용 프로필은 개별적이고 종합적인 사용자 동작과 사이트 프로필 정보로 구성됩니다. 사용 프로필을 정의할 때는 먼저 비슷한 서비스의 트랜잭션 로그를 분석합니다. 이 사용 프로필에서 파악된 특성에 따라 성능 목표를 설정합니다. 사용 프로필을 만드는 데 대한 자세한 내용은 본 백서와 동일한 웹 페이지에 제공되는 Commerce Server 2002: 사이트 용량 계획을 위한 사용 프로필 만들기(Commerce Server 2002: Creating a Usage Profile for Site Capacity Planning) 백서를 참조하십시오.

사이트 프로필 정보

다음 사항을 지정하는 대표적인 사이트 프로필을 정의해야 합니다.

  • 구축된 서비스
  • 각 서비스를 사용하는 동시 사용자수
  • 예상되는 구축 구성

참고 예상되는 구축 구성은 각 서비스 구성 요소뿐 아니라 각 서비스 구성 요소가 포함된 서버도 식별해야 합니다

다음 표에 나타난 기호는 본 백서의 TCA 방정식에서 사용되는 기호입니다.

기호
정의
설명
i = 1,...,I
HTTP, FTP, LDAP 및 SQL 등 구축된 서비스
아래 행의 예제에서 i는 HTTP입니다.
Ni
최대 사용 시간에 서비스 i를 동시에 사용하는 사용자수
HTTP 사용자가 100명이면 NHTTP = 100으로 나타낼 수 있습니다.

시나리오

인터넷 서비스 공급자가 구독자의 인터넷 웹 페이지 검색을 지원하는 웹 호스팅 플랫폼을 구축하려고 합니다. 이 플랫폼은 구독자에게 이러한 웹 페이지와 호스트 사이트 간의 파일 전송을 제어하기 위한 FTP(파일 전송 프로토콜) 서비스도 제공합니다.

이 시나리오를 지원하는 데 필요한 서비스는 웹(HTTP), FTP, 디렉터리(예: LDAP) 및 데이터베이스(예: Microsoft SQL Server™) 서비스로 구성됩니다. 웹 및 FTP 서비스는 프런트 엔드 서버에 구성되지만 디렉터리 및 데이터베이스 서비스는 각각 별도의 백 엔드 서버에 위치합니다. 이 시나리오를 좀더 단순화하기 위해 여기서는 웹 및 FTP 서비스만 분석합니다.

사용자 동작

다음과 같은 특성에 따라 개별 사용자 동작을 구분할 수 있습니다.

  • 인터넷 서비스 사용자의 동작은 기본 트랜잭션 집합으로 정의되는 클라이언트 쪽에서의 일부 작업 시퀀스에 해당합니다. 간단한 분석을 위해 전체적으로 하드웨어 리소스를 가장 많이 사용할 것으로 예상되는 트랜잭션만 고려합니다.
  • 각 서비스에 대해 예상되는 사용자 세션 시간
  • 해당 세션 시간 동안 사용자별로 각 트랜잭션이 수행되는 시간
  • 데이터를 읽거나 쓰거나 전송하는 트랜잭션의 파일 크기와 같이, 시스템 성능에 많은 영향을 미치는 관련 트랜잭션 매개 변수를 식별해야 합니다.

다음 표에 나타난 기호는 본 백서의 TCA 방정식에서 사용되는 기호입니다.

기호
정의
예제
j = 1,…,J
get, open 및 delete와 같은 트랜잭션
Open = 200
ti
서비스 i에 대한 사용자 세션 시간
tHTTP = 600 (seconds)
nij
서비스 i에 대한 사용자 세션 당 트랜잭션 수(j)
nHTTP, get = 사용자 당 5번의 HTTP get 작업

시나리오

앞의 시나리오와 연결해서 살펴 볼 때 가능한 모든 FTP 트랜잭션 중에서 "delete," "get," "open" 및 "put"만이 전체적으로 가장 많은 로드를 생성할 것으로 예상됩니다. 따라서 분석할 때 이러한 트랜잭션만 고려하면 됩니다. 특히, FTP "open"은 연결을 위해 인증이 필요할 경우 LDAP 및 해당 데이터베이스 백 엔드와 같은 디렉터리 서비스에 부담을 줄 수 있습니다. FTP "delete"는 디스크 I/O(입출력) 리소스에만 부담을 주지만 FTP "get" 및 "put"은 디스크 I/O(입출력) 리소스에 부담을 줄 뿐 아니라 네트워크 용량을 포화시킬 수 있습니다. HTTP "get" 트랜잭션에 대해서도 비슷한 문제가 나타납니다. 따라서, 이러한 분석을 위한 기본 트랜잭션은 FTP의 경우 "delete," "get," "open", "put", HTTP의 경우 "get"으로 구성되어야 합니다.

이와 같이 FTP를 사용하여 전송 또는 삭제되는 파일의 크기와 HTTP를 사용하여 요청되는 웹 페이지 크기는 중요한 트랜잭션 매개 변수로 고려되어야 합니다.

성능 목표

성능 목표는 요구되는 트랜잭션의 최소 처리량과 허용 가능한 최대 트랜잭션 대기 시간으로 구성됩니다. 이 사용 프로필을 지원하는 데 필요한 서비스 i에 대한 트랜잭션 j의 최소 처리량(트랜잭션 속도)은 방정식 1로 지정됩니다.

방정식 1

Tij = nij Ni / ti

여기서 다음이 적용됩니다.

  • Tij는 서비스 i에 대한 트랜잭션 j의 트랜잭션 속도입니다
  • nij는 서비스 i에 대한 사용자 세션별 트랜잭션(j) 수입니다.
  • Ni는 최대 사용 시간에 서비스 i를 동시에 사용하는 사용자의 수입니다.
  • ti는 서비스 i에 대한 사용자 세션 시간입니다.

시나리오

이 시나리오에서 총 웹 페이지 사용자는 200만 명이며, 이 사용자 중 1.0%가 최대 사용 시간에 동시에 웹 페이지를 검색합니다. 또한 각 웹 사용자는 20분 동안 5번의 HTTP "get" 작업을 수행하고 각 FTP 사용자는 5분 간격 동안 3번의 FTP "put" 작업과 2번의 FTP "get" 작업을 함께 수행합니다.

이 데이터를 다음과 같이 요약할 수 있습니다.

NHTTP = 20,000명의 동시 사용자 = (2,000,000 * 1.0%)tHTTP = 1,200초nHTTP,get = 사용자 당 5번의 HTTP get 작업

위의 정보를 토대로 다음 수식을 사용하여 지정된 시간 간격 동안 요청된 HTTP GET 요청의 총 횟수를 계산합니다.

nHTTP,get * NHTTP = nij Ni = (5 *20,000) = 100,000번의 HTTP get방정식 1의 수식을 사용하여 HTTP 서비스에 대한 GET 요청의 초당 트랜잭션 속도를 계산할 수 있습니다. Tij=nij Ni / ti = (100,000 / 1,200) = 83번의 HTTP get/초

이제 동일한 인터넷 사이트에 백만 명의 웹 호스팅 구독자가 있고 이 중 0.1%가 최대 사용 시간에 동시에 FTP를 사용한다고 가정합니다. 각 FTP 사용자는 5분 간격 동안 세 번의 FTP "put" 작업과 두 번의 FTP "get" 작업을 함께 수행합니다. 이 데이터를 다음과 같이 요약할 수 있습니다.

NFTP = 1000명의 동시 사용자 = (1,000,000 * 0.1%)tFTP = 300초(5분)nFTP,put = 사용자 당 3번의 FTP putnFTP,get = 사용자 당 2번의 FTP get

위의 정보를 토대로 지정된 시간 간격 동안 요청된 FTP "put" 및 FTP "get" 요청의 총 횟수를 계산할 수 있습니다.

다음 수식을 사용하여 총 FTP "put" 요청 수를 계산합니다.

NFTP * nFTP, put = nij Ni = (3 * 1,000) = 3,000번의 FTP put

다음 수식을 사용하여 총 FTP "get" 요청 수를 계산합니다.

NFTP * nFTP, get = nij Ni = (2 * 1,000) = 2,000번의 FTP get

방정식 1의 수식을 사용하여 FTP 서비스에 대한 초당 트랜잭션 속도를 계산할 수 있습니다.

TFTP, put = nij Ni / ti = (3,000 / 300) = 10번의 FTP put/초TFTP, get =nij Ni / TFTP, get =nij Ni / ti = (2,000 / 300) = 6.7번의 FTP get/초

조사 도구

TCA(트랜잭션 비용 분석) 방법을 사용하려면 리소스 활용도와 서비스 런타임 성능 간에 상관 관계가 있어야 합니다. 리소스 활용도를 측정할 수 있는 적절한 도구가 이미 운영 체제에 기본적으로 제공되기는 하지만, 서비스 트랜잭션의 성능 특성을 측정하는 메트릭을 정의하여 조사 도구에 포함시켜야 합니다. 그림 2는 용량 계획 및 성능 관리 측면에서 이러한 조사의 목적을 보여 줍니다.

capmod_2

그림 2 용량 계획 및 성능 관리 시 조사 도구 사용

Windows 2000 시스템 모니터

Microsoft Windows 2000 시스템 모니터에는 카운터라고 하는 조사 프로그램이 포함되어 있는데, 트랜잭션 흐름, 상태, 대기열 및 각 서비스의 대기 시간뿐 아니라 리소스 활용도 및 기타 시스템 매개 변수를 측정합니다.

참고 Windows 2000 시스템 모니터와 성능 로그 및 경고 기능은 Windows NT 버전 4 성능 모니터의 기능을 대체합니다.

TCA 및 정기적인 성능 모니터링 중에 일반적으로 수집되는 시스템 모니터 카운터는 다음과 같습니다.

  • Windows 2000 운영 체제 카운터

    • 이러한 카운터에는 프로세서 활용도, 컨텍스트 스위칭 속도, 프로세서 및 디스크 대기열 길이, 디스크 읽기 및 쓰기 속도, 사용 가능한 메모리 바이트 수, 프로세스에 의해 할당된 메모리, 캐시 적중률, 네트워크 활용도, 네트워크의 바이트 송수신 속도 등이 포함됩니다.

  • 트랜잭션 흐름 카운터

    • 이러한 카운터에는 HTTP get 수/초, FTP put 수/초, LDAP search 수/초 등의 트랜잭션 속도가 포함됩니다.

  • 서비스 상태, 대기열 및 대기 시간 카운터

    • 이러한 카운터에는 동시 연결수, 캐시 적중률(예: LDAP 및 SQL Server 트랜잭션의 경우), 대기열 길이 및 각 서비스 구성 요소 내에서의 대기 시간 등이 포함됩니다.

Windows NT 카운터 예제에 대해서는 Microsoft Windows 2000 Sever Resource Kit(Microsoft Press, 2000년)을 참조하십시오.

성능 측정

TCA 방법은 테스트 환경의 구성 및 시뮬레이트된 사용자 로드의 생성과 관련해서 성능 측정 요구 사항을 엄격하게 적용합니다. 이 절에서는 시스템 구성과 로드 생성의 두 가지 측면을 모두 다룹니다.

시스템 구성

한 하드웨어 구성에서 측정한 TCA 측정 결과를 다양한 구성 방식에 적용할 수 있도록 서비스 구성 요소를 가능한 한 여러 서버로 분산시키는 것이 좋습니다. 캐시를 사용하지 않는 환경에서는 각 트랜잭션의 리소스 비용을 트랜잭션에 사용되는 각 구성 요소의 함수로서 더 명확하게 구분할 수 있습니다.

서비스 구성 요소별로 트랜잭션의 리소스 비용을 구분하는 예가 그림 3에 나타나 있습니다. 이 그림은 클라이언트와 여러 서버 사이에서 한 트랜잭션(예: LDAP "add")이 어떻게 전파되는지를 보여 주며 누적된 리소스 비용도 나타냅니다. 그림 3에서 이 리소스 비용은 서버 1(LDAP 서비스가 실행되는 서버)에 대해서는 C1으로, 서버 2(SQL Server가 실행되는 서버)에 대해서는 C2로 표시됩니다.

capmod_3

그림 3 서버별로 서비스 구성 요소의 리소스 비용 구분

이 트랜잭션에 사용되는 모든 구성 요소가 특정 구축 작업을 위해 단일 서버에 위치하는 경우 통합된 비용을 대략적으로 추정하기 위해 C1+C2처럼 개별 비용을 더할 수 있습니다. 물론, 이 경우 특정 성능 속성이 변경됩니다. 예를 들면, 네트워크 연결을 관리하기 위한 CPU 오버헤드와 같은 특정 비용은 계산되지 않지만, 트랜잭션 요청 캐시에 필요한 용량이 줄어들기 때문에 처리량도 감소하므로 디스크 I/O(입출력) 등의 기타 비용은 증가할 수 있습니다. 캐싱 기능이 특히 중요한 역할을 하는 경우에는 변수 구성을 따로 분석해야 합니다.

그림 4에서 볼 수 있는 것처럼 로드 생성 클라이언트와 성능 모니터링 도구는 분석 시 서버 이외의 시스템에 위치해야 합니다. 이렇게 해야만 모니터링하는 서버에 미치는 영향이 최소화되어 보다 정확한 분석 결과를 얻을 수 있습니다.


현재 사용하는 브라우저가 인라인 프레임을 지원하지 않을 경우 여기 를 누르면 새 창에서 볼 수 있습니다.

그림 4 성능 분석을 위한 하드웨어 구성

서비스 구성은 가능한 한 성능이 가장 좋은 하드웨어를 사용하여 구축해야 합니다. 그래야만 고성능 하드웨어에서 측정한 결과를 기준으로 한 리소스 요구 사항을 저성능 하드웨어에 맞게 낮춰서 적용할 수 있습니다. 그러나 반대로 적용하면 문제가 생길 수 있습니다.

예를 들어, 다중 프로세서 확장은 거의 선형적입니다. 즉, 같은 로드가 주어지는 경우 4 프로세서 SMP 서버의 총 CPU 비용은 추가 컨텍스트 스위칭 및 버스 관리 오버헤드로 인해 2 프로세서 SMP 서버보다 클 것입니다. 500MHz의 4 프로세서 SMP 서버에서 CPU 비용을 측정하고 실제 구축 하드웨어가 300MHz의 2 프로세서 서버로 구성된다고 가정하면 다른 모든 하드웨어 특성이 변하지 않는 경우 CPU 요구 사항은 3.3 = (500MHz/300MHz)*(4프로세서/2프로세서)의 계수만큼만 증가해야 합니다. 따라서 지정된 수의 프로세서가 있는 서버의 CPU 요구 사항은 더 많은 수의 프로세서가 있는 서버에서 측정한 결과를 토대로 예측할 수 있습니다.

로드 생성

로드 생성 스크립트는 각 트랜잭션을 개별적으로 시뮬레이트하도록 작성되어야 하며, 형식은 다음과 같습니다.

do transactionsleep rand timeInterval

sleep은 클라이언트 대기열의 로드를 줄이기 위한 것이며 timeInterval은 클라이언트/서버 트랜잭션 대기 시간 범위 내에서 무작위로 선택합니다. 한 특정 클라이언트에서 병목 현상이 발생하지 않도록 여러 클라이언트로 로드 생성 스크립트를 분산시켜야 합니다.

무작위로 시간 간격을 선택하는 데 대한 자세한 내용은 Jim Gray의 The Benchmark Handbook for Database and transaction Processing Systems(Morgan Kaufman Publishers, 1992년)를 참조하십시오.

각 테스트 실행 전에 시스템을 종료하여 캐시를 비우고, 일관된 데이터 수집을 위해 시스템을 일관된 상태로 복원해야 합니다. 또한 각 테스트 실행은 최소한 런타임 "안정 상태"에 도달할 수 있을 정도로 지속되어야 합니다. 이 상태에 도달하려면 초기의 단기(시작) 비용이 투입되고, 네트워크 연결이 설정되고, 캐시가 적절히 채워지고, 주기적인 동작이 완전히 캡처되어야 합니다. 각각의 실행 중에 수집된 측정 결과는 "안정 상태"의 실행 시간에 대해 평균을 내야 합니다.

측정한 리소스 활용도 및 처리량을 수집해야 할 뿐 아니라 시스템의 경쟁 지점을 구분하는 데 도움이 되는 카운터도 모니터링해야 합니다. 여기에는 대기열 길이, 컨텍스트 스위칭, 메모리 부족 페이징, 네트워크 활용도 및 대기 시간이 포함됩니다. 특히 다음 사항에 유의해야 합니다.

  • 다중 디스크 RAID(Redundant Array of Inexpensive Disks) 어레이에서 어레이 당 평균 디스크 대기열 길이는 어레이 당 물리적 디스크 수를 초과하면 안됩니다.
  • 이더넷 네트워크의 레이어 2 CSMA/CD(Carrier Sense Multi-Access/Collision Detection) 프로토콜에서는 공유 네트워크 최대 처리량을 전달할 수 있도록 네트워크 카드 활용도를 36% 미만으로 낮추려고 합니다. 네트워크 활용도가 36%가 넘는 경우 주의해야 합니다.

Microsoft Windows 2000에만 해당되는 성능 고려 사항에 대한 자세한 내용은 David Watts,Chris Neophytou,Murat Gulver,Gregg McKnight,Peter Mitura 공저의 Tuning Netfinity Servers for Performance: Getting the Most out of Windows 2000 and Windows NT 4.0(Prentice Hall Ptr, 2000년 7월)을 참조하십시오.

동시 사용자수는 적은 수에서 시작해서 Nmax에 도달할 때까지 서서히 늘려가야 합니다. 이 수에 도달하면 트랜잭션 처리량은 최대값 Tmax에서 줄어들기 시작합니다. 이와 같은 처리량 감소는 빠른 컨텍스트 스위칭 속도, 긴 대기열 및 메모리 부족 페이징과 같은 요인 때문에 발생하며, 트랜잭션 대기 시간이 비선형적으로 변하는 시점부터 발생합니다.

이러한 관계가 그림 5에 나타나 있습니다. 이 그림에 표시된 각 지점 (O)과 (X)는 한 번의 실행을 나타내며 로드 생성 중에 데이터가 수집되는 지점입니다. Cmaxresource 는 최대 리소스 용량을 나타냅니다.


현재 사용하는 브라우저가 인라인 프레임을 지원하지 않을 경우 여기 를 누르면 새 창에서 볼 수 있습니다.

그림 5 선형 작동 범위에서 성능 측정(최대 처리량을 초과하는 로드가 생성되는 지점에서 트랜잭션 대기 시간이 비선형적으로 변함)

비용 방정식

이 절에서는 개별 트랜잭션과 전체 트랜잭션에 대한 리소스 비용을 계산하는 방법을 설명합니다. 이러한 계산 방법을 설명하기 위해 이 절에서는 다음 기호를 사용합니다.

기호
정의
Cijresource
서비스 i에 대한 트랜잭션 j의 리소스 비용
CijCPU
사용된 CPU 주기(MHz)
Cijreads
초 당 디스크 읽기 수
Cijwrites
초 당 디스크 쓰기 수
CijRAM
사용된 RAM(MB)
Cijnetwork
 사용된 네트워크 대역폭(MB/초)

각 트랜잭션의 리소스 비용

측정된 각 트랜잭션 속도(Tij)는 Cijresource로 표시되는 각 리소스의 측정된 활용도에 대응합니다. 이러한 데이터 점의 쌍들은 선형 작동 범위에서 보간(interpolate)되어 분석적 관계를 형성합니다. 이러한 관계는 리소스 활용도를 트랜잭션 속도의 함수로 나타냅니다. 이 관계가 그림 6에 나타나 있습니다.

예를 들어, CijCPU(Tij ; other)는 트랜잭션 속도가 Tij인 서비스 i에 대해 트랜잭션 j가 사용한 CPU 주기 수를 나타냅니다. 여기서 other는 다른 트랜잭션 매개 변수에 대한 자리 표시자입니다. 예를 들어, HTTP "get"의 파일 크기를 나타낼 수 있습니다.

capmod_6

그림 6 처리량(트랜잭션 속도)의 함수로서 리소스 비용을 보간하여 작성한 비용 방정식

Cijresource는 트랜잭션 속도 범위 0 <= Tij<= Tijmax에서 정의되며, Tij > Tijmax인 경우에도 하드웨어를 선형적으로 확장해야 한다는 해석과 함께 Cijresource에 대한 방정식을 계속 적용할 수 있습니다. 이 경우 이러한 해석이 유효하려면 "트랜잭션 비용 분석 방법" 절의 시작 부분에 제시된 TCA 가정이 반드시 충족되어야 합니다.

총 리소스 비용

여러 서비스가 실행되고 각 서비스에 의해 여러 트랜잭션이 처리되는 복잡한 환경에서는 리소스 활용도가 선형적으로 증가한다고 가정합니다. 방정식 2는 다음과 같이 각 리소스 및 모든 트랜잭션에 대한 총 비용을 계산합니다.

방정식 2

Ctotalresource = ĺi=1Iĺj=1J Cijresource(Tij ; other)

성능상의 이유 및 리소스 활용도가 갑자기 증가하는 경우에 대비하여 각 리소스를 최대 용량 이하로 작동하는 것이 좋습니다. 리소스를 준비할 때 이러한 점을 고려하기 위해 각 리소스에 대해 임계 요소를 도입합니다. "헤드 룸(head-room)"이라고도 하는 이 요소는 초과되어서는 안 되는 리소스 용량 비율을 나타냅니다.

다음 표에 나타난 기호는 이러한 임계 요소를 설명하는 데 사용됩니다.
기호
정의
0 < qCPU< 1
CPU 활용도 임계 요소
0 < qreads< 1
디스크 읽기 속도 임계 요소
0 < qwrites< 1
디스크 쓰기 속도 임계 요소
0 < qnetwork< 1
네트워크 활용도 임계 요소

방정식 3은 CPU 활용도 임계값을 초과하지 않으면서 해당 트랜잭션 집합을 지원하는 데 필요한 총 프로세스 수를 계산합니다.

방정식 3

CtotalCPU / ( qCPU CmaxCPU )

여기서 CmaxCPU는 프로세서 당 최대 클럭 속도이며 qCPU는 일반적으로 60~80% 사이의 값입니다.

마찬가지로 방정식 4는 필요한 총 스핀들 수를 계산합니다.

방정식 4

Ctotal reads / (qreads Cmaxreads) + Ctotalwrites / (qwrites Cmaxwrites)

여기서 Cmaxreads와 Cmaxwrites는 각각 스핀들 당 최대 디스크 읽기 수/초와 최대 디스크 쓰기 수/초를 나타냅니다. 다른 하드웨어 리소스에 대해서도 유사한 방정식을 유추할 수 있습니다.

또한 Cmaxreads 및 Cmaxwrites를 결정하기 위해 디스크 하위 시스템을 보정해야 합니다. 디스크 보정 프로세스에서는 캐시를 사용하지 않는 읽기 및 쓰기를 디스크에 대량으로 수행하여 디스크 어레이가 지원할 수 있는 최대 읽기 및 쓰기 횟수를 결정합니다. 하드웨어에서 Cmaxreads 및 Cmaxwrites는 디스크 검색 시간 및 회전 대기 시간을 가장 잘 반영하는 함수입니다.

레이어 2 CSMA/CD 프로토콜의 경우 qnetwork는 보통 이더넷 네트워크 총 대역폭의 36%로 설정됩니다.

모델 확인

실제 구축 시나리오는 사용 프로필에 의해 정의되는 혼합 트랜잭션 환경으로 구성됩니다. 확인 작업은 (1) 트랜잭션이 서로 부정적인 영향을 주지 않으면서 (2) 비용 방정식에서 추정한 리소스 비용(앞의 총 리소스 비용 절 참조)이 측정된 실제 비용을 정확하게 반영할 수 있도록 구축 시나리오를 시뮬레이트하기 위한 것입니다.

확인 스크립트

사용 프로필은 각 서비스에 대한 확인 스크립트로 변환됩니다. 원칙적으로, 모든 서비스를 호출하는 하나의 확인 스크립트만 작성해도 됩니다.

여러 트랜잭션이 포함된 단일 서비스의 경우 이 스크립트 논리를 다음과 같이 의사 코드로 작성할 수 있습니다.

count < 0
while ( count < ti )
{
if ( count mod ( ti / ni ,1 ) = 0 ) do transaction 1

if ( count mod ( ti / niJ ) = 0 ) do transaction J

sleep sleepIncrement
count < count + sleepIncrement
}
sleep rand smallNumber

여기서 sleepIncrement = GCD( ti / ni1 ,…, ti / niJ )입니다. 이 때 GCD는 GCD(가장 큰 공통 제수)이며 ti / niJ는 프로토콜 i를 사용하여 각 트랜잭션 j를 시작할 때까지 경과되어야 하는 시간입니다. 각 트랜잭션 j에 대해 이 스크립트는 사용 프로필에 정의된 서비스 세션 시간 ti 동안 정확한 수의 트랜잭션 niJ를 일률적으로 시작합니다. 명령문 sleep rand smallNumber는 트랜잭션 도달 분포를 무작위화하기 위한 것입니다.

트랜잭션 처리 시스템의 벤치마크에 대한 자세한 내용은 Jim Gray의 The Benchmark Handbook for Database and transaction Processing Systems(Morgan Kaufman Publishers, 1991년)을 참조하십시오.

로드 생성 스크립트

로드 생성 프로세스는 시뮬레이트된 각 사용 프로필에 대해 테스트가 한 번만 실행된다는 점을 제외하면 "로드 생성" 절에서 설명한 내용과 동일합니다. 이 실행 중에, 서비스 당 시뮬레이트된 사용자수는 사용 프로필에서 정의된 해당 서비스를 사용하는 동시 사용자수와 거의 같아야 합니다. 각 로드 생성 인스턴스는 하나의 서비스를 사용하는 여러 사용자의 동작을 나타내는 단일 스크립트(위의 "확인 스크립트" 절에서 설명한 스크립트같은 스크립트)를 실행합니다. 정확한 전체 사용자 로드를 생성하기 위해 로드 생성 스크립트의 여러 인스턴스가 실행됩니다.

TCA 추정값과 비교

시뮬레이트된 각 사용 프로필에 대해, 리소스 활용도 측정 결과를 "비용 방정식" 항목에 제시된 비용 방정식을 사용하여 계산한 활용도 추정값과 비교합니다. 측정한 비용과 추정한 총 비용 간의 차이가 바로 모델링 오차입니다. 그림 7은 비용 방정식 추정값과 시뮬레이션 측정값 간의 오차를 나타냅니다. 이 오차가 크면 TCA 가정이 충족되었는지 확인해야 합니다. 또한 성능 측정을 다시 반복할 것인지도 고려해야 합니다.

capmod_7

그림 7 서로 다른 세 가지 사용 프로필 A, B, C에 대한 비용 방정식 추정값과 시뮬레이션 측정값 간의 오차

시나리오

"사용 프로필" 절의 시나리오에서 사용되었던 사용 프로필에서 웹 페이지 요청에 필요한 처리량은 83번의 HTTP get/초 및 16.7개의 FTP 트랜잭션/초였습니다. 이제 이러한 리소스 비용을 "비용 방정식" 절에서 작성한 방정식을 사용하여 계산합니다.

특히, CPU 비용 방정식에서 HTTP 및 FTP 서비스에 대한 통합 CPU 비용이 CtotalCPU = 2,000MHz이고,

400MHz 프로세서가 있는 서버를 사용하여 인터넷 사이트를 구축하고 이 서버를 70% 미만의 CPU 활용도로 실행해야 하는 경우 CmaxCPU = 400MHz이며 qCPU = 70%입니다. 따라서 필요한 400MHz 프로세서의 총 수는 다음과 같이 계산됩니다.

CtotalCPU / (qCPU * CmaxCPU ) = 2000MHz / (0.7 * 400MHz) = 7.1.

이 경우 4 프로세서 서버 두 대로 필요한 로드를 지원할 수 있습니다. 다른 리소스에 대해서도 비슷한 방식으로 추정할 수 있습니다. 이 시나리오에서는 4 프로세서 서버에서 데이터를 수집했다고 가정합니다.

이러한 과정이 끝나면 확인을 위해 위의 계산에 나타난 대로 4 프로세서 서버 두 대로 시스템을 구축하고 확인 스크립트를 사용하여 적절한 로드를 생성합니다. 이 로드는 사용 프로필 예제에 나타난 것처럼 20,000명의 동시 HTTP 사용자와 1,000명의 동시 FTP 사용자를 시뮬레이트해야 합니다. 평균 85번의 HTTP get/초, 10번의 FTP put/초, 7번의 FTP get/초 및 평균 1900MHz의 CPU 활용도가 측정되었다고 가정하면 처리량 요구 사항이 충족되고 CPU 활용도 추정값의 오차는 5%보다 작아집니다.

트랜잭션 비용 분석을 사용한 용량 계획 Back to Top

사이트가 구축된 후 주기적으로 TCA(트랜잭션 비용 분석) 방법을 사용하여 하드웨어 리소스 비용을 정확하게 다시 계산해야 합니다. 시간이 경과되면서 사용량의 변화에 따라 하드웨어 리소스 비용이 증가하거나 감소할 수 있습니다. 사이트의 사용량 증가는 업무 확장, 고객의 동작 변화 등으로 인해 발생할 수 있습니다.

모든 서비스에 대해 각 트랜잭션의 리소스 비용을 결정한 후에 이 데이터를 다음 절차에 따라 용량 계획에 적용할 수 있습니다.

  1. 방정식 1을 사용하여 새로운 사용 프로필과 처리량 목표를 정의합니다. 자세한 내용은 "성능 목표" 절을 참조하십시오. 이 경우 업무 확장이나 실제 사용자 동작 변화가 고려되어야 합니다.
  2. 방정식 2를 사용하여 새로운 사용 프로필에 대한 총 리소스 비용을 계산합니다. 자세한 내용은 "총 리소스 비용" 절을 참조하십시오.
  3. 방정식 3과 4를 사용하여 용량 요구 사항을 계산하고 "가정" 분석을 수행합니다. 자세한 내용은 "총 리소스 비용" 절을 참조하십시오.

TCA 방법을 기본적으로 사용하는 용량 계획의 예제를 보려면 본 백서와 동일한 웹 페이지에 제공되는 Microsoft Commerce Server 2000 SVT 사이트 성능 특성: 트랜잭션 비용 분석(Microsoft Commerce Server 2000 SVT Site Performance Characteristics: transaction Cost Analysis) 백서를 참조하십시오. 이 백서에는 지속적인 분석 작업을 위해 각종 방정식을 통합하는 스프레드시트가 포함되어 있습니다. 이 백서를 실제 용량 계획을 세우기 위한 사례 연구 자료로 사용하십시오.

결론 Back to Top

TCA(트랜잭션 비용 분석)를 토대로 하는 이 용량 모델을 사용하여 MCIS(Microsoft Commercial Internet System), Microsoft Site Server 제품, Microsoft Commerce Server 제품 및 Microsoft Exchange 제품의 하드웨어 플랫폼 구축 요구 사항을 성공적으로 추정할 수 있었습니다. 이 모델을 사용하여 서비스를 실행할 수 있는 적절한 구성의 하드웨어를 구축하고 하드웨어를 과다하게 산정할 가능성을 줄일 수 있습니다.

부록 A - 참조 자료 Back to Top

다음 참조서에서는 일반적인 용량 및 성능 모델링에 대해 설명합니다.

The Art of Computer Systems Performance Analysis Techniques for Experimental Design, Measurement, Simulation, and Modeling
저자: Raj Jain
출판사: John Wiley & Sons, 1991

Capacity Planning and Performance Modeling: From Mainframes to Client-Server Systems
저자: Daniel Menasce, Virgilio Almeida, Larry Dowdy
ISBN: 0137895461 paperback 1999
ISBN: 0130354945 hardcover 1994
출판사: Prentice Hall, Incorporated

Capacity Planning for Web Performance: Metrics, Models, and Methods
저자: Brian Wong
출판사: Prentice Hall, 1997년 2월

Microsoft Windows 2000 Server Resource Kit
출판사: Microsoft Press, 2000년

Modeling Techniques and Tools for Computer Performance Evaluation
저자: Ramon Puigjaner, Dominique Potier
Plenum Press, 1989년
다음 참조서에서는 Sun Solaris Systems의 용량 계획에 대해 설명하지만 이해를 돕기 위해 일반적인 개념도 제시합니다.

Configuration and Capacity Planning for Solaris Servers
저자: Brian Wong
ISBN:0133499529
Prentice Hall, 1997년 2월

Microsoft Windows 2000에 해당되는 성능 고려 사항에 대해서는 다음 책을 참조하십시오.

Tuning Netfinity Servers for Performance: Getting the Most out of Windows 2000 and Windows NT 4.0
저자: David Watts,Chris Neophytou,Murat Gulver,Gregg McKnight,Peter Mitura / Paperback
Prentice Hall Ptr
2000년 7월

무작위로 시간 간격을 선택하는 데 대한 자세한 내용은 다음 책을 참조하십시오.

The Benchmark Handbook for Database and transaction Processing Systems
저자: Jim Gray
Morgan Kaufman Publishers, 1992년, 1993년

사용 프로필을 만드는 데 대한 자세한 내용은 본 백서와 동일한 웹 페이지에 제공되는 Commerce Server 2002: 사이트 용량 계획을 위한 사용 프로필 만들기(Commerce Server 2002: Creating a Usage Profile for Site Capacity Planning) 백서를 참조하십시오.

URL과 기타 인터넷 웹 사이트 참조를 포함하여 이 백서의 내용은 예고 없이 변경될 수 있습니다. 이 백서의 사용으로 인한 결과나 위험은 사용자의 책임입니다. 이 백서는 명시적 또는 묵시적인 어떠한 종류의 보증도 없이 있는 그대로 지원되며 제공됩니다. 용례에 사용된 회사, 기관, 제품, 사람 및 이벤트 등은 실제 데이터가 아닙니다. 실제 회사, 조직, 제품, 사람, 이벤트와는 아무런 관련이 없습니다. 해당 저작권법을 준수하는 것은 사용자의 책임입니다. 저작권의 권리와 별도로, 이 백서의 어떠한 부분도 Microsoft의 명시적인 서면 승인 없이는 어떠한 형식이나 수단(전기적, 기계적, 복사기에 의한 복사, 디스크 복사 또는 다른 방법)으로 또는 어떠한 목적으로도 복제하거나, 검색 시스템에 저장 또는 도입하거나, 전송할 수 없습니다.

Microsoft가 이 백서 본안에 관련된 특허권, 상표권, 저작권, 또는 기타 지적 소유권 등을 보유할 수도 있습니다. 서면 사용권 계약에 따라 Microsoft에서 귀하에게 명시적으로 권리를 제공하지 않으면, 이 설명서 제공으로는 이러한 특허권, 상표권, 저작권, 또는 기타 지적 소유권 등에 대한 어떠한 사용권도 귀하에게 부여되지 않습니다.

© 1999-2002 Microsoft Corporation. All rights reserved.

Microsoft, Visual Studio, Windows 및 Windows NT는 미국, 대한민국 및/또는 기타 국가에서의 Microsoft Corporation의 상표이거나 등록 상표입니다.

여기에 인용된 실제 회사와 제품 이름은 해당 소유자의 상표일 수 있습니다.


 

최종 수정일 : 2002년 10월 9일