서버 성능산정 및 성능추적에 대한 고찰 1

미완성글이지만 일단 잊기전에 정리할 차원으로 끄적여야 겠다...

우리 팀장님은 서비스적 시스템관리자 성향이 있으신다...

서버란것은 서비스에 맞추어서 산정되야 하며 서비스가 유지되기 위한 시스템이란 것이다...

그동안 서버성능에 대해서 주먹구구식으로만, 서비스보단 나의 편리함을 위주로

서버를 산정,튜닝했던 나로써는 나로하여금 다시 새로운 물을 공급해주는 샘물이였다..

실제로 예전에 다니던 회사는 작지만 많은 회원을 보유하고있던 포털이였기때문에,

웹서버에 대한 성능기준이 중요했다....하지만 문제는 수치라는게 막연하다했딴거다..

막 사장님이나 서비스기획자들은 대략 동시접속 만명, 이만명 정도를 불러댄다..

그러면서 서버를 어떻게 구매 해야겠냐고 묻는다...

실례로 이전회사에서 웹으로만 구성된 ( AJAX ) 채팅사이트를 구축하는데,

참 애매하게 잘되면 몇만, 일단은 몇백 을 계산으로 산정해서 서버를 구축해 달라고 한다..

니미럴...이런말 들으면 경력있는사람이라면 욕부터 나와야 할것이다...아닌가 캭..

그래서 퉁명스레 서버사양을 최대한 높여서 불르곤 했었다...

역시나 가격이 또한 문제...그래서 적당히 저렴하고 성능 튼튼한 편인

델 2950 ( 쿼드코어 제온 5080 * 2CPU, 4GRam, SAS 1500k ) 로 테스트배드를 선정했었다.

자세한 서버 셋팅에대해선 말하진 않는다 여기선 서비스 성능을 산정하기위한

접근방법에 대한 얘기만 할것이다.

위 경우엔 몇가지 고려해야 할 점이 있었다...

일단 오로지 웹으로만 진행될것인지, 디비를 사용할 것인지에 대한 구분이 필요했다...
( 서비스 제공형식 )

처음엔 오로지 파일디비 ( 단순한 채팅대화록 저장 및 읽어뿌려주기 등 ) 를 사용했다.

간단한 파일입출력만 유지되면 된다는 생각이였다...

고로 일단 DISK IO 를 고려하여 최대한 빠른 SAS 15K Raid 0으로 설정해봤다.

여기서 Raid 01 이나 10 등은 고려했지만 결국 실제로 수행해본것은 간단한 테스팅이였다.

물론 가격때문에 복합적 구성은 하지 못했다는게 정답이겠지만....ㅋㅋ

게다가 일반적인 웹서버라면 연결을 매우 짧은시간에 종료시키는게 관건이지만,

채팅서버이기때문에 오랫동안 세션을 유지시켜야 했다...

그렇다면 파일의 오픈수와 시간도 오래걸릴거고, 역시 disk IO와 메모리 IO 속도 및

총 량, 메모리 반환의 문제가 생길것이였다. ( 실제 성능과 관련된 요소들 )

위 경우처럼 고려하는 단계에서 추상적으로 몇가지 항목들이 생겨난다.

이게 바로 서비스 위주 서버 성능 산정항목 이 되는 것이다..대충 SLA라고하던가...

자꾸 다른데로 빠지는경향이 있는데,  일단 SLA 의 항목별로 정리하자면,

서비스타임 비율
동시접속자수 ( 동시 서비스 사용자 )
서비스시 실성능을 비교할 수 있는 명확한 기준
예정된 작업 및 장애사항 변경등을 사전고지 하기위한 기간
QA 의 신속성
사용량 통계제공의 용이성

대략 이정도가 내가 알고있는 서비스공급업체에서 제공하는 기준들이고,

팀장님께서 언뜻 얘기하셨던 부분들이다.

그리고 이것들을 해결하기 위한 서비스 용량산정은 필수로 따라오는법이므로

실질적인 용량산정 방법들에 대해 말하겠다..사실 정답은 없다. 경험이 답이다.

먼저 디스크를 산정해보겠다.

디스크 산정을 위해선 Disk I/O, Partion, FileSystem, Log, Backup 등을 들수 있겠다.

Disk I/O 부분에선 위에서 말했던 Raid 나 SAS, SCSI 등 디스크 어레이 혹은,

컨트롤러, 디스크 타입에 따라서 또 먼저 선정이 되야한다.

디스크 하드웨어단위로는 일단 SAS 15K 만큼 빠른 속도를 제공하는건 거의 없다고

볼 수 있겠다.....아주 초고가들 뺀다......

그래서 위에선 SAS 를 선정했다.

그리고 레이드는 매우 중요한 역할을 하는데, 어떻게 묶여있느냐에따라서

성능 및 백업의 효과가 달라지기 때문이다.

기본적인 Raid 개념은 알고 있다고 치고, 여기서 Stripe의 크기또한 용량에 많은

영향을 미칠것이다. stripe 가 크다고 좋다고만 할 수 없고,

작다고 좋다고 할 수 없는 것이다. 고로 사용하고자 하는 목적에 따라 구성하는게 좋다.

빠른 디스크 퍼모먼스를 내기 위해선 01 로 묶는 것도 좋지만,

어떤 DB서버의 경우엔 10 으로 묶는게 훨씬 안정적이고 빠를 수 도 있다.

이건 디스크 헤드의 탐색시간과 관련된 거니 좀더 공부하고 오자...

레이드로 묶었으면 이제 파티셔닝또한 영향을 준다.

파티셔닝에서 고려해야할 부분은 데이타 엑세싱 타임, 즉 헤드 탐색시간과,

스왑영역이다. ( 페이징영역이라고도 한다. )

보통 리눅스의 경우 부트파티션을 먼저 50~100메가 잡고,

그 다음에 SWAP을 잡아주고 /var, /usr, /, /home 식으로 잡아주곤 한다.

역시 파티션에 따라 사용될 용도에 따라 순서대로 나눠주면 된다.

보통 var 에는 몇몇 주요 라이브러리들과 로그가 생성되기때문에

대략 로그쌓일 양을 계산하여 2G ~ 4기가 정도를 잡아주곤 한다.

/usr 의경우에도 소스컴파일이나, Xwindow 등을 위해 적절히 잡아준다.

실제 데이타가 들어갈 용량은 이미 산정 돼어있다는걸 전제로 디스크를 구성해야 한다.

백업디스크 역시 추후로 구성하면 좋겠지만 상황에따라 적절히 파티션을

나누어 보관해야 할 것이다.

여기서 주의할점은 디스크 용량의 80~90퍼센트 정도는 사용안한다는 셈으로

구성을 하는게 좋다. 이것역시 데이타 엑세스 타임으로

스왑파일의 경우 내 요즘의 내 경험상으론, 그리고 가상메모리체제를 쓰는 한,

아무리 메모리스펙이 발달됐다고 해도, 역시 많이 필요하다...

물론 경우에따라서 잡혀진 스왑파일이나 페이징파일때문에, 램을 충분히 사용하지않고

페이징시켜버리는 운영체제들이 있다던가, 반대로 메모리가 충분한데도

기본적으로 페이징을 우선으로 하여, 램의 사용률보다 페이징률이 높은

운영체제들이 있기때문에 이것도 많은 고려를 해야한다.

그래서 고전적인 방법이겠지만 사용될 OS의 페이징 알고리즘 및 메모리관리정책

등을 확실히 알지 못한다면  물리적 램의 무조건 2배로 잡는게 좋다.

페이징영역이 디스크위주로 사용하게된다면 ( 가상메모리등 ) 얼마든지

변경 및 수정이 가능하므로 적당히 유연성 있게 산정한 단위인 셈이다...

설마 스왑인,아웃이 어떻게 시스템에 영향을 주게되는건지 모르는사람들은 없겠지??

모른다면 한번 연구해볼 필요가 있을것이다.

뭐...메모리 산정 및 효율관리등에 대해선 추후로 또 설명하게 될것이므로,

여기까지 하겠다.

어쨋든 대강 이렇게 까지 또 디스크에 대한걸 마무리하고 쉬겠다.....넘 긴가?

어차피 차차로 정리해 나갈것이며, 대략 지금생각으론 삼부작정도로 대략적인

뼈대를 잡아 기술하고, 필요하다면 중간중간 다듬으며 세분화 할 것이다.