[조대협 대용량 아키텍처]성능 튜닝

지난 시간에 성능에 대한 병목을 찾았다. 이제 해당 병목 문제를 해결 및 반영해야한다.

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

 

문제의 정의

성능 개선의 가장 기본은 문제 자체를 제대로 정의하는 것이다.

"그냥 느려요"가 아니라 "성능 목표가 350TPS에 1초 내의 응답 시간인데, 현재 60TPS에 5초의 응답 시간에 애플리케이션 서버의 CPU 점유율이 100%입니다."와 같이 명확해야 하며 문제점은 재현 가능하다. 특히 재현 가능성은 매주 중요한 점인데 테스트 환경이 잘못되었거나 외부적인 요인에 따라 결과가 다르게 나올 수 있기 때문에 문제 자체를 명확하게 정의할 필요가 있다.

 

Break down (문제 분리)

문제가 발생하는 부분이 어딘지를 판단해야한다. 시스템은 앞단의 로드 밸런서나 미들웨어, 데이터베이스와 같은 여러 구간에서 발생한다. 그래서 성능 저하의 원인이 정확하게 어느 부분인지를 확인하려면 성능 시나리오가 어떤 컴포넌트를 거치는지를 명확하게 할 필요가 있다. 이 과정을 Break down 이라고 한다.

 

Isolation (문제 고립)

문제가 되는 구간을 다른 요인으로부터 분리(고립) 시킨다. 물론 완벽한 분리는 어렵다. 

예를 들면 시나리오 자체가 로그인 시나리오고 SSO(Signle Sign On)을 통해서 로그인하는 시나리오라서 SSO 시스템과 연동이 되어 있다면, SSO 연동을 빼고 다른 목업(Mock Up)을 넣어 SSO와 연결성을 끊고 테스트하는 것이 좋다. 이렇게 문제에 대한 다른 요인과 연관성을 최대한 제거하는 작업이 Isolation 이다.

 

Narrow down (문제 상세 분석)

문제를 분리 했으면 근본적인 문제를 찾고자 원인을 찾는다. 프로파일링을 하거나 코드에 디버그 정보를 걸어서 문제의 원인을 분석하는 과정을 Narrow down이라고 한다. 특히 Narrow down 과정에서는 분석을 위한 여러 가지 기법이나 도구들을 사용해야하고 현상을 이해하려면 해당 솔루션이나 기술 분야에 대한 전문성은 필수이다.

 

병목 발견

Narrow down을 해서 문제의 원인을 계속 파헤쳐 나가면 병목의 원인이 되는 근본적인 문제가 판별 된다.

 

해결

병목의 원인을 찾았다고 해결이 되는 건 아니다. 데이터베이스에 인덱스를 설정하면 되는 간단한 문제도 있을 수도 있고 근본적인 솔루션 특성이나 설계상의 오류로 문제가 발생할 수도 있으며 하드웨어를 늘려서 해결하는 방법도 있을 수 있다. 관건은 문제를 어떻게 잘 정의하고 문제가 어떤 요소로 구성되어 있으며 각각 어떤 구조로 작동하는지를 잘 파악할 수 있는 문제 접근 능력과 솔루션의 로우 레벨(Low Level)로 들어갈 수 있는 전문성이라고 할 수 있다.

 

반복

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

 

다음 시간에는 성능 엔지니어링을 위해 필요한 것들에 대해서 알아보자

 

이전 글

성능 엔지니어링 절차

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

 

다음 글

[조대협 대용량 아키텍처]성능 엔지니어링이 필요한것들

[조대협 대용량 아키텍처]성능 엔지니어링이 필요한것들

 

---

이 글은 조대협의 서버사이드 대용량 아키텍처와 성능 튜닝 책을 참고하여 작성되었습니다.

이 글은 코드 프레소 DevOps Roasting 코스를 수강하면서 작성한 글입니다.