[조대협 대용량 아키텍처] 성능 엔지니어링

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

성능 엔지니어링은 시스템의 목표 서능을 정의하고 이를 달성하기 위해서 시스템을 구조적으로 개선하는 작업을 말한다. 좁게 생각하면 코드 상의 병목을 잡고 시스템의 설정을 수정하여 성능을 높히는 튜닝으로 볼 수 있지만, 넓게 보면 성능 목표 정의와 최적 성능을 위한 디자인, 구현, 개발, 설계, 운영, 모니터링의 모든 과정을 포함할 수 있다.

 

 

성능 엔지니어링을 수행하는 4단계

성능 엔지니어링은 소프트웨어 개발 과정 중 총 4단계에 거쳐 수행된다.

 

1. 분석 단계

초기의 분석 단계에서는 성능에 대한 목표를 정의한다. 

목표 응답 시간, 총 사용자 수, 동시 접속자 수와 같은 목표를 정하는데 요기서 이를 기반으로한 성능 모델까지 고려한다.

 

예를 들어 게임 시스템에서 초등학생을 대상으로 한 게임을 개발한다면, 보통 방과 후인 3시에서 5시가 부하가 가장 몰릴것이다. 만약 게임 플레이시간이 보통 40분이고 하루에 2 게임을 한다면, 사용자별 체류시간은 약 2시간, 게임횟수는 2, 부하시간은 3~5시인 성능 모델을 만들 수 있다.

 

2. 디자인 단계

디자인 단계에서는 목표 성능과 용량을 기준으로 설계를 진행한다. 성능을 기준으로 한다면 항상 최대 성능에 맞춰 디자인하여야 한다. 성능과 용량은 디자인뿐만 아니라 기술을 결정하는데 많은 영향을 주는데,  어떤 하드웨어를 사용할 것인지 어떤 프레임워크를 사용하는지에 따라 성능과 용량 차이가 크게 발생할 수 있기 때문에 디자인 단계에서 기술까지 고려한 설계를 해야 한다.

 

3. 개발 단계

개발 단계에서 초기에는 리스크가 높은 부분, 난도가 높은 부분, 핵심 기능 등을 먼저 개발한다. 

초기 스프린트가 끝나고 성능 테스트가 가능한 QA로 시스템이 이관되면 이 때 성능엔지니어링 영량을 집중하여 아키텍처와 모듈이 성능 목표를 달성할 수 있는지 지속적으로 테스트와 튜닝 과정을 거친다.

 

4. 최종 테스트 단계

최종 테스트 단계에서는 시스템에 대한 성능, 용량 측정, 튜닝 정도로 마무리한다. 

이 단계에서 검증을 수행하면 보통 2배에서 10배의 성능 향상이 일어난다. 그 이유는 대부분 실수에 의한 문제를 검증하기 때문이기에 성능이 낮게 나와 튜닝을 하기 쉽기 때문에 성능 향상이 높아진다.

 

5. 운영 단계

마지막으로 운영 단계에서는 테스트에서 발견되지 않은 문제를 모니터링 도구를 통해서 지속적으로 성능을 모니터링하고 문제가 되는 부분을 지속적으로 수정한다. 시스템 모니터링은 APM(Application Performance Monitoring) 도구인 제니퍼를 사용하거나 Ganglia와 같은 모니터링 도구를 통해 성능 상태를 확인한다. 

이 부분에서는 용량 증설에 대한 부분을 고려하는데 보통 CPU 용량이 80% 정도에 다다르면 용량 증설을 고려해야 한다.

 

추가적으로 운영단계에서 중요한 부분은 업무 특성에 맞춘 운영 환경 용량을 준비하는 것과 로그 기록이다.

용량을 미리 준비하는 것은 특정일자에 부하가 많아지는 경우, 예를 들어 수강신청,에는 미리 시스템 용량을 확장하여 부하가 잃어나지 않도록 대비를 한다. 

 

시스템 용량 산정

성능과 관련 된 큰 이슈 중 하나인 시스템 용량 산정에 대해 조금 더 알아보자.

용량을 산정하기 위해서는 일반적으로 아래와 같은 고려사항을 가진다.

 

Response Time(응답 시간)

응답 시간은 사용자가 서버에 요청을 한 시간부터 응답을 받을 때 까지의 시간을 말한다. 응답 시간에 대해서는 아래와 같이 세분화 해서 분리한다.

- Network Time : 서버에 요청을 보내고 받을 때 소요되는 네트워크 시간

- Transaction Time : 서버에서 트랜잭션이 처리되는 시간

- Think Time : 사용자가 요청에 대한 응답을 받고 웹페이지 혹은 화면을 보는 시간

 

이 세가지 network time과 transaction time을 계산하여 응답 시간을 산출한다. 거기에 Think time을 더하여 request interval라고 하는데, request interval은 시스템 요청부터 다음 요청이 발생하기 가지 전체시간을 말한다.

 

Concurrent User(동시 사용자)

동시 사용자는 현재 시스템을 사용하는 사용자를 말하는데, 웹 사이트를 사용하기 위해 브라우저를 열고 웹사이트를 보는 것과 같이 현재 시스템을 사용하는 사용자 수를 동시 사용자라고 한다. 

보통 시간 범위를 설정하여 동시 사용자수를 산정하는데  그 시간동안 response time과 think time이 포함 된 사용자를 합쳐 동시 사용자를 구한다.

 

Active User(액티브 사용자)

액티브 사용자는 현재 시스템에서 트랜잭션을 실행하여 부하를 주는 사용자를 말한다. 일반적으로 이 액티브 사용자는 웹이 생기면서 구체화 되었는데, 웹 페이지를 사용할 때 사용자는 로딩 되는 순간에만 서버 부하를 주고 로딩 된 후에는 부하를 받지 않는다. 즉, 사용자가 로딩된 페이지를 보는데 시간이 발생하는 것이다. 

액티브 사용자 수와 서버에서 실행되고 있는 스레드 수 혹은 프로세스 수는 동일하다 따라서 이 액티브 사용자의 수는 실제 서버가 처리할 수 있는 트랜잭션의 수와 관계가 있기 때문에 중요한 성능 요인이 될 수 있다.

 

트랜잭션

트랜잭션은 사용자의 요청을 다루는 단위를 말하는데, 이 단위를 정의하는데 따라 시스템 성능이 다르게 정의 됙 때문에 트랜잭션은 상당히 중요하다고 할 수 있다.

 

만약 리소스를 톰캣과 같은 애플리케이션 서버에서 처리하는 것이 아닌 CDN 혹은 웹서버에서 처리 할때 톰캣은 리소스에 대한 트랜잭션 요청을 받지 않는다. 그렇기 때문에 대부분 전체 시스템에서 비스니스 로직에 대한 성능을 측정할 때는 리소스에 대한 로딩시간을 계산하지 않고 트랜잭션을 처리한다. 또한 리소스의 로딩은 상대적으로 부하가 적고 브라우저에서 캐시가 되기 대문에 성능 측정에 크게 영향을 주지 않기때문에 트랜잭션 단위로 처리하지 않는다.

 

TPS(Transaction Per Second)

TPS는 초당 처리할 수 있는 트랜잭션의 양을 말한다. 주로 서버 성능의 평가 기준이 되는데, 액티브 사용자가 순간 트랜잭션을 처리할 때 이를 목표 응답 시간으로 나눈 값이 TPS가 된다. 

예를 들어, 액티브 사용자가 50명이고 개당 응답시간이 2초라면 TPS는 25가 된다.

 

HPS(Hit Per Second)

HPS는 시스템이 처리할 수 있는 모든 웹 요청의 초당 처리량이다. TPS가 비즈니스 트랜잭션에 대한 처리 시간을 정의한다면 HPS는 리소스에 대한 처리량도 포함하기 떄문에 TPS에 비해 10~20배 높게 나온다.

 

Peak Time

피크 타임(Peak Time)은 순간적으로 가장 부하를 많이 받는 시간을 말한다. 보통 서버의 용량을 산정하거나 성능을 설계할 때는 이 시간의 부하량을 기준으로 한다. 이 피크 타임을 기준으로 동시 사용자 수와 기준 응답시간을 성능 목표로 잡는 것이 일반적이다.