데이터베이스 분야에서 필자가 많이 들었던 이야기들 중에는 다음과 같은 것들이 있다.

• - 개발서버에서 사용자가 DML 구문을 잘못 수행하는 경우가 있어 쓸데없이 그것을 복구하는 데 시간을 많이 보낸다. 더욱이 며칠이 지난 다음에야 그것을 복구해달라고 하는 경우가 있어 난감하다.
• - 악성 SQL 수행으로 부하가 너무 커져서 데이터베이스는 물론 서버에도 접속이 잘 되지 않고 매우 느리다
• - 주말에 갑자기 실행계획이 변경돼 전화를 받고 주말에 출근했다.
• - 계정 Lock이 한 번씩 걸린다.
• - 평소에 잘 수행되던 작업이 갑자기 제 시간에 끝나지 않았다.

이 글에서 필자는 세 가지 관점의 지식을 이야기하고자 한다. 첫 번째는 ‘모니터링’, 두 번째는 ‘프로세싱’, 세 번째는 ‘저장’이다. 이 세 가지를 이야기하기 전에 가장 중요한 것은 무엇일까?

그것은 바로 ‘내가 하고자 하는 목표’이다. ‘목표를 세우면 목표가 나를 이끈다’라고 하듯이 목표가 있다면 ‘어떻게 해야 하지? 프로그램을 짜야 하나? 어떤 화면을 봐야 하나?’ 등의 방법론적인 문제는 자연스럽게 조금씩 해결될 것이다.

목표에는 어떤 것이 있을까? ‘지난 주 새벽에 수행되던 배치 작업이 제 시간에 끝나지 않아 식은땀을 흘린 적이 있지. 이제부터는 주기적으로 수행되는 이 작업이 새벽 5시 이전에 끝나지 않으면 담당자가 알 수 있도록 문자나 메일을 보내도록 하자’ 등 여러 가지 목표를 세울 수 있다. 목표들은 내가 해야 할 일 혹은 관심 대상이 되는 것들로 이뤄져 있을 것이다.

모니터링에 대한 고려

첫 번째로 모니터링에 대해 이야기해보자. 실시간 모니터링의 대상과 주기적인 모니터링의 대상, 그리고 특정 이벤트 발생 시의 모니터링 대상이 있다.

‘내가 목표로 하는 것이 실시간 모니터링이 돼야 하는가? 주기적으로 모니터링돼야 하는가? 특정 이벤트 발생시에 모니터링이 돼야 하는가?’ 이것을 결정하고 내가 원하는 정보를 얻을 수 있도록 방법을 세우면 될 것이다.

각각의 목표에 따라 모니터링 방법이 달라질 것이다. 지금도 데이터베이스에서 지원하는 로그 파일이나 테이블, 기능들을 통해 우리가 원하는 대로 실시간이나 주기적, 그리고 특정 이벤트 발생 시의 모니터링이 가능하다.

데이터베이스에서 지원하는 테이블이나 로그파일 정보들을 보면 내가 목표로 한 것에 대한 정보는 여기저기 흩어져 있거나 쉽게 바로 볼 수 있도록 되어 있지는 않다. 그것을 가공해 내가 원하는 정보를 빠르고 간단하게 볼 수 있도록 해야 한다.

하지만 어떤 테이블을, 어떤 기능을 이용해 봐야 할 것인가는 기술적인 문제이므로 큰 문제는 아니다. 중요한 것은 내가 원하는 목표를 이루기 위해서 어떤 정보가 필요하다는 것에 대한 정의이다.

계정이 잠기는 문제점에 대한 경우를 생각해 보자.

계정 락이 걸려 잠기는 원인은 지정된 횟수 내에 로그인하지 못했을 경우, 암호의 수명이 지났을 경우, 지정된 실패 횟수를 초과했을 경우 등이 있다.

나의 목표가 ‘비밀번호 입력이 세 번 이상 틀렸을 경우 해당 유저에게 통보하고 정상적인 접근시도였다면 비밀번호 실패 횟수를 초기화하고 비밀번호 실패 이유가 비정상적인 사용자의 접근시도였다면 보안 담당자에게 통보하는 것’이라면 모니터링 대상은 데이터베이스 계정의 비밀번호 실패 횟수와 데이터베이스 계정 로그인을 시도하는 사용자가 될 것이다.

프로세싱에 대한 고려

두 번째로 프로세싱에 대해 이야기해보자. 프로세싱의 방법에서는 자동화를 통한 즉시적인 문제 해결이 가능할 수도 있고 자동화를 통한 문제 해결이 힘들거나 불가능할 경우에는 이메일, SMS 등 여러 가지 매체를 통해 즉시 경고문을 발송할 수도 있으며 단지 로그만을 남길 수도 있다.

각각의 목표와 모니터링 결과에 따라 처리할 수 있는 방법은 여러 가지가 존재한다. 모든 상황에 대해 자동화해 해결할 수 있다면 좋겠지만 그럴 수 없는 경우들도 많기 때문에 메일서버나 SMS 서버 혹은 써드파티 솔루션과의 연동을 통해 최대한 빠르게 문제를 인식하고 해결할 수 있도록 해야 할 것이다.

‘아카이브 로그를 백업하는 네트워크 혹은 시스템에 문제가 발생했을 경우 아카이브 로그를 임시적으로 다른 디렉터리로 옮겨 데이터베이스가 운영되는 데 문제가 발생하지 않도록 하자’라는 목표가 있다고 하면 프로세싱은 아카이브 로그를 임시 디렉터리로 옮기는 것이 된다.

저장에 대한 고려

이어서 저장에 대해 이야기해보자. 저장대상이 되는 것은 설정한 목표의 모니터링 이력정보와 프로세싱 이력정보가 될 것이다. 파일을 이용한 저장, 테이블을 이용한 저장 등 정보를 저장하는 방법은 여러 가지를 선택할 수 있다.

모니터링을 지원하기 위해 특정파일을 생성해 해당 파일에 정보를 저장할 수도 있으며 테이블을 생성해 정보를 저장할 수도 있다. 아니면 통계를 내어 리포트 작업을 하는 곳에도 사용할 수 있도록 통계 테이블을 생성해 저장할 수도 있다.

특정 정보에 대해서는 조금 더 상세한 정보를 저장하기를 원할 수도 있으며 불필요한 정보라고 판단되는 것은 저장되지 않기를 원할 수도 있다.

이처럼 저장 대상은 내가 목표를 설정한 것을 파악하기 위해 필수적으로 해야 하며 스토리지 사용을 효율적으로 하고 처리속도를 높이기 위해 필요한 정보만을 저장해야 한다.

마지막으로 효율적으로 관리하기 위해 뼈대가 될 수 있는 모델이 필요하다. 모델링을 보여주고자 하는 것이 목적이 아니므로 여기에서는 하나의 경우가 될 수 있는 모델을 보여준 뒤 엔티티(Entity)를 정의하도록 하겠다.

• [그림 1] 모델과 엔티티 정의
• 

[그림 1]의 모델에서 목표는 내가 하고자 하는 것이다. 예를 들면 계정 비밀번호 실패 감시가 될 수 있다. 대상서버는 계정 비밀번호 실패를 감시하는 대상 서버가 되는 것이다.

모니터링 항목은 계정 비밀번호 실패 감시 목적을 이루기 위해 모니터링되는 항목들이 된다. 모니터링 방법은 모니터링 항목을 찾아내기 위한 방법이다.

모니터링 결과 가능 집합은 모니터링한 결과를 담는 엔티티가 아니라 나올 수 있는 가능한 집합을 정의하는 것이다. 예를 들면 비밀번호 실패 횟수가 될 수 있다. 모니터링 결과 관계는 여러 모니터링 결과의 관계집합을 나타내는 것이다.

처리방법은 계정 비밀번호 실패를 감지했을 경우 처리할 방법이 된다. 특정 명령어를 수행하거나 이메일을 보내는 등 모니터링 결과에 따라 여러 가지 다른 처리 방법을 가질 수 있다.

관계META는 목표와 대상서버, 모니터링 결과, 처리방법의 관계의 메타 정보를 담는 곳이다. 그리고 관계유형META는 목표와 모니터링 항목의 관계 목표와 대상서버의 관계, 목표와 처리방법의 관계 등의 엔티티 2개 간의 관계를 저장하는 참고용 META 코드테이블로 볼 수 있다.

위와 같은 모델 혹은 전혀 다른 모델을 기반으로 해서 하고자 하는 목적을 담아 사용할 수 있는 그릇을 만드는 것도 중요하다. 목적을 가지고 세분화하고 그것을 담을 수 있는 그릇을 만들어 사용해 보는 것은 어떨까?

이 글은 데이터베이스의 효율적이고 발전적인 관리를 위해 하나의 방법을 제시했지만, 데이터베이스 분야뿐 아니라 각자가 맡은 업무기울이게 되는 새로운 자극이 되길 희망한다.