용량 및 스토리지 관리

개요

이 장에서는, 시스템의 용량, 처리량, 성능 등의 요구사항에 맞추기 위해, 데이터베이스 관리자가 물리적 저장소를 어떻게 설정하고 관리해야 하는지에 대해 소개한다.

소개

데이터 자체와 서버 레이어에 접근하는 트래픽 간의 적절한 균형을 유지하는 것은 데이터베이스 관리자가 해야 하는 중요한 일 중 하나이다 (여기서 '서버 레이어' 란 파일이나 하드웨어 등과 같은 데이터베이스 스토리지 구성요소를 일컫는다). 그런데 데이터베이스 관리라는 것은 끊임없이 운영과 아키텍처 상의 변화 사이클 상에 있을 수 밖에 없다. 여기에서는 3 계층 응용 프로그램의 맨 마지막 계층인 스토리지 구성요소 레벨의 용량 계획과 최적화 방안에 대해 기술하기로 한다.

필요한 리소스

이 가이드는 유능한 네트워크 관리자가 네트워크 용량 계획에 도움을 줄 수 있다는 것을 전제로 한다. 또한 이 가이드는 인쇄되었거나 사람들 사이에서 통용되는 하드웨어 사양을 기반으로 하였다. 적절하게 용량 계획을 잡고 이를 수행하기 위해서는 앞에서 언급한 인력과 사양 모두 필요하다.

이러한 리소스가 필요한 것은 거기에 농축되어 있는 지식 때문이다. 리소스에 접근할 수 없는 상태에서 응용 프로그램 인프라를 구축한다는 것은 상상할 수 없다. 네트워크 관리자나 하드웨어 리소스는 응용 프로그램의 요구에 부합하는 기술적 사항을 제공해 줄 수 있다.

과정 흐름도

용량 계획 흐름도(그림 6.1)는 인프라를 검토할 때 어떤 스텝을 밟아야 하는지를 상세하게 제시하고 있다. 이러한 검토는 정기적으로 이루어져야 한다. 그렇지만 얼마나 자주 할 것인가는 순전히 처해 있는 환경에 따라 달라질 것이다.

용량 계획 흐름도에서 눈 여겨 볼 것은 '응용 프로그램이 향후에도 현재 성장세를 계속 유지할 것인가?' 라는 질문이다. 이 질문은 응용 프로그램의 기간 성장세가 이 후에도 계속 될 것인지를 판단하기 위한 것이다. DBA로서는 판단하기 참 힘든 문제이다. 응용 프로그램에 가중되는 부하를 통제하기 힘든데 어떻게 향후의 부하를 추정할 수 있을까? 그렇기 때문에 특정 징후(signs)들을 보고 판단해야 하는 것이다.

응용 프로그램 개발팀에게 차기 배포는 언제쯤 나올지를 물어보자. 차기 배포는 더 많은 사용자를 끌어들일 새로운 기능이 있는가? 이런 새로운 기능이 더 많은 리소스를 사용하는가? 응용 프로그램에 최적화된 부분이 있는가?

계획 단계부터 CPU, 메모리, 디스크, 네트워크와 같은 모든 서버 리소스를 검토해야 한다. 용량 계획의 일정 속에서 응용 프로그램의 부하 양상을 결정하려면, 반드시 앞에서 언급한 요소들을 고려해야 한다.

시스템 분류

표 6.1은 표준화된 시스템 분류를 도식화한 것이다. 이 표는 트랜잭션 볼륨, 읽기/쓰기, 데이터 사이즈 등을 다루는데 있어 일반적인 레퍼런스로 참고할 수 있는데, 여기서의 분류코드는 시스템을 위해 어떤 권고사항이 필요한지를 결정하는데 도움이 된다. 즉 시스템을 단순히 '리포팅을 위한 시스템'이라고 얘기하는 것보다는 다른 시스템과 비교를 통해 더욱 정확한 자료를 제공할 것이다.

표 6.1 표준 시스템 분류표

여기서 제시하는 코드는 단순히 하나의 예를 보이기 위한 것이다. 시스템에 적합한 코드를 작성하기 위해서는 다음과 같은 방법을 준수한다:

데이터베이스 사이즈 측정은 위 도표의 어느 레벨에도 적용할 수 있다. 만약, 테라 급 사이즈의 데이터를 가지고 있다면, 분류코드 앞에 "1T"을 붙이면 된다: 1T 7000 R100. 만약 100 G사이즈의 데이터라면, 분류코드는 다음과 같을 것이다: 100G 5 R20. 시스템의 용량을 계획하는데 있어 데이터의 사이즈 증가율을 하나의 중요한 요소로서 고려해야 한다(증분율 - the percent delta "%Δ"). 이 요소는 시스템의 상황에 따라 다를 수 있는데, 이것은 TPS의 증가량 혹은 전체 사이즈의 증가량을 백분율로h5>

용량계획의 핵심 내용은 다음과 같다:

용량계획은 굳이 복잡한 프로세스를 따를 필요가 없지만, 정확한 계량과 문서화된 증빙 등을 필요로 하는 세심한 작업이 요구되는 것이 사실이다. 그럼에도 불구하고 시스템 크기가 증가할수록 용량계획은 점점 복잡해진다. 용량을 증가하는데 많은 비용이 들어야 할 경우는 이러한 용량 계획은 더욱 중요해지는데, 이는 각 기업마다 전산비용이 제각각이기 때문이다.

전통적인 용량계획은 일정한 서버 부하를 견디기 위해 얼마나 많은 용량의 하드웨어가 필요한지를 제시한다. (응용 프로그램이 하드웨어의 장점을 전적으로 이용한다는 가정하에) 시스템이 커질수록, 용량계획과 같은 작업은 끊임없이 계속 될 것이며, 이 과정을 통해 더 많은 경험을 체득하게 되어 마침내 해당 시스템이 아주 적절하고 세련되고 향상된 프로세스를 정의할 수 있게 될 것이다. 이 것은 전적으로 시스템에 축적된 베이스라인 레코드에 의존한다.

하드웨어 성능과 구성을 규정짓는 세 가지 요소는 다음과 같다:

세 가지 요소 중 세 번째 내용이 가장 중요한데, 응용프로그램 디자인을 위해서는 본질적으로 다음과 같은 두 가지 방법 중 하나를 선택한다.

최대 확장성과 성능을 기대한다면, 위의 두 방법을 모두 적용해야 하며, 다른 개선점이 없는지를 확인하기 위해, 정기적으로 시스템을 평가해야 한다. 이러한 방법만이 최선의 결과를 가져올 수 있다.

데이터를 가져와 조작하여 입력하는 것이 시스템의 중요한 토대라면, 전체적인 아키텍처와 데이터베이스 서버의 유지관리에도 반드시 방점을 찍어야 한다. 이는 그러한 시스템일수록 더욱 집중화된 리소스를 필요로 하기 때문이다. 아키텍처 디자인과 최적화는 점층-반복되는(iterative) 과정으로서, 시스템이 안정화될 때까지는 관리자에게 있어서 가장 중요한 업무 중의 하나이다.

시스템 규모가 상대적으로 소규모 시스템이라면, 하드웨어 제공 업체와 함께 용량계획을 하는 것이 좋다. 세세한 용량 계획 작업이 오히려 업무 부하로 작용할 수도 있다. 그렇지만 여기서 제시한 용량 계획의 스텝들을 따라가는 것도 시스템에 대해 몰랐던 많은 것을 밝혀낼 수 있는 계기가 될 수도 있으므로 하나의 좋은 방안이 될 수 있다. 그러나?1000 G100 R80?정도의 소규모 시스템에서는 좀더 축약된 계획을 잡아 적용할 수도 있을 것이다.

용량 계획에 있어 가장 좋은 실천 방법은 정기적으로 시스템을 모니터링 하는 것인데, 하드웨어적인 서버 성능이 뒷받침하는 것과 응용 프로그램이 지원하는 것과의 불일치를 정확히 파악하는 것이 중요하다. (5장 : 모니터링과 컨트롤 참조). 그런 다음 모니터링을 통해 발견한 내용과 요구사항을 고려하여, 구매를 위한 판단 기준을 하드웨어 제공업자에게 제시하면 된다.

좀더 구체적인 하드웨?? 2000 관리OLOR: #78a3ff">CPU와 메모리 관리

용량과 관련하여 관리해야 하는 두 가지 중요한 구성요소가 바로 CPU 와 메모리이다. 이 것은 모든 윈도우 2000 서버 관리에서 아주 중요하다.

CPU 용량 계획

프로세서의 용량계획은 아주 간단명료하다. 프로세서 사용률을 모니터하면 된다. (\Processor(_Total)\% Processor Time). 평균 50% 이상의 사용률을 기록하고 있거나, 현재 사용률이 90% 이상이면서 사용률 정점이 자주 보이거나, 사용률이 급격히 증가하여 일정기간 지속될 때는 프로세서를 추가하든지 아니면 더 빠른 프로세서로 교체해야 한다.

In general, the processors you choose should be able to deliver the speed implied in your other system purchases.?(일반적으로 다른 시스템을 구매하면서 넌지시 프로세서를 포함시켜 빠르게 도입되도록 할 수도 있다.)일반적으로 프로세서는 다른 시스템 견적서에서 명기되었던 만큼의 속도를 제공해야 한다. 만약 시스템이 CPU 자원을 많이 소모하는 작업 (CPU-Intensive)이 많거나 그런 작업에 특화되어 있다면, 시스템을 모니터링하면 할수록 CPU 의 속도를 점차 중요하게 인식하게 될 것이다. CPU 자원을 많이 소모하는 작업의 예로는, 대량으로 자주 일어나는 데이터 변환 서비스 (Data Transformation Service)나 과학연산이나 회계 등과 같이 많은 수치 연산이 필요한 작업이 있다. SQL 서버는 CPU 자원을 많이 소모하는 응용 프로그램이므로 고속의 대용량 캐시가 장착된 프로세서를 구할 필요가 있다. 프로세서라면, 언제나 가장 빠르고 가장 최근에 나온 것을 구하는 게 좋다. 그래야만, 서버의 다른 구성요소들이 제대로 잘 동작할 수 있게 되는 것이다.

SQL 서버 전용으로 서버를 사용한다면, 모든 프로세서들을SQL 서버가 이용할 수 있도록 한다. 만약 SQL 서버와 커머스 서버가 동일한 장비에서 구동되어 각기 다른 서비스를 함께 제공해야 한다면, SQL 서버가 일부 프로세서만을 사용하는 것을 고려할 수도 있다. 그렇지 않다면, 애초에 설계되었던 대로 SQL 서버와 윈도우 운영체제가 프로세서들을 골고루 이용하는 것을 권장한다.

메모리 계획

여타 하드웨어들은 시스템의 용량에 관계된 것이지만, 메모리는 데이터 접근 최적화와 관련을 맺고 있다. SQL 서버는 실행계획이나 데이터 페이지 등을 저장하기 위해 메모리를 사용한다. 충분한 메모리가 없으면, 데이터를 읽기 위해 과다한 디스크 I/O를 불러 일으킬 수 밖에 없다. 시스템에서 데이터 읽기가 많이 일어난다면 메모리를 적당히 늘려 디스크 I/O를 줄일 수 있는데, 더 많은 메모리는 더 많은 캐시 공간을 제공하기 때문이다. 불충분한 메모리량이나 과부하된 메모리는 결국 페이징을 부추긴다. 메모리는 SQL 서버에서 관리자가 주의 깊게 모니터링 해야 하는 가장 중요한 요소 중의 하나이다.

의사결정시스템(DSS, 혹은 Decision Support System) 같이 쓰기보다 읽기가 중요한 시스템들은 메모리가 많으면 많을수록 좋다. 이 경우, 메모리는 디스크 I/O를 상쇄시킬 수 있으며 많은 량의 메모리는 높은 성능을 위해 필요한 디스크나 스핀들의 수를 줄여 줄 수 있다.

반면, 실시간 시스템(OLTP, Online Transaction System) 같이 읽기보다 쓰기가 중요한 시스템들은 메모리의 중요성을 간과할 수는 없지만, 메모리보다는 디스크 스핀들이나 빠른 디스크 컨트롤러를 통해 더 많은 효과를 얻을 수 있다.

시스템의 최대 성능을 얻으려면 어떤 리소스가 가장 중요한지 확실히 아는 것이 중요하다.

디스크 용량 계획

데이터 저장소에 관련하여 중요하게 알아야 할 점은 디스크 개수가 디스크 사이즈보다는 훨씬 더 중요하다는 것이다. 사이즈가 큰 디스크에 모든 데이터를 담아 둘 수는 있겠지만, 필요한 데이터를 가져올 디스크 헤드는 하나밖에 없다는 점을 알아야 한다. 디스크 헤드는 많을수록 좋다. 그래서 추가 하드 디스크를 계획할 때는 필요한 사이즈를 먼저 체크하고 나서, 되도록 많은 시간을 얼마나 많은 디스크 헤드가 필요한지를 판단하는데 투자하는 것이 좋다. 예를 들어, 시스템이 많은 량의 트랜잭션을 처리해야 하는 경우, 좀더 많은 디스크 헤드를 추가함으로써 시스템의 성능을 증가시킬 수 있다. 물론, 시스템을 지탱할 충분한 메모리와 CPU가 있다는 가정하에서 말이다.

하드웨어 견적에는 디스크 사이즈 뿐만 아니라 디스크의 개수도 정확히 명시하도??러 개의 디스크를 선택하는 것이 효과적이다. 외장형 저장소의 경우라면, 가장 빠른 어레이 컨트롤러를 선택하고 덧붙여 다중 채널을 가진 것을 고르도록 하자. 만약 병목현상을 일으키는 컨트롤러 카드가 있고 디스크 스핀들이 많은 경우라면, 이를 충분히 지원할 수 있을 만큼 빠른 컨트롤러 카드를 구입하는데 투자해야 한다. 얼마나 좋은 성능을 낼 수 있는가 하는 것은 컨트롤러의 품질과 시스템의 I/O 양상에 비례한다.

실시간 시스템(OLTP)은 하나의 디스크 컨트롤러에 되도록 많은 디스크를 갖도록 구성하여 데이터를 읽고 쓰는 헤드의 수가 많아지도록 하여 컨트롤러 병목을 제거할 수 있다.

의사결정시스템(DSS)은 대부분의 쿼리들이 순차적 읽히므로 작은 수의 디스크에 많은 컨트롤러를 갖도록 구성하는 것이다. 의사결정시스템에서 I/O 성능을 향상시키는 좋은 방법으로는 메모리 추가도 한가지 방법이라는 점을 추가로 인식해야 한다.

이와 관련한 좀더 자세한 자료는 SQL 서버 온라인 설명서를 참고하거나 인사이드 마이크로소프트 SQL 서버 2000 나 마이크로소프트 SQL 서버 2000 관리자의 벗이 도움이 될 것이다.

팁

데이터를 중심으로 하는 시스템 환경에서, 데이터베이스 서버는 많은 클라이언트와 상호작용을 충분히 지탱할 수 있어야 한다. 그러기 위해, 시스템의 중요성과 사용 빈도에 따라 하드웨어에 상대적으로 많은 비중의 투자가 이루어지는데, 이를 위한 가장 좋은 방법은 다음과 같다:

이러한 지침은 대부분의 상황에 잘 들어맞지만, 5000클래스나 그 이상의 대규모 저장소를 요구하는 시스템에서는 예외이다. 그런 시스템의 경? 드물기 때문이다.

디스크 컨트롤러(Disk Controllers)

캐시 (Cache)

모든 쓰기 캐시(write caching)가 데이터베이스 서버에 안전한 것은 아니다. 컨트롤러가 통제할 수 없는 갑작스런 컨트롤러 전원 중단에 대비해 보드에 장착된 배터리라든지 미러된 캐시, 혹은 ERC(error checking and correcting ) 메모리 등의 안전장치를 가지고 있는지를 확인한다. 이러한 쓰기 캐시나 데이터의 손실을 막기 위한 조치들이 강구되어 있는지 확인하기 위하여 하드웨어 제공 업체에 문의하는 것이 필요하다. 이런 안전장치를 하드웨어 제공 업체에서 보증할 수 없다면 차라리 쓰기 캐시를 쓰지 않는 것이 현명한 방법이다.

어레이 가속 캐시(Array accelerator cache)는 통상 디폴트 값인 50:50 읽기-쓰기 비율로 설정되는데, 이것을 그대로 사용해도 무방하다. 물론 시스템에 맞는 값으로 읽기나 쓰기 비율을 바꿀 수도 있다. 이 때 알아둬야 할 것은, 쓰기 값을 0 이상으로 하면 쓰기 캐시가 활성화된다는 점이다.

장애조치 클러스터를 사용하고 있다면, 미러된 캐시를 쓰는 것도 한가지 방법이다.

좀더 상세한 자료는 마이크로소프트 KB 사이트 ( http://support.microsoft.com ) 의 Q86903 항목을 찾아보길 바란다.

채널 (Channels)

어레이 구성에 있어, 디스크 컨트롤러가 다중 채널을 지원한다면, 이 것이 정상적으로 활용되고 있는지 확인한다. 빠른 채널은 I/O 성능 향상에 많은 영향을 미친다.

SCSI 어레이 컨트롤러에서 채널 구성을 확인하기위해선, 제공 업체가 제공하는 툴을 가지고 직접 확인해보는 길 밖에 없다. 이런 툴을 사용할 때는 각별한 주의가 필요한데, 확인이나 저장 등을 누른 후 드라이브에 저장된 데이터가 손실된다면, 돌이킬 수 없는 상황이 벌어질 수도 있기 때문이다.

NTFS 할당 단위

SCSI 드라이브:?새 하드 디스크를 디스크 관리자에서 포맷 할 때, 최적화된 성능을 기대한다면, 할당 단위나 블록 사이즈를 깊이 고려해야 한다. 할당 단위나 블록 사이즈를 크게 함으로써 현저한 성능 향상을 기대할 수도 있지만, 물리적 디스크의 크기에 준하여 디폴트 값이 설정된다. 일반적으로 SQL 서버를 사용하는 시스템에서 권고할만한 블록 사이즈는 64KB인데, 이렇게 하면 서로 다른 할당 단위에 걸쳐 형성된 블록으로 인해 분리 I/O (Split I/O)가 생길 수 있는 가능성을 줄여 준다. 이 점은 귀담아 둘만한 사항이긴 하지만, 디스크의 포맷은 사용하고 있는 스토리지의 종류나 경우 따라서는 백업 소프트웨어에 따라서도 달라진다는 점을 꼭 기억해두자. 만약 운영 중인 시스템에서 블록 사이즈를 변경하려고 한다면, 반드시 테스트 환경에서 베이스라인을 설정해보고, 또한 테스트가 끝난 후에라도 한번 더 모니터링을 해봐야 한다.

용량 계획과 구성에 관한 더 자세한 사항은 인사이드 SQL 서버 2000 을 참고하고 하드웨어에 대한 상세한 정보는 해당 제공 업체의 고객지원사이트를 살펴보기 바란다.

데이터 저장소 관리

디스크를 구성할 때 하드웨어 다이어그램을 작성하면, 데이터 파일의 레이아웃에 관한 정책에 맞게끔 하드웨어를 설정하는데 도움이 된다. 그 때 염두에 두어야 할 사항이 몇 가지 있다. 즉, 시스템에서 꼭 필요한 만큼의 디스크 사이즈말고는, 디스크의 사이즈보다는 개수에 더 신경을 써야 한다는 것이다. 이 점은, 하드웨어 견적 배치할 것이냐 하는 레이아웃만큼이나 중요한 사항이다.

레이드 (RAID)

RAID (Redundant Array of Independent Disks)는 여분의 물리적 디스크에 복사본을 두어 데이터를 보호하는 것인데, 만일 하드웨어적인 결함으로 인해 디스크가 손상되더라도 원래 데이터를 원상 복구할 수 있도록 하기 위한 것이다. 데이터베이스는 반드시 하드웨어적인 RAID로 구성한다. 소프트웨어적인 RAID는 CPU 시간을 점유하므로, SQL 서버 성능을 저하시킨다. 주요한 RAID 레벨로는, 패러티 있는 스트라이프(RAID5)와 미러링된 스트라이프(RAID 0+1, RAID10) 등이 있다. 일반적으로 가장 권고할만한 옵션은 RAID 0+1이다. RAID5 역시 특정 상황에서 사용할 수 있지만, RAID 0+1에 비해 신뢰성이 떨어지고 값이 비싼 단점이 있다.

RAID 5에서는 데이터를 쓸 때, 실제로는 4번의 I/O가 일어나는 셈인데, 데이터와 패러티 블록을 각각 읽고 나서 다시 데이터와 패러티 블록을 갱신하기 위한 쓰기 동작이 일어나기 때문이다. 속도가 느려지는 것은 다음과 같은 두 가지 이유 때문이다. 첫째로 각각 읽고 쓰는 단계가 하나씩 종료되어야 다음 단계가 시작될 수 있도록 순차적으로 수행된다. 둘째로, 많은 수의 다른 트랜잭션이 디스크 리소스를 차지하기 위해 경쟁하는 와중에 이러한 오퍼레이션이 일어나므로 오히려 원활한 트랜잭션 작업에 지장을 주는 것이다. 반면, RAID 0+1에서는 쓰기 동작이 주 디스크와 미러 디스크 양쪽에서 동시에 한번의 오퍼레이션으로 일어난다. 물론 시스템은 양쪽 디스크에서 모두 쓰기 동작이 마칠 때까지 기다려야 하지만, 그래도 동시에 일어난다는 것이 다르다.

RAID 5의 눈에 띠지 않는 비용 (그러니까, 패러티를 위해 하나의 여분 디스크가 필요하다는 것과는 다른 의미에서)은 쓰기 성능이 낮다는 점인데, 이는 입력될 수 있는 레코드의 수, 쓰기 동작이 이루어지는 과정 등의 영향 때문이다. RAID 5는 처음에는 아주 경제적으로 보일지는 모르겠지만, 이 후 시스템의 생산성을 높이기 위해 들은 수천 불의 추가적인 예산이 투입될 수도 있다.

RAID 5에서 얻을 수 있는 단 하나의 이점은 좀더 많은 저장 공간을 얻을 수 있다는 것 밖에 없다. 결국, 이렇게 질문할 수 있다: 가능한 한 소규모의 하드웨어(물론 어느 정도 재해 복구의 기능은 있다고 전제를 하고)로 많은 량의 데이터를 저장할 공간을 원하는가? 아니면, 빠르고 높은 수준의 재해 복구를 원하는가? 그러므로 사내에서 사용하는 소규모 시스템에서도 데이터 파일의 사이즈가 얼마나 되어야 하는지 면밀하게 검토해야 한다.

똑같은 수의 하드 디스크로 시스템을 구성한다면, RAID 0+1이 RAID 5보다 빠르다. 디스크 수를 추가할수록 RAID 0+1의 I/O 성능은 선형적으로 증가한다. RAID 0+1에서 데이터 읽기는 주 디스크에서나 미러 디스크에서도 일어나기 때문에 더 많은 수의 디스크가 주어진다면 동시에 일어날 수 있는 읽기 동작은 그만큼 많아지는 것이다.

데이터는 백업 본을 이용 복원할 수 있지만 손상된 디스크가 불러일으킬 수 있는 여러 영향에 대해서도 알아둘 필요가 있다. RAID 5로 구성된 세트에서 2개의 디스크가 오류를 일으키면, 데이터베이스는 동작을 멈춘다(만약 오류 복구 체인으로 묶여 있는 동기화된 대기 디스크가 있다면 그렇지 않을 수도 있다) RAID 0+1에서는 미러링된 세트의 양쪽에서 동시에 디스크 오류가 일어날 경우에만 데이터베이스가 멈추는데, 이런 상황이 발생할 가능성은 임의적인 변인을 고려한다 하더라도 대략 5.3 퍼센트에 불과하다. RAID 5 시스템에서 디스크 하나에서 불량이 일어나면 읽기 성능은 급격히 저하된다. 오류가 발생된 디스크에 읽기 및 쓰기 요청이 보내지면, 패러티 그룹의 모든 드라이브에서는 검증 프로세스가 일어나기 때문이다. 이러한 급격한 성능 저하는 디스크를 교체하여 완전히 RAID5가 정상적으로 재구성되기 전까지 계속 된다. RAD5의 재구성과정에서 시스템은 오류가 발생된 디스크로 보내지는 요청으로 인해 상당한 시스템 부하가 일어나게 된다.

RAID 0+1은 주 디스크나 미러 디스크의 어느 쪽으로부터든지 데이터를 읽을 수 있으므로 하드웨어 오류 시 성능 저하는 최소화할 수 있다. 하드웨어 오류 시 읽기 성능의 저하는 아주 미약하게 일어나는데, 그것도 데이터를 저장하고 있는 특정 세트에서만 그렇다. 또 RAID 0+1은 주 디스크나 미러 디스크를 동시에 접근하여 읽을 수 있다. 이 것은 동일 I/O 동작이 동시에 수행되는 것을 의미하지는 안는다. 동일 디스크에 대해 하나 이상의 읽기 요청이 일어나면, I/O 동작은 미러된 세트의 양쪽으로 분산되는 것이다.

구성 표준화

서버가 많은 경우라면 표준화는 더더욱 절실하겠지만, 표준화는 어쨌거나 모든 환경에서도 도움이 된다. 서버의 구성을 표준화하려면, 디폴트 값으로 유지하지 않을 구성 값 리스트를 만들고 이를 문서화한다. 그런 다음 이것을 새 시스템을 구성할 때 필요한 표준 구성으로 만들어놓으면 된다. 물론, 사내 환경은 표준과는 많은 차이를 가지고 있을 것이다. 그렇다면, 표준과 문제가 되는 시스템과의 차이점을 단순히 문서화하고서, 읽기 전용으로 만들어서 사내 어디에서나 접근 가능한 곳(가령, 사내 공용 웹 스토리지 등)에 올려 놓고 다수의 서버를 관리하는데 참고가 되도록 한다.

디스크와 같은 저장소는 드라이브 문자를 표준 화해놓으면 아주 편리하다. 표 6-2에서는 그 한 예를 보여주고 있다.

표 6.2 표준 드라이브 문자 할당

응용 프로그램 코드의 유연성을 보장하려면 네트워크 드라이브는 UNC(universal naming conventions)로 표기한다.

아무리 세심하게 표준화하더라도, 예외란 역시 일어나는 법이다. 우선 문서화부터 진행해야 한다. 목표는 약 90 퍼센트 정도를 표준화하는 것이고 나머지 10 퍼센트는 정말 기억하기 용이할 것이다.

구성 변경

일단 RAID레벨이 결정되면 하드웨어의 구성을 송두리째 바꾸기 전까지는 쉽사리 그 구성을 바꾸기 힘들다. RAID 구성을 바꾸면 거기에 있는 모든 데이터는 소실되므로, 일단 구성을 바꾸기로 했다면, 시스템 백업이 확실한지 점검하고, 재구성까지의 충분한 다운타임이 확보되는지 안으면 시스템을 대신할 수 있는 대기 서버나 테스트되고 검증된 원상복구 계획이 있는지를 확인한다. 또한 재구성 하기 전에 시스템의 데이터 파일을 어떻게 배치할 것인지에 대한 레이아웃 계획이 구체적으로 서 있어야 한다. 그런 다음, 전체적인 요구사항에 맞게끔, 디스크를 어느 어레이에 할당하고, 어레이를 어떻게 설정하며 논리적 드라이브를 어떻게 포맷하여 레이아웃할 것인지를 결정하는 것이다.

데이터베이스 파일 배치

데이터베이스 파일의 배치에 관련하여 몇 가지 팁과 권장 방법은 다음과 같다:

SCSI, SAN (storage area network): 가장 중요한 고려사항은 디스크의 수(달리 말해, 스핀들의 수)와 디스크 속도이다. 이런 까닭에 해당 데이터베이스의 요구사항을 미리 파악하고 하드웨어 요구사항과 레이아웃을 디자인하면 좋다. 분명한 디자인 계획이 서있기 전에는 하드웨어 견적을 내는 것에 주의를 기울여야 하는 것이다.

어떤 데이블이 매우 자주 동시에 접근해야한다면, 이 테이블은 별도의 파일 그룹에 넣어 I/O를 분산하는 것이 좋다. 대규모의 시스템에서 이런 배치가 가져오는 성능 향상이 현저하다는 것을 알 수 있다.

만약 디스크 I/O가 문제이고 더 이상의 디스크를 세트에 추가시킬 수 없는 상황이라면, 별도 파일 그룹에 서로 다른 디스크에 넌클러스터 인덱스를 배치하는 것을 고려해보자. 이렇게 하면 파일 그룹 간의 I/O가 분리되어 성능이 향상될 것이다.

사용량과 빈도에 따라 테이블을 그룹화하여 서로 다른 파일 그룹에 배치하면 가능한 한 많은 수의 오퍼레이션이 동시에 일어날 수 있게 된다. 하지만 유지 관리적 관점에서 테이블을 파일 그룹으로 형성하면 앞에서와 같은 성능향상은 기대하기 힘들다.

여분의 스핀들 확보가 가능하다면, 되도록이면 데이터베이스를 여러 파일 그룹에 걸쳐 저장하도록 한다. 이렇게 하면, 리인덱싱과 같은 관리업무를 훨씬 빠른 시간 내에 끝낼 수 있고, 데이터베이스를 복구할 때 빠른 시간에 복원할 수 있다는 점이다.

클래스1000A보다 적은 규모의 시스템에서는 , "파일 자동 증가" 옵션을 활성화해도 좋다. 반면, 그 이상의 시스템에서는, 데이터파일이 증가할 때, 트랜잭션이 데이터베이스가 증가할 때까지 기다려야 한다는 점을 기억해야 한다. 100GB 이상의 OLTP 시스템에서 자동 증가를 10퍼센트로 설정해놓으면, 피크 타임 시 공간이 모자랄 경우, 10GB의 공간을 새로 할당하는 시간 동안 온라인 사용자들이 대기해야 한다. 소규모이거나 쿼리 부하가 그렇게 심하지 않은 시스템에서는 별 문제 될 것이 없지만 말이다. 참고로, 기가바이트 당 할당 속도는 1GB를 복사하는 속도로 측정해 볼 수 있다.

그러한 시스템에서 가장 좋은 방법은 데이터베이스의 증가 속도를 미리 예견해놓고서 거기에 맞춰서 스케줄을 걸어 데이터베이스 파일의 크기를 증가시키는 것이다. 그렇게 하지 않으려면, 적당한 증가량을 선택하여 너무 손이 많이 가지 않게 하거나 너무 증가량이 작아 잦은 데이터베이스 확장이 일어나지 않도록 하는 것이다.

이상적인 방법으로는 6개월에서 12개월 단위로 증가량을 예측하여 데이터베이스를 확장하거나, 아니면 실제에 근접한 데이터베이스의 사이즈 또는 가용한 하드웨어나 예산에 부합하는 증가세에 기준을 두고 플랜을 잡는 것이 가장 좋다. 관리적 측면에서 보면 자동 증가는 업무를 수월하게 해주지만, 거기에는 다음과 같은 두 가지 위험이 있다는 것도 알아야 한다:

트랜잭션 로그가 꽉 차거나 로그가 더 이상 자동증가 할 여유가 없는 경우에도 데이터베이스는 동작을 멈춘다. 이를 복구하기 위해선 먼저 트랜잭션 로그를 잘라내거나 축소시켜 문제를 해결할 수 있는지를 알아본다.

파일그룹에 여러 파일이 있는 상태에서 또 하나의 파일을 더 추가한다면, 파일그룹이 적절하게 각 파일에게 빈 공간을 할당할 수 있도록(proportional fill)각각의 파일 사이즈를 좀더 늘려야 할 것이다.

파일 및 파일 그룹 사용

파일 그룹은 각 파일 그룹에 있는 모든 파일에 대해 "균형 잡힌 채우기 전략"( proportional fill strategy)을 사용한다. 마이크로소프트 SQL 서버 2000은 파일 그룹에 데이터를 쓸 때 첫 번째 파일에 데이터가 모두 차면 다음 파일에 쓰지 않고, 각 파일의 빈 공간이 서로 균형 잡히도록 데이터를 기록한다. 예를 들어, 파일 f1에 100MB의 빈 공간이 있고 파일 f2에 200MB의 빈 공간이 있으면, 파일 f1에서 하나의 익스텐트가 할당되고 파일 f2에서 두 개의 익스텐트가 할당되는 식이다. 이렇게 하면 거의 동시에 두 파일이 꽉 차며 간단한 스트라이프가 수행된다.

파일 그룹의 모든 파일이 꽉 차면, SQL Server가 라운드 로빈 방식으로 한 번에 하나의 파일을 확장하여 데이터를 추가한다. 단, 데이터베이스가 자동으로 증가하도록 설정된 경우에만 가능하다. 예를 들어, 파일 그룹이 3개의 파일로 구성되고 모두 자동 증가하도록 설정되었다고 가정하자. 이 때 파일 그룹의 모든 파일이 꽉 차면 첫 번째 파일만 확장된다. 첫 번째 파일이 꽉 차고 파일 그룹에 더 이상 데이터를 쓸 수 없게 되면 두 번째 파일이 확장된다. 두 번째 파일이 꽉 차고 파일 그룹에 더 이상 데이터를 쓸 수 없게 되면 세 번째 파일이 확장된다. 세 번째 파일이 꽉 차고 파일 그룹에 더 이상 데이터를 쓸 수 없게 되면 첫 번째 파일이 다시 확장되는 식이다.

데이터베이스를 여러 디스크 및 디스크 컨트롤러 또는 RAID(Redundant Array of Independent Disks) 시스템에 만들면 파일 및 파일 그룹을 사용할 때 데이터베이스 성능이 향상될 수 있다. 예를 들어, 컴퓨터에 4개의 디스크가 있으면 각 디스크마다 하나의 파일을 두어 3개의 데이터 파일과 한 개의 로그 파일로 구성된 데이터베이스를 만들 수 있다. 그러면, 4개의 읽기/쓰기 헤드가 동시에 데이터를 나란히 액세스하기 때문에 데이터베이스 작업 속도가 빨라진다.

또한 파일 및 파일 그룹을 사용하면 특정 파일 그룹에 테이블을 만들 수 있으므로 데이터를 원하는 대로 배치할 수 있다. 그러면, 특정 테이블의 모든 I/O가 특정 디스크로 집중되므로 성능이 향상된다. 예를 들어, 많이 사용되는 테이블은 하나의 디스크에 있는 한 파일 그룹의 한 파일에 배치하고 덜 사용되는 테이블은 두 번째 디스크에 있는 또 다른 파일 그룹의 다른 파일에 배치할 수 있다.

권장 사항

다음은 파일 및 파일 그룹 사용 시 일반적으로 권장되는 사항이다.

로그 파일 배치

로그 파일 배치를 위한 좋은 방법 몇 가지를 소개한다.

트랜잭션 로그는 물리적으로 분리된 디스크나 어레이에 잡으면 좋다. 트랜잭션 로그는 순차적으로 쓰여진다. 따라서, 트랜잭션 로그만을 위해 할당된 디스크를 쓰면, 디스크 헤드는 다음 쓰기 동작을 위해 알맞은 자리를 잡게 된다. 이런 이유로 해서 소규모 시스템에서 단일 미러링 디스크가 트랜잭션 로그용으로 적합한 것이다. 단일 미러링 디스크는 대략 초당 1,000개의 트랜잭션을 처리할 수 있으며, 이 성능은 개별 디스크의 속도에 따라 다르다. 그 이상의 트랜잭션이 요구되는 시스템에서는 트랜잭션 로그를 RAID 0+1어레이로 구성하면 최대 성능을 기대할 수 있다. 이럴 경우 최대의 데이터 대역폭을 보장하기 위해선, 어레이에 배터리 장착된 라이트-백(write-back) 캐시가 있어야 한다.

트랜잭션 로그를 자동 증가하도록 옵션을 설정하되, 되도록이면 로그의 사이즈가 증가될 필요가 없도록 하자. 로그의 최적화된 사이즈는 시스템의 복구모델, 로깅 레벨 설정, 또는 백업 간격에 준한다. 자동증가 비율을 적절하게 설정하되, 로그가 확장될 때 상황을 예견할 필요가 있다. 로그가 너무 자주 확장되거나, 확장하기 위해 많은 시간이 소요된다면 그에 따른 성능 저하는 불가피하기 때문이다.

로그 사이즈는 시스템 복구모델과 응용 프로그램 디자인에 따라 달라진다. 로그를 정기적으로 축소(shrink)할 필요하다면 어떤 요인에 의해 로그가 꽉 차게 되는지 심도 있게 조사해보아야 한다. 문제 회피 방안이 아닌 제대로 된 원인을 찾아내야 문제를 해결할 수 있기 때문이다.

tempdb배치

tempdb에 대해서도 좋은 방법 몇 가지를 소개한다.

tempdb는 I/O 가 빠른 쪽에 배치하는 것이 성능을 위해 좋다. tempdb를 여러 디스크에 스트라이프시켜 놓으면 더욱 좋다. 또한 tempdb를 자주 쓰는 사용자 데이터베이스와 물리적으로 격리된 디스크에 배치해야 한다.

tempdb는 대부분의 경우 데이터와 함께 위치한다. 그러나 tempdb를 아주 많이 쓰게 되는 대규모 시스템은 tempdb를 별도의 디스크 세트에 위치시켜 더 나은 성능 향상을 기대할 수 있다. 주의할 점은 데이터베이스 데이터와 운영시스템의 페이징 파일을 함께 위치시키는 것은 어떤 경우에라도 좋은 방법이라 할 수 없다.

그 외 파일의 배치

그 외의 파일들을 배치시키기 위해선 어떤 방법들이 있는지 살펴보자:

운영시스템은 RAID 1으로 구성된 어레이에 있어야 한다. 페이징 파일은 운영시스템이 있는 드라이브에서 훨씬 잘 동작하며, 데이터베이스에 별도의 디스크를 할당할 수 있게 하기 위해서 거기에 놔두어도 상관 없다. 페이징 파일을 굳이 옮겨야 할 필요가 있다면, 데이터베이스 데이터, 로그, tempdb가 있는 곳에는 위치시키지 않아야 한다. 이렇게 해야 디스크 오류에 빠르게 대응하여 복구할 수 있게 되는 것이다. 이 때, 부트 디스크는 미러를 이용하여 부팅가능해야 한다.

상식적인 얘기지만, 시스템 백업을 동일 서버에 저장해야 한다면 반드시 데이터나 로그 파일이 없는 다른 디스크에 저장해야 한다.

파일 그룹에 파일이 몇 개나 있는지는 SQL 서버의 성능과 하등의 관련도 없다. 그것은 단지 관리적 편의에 관련된 일일뿐 성능의 튜닝과는 무관하다.

다시 말해, 파일을 관리하기 쉽게 배치하라. 설정을 바꾼다고 해서 성능이 좋아지거나 하는 성질의 것은 아니다.

SQL 서버는 시스템의 버퍼 풀이 어느 정도인가에 따라 미리 읽기 동작(read-ahead)을 요청하기도 한다. 이 때 시스템이 넉넉한 메모리를 가지고 있고 이에 상응하는 I/O 성능이 있다는 것을 전제로 해야 한다. 예를 들어, 만약 SQL 서버가 400페이지 정도를 미리 읽어 들이고자 하는데, 해당 파일을 관장하는 스핀들이 하나 밖에 없다면, 항상 시스템의 읽기 큐는 대기 중일 것이다. 해당 파일에 10개 정도의 스핀들이 있다면 모든 스핀들을 움직여 해당 요청을 처리할 수 있을 것이다. 따라서, 10개의 스핀들을 구해놓든지 아니면 여러 개의 파일로 스트라이프 해놓도록 하자. 물론, 여러 파일이 하나의 스핀들 아래 놓여진다면 좋은 성능이 발휘할 가능성이 없다.

테이블 스캔과 인덱스의 범위 지정 쿼리는 미리 읽기 동작을 요청한다.

결론적으로, 데이터나 로그 혹은 tempdb를 제외한 파일들은 SQL 시스템 성능과는 무관하므로 파일 관리를 편하게 할 수 있도록 설정한다.

용량관리를 위한 모니터링

용량 관리를 위해 모니터링 하려면, 하드웨어와 직접 관련된 시스템 모니터에서 얘기하는 측정 가능한 개체들이 있어야 한다. 기본적으로 포함되어야 할 리스트는 다음과 같다:

반드시 포함시켜야 할 중요한 시스템 모니터 카운터들

5장에서 소개되었던 중요한 카운터들을 일정 기간 그래프 형식으로 나타내보자. 이를 위해선 카운터를 설정하고 매 분에서 3분 간격으로 정해진 모니터링 기간 동안 수집하면 된다. 더 많은 성능 카운터 데이터를 수집하려면, 지속적인 용량관리를 위해 추가적인 카운터 데이터를 별도로 추출하고 분석해야 한다. (이에 대한 관련 사항은 5장을 참조하라)

디스크 큐 길이에 대한 노트

SQL 2000부터는 디스크 큐 길이( Disk Queue Length) 카운터가 더 이상 의미 있는 결과를 보여주지 않는다. 이것은 SQL 2000엔진부터 디스크I/O를 동적으로 관리하기 때문이며, 바로 이러한 이유로 해서 Max Async I/O 설정이 없어진 것이다. 좀 더 간단히 설명하면 SQL 서버는 디스크 I/O 요청을 하고 그것이 완료되기 까지 다음 I/O 요청을 기다리지 않는다. 요청된 I/O가 완료된 후, 데이터베이스 엔진은 그 결과에 대하여 보고를 받는다. SQL 서버는 요청에 대한 처리량(throughput)를 모니터링 하여 디스크가 효과적으로 처리할 수 있는 I/O량을 설정-관리한다.

문제 증상 모니터링

하드웨어적 문제는 이벤트 뷰어나 시스템 모니터를 통해 관찰할 수 있다.

윈도우 2000의 이벤트 뷰어는 하드웨어 문제와 관련된 모든 메시지를 저장한다.

시스템 모니터에서는 다음과 같은 카운터를 통해 하드웨어 문제를 모니터링해야 한다.

요약

이 장에서는 DBA가, 해당 시스템에서 필요한 용량, 처리량, 성능 등의 기준에 맞출 수 있도록, 데이터 계층의 물리적 저장소를 어떻게 관리해야 하는지에 대하여 다루었다. 하드웨어 병목이 발생 여부와 이런 병목이 이후에도 계속 증가될 것인가 하는 것들을 판단하는 일련의 절차가 포함되어 있다. 이 것은 전체 조직에 걸쳐 관련된 정보를 수집하는 것도 포함하며, 특히 개발자나 네트워크 관리자로부터 많은 정보를 얻을 수 있다. 관련된 툴로는 이벤트 뷰어나 시스템 모니터 등이 있고 유용한 카운터들에 대한 설명도 함께 이루었다. 이런 프로세스를 수행하는 과정에서, DBA는 해당 시스템의 변화에 따라 달라지는 스토리지의 요구사항에 대응할 수 있을 것이다.