Admin::VLDB성능관리#2

대용량 VLDB의 성능관리
- VLDB와의 소리 없는 전쟁(2) -

 

대용량 VLDB의 성능관리에서 자주 마주치는 문제가 바로 응답 속도 저하현상이다. 대개 IT 사용자들이 시스템의 성능이 떨어질 때 하드웨어 탓으로 돌릴 때가 흔하다. 자신이 쓰고 있는 데이터베이스 성능을 유지하기 위해 땀을 흘려본 사람이라면, VLDB의 성능관리의 중요성을 다시 한번 되새겨보자.

 

권순용 | kwontra@hanmail.net

 

 

대개 대용량 데이터베이스인 VLDB에서 처음 접하게 되는 문제라면 아무래도 응답 속도 저하가 많다. 이는 비단 대용량 데이터베이스에 국한되는 것은 아니다. 데이터베이스를 이용하는 모든 업무에서 흔하게 발생할 수 있는 문제이기 때문이다. 하지만 VLDB는 응답 속도 저하가 더욱 심각하게 발생하게 된다. 그렇기 때문에 지금도 수많은 고객업체들이 VLDB에 대한 성능 관리를 고민하고 있다. 대부분 성능 관리의 중요성은 인지하지만, 어느 요소가 성능 관리의 중심인지를 모르는 경우가 많다. 이번 호에서는 많은 IT 사용자들이 고민도 하고 관심을 갖고 있는 대용량 VLDB의 성능 관리에 대해 살펴보자.

 

성능 관리의 중심에는 SQL이 있다

자신이 쓰고 있는 시스템에서 응답 속도 저하현상이 발생한다면 먼저 무엇을 확인해야 할까? 이럴 경우 일반적으로 해당 시스템의 관련자들이 한자리에 모이게 되는 것은 당연한 순서일 것이다. 모두 모여서 마라톤 회의도 진행되게 마련이다. 이 때 각 담당자들은 어떻게 처리해야 될지 과제 아닌 과제를 떠맡게 된다. 여기까지의 상황 설정은 성능 관리를 위한 일련의 활동이고 또 주위에서 자주 접하게 마련이다. 이럴 경우 회의에 참석해 보면 재미있는 현상이 있다.

 

개발자들은 서버의 자원이 부족하여 응답 속도가 저하되는 것이라고 이야기할 때가 많다. 또한, 현업은 서버 설정이나 또는 시스템 운영자들의 잘못된 관리에 의해 응답 속도 저하 현상이 발생하는 것이라고 의문을 가질 때가 흔하다. 여기까지는 그럴 수도 있는 일이다. 보다 중요한 것은 서버 담당자 또는 소프트웨어 담당자에게 응답 속도 저하의 원인 및 해결 방안을 도출하라고 요구하는 경우가 많다는 것이다. 하지만 운영 중이던 시스템이 갑자기 응답 속도 저하가 발생했다면 무엇이 문제였겠는가? 각 담당자들의 실수가 아니라면 서버 또는 소프트웨어에는 문제가 없다고 생각해야 하지 않을까? 이런 상황이라면 응답 속도 저하의 문제는 회의 때 어느 누구도 언급하지 않은 데이터의 증가 및 데이터베이스가 VLDB로 변하고 있기 때문에 생기는 성능 문제일 가능성이 높다. 현재 운영 중인 시스템의 응답 속도가 저하되었다면 시스템과 소프트웨어를 의심하지 말고 지금 시스템에 증가하는 데이터와 해당 데이터를 액세스하는 SQL을 확인해 보는 것이 좋다. VLDB의 성능 관리는 증가되는 데이터의 효과적인 관리와 데이터의 액세스 최적화에 의해 성공 여부가 좌우되기 때문이다.

 

어느 시스템에서 3개월 동안 CPU 사용량이 5% 가량 증가한 경우가 있었다. 이에 현업에서는 원인을 파악하려고 나섰다. 해당 시스템은 한 달에 70GB 정도의 데이터가 증가하는 시스템이었다. 결국에는 데이터의 증가와 데이터를 액세스하는 SQL의 비효율로 결론을 지었다. 하지만 현업에서는 데이터 증가에 따른 성능 저하는 이해가 안 된다고 반론을 제기하는 사람도 있었다. 그렇다면 이러한 현상이 왜 이해가 안 되는 것일까?

 

10GB의 데이터일 경우 이상이 없었던 데이터를 액세스하는 SQL이 데이터가 30GB가 되는 순간 악성 SQL로 변할 수 있는 것이 현실이다. 왜 이런 사실을 많은 사람들이 인지하지 못하는 것일까? 아직 늦지 않았다. VLDB의 성능 관리를 수립하기 위해 가장 중요한 요소가 데이터와 데이터를 액세스하는 SQL이라는 것을 이제라도 인지하고 성능 관리 체계를 수립한다면 VLDB를 현명하게 대처할 수 있을 것이다.

 

따라서, VLDB의 성능 관리는 대용량 데이터의 관리와 데이터를 엑세스하는 SQL의 관리로 구분하여 성능 관리 체계를 구축해야 할 것이다.

 

VLDB의 대용량 데이터 관리가 성능을 좌우한다

VLDB는 대용량 데이터베이스를 의미한다고 했다. 그러므로 관리해야 할 데이터는 TB 이상이 될 것이다. VLDB에서는 대용량 데이터를 효과적으로 관리하는 방안이 반드시 필요하다. 그렇다면 어떻게 대용량 데이터를 최적화하여 관리해야 하는 것일까?

 

첫 번째로 데이터를 저장하는 테이블 관리에 대한 방안이 정립되어 있어야 한다. 데이터를 저장하는 테이블에 대해 어떠한 생각 없이 생성하는 것에 익숙해져 있는 사람이 많다. 오라클 등의 데이터베이스에서 제공하는 테이블의 종류가 많다는 것을 아는가? 업무에 따라 어떤 구조의 테이블로 구성하는가에 따라 매우 효율적으로 업무를 구현할 수 있다. VLDB에는 많은 대용량 테이블들이 존재하게 된다. 이러한 대용량 데이터의 테이블들은 어떤 구조로 저장하는가에 따라 데이터 관리 및 성능에 많은 영향을 미치게 된다.

 

예를 들어, 통신회사의 통화 내역 테이블을 생각해 보자. 통화 내역 테이블의 경우에는 하루에도 엄청난 통화 내역 데이터가 발생하게 된다. 또한, 일반적으로 데이터의 보관 주기가 정해지게 된다. 보관 주기가 6개월이라고 한다면 현재로부터 6개월이 지난 데이터는 반드시 제거해야 할 것이다. 이와 같은 속성을 가지고 있는 데이터를 일반 테이블에 저장하게 되면 보관 주기 관리도 힘들며 성능도 저하될 수 밖에 없다.

 

이러한 데이터는 오라클의 경우 파티션(Partition) 테이블에 저장해야 된다. 파티션 테이블에 저장함으로써 보관 주기 관리뿐만 아니라 월별로 파티션을 구성했다면 월별 통계 작업은 엄청난 성능 향상을 기대할 수 있을 것이다. 이처럼 VLDB의 성능 관리를 수행하기 위해 대용량 데이터를 저장하는 테이블에 대한 아키텍처 관리는 반드시 수행되어야 한다.

 

두 번째로 디스크 I/O 분산 관리이다. 디스크 I/O 분산은 많은 사람들이 디스크 제조사 또는 운영체제 담당자에게 모든 것을 의지하는 경우가 많다. 물리적인 디스크 분산은 디스크 제조사 또는 운영체제 담당자가 수행할 것이다. 하지만, 데이터베이스에 저장되는 데이터를 모든 디스크로 분산하는 방법이 데이터베이스에 별도로 존재한다. 디스크 I/O의 최적화는 물리적인 디스크 I/O 분산과 그 위에 데이터들이 고르게 저장될 수 있도록 해야 한다.

 

필자가 어느 사이트에 지원나갔을 때의 일이다. 해당 사이트는 데이터가 특정 몇 개의 디스크로만 저장되어 있었다. 물론, 디스크 개수가 적다면 여러 디스크로 데이터가 고르게 분산되도록 하는 것이 어렵지는 않을 것이다. 하지만 VLDB라면 수천 개 또는 수 만개의 디스크에 데이터를 저장하게 된다. 디스크의 개수가 많기 때문에 전체 디스크로 데이터를 고르게 분산시키는 것이 어려울 수도 있다. 하지만, 디스크 I/O 분산의 문제를 최적화하는 것만으로도 성능은 3배~5배까지 향상되는 것을 보았다. 이 얼마나 놀라운 일인가?

 

동일한 테이블을 액세스할 경우 10개의 디스크를 액세스하는 것이 응답 속도가 빠르겠는가 아니면 1만개의 디스크를 액세스하는 것이 응답 속도가 더 빠르겠는가? 당연히 동일한 테이블을 액세스하는 경우 1만개의 디스크를 동시에 액세스하는 것이 유리할 것이다. 디스크가 1만개일지라도 10개의 디스크에 저장할 수도 있으며 1만개의 디스크로 고르게 분산하여 저장할 수도 있다. 이러한 디스크 I/O 분산 또한 성능 관리에 반드시 포함되어야 할 항목일 것이다.

 

세 번째로 데이터 모델링의 관리이다. 데이터 관리 차원에서의 데이터 모델링이라는 것은 각각의 테이블에 대한 컬럼들의 관리를 뜻한다.

 

어느 사이트에 튜닝을 지원했을 때의 이야기다. 해당 사이트는 모 카드 회사였으며 카드의 기본 정보를 저장하는 마스터 테이블이 존재하고 있었다. 거래내역을 조회하기 위해서는 고객이 소유하고 있는 모든 카드 번호를 확인한 후 거래내역 테이블과 조인을 수행하고 있었다. 해당 마스터 테이블에는 해당 카드가 사용했는지, 사용하지 않았는지를 기록하는 컬럼이 존재했다. 사용을 한번도 안 한 카드라면 해당 카드 번호로 거래내역 테이블을 액세스할 필요는 없을 것이다.

 

카드 사용 유무를 기록하는 컬럼을 이용하여 튜닝을 수행하고 난 이후 성능은 10배 정도가 향상됐다. 하지만, 실무자는 카드 사용 유무 컬럼을 사용할 수 없다는 말을 했다. 그 이유는 해당 컬럼에 어떤 가맹점은 사용 유무를 기록하지만 어떤 가맹점은 사용 유무를 기록하지 않기 때문에 카드 사용 유무 컬럼에 사용하지 않음이라고 되어 있더라도 해당 카드는 사용했을 수 있다는 것이다. 이 얼마나 어처구니 없는 일인가? 이런 사실을 실무자는 너무 자신 있게 이야기했다. 자신 있게 이야기하기 보다는 오히려 부끄러워해야 하는 것은 아닐까?

 

그런 이유에서 해당 테이블의 모든 컬럼을 확인하게 되었다. 해당 테이블에는 50개의 컬럼이 존재했지만 그 중 15개의 컬럼이 사용하기 힘든 상태였다. 이러한 컬럼을 왜 저장하고 있는지 모르겠다. 데이터의 정합성을 유지하기 힘든 컬럼들을 없앤다면 데이터는 감소한다. 이러한 컬럼들에 대해 데이터의 정합성을 맞추어 관리한다면 위와 같이 애플리케이션 성능을 향상시킬 수 있는 요소로 이용할 수 있을 것이다.

 

독자 여러분도 자신이 현재 관리하는 VLDB를 한번 확인해 보길 바란다. 진정으로 모든 테이블의 데이터를 다 사용하고 있는가? 분명 그렇지 않은 곳이 여기저기 존재할 것이다. 이는 VLDB에 대한 데이터 모델링 관리를 통한 성능 관리가 수행되지 않고 있기 때문이다.

 

대용량 데이터 관리를 위한 위의 세가지 요소는 시간과 비용이 많이 소요되는 항목들이다. 그렇기 때문에 프로젝트 초기부터 관리되어야만 VLDB의 성능 관리가 성공할 수 있다. 이러한 항목이 관리되지 않는다면 머지 않아 후회스러운 일이 발생할지도 모른다.

 

성능관리 핵심은 데이터를 엑세스하는 SQL이다

VLDB의 성능 관리는 데이터 관리와 함께 해당 데이터를 액세스하는 SQL의 관리이다. 많은 서적들을 참조해 보면 시스템을 최적화함에 있어 서버 튜닝 또는 데이터베이스 엔진 튜닝으로 얻을 수 있는 성능 향상은 전체 향상될 수 있는 부분의 10% 정도의 향상이 기대된다고 한다. 그렇다면 어떤 부분을 최적화 했을 때 나머지 90%의 효과를 얻을 수 있는 것일까? 그것은 바로 애플리케이션이다. 애플리케이션 중에서도 데이터를 액세스하는 부분인 SQL이 이에 해당된다. 애플리케이션에 사용되는 로직 또한 중요하다. 하지만 애플리케이션에 사용하는 로직이라는 것도 SQL에서 추출한 데이터를 조작하는 단계이기 때문에 여기서 말하는 데이터를 액세스하는 SQL이라는 것은 이러한 액플리케이션의 로직을 포함하는 것이다. 그렇다면 SQL의 어떤 항목을 통해 성능 관리를 수행해야 하는가?

 

첫 번째로 SQL 및 SQL의 실행 계획에 대한 계속적인 추적이 필요하다. 실행 계획이라는 것은 무엇인가? 우리가 서울역에서 분당까지 가기 위해 어떻게 가는 것이 빠른가? 여러 번의 경험이 있는 사람이라면 최적의 방법을 이용하여 목적지에 도착할 것이다. 하지만 처음 서울역에서 분당으로 가는 사람이라면 어떨까? 전철을 이용할지, 버스를 이용할 것인지 또는 버스와 전철을 동시에 이용하는 것이 적합한지 애매한 경우가 있다.

 

이러한 경우에도 서울역에서 분당까지 가고자 하는 그 사람의 의지가 중요할 것이다. SQL의 실행 계획도 이와 별반 다르지 않다. 인덱스를 이용하여 데이터를 추출할 것인지 또는 테이블을 전체 스캔하여 데이터를 추출할 것인지는 실행 계획을 생성하는 옵티마이저에 의해 결정된다. 이러한 실행 계획에 의해 동일한 데이터를 추출하는 SQL은 1분이 1시간으로 응답 속도가 저하될 수 있다. 최적화되어 수행된다면 1분이면 종료될 SQL이 악성 SQL로 수행되어 1시간이 소요된다면 이는 응답 속도의 저하뿐만 아니라 CPU 사용량도 증가시키게 된다.

 

결국, 이러한 실행 계획이 관리되지 않는다면 악성 SQL이 계속적으로 증가되어 CPU 사용량은 계속 높아만 질 것이다. 이 것이 해당 시스템의 CPU를 증설하게 되는 주범이라는 것을 눈여겨볼 필요가 있다.

 

결과적으로 VLDB의 성능 관리를 수행하기 위해서는 해당 VLDB를 액세스하는 SQL과 해당 SQL의 실행 계획을 반드시 추적하고 있어야 한다. 이와 같이 SQL과 SQL의 실행 계획을 추적해야 하는 또 하나의 이유가 존재한다. 그 이유는 SQL의 실행 계획이 변할 수 있기 때문이다. 서울역에서 분당을 갈 때 매번 버스를 이용하였지만 하루는 비가 많이 내렸다고 가정하자. 비가 많이 내린다면 버스는 일반적으로 정체 구간이 많이 발생한다.

 

그래서 이럴 경우에는 반대로 전철을 이용하여 분당에 갈수도 있을 것이다. 실행 계획 또한 이와 동일하다. 데이터베이스에 큰 변화가 발생한다면 언제든지 이러한 실행 계획은 변할 수 있다. 실행 계획이 변하면 SQL의 응답 속도가 향상될 수도 있지만 대부분 응답 속도가 저하되기 쉽다. 오라클의 경우 데이터베이스를 업그레이드 하게 되면 성능과 관련된 SQL의 실행 계획을 재점검해야 한다. 이 또한 데이터베이스의 큰 변화이므로 실행 계획이 변할 수 있기 때문이다. 급격히 데이터가 증가하는 것 또한 데이터베이스에 수많은 변화가 발생할 여지가 있게 마련이다. 이제 VLDB의 성능을 관리하고자 한다면 반드시 데이터를 액세스하는 SQL과 SQL의 실행 계획을 관리해야 한다.

 

두 번째로 SQL이 사용하는 인덱스의 관리이다. 이는 일반 데이터베이스에서도 동일하지만 VLDB에서는 매우 중요한 성능 관리 항목이다. 인덱스라는 것은 조회 성능을 향상시키기 위해 생성하게 된다. 인덱스는 데이터의 제거, 변경 및 저장에 대해서는 성능 저하를 발생시킨다. 단지, 조회를 위해 효율적으로 이용할 수 있는 것이 인덱스이다. 또 하나 고려할 것은 SQL이 인덱스를 이용했다고 해서 SQL이 최적화된 것이 절대 아니라는 것이다.

 

처리 범위를 최소화시킬 수 있는 인덱스를 이용한 것이 아니라면 해당 인덱스를 이용함으로써 응답 속도는 저하된다. 이러한 사실을 모르는 관리자 또는 개발자들이 많다는 것이 때로는 필자를 슬프게 만든다. 단지, SQL이 인덱스를 이용했다는 이유 하나만으로 최적화 되었다고 생각하지 말자. 이러한 생각은 VLDB를 최악으로 만드는 장본인이라는 것을 인지해야 할 것이다.

 

프로젝트 초기에는 인덱스의 생성 및 삭제가 가능할 수 있지만 시스템을 오픈하여 서비스를 하고 있다면 인덱스를 추가하거나 또는 삭제하는 것이 매우 힘들다. 그 이유는 인덱스를 생성하기 위해 많은 시간이 소요되고 생성하는 동안은 해당 테이블에 대해 서비스를 제공할 수 없기 때문이다. 또한 인덱스를 추가함으로써 다른 SQL에 어떤 영향을 미칠지 아무도 장담할 수 없기 때문이다. 전혀 다른 인덱스를 이용하게 됨으로써 발생하는 성능 저하는 해당 시스템을 마비시킬 수도 있다.

 

위와 같은 이유들로 VLDB의 대용량 테이블에 대해서는 프로젝트 초기부터 인덱스에 대한 전략과 운영 시 관리 방안 등이 수립되어 진행되어야만 성능 관리를 수행할 수 있다. 이러한 VLDB에서 인덱스의 관리가 수행되지 않는다면 건너서는 안 되는 강을 건너는 것과 같이 VLDB의 성능 저하에 대해 되돌릴 수 없는 상황이 된다.

 

세 번째로 VLDB에 대해 매일 또는 매주 I/O가 많은 SQL을 수집해야 한다. 이러한 일련의 활동은 VLDB의 성능 관리를 위해 반드시 필요한 단계이다. SQL은 데이터를 액세스하는 언어이며 데이터를 엑세스하기 때문에 I/O가 발생하게 된다. 이러한 I/O가 메모리에서 발생하던 또는 디스크에서 발생하던 I/O의 양이 많다면 성능은 반드시 저하된다. I/O를 많이 발생시키는 SQL의 수집은 VLDB의 성능 관리를 위한 많은 정보를 제시해 준다.

 

예를 들어, 해당 VLDB 시스템의 CPU 사용량이 갑자기 10%가 높아졌다고 가정하자. 이런 경우 서버 및 데이터베이스를 확인할 것이다. 이런 일련의 확인 작업을 수행한 후 아무런 문제가 없다면 무엇을 확인해야 하는가? 바로 I/O가 많은 SQL을 검토해야 한다. 십중팔구 데이터의 증가와 함께 I/O가 많은 SQL에 의해 이러한 CPU 사용량이 증가했을 것이다. 데이터베이스는 별도의 툴을 이용하지 않는다면 이러한 I/O가 많은 SQL을 저장하지 않게 된다. 단지, 실시간으로 I/O가 많은 SQL을 추출할 수 있다.

 

따라서, I/O가 많은 SQL에 대해서는 반드시 수집하는 스크립트 등을 작성하여 정해진 시간에 수행되게 해야 할 것이다. 이것이 VLDB의 성능 관리의 중요한 요소이자 또한 장애 관리에도 많은 도움이 될 것이다. 성능과 장애는 분리할 수 없는 관계에 있다. 이러한 I/O가 많은 SQL이 성능을 저하시키고 이것은 장애로 연결되기 때문이다.

 

앞에서 확인한 것과 같이 VLDB에서 SQL에 대한 관리는 성능 관리에 있어 중요한 요소가 된다. 그러므로 데이터를 액세스하는 SQL, SQL의 실행 계획 및 인덱스에 대한 관리 방안이 반드시 필요하다. 또한, I/O가 많은 SQL의 수집은 성능 관리를 하기 위한 기본이 될 것이다. 수집된 데이터를 바탕으로 분석을 수행하여 성능 관리를 수행해야 할 것이다.

 

성능 관리는 데이터 수집, 분석 반복되어야

VLDB의 성능 관리는 데이터 관리 및 데이터를 액세스하는 SQL의 관리에 대한 정확한 방안이 수립되어야 한다. 성능 관리는 성능 데이터의 수집부터 시작하게 된다. 성능 데이터가 수집된다면 내용을 분석하여 튜닝을 수행하게 된다. 정확한 분석을 통해 튜닝을 수행한다면 해당 VLDB는 성능 관리를 위한 1사이클(Cycle)이 종료될 것이다. VLDB의 성능 관리는 여기서 끝이 아니다. 이러한 사이클이 반복해서 수행되어야 한다는 것이다. 1년간 이러한 성능 관리 활동을 수행했다고 VLDB가 계속 최적화된다는 보장은 없다. 해당 시스템이 업무를 종료하는 그 날까지 성능 관리는 매일 수행되어야 한다. 이 것이 VLDB의 운명은 아닐까?

 

VLDB의 성능 관리에서 또 하나의 중요한 항목은 사람이다. 성능 데이터 수집은 방안만 수립된다면 간단한 작업일 것이다. 하지만 이러한 성능 데이터 수집 방안을 수립하고 추출된 성능 데이터를 분석하기 위해서는 많은 부분에서 사람이 관여할 수 밖에 없다. 사람이 관여해야 하기 때문에 중요하다는 것은 아니다.

 

다른 분야도 그렇겠지만 VLDB의 성능 관리는 담당자의 실력에 의해서 성공과 실패가 좌우된다. 이제라도 VLDB를 위한 성능 관리 전문가를 육성해야 할 시기라는 것을 이해하길 바란다.

 

 

필자소개
SKC&C에서 DBA를 수행하면서 여러 프로젝트에서 DB 아키텍처, 모델링, 튜닝을 담당하고 있다. 특히 DB 성능관리 문제가 발생하는 프로젝트를 처리하는 데 역점을 두고 있다. 저서로는 <Perfect 오라클 실전 튜닝>과 <초보자를 위한 오라클10g>가 있다.

 

 

제공 : DB포탈사이트 DBguide.net