애플리케이션 중심의 튜닝 최적화 유도

데이터베이스 성능에 애플리케이션이 가장 중요한 영향을 끼치는 핵심 요소라는 점은 이미 여러 차례 강조한 바 있다. 따라서 정확한 원인 분석에 따른 성능 최적화를 구현하기 위해서 애플리케이션 튜닝은 필수적이다. 이번 호에서는 사용자가 수행하는 애플리케이션을 중심으로 한 응답시간 최적화를 구현하는 애플리케이션 튜닝에 대해 자세하게 살펴본다.

김성록 (on the NET)

2002/05/19

애플리케이션 튜닝(Application Tuning)이란 문제가 있는 프로그램이나 SQL 문장의 로직·객체에 인덱스를 추가·변경·삭제하는 등의 작업을 수행해 성능을 최적화하는 일련의 작업을 의미한다. 이런 애플리케이션 튜닝의 최종 목표는 애플리케이션에서 사용하는 시스템 자원을 최적화함으로써, 사용자가 만족할 수 있는 수준의 응답시간을 항상 보장하는데 있다. 여기에는 애플리케이션 동시 사용자 수의 증가와 관계없이 만족할 만한 응답시간을 보장한다는 의미도 포함돼 있다.

시스템의 응답시간 분석 선행

애플리케이션 중심의 성능 분석·튜닝을 수행하기 위해서는 시스템의 응답시간 분석이 선행돼야 하는데 이 과정에서 처리시간(Service Time)과 대기시간(Queue Time) 중 어떤 부분에서 더 많은 시간이 소요되고 있는지를 파악해야 한다.

만약 대기시간이 높게 나타나면, 어느 부분에서 대기시간이 높게 나타나는지를 분석해야 한다. 많은 시간을 소비한 애플리케이션을 중심으로 응답시간을 분석하고, 각 애플리케이션을 최적화한다. 일련의 절차를 거쳐 분석하는 방법을 애플리케이션 중심의 응답시간 분석이라고 한다.

이 때 사용자가 현재 불만을 느끼지 않는 애플리케이션은 분석 대상에서 제외가 된다. 그러나 이들 애플리케이션 중 일부는 향후 사용자와 데이터 증가로 인해 성능 문제로 발전할 가능성이 매우 높기 때문에 각별한 주의가 요망된다. 이런 애플리케이션들에 대해서는 정확한 응답시간의 분석과 수행 추이의 분석을 토대로 주의 깊게 튜닝을 실시해야 하는 대상으로 분류하게 된다.

애플리케이션 기반의 응답시간 분석을 수행하면 애플리케이션이 수행 가능한 처리시간은 한계가 있다(CPU 수·애플리케이션 사용 시간 수). 이런 처리시간과는 달리 대기시간의 경우에 일단 발생하게 되면, 사용자의 애플리케이션 증가에 따라 급증하는 형태를 보인다. 따라서 애플리케이션의 입장에서 분석을 수행하지 않고 DBMS나 시스템의 입장에서 바라본다면 추상적인 분석으로 끝날 가능성이 매우 높다.

자원 활용한 성능 저하 요인 분석

DBMS를 기반으로 구축된 전산 시스템이 아무리 대형화돼도 시스템 자원(CPU, 메모리, I/O), DBMS 내부 자원이 한정적이기 때문에 극복하기 힘든 장벽에 부딪히기 마련이다. 한정된 자원을 애플리케이션에서 사용하게 되는데, 처리시간이 한계에 도달하거나 내부적인 자원 처리의 한계에 도달하게 되면 대기시간의 증가는 물론 결과적으로는 애플리케이션의 응답시간이 길어지게 된다.

따라서 처리시간과 대기시간의 증가는 애플리케이션 수행 빈도와 처리 유형이 그 원인이 되며, 초기에 안정화된 시스템일지라도 서서히 데이터가 증가하고 사용자가 늘어나면 어느새 응답시간을 많이 소비하는 시스템으로 전락하곤 만다.

중요한 것은 이런 병목 현상들이 어느날 갑자기 생기는 것이 아니라, 인간에게 발생하는 다양한 질병들처럼 서서히 증후를 보이다가 급속하게 진행되는 것이 일반적이라는 것이다. 이런 현상을 감안해 볼 때, 순간적인 모니터링보다는 일정 기간을 두고 전개되는 성능 추이 분석의 필요성이 크게 제기되고 있다고 할 수 있다.

DBMS 내부 구조를 자세히 들여다보면, 동시성(Concurrency)를 보장해 다수의 사용자가 사용 가능하도록 지원하고 있다. 일치성(Consistency)를 위해 동시에 많은 사용자를 지원한다고 하지만, 실제 내부 자원의 사용 원리를 살펴보면 순서대로 처리되고 있음을 알 수 있다. 시스템 자원과 DBMS 내부 자원은 한계점에 도달하고 결국 대기시간을 증가시키는 원인으로 작용하게 되는 것이다.

그러나 이는 결과에 치중한 방법론이라고 할 수 있다. 보다 근본적인 차원에서 문제점을 분석해보면, 다수의 사용자가 동시에 전산 시스템을 사용하는 것이 문제 유발의 근원임을 알 수 있다. 사용자가 최종적으로 사용하는 것은 결국 애플리케이션이기 때문에 애플리케이션 레벨에서의 심층 분석이야말로 한정적인 시스템 자원과 DBMS 내부 자원을 최적으로 사용할 수 있는 근본적인 대안이 될 것이다.

수많은 사용자가 동시에 그리고 보다 효과적으로 시스템을 사용할 수 있도록 하는 것이 전산 시스템의 목적이고, 이를 위해 많은 비용 투자를 감행하는 것인 만큼 동시성을 최대한 보장할 수 있는 시스템 최적화를 반드시 구현해야 할 것이다.

애플리케이션 레벨까지 최적화

지난 호에서 시스템 레벨과 DBMS 레벨에서의 응답시간 분석의 방법론과 중요성에 대해 논의한 바 있다. 이번 호에서는 애플리케이션 중심의 응답시간 분석에 대해 소개하고자 한다.

애플리케이션 중심의 응답시간 분석은 전체 응답시간 분석을 완료한 후, 시스템이 처리시간 또는 대기시간에 집중됐는가를 분석하는 단계를 거쳐 실질적으로 응답시간을 소모한 애플리케이션을 분석하는 상세 분석으로 전개되는 것이 바람직하다.

대부분의 고객 시스템을 살펴보면 개발, DBMS 운영, 시스템 운영이 각각의 파트별로 운영되는 경우가 많으며, 시스템 성능에 문제가 발생했을 때 개발팀 보다는 DBMS 운영, 시스템 운영 파트에서 원인 분석을 시작하는 것이 일반적이다. 많은 업무 담당자들이 성능 문제의 발생 원인에 대해 일차적으로 운영 팀에게 묻는 것이 현실이다.

그러나 운영 미숙과 각종 버그로 인해 발생하는 문제점들은 이미 구축 운영중인 시스템에서는 발생할 가능성이 매우 희박하다. 오히려 시스템 구축 초기 단계에서 많이 발생하게 된다.

이미 운영중인 시스템에서 주로 발생할 수 있는 문제점으로는 어제 제대로 수행됐던 시스템과 업무가 오늘 갑자기 제대로 수행되지 못하는 경우를 들 수 있다. 이와 같은 경우에는 문제의 원인을 운영적인 측면에서 찾기보다는 애플리케이션에서 찾는 것이 빠르고 정확한 경우가 많다. 검증되지 않은 애플리케이션이 초기에 불만없이 제대로 수행되다가 특정 애플리케이션이 성능 문제의 원인이 되는 경우가 많기 때문이다. 간혹 운영 미숙으로 발생하는 경우는 고객이 비용 기준 옵티마이저(cost based optimizer)를 사용할 때 대용량의 데이터 분포도 변화 발생, 오브젝트의 변경 시에 반드시 수행해야 하는 분석(analyze) 작업이 빠졌을 경우인데, 필자의 경험에 비춰볼 때 애플리케이션에서 유발할 가능성에 비하면 현저히 낮다고 볼 수 있다.

처리시간·대기시간 분석 집중 체크

전산 시스템은 하루 동안에도 수없이 많은 애플리케이션들이 수행되며, 다수의 사용자가 동시 사용한다. 시스템과 DBMS에 대한 성능 분석(응답 속도 분석)을 실시한 다음 단계에서 진행돼야 하는 것은 바로 애플리케이션 단계에서 응답 속도 분석이다. 수행되는 각각의 애플리케이션별로 응답 속도 분석을 수행해 각 애플리케이션 별로 분석 포인트를 가져가야 보다 효율적인 애플리케이션 튜닝을 수행할 수 있다.

(그림 1)은 시스템 분석과 애플리케이션 분석의 단계·연계성을 나타내는 것으로, 각각 독립적인 성능 지표를 보이는 애플리케이션 응답시간 분석에 대해 설명하기로 한다.

특정 일자에 시스템 응답시간 분석 결과가 (그림 1)과 같이 나타났다고 가정해 보자. 이 시스템은 대기시간이 전체 응답시간의 약 30%를 차지하고 있는 것을 살펴볼 수 있는데, 이는 처리시간 기반의 시스템이라고 봐야 할 것이다. 따라서 처리시간 중심의 분석을 통해 처리시간을 최소화하면 I/O 대기, CPU 대기 등과 같은 항목의 대기시간을 줄일 수 있다.

또한 모니터링을 통한 정확한 분석으로 대기시간중의 락 대기시간(Lock Waits time), 내부 락 대기시간(Internal Lock Waits Time)을 줄일 수 있는 방안을 검토해야 하는데, 전체적인 응답시간을 감소시키기 위해서는 무엇보다도 처리시간 중심의 튜닝이 진행돼야 한다.

다음 단계는 애플리케이션별 응답시간 분석을 수행해야 한다. 이 시스템에서 응답시간 분석을 수행하면 상위 4개에 해당하는 애플리케이션들이 전체 응답시간의 약 90%를 상회하고 있음을 알 수 있다. 또 각 애플리케이션별로 응답시간 비중을 확인해 보면, 애플리케이션 1이 50%, 애플리케이션 2가 18%, 애플리케이션 3이 16%, 애플리케이션 4가 8%이며, 전체 응답시간의 92%를 차지하고 있음을 확인할 수 있다.

효율적인 애플리케이션 분석 방법

다음 단계는 전체 응답시간과 비교해 각 상위 애플리케이션의 응답시간 상세 분석을 수행하는 단계다. 애플리케이션 1을 분석하면 전체 응답시간의 50% 정도를 차지하지만, 50% 기준으로 처리시간이 90%를 초과하는 것을 확인할 수 있다. 따라서 애플리케이션 1에 대한 응답시간 중심의 튜닝이 전체 응답시간을 최소화하는 방안이라는 결론에 도달할 수 있게 된다.

또 내부 락(Internal Lock)과 관련해서는 애플리케이션 2와 애플리케이션 3을 중심으로 한 분석에, 로 락(Row Lock)과 관련해서는 애플리케이션 2와 애플리케이션 4를 중심으로 한 분석에 중점을 둬야 한다. 그러나 전체 시스템 응답시간 분석 결과 처리시간 중심의 분석을 수행하기로 튜닝 방향을 이미 설정했으므로, 애플리케이션 1의 처리시간을 줄이는 방안으로 튜닝을 진행해야 한다는 대전제를 준수해야 한다.

이런 작업을 거쳐 애플리케이션 1의 응답시간 소요 원인 분석 단계로 넘어가게 되는데, 애플리케이션 1에서 수행된 SQL의 응답시간 분석이 반드시 수반돼야 한다. 애플리케이션 1에서 수행된 전체 SQL을 분석한 결과, 상위 3개에 해당하는 SQL들이 전체 응답시간의 99%를 차지하고 있는 것으로 나타났으며, 99% 기준으로 각 SQL의 응답시간 비중을 분석해보면 SQL 1, SQL 2, SQL 3이 각각 80%, 18%, 2%의 비중을 차지하고 있는 것으로 분석됐다.

처리시간 기준으로 보면 SQL1과 SQL 2를 분석해야 하고, 대기시간 기준으로 보면 SQL 2에서 CPU 대기 분석을, SQL 1에서 I/O 대기 분석을 해야 하지만, 처리시간 최적화를 기준으로 볼 때 SQL 1과 SQL 2의 처리시간을 줄여야 한다.

이들 SQL은 두 가지 경우에 분석 가능한데, 수행 속도가 1초 이하 정도로 굉장히 빠르지만 수행 빈도수가 엄청나게 많이 수행 됐을 경우와 수행 빈도수는 많지 않지만 수행 시간이 많이 걸리는 SQL일 가능성이 높다. 그러나 (그림 1)에서 제시되는 SQL들의 응답시간표를 살펴보면, I/O 대기가 얼마 되지 않고 처리시간이 높기 때문에 소량의 데이터를 처리하는 OLTP(On-Line Transaction Processing)이며 수행 빈도수가 많은 그런 SQL일 가능성이 높다는 것을 짐작할 수 있다.

0.5초의 수행 시간을 보이는 SQL을 0.25초 정도로 줄이는 것이 전체 응답시간을 30% 이상 줄일 수 있는 방안이 된다. 이런 분석 방법은 상당히 중요한 의미를 갖는다. 단순 모니터링 측면에서 0.5초의 시간을 소요하는 SQL은 결코 문제로 지적할 수 없기 때문이다. 그러나 응답시간 분석 방법론에서는 0.5초가 소요되는 SQL이 가장 문제이며 어떤 방법을 사용하더라도 이를 절반 이하로 줄여야만 전체응답시간을 줄이고 시스템 자원을 최적화할 수 있다.

그렇다면 단순 비율 기반 분석(ratio based analysis)이나 대기 이벤트 기반 분석(wait based analysis)을 이용해 시스템을 분석할 때, 0.5초의 시간이 소요되는 SQL을 가장 중요한 분석 대상 요소로 파악할 수 있는가에 대한 의문을 제기할 수 있다. 현재로서는 결코 그렇지 못하다는 것이 그 대답이다. 이에 대한 해답을 제시해야만이 시스템 분석 방법론의 올바른 해답이 될 것이다. 따라서 시스템, 애플리케이션 그리고 가장 작은 단위인 SQL 레벨까지도 응답시간을 분석하고 정확한 향상 요소를 찾아내 시스템 최적화를 구현하는 방안만이 최적의 솔루션이라고 할 수 있다.