제목 : Re: 웹기반 시스템하에서의 용량산정 이슈 글쓴이: 이원영(javaservice) 2002/04/30 03:06:57 조회수:1442 줄수:166 안건국님, 겸사겸사 보내주신 사이징에 관련한 문서는 저 역시 요긴하게 사용하겠습니다. 조만간 H/W용량산정에 관한 실질적인 국내표준을 만들고자 하는 것이 저의 최근 관심사 입니다. 보내주신 자료에 저의 현재까지의 고민을 몇가지 첨언하고자 합니다. 1. tpmC 의 기준이 되는 TPC-C의 transaction단위가, TPC-C 타입의 규정된 응용어플리케이션 유형 일진데, 이것이 최근의 웹기반 시스템의 transaction단위와 그대로 맵핑되지 않는다는 것이 일반적입니다. 사실, 여기서부터 모든 것이 무너져 내립니다. 특히, 웹기반 시스템에서는 도대체 무엇이 1 transaction 단위냐라는 논란이 끊이질 않고 있습니다. EJB의 method 단위일수도 있고, JSP model 2 에서 servlet의 호출건일 수도 있고, servlet 이든 JSP이든 사용자의 버튼 push에 의한 1request 단위가 될 수도 있으며, 심지어 J2EE의 JTA transaction 단위 즉, commit/rollback 단위로 하자는 의견 등등 다양합니다. 그러나, 현실적으로 가장 구하기 쉬운 사용자의 명시적 호출에 의한 1-request 단위를 1-transaction으로 보자는 것이 현실적인 면에서 저의 주장입니다. 2. 하루에 300만건의 transaction(?)이 있다 했을 때, 이를 무조건 24*60 으로 나누거나, 하루 8시간 계산해서 8*60으로 나누어 필요 tpmC를 구하는 것이 과연 적절하느냐의 지적인데, 웹기반시스템을 비즈니즈 도메인을 분류해서 실질적인 경험치를 보면 천차만별입니다. "일반화"의 가치가 떨어지는 것이지요. 자바서비스넷 프로젝트 실무컨설팅 게시판에 최근 꾸준히 각 사이트의 이러한 트렌젝션 분석자료를 올리고 있습니다. 읽어 보세요. 하루 HIT량 대비 분당 최대 HIT량의 비율이 과연 위와 같은 단순한 공식으로 도출될 수 있는지를 확인해 보세요. 결코 그렇지 않음을 확인할 수 있을 것입니다. 업무에 따라 달라지고, 그 사이트의 특화된 특성이 있는데, 이는 사이트마다 다르다는 결론을 얻었습니다. 따라서, 용량을 산정할 사이트의 업무적 특성과 가장 유사한 타사이트의 경험치를 통해서 도출하거나, 이미 존재하는 기존 시스템의 확장의 경우에는 실질적인 수치를 구해서 도출해야 한다는 주장입니다. 3. 용량산정을 위한 Input으로, "전체사용자수"는 하등의 연관이 없다는 것이 저의 지론입니다. 즉, 하루에 몇명이 다녀가느냐는 분당 최대 트렌젝션 건수와는 하등의 맵핑관계가 없다는 것이지요. 예를 들어, 인터넷뱅킹업무의 경우, 하루에 수십만명이 다녀가지만, 기껏 5분-10분밖에 시스템을 사용하지 않습니다. 반면, 보험사의 Tele marketer를 위한 TM시스템의 경우, 하루 200명이 다녀가지만, 그 200명이 정신없이 하루종일 사용합니다. 결국, 하루에 몇명이 다녀가느냐에 상관없이, 일중 최대 동시단말사용자수가 몇명이고, 그 동시단말사용자가 평균적으로 몇초 간격으로 호출을 발생하여 그래서 분당(혹은 1초당) 최대 호출건수가 얼마냐라는 것이 더욱 용량산정에 중요하다는 것이지요. 4. "동시사용자"란 용어를 언급하고 있습니다. "동시사용자(Concurrent User)"의 정의를 무엇으로 언급하고 계신지요? 국내 IT업종에 종사하는 대부분의 IT guys들은 "동시사용자(Concurrent User)"를 "Active User"로 사용하고 있습니다. 즉, 호출을 실제 발생하여 아직 응답을 받고 있지 않은 사용자수, 혹은 현재 시점에서 해당 서비스가 수행 중에 있는 요청의 개수로 언급하고 있다는 것이지요. 이러한 정의 하에서라면 이 수치는 사실 용량산정에 하등의 맵핑관계를 가질 수 없다는 것이 최근의 저의 이론 중 하나입니다. tpmC에서 언급하고 있는 것은 궁극적으로 분당 트렌젹션 건수 입니다. 분당 트렌젝션 건수의 의미는 1분동안 몇건이 처리되느냐의 문제라는 것입니다. 즉, 1분 사이에 몇 건의 호출이 예상되느냐가 중요하다는 것인데, 이는 위의 "Active User"와 관계가 있는 것이 아니라, Active User + Inactive User 의 합으로 표현되는 "동시단말사용자수(Concurrent Terminal User)"와 더욱 깊은 정비례 상관관계를 맺습니다. 예를 들면, 200명의 동시단말사용자수가 있을 때, 각 사용자들이 평균적으로 20초간격으로 호출을 발생한다면 서버측에서는 200명/20초 = 10 TPS(Transaction Per Second)가 되고, 이는 600 TPM(Transaction Per Minute)의 빈도로 호출이 들어온다는 것이지요. 그러면 왜 20초 이겠는가라는 의문이 들 수 있는데, 이는 각 사이트의 업무적 특성과 사용자들의 호출패턴에 의존하는 수치이며, 이는 경험적으로 자바서비스넷의 실무컨설팅 게시판의 각 사이트 경험자료에서 항상 언급해 둔 수치들이니 참고하시면 될 것입니다. "Active User"의 개수가 해당 사이트의 단위시간당 호출건수인 "부하량"과 관계가 없다는 증명을 간단히 해 보겠습니다. 아래의 도표는 서로 다른 업무적 특성을 갖는 시스템 A,B가 있는데, A시스템에는 응용 어플리케이션 a가, B시스템에서는 a와는 특성이 다른 응용어플리케이션 b가 각각 단 하나씩만 탑재되어 있다고 가정해 보겠습니다. 또한 동일한 수치의 서로다른 동시단말사용자 100명이 각각 A와 B 시스템을 독립적으로 사용하고 상태에서, 머신 A,B에서의 특정 시점에서 Active하게 서비스하고 있는 개수를 10초 간격으로 기록해 둔 수치입니다. time A B ------------------ 13:01:00 9 19 13:01:10 10 21 13:01:20 8 23 13:01:30 11 19 13:01:40 7 18 13:01:50 12 22 ...... . . 우리는 위 모니터링 된 결과를 두고, A시스템의 동시사용자(이때의 의미는 Active User)가 A는 대략 10명, B는 20명이라고 지금껏 판단해 왔습니다.(그렇죠?) 그런데, 어떻습니까? 각각 A,B시스템에는 동일한 동시단말 사용자 100명이 동일하게 평균적으로 20초 간격으로 호출을 날리고 있었을 뿐입니다. 그렇다면 도대체 A에 탑재된 응용어플리케이션 a와 B시스템에 탑재된 응용어플리케이션 b가 어떠하길래 위와 같은 결과가 나올 수 있을까요? 가정키를 a 어플리케이션의 특성은 Thread.sleep(2000) 와 같이 아무것도 하지 않지만 절대적인 응답시간 2초의 응답시간을 갖고 있는 것이고, b 어플리케이션의 경우는 Thread.sleep(4000);과 같이 절대적인 응답시간 4초의 응답시간을 갖는 특성이라고 가정해 보겠습니다. 100명이 각각 20초 마다 한번씩 호출한다고 가정했으니, 서버측에는 1초당 5회의 트렌젝션이 발생하게 됩니다.(100명/20초= 5 TPS). 1초당 5개의 호출이 들어오는데, 시스템 A의 경우 각 호출은 절대적인 응답시간 2초를 기록하고 있으므로, 1 2 3 4 5 6 ---> time(sec) +---------+---------+---------+---------+---------+------ --------------------- --------------------- --------------------- --------------------- --------------------- --------------------- --------------------- --------------------- --------------------- --------------------- --------------------- ................................ 위와 같이, 1초당 5개씩 즉, 이상적으로 0.2초간격으로 한번씩 호출이 발생하고, 각각은 2초간의 응답시간을 보이고 있는 이상적인 상황을 예상해 볼 수 있고, 결국, 특정 시점에 칼로 무자르듯 잘라 보면 해당 시점에 돌고 있는 서비스의 개수는 10개라는 사실을 확인할 수 있습니다. 반면, 시스템 B에 탑재된 b 응용어플리케이션의 경우는 어떠하겠습니까? 1초당 5개씩 호출이 들어오는 것은 동일한데, 절대적인 응답시간이 2초의 2배인 4초 이므로, 결국 특정시점에 돌고 있는 서비스의 개수는 20개가 될 것이라는 추론을 쉽게 할 수 있습니다. PS:만약, Thread.sleep(2000) 가 아니라, Thread.sleep(500) 즉 0.5초라면 어떻겠습니까? 수학적으로, 1초당 호출건수 t(tx/sec, TPS)개, 평균응답시간 r(sec) 하에서, 특정시점에 수행중인 개수 n 은, n = t * r 으로 나타납니다. 즉, 평균응답시간이 만약 0.5초라면, 5 TPS의 환경하에서는 Active User의 개수는 2.5개( 5(TPS) * 0.5(sec) = 2.5개) 가 될 것입니다. 이제, 원점으로 돌아와 반문해 보겠습니다. 특정시점에 수행하고 있는 개수 즉, 지금껏 "동시사용자(Concurrent User)"란 용어로 사용된 Acitve User 의 개수가, 해당 사이트의 부하와 어떤 비례관계가 있습니까? 해당 사이트의 부하는 무엇이 부하이던가요? 단위시간당 호출된 건수 아니었던가요? TPS, TPM, 혹은 tpmC 라고 표현된 이 모든 수치가 의미하는 바는 어떤 일정한 시간동안 처리된 건수를 의미합니다. 위의 경우, 동일한 동시단말사용자 100명이 각각 20초 간격으로 호출한다는 가정하에서라면, 100명/20초 = 5 TPS, 즉 초당 5건의 호출이 들어온다는 것이고, 이는 5(tx/sec) * 60 = 300 TPM, 즉 1분당 300건이 불려지는 해당 사이트 부하량의 수치적 기준이 되는 것이며, 따라서, 두 시스템 A,B는 동일한 부하량을 갖고 있는 셈입니다. 그러나, 응용어플리케이션의 성능에 따라 Acitve User의 개수는 위처럼 서로 달라질 수 있다는 것입니다. 따라서, 용량산정, 즉 1분당 호출건수를 측정함에 있어서 가장 중요한 수치는 특정 시점의 "동시단말사용자수(Concurrent Terminal User)"이고, 이것을 웹사이트에서 현실적으로 측정하는 방법을 찾아내었습니다. 5. 과거 C/S환경의 tpmC는 경영정보(MIS) 시스템의 특징을 갖는 OLTP성 업무 시스템에 적합한 기막힌 조건이었습니다. 그러나, 최근의 웹기반시스템으로 전환이 되면서 웹기반 시스템의 특징이 항상 MIS성 OLTP만 존재하는 것이 아닙니다. 너무나 다양한 비즈니스 도메인으로의 확장이 있었습니다. 여기서 용량산정의 핵심적인 관점을 하나 놓치고 있는 것이 있습니다. 바로 어플리케이션 관점의 성능입니다. 예를 들어, 아무리 부하를 주어도, CPU사용률은 30%를 넘지 않는데, 더이상 성능 (단위시간당 최대처리건수)이 올라가지 않는다거나, CPU나 메모리는 충분한데도 동시 단말사용자수가 증가하면서 웹사이트가 벅벅 죽어나가는 경우를 너무나 많이 보아 왔습니다. 무엇 때문에 그렇습니까? 해당 사이트가 최대로 수용할 수 있는 동시 단말사용자수는 비단 H/W적 용량에만 기반을 두지 않는다는 것이지요. 수 백개의 응용 어플리케이션은 각자 고유한 최대성능(단위시간당 최대 처리건수)이 서로 다릅니다. 수백개의 어플리케이션들이 수많은 사용자들에 의해 어떤 응용어플리케이션이 얼마나 더 높은 빈도로 호출되어지느냐에 따라, 해당 사이트의 성능은 급격하게 달라진다는 것입니다. 결국, 현재의 H/W, S/W 아키텍쳐하에서, 전체를 100%라 했을 때, 오늘은 최대로 몇 %를 사용했느냐, 즉, 현재 사용한 "성능지수(가칭)"를 계산해야만 향 후 증설을 위한 정확한 용량이 나올 수 있다는 것이고, 이러한 "성능지수(가칭)"는 결코 H/W의 CPU, 메모리에 기반한 용량에만 국한되지 않는다는 것입니다. 이처럼 전체 한계성능을 100%로 두었을 때, 현재의 "성능지수"를 계산하는 방법에 관한 이론은 아래의 글에 초기 고민의 산물을 조심스럽게 올려 두었습니다. PS: [강좌]웹기반시스템하에서의 성능에 대한 이론적 고찰 http://www.javaservice.net/~java/bbs/read.cgi?m=resource&b=consult&c=r_p&n=1008701211 PS: 저의 이런 고민이 완성되는 시점은 제 예상으로는 금년 10월을 넘기지 않을 것으로 예상합니다. 용량산정에 관련한 여하한의 자료나 연구된 내용이 있으신 분들은 함께 동참하셨으면 합니다. PS2: 그렇네요, 비가 옵니다. 자바서비스넷 이원영 제목 : Re: 참고의견 & SPECjbb2000 글쓴이: 김현숙(guest) 2002/05/01 08:21:43 조회수:663 줄수:31 - 1 transaction은 "사용자에 의한 1-request 단위를 1-transaction으로 보자는 것이 현실적인 면에서 저의 주장입니다."라는 주장에 저도 동의합니다. - 기존 legacy world(특히 S/390) 에서는 peak day의 peak time의 초당 transaction 수가 용량산정 기준 workload입니다. - 실 web application이 있다면 용량산정에 아무 문제가 없을테고, 테스트용 일부 web application이 있다면 일중 70% (나의 프로젝트 경험치) 차지하는 빈번히 일어나는 몇개 거래를 simulation하여 실측하면 되고, as-is 시스템이 있어 web application으로 전환하려고 한다면, 이때는 산업별, application 별 가중치를 주는 것이 관건이 되겠지요. (예를 들면 IBM Trade2 결과치에 Trade2 테스트 시나리오와 실업무 간 차이를 감안하여 가중치를 주는 거죠.) 전혀 새로운 web application이라면? 별 아이디어가 없네요. - 위의 얘기는 그냥 해본 소리고 진짜 하고 싶은 얘기는, 앞으로는 tpmC말고 tpmC를 만든 SPEC에서 새로 Java Benchmark를 해서 만든 SPECjbb2000을 반영해야 하지 않을까 하는 것입니다. 아직 CPU intensive 특성을 가진 JVM workload 밖에는 반영이 안되어 있지만 올해안에 Java application 특성을 반영한 기준 자료를 만든다고 합니다. 참고하십시오. IBM RS/6K performance 자료에도 이미 SPECjbb2000 기준으로 모델별 성능치가 나옵니다. All SPEC JBB2000 Results Published by SPEC http://www.spec.org/ http://www.spec.org/osg/jbb2000/ http://www.spec.org/osg/jbb2000/press/release.html http://www.spec.org/osg/jbb2000/results/jbb2000.html Hyeonsuk Kim/Korea/IBM@IBMKR S/W Architect S/W Group, IBM Korea 제목 : Re: ECperf™ = SPECjAppServer2002 글쓴이: 이원영(javaservice) 2002/05/03 12:28:30 조회수:398 줄수:97 ECperf™는 자바커뮤니티프로세스(Java Community Process)프로그램에서 개발된 벤치마크테스트 (Benchmark Test)로써, ATG,BEA,HP,IBM,Informix,Borland,IONA,iPlanet, Oracle,SunMicorsystems 등 IT기업들이 참가하는 ECperf Expert Group에서 주관하고, 그 결과물들은 theServerSide.com를 통해 운영되고 있습니다. http://ecperf.theserverside.com/ecperf/index.jsp?page=whoweare The ECperf Spec and Toolkit are being developed as JSR #000004 under the Java Community Process 2.0 . The ECperf Expert Group includes representatives from: Art Technology Group, BEA, Hewlett-Packard, IBM, Informix, Borland, IONA, iPlanet, Oracle, Sun Microsystems, and Sybase. http://java.sun.com/j2ee/ecperf/download.html The ECperf Specification was created under the Java Community Process program to provide full public participation in the definition and development. 앞서, 한국IBM의 김현숙부장님이 언급하신, TPC-C 벤치마크를 개발한 SPEC/OSG(the Standard Performance Evaluation Corporation/Open Systems Group)에서 올해 안에 Java Application의 특성을 반영한 벤치마크를 내어 놓겠다고 한 것은, 결국 "ECperf"를 지칭하고 있습니다. http://www.spec.org/osg/jAppServer/ SPECjAppServer2001 An industry standard benchmark designed to measure the performance of J2EE 1.2 application servers. This benchmark will be derived from ECperf™ which was developed under the Java Community Process. SPECjAppServer2001 will test the EJB container in a J2EE 1.2 compatible server. SPECjAppServer2002 An industry standard benchmark designed to measure the performance of J2EE 1.3 application servers. This benchmark will include an enhanced workload by adding a web tier, JMS, and other changes to SPECjAppServer2001. SPECjbb2000 벤치마크가 각 벤더의 머신사양(CPU개수와 메모리사이즈) 별로, 그리고 JDK 종류별로 JVM(Java Virtual Machine)의 CPU intensive한 관점에서의 성능을 측정함으로써 궁극적으로 Java환경에서의 하드웨어 용량 비교를 위한 것이지만, 최근과 같은 복잡한 웹기반 시스템 환경에서의 다양한 비즈니스 어플리케이션에 대한 벤치마크테스트 용도는 아니었습니다. SPECjbb2000은 데이타베이스를 이용하는 것이 아니라 자바클래스로 구현된 바이너리트리(B-Tree)구조의 메모리데이타를 사용하는 구조로 테스트가 이루어지고 있습니다. http://www.spec.org/osg/jbb2000/docs/faq.html#Q1 SPECjbb2000 is a Java program emulating a 3-tier system with emphasis on the middle tier. Random input selection represents the 1st tier user interface. SPECjbb2000 fully implements the middle tier business logic. The 3rd tier database is replaced by binary trees. SPECjbb2000 is inspired by the TPC-C benchmark and loosely follows the TPC-C specification for its schema, input generation, and transaction profile. SPECjbb2000 replaces database tables with Java classes and replaces data records with Java objects. The objects are held by either binary trees (also Java objects) or other data objects. SPECjbb2000 runs in a single JVM in which threads represent terminals in a warehouse. Each thread independently generates random input (tier 1 emulation) before calling transaction-specific business logic. The business logic operates on the data held in the binary trees (tier 3 emulation). The benchmark does no disk I/O or network I/O. 반면, ECperf는 자바로 구현된 웹기반 분산시스템 하에서의 핵심적인 비지니스로직 구현의 근간인 EJB(Enterprise JavaBeans)에 특화시켜,J2EE 기반 어플리케이션서버 제품의 성능과 확장성을 측정하는 것에 목적을 두고 있습니다. http://ecperf.theserverside.com/ecperf/ ECperf is a Enterprise JavaBeans(EJB) benchmark meant to measure the scalability and performance of J2EE servers and containers. ... ECperf stresses the ability of EJB containers to handle the complexities of memory management, connection pooling, passivation/activation, caching, etc. ECperf에서는 현재(2002.05.02) BEA WebLogic, IBM WebSphere, Pramati Application Server 등 3개 업체의 제품테스트결과가 올라와 있는 상태이며, (현재는) 성능면에 있어서 IBM WebSphere가 32,581.47(BBops/min@Std)로 가장 높은 결과를 보이고 있는 반면, BEA WebLogic은 가격대비 성능에서 $7 Price/BBops 로 선두를 달리고 있습니다. 이러한 순위 싸움은 지금껏 계속적으로 변해왔으며, 앞으로 어떻게 변화할지는 주목해 보아야 할 것입니다. 중요한 것은, C/S환경에서 유닉스서버의 용량산정(Capacity Plan) 및 OLTP어플리케이션의 성능측정을 위한 사실상의 산업표준 TCP-C 벤치마크를 개발했던 SPEC/OSG가 J2EE기반의 웹어플리케이션서버(Web Application Server) 시장에서 화두가 되고 있는 ECperf 벤치마크를 수용함으로써, ECperf벤치마크는 향후 또 한번의 업계 표준이 될 것이라는 예측은 그리 어렵지 않을 것으로 보입니다. 자바서비스넷 이원영 PS: TPC-C represents standard OLTP transaction processing in a client/server environment. TPC-W represents standard web server multiplexing to a database. SPECjvm measures computer system performance for Java virtual machine* (JVM) client platforms. PS: 이곳 자바서비스넷 "최근IT소식" 게시판에서 "ecperf" 키워드로 검색을 하면 아래의 기사들을 보실 수 있습니다. 511 theServerSide.com:XMLC vs. JSP, IBM ECperf Results... 20020503 이원영 501 J2EE 서버 벤치마크 테스트에서 BEA 웹로직 서버 7.0 1위 20020402 천보경 474 TheServerSide:EJB Design Patterns, Securing Web Services 20020308 이원영 463 TheServerSide: BEA Leads ECperf,Validator Pattern... 20020223 이원영 438 TheServerSide: Mastering EJB, ECperf, SOAP 20020115 이원영 391 TheServerSide.com:Evalutate J2EE Performance 20011106 이원영 339 TheServerSide.com Newsletter #14 : Web Services 20010806 이원영 -------------------------------------------------------------------------------- 제목 : Re: System이나 Product 자체의 성능비교 글쓴이: 김은경(guest) 2002/05/04 15:18:38 조회수:295 줄수:19 이원영과장님, 올리신 글 잘 보았습니다. 약간의 제안을 드리자면.....(내용에 대한 충고는 아니니까 긴장을 푸십시오.) 먼저 이와 관련되어 게재된 게시판의 내용이 좀 정리되어야 할 것 같습니다. 일단 제목과 내용에 있어서 다른 것들이 있습니다. 처음엔 "용량산정 이슈"로 시작했지요. 이의 제목을 보면 특정 고객이 시스템을 도입할 때, 고유의 application을 원활히 수행하기 위해선 어느 정도의 시스템을 도입해야 하느냐의 고민에 대한 해답의 글로 추정이 되지요. 그러나, 실제 내용은 어떻습니까? H/W machines 자체의 BMT나 Web Application Servers 자체의 BMT 내용으로 빠지고 있습니다. 사실 이런 BMT로는 특정 고객의 환경을 고려하지 않은 [System이나 Product 자체의 성능비교]의 결과만 얻을 수 있는 것입니다. 제목과 내용의 정리가 약간 필요하지 않을까요? Thanks, -------------------------------------------------- EunKyung Kim Advisory IT Specialist WebSphere Advanced Tech. Support, S/W Technical Sales Support