DBMS의 통제 관리 능력을 어떻게 키울 것인가
데이터베이스를 안정적으로 운영·유지하기 위해서 가장 중요한 것은 ‘적절한 통제 관리 절차’이다. 이러한 통제 관리 절차의 1차 목적은 데이터베이스 운영의 안정성 확보와 보안의 유지라 할 수 있다. 이 글에서는 이러한 통제 관리 업무와 함께 데이터베이스 폐기에 이르기까지 일반적으로 수행되는 여러 가지 업무 절차 등을 살펴보자.
삼성SDS에서 11년간 근무하였으며, 현재는 엔코아정보컨설팅 DB사업본부의 수석컨설턴트로 4년째 근무하고 있다. 데이터베이스 전문가로서의 확고한 위상 정립과 목표 달성을 위해 항상 노력하고 있으며, 엔코아의 방법론 셋업과 데 이터모델링, DB 설계, 성능진단 및 개선 컨설팅, 개발컨설팅 등에 이르기까지 다양한 분야에서 데이터베이스 관련 부분에 대한 컨설팅 업무를 수행하고 있다.
데이터베이스를 만드는 것은 여러 전문가가 각고의 노력과 정교한 협업을 통해 만들어 내는 오케스트라 연주와 같다. 각 분야 또는 각 부분을 책임지는 전문가가 모였다고 해도 호흡이 조금만 맞지 않으면 불협화음이 튈 수 있듯이 조율되지 않은 데이터베이스는 반드시 문제를 일으키게 된다. 물론 진정한 전문가라면 완료 후에 서로 맞물리는 부분들이 자로 잰 듯이 정확하게 일치하게 된다. 바로 데이터베이스를 설계하는데 있어 사용자 요구 정의부터 시작해 전체를 몇 사람의 전문가가 나누어 진행하더라도 서로 어느 부분을 공통화시켜야 하고, 내가 어느 부분을 다른 사람에게 책임져 주어야 하는지 등이 오랜 훈련과 경험을 통해 일치하기 때문에 큰 시스템도 분할 작업에 의해 정복이 가능하다는 것이다.
아이를 어떻게 키울 것인가?
대부분의 SI 프로젝트는 사용자 요구부터 시작해 시스템의 근간이 되는 데이터 모델이 완성되고, 이 골격 위에 애플리케이션이라는 잘 만들어진 옷이 입혀지면 비로소 보기 좋은 시스템이 완성된다. 이 과정 역시 데이터베이스 전문가 외에도 애플리케이션 전문가, 아키텍처 또는 시스템 통합 전문가, 하드웨어 및 네트워크 전문가 등 많은 관련 전문가가 참여하게 되고, 이들이 화음을 맞추지 않으면 결과적으로 듣기 싫은 음악처럼 사용자에게 외면당하는 시스템으로 전락하고 프로젝트는 실패로 끝나게 된다.
이처럼 어렵고 힘든 과정을 거쳐 사용자가 원하는 시스템이 마무리되면 사실상 개발팀의 임무는 완수되었다고 할 수 있다. 그 때부터 유지보수팀 또는 사용자측의 대리인 격인 관련 IT 부서가 시스템의 운영과 유지보수를 책임지게 되며, 이들에 의해 운영 시스템은 또 다른 인생 항로를 가게 된다.
사람도 낳아준 부모와 기르는 부모가 다를 수 있듯이 시스템도 한 조직이 개발에서 운영까지 책임지는가 하면 만든 사람과 운영하는 사람이 다른 경우도 허다하다. 또한 사람도 수태 기간을 거쳐 세상에 나올 때까지 많은 공을 들여야 하지만, 정작 성장 과정에서 소홀하면 결국 엉뚱한 운명으로 치닫게 되는 것처럼 아무리 잘 만들어진 시스템이라 하더라도 결국 운영을 어떻게 하느냐에 따라서 시스템이 발전하기도 하고 쇠락의 길을 걷다 조기 폐기의 운명을 맞이하기도 한다.
지금까지 많은 서적과 사람들의 관심은 대부분이 시스템을 어떻게 하면 잘 만드느냐에 맞춰져 왔으며, 사실상 서점에 나가 보면 시스템 운영을 어떻게 해야 하는지 데이터베이스를 어떻게 관리해야 하는지 등에 대해서는 관련 서적을 찾아보기가 매우 어렵다. 시스템 운영, 그 중에서도 특히 데이터베이스의 운영은 체계적인 전문 지식과 고도의 훈련 없이는 수행하기 어려운 업무이다 보니 이와 같은 업무를 가이드하거나 지침을 삼을만한 내용을 담고 있는 대중 매체가 거의 전무하다. 게다가 대부분의 조직에서 선배로부터 후배에게로 일부에 한해서만 이어져 내려가다 보니 많은 사람들이 데이터베이스 운영에 대해 무지하거나 전체를 알기 못하는 것이 현 사정이다. 데이터베이스 운영을 전담하는 전문가를 데이터베이스 관리자(이하 DBA)라 부르는데, 앞서 얘기한 것처럼 이들의 업무 영역이 보편화되어 있거나 관련된 사람들에게 충분히 이해가 되지 않아 자신을 알아주는 사람만 만나면 끝도 없이 속내를 털어놓는 사람들을 필자는 많이 보아 왔다.
데이터베이스는 치밀하고 구체적이면서 또한 입체적인 설계 과정을 거쳐 탄생하게 되며 정교하게 짜 맞춰진 애플리케이션에 의해 생명력을 갖게 된다. 이렇게 탄생한 데이터베이스는 애플리케이션에 의해 생성되고 사용되며 소멸되는 시험 과정을 수차례 반복하면서 저장되는 데이터들의 무결성을 보장받게 되고, 데이터를 액세스하는 애플리케이션의 응답속도 및 서비스 품질이 사용자 요구 수준에 만족할 만한 상태에 이르기까지 안정화 과정을 거치게 되며, 그 이후에 적절한 운영 및 통제 절차에 의해 개인 또는 기업의 데이터가 유지·관리되고, 그 필요성이 다하는 시점에서 적절한 폐기 절차에 의해 생명을 다하게 된다.
통제 관리를 하는 1차적인 목적은 데이터의 안정성 확보와 보안의 유지라 할 수 있다. ‘안정성’이라는 의미에는 ‘서비스가 중단되지 않도록 한다’는 것 외에 ‘최상의 성능을 유지한다’는 의미가 포함되어 있는데, 많은 사이트에서 데이터베이스가 가사 상태에 빠져 있거나 정신을 못 차리고 시름시름 앓고 있는 것도 따지고 보면 서비스의 지속에만 의미를 두고 운영해 온 결과라 해도 과언이 아니다.
필자는 이 글을 통해 많은 사람들이 궁금해 하는 데이터베이스 운영에 대해 데이터베이스의 탄생 이후부터 성장 변화를 거쳐 노화하고 사멸(폐기)에 이르기까지 수행되는 관련 업무 범위와 내용에 대해 소개함으로써 데이터베이스 운영에 대해 알고자 하거나 또는 이러한 업무를 하고자 희망하는 이들의 궁금증 해소를 돕고 관련 실무를 담당하는 이들에게도 혹시 놓치고 있는 업무가 있는 지를 살펴보는 계기를 제공하고자 한다. 그럼 탄생된 데이터베이스를 DBA가 어떻게 잘 키우고 돌보는지 살펴보도록 하자.
데이터베이스 운영을 위해 필요한 요소
어떤 대상을 ‘관리’하고자 한다면 우선 ‘관리할 대상’이 명확해야 하며, 거기에 ‘그 일을 할 사람’과 ‘일하는 방법(절차)’ 등이 필요하다. 이런 관점에서 데이터베이스를 관리할 때 필요한 사항을 꼽아 본다면, ‘관리할 대상’은 당연히 데이터베이스가 될 것이며(좀더 명확하게는 최종 사용자에게 서비스가 되고 있는 운영 데이터가 저장된 운영 데이터베이스라 할 수 있다), ‘일을 할 사람’은 DBA 또는 운영조직이라 할 수 있으며, 마지막으로 ‘일하는 방법(절차)’는 바로 이 글의 주요 논제가 될 데이터베이스 운영에 대한 제반 업무 절차가 될 것이다.
데이터베이스는 개인 또는 기업, 단체, 공공기관 등 누구나 필요에 의해 만들고 운영할 수 있는 것이며, 데이터베이스 구성 매체로 오늘날 가장 보편화되어 있는 것은 관계형 데이터베이스 관리 시스템(이하 RDBMS)이지만, 그 외에도 다양한 형태의 데이터베이스가 존재할 수 있고, 여기에서 이들 모두를 거론하는 것은 논제에서 다소 벗어나기 때문에 이 글에서는 논외로 하고, RDBMS를 운영하고 있는 기업을 모델로 하여 주로 기업에서 데이터베이스를 어떻게 관리하고 있는가에 초점을 맞추어 설명하고자 한다.
DB 운영을 위한 환경
데이터베이스는 1차로 디스크 상에 저장이 된다. 시스템 규모와 환경에 따라 RAID(Redundant Array of Inexpensive/Independent Disks)와 같은 별도의 저장장치에 저장해 운영할 수도 있고, 작은 규모에서는 서버 자체의 로컬 디스크 상에 데이터를 저장할 수도 있다. 그러나 디스크 내에 무한정 데이터를 보관할 수는 없기 때문에 대부분의 기업 전산실에서는 저렴하면서도 장기간 보관이 가능한 보조 저장매체를 채택해 데이터의 백업본을 분리·저장하기도 한다. 로컬 디스크나 RAID와 같은 첫 번째 데이터 저장장치는 대개 항온 항습 환경이 갖춰진 별도의 시설을 사용하게 되고, 필요에 따라 분리된 장소에서 유사시를 대비해 동일 데이터의 복사본을 저장하기도 한다.
이와 같은 복제 데이터 보관은 대개 각종 재난, 재해로부터 기업의 데이터를 안전하게 보호하고 핵심 업무의 연속성을 유지하기 위한 사전 준비 행위이며, 이에 대한 업무는 BCP/DRP(Business Continu ity Plan/Disaster Recovery Plan)이라는 분야로서 9.11테러 이후 전세계의 많은 기업들의 이슈가 되고 있다. 백업 데이터의 보관 역시 BCP/DRP와 무관하지 않다.
데이터베이스 운영이라는 관점에서 보면 지금까지 얘기한 데이터 보관 문제, 즉 데이터를 어디에 어떻게 보관하는가 하는 문제가 데이터베이스 운영과 밀접한 관련이 있긴 하지만 대부분의 기업에서는 시스템 관리 조직이나 정보전략 부서 또는 정보보호 담당 부서 등에서 취급하기 때문에 이 부분에 대한 상세한 설명은 생략하고 직접적인 데이터베이스 운영 업무와 연관된 부분에 대해 설명하고자 한다. 데이터베이스의 운영 환경과 관련해서 반드시 짚고 넘어갈 부분이 있다면 시스템의 개발과 운영이 가급적 별도로 분리된 서버 상에서 이루어져야만 한다는 것을 들고 싶다.
“전쟁터에서 사격 연습을 하지 말라”
분리된 운영 환경을 구성해야 하는 이유는 시스템 개발시의 개발 환경(또는 개발 서버)과 테스트를 위한 테스트 환경(또는 테스트 서버), 실 사용자가 액세스하는 운영 환경(또는 운영 서버)으로 구분해 각각의 환경에 분리된 애플리케이션과 데이터베이스를 유지함으로써 시스템 개발 및 유지보수 업무 과정에서 원본 또는 운영 데이터가 훼손되지 않도록 하기 위함이다.
기업의 IT 관련 부서에서 근무한 경험이 있는 사람이라면 한번쯤은 “전쟁터에서 사격연습을 하지 말라”는 말을 들어 봤을 것이다. 필자 역시 전산실 근무 시절 귀에 못이 박히도록 들어 온 말이다. 막상 전쟁터에 가서 그때서야 사격연습을 한다면 어떻게 쳐들어오는 적을 물리칠 수 있느냐는 의미로, 실제 서버에서 운영되는 데이터를 가지고 이런 저런 테스트를 하는 것은 매우 위험천만한 일이라는 점을 강조해 빗댄 말이다.
<그림 1> 다양한 개발/테스트/운영환경 구성 사례
대부분의 사람들은 과연 누가 실 운영 서버에서 데이터처리 연습을 하겠느냐고 반문할 수 있지만, 필자의 경험에 비춰보면 의외로 이런 사람 내지 이런 IT 조직이 적지 않다는 것이다. 그래서 운영 서버에서 함부로 데이터 처리 테스트를 해보거나 테이블 또는 데이터파일 처리 테스트를 해보다가 뜻하지 않게 중요한 데이터 또는 테이블, 데이터 파일 등을 없애버리게 되어 거의 사색이 된 얼굴로 어쩔 줄을 몰라 하던 개발/유지보수 담당자들의 모습을 여러 번 보아 왔다. 이런 경우 대개는 백업 데이터를 이용해서 무사히 복구하기도 하지만 어떤 경우에는 백업 데이터가 없거나 백업 데이터가 있더라도 삭제 순간의 데이터와 많은 차이가 있어 삭제되기 바로 이전의 시점으로 되돌리지 못해 담당자가 시말서를 쓰거나 징계를 받는 모습도 간혹 보았다.
이와 같은 어처구니가 없는 일이 왜 일어날 수 있는가를 곰곰이 생각해 보면, 그 속에는 데이터에 대한 경시 사고가 있음을 알게 된다. “그까짓 데이터? 다시 입력하지, 뭐!” 혹시 여러 분들은 이런 말을 쉽게 내 뱉어 본 적은 없는가? 이런 말을 쉽게 하거나 쉽게 생각하는 사람이 있다면 데이터에 대한 자신의 생각을 깊이 반성해 볼 필요가 있다. 기업의 데이터 하나하나는 모두 기업 활동에서 얻어지는 소중한 자산이며, 이런 데이터들을 잘 모으고 가공함으로써 그야말로 백만불짜리 정보를 만들어 낼 수 있게 된다. 데이터베이스 입장에서 생각해 보아도 자신이 저장하고 있는 데이터가 있어도 그만, 없어도 그만인 데이터들이라면 얼마나 서글프겠는가? 여러분들도 자신의 존재 가치를 인정받지 못한다고 생각해 보라. 말 못하는 데이터베이스라고 해서 함부로 취급한다면 그 결과는 결국 사람에게 되돌아 간다. ‘Garbage-In-Garbage-Out’이라고 하지 않았는가?
결론적으로 말하면 사용자의 데이터는 별도로 분리된 환경에서 적절하게 보호되어야 한다는 것이며, 개발/유지보수 담당자는 운영환경과 물리적으로 분리된 개발/테스트 환경에서 실제로 사용되는 제대로 된 데이터를 가지고 개발 및 테스트를 하면서도 운영 환경(서버)의 원본 데이터가 훼손되지 않도록 잘 통제하고, 개발/테스트/유지보수 등의 행위로 인한 서버 부하로부터 사용자들이 실제 데이터에 접근하는 데 영향을 받지 않게 보호하며, 운영환경의 데이터베이스에 대한 변경에 대해 적절한 형상관리를 함으로써 사용자의 데이터가 항상 최적의 성능을 유지하면서 안전하게 보호되어야 한다는 것이다.
이러한 문제를 잘 통제하기 위해 다양한 업무 기준과 절차가 필요하게 되고, 이러한 기준과 절차가 얼마나 실현 가능하게 만들어져 있으며 각 관련자들이 이를 얼마나 성실하게 준수하느냐가 안정적인 데이터베이스 운영에 있어서 최대 관건이라고 할 수 있다. 만일 여러분이 아주 고가의 귀중품을 가지고 있다고 가정하면, 그런 물건에 아무나 함부로 접근하게 하겠는가? 아마도 모처에 잘 보관해 놓고 신분이 확실하고 믿음이 가면서 자신의 통제에 잘 따르는 사람으로만 한정하여 접근을 허용할 것이고, 거기에 자신도 분명히 함께 있으려 할 것이다. 개인의 귀중품에도 이와 같은 철저한 보호 통제 절차를 적용하는데, 하물며 기업의 활동 내역이 담긴 데이터베이스는 오죽 하겠는가? 그러면 지금부터 데이터베이스 운영과 관련된 여러 가지 업무 영역에 대해 살펴보기로 하자.
데이터베이스 운영 업무
데이터베이스의 관리 방법 및 절차 등에 대해서는 데이터베이스를 운영하는 IT 부서 또는 관련 조직마다 각자의 환경에 적합한 지침을 만들어 적용하고 있다. 전체적인 전산 환경을 관리하기 위한 활동 측면에서 보면 좀더 많은 업무 영역이 있을 수 있으나, 범위를 데이터베이스 관리와 운영으로 국한한다면 다음과 같은 업무 영역을 들 수 있다. 이는 제반 여건 및 환경에 따라 업무 범위에 가감이 있을 수 있다. 중요한 것은 각자의 처한 환경에 맞게 적절한 관리 영역을 설정하는 것이다. 너무 넓거나 반대로 너무 좁게 업무 영역을 설정하게 되면 무리가 따라 손이 미치지 못하거나 관심 밖의 일이 되어서 관리와 통제가 제대로 이루어지지 않을 수 있다.
데이터베이스가 항상 최적의 상태로 유지될 수 있도록 관리하기 위한 업무 범위에는 어떤 것들이 있을까? 그에 대해서는 의견이 분분하겠으나 대략적으로 다음과 같이 요약해 볼 수 있다.
◆ 데이터베이스 이관 관리
◆ 데이터베이스 전환 관리
◆ 용량계획
◆ 백업 및 복구
◆ 운영 통제(변경 관리)
◆ 성능관리 및 튜닝
◆ 장애 대책 및 위험 관리
◆ 운영현황 보고
이 글에서 알아볼 운영의 핵심 사항으로, 이들이 각각 어떠한 특징이 있고 어떤 점이 중요한 지에 대해 알아보자.
데이터베이스 이관 관리
데이터베이스 이관 관리는 전산 설비 이주시나 서버를 교체하는 등 데이터베이스의 보관 장소가 변경됨으로써 발생되는 서비스 중단을 최소화하기 위한 목적으로 수행된다. 살고 있던 집을 떠나 새로운 집으로 이사를 갈 때도 이삿짐센터 선정부터 많은 것들을 계획·결정해야 하고, 이것을 잘 해야 이사가 무사하게 잘 끝나게 되는 것처럼, 데이터베이스를 이사시킬 때도 철저한 사전 준비가 있어야만 무사히 이사를 마칠 수 있다. 더구나 집을 이사하는 문제는 개인에 국한하겠지만 데이터베이스를 이사시키는 것은 수많은 사용자들과 관련이 되기 때문에, 여기서 발생하는 문제는 곧바로 엄청난 손실로 이어질 수 있는 가능성을 안고 있다. 이 때문에 진행 절차에 대한 계획을 수립하고 예상되는 제반 문제요소를 도출해 사전에 대비책을 강구하는 한편 수립된 계획에 따라 사전에 모의 훈련을 실시해 이관에 따른 불확실한 요소를 제거해 내는 것들을 주요 골자로 하는 계획이 필요한 것이다.
이러한 상황은 데이터베이스 이관을 데이터베이스 관리 업무의 범주로 논할 때 혹자는 직접적인 데이터베이스 관리 업무라고 보기에는 다소 무리가 따른다고 할 수 있겠으나, 데이터베이스 운영의 목표가 안정된 서비스가 이루어지도록 하는 것이라면 데이터베이스에 대한 서비스 관리 관점에서 중요한 업무 요소라 할 수 있다.
이를 위해 DBA는 물론이고 시스템 관리자 등 관리 인원은 평상시 장애복구 및 최단 시간 서비스 재개를 위한 교육과 훈련이 철저히 준비되어 있어야 하고, 이관을 실행하기에 앞서 철저한 계획수립과 검토, 도상 훈련, 체크리스트 등을 통해 실행시 관련자들이 우왕좌왕하지 않고 일사분란하게 움직여 목표한 시간 내에 이관이 완료되도록 해야 한다. 특히 서버 교체의 경우 RDBMS를 사용하고 있다면 이관 후에 옵티마이저라고 하는 질의 처리기가 기존과 다른 실행계획을 수립하게 되어 시스템 성능이 저하되거나 심지어 데이터 오류를 발생시킬 가능성도 있기 때문에 DBA는 이관 후에 이러한 상황이 발생하는지 꼼꼼하게 따져 보아야 한다. 해당하는 RDBMS에서 제공되는 SQL 트레이스 유틸리티(SQL 서버의 경우에는 프로파일러)를 이용하면 이러한 변화를 용이하게 발견할 수 있다. 이관 후 일정 시간 동안 트레이스 자료를 수집해 분석해 보면 응답시간이 많이 걸리거나 실행계획 변경으로 I/O에 병목현상이 발생하고 있는 질의문(SQL) 등을 쉽게 찾아 낼 수 있기 때문이다. 이관 전과 후에 각각 트레이스 자료를 수집해서 비교해 보면 차이가 쉽게 발견된다.
데이터베이스 전환 관리
데이터베이스 전환은 대체로 다음과 같은 두 가지 상황에 의해 발생한다.
- 새로 개발된 시스템을 운영환경에 적용시 기존 데이터의 전환
- DBMS 교체나 업그레이드에 따른 기존 데이터 전환
데이터베이스 전환시 앞의 두 가지 경우의 포인트는 조금씩 차이가 있다. 첫 번째 경우인 신규 개발 시스템에 기존 데이터를 전환할 때는 전환 전후에 데이터가 정확히 일치하는지의 여부가 가장 중요하다. 물론 전환 과정에서 데이터 클린징에 의해 일부 제거되는 데이터가 존재할 수 있으나 전환 대상과 클린징이 되는 데이터를 모두 합했을 때 기존 데이터와 총 건수가 일치해야 한다. 즉, 사전에 정의한 검증 요소와 기준 값에 정확히 일치해 전환 과정에서 누락되거나 변질된 데이터가 없음을 입증하는 것이 중요하다.
<그림 2> 관계형 데이터베이스 사용환경에서 AS-IS 데이터를 TO-BE 데이터로 전환하는 절차 사례
데이터의 전환은 대개 별도의 프로그램을 작성해 수행하고 있으나 관계형 데이터베이스 시스템이라면 가급적 SQL 중심으로 처리할 것을 권하고 싶다. 복잡한 맵핑 규칙을 이유로 C나 COBOL과 같은 3세대 언어 처리방식으로 작성한 프로그램은 대부분 복잡한 IF...THEN...ELSE 처리와 수많은 반복구조(루프)를 갖고 있기 때문에, 전환 대상 데이터량이 클수록 자칫 전환에 소요되는 시간이 장기화되어 기껏 개발한 신규 시스템의 오픈 시점에 영향을 줄 가능성이 크다. 그러나 SQL 중심의 전환 처리에서는 관계형 데이터베이스의 옵티마이저가 SQL을 대상으로 최적화를 수행하기 때문에 훨씬 향상된 성능을 얻을 수 있으며, 조인 방식이나 조인 순서 등을 바꾸거나 간단한 SQL 재구성만으로도 수행속도가 크게 달라질 수 있다. 여기에 더해서 SQL 수행시 병렬처리나 세션 메모리 조절 등의 방법을 적용하면 더욱 빠른 SQL 처리 성능을 얻을 수 있기 때문에 이와 같은 SQL 중심의 전환처리 방식을 적용해야만 목표한 시간 내에 전환을 완료하고 무사히 시스템을 오픈할 수 있게 된다.
요즘과 같이 억 단위의 대용량 데이터를 저장하고 있는 테이블의 존재가 보편화되어 가는 추세에서는 더욱 이런 처리 방식이 중요하다. 물론 이러한 모든 전환 과정이 DBA의 책임은 아닐 것이나 최소한 데이터베이스 관리 차원에서 전환이 순조롭게 목표한 시간 내에 이루어질 수 있는지의 여부를 판단하고 전체적인 데이터베이스 관리 업무의 범주 내에 반영하려면 상당한 수준의 관계형 데이터베이스 원리 이해와 SQL 실력을 갖추고 있어야만 가능하다.
두 번째 경우인 DBMS 교체는 첫 번째 경우와 크게 다르지 않으나 업그레이드시에는 전환 전후의 데이터에 변경이 없음을 검증하는 것에 더해서 업그레이드 대상 버전에 버그는 없는지 혹은 이로 인해 서비스가 중단될 가능성이 있거나 데이터 자체에 오류가 발생할 가능성은 없는지 등을 꼼꼼하게 따져 보아야 한다(해당 DBMS의 사용자 그룹이나 포럼 사이트 등을 방문해서 알려진 버그가 없는지 등을 살펴보는 것도 좋은 방법이다). 특히 RDBMS의 경우 버전 업그레이드에 따라서 옵티마이저라고 하는 질의 처리기가 기존과 다른 실행계획을 수립하게 되어 시스템 성능이 향상될 수도 있지만 반대로 성능이 저하되거나 심지어 데이터 오류를 발생시킬 가능성도 있기 때문이다.
예를 들어 기존 환경에서 프로그램A에 내장된 SQL이 테이블 A의 1번 인덱스에 접근해 관리번호를 생성한다고 가정했을 때, DBMS 업그레이드 이후 옵티마이저가 수립하는 실행계획이 바뀌어 다른 인덱스를 사용하도록 되었다면 이때 이 인덱스로 접근해 생성하는 관리번호는 이미 발생한 번호가 중복 발생되거나 하여 오류 상황으로 귀결될 가능성도 있을 수 있다는 것이다.
이와 같은 옵티마이저 실행계획과 성능의 변화에 대한 검증은 데이터베이스 이관에서 설명한 것처럼 SQL 트레이스 유틸리티를 이용하면 변화를 쉽게 발견할 수 있으며, 추가적으로 sar나 iostat과 같은 명령을 이용해 시스템 부하를 측정해 보는 것도 좋은 방법이다.
데이터베이스 전환은 전환 과정 자체를 치밀하게 계획하고 통제함으로써 실행 과정에서의 오류 가능성을 제거하고 목표한 시간 내에 전환을 완료하는 것도 중요하지만, 전환 결과 데이터에 대한 신뢰성 확보도 그에 못지않게 중요하다. 전환 데이터에 대한 검증시 많이 사용하는 방법으로 대략 4가지 정도를 들 수 있는데, 이들에 대한 전환 전후의 비교를 통해 전환시 오류가 있었는지 여부를 검증할 수 있다.
◆ Financial Total 또는 Monetary Total : 컬럼 중 급여처럼 재무적으로 의미가 있는 컬럼에 대한 합계
◆ Hash Total : 일련번호처럼 재무적으로 무의미한 컬럼의 합계
◆ Total Items : 수량과 같이 양적인 의미를 가진 컬럼의 합계
◆ Total Document : 로우(rows) 또는 레코드(records)에 대한 총 건수
용량계획
용량계획은 최소한의 비용으로 최상의 서비스를 보장할 수 있는 범위 내에서 이루어지는 서버, 디스크, CPU, 메모리, 네트워크 구성 등에 대한 적정량을 결정하고 유지하기 위한 업무라고 할 수 있다. 특히 데이터베이스 운영과 관련해 적정한 디스크 용량을 유지하는 것은 안정적인 데이터베이스 서비스를 위해 매우 중요한 사항이다. 사람도 적당한 공간이 있어야 숨도 쉬고 활동하며 살아가는 것처럼, 데이터에게도 적절한 활동 공간은 데이터가 항상 최상의 상태로 서비스될 수 있기 위한 기본 조건이라 할 수 있다.
데이터베이스를 액세스할 때 병목이 발생하지 않도록 하기 위해서는 적절한 I/O 분산이 필수며, 이를 위해서는 물리적으로 구별되는 하나 이상의 디스크를 할당할 수 있어야 한다. 이러한 문제를 해결하기 위해 여러 개로 구성된 로컬 디스크를 사용하거나 RAID와 같은 디스크어레이를 사용하는 것이 일반적이다. 여러 개로 구성된 디스크를 사용하는 경우 디스크 공간이 충분하다면 좀더 빠른 액세스 속도를 구현하기 위해 스트라이핑(striping)과 같은 기법을 사용하기도 한다. 이와 같이 최적의 데이터베이스 서비스를 유지하기 위해서는 적정한 양의 디스크가 필요한데, 이는 곧 비용으로 귀결되기 때문에 데이터 증가 추이를 잘 분석해 사전에 철저한 대비와 검토를 통해 장기적인 계획에 의해 이루어지지 않으면 기업의 입장에서는 많은 비용 낭비는 물론이고 서비스 품질에도 영향을 받을 수 있다. 이는 사람이 성장 과정에 맞추어 적당한 시점에서 좀 더 크고 편안한 옷으로 갈아입는 것과 같은 이치이다.
데이터의 증가 추이 예측은 이 글에서 소개하는 데이터베이스 운영 업무 중 ‘운영현황 보고’와도 연계되는데, 매월 운영현황 정보를 수집하고 분석해 월별로 데이터가 증가하는 추이를 분석해 보면 어느 시점에 가서 디스크 용량이 부족하게 되는지 예측이 가능해진다. 이런 예측을 통해 저장공간 부족에 의해 시스템 가동이 중단되지 않도록 시기적절하게 디스크를 추가 또는 교체해 데이터베이스가 항상 최상의 상태로 서비스될 수 있도록 해야 한다. 운영현황 분석과 함께 추가로 고려할 것은(운영현황 분석에 의한 예측은 어디까지나 산술적인 계산에 의한 것이므로) 이벤트나 캠페인 실시, 업무범위/량 증가, 트랜잭션 증가 등으로 업무 환경 변화에 의해 증가 폭이 달라질 수 있음을 생각해야 한다. 이 때문에 대개는 불완전하더라도 증가 추이를 예측할 때 보정계수를 사용한다. 보정계수는 아이들 옷을 살 때 몸이 계속 자라나는 것을 고려해서 현재보다 한두 치수 더 큰 것으로 사는 것과 같다. 보정계수는 앞에서 기술한 여러 가지 업무 변화 가능성 등을 고려해 각자에 맞게 설정해 사용하면 된다.
백업 및 복구
백업은 두 가지 목적으로 운영된다. 하나는 유사시 신속하게 최신의 상태로 데이터베이스를 되돌리기 위함이고, 또 하나는 한정된 저장 공간의 제약사항을 보완하기 위해 마그네틱 테이프와 같은 보조 저장장치를 이용해 과거에 발생되어 현재는 거의 사용이 되지 않는 오래된 데이터나 중요 데이터에 대한 복사본을 저장하는 것이다. 어떤 DBMS를 사용하고 있느냐에 따라 다소간의 차이가 있을 수는 있으나 대개의 경우 첫 번째 목적을 위해 아카이브와 같은 1차 백업본을 만들기도 한다. 하지만 이 역시도 데이터 발생 및 변경 등이 활발하면 한정된 디스크 공간 내에 많은 아카이브 정보를 보관해야 하므로 비용 상의 문제가 발생해 대개의 경우는 어느 정도의 아카이브 자료가 쌓이면 보조 저장매체로 이동시켜 보관한다.
보조저장 매체로 가장 널리 사용되는 것은 광 디스크와 마그네틱 테이프인데, 저렴한 가격으로 많은 정보를 저장할 수 있고 재사용성 측면에서도 우수한 마그네틱 테이프가 좀더 보편적으로 사용되고 있다. 마그네틱 테이프를 사용할 때는 반드시 사용기한과 기록횟수를 확인해야 하며, 사용기한이 경과한 오래된 테이프를 사용하거나 보장된 기록횟수를 넘긴 테이프를 사용함으로 해서 막상 필요할 때 저장된 정보를 제대로 읽지 못하게 되어 낭패를 당하지 않도록 주의해야 한다.
백업은 대개 변경된 부분만 따로 읽어 들여 만들거나 혹은 전체 복사본을 만드는 방법으로 진행되는데, 변경된 부분만 저장하면 백업 데이터 생성이 짧은 시간 내에 이루어질 수 있어서 대용량 데이터를 저장하고 있는 환경에서 백업 생성시 유리한 장점이 있다. 반면에 백업된 내용 자체가 그날그날 또는 특정 시점에서의 변경 부분만 갖고 있으므로 그 기반이 되는 데이터 전체가 문제시 되는 경우에는 이것만 가지고는 제대로 복구할 수 없다는 단점이 있다. 전체를 그대로 복사본으로 만드는 방법은 전체 데이터에 문제가 생겼을 경우에도 그대로 다시 복사해 넣으면 전체 데이터를 복구할 수 있다는 장점이 있는 반면에, 대용량 데이터를 저장하고 있는 환경에서는 백업 생성시 매우 많은 시간이 소요되어 자주 백업본을 생성하기가 곤란하고, 이 때문에 ‘최신’과는 항상 괴리가 있다는 단점이 있다. 그렇기 때문에 전체 백업은 불연속적인 시점에서의 스냅 샷만 가질 수밖에 없고, 이것은 곧 데이터 복구시에 전체 백업본만 가지고 있는 경우에는 문제가 발생하기 바로 전 상태로 원상 복구시키기가 불가능하고, 최종적으로 전체 백업을 받은 시점까지만 복구가 가능하게 된다.
이러한 문제를 극복하기 위해 대부분의 시스템 관리자나 DBA는 주기적으로 전체 백업을 수행하고 매일 또는 수시로 변경 부분에 대한 백업을 수행해 보관하고 있다. 그리고 이를 통해 전체 데이터에 대한 장애 발생시 일단 최종적인 전체 백업본을 먼저 복사한 후 그 위에 시점 별로 생성한 변경 사항에 대한 백업을 시간 순으로 다시 반영해 나감으로써 장애가 발생하기 바로 전 시점으로 완벽하게 복구가 가능하게 된다.
[ 디스크 스트립핑 ]
복수의 개별 디스크에 하나의 데이터(테이블, 데이터 파일 등)을 물리적으로 분산 저장되게 하고, 논리적으로 하나의 오브젝트처럼 사용함으로써 데이터 엑세스시 동시성 향상에 의해 엑세스 성능을 향상시키는 물리적인 저장 기법이다. 관계형 데이터베이스에서 하나의 데이터 파일을 여러 개의 디스크에 할당함으로써 저장 데이터가 할당된 복수 개의 디스크에 나뉘어 저장되도록 하거나, 디스크 구성시 가상적 스트라이프(virtual stripe)를 작성하여 이들 디스크를 컴퓨터의 운영 체계가 단일의 디스크 구동 장치(disk drive)로 인식하도록 하여, 이들 디스크상에 존재하는 똑같은 크기의 디스크 분할(disk partition)의 집합을 단일 디스크 볼륨(disk volume)으로 종합하여 사용하기도 한다. 이렇게 하면 같은 볼륨 내에서의 다중 입출력 동작이 동시에 진행될 수 있게 되어 성능이 크게 향상된다.
운영 통제
운영 통제는 데이터베이스를 운영하는 과정에서 애플리케이션 개발/유지보수 담당자들이 운영환경에 반영된 데이터베이스의 형상을 변경하고자 하는 경우에 대한 적절한 통제 절차를 의미하며, 주로 신규로 파일, 테이블, 인덱스 등을 생성하거나 이들에 대한 변경, 삭제, 데이터 업로드(임포트)/다운로드(익스포트) 등이 해당된다. 또한 좀더 확장해서 생각해보면 잘못 변경된 애플리케이션에 의해 저장 데이터가 예기치 않게 삭제되거나 잘못된 값으로 바뀌지 않도록 애플리케이션에 대한 소스코드 검사나 SQL 검증까지도 생각해 볼 수 있다. 물론 값이 틀려지지 않았더라도 시스템 성능에 문제가 발생하지 않도록 하기 위해서도 변경된 애플리케이션의 소스코드나 SQL 검사는 반드시 필요하다. 운영 통제는 데이터베이스 운영과 관련한 업무 중에서 가장 중요하고 빈번하게 수행되는 핵심 업무라 할 수 있으며, 아이들을 갖가지 외부 위협이나 영향으로부터 적절하게 보호하지 않으면 아이들의 성장에 문제가 생길 수 있는 것처럼 데이터베이스 또한 계속되는 변경이나 비인가된 접근으로부터 적절하게 보호되지 않으면 안정성에 치명적인 결함이 발생할 수 있다.
이러한 업무와 관련해 애플리케이션 개발자들에 대해 DBA가 적절한 통제 수단이나 권한을 가지지 못한다면 데이터베이스를 최상의 상태로 유지하는 데 있어서 어려움을 겪게 된다. 이 때문에 많은 데이터베이스 운영자들은 때때로 애플리케이션 개발/유지보수 담당자들과 데이터베이스 관리 목적을 위해 충돌이 발생하기도 하며, 이때 데이터베이스 운영자의 직급 및 기술 수준, IT 부서 또는 관련 조직 내에서의 위상 등에 따라 데이터베이스의 안정적인 운영 문제는 많은 영향을 받게 된다.
필자도 과거 개발자 시절에 DBA로부터 변경 신청한 애플리케이션의 SQL 성능 문제로 호되게 혼난 경험이 몇 차례 있는데, 그 DBA 덕분에 당시 필자가 근무하고 있던 곳의 전산 시스템은 여러 곳으로부터 벤치마킹 대상이 되며 인기가 있었던 기억이 있다.
운영 통제는 데이터베이스를 무분별한 변경 또는 액세스로부터 보호하기 위한 보안 개념에서 출발하며, 시스템 유지보수의 목적을 대개 시스템의 가용성 향상과 사용자의 요구사항 변화 반영, 시스템의 생명 연장으로 보았을 때 이의 연장선에서 이러한 변화로부터 데이터베이스의 안정성, 가용성, 신뢰성을 확보한다는 측면에서 매우 중요한 업무이다.
운영 통제와 관련해 대개 애플리케이션 개발/유지보수 담당자들과 DBA의 관계는 상호 협력적이기보다 다소 과격한 표현일 수 있으나 ‘창과 방패’ 관계에 가깝다. 애플리케이션 담당자 입장에서는 사용자 요구사항에 의해 개발/변경된 내용을 용이하고 신속하게 운영환경에 반영하고자 하는 습성을 보이고, DBA 입장에서는 애플리케이션 담당자들의 작업 결과를 무턱대고 반영했을 때 성능저하나 예기치 못한 오류 상황으로 이어질 수 있기 때문에 가급적 문제가 없다는 확신을 가지고 형상변경을 하려다 보니 개발/유지보수 담당자들의 기대와는 다르게 행동할 수 있게 된다. 말하자면 데이터베이스를 중심에 놓고 봤을 때 애플리케이션 담당자와 DBA는 공격과 방어의 입장 차이가 있게 된다는 것이다. 둘 중 어느 쪽이 우세하냐에 따라서 때때로 데이터베이스의 안정성은 심각한 영향을 받을 수 있는데, 필자가 다녀 본 여러 고객 사이트 중에도 DBA의 통제력이 약하거나 아예 통제 절차가 없는 경우도 상당수 있었으며, 안타깝지만 그러한 곳에서는 유독 성능 문제가 심각하게 나타나는 것이 일반적이었다.
이처럼 데이터베이스의 안정성을 보장하기 위한 중요한 수단의 하나로 통제절차는 반드시 고려할 사항이며, 통제절차가 너무 까다로우면 준수하기가 어렵고 너무 형식적이면 안정성에 아무런 도움이 되지 못한다. 이에 애플리케이션 담당자와 DBA가 상호간에 잘 준수할 수 있는 수준으로 적절하게 기준과 절차가 만들어져야 하며 양자 모두 절차 준수를 위한 의지와 절차 교육이 철저해야만 효과가 있다.
운영 통제는 사용자 데이터에 대해 적절한 통제가 이루어지고 있음을 증명하기 위한 ‘기록’을 필요로 하고, 이 기록의 내용에는 변경 일자와 변경 사유, 변경 내용을 비롯해 최초 요구자, 변경 신청자, 변경 처리자, 처리일자, 처리 결과, 검증 내용 등이 포함되며, 처리 결과 통제의 기준으로 가장 많이 사용되는 검증 방법은 성능기준에 대한 만족도와 표준에 대한 준수여부 검증이다. 예를 들면 온라인 화면의 응답속도는 조회 프로그램 기준으로 3초 이내이어야 한다든지 하는 성능 기준이 있을 수 있고, 또는 코딩 규칙으로 코딩시 코멘트나 적절한 메시지 사용 규칙, 에러 처리 규칙, 사용자 인터페이스 표준 등 시스템 개발과 관련한 여러 가지 표준 규정들을 잘 준수해 애플리케이션이 작성되었는지 등을 검사하는 것이 통제 기준의 한 사례라고 할 수 있다.
추가적으로 한 가지만 더 중요한 통제 요소를 든다면 해당 애플리케이션 변경에 따른 설계서 변경의 확인이다. 설계서에 변경 사항이 적절하게 반영되었는지 항상 확인하지 않으면 조만간 실행되고 있는 애플리케이션과 설계서가 서로 맞지 않아 결국 설계서는 아무도 들여다보지 않는 쓰레기로 전략하고 만다.
이러한 변경 기록의 작성과 검증 기준의 명시, 기준을 준수했는지를 검증하는 방법, 운영환경에 액세스하는 순서, 변경사항 반영 후의 행동 요령 등을 정의한 것을 통제 절차로 볼 수 있으며, 이 절차에 따라 업무를 수행함으로써 애플리케이션 담당자와 DBA 상호간에 명확한 업무 기준이 확보되고, 운영 데이터베이스는 안정적으로 서비스되면서 잘 자라날 수 있게 될 것이다.
성능 관리와 모니터링 그리고 진단과 튜닝
적절하게 통제되지 않은 애플리케이션이나 배치 작업 등에 의해, 또는 시스템 이상 발생에 의해 데이터베이스 서비스는 언제든지 장애가 발생할 수 있기 때문에, 이에 대한 모니터링과 주기적인 성능 진단 및 조치, 튜닝(성능개선) 활동은 DBA에게 있어서 매우 중요한 업무 요소가 된다. 사람으로 치면 주기적인 건강 진단과 적절한 치료가 여기에 해당된다고 할 수 있겠다.
<리스트 1> 모니터링에 발견된 비효율적인 SQL에 대한 원인 분석과 조치 사례
아무리 통제가 잘 이루어지고 있는 환경이라고 하더라도 데이터나 트랜잭션의 증가가 당초의 설계 기준을 상회하게 된다거나 미처 발견하지 못한 오류 요소들로 인해서도 성능 문제는 항상 발생할 소지를 안고 있다. 이 때문에 아무리 잘 설계되고 잘 개발된 시스템이라 할지라도, 또한 잘 통제되고 안정적으로 운영되고 있는 시스템이라 할지라도 지속적으로 성능 요소들을 모니터링하고 정기적인 진단 등을 통해 문제 요소를 사전에 도출해 내고 이를 적절하게 제거해 내는 일은 데이터베이스의 안정적인 운영에 있어서 중요한 업무이다.
DBA가 항상 모니터 앞에 앉아 성능 변화를 지켜보고 있는 것은 사실상 불가능하기 때문에 대부분은 자동화된 모니터링 소프트웨어(모니터링 툴)의 도움을 받게 되며, 이때 사용되는 소프트웨어의 기능이나 적용 범위 등에 의해, 또한 이를 사용하는 관리자의 기술 수준에 따라서도 결과는 판이하게 다를 수 있다. 그러나 모니터링 툴이 아무리 뛰어나도 여기에는 분명히 한계가 있을 수밖에 없기 때문에 가장 중요한 것은 이를 사용하는 사람이다. 즉, DBA가 툴이 제공하는 정보로부터 정확하게 문제 요소와 원인을 찾아낼 수 있어야 하며, 이를 위해 DBA는 전문성이 필요하다.
DBA를 ‘의사’라고 생각해보면 잘 이해가 갈 것이다. 선천적인 장애(설계부터 잘못된 경우)가 아닌 다음에는 훌륭한 의사가 있다면 건강에 대해 어느 정도 안심이 되듯이 잘 다듬어진 훌륭한 DBA는 데이터베이스의 건강 유지를 위해 꼭 필요한 요소라 할 수 있다. 수시로 성능진단을 해보고 원인을 추적해 보며 관련 서적이나 타인의 경험을 토대로 해결 방안을 찾고 조치하는 등의 훈련이 꾸준히 이루어져야만 툴에 의존하지 않고 사람이 올바르게 문제를 판단하고 적절하게 조치하는 것이 가능하며, 이러한 사람이 훌륭한 의사, 훌륭한 DBA라 할 수 있다.
<화면 2>처럼 서버에 갑작스럽게 심각한 부하가 발생하면 시스템 관리자는 신속하게 원인을 추적하고, 그 원인이 데이터베이스 쪽임이 판명되면 시스템 관리자는 DBA에게 원인 추적과 조치를 의뢰하게 된다. DBA는 원인 추적에 의해 부하의 원인이 <화면 2>에서와 같이 특정 SQL에 의한 것을 밝혀 낼 경우 이 SQL의 사용 목적과 사용 시점 등을 조사해 제거하거나 사용 시간대를 변경하도록 가이드해 주는 등의 조치를 통해 부하를 해소하게 된다. 또한 어떤 경우에는 저성능 SQL에 대한 실행계획을 분석해 비효율 원인을 도출해 내고, 직접 또는 해당 개발자나 유지보수 담당자에게 연락해 조치하게 함으로써 데이터베이스의 성능을 유지한다.
<리스트 1>은 모니터링에 발견된 비효율적인 SQL에 대한 원인 분석과 조치에 대한 사례이다. 이 경우는 memo_regdate 컬럼이 조건문에 사용될 때 to_char 함수로 가공되었기 때문으로 해당 인덱스를 사용하지 못하고 전체 테이블을 모두 검색하게 되어 매우 많은 I/O와 함께 이에 따른 응답속도 저하가 나타나게 된 사례이다. 여기서는 조건에 사용된 컬럼이 가공되지 않도록 상수 쪽을 가공해 조건문장을 재구성하면 된다.
<그림 3>은 진단/튜닝 업무를 수행하는 절차이며, 성능진단과 튜닝에 대한 방법에 대해서는 너무나 방대한 내용을 거론해야 하기 때문에 생략하기로 한다.
<그림 3> 시스템 성능진단/튜닝 절차 사례
장애대책 및 위험관리
데이터베이스 운영자는 다양한 장애 유형을 예측하고 평상시에 이에 대한 적절한 대응계획을 수립해 관련자들에 대해 교육·훈련을 실시함으로써 유사시에 대비해야 한다. 또한 다양한 위험요소에 대한 정의와 모니터링을 통해 장애 발생을 사전에 막을 수 있도록 함은 물론이고 유사시 신속하게 대응할 수 있는 비상조직 구성과 보고체계를 수립해 이러한 비상조직망에 대한 주기적인 점검 및 모의 훈련을 꾸준히 시행해야 한다. ‘비상시’는 장애상황과 재해상황으로 구분해 볼 수 있으며, 장애상황 발생시는 앞서 설명한 정규조직이 비상연락망을 가동해 신속하게 복구를 수행하고, 재해상황이 발생하면 앞서 설명한 비상조직이 가동되어 신속하게 상황을 극복하고 업무의 연속성을 확보할 수 있도록 해야 한다.
응급 환자가 응급실에 실려 왔을 때를 생각해 보자. 응급실에 있는 간호사며 의사들이 무슨 일을 해야 할지 모르고 허둥지둥하면 결국 환자의 생명은 보장할 수 없게 되는 것처럼, 비상 상황이 발생했을 때 관련자들이 훈련이 되어 있지 않아서 신속한 조치를 하지 못하고 허둥대게 되면 데이터베이스는 결국 조기에 생을 마감할 수밖에 없을 것이다. 이 때문에 평상시 비상 상황에 대한 대처 방안을 수립하고 관련자들에 대한 꾸준한 모의 훈련을 시행해야 하며, 이를 소홀히 하면 정작 중요한 순간에 눈물을 흘릴 수밖에 없을 것이다. 이는 앞서 설명한 것처럼 BCP/DRP로 불리는 업무 영역에서 주로 취급되기 때문에 더 이상의 설명은 생략하기로 한다.
평상시 정규조직의 업무 범위 내에서 자주 발생될 수 있는 장애상황과 이에 대한 조치를 RDBMS를 사용하고 있는 환경을 예로 들어 간략히 소개하면 <표 1>과 같다.
운영현황 보고
운영현황 보고는 사람으로 치면 정기 건강검진 보고와 같다. DBA는 운영현황 보고를 통해 운영 시스템의 구성 현황과 변동사항, CPU, 디스크, 메모리 등 주요 시스템 자원의 부하 현황, 장애발생 현황 등 운영하고 있는 시스템 자원에 대한 보고 의무에 수행하고, 데이터베이스에 발생하는 장애들을 분석해 각 장애 사이에 연관성이 있는지를 파악하며, 데이터베이스에 발생 가능한 추가적인 장애 요소들이 잠재하는지를 예측해 사전에 제거함으로써 데이터베이스가 안정적으로 운영되도록 해야 한다. 한편으로 장애발생 추이를 비롯해 평소 데이터 증가 추이를 잘 관찰해 저장공간 부족에 의해 시스템 가동이 중단되지 않도록 시기적절하게 디스크를 추가 또는 교체함으로써 데이터베이스가 항상 최상의 상태로 서비스될 수 있도록 하는 것도 DBA의 중요한 임무의 하나이다. 의사가 건강 검진한 결과들을 모아서 추이를 관찰함으로써 질병의 잠재 가능성을 찾아내고 미리 조치하는 것과도 같다고 하겠다.
이를 위해 DBA는 주기적으로 데이터베이스 운영 현황에 대한 자료를 수집해 이를 분석하고, 정기/부정기적으로 결과를 리포팅해 관리자 및 사용자 계층에 현황을 알리게 되는데, 이는 대개 전체 시스템에 대한 시스템 운영 현황 보고의 한 부분으로 이루어진다. 데이터베이스에 대한 운영현황 보고에서 주된 내용은 디스크 구성 및 사용량에 대한 현황, 데이터 저장량의 변화 추이, I/O 병목 발생 현황, 장애 발생 및 복구에 대한 기록 등을 포함하며, DBA는 이러한 보고를 통해 데이터베이스의 현재 운영 상태에 대한 정보를 주요 관련자를 포함한 조직 전체에 알려 공감대를 형성하고, 디스크 추가 또는 교체 시기 등의 예측을 통해 예산을 편성해 시기적절하게 구매를 추진하는 등 사전 대응을 용이하게 수행할 수 있다.
데이터베이스를 운영하는 사람
지금까지 데이터베이스의 운영 환경과 운영 통제 업무의 범위 등에 대해 설명했다. 데이터베이스 운영에 대해 마지막으로 논의할 중요한 사안은 운영의 주체인 ‘사람’이다. SF영화에 나오는 것처럼 완전히 자동화된 IT 환경이 아닌 다음에는 데이터베이스 관리의 궁극에는 사람이 있기 때문에, 결국 데이터베이스의 안정적인 운영 관리는 데이터베이스가 잘 운영되도록 관리하는 전문 인력의 구성과 전문성 정도에 영향을 받는다고 할 수 있다.
<표 1> 장애상황과 이에 대한 조치
대개 거의 모든 기업의 IT 부서는 데이터베이스를 운영·관리하기 위해 평상시 운영 업무를 담당하는 정규조직을 두고 있고 별도로 비상사태나 재해시 응급 복구 및 비상 운영을 위한 비상조직을 갖추고 있는데, 중요한 것은 이러한 조직 구성이 아니라 이들 각자가 상황에 맞게 충실히 역할을 수행할 수 있도록 평상시 이들에 대한 교육계획 수립과 지속적인 교육·훈련을 실시해 평상시나 유사시에 있어서 관련자들이 충분히 제 몫을 해내야 한다는 것이다.
정규조직의 보편적인 형태는 운영 시스템의 관리 업무 전체를 총괄하는 시스템 관리팀장을 두고 하드웨어, 소프트웨어 등을 관리하면서 이들에 대한 업그레이드 및 버전 관리, 장애 복구 및 성능 유지 관리 등의 업무를 수행하는 시스템 관리 파트와 네트워크 관련 하드웨어를 포함한 네트워크 구성과 회선 용량을 설계하고, 설치 및 유지 관리, 장애 복구 등의 업무를 수행하는 네트워크 관리 파트, 그리고 데이터베이스에 대한 형상관리 및 성능 유지, 장애 복구 등의 업무를 수행하는 DB 관리 파트 등으로 구분해 시스템 관리팀장이 각 담당자를 통해 이러한 업무들을 원활히 수행하도록 하고 있다. 앞에서 열심히 설명한 데이터베이스 운영 통제 관련 업무들은 바로 이 DB 관리 파트의 업무 내용이라고 보면 되겠다. 여기에 각 부문에서 심각한 장애가 발생했을 때 이를 신속하게 복구할 수 있도록 하드웨어 및 소프트웨어, 네트워크, DBMS 등에 대한 각 벤더 전문가들의 긴급 연락 전화번호를 중심으로 한 비상연락체계를 만들어 운영한다. <그림 4>는 정규조직과 비상조직의 구성 사례를 표시한 것이며, 비상조직은 앞서 얘기한 BCP/DRP의 업무 영역에 속하므로 여기서는 비상조직의 구성 사례만 소개하고 자세한 업무 내용에 대해서는 생략하였다.
데이터베이스 운영의 마지막 : 폐기
지금까지 데이터베이스를 운영·유지하는 여러 가지 업무 내용과 특징에 대해 살펴봤다. 시스템은 생명주기에 따라서 개발과 유지보수를 거쳐 용도 폐기라는 종착역에 이르게 되는데, 데이터베이스 역시 시스템의 생명주기에 따라 운명을 같이 하게 되는 것이 보통이다.
좀더 엄밀히 얘기하면 애플리케이션과 데이터베이스의 생명주기는 약간 다르다. 애플리케이션은 한번 개발되어서 성능 개선이나 요구사항 변경 등에 의해 유지보수가 일어나고 필요성이 소멸되면 그 애플리케이션도 더 이상 존재 가치가 없어지기 때문에 백업 후 시스템에서 제거해 내는 것이 보통이지만, 데이터베이스는 애플리케이션보다 생명주기가 길고 기업이 존재하는 한 해당 데이터가 계속해서 필요한 경우가 대부분이다. 물론 과거 데이터의 경우에 더 이상 접근할 필요가 없어져서 백업 후 시스템에서 삭제하는 경우도 있지만 그것은 어디까지나 일부 데이터에 국한된 얘기일 뿐 데이터베이스 전체에 대한 것은 아니다. 즉, 애플리케이션은 필요에 의해 얼마든지 재개발되고, 폐기, 변경 등이 일어날 수 있지만, 한번 생성된 데이터베이스는 그 기업 활동의 근간이 되기 때문에 쉽게 폐기되지 않는다. 그렇다면 데이터베이스 폐기는 어떤 경우에 일어날까?
<그림 4> 정규조직과 비상조직
데이터베이스 사용이 종료되는 상황으로는 시스템 재개발 또는 재구축 등에 의해 기존 데이터를 새로운 시스템으로 옮기고, 기존 데이터를 백업한 뒤 폐기하거나 또는 시스템 자체의 필요성이 소멸되어 데이터를 백업한 뒤 완전히 삭제 처리하는 경우 등이 있다.
첫 번째는 시스템 재개발이나 재구축에 따른 신규 시스템으로의 데이터베이스 전환에 해당하는 경우로, 앞의 데이터베이스 전환관리 업무 부분에서 이미 설명하였고, 두 번째는 해당 업무 자체가 완전히 없어지는 사례이므로 주로 기업 활동의 대상 분야가 변경되거나 기업의 존속 자체가 없어지는 경우라고 할 수 있다. 예를 들면 유통과 전자제품 조립을 주요 사업부문으로 하고 있던 어떤 기업이 구조조정으로 유통 부문을 완전히 정리해서 접기로 했다면 이제 더 이상은 이와 관련된 데이터베이스의 운영은 의미가 없어지게 되기 때문에 이러한 경우에 해당 데이터베이스가 폐기의 운명을 겪게 된다고 할 수 있고, 또는 회사가 부도나 경영상의 어려움으로 기업 활동을 완전히 종료하기로 했다면 이와 같은 경우에도 데이터베이스는 폐기의 운명을 겪게 될 것이다.
일단 데이터베이스를 폐기할 때는 적절하고 적법한 절차를 거쳐야 하는 것이 보편적이다. 항간에 일부 인터넷 사이트에서 사이트를 폐쇄하면서 회원정보를 다른 곳으로 빼돌려 많은 폐단이 발생하는 경우들을 보았을 것이다. 필자를 포함해서 독자 여러분들도 많은 인터넷 사이트에 회원으로 가입해 본 경험이 있을 텐데, 가입 동의문에는 반드시 고객의 정보를 보호하겠다는 내용의 문구가 포함되어 있는데, 바로 이 점 때문에 데이터베이스를 폐기할 때는 그 마지막 순간까지도 데이터베이스 내에 저장된 정보가 외부로 유출되지 않도록 주의를 기울이고 최선을 다해야 한다. 필자가 전산실에 근무하던 시절에도 이런 문제로 인해 보안 검사를 아주 강력하게 실시하곤 했었는데, 한번은 보안 검사팀이 쓰레기 소각장까지 모두 뒤져서 몇 조각으로 찢어진 문서 조각들을 찾아 퍼즐 맞추듯이 맞추어 내고는 결국 해당 문서의 폐기 처리자를 처벌했던 사례도 있었다. 이와 같이 정보의 폐기는 매우 중요시해야 하는 업무로, 나에겐 필요가 없어진 정보일지라도 다른 어떤 이에게는 매우 유용한 정보가 될 수 있음을 상기해 부주의로 인해 폐기한 정보가 외부로 유출되어 악용되지 않도록 주의해야 한다.
데이터베이스를 폐기할 때는 DBA가 해당 팀장 또는 관리자에게 폐기 사유와 폐기 일정, 방법, 폐기 장소, 확인 절차 등을 기재한 폐기 계획을 작성해 승인을 얻은 후에 계획에 따라 관리자 입회 하에 수행해야 한다.
폐기되는 데이터에 대해서는 보안 문제를 고려하여 어떠한 방법으로도 복구가 불가능하도록 인위적으로 자기적 훼손 방법을 사용하거나(자석으로 훑어 내려 데이터의 자기적 정렬을 파괴한다), 물리적인 손상이나 흠을 내서 판독이 불가능하게 할 수도 있고, 또는 관리자 입회 하에 소각 처리하는 등이 방법이 많이 사용되어 진다. 그냥 포맷하면 되지 않느냐고 반문할 수도 있겠으나, 요즈음은 기술의 발달로 포맷된 디스크도 얼마든지 복구가 가능하기 때문에 폐기 방법의 선택에 주의를 기울여야 한다.
앞에서 얘기한 것처럼 전환이나 폐기에 앞서 데이터는 일단 백업되어 일정기간 보관하게 되는데, 용도가 다한 데이터라 하더라도 법적 또는 재무적 목적에 의해 훗날에 다시 필요로 하게 될 수도 있기 때문이다. 보관기간은 최소 3년에서 5년, 10년 등으로 데이터의 성격이나 중요성 등에 따라 각자의 규칙을 정해 시행하게 된다. 백업된 과거 데이터는 저장 매체에 따라 영구 보관이나 주기적인 매체 교환 등을 통해 별도의 장소에서 보관되는 데, 이를테면 광 디스크 같은 매체는 영구보관용으로, 마그네틱 테이프는 일정기간 보관용으로 많이 사용된다. 도면이나 중요 서류 같은 것들은 오늘날 효용성이 많이 줄기는 했으나 마이크로필름 같은 것도 매우 유용한 저장매체로 활용될 수 있다.
우수한 DBA는 시스템 성능 유지와 직결
지금까지 데이터베이스의 운영부터 폐기에 이르기까지 다양한 운영 유지 업무와 그 특징들을 설명하였다. 처음 원고를 청탁받았을 때는 ‘매우 재미있겠다’는 생각으로 글을 쓰기 시작했는데, 막상 원고를 작성하다 보니 말해야 할 범위가 매우 넓고 내용도 깊어, 어떻게 수위를 조절해야 많지 않은 지면에 그래도 부족하지 않게 얘기를 풀어 낼 수 있을까 하는 걱정이 앞섰다. 사실 항목 하나하나가 너무나 깊은 내용을 갖고 있어 모두를 설명하기에는 지면이 부족했기에 설명의 수위를 조절하다 보니 어떤 부분은 ‘수박 겉핥기’식으로 지나가게 되어 부족한 점이 많다고 여겨진다. 그래도 앞서 서론 부분에서 언급한 것처럼 데이터베이스 관리 업무에 대해 궁금해 하거나 데이터베이스가 생성되어 운영 유지 과정을 거쳐 폐기에 이르기까지 어떤 일들을 하는지 알고자 하는 독자에게는 조금이라도 도움이 되었으면 하는 바람이다.
데이터베이스 운영에 대한 방법론이나 시각 등은 사실 이해 당사자들이나 기업에 따라 매우 다양하게 존재하기 때문에 이 글에서 소개한 내용들이 전부라 할 수 없거니와 또한 대표적인 사례라 말하기도 어렵다. 그래도 해당 업무의 일부는 될 것이기에 이러 이러한 일들이 진행된다고 감히 말한 것이며, 이 글을 읽는 독자들도 이 글에 소개된 업무가 데이터베이스 운영 업무의 전부라는 오해가 없기를 바란다.
다시 한번 말하거니와 데이터베이스 운영은 지식만으로 수행하기에 한계가 있으며, 많은 교육과 경험이 바탕이 되어야 하기 때문에 우수한 DBA를 양성하기 위해 많은 시간과 공을 들여야 한다. 우수한 DBA는 시스템의 성능 유지와도 직결된다고 할 수 있기 때문에 하드웨어에 대한 투자 못지 않게 사람을 키우는 데도 적절한 투자가 이루어져야 함을 다시 한번 강조하면서 이 글을 끝맺는다.
