Admin::VLDB성능관리#1

 VLDB성능관리#2

VLDB와의 소리 없는 전쟁
- 대용량 DB의 개념 및 발생 환경 -

 

VLDB는 Very Large Database의 약자이다. 결국, VLDB는 매우 큰 데이터베이스를 뜻하며 이는 대용량 데이터베이스를 의미한다. 대용량 데이터베이스라는 말은 1990년대부터 나왔던 용어이다. 그 당시는 100GB 정도의 데이터만 되어도 대용량 데이터베이스라고 했었다. 하지만 이제는 100GB 정도의 데이터베이스를 대용량 데이터베이스라고 부르는 사람은 한 명도 없을 것이다.

 

글 _ 권순용｜kwontra@hanmail.net

 

 

IT시장도 세월이 흐르면서 대용량 데이터베이스에 대한 기준이 바뀌고 있다. 객관적인 기준은 없지만 필자는 대용량 데이터베이스를 GB 단위의 데이터베이스가 아닌 TB 단위의 데이터베이스라고 정의하고 싶다. 이번 호에서는 VLDB의 개념과 VLDB에서 발생하는 현상에 대해 알아 보도록 하겠다.

 

 

21세기 IT의 재앙은 VLDB인가?

언론에서 작년 말에 모 통신 회사의 가입 고객이 2,000만 명을 넘어섰다고 발표했다. 그것은 무엇을 의미하는 것일까? 이런 내용을 언론을 통해 알고 나면 습관처럼 계산하는 것이 하나 있다. 바로 데이터의 크기에 대한 계산이다. 2,000만 명이 하루에 다섯 통화씩 한다고 가정하면 하루 1억 건의 통화 데이터가 발생하게 되며 한 달에 30억 건의 데이터가 쌓이게 된다.

 

통화 데이터는 법적으로 보관해야 하는 개월 수가 정해져 있기 때문에 6개월을 보관한다고 가정하면 180억 건의 데이터가 쌓이는 대용량 테이블이 될 것이다. 이렇다면 해당 시스템은 누구나 VLDB라고 부르게 될 것이다. 또 하나의 예를 들어보자. 어느 카드 회사의 고객이 1,000만 고객이라고 가정하자. 카드 고객이 하루에 한번씩 사용한다고 가정하면 하루 발생 데이터는 1,000만 건이 된다. 한 달이면 3억 건의 데이터가 된다. 이 또한 어느 누가 VLDB라고 부르지 않겠는가?

 

예전에는 상상할 수 없었던 이러한 VLDB들이 현재는 흔하게 생겨나고 있다. 특히, 회사들의 DW 시스템은 해당 회사에서 발생하는 대부분의 데이터를 취합하기 때문에 거의 대부분 VLDB가 된다. 시대가 변화면서 우리 일상에는 많은 변화가 발생했다. 우리의 눈에는 보이지 않지만 시대가 변함으로써 변경된 것 중에 하나가 VLDB의 탄생이다.

 

데이터베이스가 VLDB로 다시 태어나는 순간 우리에게는 예상치 못한 일들이 발생하게 된다. 응답 속도 저하, 장애 증가, 백업과 복구 시간의 증가, 비용 증가 및 일반 작업 시간 증가 등의 현상이 발생하게 된다. 발생하는 현상들을 보면 데이터베이스가 VLDB로 변경되는 순간 악영향만 있을 뿐 좋아지는 현상은 없다. 데이터의 증가는 시스템적인 면에서는 어떠한 장점도 제공하지 않게 된다. 단지, 데이터의 증가에 의한 VLDB는 우리에게 해결해야만 하는 쉽지않은 과제만을 남기게 되었다.

 

수많은 회사들이 지금 VLDB에 대한 고민을 하고 있다. 해결 방안을 찾으려고 갖은 노력들을 하고 있는 것을 지켜보기도 했다. 하지만 데이터와 데이터베이스의 이해도가 부족한 사람들이 VLDB의 해결 방안을 찾고 있었다면 과연 VLDB의 해결 방안을 찾을 수 있을까? 필자는 데이터와 데이터베이스를 이해하는 사람이 그러한 방안을 찾아야 한다고 생각한다.

 

이러한 VLDB의 문제점에 대한 해결 방안을 찾지 못한다면 몇 년이 지나지 않아서 큰 문제를 발생시킬 것이다. 최악의 경우에는 해당 회사의 존재 유무에 영향을 줄 수 있을 것이다. 그렇게 된다면 이것이 21세기 IT의 재앙이 아니고 무엇이겠는가? VLDB가 발생시킬 수 있는 재앙에 대해 미리 준비하고 최적화해야 할 시간이 별로 많이 남아 있지 않다. VLDB의 재앙을 극복하는 회사가 결국 사업을 영속적으로 이끌어 갈수 있으리라 생각한다.

 

 

데이터는 운영 데이터와 이력 데이터로 구분된다

VLDB를 이해하기 위해서는 데이터베이스에 존재하는 데이터의 속성을 이해해야 한다. 데이터의 속성을 이해해야 VLDB에서 관리해야 할 데이터를 이해할 수 있을 것이다. 운영 중인 데이터베이스의 데이터는 운영 데이터와 이력 데이터로 구분할 수 있다.

 

운영 데이터는 실제 운영에 필요한 메타 데이터에 해당된다. 예를 들어, 카드 회사의 카드 마스터 테이블이라는 것이 존재한다고 가정하자. 신규 카드를 만들게 되면 해당 테이블에 한 건씩 데이터가 저장된다. 이렇다면 결국 해당 테이블의 총건수는 카드 회사에서 발급한 카드의 건수와 동일할 것이다. 어느 카드 회사가 1,000만 고객이라고 한다면 해당 테이블은 1,000만 건이 될 것이다.

 

그럼 카드 회사의 카드 마스터 테이블이 급격하게 증가할 수 있는가? 일반적으로 하루에 몇 천만 건씩 증가하지는 않을 것이다. 몇 천만 건이 아니라 몇 만 건도 증가 하지 않을 것이다. 통신 회사의 예를 들어 보자. 통신 회사에서 가입 고객의 수가 하루에 얼마나 늘어날까? 통계에 따르면 통신사별로 순수 증가 가입자가 한달 평균 10만 명 정도인 것으로 나타나고 있다. 한 달에 10만 건의 데이터가 발생하는 것은 그렇게 많은 데이터는 아닐 것이다. 카드 회사의 카드 마스터 테이블 또는 통신 회사의 가입 고객 테이블은 운영을 위한 기초 데이터를 가지고 있다.

 

논리 모델링시 키 엔티티(Key Entity)로 도출되는 테이블들이 운영 데이터의 역할을 수행하게 된다. 논리 모델링시 도출되는 운영 데이터를 보관하는 키 엔티티는 데이터베이스를 VLDB로 만드는 어느 정도의 역할은 수행하더라도 데이터베이스를 VLDB로 변경하는 근본적인 역할은 수행하지 않게 된다.

 

이력 데이터는 키 엔티티에 의해 발생하는 데이터에 해당될 것이다. 이를 논리적 모델링에서는 액션 엔티티(Action Entity)라고 한다. 예를 들어 카드 회사의 거래내역 테이블을 생각해보자. 거래내역 테이블의 데이터는 앞서 언급한 카드 마스터에 있는 각각의 카드에 의해서 만들어 지는 데이터이다. 거래 내역 테이블에는 각 카드가 사용한 데이터가 저장되며 하나의 카드는 하루에 여러 건의 데이터를 만들어낼 수 있다.

 

따라서 카드 회사의 거래내역 테이블은 대용량 테이블로 만들어질 것이다. 어디 이 뿐인가? 일반적인 거래내역 테이블은 일정 기간의 거래 내역을 보여주기 위해 과거의 데이터도 보관하고 있다는 것이다. 따라서 거래 내역 테이블의 크기는 상상을 초월하는 크기가 될 것이다. 이러한 카드회사의 거래 내역 테이블 뿐만 아니라 통신회사의 통화 내역 테이블도 동일하다. 통화 내역 테이블 역시 가입 고객에 의해 발생하는 논리 모델링에서 액션 엔티티에 해당된다.

 

통화 내역 테이블에는 가입 고객이 사용한 하나의 통화에 대해 하나의 데이터가 저장된다. 또한 통화 내역 테이블은 이력을 관리해야 하기 때문에 대용량 테이블로 탄생할 것은 명백한 사실일 것이다. 결국, 논리적 모델링에서 액션 엔티티로 표현되며 이력 데이터를 저장하는 테이블들이 데이터베이스를 VLDB로 만드는 주범일 것이다.

 

데이터의 증가와 응답 속도는 반비례 관계인가?

데이터베이스가 VLDB로 변하면서 발생할 수 있는 첫 번째 영향이 응답 속도이다. 일반적으로 데이터가 증가하면 응답 속도는 저하되기 쉽다. 이력 데이터가 1억 건이였을 경우 조회 쿼리의 응답속도가 1초였다고 가정하자.
이러한 이력 데이터가 2억 건이 된다면 이전 응답 속도인 1초 만에 해당 쿼리가 수행되기에는 힘들 것이다. 쿼리의 응답 속도는 디스크 블록 엑세스의 양과 밀접한 관계를 가진다.

 

디스크 블록 엑세스가 적다면 전체 데이터가 몇 건인가에 관계 없이 응답 속도를 보장 받을 수 있다. 하지만 데이터가 증가한다는 것은 엑세스해야 하는 디스크 블록의 증가를 암시하고 있다. 따라서 데이터 증가와 응답 속도 저하는 완전한 반비례 관계는 아니지만 VLDB에 대한 준비가 없다면 데이터 증가에 따라 응답 속도는 반비례 관계로 저하될 것이다.

 

예를 들어, 어느 통신회사의 통화 내역 테이블을 보자. 시대의 흐름에 따라 개인마다 한 대 이상의 휴대폰을 소지하면서 가입자가 증가하게 되었다. 가입자들은 개인적인 일뿐만 아니라 회사일 때문에도 많은 통화를 하게 된다. 이러한 한 통화 한 통화가 해당 통신 회사의 통화 내역 테이블에 저장된다. 통신 회사 가입 회원이 1,000만 명이라고 가정하자. 한 사람이 하루에 다섯 통화만 하게 되면 하루 데이터 량은 5,000만 건에 육박하게 된다. 또한 최근 6개월 전 통화 내역까지 고객에게 조회 가능하게 한다고 가정하자. 그렇다면 대용량의 통화 데이터가 생성될 것이다. 초기에는 특정 번호로 통화 내역 데이터를 엑세스하면 1초가 소요되었다고 가정하자.

 

그러나 계속적으로 가입자가 증가하게 되면 가입자들에 의해 발생하는 통화 데이터는 기하급수적으로 증가될 수 있다. 그렇다면 기존 쿼리의 응답 시간이 데이터의 증가에도 불구하고 1초가 유지될 것인가? 정답은 VLDB에 대한 최적화된 준비가 되어 있지 않다면 응답 속도는 저하된다는 것이다.

 

데이터의 증가는 증가된 데이터와 관련된 프로그램의 응답 속도를 저하시키는 것은 당연할 수 있다. 증가하는 데이터에 대해 어떠한 고려도 없다면 해당 시스템의 프로그램들은 점차 응답 속도가 저하되게 된다. 이를 해결하기 위해서는 기존 VLDB에 대한 성능 관리 고도화 및 새로 탄생하는 VLDB에 대한 최적화된 관리 방안 수립이 필요할 것이다.

 

VLDB에서 비용 증가는 왜 계속 되는가?

대부분의 회사에서는 매년 말 또는 매년 초 관리하고 있는 시스템에 대한 용량 증설을 계획한다. 용량 증설에는 보통의 경우 CPU, 메모리 및 디스크가 대상이 된다. 이러한 용량 증설을 위해 과연 무엇을 검토하는가? 용량 증설을 하기 위해서는 많은 데이터를 기초 데이터로 하여 용량 증설을 하게 된다.

 

CPU 용량 증설에 대한 기준은 보통의 경우 CPU 사용률이 된다. 디스크의 용량 증설의 기준은 현재 디스크 사용률과 데이터 증가량이다. 마지막으로 메모리 증설의 경우는 CPU 증설에 따라 결정되는 것이 보편적인 방법일 것이다.

 

필자가 지원했던 곳 중에 VLDB에 대해 매년 용량 증설로 10억 원 이상의 비용이 소요되고 있는 곳이 있었다. 그렇다면 막대한 비용이 매년 소요되는 용량 증설은 어쩔 수 없는 현상인가? 필자는 이 질문에 대해 아니라고 말하고 싶다. 이러한 비용이 적절하게 사용되는 부분도 있겠지만 어느 정도는 잘못 투자되는 부분도 존재한다고 생각한다.

 

CPU 사용률에 의해 CPU와 메모리가 증설된다. 중요한 점은 CPU 사용량만 보고 증설을 한다는 것이다. CPU 사용률이라는 것이 무엇인가? VLDB에서는 악성 SQL이 하나 수행되면 CPU 사용률은 많이 높아지게 된다. 그런 악성 SQL이 몇 개 수행된다면 해당 시스템은 용량 증설 대상이 될 것이다. 이런 이유에서 CPU 사용률이 높아진 시스템이 CPU 증설 대상이 되어야 하는 것인가? 시스템 관리자도 이러한 사실을 잘 인지하지 않고 있는 현실이 필자로서는 너무 아쉽다.

 

이런 악성 SQL을 최적화한다면 해당 VLDB 시스템은 CPU 사용량이 감소하게 된다. 그렇다면 CPU 또는 메모리 증설 비용이 추가되지 않을 수도 있을 것이다. 또한 배치 작업을 최적화하고 디스크 I/O 분산을 최적화한다면 이 또한 CPU 사용량이 감소하게 된다. 왜 이런 근본적인 문제를 해결하려 하지 않고 CPU와 메모리를 추가하려 하는가? 이와 같이 CPU 사용량만 보고 용량 증설을 한 시스템은 매년 이유도 모르고 용량 증설을 계속하게 마련이다.
이 얼마나 무서운 일인가? 필요한 용량 증설에는 비용을 투자해야 하는 것이 맞다. 하지만 VLDB에서 종종 발생하고 있는 잘못된 용량 증설에 의한 비용은 회사의 발전을 위해 사용해야 하는 비용을 엉뚱한 곳에 사용하고 있는 셈이다.

 

디스크 증설은 디스크 사용률과 데이터 증가량에 의해 결정된다. VLDB는 보통의 경우 대용량 이력 데이터의 증가로 용량을 증설하게 된다. 이러한 디스크 용량 증설이 반드시 필요한 것일까? 필요할 수도 있고 아닐 수도 있다. 집의 평수가 10평일지라도 이를 30평처럼 효과적으로 사용하는 사람이 있는가 하면, 30평에 살고 있어도 거의 10평 남짓한 집처럼 사용하는 사람이 있다.

 

VLDB의 디스크도 이와 별반 다르지 않다. 10TB의 VLDB가 진정한 10TB의 VLDB인지는 아무도 모른다.

 

요즘은 대부분의 데이터베이스 업체에서 데이터 압축 기술을 제공하고 있다. 이를 잘 이용한다면 10TB의 데이터가 5TB의 데이터로 변할 수 있는 것이 현실이다. 또한 데이터베이스의 특성 때문에 잘못 이용하여 불필요하게 낭비되는 공간도 있을 수 있다. 중요한 점은 논리적 모델링에서 정규화가 잘못되면 데이터는 기하급수적으로 증가하게 되며 인덱스 선정을 잘못하면 응답 속도 저하뿐만 아니라 엄청난 디스크를 사용하게 된다.

 

데이터베이스를 잘못 구성하고서 디스크가 부족하다는 이유로 디스크를 증설하는 것이 옳은 일인가? 이런 잘못된 데이터베이스 아키텍쳐와 논리적 모델링을 최적화하지 않는 한 해당 VLDB는 매년 대규모의 디스크를 증설해야 할 것이다.

 

VLDB에 대해 용량 증설을 하는 과정을 보면 필요한 부분에 대한 용량 증설을 하는 경우도 많지만 주먹 구구식으로 용량 증설을 하는 경우도 흔하다. 이런 경우 필자가 보기에는 귀찮아서가 아니라 VLDB에 대한 이해가 부족하기 때문에 발생하는 현상인 것 같다. 더 이상 VLDB를 간과할 수 없는 것이 대다수 기업의 현실이다. 체계적인 용량 증설에 대한 이해가 없다면 VLDB에 대한 용량 증설은 그 회사의 비용을 계속적으로 발생시키게 된다.

 

VLDB의 데이터 백업과 복구는 불가능 한가?

VLDB에 대해 데이터베이스가 너무 크기 때문에 백업 시간이 많이 소요되므로 업무에 지장을 초래한다는 얘기가 있다. 이는 백 번 맞는 말이다. 왜냐하면 백업을 수행하는 동안은 데이터베이스의 성능이 저하되기 때문이다. 그렇다고 VLDB여서 백업을 수행하지 못한다는 것은 이해되지 않는 말이다.

 

또한 VLDB는 장애 시 복구가 힘들 수 있지만 복구를 못하는 것은 아니다. 그렇다면 이러한 VLDB에 대한 백업과 복구에 대한 전략은 누가 수립해야 하는가?

 

어느 회사를 지원했을 때 필자가 경험했던 일이다. 그 회사는 시스템 관리자와 DBA 및 백업 관리자가 분리되어 있었다. VLDB에 대한 백업과 복구에 대한 전략을 개발자 또는 시스템 관리자가 수립하지는 않을 것이다. 그렇다면 백업 관리자인가? 이 또한 아닐 것이다. VLDB에 대한 백업과 복구에 대한 전략은 반드시 데이터베이스와 데이터를 이해하는 담당자가 계획하고 수행해야 한다는 사실이다. 데이터베이스의 아키텍쳐와 데이터의 구조를 모르는 백업 관리자가 어떻게 백업과 복구에 대해 전략을 세울 것인가? 필자가 지원했던 그 회사는 데이터베이스와 데이터를 이해하지 못하는 백업 관리자가 VLDB에 대한 백업과 복구의 모든 전략 및 계획을 수립했기 때문에 힘들어 하지 않았나 생각한다.

 

데이터베이스는 여러 가지 방법으로 데이터 백업을 지원한다. 어떤 데이터베이스는 데이터 증감 분에 대해 백업을 수행할 수 있게 해준다. 어떤 데이터베이스는 변경 작업이 발생하지 않는 데이터에 대해서는 한번 백업을 수행한 백업 본으로 언제든 복구를 수행할 수 있게 기능을 제공한다.

 

또 어떤 데이터베이스는 단순 파일 복사로만 백업을 대신할 수도 있다. 그리고 대부분의 데이터베이스는 데이터를 저장하고 있는 테이블 단위로 백업을 수행할 수 있게끔 기능을 제공하고 있다.

 

이렇게 다양한 방법의 백업방법이 제공되고 있지만, 이러한 방법을 효과적으로 이용하지 않고 전체 데이터에 대해 백업을 수행하는 경우를 자주 보아 왔다. 이렇게 전체 데이터를 매일 백업 받기 때문에 백업 시간이 많이 소요되고 이에 따라 시스템 성능 저하가 발생하게 되므로 백업을 수행하지 못한다는 얘기를 들을 때가 있다. 이 어찌 백업을 못 받는 것인가? 백업을 안 받는 거라고 해야 되지 않을까?

 

전체 데이터를 백업 받은 것으로 복구를 수행하는 경우는 그리 흔한 일은 아니다. 하지만 전체 데이터를 복구할 수 있는 백업은 반드시 백업 전략에 포함되어야 한다.

 

VLDB에서 전체 데이터를 복구하는 것은 데이터가 많기 때문에 당연히 많은 시간이 소요될 것이다. 하지만 전체 데이터베이스를 복구해야 하는 상황은 거의 발생하지 않는다. 보통의 경우 테이블스페이스 단위이거나 오브젝트 단위가 흔하게 발생하게 된다. 이런 방향으로 VLDB 복구 전략이 수립되고 복구를 수행한다면 빠르게 복구를 수행할 수 있을 것이다.

 

VLDB는 백업도 어렵지만 복구도 어려운 것이 사실이다. 하지만 데이터베이스에서 제공하는 많은 기능들을 효과적으로 사용하고 데이터의 감소를 성공적으로 달성하여 최적화된 백업 및 복구 전략을 수립할 수 있다면 VLDB의 백업과 복구가 어렵지 만은 않을 것이다. 이런 준비 없이 VLDB를 운영한다면 언젠가는 눈물을 흘리는 날이 올 것이다.

 

데이터가 증가함에 따라 일반적인 운영에 소요되는 시간은 증가하게 된다. 운영에 소요되는 시간이 증가하는 것이 문제인 것은 아니다. 오히려 문제는 운영에 필요한 많은 작업이 서비스 정지 시간을 필요로 한다는 사실이다. 이러한 서비스 정지 시간이 필요한 운영 작업이 데이터의 증가에 따라 소요시간이 증가되므로 서비스 정지 시간도 증가하게 될 것이다.

 

대부분의 업무 관리자들은 시스템이 무정지 시스템으로 운영되길 원한다. VLDB는 이러한 무정지 시스템을 구현하기 위한 제약 조건에 해당된다. 대용량 테이블에 인덱스를 하나 생성하는 것 조차 VLDB는 힘들 수 있다. 하지만 우리가 앞서 언급한 문제점들을 제거하는 과정을 거치게 되면 데이터는 감소하게 된다. 또한 데이터베이스에서 제공하는 수 많은 VLDB에 최적화된 기능을 사용한다면 서비스 정지 시간을 없애거나 감소시킬 수 있을 것이다.