1.
x86 vs. Power7라는 제목으로 x.86서버를 새롭게 보자는 주장을 했었습니다. 한국후지쯔의 PrimeQuest를 소개하는 홍보하는 글이기도 했습니다. 이후 빙하기 살아남기에서 이런 글을 남겼습니다.
또하나 블로그를 한 이후 여러 분들이 찾아왔습니다. 특히 하드웨어나 네트워크와 관련한 분들이 많습니다. 두런두런 대화를 나누다 보면 긴 시간을 투자하여야 합니다만 저에게 돌아오는 것은 별로 없습니다. 그래서 소극적인 태도를 가졌지만 적극적인 태도를 가지려고 합니다. 좋은 제품을 직접 찾아보고 괜찮은 제품은 솔류션을 만들어 직접 영업도 할 생각입니다.
직접적인 영업은 아니더라도 영업에 대한 기술적인 지원을 하고 있습니다. 그중 한 제품이 PrimeQuest입니다.
사례와 문서만을 놓고 보면 좋긴 좋은데 마땅히 인상을 남길 방법이 없었습니다. 그래서 직접 숫자를 만들어 보기로 하였습니다. 전 직장이면서 마음의 빗을 지고 있는 아이낸스와 협력하여 작업을 하였습니다. 아시는 분은 아시겠지만 아이낸스가 하는 주된 사업이 HTS 개발입니다. 자체로 보유한 플랫폼이 AS/PlaformPrime입니다. 이를 리눅스에 최적화한 제품인 XPlatform입니다.
BMT 시나리오는 다음과 같이 구성하였습니다.
첫째 현재 증권사에서 가동적인 시스템을 리눅스에서 최적화하여 실행한다. 가동중인 시스템이라는 의미는 HTS서버가 하는 기능 – 실시간 시세처리 이외에 다양한 시세를 가공하는 업무까지를 포함 – 을 한다는 뜻입니다.
둘째 시장 개장후 시세를 포함하여 Exture+를 위한 시세분배시험에서 사용하는 데이타를 이용하여 시세스트레스시험을 한다.
셋째 다양한 경우의 동시접속자를 만들어 실시간시세 전송이 이루어지도록 한다
넷째 각각의 시나리오에서 CPU 사용을 측정한다. I/O 병목현상은 CPU 병목으로 이어지기때문에 CPU 사용을 측정하여 비교한다.
2.
우선 시험에 사용한 하드웨어 사양입니다.
위의 장비들은 Chelsio T420-CR을 통하여 10G 네트워크로 연결하였습니다. PrimeQuest를 이용한 시험 결과는 아래와 같습니다.
시험한 시나리오는 동시접속자수를 2,000, 5,000, 10,000명을 놓고 시세도 Exture+시세데이타의 네배와 여덟배를 하는 경우가 있지만 장시작후 시세와 Exture+의 여덟배 시세만을 비교하였습니다. Primequest를 이용한 결과를 보면 현재 시세수준이면 몇 만명의 동시접속자를 충분히 수용하고 남습니다. 만약 Exture+ 시세분배데이타의 초당건수 보다 여덟배가 많은 시세 = 초당 79400건을 수신하는 경우라도 대당 만명의 동시접속자를 충분히 처리하고도 여유가 있습니다.
혹 시세시험만 한 것이 아닌가 하고 의문을 가질 수 있습니다. 그렇지만 위의 시니라오를 살펴보시면 Request/Reply와 같은 업무인 주문을 충분히 처리하는 상태임을 알 수 있습니다.
1. 기타 프로세스들은 증권사와 동일함.
2. TRANSACTION 발생 초당 50건(1,000명 기준)
3. PUSH 접속자별 17개 실시간요청(접속수 * 17)
그러면 IBM Power7을 이용한 결과는 어떨까요? 시험을 한 IBM P7의 사양입니다.
Model : IBM, 8202-E4B PowerPC_POWER7 CPU (4core)
Number Of Processors: 4
Processor Clock Speed: 3000 MHz
Memory Size: 24,576 MB
시나리오는 앞서 PrimeQuest와 동일합니다.
위의 결과를 가지고 직접적으로 Power7과 PrimeQeust를 비교할 수는 없습니다. 하드웨어 사양이 다르기때문입니다. 다만 x.86서버를 이용할 경우 Power7에 비하여 아주 훌륭한 결과를 얻을 수 있음을 간접적으로 보여주고 있습니다.
3.
그러면 PrimeQuest를 어떻게 실환경에 이용할 수 있을까요? PrimeQeust가 가지는 기능중 가장 탁월한 것이 하드웨어 다중화와 파티션기능입니다.Scale Up/Scale Out이 모두 가능합니다.
만약 PrimeQuest와 Chelsio T5를 적용하면 최소 32,000명을 안정적으로 처리하지 않을까 합니다. 위의 시험에서 UDP Offload를 적용하지 않았지만 UDP Offload를 적용하면 Network I/O에 의한 병목을 더 줄일 수 있을 듯 합니다.
이상에 대한 구체적인 자료는 아이낸스나 저에게 문의하시길 바랍니다.(^^)
