AdminID.kr (어드민아이디) - 서버

용량 산정 (동시 접속자 계산)

JAESOO — Wed, 04 May 2016 20:41:09 +0000

= 동시접속자수, 서버용량, 로드 밸런싱

회선 대역폭 이용한도란 미디어호스팅 고객사이트에서 다운로드 전송되는 동영상 데이터로인해 발생하는 회선트래픽의 양을 의미합니다. 아래 예제는 동시접속자와 예상 대역폭을 계산하였습니다. 즉, 고객님의 홈페이지에서 한개의 동영상을 대상으로 최대 몇명의 동시 접속자가 발생하는지를 예상하여 서비스를 선택하실 수 있습니다.

예)300Kbps로 인코딩된 동영상 파일을 10명이 동시에 예) 감상하는 경우

..- 300Kbps × 10명 = 3,000Kbps = 3M bps

..- (bps = bitper second : 초당 전송 바이트수)

..- 만일 한개의 사이트에 위와같은 동영상이 10개가

..- 동시에 서비스된다면 전송량은 10배가 됩니다.

동시접속자수는 웹서버에 최근 10초 사이에 서비스요청이 있었던 사용자를 접속중인 사용자로 보아 계산한다.

서비스요청 제한수는 추후에 웹서버의 성능 테스트 결과에 따라 변경할 수 있다.

동시접속자수(천 분의 1초 사이에 동시에 request를 보내는 사용자수) 40명이라는 안정적인 수치를 확보하였다.

시스템의 운영중에 이를 초과하는 접속자수의 급격한 증가로 네트워크 트래픽이 발생하면 이를 위해서는 서버에

연결되어 있는 전용선의 용량을 증대시켜 속도개선을 취해야 한다.

=====================================================

(급) 웹서버 구축시 동시 가능 접속자수 예상법

=====================================================

웹서버 구축시 (intel Xeon 2.4Ghz, win2000, IIS서버) 서버가 얼마만큼의

동시 가능 접속자를 서비스 할 수 있을까요?

-> 일반적으로 IIS 의 경우 커넥션 수를 대략의 폭만 정하고 있습니다.

그렇기 때문에 CPU 나 RAM 등의 사양에 따라 상이하게 틀려질수 있습니다.

그리고 Xeon cpu 를 사용 하고 계시는데 이xeon cpu 의 경우 하이퍼쓰레드 를

지원 합니다. 그러나 win2k 는 완벽히 지원을 하지 못합니다.

이것이 첫번째 이유 입니다.

두번째 이유 입니다.

구성을 계획하고 계시는 사이트 의 DB 커넥션 수라던지 소스의 크기 그리고 가져가는 소스 들의 사이즈 에 따라 성능이 틀려 집니다.

세번재 이유 입니다.

사용 하실수 있는 트래픽의 대역폭이 어떻게 되는 건가요?

그 한계를 끌어 들였을때 동시에 값을 계산을 하여야 합니다.

apache web server 의 경우는 일반적인 지원 커넥션이 256 이고 컴파일을 하면서 옵션을 주며 1024 이 되는걸 알고 있습니다.

그런데 IIS 상에서는 대역폭 설정만 있으며 그 값이 세분화 된것이 아니며

그냥 10만 이하 이상 등의 방법으로 하고 있습니다.

일반적인 사이트 의 경우 동시 접속은 100을 넘는 경우가 드물며.. 활성화된 동호회 사이트 는 1000정도 그리고 잘나가는 게임 사이트 등 초대형 사이트 들은 1 만 에서 10만 정도로 알고 있습니다.

이 서버들이 부하를 못견디는건 웹서비스 가 아닌 DB 커넥션과 소스 의 입출력이 되는

트래픽 입니다.

시물레이션 할 수 있는 방법 또는 평균 예상치(벤치마크) 있나요?

-> 답이 되셨을지...

======================================================

서버용량

======================================================

우선 한게임 싸이트는 일반 웹서비스와 차원이 다릅니다..

각 유저마다 서버가 접속해 있는지 아닌지를 항상 확인하는 데몬(혹은 세션) 이 떠 있어야 하는데..

이것은 즉.. 각 사용자에게 최소한의 패킷 과 메모리가 ( 한 100 bit 쯤 되지 않을까..? ㅡㅡ^ )

할당 되어 있어야 한다는 뜻이죠.. 즉 서버가 엄청난 고사양이어야 한다는 것입니다.

그런데 그것도 한계가 있습니다.

라인 용량의 한계요...결국에는 그래서 서버수를 늘리는 거죠...

모르긴 몰라도 한게임 은.. 한 서버당 최대 수용이 800 정도가 아닐까 하는

개인적인 생각을 가지고 있습니다.

암튼,

님이 말씀하시는 싸이트의 성격이 어떤 서비스를 하려는 곳인지는 잘 모르겠지만,

우선 제 경험 상으로는.. [ 제가 운영하는 곳은 쇼핑몰입니다.]

동시 접속자 수가 편균 3000 입니다.

최대 수용은 4000 정도가 되죠..

웹서버 3 대와 관리자서버 1 대 , 파일서버가 1 대, 디비 서버가 1 대죠..

일반적으로 이렇게들 생각하실겁니다..

"아니 그럼 웹서버 한대가 1000 ~ 1400 을 커버 한단 말야..? "

가능합니다 충분히....더 할 수도 있습니다.

문제는 위에 말씀드렸던 세션 부분과 메모리 할당은 어떻게 최소화 할 것이냐와

네트워크를 오가는 패킷[데이타] 를 어떻게 최소화 할 것이냐의 문제..

그리고 데이터 베이스와의 통신의 양을 가장 적게 할 수 있는 방법들을 살펴 보면 가능합니다...

즉 시스템의 튜닝 뿐 아니라 돌아가는 프로그램의 [ 그것이 웹서비스던, 아니던간에~!!]

튜닝도 같이 이뤄져야 한다는 것을 의미합니다.

서버가 100 Mbps 의 라인을 이용하고 있다고 칩시다.

이론적으로 100 Mbps 지만.. 실제로는 네트웍이 30Mbps ~ 35Mbps 면 잘 나오는 겁니다.

그러면 봅시다...

한 서버가 초당 내보낼수 있는 라인의 용량의 한계가 35Mbps 라고 한다면..

동시접속자수가 1000 명이라고 할때..

한명당. 35 Kbps 정도가 한계라는 거죠...

또한 아마 저정도면 웹서비스 데몬이 적어도 메모리를 2 Giga 는 되야 할겁니다.

결론은 총체적으로 여러가지 부분에서 선행되어야 하는 문제들이 있지만.

그냥 기본적으로 생각할때..

동시 접속자 수가 5000 정도라고 한다면..

약 서버 5 대 정도와 디비 1 대 정도라고 말씀드릴수 있겠습니다.

( 그외에 관리서버 , 파일 서버, 백업서버, L4 스위치 등등 머 따지구 들자면 끝없지만..)

참고로 저희 사양을 말씀드리면..

웹서버,관리,파일 서버는 2 CPU/2 Giga

디비서버는 4 CPU/8 Giga 입니다..

답변이 되셨을지 모르겠네요

======================================================

동시접속자수 부하에 견디는 하드웨어

======================================================

안녕하세요. AnyMOS 서버팀 입니다.

저희가 가장 어려워 하는 질문이네요...

일반적으로 저희 Q&A를 살펴 보시면 아시겠지만 어느 특정한

서버를 놓고 '이 서버는 몇명의 동시접속자를 수용 할 수 있습니다.'

라고 하는 것은 옛날 서버가 귀하던 시절의 영업 방식입니다.

그러므로 정확한 답변은 드릴 수 없다가 저희가 드릴 수 있는 답변

이고요. 이 부분은 저희와 이상환님의 검증아래 가장 근접한 데이터를

수집하는 것으로 일을 시작해야 합니다. 일반적으로 포털 사이트인

경우 왭서버의 경우엔 시스탬의 부하량 보다는 네트웍의 부하가 우선시

됩니다. 즉 네트웍 대역폭이 받처 주는 상황에서 서버를 선정 하는 것

이 순서입니다. 기본적인 스팩의 서버로 유저들이 접속 할 경우에 대한

CPU점유률 메모리 사용량 등등을 계산하여 하나의 서버가 처리 할 수

있는 용량을 염두해 두시고 필요한 수량을 선정 해야 합니다.

이전에는 접속자가 많은 대형 포탈 서비스 업체인 경우 엔터프라이즈급

의 서버를 많이 선호 하였으나 요즘은 저가 사양의 서버에 사용자의

수에 따라 유연하게 대처 할 수 있는 로드발란싱 기술을 좀 더 선호

하고 있는 추세 입니다. 오버 사이징으로 인한 비용 낭비를 막고

하나의 서버에 집중화 시켜 부담을 주기 보다는 하드웨어나 소프트웨어

적인 결함을 유연하게 대처 할 수 있는 설계가 환영 받고 있죠.

어느정도 답변이 되셨을지 궁금하네요.

혹시 저희 AnyMOS의 제안에 동의 하셨다면 연락 부탁 드리겠습니다.

저희 AnyMOS에서는 고객사가 보다 정확한 서버를 선정하기 위해 필요

로 하는 장비들을 지원해 드리고 있습니다. 물론 비용은 들지 않습니다.

감사합니다.

======================================================

로드 밸런싱을

======================================================

(3) 세션 관리

* 기본적으로 세션 관리 기능 제공

* 세션때문에 관리와 배포가 힘든 경우도 있는데, 대규모 사용자가 있을 경우에는

세션 정보 자체가 오버헤드가 될 수 있고, 로드 밸런싱을 할 때 문제가 발생할 수 있다.

session 객체는 메모리 안에 생성된 객체이기 때문이다. 이 문제는 특정 브라우저를

특정 서버와 통신하도록 로드 밸런싱 서버를 설정함으로써 해결할 수 있기는 하지만,

해당 서버가 다운 되는 등의 경우는 Session Migration을 해주어야 한다.

출처 : http://nimba.tistory.com/m/entry/%EB%8F%99%EC%8B%9C%EC%A0%91%EC%86%8D%EC%9E%90%EC%88%98-%EC%84%9C%EB%B2%84%EC%9A%A9%EB%9F%89-%EB%A1%9C%EB%93%9C-%EB%B0%B8%EB%9F%B0%EC%8B%B1

=나의 웹서버는 얼마나 튼튼한가?

이 문서는 웹서버를 운영하면서 자신의 웹서버가 어디까지 버틸수있는지 웹서버의 임계치를 유추해내는 방법에대한 문서이다. 자 이제부터 내 웹서버는 어디까지 버틸수있을지를 실험해보자.

작성자 : 김형채

작성일 : 2005년 6월

1. 서문

리눅스를 설치하면 대부분 웹서버를 많이 설치한다. 그냥 모르고 설치하는 사람도 있고 개인적은로 웹서버를 운용하기위해서 설치하기도 하고, 공부를 위해서 설치하기도 하는등 다양한 이유로 웹서버는 설치된다.

이 문서는 나의 하드웨어 사양에서 내가 설치한 웹서버의 능력을 알려고 하면 어떻게 해야할까에서 시작된다. 같은 페이지가 보인다고 해서 같은 성능은 아니다. 이제부터 내 웹서버의 성능이 어디까지 나오는지를 테스트해보기로 하자.

2. 테스트를 위한 프로그램

웹서버의 성능 테스트를 위해서는 아래의 프로그램 들이 필요하다.

◆ 웹서버 - 이것은 당연히 설치가 되어있다고 가정한다.

◆ httperf - 웹서버에 부하를 주면서 성능을 측절하는 프로그램이다.

◆ idleconn - Idle connection 을 만들어 주는 프로그램이다. 동시접속자의 상황을 만들수있다.

httperf & idleconn

httperf 는 아래의 주소에서 다운로드 받을수 있으며 설명서도 제공되므로 참고하기 바란다.

http://www.hpl.hp.com/research/linux/httperf/

ftp://ftp.hpl.hp.com/pub/httperf/

wget 을 이용해서 다운로드 받는다

[root@ns src]# wget ftp://ftp.hpl.hp.com/pub/httperf/httperf-0.8.tar.gz

--15:31:03-- ftp://ftp.hpl.hp.com/pub/httperf/httperf-0.8.tar.gz

=> `httperf-0.8.tar.gz'

Resolving ftp.hpl.hp.com... 192.6.19.21

Connecting to ftp.hpl.hp.com[192.6.19.21]:21... connected.

anonymous로서 로그인하고 있습니다...로그인 했습니다!

==> SYST ... 완료. ==> PWD ... 완료.

==> TYPE I ... 완료. ==> CWD /pub/httperf ... 완료.

==> PASV ... 완료. ==> RETR httperf-0.8.tar.gz ... 완료.

길이: 146,107 (unauthoritative)

100%[===============================>] 146,107 73.21K/s

15:31:07 (73.06 KB/s) - `httperf-0.8.tar.gz' saved [146,107]

다운받은 파일의 압축을 해제한다

[root@ns src]# tar -xvzf httperf-0.8.tar.gz

httperf-0.8/

httperf-0.8/timer.h

httperf-0.8/core.c

httperf-0.8/httperf.c

httperf-0.8/core.h

httperf-0.8/event.h

------- 중략 --------

httperf-0.8/config.guess

httperf-0.8/aclocal.m4

httperf-0.8/idleconn.c

[root@ns src]#

일반적인 소스 설치 방법대로 아래 과정을 수행해서 설치해준다.

./configure

make

make install

동시접속자를 만들기 위한 idleconn은 설치시에 복사되지 않으므로 수동으로 복사해준다.

[root@ns httperf-0.8]# cp idleconn /bin/idleconn

3. 성능측정

자 이제 설치를 모두 마쳤으면 성능을 측정해 보기로 하자.

테스트는 일단 idleconn을 이용하지 않은 상태에서 테스트하고, idleconn을 이용해서 접속자를 많이 생성한후에 한번 진행해 보기로 하자.

httperf의 각 옵션은 다음과 같다.

--server 서버주소 : 여기에 적어 준 서버로 접속을 시도하게 된다.
--port 숫자 : 여기에 적어 준 포트로 접속을 시도하게 된다. 웹서버는 기본적으로 80번 포트를 사용하지만 정확한 측정을위해서는 8080등의 포트를 이용할 것을 권장한다. (측정중 일반 사용자의 접속이 있으면 결과가 제대로 나오지 않기 때문이다.)
--num-conns 숫자 : 서버로 총 몇개의 접속을 만들 것인지를 결정한다.
--rate 숫자 : 1초에 몇개의 접속을 만들 것인지를 결정한다.
--timeout 숫자 : 이곳에 주어진 숫자만큼의 초동안 기다린 후 응답이 없는 연결은 timeout 에러로 처리한다.
--think-timeout 숫자 : CGI등 서버쪽에서 처리해야 하는 일들이 있는 페이지의 경우 서버측에 이를 처리할 시간을 준다. timeout에서 이곳에 주어진 숫자만큼을 더한 값이 진짜 timeout값이 된다.
--hog : 가능한 모든 포트를 사용한다. 이 옵션을 주지 않으면 기본적으로 1024부터 5000까지의 포트만 사용한다.

httperf --server=linuxhowto.co.kr --uri=/ --port=80 --num-conns=500 --rate=50 --timeout=5 --think-timeout=5 --hog

위의 명령은 linuxhowto.co.kr 이라는 주소를 가진 서버의 / 페이지에 80번 포트로 1초에 50개씩 총 500개의 접속을 만들게 된다. 또한 5초간 응답이 없을 경우 시간초과 에러로 처리한다.
웹서버가 정상적으로 요청을 처리한다면 10초후에는 결과가 나타난다

4. 결과분석방법

실제 테스트 결과 아래와 같은 결과가 나타난다.

각 항목이 무엇을 말하는지는 알아보자.

Total: connections 500 requests 500 replies 500 test-duration 9.983 s

Connection rate: 50.1 conn/s (20.0 ms/conn, <=1 concurrent connections)

Connection time [ms]: min 1.6 avg 1.8 max 2.9 median 1.5 stddev 0.1

Connection time [ms]: connect 0.0

Connection length [replies/conn]: 1.000

Request rate: 50.1 req/s (20.0 ms/req)

Request size [B]: 67.0

Reply rate [replies/s]: min 50.0 avg 50.0 max 50.0 stddev 0.0 (1 samples)

Reply time [ms]: response 1.8 transfer 0.0

Reply size [B]: header 217.0 content 5726.0 footer 0.0 (total 5943.0)

Reply status: 1xx=0 2xx=500 3xx=0 4xx=0 5xx=0

CPU time [s]: user 3.06 system 6.90 (user 30.7% system 69.1% total 99.8%)

Net I/O: 294.0 KB/s (2.4*10^6 bps)

Errors: total 0 client-timo 0 socket-timo 0 connrefused 0 connreset 0

Errors: fd-unavail 0 addrunavail 0 ftab-full 0 other 0

결과는 6개의 그룹으로 표시되고 전체테스트 요약("Total"), 접속상태관련("Connection"), HTTP request 부분 ("Request"), 서버로부터 받은 응답부분 ("Reply"), CPU 시간과 network bandwidth 사용량, 마지막으로 에러집계 ("Errors") 부분으로 구성된다

실제 테스트 결과에서 주의깊게 보아야 하는부분은 서버의 응답시간을 표시하는 Reply time 부분이다.

위의 결과에서는 응답시간이 1.8 ms 인것을 확인할수 있다.

5. 웹서버 괴롭히기

테스트결과 웹서버가 50개씩 500번은 무리없이 수행하는것을 알수있다.

자 그럼 웹서버를 좀 괴롭혀보기로 하자. 컴파일시에 생성된 idleconn 을 이용해서 동시접속자를 한번 만들어보자. idleconn 이라고 치면 아래처럼 사용법이 나온다.

[root@ns httperf-0.8]# idleconn

Usage: idleconn server port numidle

동시접속자를 한 250명정도 만들어본다

[root@ns httperf-0.8]# idleconn linuxhowto.co.kr 80 250

idleconn: creating and maintaining 250 idle connections

동시접속자가 정말 만들어 졌는지 확인해보자

[root@ns ~]# netstat -anpt|grep httpd|grep ESTA|wc -l

250

보는것처럼 250개의 연결된 접속을 생성해냈다.

이제 앞에서 테스트했던 방법대로 한번더 해보자.

httperf --server=linuxhowto.co.kr --uri=/ --port=80 --num-conns=500 --rate=50 --timeout=5 --think-timeout=5 --hog

Total: connections 500 requests 500 replies 500 test-duration 9.982 s

Connection rate: 50.1 conn/s (20.0 ms/conn, <=1 concurrent connections)

Connection time [ms]: min 1.4 avg 1.9 max 16.2 median 1.5 stddev 0.7

Connection time [ms]: connect 0.0

Connection length [replies/conn]: 1.000

Request rate: 50.1 req/s (20.0 ms/req)

Request size [B]: 67.0

Reply rate [replies/s]: min 50.0 avg 50.0 max 50.0 stddev 0.0 (1 samples)

Reply time [ms]: response 1.9 transfer 0.0

Reply size [B]: header 217.0 content 5726.0 footer 0.0 (total 5943.0)

Reply status: 1xx=0 2xx=500 3xx=0 4xx=0 5xx=0

CPU time [s]: user 2.91 system 7.03 (user 29.2% system 70.5% total 99.6%)

Net I/O: 294.0 KB/s (2.4*10^6 bps)

Errors: total 0 client-timo 0 socket-timo 0 connrefused 0 connreset 0

Errors: fd-unavail 0 addrunavail 0 ftab-full 0 other 0

아직까지는 별 문제없이 잘 견디는것 처럼 보인다.

그럼 약간 더 괴롭혀 보자.

이번에는 1초에 200개씩 요청하고 10000번 해보자.

httperf --server=linuxhowto.co.kr --uri=/ --port=80 --num-conns=10000 --rate=200 --timeout=5 --think-timeout=5 --hog

Total: connections 10000 requests 10000 replies 10000 test-duration 49.999 s

Connection rate: 200.0 conn/s (5.0 ms/conn, <=3 concurrent connections)

Connection time [ms]: min 0.2 avg 1.8 max 13.3 median 1.5 stddev 0.3

Connection time [ms]: connect 0.0

Connection length [replies/conn]: 1.000

Request rate: 200.0 req/s (5.0 ms/req)

Request size [B]: 67.0

Reply rate [replies/s]: min 199.8 avg 200.0 max 200.0 stddev 0.1 (10 samples)

Reply time [ms]: response 1.8 transfer 0.0

Reply size [B]: header 217.0 content 5726.0 footer 0.0 (total 5943.0)

Reply status: 1xx=0 2xx=10000 3xx=0 4xx=0 5xx=0

CPU time [s]: user 14.05 system 35.47 (user 28.1% system 70.9% total 99.0%)

Net I/O: 1173.9 KB/s (9.6*10^6 bps)

Errors: total 0 client-timo 0 socket-timo 0 connrefused 0 connreset 0

Errors: fd-unavail 0 addrunavail 0 ftab-full 0 other 0

아직까지는 별문제 없는 상태이다.

이번에는 좀 더 많은 부하를 줘보자. 아래는 초당 1000 개의 요청을 20000개가 될 때까지 테스트하는 예이다.

[root@ns ~]# httperf --server=linuxhowto.co.kr --uri=/ --port=80 --num-conns=20000 --rate=1000 --timeout=5 --think-timeout=5 --hog

httperf --hog --think-timeout=5 --timeout=5 --client=0/1 --server=linuxhowto.co.kr --port=80 --uri=/ --rate=1000 --send-buffer=4096 --recv-buffer=16384 --num-conns=20000 --num-calls=1

Maximum connect burst length: 13

Total: connections 12506 requests 10011 replies 9984 test-duration 28.036 s

Connection rate: 446.1 conn/s (2.2 ms/conn, <=1022 concurrent connections)

Connection time [ms]: min 3.3 avg 876.3 max 12766.8 median 290.5 stddev 1345.5

Connection time [ms]: connect 546.2

Connection length [replies/conn]: 1.000

Request rate: 357.1 req/s (2.8 ms/req)

Request size [B]: 67.0

Reply rate [replies/s]: min 107.2 avg 399.2 max 499.2 stddev 165.2 (5 samples)

Reply time [ms]: response 336.2 transfer 0.0

Reply size [B]: header 217.0 content 5726.0 footer 0.0 (total 5943.0)

Reply status: 1xx=0 2xx=9984 3xx=0 4xx=0 5xx=0

CPU time [s]: user 1.08 system 20.19 (user 3.9% system 72.0% total 75.9%)

Net I/O: 2090.1 KB/s (17.1*10^6 bps)

Errors: total 10016 client-timo 2522 socket-timo 0 connrefused 0 connreset 0

Errors: fd-unavail 7494 addrunavail 0 ftab-full 0 other 0

[root@ns ~]#

결과를 보면 타임아웃으로 처리를 못하는 경우가 절반이상이고, 응답시간도 매우 길어졌음을 알수있다

5초안에 대답을 못한 요청수가 10016 개이다. 테스트한 웹서버가 이 정도는 무리라는 결론이다.

자 이제 여러분의 웹서버를 마구 괴롭혀서 어디까지 견디는지 테스트해보자.

6. 참고문헌 또는 URL

http://www.hpl.hp.com/research/linux/httperf/docs.php

출처 : http://jikime.tistory.com/284 동시접속자수 테스트 방법 참조

출처 : http://phpdoumi.tistory.com/147

SVN의 cleanup 에러시 해결방법

JAESOO — Wed, 04 May 2016 20:12:59 +0000

SVN으로 업데이트 하다가 도중에 끊겼는데 다시 업데이트를 실행하니

cleanup 에러가 발생 합니다.

그래서 cleanup 을 실행했떠니 또 에러가 뜹니다. '-' 난감합니다.

[에러코드]

Previous operation has not finished; run 'cleanup' if it was interrupted

svn cleanup failed–previous operation has not finished; run cleanup if it was interrupted

[해결방법]

Windows의 경우 http://www.sqlite.org/download.html 에서 sqlite를 다운받아 SVN 폴더에 복사

cmd 에서 SVN폴더로 이동한다음에 아래의 명령을 주면 됩니다.

sqlite3 .svn/wc.db "select * from work_queue"

sqlite3 .svn/wc.db "delete from work_queue"

보아하니 svn은 sqllite를 사용하는것 같고 work_queue에 업데이트 명령을 담아두고 실행하는것 같은데

중간에 연결이 끊어지니 work_queue의 내용이 꼬인것 같습니다.

work_queue를 delete 하고 다시 SVN의 cleanup 명령어를 준뒤 업데이트 명령을 실행하니

문제없이 최신 소스로 업데이트 되었습니다.

출처 : http://doswlf.tistory.com/489

[오류해결] svn cleanup failed-previous operation has not finished; run cleanup if it was interrupted

JAESOO — Wed, 04 May 2016 20:00:15 +0000

Previous operation has not finished; run 'cleanup' if it was interrupted

svn cleanup failed–previous operation has not finished; run cleanup if it was interrupted

직접 겪은 것은 아니고, 동료가 겪은 문제라 해결을 도와주다가 알게 된 방법입니다.

실제 해결 방법은 가장 마지막에 작성한 참고 블로그를 통해 알게 되었습니다.

일단 정확한 발생 원인은 모르겠으나 SVN을 통한 Update 과정에서 발생하는 것으로 보입니다.

Update 과정에 SVN과의 접속이 예상치 못하게 끊겨 정상적으로 처리가 완료되지 못하면 종종 발생하는 것 같습니다.

일단 SVN Clean up 을 통해서 해결이 될 줄 알았습니다.

오류 안내 메시지가 그랬거든요.

이전 작업 도중이 완료되지 못하였습니다. 만약 작업 중단되었다면 'cleanup' 을 실행하세요.

SVN cleanup 실패 - 이전 작업이 완료되지않았습니다. 만약 작업 중단되었다면 'cleanup' 을 실행하세요.

그런데 cleanup 을 하고 실행해도 같은 오류가 계속하여 뜹니다.

해결 방법은 다음과 같았습니다.

* SqlLite 내려 받은 후, 프로젝트의 SVN 폴더에 복사합니다.

아래 주소에서 받으실 수 있습니다. (윈도우 사용자인 경우 아래 스크린샷에 빨간 박스로 된 파일을 받으시면 됩니다. 다른 환경이라면 환경에 맞는 파일을 받으시면 될 것 같은데, Eclipse SVN 사용하시는 분들이 대다수 윈도우 환경 개발자이겠지요?^^)

SQLite Download Page : http://www.sqlite.org/download.html

또는 아래 파일을 그냥 내려 받으시면 됩니다. (제가 미리 받아놓은 파일입니다. ㅎㅎㅎ)

sqlite-shell-win32-x86-3081101.zip

내려 받은 후, 압축을 푸시면 sqlite3.exe 파일이 하나 있습니다.

이 파일을 문제가 발생한 프로젝트의 .svn 폴더에 복사합니다. (프로젝트의 하위 폴더에 있습니다.)

그리고 윈도우 커맨드창(Command Window)을 실행하여 해당 경로로 이동한 후, 아래 명령어 2개를 순차적으로 실행합니다.

sqlite3 .svn/wc.db "select * from work_queue"

sqlite3 .svn/wc.db "delete from work_queue"

왜 갑자기 svn 오류를 해결하는데, sqlite 프로그램이 나왔냐고 의아해 하실 수도 있을 것 같은데요.

아마도 svn에서 sqllite를 사용하는 것으로 보입니다. 그리고 그 작업 처리(명령)를 work_queue라는 테이블에 저장하고 있는 것이구요. 이 work_queue 테이블의 정보가 SVN이 갑자기 작업 중에 중단되면서 문제가 발생한 것으로 보이는데요.

그래서 데이터베이스 테이블에 저장된 이 작업들을 모두 초기화하여 문제를 해결하는 것으로 보입니다.

위의 2개의 명령어까지 문제 없이 잘 실행되었다면 다시 Eclipse를 실행하여 해당 프로젝트의 파일들을 Update받아보시길 바랍니다.

만약 동일한 오류나 유사한 오류가 다시 나타난다면 SVN의 Cleanup 명령어를 다시 한 번 실행한 후, Update 받아보세요!

참고

http://kure0769.tistory.com/entry/SVN-cleanup-fail-%EC%B2%98%EB%A6%AC

출처 : http://ooz.co.kr/281

TortoiseSVN 계정변경

JAESOO — Wed, 04 May 2016 19:58:28 +0000

출처 : http://blog.daum.net/pascal24/15122171

SVN passwd 설정 : 계정 (users/passwd)

JAESOO — Wed, 04 May 2016 14:38:28 +0000

passwd 설정 : 계정(users/passwd)

/svn/저장소 디렉토리/conf/passwd

- 원본은 보관하고 새로 만든다.

]# cd /svn/okkks.tistory.com/conf/

]# ll

]# cat passwd

]# mv passwd passwd.old

]# vi passwd

[users]

user1 = 1234

user2 = 1234

설명

- 2명의 계정 생성(user1/1234, user2/1234)

svn 설치

- svn(Subversion) 설치 확인 및 설치하기

svn 설정

- 01. svn 저장소(repository) 만들기

- 02. svn 서비스 데몬 만들기

- 03. svn svnserve.conf 설정

- 04. svn passwd 설정 : 계정(users/passwd)

- 05. authz 설정 : 권한

출처 : http://okkks.tistory.com/979

[SVN] Subversion 명령들

JAESOO — Fri, 05 Feb 2016 16:41:42 +0000

Subversion 에서 사용되는 기본적인 명령들을 알아보자. IDE (통합 개발환경)을 사용하면 쉽게 사용할 수
있는 기능들이지만 커맨드 사용법을 알아두면 유용하게 사용할 수 있다. 커맨드를 직접 사용해 보면 내부동작을
좀 더 쉽게 이해할 수 있으며 특히 자동화 스크립트를 작성할 때 도움이 된다.
(소스관리 프로젝트를 위해 svn 명령을 사용할 경우와 svn 자바 라이브러리를 다룰 때도 도움이 된다. )

다음과 같은 순서로 Subversion 사용방법을 알아보겠다.

1 저장소 생성
2 프로젝트 생성
3 프로젝트 저장소에 임포트(import)
4 작업본(working copy) 내려받기(checkout)
5 woking copy에 파일 추가(add)
6 로컬 수정사항 커밋(commit)
7 저장소 변경사항 업데이트 받기 (update)
8 브랜치/태그 (저장소 파일 복사/이동)
9 저장소 파일 삭제
10 working copy 정보 보기

1. 저장소(Repository) 생성

가장 먼저 해야할 일은 저장소를 생성하는 작업이다. 저장소 생성에 관련된 내용은 지난 포스팅을 참고하기 바란다.

svnadmin create --fs-type fsfs MyRepository

2. 프로젝트 생성

이제 저장소에서 관리할 프로젝트를 위한 최초 디렉토리 구조를 로컬상에 생성한다.
다음과 같은 구조로 "문서관리 시스템"을 위한 디렉토리 구조를 생성하였다.

3. 프로젝트 저장소에 임포트(import)

이제 로컬에 생성한 프로젝트를 저장소로 옮기자. 이 작업은 공유를 위한 프로젝트 최초 기본파일을 구성하는 단계이다.
아래 명령으로 로컬 프로젝트 파일을 저장소로 복사한다.

svn import -m "First DMS Project Import" ./dms

저장소에 프로젝트 파일들이 옮겨졌기 때문에, 로컬 상에 있는 프로젝트 파일들을 삭제하자.
이제 저장소에 있는 파일들이 모든 공유 문서들의 원본이 되고, 변경이 추가될 때마다 그 이력이 버전별로 관리가 된다.

4. 작업본(working copy) 내려받기(checkout)

여러 사람이 저장소에 접근하여 산출물을 공유할 수 있게 되었다. 저장소에 있는 프로젝트 파일들을
로컬상에 먼저 내려 받아보자. 로컬상에 자신이 다루게 되는 프로젝트 파일들을 작업본(working copy) 이라고 한다.
작업본 내 모든 디렉토리에는 숨김파일 .subversion 이 생성되며 디렉토리 내 파일들의 목록과 수정사항들이 관리된다.

svn checkout svn://repository_ip_address/MyRepository/trunk dms

※ svn 명령들은 -r (revision) 옵션을 주어 아래와 같이 특정 리비전의 파일들을 다운 받을 수 있다.
svn checkout -r 7 svn://repository_ip_address/MyRepository/trunk dms

5. 작업본에 파일 추가 (add)

내려받은 작업본을 기반으로 자신이 담당한 모듈을 개발해 나가면 된다.
새로운 파일을 작업본에 추가하고 싶은 경우, 새로운 파일을 생성하는 것만으로는 되지 않는다.
작업본 파일목록에 명시적으로 새로 생성한 파일을 번영해 주어야 한다. 다음과 같은 명령을 사용한다.

svn add build.xml

6. 로컬 변경사항 커밋 (commit)

작업본에 대한 모든 수정사항은 커밋을 해야 저장소에 반영이 된다. 파일 하나하나를 수정할 때마다
커밋을 하는 것은 좋은 방법이 아니다. 에러가 발생하는 파일들을 저장소에 반영하면 업데이트를 받은 다른 팀웍들의
작업에도 영향을 주기 때문이다. 되도록이면 명확한 단위작업별로 구분하여 완전히 동작하는 수정사항만을 커밋하는
것이 좋다. 커밋을 할 때마다 -m 옵션으로 변경사항에 대한 메시지를 반드시 달아주어 변경에 대한 정보를 알수있게 하자

svn commit -m "Added build.xml ant file"

7 저장소 변경사항 업데이트 받기 (update)

작업본 checkout 이후부터, 작업을 시작하기 전에 저장소 최신 변경사항을 update 받아 작업본을 최신버전으로
유지하는 것이 좋다. 저장소와 작업본 사이에 버전 차이가 커질 수록 나중에 commit이 충돌문제가 발생할 수 있기
때문이다. 다음 명령으로 저장송 변경사항을 작업본에 최신화시킨다.

svn update

8 브랜치(branch)와 태그(tag)

특정시점의 문서버전(예를 들어 1차 개발버전과 같은...)에 대한 복사본을 남겨두고 싶을 때 브랜치를 사용한다.
브랜치를 사용하면 복사본이 생성되고, 이후 수정작업들은 다시 작업본에 계손 수정되어 나간다. branch는 가지라는 뜻으로
현재 작업버전에 대해 분기점이 되는 버전이라는 의미를 갖는다. 태그는 브랜치와 비슷한 의미를 갖지만, 분기되어
완전히 작업이 완료된 버전(첫번째 릴리지 버전과 같은...)이며 이름표를 달아서 알아보기 쉽게 표시를 한다.
svn에서 브랜치와 태그를 생성하는 명령은 copy 로 동일하다. 태그 생성시는 t 옵션을 주어 이름표를 달아준다.

브랜치 생성

svn mkdir -m "Create branch directory" svn://repository_ip_address/MyRepository/branches

svn copy -m "Creating release branch for 1.0" svn://repository_ip_address/MyRepository/trunk \

svn://repository_ip_address/MyRepositorybranches/RB-1.0

태그 생성

svn mkdir -m "Create branch directory" svn://repository_ip_address/MyRepository/tags

svn copy -m "Tag release 1.0.0" svn://repository_ip_address/MyRepository/branches/RB-1.0

svn://repository_ip_address/MyRepository/tags/REL-1.0.0

9. 저장소 파일 삭제 (delete)
저장소에 있는 파일을 삭제하는 명령은 다음과 같다. 파일 삭제후 update 를 수행하면 작업본에도 반영이 된다.

svn delete -m "Remove branch 1.0" svn://repository_ip_address/MyRepository/branches/RB-1.0

10. working copy 정보보기

다음명령으로 작업본 리비전 정보와 저장소 루트, 최신 수정일 등의 정보를 확인할 수 있다.

svn info

출처 : http://hiddenviewer.tistory.com/94

성능 엔지니어링 대한 접근 방법 (Performance tuning)

JAESOO — Mon, 24 Aug 2015 11:43:16 +0000

성능 엔지니어링에 대한 접근 방법

조대협

성능 개선, Performance Tuning, 용량 선정 과 같은 튜닝 관련 용어들은 모든 개발자나 엔지니어에게 모두 흥미가 가는 주제일 것이다. 그 만큼 소프트웨어에서 고성능을 내는 시스템은 만들기도 힘들뿐더러, 고성능 시스템이란 즉 잘 설계되고 구현된 소프트웨어를 뜻하는 것이니 관심을 가지는 것이 당연하지 않을까 싶다.

필자의 경우, 엔터프라이즈 시스템에 대한 약 6년간 장애 해결, 장애 회피 설계, 성능 개선, 고성능 시스템 설계 및 구현에 관련된 일을 해왔다. 특히 장애 해결과 성능 개선 작업은 하고 나면 뿌듯하기는 하지만, 특정한 기술이 필요하기 보다는 문제를 정의하고 접근하는 능력과 끝까지 목표를 달성할 때까지 지루한 작업을 반복적으로 할 수 있는 인내심을 필요로 하는 작업이다

이번 챕터에서는 Performance Engineering의 전반적인 접근 방법과, 용량 산정 방법 그리고 자바 기반의 서버 애플리케이션에 대한 성능 튜닝 및 병목 발견 방법에 대해서 설명하고자 한다.

Performance Engineering 의 정의와 범위

Performance Engineering은 시스템의 목표 성능 (응답 시간과 동시 접속자수)을 정의 하고, 이를 달성하기 위해서, 시스템의 구조를 반복적으로 개선하는 작업을 이야기 한다.

좁게 생각하면, 코드상의 병목을 잡고, 시스템의 설정(Configuration)을 바꿔서 성능을 올리는 튜닝으로 생각할 수 있지만, 성능 목표의 정의에서 부터, 최적의 성능을 내기 위한 디자인 및 구현과 같은 개발 초기의 설계 부분와 개발후의 운영단계에서 모니터링 까지 전과정을 포함한다.

Performance Engineering은 언제 해야 하는가?

Performance Engineering은 전체 소프트웨어 개발 과정에 걸쳐서 크게 아래와 같이 4단계에 걸쳐서 일어난다.

위의 개발 모델은 전형적인 Water fall model이다. 개발프로세스 챕터에서도 설명하였지만, 스크럼과 같은 애자일 방법론을 사용하더라도 큰 범위에서 개발 사이클은 Waterfall 모델과 크게 다르지 않게 된다. (각 단계별을 SPRINT 단위로 수행한다.)

분석 단계

초기 요구 사항 분석 및 시스템 기획 단계에서는 성능에 대한 목표를 정해야 한다.

목표 응답시간은 어떻게 되는지, 시스템을 사용할 총 사용자수와 동시에 시스템을 사용하는 동시접속자 수가 어떻게 되는지와 같은 성능 목표를 정의한다.

또한 고려해야 하는 사항중의 하나는 성능 모델이다. 시스템에 부하가 어떤 패턴으로 들어오는지를 정의할 필요가 있다.

예를 들어 일반적인 웹컨텐츠 사이트의 경우 사용자가 들어와서 페이지 컨텐츠를 1~3분 내에 읽고 다른 페이지로 이동하다가, 20 여분 후에는 로그아웃하거나 다른 사이트로 이동한다. 즉 한 사용자의 체류 시간은 20분정도되며, 총 평균 20 페이지를 보는 트렌젝션을 발생 시키고 나간다고 할 수 있다. 한글로 만든 사이트이고, 육아나 주부를 대상으로 한 사이트라고 가정하면, 시스템의 부하는 한국 시간으로 아이들이 학교나 유치원을 간후인 10시~11시와, 저녁시간대인 10시~12시 사이에 몰린다고 가정할 수 있다.

다른 예로 게임 시스템을 예로 들어보자, 주로 초등학생을 타켓으로 한 게임이라면, 방과후 시간인 3시~5시 대에 부하가 가장 몰릴 것이며, 게임의 종류에 따라 다르겠지만, 스타크래프트와 같은 게임의 경우 한번 플레이에 40분 정도 소요가 되고, 한 사용자가 하루에 두번정도 게임을 한다 가정 아래, 사용자당 체류 시간은 2시간, 게임 횟수는 2회/일. 그리고 주요 부하는 3~5시 오후대 라는 성능 모델을 만들 수 있다.

초기 성능 정의는 서비스의 종류(웹,게임,기업 시스템,쇼핑,뱅킹등) 나, 서비스를 사용하는 사용자층, 그리고 서비스를 사용하는 지역. 즉 전세계를 서비스하는 시스템이라면 시스템의 부하는 365일,24시간 거의 다 걸린다고 봐야 한다. 그러나 한국만을 대상으로 서비스 하는 한국어로 된 사이트인 경우, 새벽 시간에는 일반적으로 로드가 없는 것과 같은 한국의 시간대에 영향을 받을 뿐만 아리나 명절,휴일,휴가와 같은 한국이라는 국가 특성에 따라 시스템의 부하가 영향을 받는다.

디자인 단계

다음으로는 디자인 단계에서는 목표 성능과 용량을 달성할 수 있는 규모의 시스템으로 설계를 진행한다.

성능 관점에서 시스템 디자인은 항상 Peak Time (최대 성능)에 맞춰서 디자인이 된다. 최대 성능을 기반으로 전체 시스템이 받아낼 수 있는 용량과 응답 시간을 고려해야 한다.

특히 성능과 용량은 애플리케이션 디자인 뿐만 아니라 Technology selection에도 많은 영향을 받는다. 어떤 하드웨어를 사용할 것인지, 어떤 미들웨어나 프레임웍을 사용할 것인지이에 따라 용량과 성능의 차이가 많이 발생하기 때문에, 디자인 단계에서 부터 성능과 용량을 감안해서 시스템을 설계해야 한다.

하드웨어 관점에서는 예전에는 성능 모델을 산정한 후에, Peak Time 기준 (최대 성능 요구)으로 시스템을 설계하고, 하드웨어를 구매 하였으나, 근래에는 클라우드를 이용하여 필요시에만 하드웨어를 탄력적으로 사용하는 Auto Scale Out 모델을 많이 사용한다.

기업 내부의 업무 처럼 (예를 들어 이메일), 부하가 일정하고 예측이 가능한 경우에는 Fixed 된 사이즈의 하드웨어를 사용하도록 설계 하고, 출시 이벤트 행사 사이트와 같이 부하가 갑자기 몰리는 시스템의 경우 클라우드를 고려해보는 것도 권장할만 하다.

또한 빠른 응답 시간이 필요할 경우 SSD 디스크를 사용하거나, RAID 구성도 5보다는 1+0 등을 고려하는 등, 성능 모델에 따라서 적절한 하드웨어 선정과 구성 설계가 필요하다.

나 프레임웍 관점에서도 정의된 성능 모델에 따라 적절한 제품군과 설계 구조를 채택해야 한다. 100,000 사용자 정도의 시스템 규모에서는 RDBMS 를 사용해도 성능이나 용량상에 문제가 없다. 그러나 50,000,000 사용자 정도를 지원해야 하는 시스템의 경우 그냥 RDBMS 를 사용할 수 없다. Sharding이나, NoSQL과 같은 다른 차원의 접근이 필요하다.

또한 빠른 응답 시간을 요구하는 경우 Redis나 Memcached와 같은 Cache 솔루션을 적극적으로 활용하거나, 미들웨어 부분에서는 Tomcat과 같은 일반적은 Web Application Server 보다는 Netty나 Vertex와 같은 고성능 미들웨어를 고려해볼 수 있다.

이러한 성능이나 용량에 관련된 제품 선정이나 설계는 돌려 보지 않으면 사실 확신을 가지기 어렵다. 그래서 가능하면, Technology selection 후에, 간단한 프로토타입을 구현한후에 시나리오가 단순한 대규모의 성능 및 용량 테스트를 해보는 PoC (Proof Of Concept)과 같은 작업을 이 단계에서 수행하는 것을 권장한다.

개발단계

개발 단계는 개발프로세스 챕터에서 설명하였듯이, risk 가 높은 부분과 아키텍쳐에 관련되는 부분, 난이도가 높은 부분, 핵심 기능등을 개발 초기의 스프린트에서 개발한다.

초기 스프린트가 끝나고 릴리즈가 되서 성능 테스트가 가능한 QA나 스테이징 환경으로 시스템이 이전되면, Performance Engineering 역량을 이 단계에 집중하여, 시스템의 아키텍쳐와 모듈들이 성능 목표를 달성할 수 있는지 지속적으로 테스트하고 튜닝을 수행한다.

초기 단계에 성능 목표의 달성 가능 여부가 판단되어야, 아키텍쳐 변경이 가능하고, 주요 성능 이슈들을 초반에 발견해야, 발견된 성능 문제들에 대해서는 같은 문제가 발생하지 않도록 디자인 가이드나 코딩 가이드를 개발자들에게 배포하여 성능에 대한 위험도를 줄일 수 있다.

최종 테스트 단계

앞의 단계에서 성능과 용량을 고려해서 설계가 되었고, 개발 초기 단계에서 성능과 용량 부분을 검증을 제대로 하였다면, 최종 테스트 단계에서는 개발된 최종 시스템에 대한 성능과 용량 부분의 측정과 미세 튜닝 (애플리케이션의 병목을 찾아서 부분적으로 수정하거나, 하드웨어나 미들웨어의 Configuration 하는 수준)을 하는 정도로 마무리가 되어야 한다.

이 과정에서는 실수로 잘못한 설정(configuration) 이나 잘못된 코딩으로 된 부분에 대해서 검증이 이뤄지는데, 이 경우에는 보통 2배에서 크게는 10배까지의 성능 향상이 이루어진다. 이런 경우는 대부분 실수에 의한 것이고 성능이 터무니 없이 낮게 나오기 때문에 찾기가 쉽다.

예를 들어 로그 파일을 NFS와 같은 리모트 디스크에 쓴다던지, Intel 계열의 CPU에서 하이퍼쓰레딩을 ON을 안했다던지와 같이 실수에 의한 경우가 많다.

이런 오류성의 문제들이 해결되면 실제 미세 튜닝에 들어가게 되는데, JVM 튜닝이나 톰캣의 설정 튜닝, SQL 튜닝들이 이루어지는데, 이 미세 튜닝을 통해서는 비약적인 성능향상은 이루어나지 않는다. 보통 20% 내외 정도 성능이 올라간다고 보면 된다.

운영 단계

마지막으로 시스템이 운영 단계로 넘어가게 되면, 테스트시에 발견되지 않은 성능적인 문제가 있을 수 있기 때문에, 모니터링 도구를 사용하여 지속적으로 성능을 모니터링 하고, 성능상에 문제가 있는 부분을 지속적으로 수정해야 한다. 웹서버의 access로그에서 응답 시간을 모니터링 하거나, 제니퍼(http://www.jennifersoft.com)과 같은 전문적인 APM (Application Performance Monitoring)툴이나, Ganglia와 같은 시스템 모니터링 도구를 사용하면, 시스템의 성능 상태를 잘 알 수 있다.

더불어 용량 부분에 대해서도 운영단에서는 고민을 해야 하는데, 일반적으로 PEAK Time의 시스템 용량이 (CPU) 80% 정도에 다다르면, 시스템 용량 증설을 고려해야 한다.

그리고 업무에 특성에 맞게 미리미리 용량을 준비해놓는게 좋다. 예를 들어 대학의 수강 신청 시스템의 경우, 학기 시작하는 날에 부하가 폭주하기 때문에, 클라우드 기반일 경우 수강신청 전에 시스템 수를 미리 늘려놓는다던지, 클라우드가 아닌 경우, 수강 신청 기간을 앞뒤로 서버를 임대해서 용량을 늘려놓는 등의 대책을 미리 세워놓을 수 있다.

, 운영 단계에서 Performance Engineering 관점으로 챙겨야 하는 부분은 운영 로그의 수집이다. 성능 및 용량 목표 설정은 매우 중요한 과정이다. 특히 용량 목표의 경우에는 기존의 업무 시스템의 사용 패턴을 분석 하는 것이 가장 효율적이기 때문에 운영 시스템의 로그를 수집하고 분석하여 운영 중인 업무 시스템의 성능 모델을 분석 및 보유 해놓는 것이 좋다.

시스템 용량 산정 (Capacity Planning)

더 자세한 설명에 들어가기 앞서서, 성능에 관련된 용어와 함께 시스템의 목표 용량 산정 방법에 대해서 이야기 해보도록 하자.이 용어는 이 글에서 정의하는 의미의 용어이며, 다른 성능 이론에서 언급되는 용어와 다소 다를 수 있다.

Response Time (응답 시간) : 사용자가 서버에 요청을 한 시간에서 부터, 응답을 받을 때 까지의 모든 시간을 포함한다. 이 응답시간은 내부적으로 다음과 같이 조금 더 세분하게 분리된다.

Network Time (또는 Latency time). 서버에 요청을 했을때, Request를 보내고 받을 때 소요되는 네트워크 시간을 의미한다.

Transaction Time : 서버에서 실제 트렉젝션이 처리되는 시간을 의미 한다.

Think Time : 사용자가 요청에 대해서 응답을 받은 후에, 웹페이지를 보거나 화면을 보는 등의 작업을 하는 시간의 의미한다.

예를 들어 보면 한국의 사용자가 미국이 페이스북을 사용한다고 했을때, 사용자가 웹 브라우져에서 클릭을 하면, 요청이 서버로 도달할때 까지 걸리는 시간 Network time (Request), 서버가 요청을 받아서 처리를 하고, 응답을 하는 시간 (Transaction Time), 그리고 그 응답이 사용자의 브라우져 까지 도착하는 시간이 Network time (Response) 이다. 이 전체 시간을 합친 것이 Response Time이 된다.

응답을 받은 후에는 사용자가 페이스북 내용을 보는데 소요 되는 시간이 Think Time이 된다.

Think Time 까지 포함하여 다음 요청이 발생하기 까지의 전체 시간을 Request Interval 이라고 한다.

Concurrent User (동시 사용자) : 시스템을 현재 사용하고 있는 사용자를 정의한다. 웹사이트를 사용하기 위해서, 현재 브라우져를 열어놓고 웹사이트를 보고 있는 것과 같이 현재 시스템을 사용하고 있는 사용자 수를 의미 한다.

위의 그림을 보자, 5명의 사용자 A~E가 있다고 가정했을 때, 단위 시간 10분동안에 Transaction Time과 Think Time중에 있는 사용자는 A,B,C 총 3명으로 해다 시간 10분간의 Concurrent User는 3명이 된다.

Active User (액티브 사용자) : 현재 시스템에 트렌젝션을 실행하여 부하를 주고 있는 사용자를 정의한다.

기존에는 Concurrent User와 Active User간의 차이가 없었다. 이 개념은 웹이 생기면서 구체화된 개념인데, 웹 사이트를 사용하기 위해서 컴퓨터 앞에 앉아 있는다고 하더라도, 웹 페이지가 로딩 되는 순간에만 서버는 부하를 받고, 페이지가 웹 브라우져로딩 된 후에는 부하를 받지 않고 사용자는 로딩된 페이지를 보는데 시간이 발생한다. 이 시간동안에는 서버는 부하를 받지 않는다. 즉 시스템을 사용하기 위해서 웹 사이트를 열어 놓고 있는다 하더라도 지속적으로 서버에 부하를 주는 것이 아니기 때문에 Concurrent User와 Active User 의 개념 차이가 발생한다.

Active User는 클릭을 발생시켜서 그 시간 당시에 서버에 트렌젝션을 발생 시키는 사용자를 의미한다.

Active User의 수는 서버에서 순간 실행되고 있는 Thread 수 (쓰레딩 기반의 자바 서버의 경우) 나 Process의 수와 같다. 이 Active User의 수는 실제로 서버가 동시에 처리할 수 있는 트렌젝션의 양을 판단할 수 있는 기준이 되기 때문에 매우 중요한 성능 Factor가 된다.

위의 그림을 보자, 위의 그림에서 특정 순간에 있는 사용자는 총 5 명으로 Concurrent User 는 5명이지만, Transaction Time 구간중의 있는 사용자는 A,B,C 로, 총 Active User는 3명이 된다.

Transaction (트렌젝션) : Transaction이란, 사용자로 부터의 요청을 다루는 단위를 정의 한다. 이 정의가 상당히 중요한데, 성능 모델링이나 성능 테스트 시 이 Transaction의 정의에 따라서 시스템의 성능이 매우 다르게 정의 된다.

예를 들어서 사용자가 웹 페이지를 클릭했을때, 그 페이지에 대한 응답을 받는 것 까지를 하나의 트렌젝션이라고 정의 하자.

이 때, 웹페이지에는 서버에서 생생된 HTML 이외에, 여기서 참고 하는 리소스 즉, 이미지나 동영상, 자바 스크립트들이 들어있을 수 있다. 이 경우 트렌젝션에 대한 응답 시간을 측정할때, HTML 생성 이외에 이러한 리소스들을 로딩 하는 것 까지 하나의 트렌젝션으로 정의 해야 하느냐를 고려해야 한다.리소스에 로딩을 트렌젝션의 범위로 넣게 되면 전체 시스템의 응답 시간은 떨어지게 된다. (리소스를 로딩할 때 까지 기다려야 하니).

이러한 트렌젝션의 정의는 무엇을 판단 기준으로 할것인가에 따라 결정이 되는데, 예를 들어 리소스를 톰캣과 같은 WAS에서 처리하지 않고 앞단의 CDN이나 웹서버에서 처리할 경우 톰캣은 리소스에 대한 트렌젝션 요청을 받지 않기 때문에, 전체 시스템에서 비지니스 로직에 대한 처리 성능을 측정하고자 할 때는 리소스에 대한 로딩 시간을 계산하지 않고 트렌젝션을 정의 한다. 또한 리소스에 대한 로딩은 비지니스 로직에 대한 처리에 비해서 부하가 상대적으로 매우 적고, 일반적으로 브라우져에 캐쉬되기 때문에 보통 서버의 성능 측정시 이러한 리소스 로딩에 대한 부하는 트렌젝션의 단위로 처리하지 않는 경우가 많다.

TPS(Transaction Per Second) : 초당 처리할 수 있는 트렌젝션의 양을 정의 한다. 주로 서버의 성능 평가 기준이 된다.

Active 사용자가 순간 Transaction을 처리한다고 하면, 이를 목표 응답시간 (Response Time)으로 나눈 값이 목표 TPS가 된다. 예를 들어, Active User가 50 명이고, 개당 Response Time이 2초 라고 하면, 이 시스템의 TPS는 25 TPS가 된다.
※ Network time이 미세하다고 판단하여, Network time을 0으로 가정하여 계산

HPS(Hit Per Second) : 시스템이 처리할 수 있는 모든 웹 request의 초당 처리량이다. TPS가 비지니스 트렌젝션에 대한 처리 시간만을 정의 한다면, HPS는 리소스 (이미지, 자바스크립트)에 대한 request 처리량을 포함하기 때문에, TPS에 비해서 10~20 배 정도 높게 나온다.
Peak Time(피크 타임) : 서버가 순간적으로 가장 부하를 많이 받는 순간을 정의 한다. 보통 서버의 용량 산정이나 성능 설계는 이 시간의 부하량을 기준으로 한다

일반적인 업무 시스템의 경우, 출근 9시~9시30분 사이가 가장 부하가 높다. 이 때 Peak (최고 정점)을 찍는 순간의 동시 사용자 수와 기준 응답 시간을 목표로 성능 목표를 정의 하는 것이 일반적이다.

위의 개념을 정리해서 공식화 해보자.

TPS = (Active User) / (Average Response Time) – F1
TPS = (Concurrent User) / (Request Interval) – F2
Active User = TPS * (Average Response Time) – F3
Active User = (Concurrent User) * (Average Response Time) / (Request Interval) – F4
Active User = (Concurrent User) * (Average Response Time) / [ (Average Response Time) + (Average Think Time) ] – F5

예를 들어 Concurrent User가 300명이고, 목표 응답시간이 3초 이내이며, Think Time이 15초 인 시스템의 경우, F5 공식에 따라서 Active User는 300*3/(3+15) = 50 이 되며, 시스템의 Thread 또는 적정 Process 양은 50개가 된다. 목표 TPS는 약 16.6 TPS가 된다.

위의 공식은 어디까지나 이론적인 공식이다. Network Latency 값은 가변적이며, Think Time 또한 유동적이다. 그러나 용량 산정에는 어느 정도의 산정 기준이 필요하기 때문에, 이 공식을 사용하면 대략적인 시스템에 대한 요구 용량을 예측할 수 있다.

Performance Engineering 의 절차

그러면 어떤 절차로 성능과 용량을 측정하고 개선하는 절차에 대해서 알아보도록 하자.

성능 목표와 모델의 정의

먼저 주요 업무 패턴이나, 튜닝의 대상이 되는 시나리오에 대한 개별 성능 목표를 정의 한다. 예를 들어 전체 성능 목표가 1,000 동시 사용자에 대해서 응답 시간 1초내의 시스템이 전체 성능 목표라고 가정하고, 전체 성능 목표를 대략 1,000 TPS (Transaction Per Second)라고 하자. 이것이 바로 성능 목표가 된다.

다음으로 성능 모델을 정의 해야 하는데, 해당 시스템의 주요 사용자 시나리오가 여러개 있을 때, 각 시나리오별의 사용 비중을 정의 해야 한다.

예를 들어 사진을 저장하는 클라우드 서비스 시나리오가 있다고 하면, 이 서비스의 주요 사용자 시나리오는

로그인
사진 리스트
사진 업로드
사진 보기
사진 다운로드
로드 아웃

등이 된다. 이 중에서 한 사용자가 실행하는 비율을 따져야 한다. 즉 사용자가 로그인 한후, 리스트 보기를 10번, 업로드를 2번, 보기를 5번, 그리고 다운로드를 1번 한후에 로그 아웃 한다고 하자. 그러면 비율은 다음과 같이 된다. (전체 트렌젝션 횟수 1+10+2+5+1+1 = 20회)

성능 모델 :로그인의 비율 5%, 리스트 보기 50%, 업로드 10%, 보기 25%, 로그아웃 5%

이 비율을 기준으로 복합 시나리오 (전체 시나리오를 함께 돌리는) 부하테스트를 수행하였을때, 1000 TPS가 나와야 하고, 각 개별 시나리오에 대해서 최소한, 로그인의 경우 1000 TPS의 5%인 50 TPS, 리스트 보기는 500 TPS를 상회 해야 한다.

부하 생성

성능 모델이 정의 되었으면, 이 모델에 따라서 부하를 생성해야 한다.

부하 생성 도구는 여러가지가 있다. 대표적인 오픈 소스 도구로는

가장 간단하게 쓸 수 있는 도구로는 Apache AB 라는 명령어 기반의 도구가 있으며, 복잡한 스크립트를 지원할 수 있는 도구로는 grinder나 apache JMeter 등이 있으며, NHN에서 grinder를 enhancement해서 만든 (GUI가 지원되는) nGrinder라는 도구가 있다.

근래에는 국내에서는 nGrinder라는 도구가 많이 사용되고 있다.

성능 모델이 단순하고, 테스트 시나리오가 간단할 경우에는 Apache ab 등으로도 가능하지만, 스크립트가 복잡해지는 경우에는 nGrinder와 같은 도구가 유리 하다.

또한 부하 생성에 사용되는 스크립트는 복잡도가 생각보다 높고, 향후 regression(회귀) 테스트에도 재 사용되기 때문에, 반드시 형상 관리 시스템을 통해서 (VCS) 관리 하는 것을 권장한다.

※ 자세한 부하 테스트에 대한 방법은 “4장 테스트의 시스템 테스트 “ 부분을 참고하기 바란다.

※ 클라우드 컴퓨팅과 부하 테스트 툴 라이센스 모델에 대해서

예전에는 부하 테스트가 사내에서 사내에 있는 시스템을 대상으로 했었기 때문에 큰 문제가 없었다. 그러나 근래 들어서 클라우드 컴퓨팅을 사용하는 사례가 늘어남에 따라, 서비스 시스템이 회사 밖에 즉, 클라우드에 있는 경우가 많아 졌다.

상용 부하 테스트툴의 경우에는 부하 발생기의 위치와 툴 사용자에 대해서 제약을 두는 경우가 있는데, 툴을 구매했다 하더라도, 부하 테스터의 controller (부하 발생기 제외)는 반드시 사내에 있어야 하며, 사용자 역시 그 회사의 내부 직원으로만 한정하는 경우가 있다.

예를 들어, 내가 부하 테스트 도구를 서울에 있는 회사에서 구매하여, 이 툴을 Amazon 클라우드 미국에 설치하고 부하 테스트를 미국 지사 직원을 통해서 진행하는 것이 불가능 하다.

이 경우 부하 테스트 툴의 Controller는 한국 서울 사무소에 설치하고, 부하 생성기만 Amazon에 설치한후 한국 서울 사무소 직원을 통해서만 사용해야 한다.

간혹 (이럴리는 없어야 하겠지만) 부하 테스트 툴의 판매 회사 영업 사원이 이러한 사실을 제대로 통보하지 않아서, 툴을 잘 쓰다가 갑자기 영업 사원이 변경되거나, 부하 테스트 툴의 이전을 요청 하였을때, 갑자기 벤더로 부터, 추가 라이센스 구매 요청을 받을 수 있으니, 구매 전에 반드시 구매 조건에 사용 시나리오와 Controller 위치, 사용 주체 및 테스트 대상 시스테들에 대해서 명시적으로 기재 하고 구매 계약을 추진 하는 것이 좋다.

테스트 및 모니터링

부하 테스트 준비가 되었으면, 부하 테스트를 진행하고 진행중에 주요 성능 Factor에 대해서 지속적으로 모니터링 및 기록을 하여야 한다. 주로 모니터링해야하는 Factor들은 다음과 같다.

애플리케이션 관점

가장 기본적으로 애플리케이션 즉 시스템의 성능을 측정 해야 한다. 주요 모니터링 Factor는 다음과 같다.

Response Time : Request 별 응답 시간

TPS (Throughput per second) : 초당 요청(Request) 처리량

Factor들이 궁극적으로 성능에 대한 최종 목표 값이 되기 때문에, 가장 중요한 성능 Factor가 되며, 부하 생성 도구를 통해서 손쉽게 측정할 수 있다.

미들웨어 관점

미들웨어는 애플리케이션이 동작하기 위한 기본적인 솔루션이다.. Apache와 같은 웹서버나 Tomcat과 같은 Web Application 서버 , RabbitMQ와 같은 Message Queue, MySQL과 같은 데이타 베이스 등이 이에 해당한다.

각 성능 시나리오별로, 거쳐 가는 모든 미들웨어들을 모니터링해야 하는데, 이를 위해서는 각 솔루션에 대한 개별적인 깊은 이해가 필요하다.

웹서버의 경우 거의 성능 문제가 되는 부분은 없다. 성능 문제가 발생하는 부분은 대부분 Network outbound io (bandwidth)쪽이 되는 경우가 많다. 웹서버가 설치된 하드웨어의 network out bound bandwidth를 모니터링 하는 것이 유용하다.

대부분의 성능 문제는 실제 애플리케이션 로직이 수행되는 Tomcat과 같은 application server와 데이타 베이스단에서 많이 발생하는데, application server의 경우에는 Thread의 수와 Queue의 길이가 1차 모니터링 대상이 된다.

서버가 용량을 초과 하게 되면, Idle Thread수가 떨어지게 되고, Idle Thread가 0이 되면 request message가 앞단의 queue에 저장되게 된다. 그래서 이 두 개를 모니터링 하면 시스템이 병목 상태인지 아닌지를 판단할 수 있다. 이 값들은 JMX (Java Management Extension) API를 이용하여 모니터링 하면 된다.

의 경우에는 slow query를 모니터링하면 특히 느리게 수행되는 쿼리들을 잡아서 튜닝할 수 있다. MySQL 5.6의 경우 slow query는 http://dev.mysql.com/doc/refman/5.6/en/slow-query-log.html

를 사용하면 쉽게 잡아낼 수 있다.

Slow query를 찾았으면, EXPLAIN 명령어를 이용하여 query의 수행 내용을 분석한후 Index등의 튜닝을 수행할 수 있다.

인프라 관점 : CPU, Memory, Network IO, Disk IO

다음으로 하드웨어 인프라에 대한 부분을 지속적으로 모니터링해줘야 하는데, 이는 하드웨어가 해당 성능을 내기 위해서 용량이 충분한지 그리고 하드웨어 구간에서 병목이 생기지는 않는지, 생긴다면 어느 구간에서 생기는지를 모니터링하여, 해당 병목 구간에 대한 문제 해결을 하기 위함이다.

인프라에 대한 모니터링은 Ganglia나 Cacti와 같은 전문화된 인프라 모니터링 도구를 사용하거나 top이나 glance, sar와 같은 기본적인 Unix/Linux 커맨드를 사용해서도 모니터링이 가능하다. (부하 테스트주에 top 등을 띄워놓고 모니터링을 하는 것이 좋다. Load Runner와 같은 상용 도구의 경우에는 부하 테스트 툴 자체에서 테스트 대상 시스템에 대한 하드웨어 사용률을 함께 모니터링할 수 있게 제공해준다.)

CPU : 일반적으로 CPU는 대부분 잘 모니터링 한다. 목표 성능을 달성할 시에는 보통 70~80% 정도의 CPU 를 사용하는 것이 좋고, 20~30%의 여유는 항상 가지고 가는 것이 좋다 이유는, 70~80% 정도의 CPU가 사용된 후에, 하드웨어를 물리적으로 늘리는 시간에 대한 여유 시간을 가지기 위함이다. 하드웨어는 특성상 주문을한다고 해도, 바로 그 시간에 증설을 할 수 있는 것이 아니고, CPU 가 100%가 되는 순간에는 이미 애플리케이션이 CPU 부족으로 제대로 작동을 하지 못하는 경우가 많기 때문에, 항상 여유를 남겨 놓고 성능 목표를 정의 하는 것이 좋다. 그래서 성능 목표를 잡을 때는 “CPU 70%시, 500 TPS, 응답시간 1.5초 내외” 식으로 하드웨어에 대한 사용률을 포함하는 것을 권장한다.

Memory : 다음으로는 Memory 부분이다. Peak Time시에 Memory가 얼마나 사용되느냐가 중요한데, Java Application의 경우 특성상, 전체 JVM 프로세스가 사용할 메모리량을 미리 정해놓기 때문에, 부하 테스트 중에도 메모리 사용량 자체는 크게 변화하지 않는다. 다만 자주 놓치는 점이 swapping status 인데, Unix/Linux는 시스템의 특성상 물리 메모리 이상의 메모리를 제공하기 위해서 virtual memory 라는 개념을 사용하고 swapping space라는 디스크 공간에 자주 사용하지 않는 메모리의 내용을 dump해서 저장한 후 다시 사용할때 memory에 loading 하는 방식을 사용한다. 그런데 이 메모리의 내용을 디스크에 저장 및 로드 하는 과정 (swapping이라고 함)이 실제 disk io를 발생 시키기 때문에, 실제 메모리 access 성능이 매우 급격하게 떨어진다. 그래서 시스템에서 system에서 swapping이 발생하면 시스템의 성능이 장애 수준으로 매우 급격하게 떨어진다.

부하 테스트 중이나, 운영 중에 swapping이 발생하게 되면 전체 메모리 사용량을 줄이도록 튜닝을 하거나, 반대로 물리 메모리를 늘리는 증설 과정이 필요하다.

Disk IO : Disk IO는 파일 시스템에 파일을 저장하는 시나리오나, Log를 저장하는 모듈 그리고 데이타 베이스와 같이 뒷단에 파일 시스템을 필요로 하는 모듈에서 많이 발생을 한다. Ganglia와 같은 도구를 사용하면, IOPS (Input Out per Second - 초당 read/write등의 IO 발생 횟수)를 통해서 모니터링할 수 있고, 또는 iostat나 sar와 같은 명령어를 이용하면 iowait 를 통해서 디스크 IO의 pending이 발생할 경우 디스크 병목이 있는지 없는지를 확인할 수 있다.

Figure 1. iostat

Process당 Disk IO는 iotop과 같은 툴을 사용하면 조금 더 상세한 정보를 얻을 수 있다.

Figure 2. iotop

Disk IO에 대한 Bottleneck은 여러가지 해결 방법이 있다. 먼저 하드웨어 인프라 ㅈ체에서 접근 하는 방식은, 디스크 자체를 SSD로 변경하거나, 버퍼가 크거나 RPM이 높은 디스크로 변경하는 방식, 인터페이스를 SATA에서 SAS나 SSD와 같은 높은 IO를 제공하는 디스크 인터페이스로 변경, Disk Controller는 iSCSI에서 FC/HBA와 같은 광케이블 기반의 고속 컨트롤러를 사용하는 방식 또는 RAID 구성을 Stripping 방식으로 변경해서 IO를 여러 디스크로 분산 시키는 방식 등이 있으며, 애플리케이션 차원에서는 데이타 베이스 앞에 memcache와 같은 캐슁을 사용하거나, 로깅의 경우에는 중간에 message queue를 써서 로그를 다른 서버에서 쓰도록 하여 IO를 분산하거나 또는 Back write와 같은 방식으로 로그 메세지가 발생할때 마다 disk에 writing 하는 것이 아니라 20개 30개씩 한꺼번에 디스크로 flushing 하는 방식등을 이용할 수 있다.

또는 조금더 높은 아키텍쳐 레벨로는 디스크 IO가 많이 발생하는 로직의 경우 동기 처리에서 message queue를 사용하는 비동기 방식으로 시스템의 설계를 변경하는 방법을 고민할 수 있다. 예를 들어 사진을 올려서 변환하는 서비스의 경우 파일을 업로드 하는 시나리오와 변경하는 모듈을 물리적으로 분리하여, 파일 업로드가 끝나면, 사용자에게 동기 방식으로 바로 응답을 줘서 응답 시간을 빠르게 하고, 업로드된 파일은 뒷단에서 비동기 프로세스를 통해서 변환 과정을 다 끝낸 후에 사용자에게 변환이 끝나면 알려주는 방법을 사용할 수 있다.

Network IO: Network IO는 특히 고용량의 파일이나 이미지 전송에서 병목이 많이 발생하며, Reverse Proxy, NAT (Network address Translator), Router, Load Balancer 등에서 많이 발생한다. 여러가지 지점과 장비에 대해서 모니터링 해야 하기 때문에, 일반적인 unix/linux command 를 사용하는 방법보다는 Cacti나 Ganglia와 같은 RRD 툴이나 OpenNMS와 같은 NMS (Network Management System)을 사용하는게 좋다.

그래프를 보면서 추이를 지켜 보는 것이 중요한데, 부하를 넣으면 일정 수준이 되어도, 시스템들의 CPU나 메모리, Disk등의 기타 자원들은 넉넉한데, Network Input/Output이 일정 수준 이상으로 올라가지 않는 경우가 있다. 이 경우는 네트워크 구간의 병목일 가능성이 높다.

특히 소프트웨어 기반의 Load Balancer나, 소프트웨어 기반의 NAT 장비에서 많이 발생하는데, 이미지와 같은 정적 컨텐츠는 가급적이면 CDN이나 분리된 Web Server를 이용해서 서비스 하도록 하는 것이 좋다. 클라우드의 경우에는 특히나 소프트웨어 기반의 NAT나 Load Balancer를 사용해서 문제가 되는 경우가 많은데, NAT의 경우에는 여러개의 NAT를 사용해서 로드를 분산하도록 하고, Load Balancer의 경우에도 충분히 큰 용량을 사용하거나 2개 이상의 Load Balancer를 배포한 후 DNS Round Robine등을 사용하는 방법을 고려 하는 것이 좋다.

개선 (Tuning)

병목을 찾았으면, 해당 병목 문제를 해결 및 반영해야 한다.

튜닝은 병목 구간이 발생하는 부분에 대한 전문적인 지식을 필요로 하지만, 기본적인 접근 방법은 거의 같다고 보면 된다.

문제의 정의 : 성능 개선의 가장 기본은 문제 자체를 제대로 정의 하는 것이다. “그냥 느려요”가 아니라, “성능 목표가 350TPS에 1초내의 응답 시간인데, 현재 60 TPS에 5초의 응답 시간에 WAS의 CPU 점유율이 100% 입니다.”와 같이 명확해야 하며, 문제점이 재현 가능해야 한다.

특히 재현 가능성은 매우 중요한 점인데, 테스트 환경이 잘못되었거나, 외부적 요인 예를 들어 부하 테스트 당시 네트워크 회선이 다른 테스트로 인하여 대역폭이 충분히 나오지 않았거나 했을 경우 결과가 그 때마다 다르게 나올 수 있다.

즉 문제 자체를 명확하게 정의할 필요가 있다.

Break down : 다음으로는 문제가 발생하는 부분이 어떤 부분인지를 판단해야 한다. 시스템은 앞단의 로드밸런서나 미들웨어, 데이타 베이스와 같은 여러 구간에서 발생을 한다. 그렇기 때문에, 성능 저하의 원인이 정확하게 어느 부분인지를 인지하려면, 먼저 성능 시나리오가 어떤 어떤 컴포넌트를 거치는지를 명확하게 할 필요가 있다. 이 과정을 break down이라고 한다. 이 과정을 통해서 전체 성능 구간중, 어느 구간이 문제를 발생 하는지를 정의한다.
Isolate : 다음으로는 다른 요인들을 막기 위해서, 문제가 되는 구간을 다른 요인으로 부터 분리 (고립) 시킨다. 물론 완벽한 분리는 어렵다. 애플리케이션이 동작하기 위해서는 데이타 베이스가 필수적으로 필요하다. 이 경우에는 데이타 베이스를 분리할 수 는 없다. 그러나 예를 들어 시나리오 자체가 로그인 시나리오이고 Single Sign On을 통해서 로그인 하는 시나리오라서 SSO 시스템과 연동이 되어 있다면, SSO 연동을 빼고 다른 mock up을 넣어서 SSO와의 연결성을 끊고 테스트를 하는 것이 좋다.

이렇게 문제에 대한 다른 요인과의 연관성을 최대한 제거 하는 작업이 isolation이다.

Narrow down : 문제를 isolation을 시켰으면, 근본적인 문제를 찾기 위해서 문제의 원인을 파 내려간다. Profiling을 하거나, 코드에 디버그 정보를 걸어서 문제의 원인을 분석하는 과정을 narrow down이라고 한다. 특히나 이 narrow down 과정은 분석을 위한 여러가지 기법이나 도구들을 사용해야 하고, 현상에 대한 이해를 하기 위해서는 해당 솔루션이나 기술 분야에 대한 전문성은 필수적으로 필요하다.
Bottleneck 발견 : Narrow down을 해서 문제의 원인을 계속 파해쳐 나가면 병목의 원인이 되는 근본적인 문제가 판별이 된다.
해결 : 일단 병목의 원인을 찾으면 해결을 해야 하는데, 찾았다고 모두 해결이 되는건 아니다. 데이타 베이스 index를 걸지 않아서 index를 걸어주면 되는 간단한 문제도 있을 수 있지만, 근본적인 솔루션 특성이나 설계상의 오류로 인해서 문제가 발생하는 경우도 있다. 하드웨어를 늘려서 해결하는 방법도 있지만, 비지니스 시나리오 자체를 바꾸거나 UX 관점에서 해결 하는 방법도 고려할 수 있다. 예를 들어 로그인 화면이 넘어가는데 시간이 많이 걸린다고 했을때, 이 문제가 근본적으로 솔루션의 특성이라면 애플리케이션이나 솔루션 수정으로는 해결이 불가능하다. 이런 경우에는 모래 시계 아이콘이나 progress bar등을 넣어서 UX 관점에서 사용자로 하여금 체감되는 응답 시간에 대해서 느리지 않고 몬가 진행이 되고 있다고 보여주는 형태로 접근을 해서 문제를 해결할 수 도 있다.

간단한 예를 하나 들어보자. Drupal 이라는 웹 CMS 기반의 웹사이트가 있다고 하자. 성능 테스트를 수행하였는데, CPU 점유율이 지나치게 높게 나오고 응답 시간이 느리게 나왔다. 이것이 문제의 정의이다.

성능의 문제점을 찾아내기 위해서, 성능 테스트 시나리오를 검토하였다 성능 테스트 시나리오는 1) 로그인 페이지 로딩, 2) id,password를 post로 전송 3) 초기 화면으로 redirect됨 4) 로그 아웃 4가지 과정을 거치고 있었다. 1,2,3,4 과정의 응답시간을 각각 체크해서 보니, 2) 과정에서 성능의 대부분을 차지 하고 있음을 찾아 내었다. 전체적으로 성능이 안나오는 것을 인지한 후, 문제를 여러 구간으로 나누어서 접근 하는 것이 Break down이다.

2) 과정을 분석하기 위해서 성능 테스트를 다시 진행한다. 다른 시나리오가 영향을 주는 것을 방지하기 위해서, 1,3,4 시나리오를 제외 하고, 2 시나리오만 가지고 성능 테스트를 진행한다. 이렇게 문제점을 다른 변수로 부터 분리하여 고립 시키는 것을 isolation이라고 한다.

다음으로 Xhprof 라는 프로파일링 툴을 사용하여 로직중 어느 부분이 가장 성능 문제가 발생하는 지를 profiling 하였다. 대 부분의 성능 저하가 SQL 문장 수행에서 발생함을 찾아내었다. 이렇게 하나의 포인트를 깊게 들어 가면서 범위를 좁혀가는 것을 narrow down이라고 한다.

SQL 수행이 문제가 있음을 정의하고(문제의 정의), 어떤 SQL 문장이 수행되는지(Break down) 각각을 정의한후, 가장 수행 시간이 긴 SQL 문장을 찾아서 원인을 분석하였더니(narrow down) index 가 걸려 있지 않음을 찾아내었다.

해당 테이블에 index를 적용하고, 성능 테스트를 다시 수행하여 성능 목표치를 달성하였음을 해결하였다.

가상의 시나리오지만 성능 튜닝의 접근 방법은 대부분 유사 하다. 관건은 문제를 어떻게 잘 정의하고, 문제가 어떤 요소로 구성이 되어 있으며 각각이 어떤 구조로 동작을 하고 있는지 잘 파고 들어갈 수 있는 문제에 대한 접근 능력과, 점점 솔루션의 아랫부분(low level)로 들어갈 수 있는 전문성이 필요하다.

반복

튜닝이 끝났으면 다시 “테스트 및 모니터링” 항목으로 돌아가서 성능 목표에 도달할때까지 위의 작업을 계속해서 반복해서 수행한다.

Performance Engineering을 위해 필요한 것들

그러면 성능 엔지니어링을 하기 위해서 필요한 것들은 무엇이 있을까? 먼저 도구 적인 측면부터 살펴보자.

부하 테스트기 : 가장 기초적으로 필요한 것은 부하 발생 도구 이다. HP Load Runner와 같은 상용 도구에서 부터, nGrinder와 같은 오픈 소스 기반의 대규모 부하 발생 도구를 사용할 수 도 있고, SOAP UI같은 micro benchmark 테스트 툴을 이용해서 소규모 (50 사용자 정도)를 발생 시키거나 필요에 따라서는 간단하게 Python등의 스크립트 언어로 부하를 발생시킬 수 도 있다.
모니터링 도구 : 다음으로는 모니터링 도구이다. 어느 구간이 문제가 있는지 현상이 어떤지를 파악하려면 여러 형태의 모니터링 도구들이 필요하다.
프로파일링 도구 : 그리고, 문제되는 부분을 발견했을때, 그 문제에 대한 근본적인 원인을 찾기 위해서 프로파일링을 할 수 있는 도구들이 필요하다.

우리가 일반적으로 이야기 하는 프로파일링 도구들은 IDE와 같은 개발툴에서 debug 용도로 사용은 가능하지만, 대부분 대규모 부하 환경에서는 사용이 불가능한 경우가 많다.그래서 그런 경우에는 해당 시스템의 상태에 대한 스냅샷을 추출 할 수 있는 dump 도구들을 많이 사용하는데, unix process의 경우에는 ptrace를 통해서 system call을 모니터링 하거나, pmap을 이용하여 메모리 snapshot등을 추출할 수 도 있고, 자바의 경우에는 thread dump를 추출해서 병목 당시 애플리케이션이 무슨 동작을 하고 있었는지를 찾아낼 수 있다.

다음이 이 글에서 정말 언급하고 싶은 내용인데, 앞에서 도구를 언급했다면 다음은 엔지니어로써의 역량이나 지식적인 부분이다.

역량 : 당연한 것이겠지만, 기술적인 역량은 필수적이다. netstat를 통해서 TCP 소켓이 FIN_WAIT가 발생하였는데, 이 FIN_WAIT가 의미하는 것이 무엇인지 모르면 아무리 모니터링을 잘해도 소용이 없다. 기본적인 엔지니어로써의 컴퓨터와 프로그래밍, OS등에 대한 넓은 이해는 필수적이다.
하드웨어 인프라, 미들웨어 , 애플리케이션에 대한 지식 : 다음은 사용하는 특정 솔루션에 대한 전문적인 지식이다. 톰캣의 내부 구조가 어떻게 되어 있으며, JVM의 동작원리가 어떻게 되는지와 같은 특정 지식인데, 사실 이러한 지식은 오랜 경험이나 습득할 시간이 없으면 가지기가 어렵다. 이런 경우는 해당 솔루션 제품 엔지니어를 통해서 지원을 받는 방법도 고려해볼만 하다.
그리고 경험 : 성능 엔지니어링에 대한 경험인데, 대략 시스템의 상태마 봐도 어느 부분이 의심이 되는지 경험이 많은 엔지니어는 쉽게 접근을 한다. 성능 문제는 넓어보이기는 하지만, 결국 발생되는 패턴이 거의 일정하다. 그리고 특정 솔루션에 대한 지식이 없다하더라도, 문제에 대한 접근 하는 방법이나 모니터링 방법, 툴등은 사용법이 다르다 하더라도 그 의미하는 방법은 거의 비슷하기 때문에, 다른 기술로 구현되어 있는 시스템이라고 하더라도, 경험이 있는 엔지니어는 문제를 접근해서 풀어나가는 방식이 매우 익숙하다.
마지막으로 인내심 : 그리고 마지막으로 강조하고 싶은 점이 인내심인데, 사실 성능 엔지니어링은 상당히 지루한 작업이다. 반복적인 테스트와 모니터링 및 분석을 거쳐야 하고, 해당 솔루션에 대한 전문적인 지식이 없을 경우에는 보통 제품 문제라고 치부하고 하드웨어 업그레이드로 가는 경우가 많은데, 어짜피 솔루션이라고 해도 소스코드로 만들어진 프로그램이다. 디컴파일을 하건, 덤프를 추출하건, 꾸준히 보고, 오픈 소스의 경우 소스코드를 참고해서 로직을 따라가다 보변, 풀어낼 수 있는 문제가 대부분이다. 결국은 시간과 인내심의 싸움인데, 꾸준하게 인내심을 가지고 문제를 접근하고 풀어나가는 것을 반복하면 문제는 풀린다.

[1] 출처 : http://guichaz.free.fr/iotop/

출처 : http://bcho.tistory.com/787

시스템 용량산정 도구 (x86 서버외 용량산정)

JAESOO — Mon, 24 Aug 2015 11:38:28 +0000

시스템 용량산정 도구 입니다.

X86서버 외 용량산정 하실 때 유용한 자료 입니다.

- 정보시스템 용량산정 도구(Sizing).xls

- Dell_PowerEdge_tpmC_추정값.xlsx

- HP_ProLiant_tpmc_공인_추정성능치_v12_E5-24xx_update.xls

- HP_ProLiant_tpmc_공인_추정성능치_v15_IVY_bridge_update.xlsx

출처 : http://redsunset.synology.me/xe-dwcts/index.php?mid=customer_support_technical&category=1246&search_keyword=%EC%9A%A9%EB%9F%89&search_target=title&document_srl=3636

throttle-me를 이용한 계정 트래픽 나타내기

JaeSoo — Fri, 12 Apr 2013 23:51:32 +0000

http://홈주소/throttle-me

를 했을 때 트래픽을 확인 할 수 있는 호스팅에 한해

편법으로 홈페이지에 거의 실시간으로 자신의 홈 트래픽을 나타낼 수 있습니다.

사실... 아무것도 아닙니다.

그냥 나타나는 html 소스에서 트래픽 부분만 가져오는 방법입니다.

이것이 가능한 것은 throttle-me 에서의 html 소스가 (라인수가) 항상 일정하게 나온다는 것을 이용한 것입니다.

먼저, http://홈주소/throttle-me 를 해서 html 소스보기를 합니다.
여기서 트래픽이 나타나는 부분의 라인수를 찾아냅니다.

저 같은 경우는 44번 라인에

<td class="green">32663</td>

이렇게 나옵니다.

그럼 끝났습니다.

1. http://홈주소/throttle-me 의 html 소스를 읽고,
2. 44번 라인을 읽어서
3. html 태그를 모조리 없애고
4. 옵션으로 단위를 붙여서 출력한다!!!!

이하 소스입니다.

================================================================================

<?

ini_set("allow_url_fopen","1"); // 서버 설정에 따라 file() 함수의 사용이 가능하도록... [라인추가]

$throttle = "http://홈주소/throttle-me/";

$file = file($throttle); // 소스를 읽고,

$traffic = sprintf("%0.2fMB",strip_tags($file[43]) / 1024); // 44번 라인을 읽어서 태그를 없애고 MB단위로...배열은 0부터 44-1 = 43

// 현재트래픽/일일허용트래픽 의 형식으로 나타내자.... ex) 34.85MB/1GB
echo("• 트래픽 : <a href=/throttle-me/ target=_blank onfocus=blur();>$traffic/1GB</a>");

?>

출처 : http://www.xpressengine.com/index.php?mid=phpClass&page=14&document_srl=19375676

윈도우 디스크 용량 확인

JaeSoo — Fri, 12 Apr 2013 23:39:03 +0000

개요

윈도우 디스크 용량 확인
윈도우 볼륨 용량 확인

명령어를 사용하여 디스크(물리디스크), 볼륨(논리디스크)의 크기를 알아낼 수 있다.

방법 1: diskmgmt.msc

diskmgmt.msc 즉 "디스크 관리"를 사용하면 UI를 통해 디스크와 볼륨 크기를 한눈에 볼 수 있다

[시작] --- diskmgmt.msc ↵ Enter

방법 2: Get-WmiObject (PowerShell)

디스크 (GiB)

C:Usersjmnote>PowerShell "Get-WmiObject Win32_DiskDrive | FT DeviceID,@{E={"{0:N1} GiB" -F($_.Size/1000000000)}} -H -A" | FindStr G | Sort \.PHYSICALDRIVE0 1,000.2 GiB \.PHYSICALDRIVE1 128.0 GiB

디스크 (GB)

C:Usersjmnote>PowerShell "Get-WmiObject Win32_DiskDrive | FT DeviceID,@{E={"{0:N1} GB" -F($_.Size/1GB)}} -H -A" | FindStr G | Sort \.PHYSICALDRIVE0 931.5 GB \.PHYSICALDRIVE1 119.2 GB

볼륨

C:Usersjmnote>PowerShell "Get-WmiObject Win32_LogicalDisk -F DriveType=3 | FT DeviceID,@{E={"{0:N1} GB" -F($_.Size/1GB)}} -H -A" | FindStr G C: 29.3 GB D: 89.9 GB E: 931.5 GB

방법 3: diskpart

디스크

C:Usersjmnote>echo list disk | diskpart | findstr GB 디스크 0 온라인 931 GB 0 B * 디스크 1 온라인 119 GB 1024 KB

볼륨

C:Usersjmnote>echo list volume | diskpart | findstr GB 볼륨 0 E DATA NTFS 기본 931 GB 정상 시스템 볼륨 1 C System NTFS 파티션 29 GB 정상 부팅 볼륨 2 D Virtual NTFS 파티션 89 GB 정상

방법 4: wmic

디스크

C:Usersjmnote>wmic diskdrive get deviceid,model,size DeviceID Model Size \.PHYSICALDRIVE0 Hitachi HDS721010CLA332 ATA Device 1000202273280 \.PHYSICALDRIVE1 SAMSUNG SSD 830 Series ATA Device 128034708480

볼륨

C:Usersjmnote>wmic logicaldisk get name,size Name Size C: 31457275904 D: 96574894080 E: 1000202240000

C:Usersjmnote>wmic volume get name,capacity Capacity Name 31457275904 C: 96574894080 D: 1000202240000 E:

같이 보기

윈도우 디스크 사용량 확인

출처 : http://jmnote.com/wiki/%EC%9C%88%EB%8F%84%EC%9A%B0_%EB%94%94%EC%8A%A4%ED%81%AC_%EC%9A%A9%EB%9F%89_%ED%99%95%EC%9D%B8

PHP 디렉토리 용량 체크 (윈도우 리눅스 공용)

JaeSoo — Fri, 12 Apr 2013 23:36:03 +0000

<?php

function Yget_dir_size($dir, $debug=false){

if (!is_dir($dir)) return false;

if (!preg_match("`/$`", $dir)) $dir .= '/';

$get_size = 0;

$d = dir($dir);
while (false !== ($entry = $d->read())) {

if (substr($entry, 0, 1) == '.') continue;

if (is_file($dir . $entry)) {

$get_size += filesize($dir . $entry);
if ($debug == true) echo $dir . $entry . ' ' . filesize($dir . $entry) . "<br>n";
}
else if (is_dir($dir . $entry)){

$get_size += Yget_dir_size($dir . $entry, $debug);
}
else{

continue;
}
}
$d->close();

return $get_size;
}

$dir = '용량체크하고픈 디렉토리경로(상대경로 or 절대경로)';
echo Yget_dir_size($dir, true);//개별파일출력을 원할 경우
echo Yget_dir_size($dir);//개별파일출력을 원하지 않을경우

?>

몇가지 첨언을 하자면
Yget_dir_size 이함수는 재귀호출 함수입니다.
해당디렉토리에 다른 디렉토리를 발견하면 자기 자신을 다시 호출합니다.

이함수는 해당 디렉토리를 웹서버가 읽을 수 있을 경우에만 제대로 작동합니다.

--------------------------------------------------------------------------------------------------

지나가다가 슬쩍...

function get_dirsizea($file_dir) {
$size = 0;
$d = dir($file_dir);
while ($entry = $d->read()) {
if ($entry != "." && $entry != "..") $size += filesize("$file_dir/$entry");
}
$d->close();
return $size;
}

출처 : http://www.welog.net/gbbs/bbs/board.php?bo_table=php&wr_id=18

PHP 웹에서 서버 동시 접속자 수 확인 하기 (리눅스용, 윈도우용)

JaeSoo — Fri, 12 Apr 2013 23:32:58 +0000

리눅스용 :

동시 접속자 확인 하기 위해선 서버에서 root 권환으로
netstat -n | grep 80 | grep ESTABLISHED | wc -l
이라고 실행하면 동시 80 포트로 접속한 사람 수 가 나타납니다.

netstat -n | grep 80
라고만 실행하면 Fin_Wait, Time_Wait 인 접속자 수 모두를 표시 하게 됩니다.

웹상에서 리눅스 명령을 실행할땐 exec 함수를 사용합니다.

<?
$cmd = "netstat -n | grep 80 | grep EST | wc -l";
exec($cmd, $cmd_result);
$count = sizeof($cmd_result);
echo "현재 접속자 수 : ".$count.";
echo "<br>";
$cmd = "netstat -n | grep 80";
exec($cmd, $cmd_result);
$count = sizeof($cmd_result);
echo "Fin_Wait, Time_Wait 포함 현재 접속자 수 : ".$count;
?>

출력결과 :
현재 접속자 수 : 10
Fin_Wait, Time_Wait 포함 현재 접속자 수 : 132

출처 : http://t.saybox.co.kr/423

윈도우용 :

<?
$cmd = 'netstat -n | findstr /i :80 | findstr /i EST';
exec($cmd, $cmd_result);
$count = sizeof($cmd_result);
echo '현재 접속자 수 : '.$count;
echo '<br>';
$cmd = 'netstat -n | findstr /i :80';
exec($cmd, $cmd_result);
$count = sizeof($cmd_result);
echo "Fin_Wait, Time_Wait 포함 현재 접속자 수 : ".$count;
?>

출처 : 직접수정

통합로그관리시스템 구축사례

JaeSoo — Tue, 05 Feb 2013 20:17:58 +0000

EIM 사업실/대리 신호근

시스템 및 보안인프라의 효과적인 운영관리 정보수집과 장애요인에 대한 고속 추출 대책 마련으로 보다 안정적인 전산 서비스를 제공하기 위해 본 시스템이 구축되었습니다.


		방대한 로그 관리 및 활용 방안 요구
		- 다수의 네트워크/보안/주요 서버에서 발생하는 방대한 로그 데이터 활용
		- 수집된 대용량 로그를 신속히 조회하고 검증할 수 있는 로그아카이빙

		로그관리 중요성 확대
		- 로그관리의 중요성 증대 및 로그관리에 대한 법적 준수사항 이행 필요
		- 정보시스템 구축·운영기술 가이드라인, 정보통신기반보호법 등 관련지침 준수
		※ 주요 정보제공 시스템은 주1회 이상 로그분석

		포렌식기반 로그감사
		- 관리측면: 로그분석을 통한 사전 장애예방 및 사후 장애원인 파악
		- 보안측면: DoS공격에 대비한 백도어 분석 등 사이버 테러 대응 분석 활용
		- 경제성측면: 전산 유지관리 인력의 로그 관련 업무시간/비용 증가 최소화


		21세기 정보화시대에 걸맞는 전산 인프라 관리 수준 유지: 기하급수적으로 늘어가는 로그의 활용 요구에 부응하기 위해, 보다 진보된 수준의 로그분석 요구

		로그 분석 솔루션 확보와 더불어 운용 능력 향상을 위한 환경 조성: 자체 교육 및 전문가의 조언에 의한 유연성 있는 로그관리 방안 강구


		로그분석 전용 툴은 대규모 시스템 관리를 위한 기본적 인프라 솔루션임.

		내부망에서 외부로의 보안사고 발생 시 주요 기관의 신속한 대응 요구에 회신불가
		※ 평상시 광범위한 분석대상 주요 로그에 대해 폭넓은 로그 추출이 필요


		원천적으로 로그를 통합적으로 관리하지 않고 있으며 지속적으로 발생하는 로그 패턴을 분석 추출하는 자체 기준이 없음

		유닉스 시스템의 불편한 로그분석 명령과 다수 벤더의 이기종 시스템 로그 활용에 어려움을 겪고 있음.

		다양한 포맷의 로그형식 상호 연관관계 분석 수행에 어려움을 겪고 있음.


		대용량 통합 로그의 효과적 활용과 고속 추적 감사 대책 미흡: 각종 시스템에서 발생하는 로그의 분석에 상당한 시간 소요되며, 이기종 장비에서 발생하는 연관성 있는 멀티로그 분석의 한계.

		별도의 축약과정 없이 원시로그를 분석/관리할 수 있는 대용량 원시로그 통합 활용 솔루션 구축

		전문 교육을 통한 내부 운용자 로그관리 수준 향상: 자체 로그관리지침 적용


		전산시스템 장애 사전예방: 악성 장애 로그 추출 후 자체 노하우로 재활용

		전산시스템 로그를 통한 Capacity 정보수집: 증설 계획 분석

		압축검색엔진을 통한 디스크 효율성 증대

		전산시스템 부하에 의한 서비스 중단 방지 및 신속한 경보체계 확보
		- 신속한 로그검증으로 장애정보의 조기탐지 및 대응이 가능
		- 다양한 형식의 로그파일을 통합 검증할 수 있는 방안 확보


		로그분석 시스템을 통한 관리정책 설정 예측 및 시스템 상황 동시 모니터링

		여러 장비에서 생성되는 로그를 개별 관리해야 하는 문제점 해소

		파일 기반 대용량 원시로그 수집: 대량으로 생성되는 로그파일의 효율적인 관리


		정책화: 정책기반의 체계적 통합로그관리 구현

		시스템화: 다양한 시스템 로그에 대한 효율적 운영 관리 가능

		전문화: 교육 수준 향상 및 지속적 운용을 통한 노하우 축적

		효율화: 압축 및 고속추출 기법을 활용한 업무 효율화

출처 : http://www.netcruz.co.kr/newsletter/vol8/case_study.htm

SAS(Serial Attached SCSI)에 대하여 알기

JaeSoo — Fri, 09 Oct 2009 15:29:08 +0000

참고; http://www.adaptec.com/pdfs/SASWhitepaper_lo.pdf

참고: 파코즈에서 퍼왔습니다.

소개

이전까지 서버 저장장치의 규격화된 인터페이스(엔터프라이즈 환경은 SCSI, 데크스탑 환경은 저렴한 ATA)는 데이터 전송이 병렬전송방식이었습니다. 하지만 병렬전송방식의 신호는 어긋남, 혼선, 신호 터미네이션의 한정, 케이블과 커넥터 제한, 및 디베이스의 주소할당능력의 제약으로 시스템과 애플리케이션의 진보를 가로막고 있었습니다.

SAS와 SATA

직렬 전송 방식의 SAS (Serial Attached SCSI) 와 SATA (Serial ATA)는 더욱 빠른 속도를 가져다주었으며, 신뢰성과 확장성에 대한 해결책을 제시하였습니다. SATA가 구성의 단순성과 최상의 가격/효능을 요구하는 스토리지 환경에 탁월한 선택이며 데스크탑을 위해 고안 됐다면 SAS는 서버와 엔터프라이즈 저장장치가 요구하는 고성능과 범용성, 및 확장성을 제공하였습니다. SAS는 고사용율, 온라인 쇼핑몰과 은행업무와 같은 즉각적인 데이터 입출력을 요구하는 곳에 매우 적합합니다.

SAS만이 다음과 같은 증명된 SCSI의 신뢰성과 기능성의 결합을 통해 강력한 직렬전송방식을 통해 다음과 같은 특성과 효능을 가져옵니다.

성능 - 1.5Gb/s에서 3Gb/s까지 대역폭 향상, 광범위한 포트를 통한 대역폭 집중, 전이중방식, 포트 집중화, 진보된 SCSI 설정의 rich command

범용성 - 물리 디베이스의 광범위한 주소체계로, 작은 커넥터와 긴 길이의 케이블로 인한 외장형 스토리지 시스템과의 연결성 제공

신뢰성과 이용률 - point to point 연결, 다중 이니시에이터를 통한 동시 접근, Dual- Active 포트 제공

유연성 - 물리적이며 소프트웨어 호환성의 SAS와 SATA 드라이브, 그리고 SCSI소프트웨어와 미들웨어에 대한 하위호환성 제공

성능

제1세대 SAS는 3Gb/s의 전송률을 제공하며 다음 세대에 기술과 애플리케이션 진보에 보조를 맞추기 위해 12Gb/s까지의 대역폭을 향상시킬 것입니다. 또한, SAS는 무장애를 위해 디자인된 다중 point to point 연결방식을 제공합니다.

SAS의 전이중방식과 point to point 연결의 특성으로 인해 다중 이니시에이터와 고성능 SAS target 사이에 활발한 동시연결을 가능하게 해줄 것입니다. 장치들은 링크비율의 사용가능한 대역폭을 2배로 늘리기 위해 2가지 방향으로 즉시 데이터를 전송할 수 있습니다. Narrow 포트는 단일의 시리얼 링크를 지원하는 반면, Wide 포트는 다중링크를 지원하여 8개의 SAS 또는 SATA Target으로 총 사용 대역폭을 24Gb/s로 늘릴수 있습니다.(아래 그림: Wide SAS ports)

다중 물리적 장비를 함께 결합시킴으로써, Wide 포트는 규모가 큰 SAS 토폴로지가 요구하는 중요한 대역폭 지원할 수 있도록 만들어졌습니다.

SCSI와 같이 SAS는 256 queue(대기행렬)를 포함하고 있으며, head queue와 out of order queue를 통해 최고의 데이터 핸들링의 특징을 제공해드릴 것입니다. 이러한 대기행렬들의 특징은 엔터프라이즈 애플리케이션에 중요한 요소로 작용하며, 시스템에 추가주문을 허락하며, 우선적인 Command 인터페이스입니다.

규모가 큰 고성능 토플로지는 SAS를 위한 캐이블링을 하는데 좀 더 실용적으로 만들어졌습니다. SAS는 wide 68-pin 케이블과 분리할 수 있는 8미터까지 확장 가능한 단일 4-wire SAS 전원케이블, 치밀한 디자인으로 인한 인클루저와 Hot-plug연결의 향상을 가져다줄 것입니다.

유연성

SAS의 중요한 장점은 SAS의 백플레인 디자인과 프로토콜 인터페이스로 인해서 같은 시스템 내에서 SAS와 SATA 드라이브의 사용이 가능해졌다는 점이다. 비록 각각의 드라이브형태는 다른 애플리케이션에서 사용되는 것이 일반적이지만, 대부분의 엔터프라이즈 사용자들은 두 드라이브 종류가 있어야 한다는 것이다. 드라이브에 대한 혼용과 match의 능력은 디자이너와 사용자들에게 강력한 장점이다.

SATA 드라이브는 아마도 가격대 성능비가 높은 bulk 스토리지를 위해 첫째로 디자인될 것입니다. 규모의 경제를 달성하기 위해, SATA 드라이브는 스핀들 속도(spindle speed)가 더 낮을 뿐만 아니라 (일반적으로 7,200rpm), 평균 무고장 비율과 가격이 낮은 것이 특징입니다. 결론적으로, SATA드라이브는 트랜잭션비율이 낮고 데이터 이용률이 크게 중요하지 않은 곳에 적합합니다.

반면, SAS 드라이브는 고성능, 고가용성에 사용됩니다. SAS드라이브는 데이터 무결성을 보장하기 위해 회전진동에 대한 보상으로 더 높은 spindle 속도에서 (10,000 to 15,000 rpm) 작동될 것입니다. 또한, 더 높은 신뢰성을 위해 만들어짐. SAS 드라이브는 데이터 부피가 크고 데이터 가용성이 필수적인 환경에서 사용될 것입니다. SATA 커넥터 신호는 SAS신호의 부분집합이기 때문에, SATA 드라이브는 SAS controller와의 완전한 호환이 가능합니다.

SAS controller는 SAS 안에 포함된 SATA Tunneled Protocol(STP)로써 SATA command를 통해 SATA드라이브를 통과합니다. SAS 커넥터는 그 자체가 single uniform backplane으로 다자인 됐기 때문에, 두 종류의 드라이브를 가지고 시스템을 디자인하는 것은 간단합니다. 이러한 호환성으로 인해 비용을 줄이고 스토리지 디자인의 복잡성을 해결할 수 있게 되었습니다. 이로 인해 다자인 선택에 대한 다양성이 증가하였습니다.

또한, 이 호환성 때문에 시스템 builder 들은 보통의 커넥터와 cabling을 사용하여 혼용의 스토리지 시스템을 디자인할 수 있게 되었습니다. 같은 시스템에서 SATA 또는 SAS를 설치하고 업그레이드하는 것은 하나의 드라이브 형태를 다른 것으로 교체하는 단순한 문제입니다. - SAS backplane 커넥터가 SAS와 SATA를 함께 받을 수 있기 때문입니다. 그러나 SATA backplane은 SATA 장치에만 연결하는 반면, backplane은 최고의 시스템 디자인 유연성을 공급하기 위해 SAS 커넥터를 사용해야 합니다.

범용성

병렬 버스의 범용성은 제한적입니다. 왜냐하면, 병렬 버스는 연결경로를 공유하기 때문이며, multiple initiator에 더 많은 버스를 추가한다고 해서 제한된 공유능력이 확장되지 않기 때문입니다. SAS는 대형 외장형 스토리지 시스템의 구성을 단순화시키기 위한 교환기로써 expander 하드웨어를 사용합니다. 이런 large external 스토리지 시스템은 증가한 업무량을 위한 대역폭을 보존하는 동안 최소의 대기시간으로 쉽게 측정될 수 있습니다.

예를 들어, fan out expander는 initiators, SAS 와 SATA 드라이브, Edge expanders 와 다른 Fan Out expanders를 포함하여 좁고 넓은 format으로 128 device까지 연결될 수 있습니다. 이 추가적인 Fan out과 Edge expander는 추가적인 연결 노드(node)를 공급하면서, 번갈아서 다른 호스트와 드라이브에 연결될 수 있습니다. SAS내에서 SCSI운영 프로토콜(SMP)은 토폴로지에서 point to point 연결로 운용되어 집니다. (아래 그림)

신뢰성

Multiple initiator는 multiple 호스트를 통한 디스크 드라이브 액세스를 제공, HBA(Host Bus Adapter) 또는 양쪽 모두 디스크 드라이브 접근을 제공하고 실패할 경우를 대비하여 계속적인 데이터 접근을 보장하기 위해 엔터프라이즈 컴퓨팅을 하는데 오랫동안 사용되어 왔습니다. 그러나, 병렬기술구성에 있어서 multiple initiator의 single point 구성은 블록이 장비에 접근할 수 없는 실패의 원인을 가지고 왔습니다. SAS의 dual porting의 특징은 single point의 실패 없이 고이용 시스템을 구축할 수 있습니다.

SAS를 통해 무장애 시스템을 높이는 다른 방법은 expander를 사용하여 multiple device를 multiple initiator에 연결하는 것이며 이는 많은 장치가 동시에 작동을 할 수 있도록 합니다. Command는 무장애시스템을 높이기 위해 별도의 연결에서 다론 곳에 돌아온 자료와 하나의 링크를 보낼 수 있습니다.
SAS expander의 특징은 Dual-port SAS 드라이브와 SATA 드라이브 2-port이며, 혼합된 SAS ex 최대의 무장애시스템에 대한 예비 여분의 시스템을 디자인하는데 용이하다는 점입니다. 2.5인치 dual-ported SAS 드라이브는 추가로 표준 3.5-inch 드라이브를 이용할 수 있으며, 애플리케이션에서 완전한 무장애 시스템 디자인을 가능하게 해드릴 것입니다. 높은 범위성과 신뢰적인 연결은 엔터프라이즈 레벨의 토폴로지에서 자동적인 장애극복 가용성 또는 절대적으로 필요한 시스템 어플리케이션에 필수적인 부하조절을 위한 multi-node 클러스터링을 지원합니다.

결론

SAS의 장점은 주목하지 않을 수 없습니다. 과거 serial 기술이 도입하기 이전에는, 서버성능과 애플리케이션 필요성이 증가할 경우 시스템 디자이너들은 스토리지의 기가바이트당 가격과 드라이브 신뢰성, 범용성과 유용성을 가진 I/O당 가격 사이의 상충관계를 조심스럽게 조절해야만 했습니다. 추가로, 병렬인터페이스로 인해 사용자들은 각각 드라이브 형태에 대한 별도의 시스템을 구현해야 했으며, 추가적인 서버, 드라이브와 지원에 대한 비용을 부담해야 했습니다.

그러나 현재 SAS와 SATA를 위한 균일한 인터페이스 플랫폼이 나오게 됨에 따라, 사용자들은 이런 모든 요소가 추가 시스템이 없이 공존할 수 있고 스토리지 시스템을 쉽고 빠르게 개발할 수 있게 될 것이며, 엔터프라이즈 스토리지의 수요가 변함에 따라 다른 드라이브 형태가 hot-plugged 되고 엔터프라이즈의 스토리지는 변화가 필요하였습니다.

Serial Attached SCS는 차세대 SCSI의 진보와 I/O interface의 구조의 결정적 진보를 나타냅니다. 2004년 시장에 출현하였을 때 , SAS는 유연성이 높고 무장애시스템인 스토리지 토플로지로 인하여 사용자가 쉽게 스토리지를 디자인할 수 있도록 스토리지 전망에 변화가 시작될 것입니다.

SAS 하드 외형

SAS 하드의 커넥터 부위

SAS, SCSI, Raptor 하드를 회전속도 10000RPM, 용량 74G을 기준으로 비교해 보았습니다.

SAS와 SCSI는 회전속도가 15000RPM인 제품이 나와 있고, 랩터는 아직없습니다. 기본 성능은 거의 비슷하다고 보입니다. 하지만 SAS는 특히 대역폭과 확장성 면에서 발전 가능성이 높습니다.

1	SAS	SCSI	SATA
연결방식	Serial Attached SCSI	울트라320 SCSI	Serial ATA
커넥터	SAS	68pin Wide LVD	SATA
포멧용량	73.5GB	73.5GB	73.355GB
원판/헤드 갯수	플래터 한장/헤드 2개	플래터 한장/헤드 2개	플래터 한장/헤드 2개
원판 회전속도	10,000rpm	10,000rpm	10,000rpm
캐시메모리	16MBytes	8MBytes	16MBytes
예상수명	140만 시간 MTTF	140만 시간 MTTF	120만 시간 MTTF
평균탐색시간	읽을때4.0ms/쓸때4.5ms	읽을때4.0ms/쓸때4.5ms	읽을때4.6ms/쓸때5.2ms
트랙간탐색시간	읽을때 0.3ms / 쓸때 0.5ms	읽을때 0.3ms / 쓸때 0.5ms	0.4ms
전체 행정시간	읽을때 11ms / 쓸때 12m	읽을때 11ms / 쓸때 12ms	10.2ms
평균지연 시간	3ms	3ms	2.99ms
최대 전송속도	320MB/s	320MB/s	150MB/s
최대 처리속도	270MB/s	270MB/s	1
연속 쓰기속도	89MB/s	89MB/s	72MB/s
SAS 대역폭	600MByte/s	1	1

SAS의 하드웨어적인 컨트롤러

참고; http://support.ap.dell.com/support/edocs/storage/RAID/PERC5/ko/index.htm

http://www.acnc.com/04_01_00.html

Dell PERC(PowerEdge Expandable RAID Controller) 5/E의 외형은 SCSI 컨트롤러인 320-2e(perc 4e/dc)와 유사합니다.

RAID 레벨 요약
RAID 0은 특히 어떤 환경에서 데이터 중복을 필요로 하지 않는 큰 파일에 높은 데이터 처리량을 제공하기 위해 디스크 스트라이핑을 사용합니다.

RAID 1은 디스크 미러링을 사용하여 하나의 물리 디스크에 기록되는 데이터를 동시에 다른 물리 디스크에 쓸 수 있습니다. 이 기능은 적지만 완전한 데이터 중복 용량을 필요로하는 소규모 데이터베이스나 기타 응용 프로그램에 적합합니다.

RAID 5는 모든 물리 디스크에서 디스크 스트라이핑 및 패리티 데이터 (분산 패리티)를 사용하여 특히 규모가 작은 무작위 액세스를 위해 높은 데이터 처리량 및 데이터 중복성을 제공합니다.

RAID 0과 RAID 1의 조합인 RAID 10은 미러링 처리된 스팬에서 디스크 스트라이핑을 사용합니다. 높은 데이터 처리량과 완벽한 중복 데이터를 제공합니다.

RAID 0과 RAID 5로 구성된 RAID 50은 분산 데이터 패리티와 디스크 스트라이핑을 사용하며, 높은 시스템 가용성, 높은 요구 속도, 높은 데이터 전송률, 중간~대용량을 필요로 하는 데이터를 이용한 작업에 최적입니다.

RAID 용어
디스크 스트라이핑
디스크 스트라이핑은 단 하나의 물리 드라이브 대신 여러 물리 디스크에 데이터를 기록하는 것입니다. 디스크 스트라이핑은 종종 스트라이프 크기로 설명되는 8 KB ~ 128 KB의 크기로 변경이 가능한 스트라이프에 각각의 물리 디스크 저장 공간을 분할하는 작업을 나타냅니다. 이 스트라이프들은 반복되는 연속적인 방법으로 상호배치됩니다. 단일 물리 디스크에서 스트라이프 부분을 스트립이라 합니다.

예를 들어, RAID 레벨 0에서와 같이 디스크 스트라이핑만 사용하는 4 디스크 시스템에서 세그먼트 1은 디스크 1에 기록되고 세그먼트 2는 디스크 2에 기록되는 방식으로 기록됩니다. 디스크 스트라이핑을 사용하면 여러 개의 물리 디스크가 동시에 접근되므로 성능이 향상됩니다. 디스크 스트라이핑은 데이터 중복성을 제공하지 않습니다.

아래 그림에서 디스크 스트라이핑(Raid0)의 예를 보여 줍니다.

디스크 미러링
RAID 1에서처럼 미러링을 사용하면 하나의 디스크에 기록되는 데이터가 다른 디스크에도 동시에 기록됩니다. 하나의 디스크가 고장나면 다른 디스크의 내용을 사용하여 시스템을 실행하고 실패 물리 디스크를 복구할 수 있습니다. 디스크 미러링의 주요 장점은 100%의 데이터 중복성을 제공한다는 점입니다. 디스크 내용이 두 번째 디스크에 다시 전체적으로 기록되므로 디스크 중 하나가 고장나더라도 문제가 되지 않습니다. 두 디스크에는 항상 같은 데이터가 포함되어 있습니다. 하나의 물리 디스크는 운영 체제용 물리 디스크로 사용될 수 있습니다.

디스크 미러링은 100% 중복성을 제공하지만 시스템의 각 물리 디스크를 모두 복사해야 하므로 많은 비용이 소모됩니다. 그림 1-2에서는 디스크 미러링의 예를 보여 줍니다.

주: 미러링 처리된 물리 디스크는 읽기 로드 균형을 통해 읽기 성능을 향상시킵니다.

아래 그림은 디스크 미러링의 예 (RAID 1)

패리티
패리티는 둘 이상의 상위 데이터 세트로부터 중복 데이터 세트를 생성합니다. 중복 데이터는 상위 데이터 세트 중 하나를 복구하는 데 사용될 수 있습니다. 패리티 데이터는 상위 데이터 손실 발생시 그러한 데이터를 복제하는데 사용될 수 있지만 상위 데이터 세트를 완전히 복제하지 않습니다. RAID에서 이 방법은 하나의 물리 디스크 그룹의 모든 물리 디스크에 대한 전체 물리 디스크 또는 스트라이프에 적용됩니다.

패리티 데이터는 시스템의 하나 이상의 물리 디스크에 분산됩니다. 하나의 물리 디스크가 고장나면 패리티와 나머지 물리 디스크의 데이터를 사용하여 실패 드라이브를 복구할 수 있습니다. RAID 레벨 5는 그림 1-3에서와 같이 분산 패리티를 디스크 스트라이핑과 조합합니다. 패리티는 전체 물리 디스크의 내용을 복제하지 않고 하나의 물리 디스크 장애에 대한 중복성을 제공합니다. 그러나, 패리티 생성은 기록 과정의 속도를 저하시킬 수 있습니다.

아래 그림은 분산 패리티의 예 (RAID 5)

출처 : http://blog.naver.com/heewon0117/120032750559

AdminID.kr (어드민아이디) - 서버

용량 산정 (동시 접속자 계산)

SVN의 cleanup 에러시 해결방법

[오류해결] svn cleanup failed-previous operation has not finished; run cleanup if it was interrupted

TortoiseSVN 계정변경

SVN passwd 설정 : 계정 (users/passwd)

[SVN] Subversion 명령들

성능 엔지니어링 대한 접근 방법 (Performance tuning)

Performance Engineering 의 정의와 범위

Performance Engineering은 언제 해야 하는가?

시스템 용량 산정 (Capacity Planning)

Performance Engineering 의 절차

성능 목표와 모델의 정의

부하 생성

테스트 및 모니터링

개선 (Tuning)

반복

Performance Engineering을 위해 필요한 것들

시스템 용량산정 도구 (x86 서버외 용량산정)

throttle-me를 이용한 계정 트래픽 나타내기

윈도우 디스크 용량 확인

목차

개요

방법 1: diskmgmt.msc

방법 2: Get-WmiObject (PowerShell)

방법 3: diskpart

방법 4: wmic

같이 보기

PHP 디렉토리 용량 체크 (윈도우 리눅스 공용)

PHP 웹에서 서버 동시 접속자 수 확인 하기 (리눅스용, 윈도우용)

통합로그관리시스템 구축사례

SAS(Serial Attached SCSI)에 대하여 알기