지금 하는 프로젝트에서 하드웨어증설을 해야 한다고 하길래 알아본것을 포스팅!!
인터넷을 찾아보면 '일일 방문자수가 몇명이고 동접자수가 최대 몇명 정도가 되는데 이정도 서버로 버틸수 있을까요??' 라는 글을 많이 봤다.
나도 궁금했다.
어느정도 서버 스펙이 되어야 동접자 수를 커버할 수 있을까??
알아보니 정부에서 공식으로 사용하는 하드웨어 규모산정이 있다.
한국정보통신기술협회 에서 인정하는 '정보시스템 하드웨어 규모 지침' 이라는 문서가 있는데 한국정보통신기술협회 사이트에서 다운로드가 가능하다.
찾기 귀찮은 사람들을 위해 링크를 올려 놓는다.
다운로드 링크
내용을 보기 귀찮은 사람들을 위해 하단에 요약을 올려 놓았다.
1004lucifer
내용상으로는 다음과 같이 기준산정이 가능하다.
- 사이트의 순간최대요청을 알아야 계산이 가능
(순간최대요청을 PV로 변경하여 기술,
분당 트랜잭션 수는 Peak 타임을 기준으로 기술했다.)
1. DB서버 (1대 가정)
1) CPU (tpmC 단위)
- 분당 트랜잭션 수 * 기본 tmpC 보정(1.3) * 데이터베이스크기 보정(1.3) * 어플리케이션구조 보정(1.4) * 어플리케이션부하 보정(1.5) * 시스템 여유율(1.3)
2) 메모리
- {시스템영역 + (사용자당 필요메모리(1MB) * 동시사용자수)} * 버퍼캐쉬 보정(1.2) * 시스템 여유율(1.3)
3) 디스크
- 시스템: (시스템OS + 응용프로그램 + SWAP) * 파일시스템 오버헤드(1.1)
- 데이터: (데이터 + 백업) + 파일시스템 오버헤드(1.1) * 데이터디스크 여유율(1.3)
1004lucifer
2. WEB/WAS 서버 (각각 1대 가정)
1) CPU (OPS 단위)
- PV * PV 오퍼레이션(DB호출) 수 * 인터페이스부하 보정(1.1) * 피크타임부하 보정(1.3) * 시스템여유율(1.2)
2) 메모리
- {시스템영역 + (사용자당 필요메모리(1MB) * 동시사용자수)} * 버퍼캐쉬 보정(1.2) * 시스템 여유율(1.3)
3) 디스크
- 시스템: (시스템OS + 응용프로그램 + SWAP) * 파일시스템 오버헤드(1.1)
- 데이터: (데이터 + 백업) + 파일시스템 오버헤드(1.1) * 데이터디스크 여유율(1.3)
계산을 하고나니 tpmC 기준으로는 인터넷을 찾아보니 Cpu 모델별로 성능이 나와서 대충 어떤 CPU를 구매하면 되겠구나 감을 잡을 수는 있지만 우리나라에서만 사용하는 단위인지는 모르겠지만 OPS 단위로는 인터넷으로 적합한 CPU모델을 알 수 없었다.
아마 벤더나 중간업체에 이야기를 하면 알 수 있을지도?
PS.
개인적인 생각으로는 서버스펙도 중요하지만 논리적인 서버의 구성도 상당히 중요하다고 생각한다.
물리적인 서버하나에 WAS를 여러개 올릴수도 있고 WAS하나에 Context를 여러개 올릴수도 있으니 어떤게 가장 효율적인지 확인하고 테스트 해가면서 어떤게 해당 프로젝트에 맞는지 알아보는게 좋다고 생각한다.
1004lucifer
그리고 경험적으로 이따금씩 또는 특정 시간이 되면 서버가 응답이 없는 증상에 대해서 물리적인 스펙변경없이 WAS 셋팅만으로 이슈를 해결한 적이 있었다.
1. WAS의 응답이 너무 느릴 시 체크하여 Thread Dump 를 생성하는 데몬을 만들었었다.
2. GC Log 를 생성하는 옵션을 넣어서 GC 를 지속적으로 모니터링 했었다.
3. Heap Memory 를 4096MB => 2048MB 변경
- Full GC 할 시 Stop the World 의 시간이 줄어들었다.
4. GC튜닝: 정확히 어떻게 했는지 기억이 가물가물하다.
- Full GC 하는 딜레이를 Heap Memory가 60~70%만 되어도 Full GC가 수행되도록 변경하여 Full GC 시간(Stop the World)을 줄였던 것으로 기억한다.
다음의 링크가 개념적으로 정리하기에 좋다.
Java Garbage Collection
Garbage Collection 튜닝
Garbage Collection 모니터링 방법
자바 애플리케이션 성능 튜닝의 도(道)
엑셈에서 JVM 옵션을 확인해보는 것이 좋다.
JVM 옵션 정리
Tmax 에서 만든 JVM 튜닝옵션 문서를 참고해도 도움이 될것 같다.
SUN JVM 튜닝 옵션 by Tmax
============================
성능기준치
1) RDBMS => TPC-C
2) WEB => SPECWeb99
3) WAS => SPECjbb2000
1004lucifer
규모산정의 4가지요소
1) 인터뷰 분석 보고서 (규모산정 기초자료)
2) 규모산정 계산식 (계산식의 표준화)
3) 규모산정 절차서 (절차에 의한 규모산정)
4) 규모산정 Repository (사례 DB화를 통한 공유)
개념적 규모산정 절차
1) 구축방향 및 기초자료 조사
2) 기초자료 및 업무분석
3) 참조모델 결정 및 서버 규모산정
4) 참조모델별 가중치 적용
시스템 구축방향 및 기초자료 조사
1) 대략의 서버 개수, 어플리케이션 아키텍처 (2-계층, 3-계층), 통신환경 등을 결정
ex) 2계층은 서버1(WEB,WAS), 서버2(DB) 구성
3계층은 서버1(WEB), 서버2(WAS), 서버3(DB) 구성
2) 서버의 개략적인 업무 성격과 정보 흐름을 파악하기 위해 업무 사용자를 대상으로 아래의 양식에 따라 규모산정을 위한 기초자료 조사
기초자료 및 업무분석
- 고려해야할 요소는 다음과 같다.
1) 응용업무의 각 트랜잭션 타입, 특성, 가중치를 조사한다.
2) 온라인 업무와 배치처리 업무는 구분해서 분석한다.
3) 현재의 규모와 향후 시스템 서비스를 개시한 후 업그레이드 없이 사용할 기간을 감안하여 필요 규모를 사전 확보해야 한다.
참조모델 결정 및 서버 규모산정
- 참조모델에서 제시하는 서버1, 서버2, 서버3은 물리적이 아니라 논리적인 개념의 서버이다.
참조모델별 가중치 적용
하드웨어 요소별 규모산정 방식
1) CPU 산정방식
가) DB서버 또는 OLTP & Batch (tpmC 추정방식)
1) 분당 트랜잭션 수 (3가지 방법 존재)
ㄱ) 클라이언트 수를 이용하는 방법
- 동시사용자 수를 이용한 분당 트랜잭션을 구한다.
ㄴ) 기존시스템의 트랜잭션을 조사하는 방법
ㄷ) 동시사용자 수를 이용하는 방법
- 분당 트랜잭션 수 = 동시사용자 수 * 사용자당 트랜잭션 처리 수
2) 기본 tmpC 보정
- 20%: 단순, 동시사용자가 300명 미만
- 30%: 복잡, 동시사용자가 300명 이상
3) 피크타임 부하 보정
1004lucifer
4) 데이터베이스 크기 보정
- DB에 속한 가장 큰 테이블의 레코드 건수와 전체 DB의 볼륨을 고려하여 결정
- 아래에서 행은 가장 큰 테이블의 레코드 건수(million)를, 그리고 열은 데이터베이스 크기(Gbyte)를 나타낸다.
5) 어플리케이션 구조 보정
6) 어플리케이션 부하 보정
7) 클러스터 보정
8) 시스템 여유율 (30%)
- 예기치 못한 업무의 증가 및 시스템의 안정된 운영을 위한 보정치, 일반적으로 피크타임을 고려하여 30%를 적용
1004lucifer
- 산정방식
- 산정식에서 보정치 및 여유율은 100%를 추가한 후 소수점으로 변환(예, 30%는 1.3)하여 계산한다.
나) WEB/WAS (ops 추정방식)
1) 동시사용자 수
- 불특정 다수를 대상: 전체사용자의 1~10%를 접속사용자로 보며, 이러부터 5%~10%를 동시사용자로 산정
- 특정 다수를 대상(인트라넷): 10~20%를 동시사용자로 적용할 수 있다.
<사례>
전국민을 대상으로 하는 서비스인경우 아래와 같이 산정
가입자 수: 100만명
동시접속자 수: 10,000명
동시사용자 수: 1,000명
2) 사용자당 오퍼레이션 수
- 사용자당 한 사람이 초당 발생시키는 비즈니스 로직 오퍼레이션 수로서 다음과 같이 업무유형에 따라 3~6개 정도로 가정
3) 인터페이스 부하 보정 (5%)
- 서버가 타 서버와 통신하게 될 때 인터페이스에서 발생하는 부하를 고려한 보정치, 일반적으로 5% 적용
1004lucifer
4) 피크타임 부하 보정 (아래의 예시 참고)
5) 클러스터 보정
6) 시스템 여유율 (30%)
- 예기치 못한 업무의 증가 및 시스템의 안정된 운영을 위한 보정치로서, 일반적으로 30%를 적용
- 산정방식
- 보정치 및 여유율은 100%를 추가한 후 소수점으로 변환 (예, 30%는 1.3)하여 계산한다.
2) 메모리 산정방식 (프로그래밍 언어나 쓰레드, 특정 시스템에 대한 메모리 구성특성의 반영 고려하지 않고 일반적인 시스템 용도와 구조를 바탕)
가) 시스템 영역
- 시스템 운영시 구동되는 모든 소프트웨어의 소요공간 산정 (일반적으로 각각의 소프트웨어 제조사가 권고하는 필요메모리 반영)
나) 사용자당 필요메모리
- 각 벤더의 WEB, WAS, DBMS 특성에 따라 요구되는 메모리 등을 감안하여 계산한다.
- 계산이 불가능한 경우 0.5MB ~ 1.5MB 값을 임의로 적용할 수 있다.
다) 동시사용자 수
- 독립적으로 산정하는 것이 아니라 이전 단계에서 산정한 CPU의 동시사용자 수 추정치와 동일한 값을 적용한다.
라) 버퍼캐쉬 보정
- 시스템 운영자의 요구에 의해서 정해진다.
1004lucifer
마) 시스템 여유율 (30%)
- 예기치 못한 업무의 증가 및 시스템의 안정된 운영을 위한 보정치로서, 일반적으로 30%를 적용
- 산정방식
- 보정치 및 여유율은 100%를 추가한 후 소수점으로 변환 (예, 30%는 1.3)하여 계산한다.
3) 디스크 산정방식
- 시스템디스크는 모든 서버에 대해 산정하나 데이터디스크는 서버의 특성이나 목적 혹은 구성 형태에 따라 선택적으로 산정한다.
- 디스크 포멧 시 15% 정도의 공간이 필요로 하게되지만 지침의 산정식에서는 이를 감안하지 않고있으니
디스크 규모산정치에 이를 추가적으로 고려할 필요가 있다.
가) 시스템 OS영역
- 대상시스템에 설치될 운영체제, 시스템 S/W와 수퍼유저(SU)를 위한 영역을 포괄한다. (OS, S/W의 크기는 벤더가 권장하는 크기를 바탕으로 산정)
나) 응용프로그램 영역
- 서버용 S/W, 응용 S/W, DBMS 설치에 따른 영역의 모든 크기의 합을 구한다. (S/W는 벤더가 권장하는 크기를 바탕으로 산정)
- DBMS의 경우 실자료공간, 예비용데이터 공간, 인덱스 및 키 데이터 공간 등 세부항목의 합계로 결정
다) SWAP 영역
- 일반적으로 메모리 요구량의 2배로 산정
라) 파일시스템 오버헤드
- 시스템디스크의 경우: 시스템OS 영역과 응용프로그램 영역, SWAP 영역을 합한 값의 10%정도
- 데이터디스크의 경우: 데이터 영역과 백업 영역을 합한 값의 10%정도
마) 시스템/ 데이터 디스크 여유율
- 일반적으로 30%를 산정 (전체 필요 디스크량의 20~50% 정도를 여유율로 산정)
바) 데이터 영역
- 실제 필요한 데이터량을 대상으로, 계산시 매년 증가치를 반영하여 산정
사) 백업 영역
- 백업정책에 의해서 결정
1004lucifer
아) RAID 여유율
- RAID1의 경우 100%를, RAID5의 경우 30%로 산정
- 산정방식
- 파일시스템 오버헤드 및 시스템/데이터디스크 여유율은 100%를 추가한 후 소수점으로 변환(예, 30%는 1.3)하여 계산한다.
와... 필요한 내용이었는데, 고맙습니다 :)
답글삭제도움이 되었다니 기분이 좋네요. ^^
삭제