성능치 반영도

#7 성능치 반영도

 전체 시스템 구성도를 그렸다면 의문스러운점이 많이 있을것이다. 무슨 근거로 서버와 네트워크 장비들, 그리고 소프트웨어의 수량과 성능을 정하고 설계한 것일까 하는 것일 텐데, 예를 들자면 Tomcat 으로 처리하고자 하는 것이 계속 늘어나고 각 처리를 요하는 예상 클라이언트의 수를 고려하지 않았기 때문이다. 또한 처리될 양의 계산또한 고려되지 않았고 처리의 방법도 고려되지 않았다. 

 여기서는 예상 성능치를 반대로 서버에서 얼마나 처리 할수 있는지를 확인하고 필요 요건을 감안해 설계도를 재 작성 해보겠다. 

 WEB 서버에서는 클라이언트들의 요청을 최초로 받아서 요청하는 페이지와 처리를 각 WAS 서버의 Port 로 보내게 되는 간단한 모듈만 작동하지만 성능의 과다가 예상 되고 있고 세션을 기준으로 1유저당 약 1Mb/s 8세션 의 처리가 예상될때 서버의 실장 메모리 128GB 로는 128,000개의 처리가 초당 가능 할 것이다. 물론 초당 128,000명의 유저를 1서버에서 초당 처리가 된다는 가정은 아닌데 서버 자체에서 OS 를 사용하거나 기타 유틸리티 혹은 HTTPD 자체적으로 사용하는 메모리는 고려되지 않았고, 1유저의 예상 사용시간이 계산되지 않았기 때문이다. 하지만 크게 유추가 될 수 있으니 이를 통해 계산하면 WEB 서버 1기당 OS 및 기타 유틸리티, 그리고 HTTPD 의 사용 메모리 약 8GB 이고, 세션의 스틱키 기능이 없음을 고려한다면 약 120,000명의 유저를 초당 처리가 가능하다고 볼 수 있다. 이정도 크기라면 우리나라 국민의 수 약 50,000,000명이라고 볼때 416명중에 1명은 초마다 접속해도 처리가 가능하다고 볼 수 있다. 

 만약 초당 120,000명을 처리하지 않아도 되는 서버이고 차후에 서비스의 성장을 생각하고 있다면, 성능을 하향 시키는것이 비용적인 측면에서 효과적일 것이다. 이것은 위의 계산과 반대로 사용자 수를 미리 예측하고 계산 하는것이다. 가입자 5,000,000명을 목표로 서비스를 한다면, 초당 100명중 1명이 접속을 하고 최번시간으로 계산을 하게 되고 이때 필요한 메모리 양은 약 6,250MB 이고 3년간 연단위 30% 증가를 목표로 한다면, 이때 필요한 메모리 양은 약 10,563MB 가 되고 여기에 OS가 필요한 메모리 약 8GB를 합한다면, 약 19GB 정도의 메모리가 있다면 예측치 3년간 서비스 가능한 양이 될것이다. 

 그렇다면 100GB가 넘는 양의 메모리가 사용하지 않아도 되는 양이 될텐데 이때 고려해 볼 수 있는방법이 가상머신을 사용하는것이다. 물리서버를 사용해서 하기에는 초기 구매 자금을 낮출 수도 있고, 실제 필요한 자원만큼만 사용 할 수 있기 때문이다. 최초 구성에서 Memory를 저사양으로 구매하여 장착하면 될 것이다라고 생각이 들 수 도 있지만 서버의 기본 비용이 불필요하게 더 낭비 될 수 있으므로 가상서버를 사용하는것이 더 저렴할 것이다. 

 또한 서버는 2기 이기때문에 더욱더 절반인 10GB정도면 될 것이라 볼 수 있지만, 2기 이상 배치하는것은 1기의 장애 혹은 관리 상태에서 생기는 처리가 포함 되어있고 A - A 의 방식으로만 운영되고 있다고 해도 기본적으로 사용되는 OS 메모리를 고려해서 최소 약 15GB는 사용하여야 1기의 기능이 처리가 가능 할 것이다. 

 해서, 기준표를 작성해서 시스템을 다시 정리해보겠다. 

 성능이 반드시 위의 표처럼 되지는 않지만, 기준을 마련해서 사용하게 된다면, 필요로 하는 성능과 현재 가능한 성능을 예상 할 수 있기때문에 많은 도움이 될 수 있다. 물론 이때 성장률을 감안해서 전체 성능의 20 ~ 40% 미만으로 현재 성능을 상정하면 큰 무리 없이 구성이 가능할 것이다. 위의 표로 본다면, 서비스 시 순간접속 1만명 을 목표로 한다면, WEB Server는 10GB의 메모리 사용과 WAS Server는 WEB Server의 요청과 처리가 동일한 양으로 계산하면, 100GB 가 필요로 하게된다. 한개의 인스턴스에 100GB를 다 쓰지는 않으므로 32GB 씩 분배한다고 할때 4개의 인스턴스가 필요 할 것이다. 만약 요청 1의 간단처리 1만 된다면 위의 계산이 맞지만, WAS의 처리는 단순 하지 않을것이다. 이에 맞춰 배수를 정해도 되고, 예상 처리량을 계산할 수 있다면, 계산을 해보면 될 것이다. 

 여기서는 인증을 요청할 서버를 추가로 둔다는 예상을 두고, 클라이언트의 요청을 받을 WEB( 1MB ), 요청을 처리할 WAS( 1MB ), 요청중 인증을 처리할 WAS(1Mb)를 시나리오로 예상하고 진행하겠다. 비율은 1 : 1 : 1/8 이 되겠다. 그렇다면, 기본 OS용( 유틸리티, 배치 등등 )을 2코어 8GB를 예상하고 사용할때, WEB Server는 OS용 + 10,000User = 2Core 8GB Ram + 2Core 10GB 가 되고 WAS Server는 OS용 + 10,000User + 1250인증 = 2Core 8GB Ram + ( 2Core 32GB Ram X 4 ) + 2Core 16GB Ram 이 될 것이다. 물론 각 서버가 2기씩으로 1/2 의 분배가 있지만 2기로는 장애 혹은 배포시 성능의 제약이 생기게 된다. 

 WEB Server의 경우 성능이 불필요하게 많은 여분이 생기게 되고, WAS Server의 경우 12Core 152GB로 여유있게 성능을 잡긴했지만 이대로 사용하기에는 성능의 여력이 모자르게 된다.  그렇다면, 증량이 필요하게 되는데 짝수, 홀수의 구분은 크게 상관없지만 여유분과 확장성을 위해서는 짝수를 고려하는것이 여러모로 유리하다. 해서 위의 성능을 4기로 예상하고 1기의 여분을 둘때 152GB 의 1/3을 고려하면 서버당 약 50GB의 메모리를 할당하게 되므로 40% 정도의 성능으로 사용 할 수 있게된다. 

 웹의 경우 가상서버의 팜이 미리 준비 되어 있다면 월 사용료를 지불하는 방식으로 구성하는것이 좋고 만약 IDC 에 단독 구성만으로 해야 한다면 CPU와 RAM이 낮은 서버를 WEB으로 구축하고 기존 WEB Server를 WAS Server로 구성하는 방법도 있을수 있겠다. 만약 WEB Server 2기의 구성을 위해 클라우드서버를 따로 구축한다면 더 큰 손실이 발생할수 있으므로 클라우드서버가 없을경우 낮은성능으로 변경을 구성해야 하겠다. 성능을 고려한다면, 아래의 표와 같이 구성이 변경이 될 것이다. 

성능 조정 전, 구성표

성능 조정 후, 구성표

 인스턴스는 각 2개에서 16개, 4개로 늘어나게 된다. 위의 조정표로 다시 시스템을 구성하게 되고, DB의 경우 변수가 있겠지만 DB 사용율에 따라 조정을 하게된다. 만약 DB의 사용량이 많다면 A-S-B 구조 혹은 A-A-B의 구조로 변경이 되겠다. 이 모든것을 적용한 전체 시스템 구성도는 아래와 같다. 

성능치 반영 전체 구성도

 성능을 조정한 표를 다시 구성하게 되면 다음고 같다. 

성능 변경 표

 네트워크, 스토리지 또한 상정하고, 서버와 서버간의 트래픽을 실제 구간으로 계산할 수 있어야한다. 스토리지의 경우 저장 기간과 용량을 염두해서 계산하도록 한다. 

Network 속도 대비표

네트워크의 경우 서버들간의 최대 트래픽 송, 수신 모두 합산하게 되면 필요 대역폭이 나오게 되고, 데이터의 경우 기간별 합산을 통해 값을 구하게 된다. 

데이터 적제표