대용량 아키텍처와 성능 튜닝: 성능 엔지니어링

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

성능 엔지니어링은 시스템의 목표 성능을 정의하고 이를 달성하기 위해서 시스템의 구조를 반복적으로 개선하는 작업이다.
좁게는 코드와 시스템의 설정 변경에서부터 넓게는 최적의 성능을 위한 설계, 운영, 모니터링까지 포함하게 된다.

성능 엔지니어링은 언제 해야 하는가

• 분석 단계
  초기 분석 단계에서는 성능에 대한 목표를 정해야 한다.
  목표 응답시간, 총 사용자수와 동시 접속자 수, 시스템의 부하 패턴을 정의한다.

• 디자인 단계
  목표 성능과 용량을 달성할 수 있는 규모로 시스템 설계를 진행한다.
  시스템 디자인은 항상 최대 성능을 기반으로 고려한다.

• 개발 단계
  초기 스프린트가 끝나고 릴리스 되면 시스템의 아키텍처와 모듈들이 성능 목표를 달성할 수 있는지 지속적으로 테스트하고 튜닝을 수행한다.

• 최종 테스트 단계
  개발된 최종 시스템에 대한 성능, 용량 측정, 미세 튜닝을 수행한다.
  이 과정에서 잘못된 설정이나 코딩에 대해 검증한다.

• 운영 단계
  테스트 시에 발견되지 않은 성능 문제를, 모니터링 도구를 통해 지속적으로 탐색하고 수정해야 한다.

시스템 용량 산정

• 응답 시간
  사용자가 서버에 요청한 시간부터 응답을 받을 때까지의 모든 시간을 포함하고, 다음과 같이 세분화할 수 있다.

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

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

  • Think Time: 사용자가 보낸 요청에 대한 응답을 받고 웹 페이지를 보거나 화면을 보는 시간.

• Concurrent User
  현재 시스템을 사용하는 사용자

• Active User
  현재 시스템에 트랜잭션을 실행하여 부하를 주는 사용자.
  Active User의 숫자가 실제로 서버가 동시에 처리할 수 있는 트랜잭션의 양을 판단하는 기준이 되기 때문에 중요하다.

• Transaction
  사용자의 요청을 다루는 단위를 뜻한다.
  트랜잭션의 정의에 따라 시스템에 성능이 매우 다르게 정의되므로 어떻게 정의하느냐가 중요하다.

• TPS(Transaction per Second)
  초당 처리할 수 있는 트랜잭션의 양으로, 서버 성능 평가의 기준이 된다.

• HPS(Hit per Second)
  시스템이 처리할 수 있는 모든 웹 요청의 초당 처리량이다.
  단순히 비즈니스 트랜잭션에 대한 처리 시간만이 아니라 리소스에 대한 요청 처리량을 포함한다.

• Peak Time
  서버가 순간적으로 부하를 가장 많이 받는 순간이다.
  보통 정점을 찍는 순간의 동시 사용자 수와 기준 응답 시간을 성능 목표로 정의한다.

성능 엔지니어링의 절차

• 목표와 모델의 정의
  주요 업무 패턴이나 튜닝의 대상이 되는 시나리오의 개별 성능 목표를 정의한다.
  성능 모델을 정의한 후, 한 사용자가 실행하는 비율을 따져 복합 시나리오를 작성한다.

• 부하 생성
  성능 모델을 정의했으면 이에 따라 부하를 생성한다.
  부하 생성 도구는 간단하게는 Apache AB를 사용할 수 있고, nGrinder와 같이 복잡한 스크립트도 지원하는 도구를 사용할 수도 있다.

• 테스트와 모니터링
  주로 모니터링해야 하는 요인들은 다음과 같다.

  • 애플리케이션 관점
    기본적인 시스템의 성능을 측정한다. Response Time, TPS를 모니터링한다.
  • 미들웨어 관점
    성능 문제는 대부분 네트워크 아웃바운드 IO에서 발생하거나, 애플리케이션 서버 또는 데이터베이스에서 많이 발생한다.
    웹 서버가 설치된 하드웨어의 네트워크 아웃바운드 IO의 대역폭을 확인하고, 애플리케이션 서버의 유휴 스레드 수와 슬로우 쿼리의 모니터링이 주가 된다.
  • 인프라 관점
    • CPU: 항상 20~30%의 여유를 두고 사용한다.
    • 메모리: 피크 타임 시에 메모리의 사용량을 파악하는데, 스와핑이 발생한다면 메모리 사용량을 줄이도록 튜닝하거나 메모리를 늘려야 한다.
    • 디스크 IO: 보통 파일 시스템에 파일을 저장하는 시나리오나 로그를 저장하는 모듈, 데이터베이스와 같이 뒷단에 파일 시스템을 요구하는 모듈에서 많이 발생한다.
    • 네트워크 IO: 고용량의 파일이나 이미지 전송에서 병목이 발생하는 경우가 많다.

• 튜닝

  • 문제 정의
    문제 자체를 구체적으로 정의한다. 단순히 '속도가 느리다'가 아니라 문제를 명확히 해야 하며 재현 가능해야 한다.

  • 문제 분리
    문제가 발생하는 부분이 어디인지 파악해야 한다. 이를 위해서는 성능 시나리오가 어떤 컴포넌트를 거치는지부터 명확히 할 필요가 있다.

  • 문제 고립
    문제가 되는 구간을 다른 요인으로부터 고립시킨다.

  • 문제 상세 분석
    문제의 근본적인 원인을 파악한다. 프로파일링을 하거나 코드에 디버그 정보를 걸어 분석한다.

  • 병목 발견

  • 해결

• 반복
  테스트 및 모니터링으로 돌아가, 성능 목표에 도달할 때까지 작업을 반복한다.

성능 엔지니어링을 위해 필요한 것들

• 도구
  부하 테스트기를 사용해 부하를 발생시킨다.
  어느 구간에서 문제가 발생했는지 파악하기 위해 모니터링 도구가 필요하다.
  문제를 발견했을 때, 근본적인 원인을 찾기 위해 프로파일링 도구가 필요하다.

• 역량
  컴퓨터와 프로그래밍, OS 등에 대한 폭넓은 이해가 필수적이다.

• 하드웨어 인프라, 미들웨어, 애플리케이션에 대한 지식
  특정 솔루션에 대한 전문적인 지식이 있어야 하는데, 이러한 지식은 오랜 경험이나 습득하기 위한 긴 시간이 필요하다.

• 경험
  경험이 많으면 시스템의 상태만 봐도 어디서 문제가 발생했을지 예상이 가능하다.
  다른 기술로 구현된 시스템도, 경험이 있다면 문제에 대한 접근법은 유사하므로 해결이 가능하다.

• 인내심
  성능 엔지니어링은 반복적인 테스트와 모니터링 및 분석으로 이루어지므로, 문제를 해결하기 위한 인내심이 필수적이다.