Web을 위한 SQL Server 고려시 점검사항

Mahnho Han / HAN Consulting

mhan@bora.dacom.co.kr

원본출처 : http://bora.dacom.co.kr/~mhan/ms/web10.html

Microsoft의 SQL Server는 Web 구축시, 특히 Microsoft의 IIS server를 사용하는 NT기반에서는 매우 적합한 데이타베이스이다. 설치하기 쉽고, 상대적으로 비용이 저렴하고, IIS와 상호작용이 잘되며, 더 생각한다면 한 벤더의 제품으로 통일하므로써 지원을 받는데 유리해진다는 측면을 생각할 수 있다.

그러나 아무리 SQL Server가 사용하기 쉽다고 할지라도, SQL Server를 효율적으로 잘 사용하기 위하여는 관리와 튜닝이 필요한 정밀한 제품임을 인식하여야 한다. SQL Server를 효율적으로 사용하려면 제품에서 문제가 발생하기 이전에 프로젝트 시작 단계에서 이들 요구사항을 인지하고 계획을 철저히 세우는 것이 중요하다.

이런 측면에서 프로젝트가 가능한 순조로이 수행되는데 도움을 줄 수 있는 검토사항을 설명한다.

1. 하드웨어와 소프트웨어 컨피규레이션을 점검한다.

SQL Server를 위한 하드웨어 사양을 정의할때는 성능에 영향을 미치는 부분이 어디인가를 아는것이 중요하다. 디스크 사양에 주의를 기울이기 보다는 CPU 갯수와 대용량 메모리에 신경을 쓰는것이 일반적인 현상이다. 일반적으로 디스크와 콘트롤러가 충분 할수록 I/O는 빨라질것이다. 하드웨어 성능을 높이기 위하여 어떻게 하여야 할것인지를 알고 싶다면, Microsoft SQL Web Site의 TPC 벤치마크를 참조하기 바란다. 벤치마크에 사용된 시스템들의 도표를 찾을 수 있을것이다. 이 도표를 보면 현저한 성능을 낸것은 오직 한개의 CPU를 사용하였다.

SQL Server가 처음 설치되면 가장 최소의 환경에 적합하게 설정된 디폴트 컨피규레이션을 사용하게 된다. 예를 들면 16MB 램과 2MB 로 설정된 TEMPDB를 가지는 최소한의 DBMS 환경이다.

반드시 자신의 환경에 적합한 컴피규레이션으로 재설정을 해주어야 한다.

2. 백업과 복구 계힉을 세워라

데이타베이스 백업은 화일 백업과는 다르다. 데이타베이스 백업을 위한 특별한 명령들이 있다. 백업을 수행하고 그것이 정상적으로 재탑재가 되는지 정기적으로 테스트하는 담당자가 있어야 한다. 그러나 이것을 간과하는 경우가 너무 많은것이 현실이다. 내가 아는 한 고객은 자신의 서버에 정보를 제공하는 많은 정보제공업자를 가지고 있었다. 그는 제공업자들에게 당신들이 책임져야할 데이타들이니까 당신들이 백업을 받으라고 주장했다. 당연히 아무도 백업을 받지 않았고 결국 데이타베이스 관리는 그들 고객의 부담으로 남게 되었다. 버젼 7에서는 개선이 되었지만 버전 6.5에서는 데이타베이스가 덤프를 쏟고 있을때 성능이 현격히 떨어진다는것을 알아야 한다.

모든 사고의 경우에 대비한 계획을 문서화하여 가지고 있어야 한다. 하드웨어가 손상되었을 경우 대체할 하드웨어는 어떻게 구할 것인가? 백업받은 테이프를 유지 관리할 사람은 누구인가? 사고가 발생하기 전에 계획을 세워두어야 발생한 문제를 조용히 효과적인 방법으로 처리할 수가 있는것이다.

3. 유지관리 스케쥴을 세워라

SQL Server는 유지관리를 위하여 정기적으로 수행되어야 할 명령어가 몇가지 필요하다. 이들 명령어는 성능유지를 위해서 그리고 데이타베이스 파손에 대비하여 필요한 것이다.

예를 들어 UPDATE STATISTICS 명령어는 테이블들의 통계치를 갱신하도록 한다. 이 통계치는 SQL 문이 수행될때 어떤 인덱스를 사용할지 결정하는데 이용된다. 이 명령어를 언제 어떤 주기로 수행할것인지는 데이타 추가와 갱신량을 고려하여 결정하여야 한다. 이 명령어를 정기적으로 수행시켜주지 않는다면 성능이 현격히 떨어질 가능성이 많다.

DBCC (database consistency check command) 명령어는 하드 드라이브의 chkdsk와 같은 역할을 한다. DBCC는 데이타베이스가 파손되지 않았는지 내부점검을 수행한다. DBCC는 UPDATE STATISTICS처럼 자주 수행하면 안되지만 적어도 매월 한번씩은 수행하는것이 바람직하다. 데이타베이스 크기에 따라서 이 명령어 수행시간이 몇시간이 될수도 있다. 또한 DBCC 수행중에는 데이타 갱신작업을 금지시키는것이 바람직하다.

4. 스키마 설계를 정확히 하여야 한다.

Web site들은 계속 변경되는것이 속성이지만 데이타베이스 스키마는 Web page처럼 쉽게 변경할 수 없다. 바람직한 설계는 어떤 정보가 저장되고 그것이 어떻게 사용될것인가를 명확히 정의하고 있어야 한다. 잘 설계된 스키마는 이용하기도 유지관리하기도 용이하다. 경솔하게 잘못 설계된 스키마는 이용하기 어렵거나 아예 이용 불가능하게 되고 기능적인 요구에 대하여 적응할 수 없게 되는것이 다반사이다.

5. 강력한 검색?

Web site 기능중 일반적인것은 저장된 데이타를 검색하는 강력한 써치능력이다. 강력한 검색기능을 위하여는 검색시 보다 많은 테이블과 로우를 찾아야 하고 결과적으로 검색시간이 오래 걸리게 된다는것을 생각하여야 한다. 아무리 훌륭한 코딩을 하더라도 데이타베이스의 모든 테이블과 로우를 검색하는 쿼리는 느려지게 될것이다.

실질적으로 유용한 한계를 쿼리기능에 설정하도록 노력하여야 한다. 몇개의 잘게 쪼개어 검색하는 강력한 검색기능을 고려할 수도 있다.

6. 적절한 인덱스를 사용하도록 한다

적절한 인덱싱은 성능에 매우 중요한 요인이다. 테이블에 인덱스 생성할때는 어떤 컬럼으로 인덱스를 만들것인가, 또 클러스터 인덱스로 하여야 하는가 여부를 판단하여야 한다. 클러스터 인덱스는 데이타 자체를 정렬시키기 때문에 쿼리시 현저한 성능향상을 볼수 있다. 그러나 클러스터 인덱스는 테이블당 한개만 정의할 수 있다.

7. 서버 보안대책을 세우라

sa 는 SQL Server 를 통제하는 슈퍼바이져 ID 이다. 따라서 sa 하에서 스크립트를 수행하는 것은 바람직하지 못하다. 대신에 작업을 수행하는데 필요한 최소한의 권한을 가지는 ID 를 만들어 사용하여야 한다. sa 패스워드는 SQL Server 설치후 즉시 변경하여야 한다.

8. DBA 를 확보하라

시스템이 완성되어 업무에 활용되는 상태에서도 계속적으로 성능을 감시하고 유지관리 절차와 백업의 결과를 점검하여 순조롭게 작업이 수행되는것을 확인하는 담당자가 있는것이 바람직하다. 그렇다고 반드시 이를 담당할 풀타임 직원이 필요하다는것은 아니다. 얼마간의 비용을 지불하면 호스트 제공업체에서 이러한 서비스를 제공할 수도 있을것이다. 어쨌든 갑자기 이런 담당자가 필요하게 되기 전에 담당자를 해결하여 두는것이 바람직하다.