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

원본출처 : http://www.zdnet.co.kr/develop/backend/db/article.jsp?id=48947&page=1&forum=0

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

김성록 (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 레벨까지도 응답시간을 분석하고 정확한 향상 요소를 찾아내 시스템 최적화를 구현하는 방안만이 최적의 솔루션이라고 할 수 있다.

시간 기반의 응답시간 분석

전산 시스템의 성능 최적화는 사용자가 인지하는 응답시간을 최적화하는 것이다. 따라서 사용자가 시스템을 사용할 때마다 응답시간에 불만을 느끼지 못하도록 시스템 성능을 최적화하는 대안 수립과 상황 예측은 필수적이다.

어떤 시스템을 일일 단위의 응답시간 분석을 수행한 결과, 24시간 단위로 모든 애플리케이션이 일일 4~5시간 정도를 사용됐다고 하면 별반 문제가 없다는 결론이 도출될 수 있다. 특히 CPU가 여러 개가 존재하는 시스템에서는 애플리케이션에서 사용 가능한 시간이 실질적으로 24시간의 배수가 될 수 있기 때문에 일일 24시간 가운데 4~5시간 사용은 그다지 사용량이 많지 않다고 볼 수 있다. 특히 기존 방식의 시스템 분석 방법론으로는 특정한 문제점을 찾아낸다는 것은 매우 힘들다. 그러나 시간 단위의 응답시간 분석으로 특정 시간대에도 응답시간이 사용자가 느끼기에 최적화돼 있는지에 대한 분석이 수행돼야 한다.

[img2]

예를 들어, CPU가 2개인 시스템에서 12시 10분부터 12시 20분까지의 응답시간 분석을 수행했다고 하자(그림 2). 그 결과 총 애플리케이션이 사용한 시간이 30분을 초과했다면, 이 시스템은 전체적인 사용량으로는 별다른 문제가 없겠지만 사용자는 특정 시간의 응답시간에 문제점을 느낀다고 가정할 수 있을 것이다.

특히 사용자가 특정 시간대의 응답시간에 불만을 느낀다면, 전체적인 일자별 시스템 분석 방법론도 중요하지만 반드시 시간대별 응답시간 분석을 통해 24시간 최적화된 시스템을 운영할 수 있도록 해야 한다. 응답시간 중 처리시간은 한정적인 시스템 자원의 사용량을 초과할 수 없지만, 대기시간의 경우에는 사용자가 요청을 하면 할수록 급격히 증가하는 형태를 보일 수 있다. 따라서 대기시간이 처리시간보다 커지면 커질수록 오라클의 대기 이벤트도 다양해지고 복잡하게 나타나게 되므로 정확한 원인 분석이 힘들어지게 된다.

(그림 2)는 특정 시간대에 사용자의 시스템 사용이 집중되는 형태를 보여준다. 따라서 특정 시간대에 발생한 애플리케이션과 세션 그리고 단위 SQL의 응답시간 분석을 통해 분석 기준을 설정하고 최적화할 수 있는 방안을 반드시 찾아야 한다.

특정 시간대에 집중 사용된 애플리케이션과 SQL을 분석한 결과, 상위 2개의 애플리케이션과 각 애플리케이션에서 수행된 각 상위 SQL이 이 시간대의 시스템 자원의 90% 이상을 소요했음을 확인할 수 있다. 결국 2개의 애플리케이션과 2개의 SQL을 분석해 24시간 최적화된 애플리케이션을 제공할 수 있고 사용자는 시스템 성능에 만족하게 됐다.

결국 시스템 응답시간 분석을 통해 전체적인 응답시간 분석을 수행한 후, 시간 기반의 응답시간 분석과 특정시간 기반의 애플리케이션 응답시간 분석을 통해 최종 사용자의 응답시간을 분석해 최적화하는 방안이 가장 효과적인 방법이라고 할 수 있겠다. 기존의 분석 방법론과는 달리, 응답시간 분석 이후 최종 사용자가 불만을 느끼지 않는 시간대의 애플리케이션 성능 분석은 배제하는 방법으로 접근하는 것이다.

애플리케이션 중심의 응답시간 분석시 장점

기존의 방법론은 사용자의 입장에서 응답시간을 분석하는 방법론과는 상당한 차이가 있다. 단순히 DBMS 내부의 딕셔너리에 남는 정보를 이용한 비율 기반 분석(ratio based analysis)의 기존 시스템 성능 분석은 사용자 중심이 아닌 DBMS 중심적인 분석 방법이다. 이런 기존 방법론은 사용자의 사용 유형과 사용 비중이 전혀 고려되지 않은 상태에서 단순 수치로 서버의 효율성을 체크하는 방법이기 때문에, 사용자에게 만족을 주기 어렵다.

사용자의 응답시간에 사용자 스스로가 만족하도록 하는 것이 가장 중요한 요소이고, 어떤 분석 방법론을 사용하더라도 시작점은 반드시 사용자의 응답시간 만족도 분석에 맞춰야 한다. 애플리케이션 중심의 응답시간 분석에 있어서 가장 중요한 요소는 사용자가 사용하는 애플리케이션이 만족할 만한 시간내에 원하는 답을 추출하는 것이다.

그렇지 않다면 그 시간대에 보여주는 시스템 응답시간을 통해 처리시간과 대기시간의 분석을 선행하고 분석의 표준을 설정한 뒤, 각 애플리케이션 레벨의 응답시간 분석을 통해 최적화 가능한 요소를 찾아내 사용자가 현재 수준에서 더 많은 애플리케이션을 수행하더라도 응답시간에 불만을 갖지 않도록 하는 분석 방법이다.

특정 애플리케이션에서 대기시간이 급증한다면 대기시간의 비중도를 분석해 CPU, I/O, 메모리 등과 같은 시스템 자원에 의한 것인지, 아니면 latch, enqueue, parameter 등과 같은 오라클 내부 자원에 의한 것인지를 분석한 후 문제 소지가 있는 성능 요소를 체크한다. 사용자가 불만을 느낄만한 요소가 발견되지 않거나 대기시간은 길지만 전체 응답시간에서 살펴봤을 때 큰 문제가 아니라면, 분석 대상에서 배제하는 형태로 접근한다. 이 때 최적화하는 방안은 여러 가지가 있으나 간략하게 설명하면 다음과 같다.

CPU 사용량이나 I/O 자원의 대기시간이 많다면 애플리케이션에서 사용하는 SQL의 효과적인 실행 계획 제어 또는 애플리케이션 수행 시간 재분배(load balancing) 등의 방법으로 최적화할 수 있다.

만약 공유 풀 대기와 내부 자원 대기의 값이 크다면 공유 풀의 크기, 애플리케이션의 SQL 사용 형태, 운영 시간중의 오브젝트 구조 변경, 불분명한 오브젝트, 공유 풀 관련 래치(latch)의 적절성 등의 다양한 요소들을 점검할 수 있다. 각각의 시스템 환경에 따라 분석 방법이 달라진다고 할 수 있다. 버퍼 대기와 내부 자원 대기의 값이 크다면 버퍼 캐시를 비효율적으로 사용하는 SQL을 분석하거나, 버퍼 캐시의 크기, 버퍼 캐시 관련 래치의 적절성 등의 요소를 점검할 수 있다.

시행착오 줄이는 애플리케이션 중심의 접근

이 외에도 다양한 요소가 있지만 위의 예를 든 것은 DBMS 서버 튜닝은 DBMS 입장에서 바라보면 효과적인 분석이 힘들어지고 많은 시행착오를 겪게 되기 때문이다. DBMS 관련 대기시간은 결국 애플리케이션에서 유발하는 것이고 이런 애플리케이션이 특정 시간대에 집중적으로 수행돼 DBMS 내부 자원의 경합이 발생하게 된다. 결국은 처리시간보다는 대기시간을 많이 소요하게 되는 것이다. 따라서 이런 경합을 유발시키는 애플리케이션을 중심으로 분석 접근하면 시행착오도 줄이고 가장 확실하고 효과적인 최적화 방안이 유도될 것이다.

SQL 튜닝, DBMS 서버 튜닝, 운영체제 튜닝 등의 모든 요소를 각기 독립적인 요소로 분석하는 것이 아니라, 애플리케이션 입장에서 애플리케이션의 수행 내역을 분석하며 각 요소의 튜닝을 연계해 분석해야 할 것이다. @