분석 시스템 성능분석

분석 시스템의 성능분석은 빅데이터를 구성하는 모든 구성요소(서버, 네트워크, 데이터베이스, 응용 소프트웨어)의 효율적인 사용을 위해 성능과 관련된 모든 상태를 측정해, 최적의 서비스 품질과 분석 시스템 자원의 효율성을 유지 및 제고시키는 활동을 의미한다. 과거에는 소수의 시스템 자원들에 대해 제한된(업무) 시간 동안 제한된 기준들에 대해서만 관리해도 충분하였으나 현재는 다양한 역할을 수행하는 자원들에 대해서 다양한 기준들로 관리해야 하는 상황이 되었고, 수 초의 짧은 시간이라고 해도 핵심적인 시스템에서 장애가 발생해 사용이 불가능하게 되면 사용자에게 엄청난 불편을 주는 것은 물론이고 대외적인 이미지 손상 및 막대한 경제적 손실을 끼치는 경우를 흔치 않게 볼 수 있다. 시스템의 용량 계획에 앞서 성능관리 프로세스를 학습해 시스템 성능을 적절하게 구현할 수 있도록 한다.

• 서비스를 제공하도록 정의된 목표응답시간 내에 모든(정의된 부하량 내의) 사용자의 요청을 성공적으로 처리할 수 있는 분석 시스템의 성능을 분석한다.
• 시스템의 성능을 결정하는 지표에 대해 알아본다.
• 하이브와 같이 자체 SQL(HiveQL)을 만들지 않고, 가능한 ANSI-SQL 표준을 준수한다. 비표준 추가 기능에 대해서는 PostgreSQL 표기법과 오라클 표기법을 사용한다.
• 하이브와 같이 데이터 수정 구문(Update)은 지원하지 않는다.
• Long-Term Query뿐 아니라 Ad Hoc Query를 지원한다.

성능지표

분석 시스템의 성능을 결정하는 일반적인 지표에는 다음과 같은 항목들이 존재한다.

[표 V-2-1] 성능지표

성능지표	정의	단위	목표
응답시간	작업 처리를 요청한 시간으로부터 이를 시스템이 처리해 결과를 보여줄 때까지 소요된 시간	초	낮춤
시간당 처리량	시스템이 성공적으로 처리한 단위 시간당 요청(트랜잭션) 처리 건수	TPS/OPS	높임
자원 사용량	자원(CPU, 메모리 등)들의 용량 중 실제 사용하고 있는 값의 비율	%	높임
효율성	시간당 처리량을 자원사용량 또는 비용으로나눈 값	%/tpmC	높임

응답시간

응답 시간(사용자 응답 시간, End User Response Time)은 크게 클라이언트 시간, 네트워크 시간, 서버 시간으로 이뤄진다. 클라이언트 시간은 HTTP(HTTPS) 요청을 서버로 전송하고 서버로부터의 결과를 브라우저에 표시하기 위한 I/O(Input/Output) 및 CPU 처리시간이 포함된다. 네트워크 시간은 HTTP(HTTPS) 요청이 브라우저로부터 인터넷 서비스 업체(ISP)까지 전송되는 데 걸리는 시간, 인터넷 서비스 업체로부터 인터넷을 거쳐 웹 사이트의 서버까지 전달되는 데 걸리는 시간, 처리 결과가 반대의 경로로 브라우저에 전달되는 데 걸리는 시간으로 이뤄진다. 마지막으로 서버 시간은 웹 사이트에서 HTTP(HTTPS) 요청을 처리하기 위해 서버에서 소요되는 I/O 및 CPU의 처리시간과 내부 서버들간의 네트워크 통신 시간을 포함한다. 이 3가지 시간은 시스템의 자원들(CPU, 디스크, 네트워크)을 사용하기 위해 대기하는 시간인 경합 시간(congestion time)이 포함돼 있다. 경합 시간은 시스템이 동시에 처리해야 하는 요청건수에 따라 달라지는 데 동시 요청이 많으면 많을수록 이 경합 시간도 늘어나게 된다. 시스템의 관점에서 보았을 경우에도 응답 시간은 하나의 소프트웨어 또는 하드웨어 모듈이 타 모듈에서 제공하는 서비스를 요청한 후 응답을 받을 때까지의 소요 시간으로 정의할 수 있으므로 사용자 응답시간 = 브라우저 응답시간 + 네트워크 응답시간 + 서버 응답시간이 됨을 알 수 있다.

시간당 처리량

시간당 처리량은 일반적으로 [표 V-2-2]와 같은 방법으로 측정된다. 이를 측정할 때는 요청 (트랜잭션)의 성격을 명확히 이해해야 한다. 예를 들어, 온라인 처리(OLTP: Online Transaction Processing) 시스템의 경우 시간당 처리량은 초당 트랜잭션 처리 건수(TPS: Transactions Per Second)로 측정되지만, 트랜잭션은 처리 내용과 자원 사용량에 따라 판이하게 다르기 때문에 무엇을 하나의 트랜잭션으로 보는지를 명확히 규정하지 않으면 아무런 의미 없는 수치가 돼버린다. TPC (Transaction Processing Performance Council)는 온라인 처리 시스템에 적용되는 TPC-C 벤치마크를 제공한다. 이는 전형적인 주문 처리 시스템의 트랜잭션을 정의해 각 제품별로 1분당 트랜잭션 처리량 및 트랜잭션 당 소요 비용(tpmC)을 측정하는 것이다.
웹 시스템은 SPEC(Standard Performance Evaluation Corporation)에서 제공하는 Web96, Web99, Web2005 등의 벤치마크를 활용할 수 있다. Web96은 정적인(static) 웹페이지만을 대상으로 하였으나 Web99 이후 동적인(dynamic) 콘텐츠 및 HTTP 1.1 Persistent Connection 등을 워크로드 모델에 포함해 실 환경에 근접한 측정환경을 구현하고 있다.
OPS(Operations per Second)는 Web96의 측정단위였으나, Web99 이후 최대 동시 연결 개수가 주요 측정지표로 변경됐으며(OPS는 보조 측정 단위) 웹 정보 시스템의 경우 현재는 OPS보다는 초당 페이지 처리 건수가 더 중요한 개념으로 사용되고 있다. 한 가지 유의해야 할 점은 정보 시스템의 용량 또는 성능을 나타내기 위한 값으로 시간당 처리량을 사용할 경우에는 최대값을 사용해야 한다. 즉 시간당 처리량은 정보 시스템에 가해지는 부하량에 좌우되며 운영 중에는 최대값을 측정하기 어려우므로 일반적으로는 부하 테스트 등을 통해 산출한다.

[표 V-2-2] 시간당 처리량 측정방법

시스템	측정방법
온라인 트랜잭션 처리(OLTP) 시스템	초당 트랜잭션 처리 건수(Transactions Per Second: TPS)
	분당 트랜잭션 처리 건수 비용(TPC-C: tpmC)
웹 사이트	초당 요청 처리 건수(HTTP requests/sec)
	초당 페이지 처리 건수(Page Views per Second)
전자상거래 사이트	초당 웹 처리 건수(TPC-W : WIPS(Web Interactions Per Second))
	초당 세션 수(Sessions per Second)
라우터	초당 패킷 처리 건수(Packets per Second : PPS)
	초당 데이터 전송량(MB transferred per Second)
CPU	초당 명령 수행 건수(Millions of Instructions per Second : MIPS)
	초당 부동 소수점 계산 수행 건수(Floating Point Operations per Second: FLOPS)
디스크	초당 입출력 건수(I/Os per Second)
	초당 데이터 전송량(KB transferred per Second)
E-mail 서버	초당 메시지 전송 건수(Messages Sent Per Second)

성능지표 간의 관계

시간당 처리량이 많은 빅데이터 시스템의 경우 응답 시간이 작은 것이 보통이지만 반드시 그런 것은 아니다. 예를 들어 단일 노드로 구성된 시스템을 처리 업무를 분리해 이중화 구성하는 경우 전체적인 처리 용량이 증가돼 시간당 처리량은 증가하게 되지만 이중화 노드간의 동기화 등의 오버헤드로 인해 하나의 요청에 대해서는 다소의 응답 시간 지연이 발생하게 된다. 따라서 응답 시간과 시간당 처리량은 별개의 개념으로 인식해야 하지만 동일 시스템 내에서는 두 지표 간에는 다음과 같은 일정한 관계를 가지게 된다.

[그림 Ⅴ-2-1] 지표간의 관계

정상적인 시스템의 경우 부하량에 따른 응답 시간과 시간당 처리량의 변화는 위의 그림과 반대의 경향을 보이며, ‘Saturation Point’는 응답시간이 급격히 증가하기 시작하고 시간당 처리량이 거의 일정하게 유지되는 지점을 의미한다. 이 때의 부하량이 시스템에서 지원 가능한 최대 부하량이다. 시간당 처리량이 Saturation Point 이후 일정하게 유지되는 것이 아니라 오히려 감소(Thrashing)하는 경우도 있는데 대부분은 시스템의 자원 부족으로 인해 발생하게 된다.

성능관리 활동

분석 시스템을 구성하는 서버, 데이터베이스, 애플리케이션, 네트워크 등의 자원에 대한 운영상태관리 데이터를 수집해 세부 자원(CPU, 메모리, 디스크 I/O 등)들 및 구성요소(애플리케이션, 데이터베이스 등)들의 운영상태와 운영조건(사용자 접근 환경, 부하량 등) 등을 종합적으로 분석하고 개선이 필요할 경우 정의된 목표응답시간(또는 목표처리량)을 만족시키는 데 가장 효과적인 영역 및 구체적인 실행 계획들을 도출해 이를 수행하고 그 결과를 검증하는 활동을 포함하고 있는 것이 성능 관리다. 성능 목표를 수립하는 것이 가장 중요한 부분으로 이를 위해서는 시스템 및 조직의 목표, 투자비용 대비 효과를 고려해야 한다. 다음의 그림은 분석 시스템의 성능과 빅데이터 처리의 생산성간 관계를 보여주고 있다.

[그림 Ⅴ-2-2] 분석 시스템 성능과 빅데이터 처리의 생산성 관계

앞 그림에서 보듯이 분석 시스템의 응답 시간을 개선하는 데에 따라 생산성이 선형으로 증가하지는 않으므로 최적의 성능 목표를 정의하는 것이 중요하다. 다음 그림과 같은 방법으로 최적의 성능 목표를 결정할 수 있다.

[그림 Ⅴ-2-3] 최적의 성능 목표 결정

시스템 파라미터 변경, 애플리케이션 및 데이터베이스 튜닝 등이 적합하지 않거나 효과가 없거나 조직의 신규 업무 요구사항에 의해 기 정의된 부하량(Workload Model)을 장기적으로 초과할 것으로 예측되는 경우에는 하드웨어와 소프트웨어 자원 증설 및 증설 결과 예측(시뮬레이션) 등을 포함하는 용량계획 수립 활동도 넓은 의미에서 성능 관리에 포함된다고 볼 수 있다. 유지, 관리 및 개선 활동은 단지 성능상의 문제점이 발견돼 이를 해결하는 활동으로서 수행되는 것이 아니라, 정보 시스템이 운영되는 동안 지속적으로 수행하도록해 사전에 문제가 발생되지 않도록 예방하는 활동이 더욱 중요하다. 이를 통해 궁극적으로 업무 처리의 효율성 확보 기반을 다질 수 있다.

용량계획

일반적으로 용량관리(Capacity Management), 용량계획(Capacity Planning), HW 규모산정(HW Sizing, Capacity Sizing)이라는 용어를 명확히 구분하기는 쉽지 않으나, 이들 용어 간에는 분명한 차이가 있다.
용량관리는 ‘비즈니스 요구사항을 충족하기 위한 현재와 미래의 용량 계획을 수립하고 비용(Cost)과 용량(Capacity)의 균형을 맞추는 것’으로 정의할 수 있다. 용량관리 대상은 시스템, 네트워크 등 조직 내의 HW 자원만으로 국한하는 것이 아니라, 전사적인 자원(Resource)을 관리 대상으로 하며 일시적이 아닌 지속적인 관리에 중점을 두고 있다.
규모산정은 ‘기본적인 용량과 성능 요구사항이 제시되었을 때, 그것을 시스템 요구사항으로 변환하는 것’을 말한다. 따라서 규모산정 시에 결정하는 요소로는 서버의 CPU 형태나 수, 디스크 크기나 형태, 메모리 크기, 네트워크의 용량 등의 요소를 들 수 있다.
용량계획이라 함은 개략적인 시스템 아키텍처와 응용 업무를 기반으로 시스템에 요구되는 성능 요구사항과 성능을 결정하기 위한 계획으로 이해할 수 있다. 일반적으로 이러한 용량계획은 클라이언트 애플리케이션의 형태, 이들 애플리케이션들에 접근하는 사용자의 수, 클라이언트 애플리케이션의 동작 특성, 서버 시스템에 대응하는 오퍼레이션의 형태, 서버 시스템에 접속하는 동시 접속자의 수, 서버 시스템에 의해 수행돼야 하는 피크 율, 피크타임 하에서의 여유율 등과 같은 사항을 다루고 있다.
시스템의 아키텍처와 응용 기반을 전제로 용량 요구사항과 성능을 결정하는 용량계획은 실제 업무와 응용을 기반으로 수학적인 방법론을 사용해 도입하고자 하는 시스템의 용량을 계산해 시스템 규모를 산정하고 있다. 다시 말하면 용량계획은 조직이나 시스템의 관점에서 지속적인 시간성을 갖고 개략적인 시스템 아키텍처와 응용 업무를 기반으로 시스템에 요구되는 성능 요구사항과 성능을 결정하는 계획을 의미한다.

• 적합한 용량 계획을 세우기 위해 서버, 데이터베이스, 네트워크, HW, 응용 프로그램과 같은 여러 리소스 영역을 고려한다.
• 인증, 콘텐츠, 구축과 같은 논리 영역에 대한 검사도 병행해야 한다.
• 사이트 용량 요구 사항은 하향식으로 계획하며, 원하는 비즈니스 유형, 사이트 사용 대상자, 사이트 방문자 수를 고려해 계획한다.

용량계획의 정의

일반적으로 시스템 용량계획은 시스템의 아키텍처와 응용 기반을 전제로 성능 요구사항과 성능을 결정한다. 용량계획은 비용 제약적인 상황에서 대상 시스템이 내외부 고객을 위한 서비스 수준 협약(Service Level Agreements)을 만족하도록 시스템 리소스의 양을 결정하는 프로세스를 뜻한다. 또한 IT 인프라스트럭처가 시시각각 변하고 있는 비즈니스 요건들을 비용 효율적으로 수용할 수 있도록 보증하는 계획 활동이다. 컴퓨터 시스템이 급변하는 비즈니스 상황에 맞춰 복잡해 짐에 따라 IT 자원을 효율적으로 관리해야 하는 필요성에 의해 크게 부각되고 있다.

[그림 Ⅴ-2-4] 용량계획 관련 개념 관계

용량계획의 효과

비용 측면에서 용량계획은 비즈니스 요구사항을 적절한 비용으로 신속히 대처 가능하다는 점과 전체 운영비용을 절감 가능한 점, 그리고 하드웨어 투자 비용 효율화가 가능하다는 점 등의 효과를 제공한다. 운영 관리 측면에서는 시스템 기존 리소스 사용률의 향상 가능, 애플리케이션 효율성 향상 가능, 서비스 품질 향상 가능, 서버 통합(Server Consolidation) 달성 가능이라는 효과를 제공한다.

용량계획의 유형

크게 2가지로 구분 지을 수 있다. 첫 번째는 서비스 측면에서의 용량 계획과 두 번째는 리소스 측면에서의 용량계획이다. 서비스 용량 계획은 비즈니스의 확장성을 고려해 서비스 운영 측면에서의 용량 계획을 의미하고, 리소스 용량 계획은 IT 인프라스트럭처의 개별 구성 요소 측면에서의 용량 계획을 의미한다.

용량계획 프로세스

분석, 설계, 이행, 평가와 같은 4가지 단계로 구분 지을 수 있다.

[그림 Ⅴ-2-4] 용량계획 프로세스

분석

분석 프로세스에서는 요구사항과 현행 시스템에 대해 분석을 처리한다. 요구사항을 수집·정의하고, 부하를 분석하고 리소스를 모니터링하는 단계다. 요구사항 분석은 용량 계획을 통해 얻고자 하는 요구사항들을 파악하는 과정이다. 여기서 수집하는 대상 정보는 기업의 비즈니스 동향 및 향후 계획, 재정 계획, 기업의 IT 전략 및 계획, 예산 규모, 기업의 기존 성능 관련 장애 관리 프로세스, 기업의 기존 서비스수준협약(SLA) 관련 프로세스, 지원 도구, 보고서와 같은 정보를 수집해 현행 시스템을 분석한다. 대상 시스템에 대한 성능 기준선(Baseline)을 산정해 기준 데이터로 사용하기 위함이며, 적어도 6개월 이상의 워크로드 및 리소스 사용량 현황 데이터가 필요하다.

설계

SLA 체결과 같은 단계를 나타내는 프로세스다. SLA 체결을 위해 주요 서비스를 정의하고 주요 평가항목을 정의하며, 목표치를 정의한다. 용량 계획 관련 요구사항에 대한 만족도를 검증하기 위해 수립하며, 대상 시스템에 대한 서비스, 트랜잭션 정의, 주요 평가항목 정의, 목표치 설정으로 구성된다. 서비스는 비즈니스 프로세스를 의미하는 것으로 중요도와 우선순위를 고려해 설정하고, 서비스는 최종 사용자의 행위 단위를 기준으로 트랜잭션으로 세분화한다.

이행

부하를 모델링하는 프로세스다. 부하를 예측하고 응용 애플리케이션을 사이징한다. 분석 시간 및 소요 비용에 따라 다음과 같이 구분된다.

[표 V-2-3] 이행 프로세스에서의 구분

구분	정확도	소요비용	신뢰도	비고
단순 계산 모델	하	적음	낮음	엑셀 이용 가능
선형 회귀 분석 모델	중	적음	높음	엑셀 이용 가능
큐잉 모델	상	많음	높음	큐잉 모델링 도구 필요
시뮬레이션 모델	상	많음	높음	시뮬레이션 도구 필요

평가

앞선 프로세스를 통해 정의한 용량계획의 결과보고를 처리하는 프로세스다.

정밀한 용량

성능 분석을 통해 CPU 및 메모리 사용, 스왑(swap) 비율, 디스크 I/O 비율 및 대기 시간 등을 포함한 시스템의 데이터 영역을 다각도로 측정해야 한다. 이 데이터를 종합적으로 분석해 현재의 하드웨어 구성으로 서버 성능을 향상시킬 수 있는 방안을 모색하고, 시스템 자원을 추가해야 하는 부분을 파악한다. 분석을 통해 작업 유형에 따른 자원 소비량과 전체적인 자원 로딩 비율을 파악할 수 있다. 서버의 성능 분석은 고성능 IT 환경을 위한 첫 번째 수행 단계이며, 보다 정밀한 용량계획 분석을 위한 사전 작업이다.

[표 V-2-4] 용량계획 산정기준

구분	산정근거
CPU	- 기본 분당 트랜잭션(tpm-C) - 피크타임 보정율 - 애플리케이션 복잡성 보정율 - 시스템 소프트웨어 부하 보정율 - 확장대비 보정율: 사용자 및 트랜잭션 증가율을 감안한 여유율 확보
CPU	- 기본 메모리 소요량: 시스템 영역, 사용자, 상용 소프트웨어 등이 요구하는 메모리 소요량 - 개발 애플리케이션이 요구하는 메모리 소요량 - 향후 사용자 및 트랜잭션 증가율을 감안한 메모리 여유율 - 기타 추가 부하에 따른 메모리 소요량
CPU	- 시스템 및 SWAP 영역의 디스크 사용량 - 파일 시스템 오버헤드를 고려한 디스크 여유분 - 애플리케이션 및 데이터 영역 - 파일 시스템 오버헤드를 고려한 디스크 여유분 - 데이터베이스 오버헤드를 고려한 디스크 여유분 - Array RAID 1+0 방식 적용 시의 디스크 사용분

CPU 용량 계획 및 사례

동시사용자수 * 분당 트랜잭션 (사용자수 * 트랜잭션 복잡도(50%) ) + 인터페이스(가중치 %) * 네트워크 보정(30%) * 피크타임 보정(50%) * I/O 부하(20%) * 년간 업무증가 및 여유율(연 20%)

[표 V-2-5] CPU 용량계획 사례

구분		항목	계산값	수식	산정근거
일 발생 건수		A	104,960		실제 분석 결과
일 트랜잭션 처리 수		B	629,760	A*6	건당 트랜잭션(조회 15건, 저장 1건)
연계업무 가중 부하 보정		C	3,776,560	B*6	트랜잭션 당 연계업무 처리 건수
분당 트랜잭션 수		D	7,872	C/24H/60M	24시간 기준 (일 Txn/24/60)
보정계수	Peak 시 보정	E	15,744	D*2	Peak Time을 대비한 2배 보정율
	네트워크 보정	F	20,467	E*1.3	원격지 사용에 따른 시간 손실의 보정
	애플리케이션 복잡도	G	26,607	F*1.3	애플리케이션 복잡도에 의한 보정율
	DB 크기 보정	H	34,590	G*1.3	DB크기에 따른 영향 보정
	클러스터링 예비율	I	51,884	H*1.5	클러스터링을 대비한 보정 계수
	확장 예비율	J	67,450	I*1.3	시스템 확장을 고려한 보정 계수
	작업부하 보정	K	80,940	J*1.2	최대 작업 부하를 가장한 보정 계수
	기타작업 보정	L	105,221	K*1.3	On-line과 Batch 작업 동시 수행시 부하
	시스템 여유율	M	136,788	L*1.3	30% 시스템 여유율
계(tpmC)			68,394		서버당 tpmC(DB서버 1대 기준)

이 CPU 용량산정 사례는 Enterprise Model의 tpmC 값 21871.90을 기준으로 한 기업의 데이터베이스 서버의 트랜잭션량을 분석한 결과이다. 용량산정시 고려되었던 핵심 기준은 1000만명의 고객이 동시에 Access 할때의 Job Load량의 Inflation이었다. 기준이 되는 일 발생 트랜잭션 처리 수(629,760)는 DB 엔진을 대상으로 분석한 결과 값이며, DB 크기와 트랜잭션 분석(조회 15: 저장 1건)의 비율이 적용됐다. CPU당 처리할 수 있는 분당 트랜잭션 양을 비교한 결과 1000만 고객을 대상으로 할 경우, 현재 트랜잭션의 3배를 가중한 결과 현재 CPU 사용률(Idle Time 90% 이상)을 고려해 8EA의 CPU 구성으로 결정했다. 물론 이런 구성이 완벽한 CPU 용량산정이라고 볼 수는 없지만, 애플리케이션 개발업체의 검증된 보정률과 하드웨어 공급사의 시스템 사양을 기준으로 최대한 객관적인 수준의 사이징을 유도했다.

① 메모리 용량 계획

{(OS Kernel(100M) + [SGA()] + 사용자수 * 5MB) + [Webserver()] + 인터페이스(가중치 %) } + 여유율(30%)

빅데이터 시스템에서 데이터베이스 서버의 메모리 산정 시 가장 중요한 것은 데이터베이스 인스턴스 메모리와 그 여유율, 그리고 동시 접속자들의 세션 수에 비례하는 Private Memory의 총합이라고 볼 수 있다. 데이터베이스 엔진의 특성이 메모리 용량계획의 관건이라고 볼 수 있다.

② 애플리케이션 서버 디스크 용량 계획

{OS Kernel(공급사 표준값) + [Pkg(공급사 표준값)] + [Web Server(공급사 표준값)] + Memory Swap(real memory의 2배) } * 여유율(30%)

③ DB 서버 디스크 용량 계획

{(Data file() + archive file() + RAID 보정} * 여유율(30%)

[표 V-2-6] 디스크 용량계획 사례

구분	항목	계산값	수식	산정근거
운영체제 탑재	A	1,024	1,024	운영체제 설치용
Swapping 영역	B	8,192	8,192	메모리의 100%
시스템 소프트웨어	C	1,024	1,024	시스템 관련 소프트웨어 1GB로 예상
RDBMS 엔진	D	4,096	4,096	오라클 SW(엔진) 설치·관리 공간
기타 소프트웨어	E	5,120	5,120	응용 프로그램 추가 시 예상 공간
소계	F	19,456
파일 시스템 오버헤드	G	1,536	F*1.1	전체 파일 시스템의 10%
예비율	H	4,608	G*1.3	여유율 30%
Oracle Data + (Raid 1+0)	I	15,360	H*2	오라클 데이터 저장 영역(미러링 구성)
디스크 포맷율	J	2,304	I*1.15	디스크 포맷율 대비 15% 추가
합계(MB)		43,264

이 시스템의 인터널 디스크로 구성된 데이터베이스 서버의 저장 공간은 총 64GB이며, 이 중 오라클 데이터를 저장하기 위한 할당된 공간은 24GB(24GB 중 13GB 사용, 사용률 55%)로 분석됐다. 이때 사용 공간에 대한 용량산정은 Raid 1+0로 구성할 것인지, Raid-5로 구성할 것인지에 따라 많은 편차를 보일 것이다. 레이드 구성방식이 성능에 미치는 영향 역시 간과할 수 없다. 또한 데이터 및 트랜잭션이 세 배 이상 증가하는 1000만 고객 시점에 디스크 I/O 병목현상을 예상해야 한다. 따라서 현재의 I/O 스루풋과 활용율(Utilization)을 고려해 속도가 빠른 외장형 디스크 어레이를 적용해야 한다. 현재 초당 I/O 양이 5.46mb/S인 것을 감안했을 때, 앞으로 3배의 I/O 양이 늘어났을 경우 16.38mb/s를 처리할 수 있는 고성능의 외장형 디스크 어레이가 필요하다.
이상과 같이 빅데이터 시스템을 구성하는 세 가지 펙터(CPU, 메모리, 디스크)에 대한 용량계획의 일반적인 규칙들과 사례를 살펴보았다. 최근 용량계획에 영향을 미치는 새로운 이슈로 등장한 것이 바로 SLM(Service Level Management)이다. 시스템이 어떤 부품들로 구성됐는지, 어떤 데이터베이스가 운용되고 있는지, 백본 네트워크가 어떻게 구성돼 있는지도 중요하다. 그러나 고가용성 시스템을 구성하는 경우에도 SLM이 적용됐듯이, 용량산정의 더 근본적인 기준은 비즈니스 목표를 달성하기 위한 서비스 레벨에 맞춰져야 한다는 것이다. IT 인프라스트럭처 전체를 놓고 하나의 서비스가 완벽하게 딜리버리될 때까지 서비스 레벨이 조율되고, 이에 따라 고가용성 시스템의 용량계획도 이뤄져야 한다.