SQL 서버 2014는 OLTP의 왕좌를 노린다. 마이크로소프트는 비록 BI 부분의 향상은 건너뛰었지만 다방면에서 OLTP 성능 문제를 해결하기 위한 노력을 기울였다. 느린 디스크 성능은 메모리 내 테이블로, 느린 로그 성능은 지연된 내구성으로, 유지 동시성에는 잠금 우선 순위로 대처했다. 그게 전부가 아니다. 새로운 SQL 서버는 리소스 거버너(Resource Governor) I/O 제어를 통해 과도한 I/O를 차단하고, SSD 버퍼 풀 확장을 통해 메모리 문제를 해결하고, 애저 클라우드와의 통합을 통해 가용성을 높인다. editor@itworld.co.kr
메모리 내 OLTP
OLTP와 관련해서 SQL 서버 2014에서 가장 구미를 당기는 새 기능은 개별 테이블을 특별한 메모리 내 구조로 옮길 수 있게 해주는 메모리 내 OLTP(일명 "헤카톤(Hekaton)")다. 성능 향상 폭은 최대 30배에 이른다. 이러한 테이블에는 여러 가지 제약과 특수한 요구 사항이 있으므로 모든 조건에서 이 정도의 이득을 볼 수 있는 것은 아니다. 그러나 만일 해당된다면 지붕을 뚫고 올라갈 정도의 OLTP 성능 향상을 얻을 수 있다. 전체 데이터베이스를 메모리에 배치해야만 하는 여타 메모리 내 솔루션에 비해 더 우수한 방법이다. 기존 저장 프로시저를 메모리 내 프로시저로 변환하는 부가적인 성능 향상도 가능하다. 테스트를 통해 테이블의 호환성을 확인해야 하지만 일단 호환된다면 이 기능이 정말 마음에 들 것이다.
애저로의 관리되는 백업
중소기업들의 경우 제대로 된 DBA가 없는 경우가 무척 많다. 이러한 기업들은 대부분 백업이 제대로 처리되지 않더라도 이러한 사실을 모르며, 이미 너무 늦은 시점이 되어서야 알게 된다. 이름 그대로 '관리되는 백업'은 사용자가 정해놓은 복구 간격과 워크로드 패턴에 따라 데이터베이스(또는 인스턴스)를 자동으로 백업한다. 시스템은 데이터가 충분히 변경되었다고 판단하면 애저에 데이터를 백업한다. 이 기능은 애저 블롭 스토리지에서만 작동한다. 그러나 백업이 이미 오프사이트에 위치하므로 테이프에 대해 걱정할 필요가 없다.
가용성 복제본을 위한 애저 VM
SQL 서버 2014에서는 애저에 위치하는 가용성 그룹 복제본을 정의할 수 있다. 주 장애가 발생하면 수동으로 페일오버해야 하지만 아주 빠르게 가동 상태가 된다. 주 시스템이 온라인 상태인 동안 리포팅을 애저 복제본으로 푸시해서 프로덕션에서 이 작업 부담을 덜 수 있다. 안정적인 오프사이트 HA가 필요하지만 예비 사이트가 없는 경우 이 기능을 사용하면 된다. 애저 VM을 만들 때 원하는 위치만 선택하면 된다.
애저의 SQL 서버 데이터 파일
애저의 데이터 파일은 이름 그대로다. 데이터베이스는 데이터 센터에서 로컬로 실행되며 데이터베이스 파일 자체는 애저 블롭 컨테이너에 위치한다. 이는 DR과 마이그레이션에서 장점을 제공한다. 그러나 모든 트랜잭션에 대해 인터넷으로 데이터를 푸시하는 데 따르는 잠재적인 성능 하락폭은 데이터베이스와 워크로드의 크기에 따라 수용이 어려울 정도로 커질 수 있다. 이 기능을 잘 활용하는 방법은 같은 데이터 센터의 애저 VM에 데이터 파일을 저장하는 것이다. 이 방법을 사용하면 애저 VM에 마운트되는 디스크의 수가 16개라는 현재의 제한도 피해갈 수 있다.
업데이트 가능한 컬럼스토어 인덱스
SQL 서버의 컬럼스토어 인덱스는 데이터 웨어하우스 성능을 극적으로 높여주지만 한 가지 결점이 있다. 바로 업데이트가 안 된다는 점이다. SQL 서버 2014에서는 이제 업데이트가 가능하다. 즉, 더 이상 웨어하우스 테이블을 로드해야 할 때마다 컬럼스토어 인덱스를 삭제하고 다시 만들 필요가 없다는 뜻이다. 그뿐만 아니라 업데이트가 가능하다는 것은 컬럼스토어 인덱스에서 특정 OLTP 애플리케이션을 찾을 수도 있음을 의미한다. 다만 테이블에 클러스터된 컬럼스토어 인덱스가 있어야 한다. 클러스터되지 않은 컬럼스토어는 지원되지 않는다.
I/O를 위한 리소스 거버너
디스크 I/O는 전통적으로 데이터베이스 시스템에서 가장 제약되는 리소스인데, 대용량 또는 불량 쿼리가 귀중한 I/O 리소스를 감당할 수 있는 수준 이상으로 점유하는 경우가 많다. 마이크로소프트가 마침내 통제불능의 I/O에 대해 몇 가지 통제 수단을 제공했다. I/O를 위한 리소스 거버너를 사용하면 이제 자체 리소스 풀에 쿼리를 넣고, 쿼리에게 허용되는 볼륨당 I/O의 양을 제한할 수 있다. MIN_IOPS_PER_VOLUME 및 MAX_IOPS_PER_VOLUME은 디스크 볼륨에서 프로세스에게 허용되는 초당 읽기 또는 쓰기의 최소/최대값을 설정한다.
리소스 거버너 I/O 제어, 계속
MIN_IOPS_PER_VOLUME은 초당 최소의 I/O 트랜잭션 수를 유지하고, MAX_IOPS_PER_VOLUME은 최대 수를 제공한다. 이 최대값은 쿼리가 수행할 수 있는 I/O 작업의 수를 제한하는 것이 아니라 그저 쿼리가 디스크를 독점하지 못하도록 할 뿐이다. 이를 통해 대용량 쿼리를 계속 실행하면서 다른 작업도 할 수 있게 된다. I/O 제어의 유용한 사용처 중 하나는 디스크 과부하가 발생할 때 관리자가 문제를 조사할 수 있도록 관리자를 위한 일부 IOPS를 예약하는 것이다.
지연된 내구성
SQL 서버에서는 데이터에 대한 변경은 먼저 로그에 작성된다. 이것을 로그 선행 기입(WAL)이라고 한다. 로그 레코드가 디스크에 작성될 때까지 (이 프로세스를 "경화(hardening)"라고 함) 제어는 애플리케이션으로 돌아가지 않는다. 지연된 내구성은 로그가 경화되기 전에 애플리케이션으로 제어를 돌려줄 수 있게 해준다. 로그 성능에 문제가 있을 때 이를 통해 트랜잭션 속도를 높일 수 있다. 다만 대가는 있다. 바로 복구 가능성의 희생이다. 로그가 디스크에 커밋되기 전에 데이터베이스가 다운되는 경우 해당 트랜잭션은 영구적으로 잃게 된다. 그러나 로그 성능이 애플리케이션 응답 성능을 심각하게 저해하는 상황이라면 위험을 감수할 가치가 있다.
SSD 버퍼 풀 확장
SQL 서버 2014에서 버퍼 풀 확장을 만드는 것은 윈도우에서 다른 페이지 파일을 정의하는 것과 비슷하다. 데이터 페이지는 메모리로 이동하면서 버퍼 풀을 채우기 시작한다. 버퍼 풀이 모두 차면 사용 빈도가 낮은 페이지가 디스크로 페이징된다. 이후 그 페이지가 다시 필요해지면 버퍼 풀의 다른 요소와 스왑되어 메모리도 돌아온다. 버퍼 풀 확장 옵션을 사용하면 SSD를 버퍼 파일 위치로 정의할 수 있다. SSD는 회전 디스크에 비해 훨씬 더 빠르므로 페이징 역시 현저히 더 빠르고, 이는 경우에 따라 극적인 성능 증대로 이어진다. 버퍼 풀 확장은 메모리의 32배까지 정의할 수 있다.
증분적 통계 업데이트
SQL 서버에서 통계를 업데이트하는 것은 여분의 작업으로 정의되고 있다. 통계를 재구축해야 할 때마다 새로운 아이템만을 업데이트할 수는 없고 모든 내용을 업데이트해야 한다. 이는 2억 줄 짜리 테이블에서 4000만 줄만 내용이 변경됐다고 해도 변경 사항을 반영하기 위해서는 2억 줄을 모두 업데이트해야 한다는 것을 의미한다. SQL 서버 2014의 증분적 통계는 변경된 줄만을 업데이트해 이를 기존 통계에 합칠 수 있도록 해 준다. 이는 환경 설정에 따라서 쿼리 성능에 큰 영향을 미칠 수 있다.