용량산정이란 - 클라우드, 가상화 시대에 tpmc가 왠말이냐

최근 업무도 그렇고 후배를 통해 비슷한 자문 요청이 오기도 하는데

 

 - 용량산정을 어떻게 해야 하는지에 대한 내용이다.

 

과거, 대략 한 20년 전부터 10년 전까지의 용량산정은 하드웨어의 성능 측정치에 의존했던걸로 기억한다.

 

예를 들어,

사업팀에서 설계한 서비스는 대략 어느정도의 동시사용자, TPS를 수용해야 한다는 목표가 있고

설계팀은 이를 토대로 시스템의 용량(capacity)를 산정해야 한다

 

그 시절의 OLTP에 필요한 SW는 선택의 폭이 딱 다음 정도인데,

 - AIX, HP-UX, Solaris 등 Unix 서버

 - Tuxedo, Tmax 등의 TP, 아니면 J2EE 기반의 WAS - WebLogic, Jeus, WebSphere, JRun, OC4J 정도

 - Presentation Layer, 또는 Proxy 역할을 수행할 WEB - Apache Web Server, iplanet, IIS

 - Oracle Database, SQLServer, DB2, 하나가 뭐였드라.. SQLServer의 origin에 해당하는게 있었는데...

 

이러한 인프라 SW를 기반으로 benchmarking된 HW의 성능 수치가 바로 tpmc이다.

tpmc -> Transaction per minute, C type

HW과 특정 SW에서 분당 처리할 수 있는 트랜잭션 수

 

최근 이 tpmc 기반 용량 산정때문에 조금 골치가 아픈데,

솔직히 답답한게 tpmc를 기반으로 하는 용량산정은 x86, 클라우드, 컨테이너를 주로 사용하는 현대? 시스템에서는 의미가 없다.

라는 것이다.

 

내가 그렇게 생각하는 이유가 뭐냐면,

1. tpmc는 솔직히 공인 수치가 아니고, 특정 기관(TPC.org)에서 benchmarking한 참조 수치이다.

2. 최근 HW업체는 자신의 HW의 tpmc 수치를 제시하지 않는다. 최근 -> 한 10년 넘었음

3. tpmc는 CPU(ex. Intel Xeon Gold 6252 등)의 단위 성능 수치가 아니다. 이건 flops 뭐 이런걸로 따져야 하지 않나?(슈퍼컴처럼)

4. tpmc 리포트를 보면, 이렇게 되어 있다. 이 내용으로 현재의 시스템 용량산정이 가능할 것 같지 않다.

   - [몇 년도에] [어떤 CPU를 사용하는] [어떤 벤더사의 HW에서] [어떤 SW를 돌려서] 나온 결과가 [몇 tpmc] 입니다.

TPC.org에서 다운로드 받은 TPC-C type 보고서 - tpmc

위 내용을 보면, 이 tpmc 수치로 과연 현재 우리가 만들고자 하는 시스템의 용량을 산정할 수 있을까 하는 의구심이 든다.

 

현재의 아키텍처를 보면,

1. m3.large spec, 또는 vCore 10개, 10GiB 메모리

  - 어떤 CPU를 쓴다는 명시 없음 그냥 가상 코어이며 가상 코어가 물리 코어 대비 몇 %의 over commit 한다는 내용도 거의 없음

2. 컨테이너, Kubernetes

3. Linux

  - 오픈소스, 레드햇 같은 상용 리눅스도 tpmc를 제공하지 않음

4. nginX, HAproxy, Springboot

  - Tuxedo 같은 TP는 커녕 WAS도 잘 안씀, 물론 Springboot가 WAS 역할을 하나, WebLogic, Jeus 같은 J2EE 엔진과 비교해 보면 완전 다른 개념임

  - 알리클라우드에서 자기네 Aliyun Linux에 nginX로 tpmc 산정한 리포트는 봤는데..최근 주로 사용되는 SW를 가지고 한 케이스는 그게 유일했음

5. mongoDB, PostgreSQL, mySQL

  - NoSQL 은 고사하고  PostgreSQL, mySQL 가지고 tpmc를 산정한 HW 자료가 있던가?

 

이런 아키텍처로 개발할 건데, 이걸 tpmc 자료로 용량 산정하고 HW 산정한다고 하면

일단 기반 데이터 부터 신뢰도 가 없고, 이를 환산하는 방식 역시 마찬가지라고 생각한다.

 

- 그럼 대안은?

실제로 클라우드 향으로 시스템을 설계하는 다른데서는 어떻게 하는지 모르겠지만,

1. 초기 설계시 일반적인 구성 후 Autoscale을 활용해서 가변적인 용량을 확보

   -> 이 방안은 이론적으로는 심플하고 합리적인데, 사업을 기획하는 입장에서는 초기 투자비를 산정하기가 어렵다.

   -> Autoscale이라는게 대안이 될 수 있는지는 약간 미지수이다.

2. 비슷한 아키텍처의 선행 시스템이 있다면 이를 기반으로 용량을 역산정하는 것도 방법이 될 듯

   -> 없으면 1번으로 ㅎ

 

- 클라우드, 컨테이너 등 최신의 인프라에 대한 새로운 기준이 필요, 뾰족한 대안은 마땅히 없지만..

그냥 쓴 내용이긴 한데, 요지는 tpmc라는 기준으로 현재의 클라우드, 가상화, 컨테이너 기반의 아키텍처 용량을 산정하는 것은 무리가 있다라는 것이고 이것이 의사결정권자(decision maker)를 투자비용 측면에서 설득하기 위한 논리는 될 수도 있으나 실무 입장에서는 납득이 어렵고 신뢰하기 힘든 요소라는 것이다.