8장. 성능 엔지니어링의 정의와 범위

저는 금융 서버 개발자로 일하고 있습니다. 금융에는 다양한 데이터가 존재합니다. 사용자에게 보여주는 데이터를 제공해주는 A서버는 B,C,D 서버( 신용카드, 체크카드 등 다양한 자료 ) 를 수집하여 복잡한 계산 후 응답을 줍니다.

1차적으로 B,C,D를 병렬로 응답을 받아와서 처리하면 어느정도 개선은 가능합니다. 다만, 여기서 몇가지 고민이 생겨 책(조대협-대용량아키텍쳐와 성능 튜닝)을 읽게 되었습니다

Analysis Layer 구축이 어려움 : A 서버는 B,C,D 서버 응답을 통해 만들어진 데이터이기 떄문에 Persistence Layer가 현재 존재하지 않는다. 물론, B,C,D 서버에서 저장한 데이터 기반으로 Dataware house를 만들수 있겠지만 매우 복잡한 A서버의 비즈니스 로직을 쿼리로 만드는건 현실적으로 불가능하고 유지보수도 되지 않는다. 그래서, B,C,D 개별 분석은 가능하지만 실제로 우리 유저가 최종적으로 보고 있는 데이터에 대한 분석은 한계가 있다.
1000만 이상의 고객과 개편으로 인한 트래픽 급증 예상 : 성능 개선 측정을 위해서 어떠한 부분을 측정해야 되는지 어떻게 하는지에 대해 궁금하였다.

1. 분석 단계 : 모든 일이 그렇듯이 목표를 정해야 한다.

시스템 용량 산정 방법은 아래에서 설명할 예정이다.

2. 디자인 단계

시스템 디자인은 항상 피크 타임(최대 성능)에 맞춰서 디자인
But, 근래에는 클라우드를 이용하여 필요시에만 탄력적으로 사용하는 Auto Scale out 모델 사용
업무 종류에 따라 디자인 필요 : 이메일 서비스는 일정한 부하 -> 고정된 하드웨어 설계 / 이벤트 사이트 같은 경우 -> 클라우드 권장
미들웨어나 프레임워크에서도 정의된 성능 모델에 따라 적절하게 선택햐아 함 : 10만명 정도면 RDBMS 사용해도 문제 없지만, 1000만명 정도라면 샤딩이나 NoSQL과 같은 다른 차원의 접근이 필요함, 빠른 응답 시간을 요구하는 경우 Redis 같은 캐시 솔루션 적극 활용

단순한 대규모 성능 및 용량 테스트를 해보는 Proof Of Concept 같은 작업 수행은 꼭 해봐야 한다.

3. 개발 단계

4. 최종 테스트 단계

5. 운영 단계

Response Time

Concurrent User ( 동시 사용자 )

Acitve User ( 활성화 된 사용자 )

웹 사이트를 열어 놓고 있는 경우 Concurrent User와 Active User 간의 개념차이가 발생한다. 위의 그래프를 보면 열어놓고 웹사이트를 보는 사람 포함하여 Concurrent User가 5명이지만 순간 Active User는 3명이다. 즉, Active User가 실제로 서버가 동시에 처리할 수 있는 트랜잭셩 양을 판단할 수 있는 기준이다

성능 측정 지표 정리

TPS(transaction per second) = [ Active User ] / [ Response Time ]
HPS(hit per second) : 시스템이 처리할 수 있는 모든 웹 요청의 초당 처리량
Active User = [ Concurrent User ] X [ Response Time ] / ( [ Response Time ] + [ Think Time ] )

예를 들어, Concurrent User가 300명이고 목표응답시간이 3초 이내, Think Timedl 15초인 시스템이라면?

300 * 3 / 18 = 50이므로 적정 프로세스 양은 50개가 되고, 목표 TPS는 16.6 TPS가 된다

IT 메모장