SSD를 쓰면 DBMS가 빨라질까?

NHN Business Platform DBMS개발랩 이기열

SSD는 HDD보다 처리 속도가 빠릅니다. 그렇다면 DBMS의 저장 매체를 HDD에서 SSD로 바꾸면 DBMS의 속도도 빨라질까요? DBMS의 데이터 버퍼링이 효율적으로 동작하지 않으면 SSD로 바꾸더라도 기대한 만큼 속도가 빨라지지 않을 수 있습니다.

디스크 드라이브와 데이터 버퍼링

SSD(Solid State Disk)는 HDD(Hard Disk Drive)보다 읽기/쓰기 속도가 빠르다. 그래서 HDD를 SSD로 대체하면 운영체제를 비롯한 많은 프로그램의 실행 성능이 좋아진다. 그런데 DBMS에서는 저장 매체를 HDD에서 SSD로 바꾸어도 성능이 나아지지 않거나, 나아진다 해도 미미한 정도인 경우가 많다.

그 이유는 DBMS에서는 데이터 버퍼링(페이지 버퍼링)을 하고 있기 때문이다. 데이터 버퍼링은 일종의 캐시로 이해할 수 있는데, 데이터 버퍼링으로 저장 매체 I/O를 줄일 수 있다. 효과적으로 데이터 버퍼링이 수행되는 환경이라면(즉 캐시 시스템의 히트율(hit ratio)이 높다면), 저장 매체의 I/O 실행 성능이 상대적으로 중요하지 않게 되는 것이다.

그래서 HDD를 SSD로 바꾸어 성능 향상 효과를 얻고 싶다면 DBMS의 데이터 버퍼링이 효율적으로 동작하고 있는지를 파악한 이후에 결정하는 것이 좋다. 저장 매체를 SSD로 변경하지 않고 데이터 버퍼 설정만으로 충분한 기대 효과를 얻을 수도 있기 때문이다.

이 글에서는 HDD 환경과 SSD 환경에서 데이터 버퍼의 효율과 이에 따른 TPS(Transactions Per Second) 변화 추이를 살펴봄으로써, 효율적인 데이터 버퍼 크기를 설정하는 방법과 저장 매체를 선택하는 방법을 알아보겠다.

HDD의 구조와 I/O 특성

HDD는 회전하는 플래터(자기 디스크)에 데이터를 기록한다. HDD에는 플래터가 여러 개 있는데, 이 플래터는 각각 따로 회전하는 것이 아니라 모두 함께 같이 회전한다. 다음 그림에서 보듯이 플래터 중심을 중점으로 하는 동심원을 트랙이라고 하한다. 그리고 여러 플래터 상의 같은 위치의 트랙(같은 트랙 넘버)을 실린더라고 한다. 이 플래터에 자기 정보를 읽고 쓰는 것을 헤드라고 하는데 플래터 양면에 정보를 기록할 수 있기 때문에 각각의 플래터마다 두 개의 헤드가 있다. 그리고 헤드는 디스크 암의 끝에 달려 있다.

그림 1 HDD의 구조(이미지 출처: http://en.wikipedia.org/wiki/Cylinder-head-sector)

데이터는 빠르게 회전하는 플래터의 실린더에 순차적으로 블록 단위로 기록된다. 그래야 연속된 데이터를 한 번의 이동(플래터 회전과 디스크 암 이동)으로 잘 읽을 수 있기 때문이다. 그래서 HDD의 I/O 시간이란 '디스크 암이 해당 실린더까지 이동하는 seek time'과 '플래터가 해당 블록(섹터)까지 회전하는 rational latency', 그리고 '헤드가 데이터를 읽거나 쓰는 data transfer time'을 모두 합한 것을 말한다.

그림 2 HDD 내부 http://en.wikipedia.org/wiki/Hard_disk_drive

data transfer time보다 seek time과 rational latency가 훨씬 더 크기 때문에(seek time >> rational latency > data transfer time), 일반적으로 운영체제는 헤드의 이동과 플래터의 회전을 최소화하도록 최적화 스케줄링(I/O Scheduling) 방식을 사용한다.

하지만 애플리케이션은 운영체제에 매우 비번하게 I/O를 요청하고 운영체제 입장에서는 시기를 예측할 수 없기 때문에, 언제나 I/O 스케줄링 효과를 기대할 수 있는 것은 아니다. 만약 애플리케이션을 제작할 때 '작은 크기의 데이터를 여러 번 읽고 쓰도록 요청'하기보다 '데이터를 모아 큰 데이터를 적게 읽고 쓰도록 요청'하게 한다면, 운영체제 입장에서는 효율적으로 I/O 스케줄링(Scheduling)을 할 수 있어서 성능이 좋아질 수 있다.

CUBRID는 디스크 I/O를 페이지 단위로 묶어서 요청한다. 또한, I/O 요청 중 response time에 영향이 없는 것들은 최대한 모아서 페이지 일련번호대로 정렬시켜 I/O를 요청하는 내부 최적화를 수행한다. 이렇게 하면 seek time, rational latency를 최소로하여 운영체제가 스케줄링하기 쉽게 된다. CUBRID에서는 이 방식을 적용하느냐 적용하지 않느냐에 따라 성능에 차이가 난다.

HDD에서는 헤드가 데이터를 읽고 쓰는데 필요한 시간은 상대적으로 매우 짧다. 그렇기 때문에 seek time, rational latency를 얼마나 줄이느냐가 디스크 I/O 성능을 향상시키는 중요한 요인이 된다. 경우에 따라 sequential write는 SSD보다 좋은 성능을 보이기도 한다.

SSD의 구조와 I/O 특성

SSD(Solid State Disk)는 플래시 메모리(flash memory)를 저장 매체로 사용하는 디스크이다. 플래시 메모리는 전자적으로 메모리의 내용을 읽는 것 외에, 프로그래밍(Write)하거나 초기화(Erase)할 수 있는 EEPROM의 한 종류이다.

그림 3 SSD의 내부 http://www.techspot.com/review/160-solid-state-drive-roundup/

메모리를 초기화하면 모든 비트를 1로 세팅하는데, 페이지 단위로 프로그래밍하면 특정 비트를 0으로 변경시킬 수 있다. 프로그래밍한 페이지에 대해 다시 프로그래밍할 수도 있지만 비트를 1에서 0으로 변경시키는 것은 가능해도 0에서 1로 변경시키는 것은 불가능하다. 그렇기 때문에 범용적으로 사용하려면 해당 영역에 특정 데이터를 다시 기록하기 전에 초기화를 수행하여 특정 영역의 비트를 전부 1로 변경시키는 작업이 필요하다.

HDD는 헤드가 데이터를 읽는 시간과 쓰는 시간이 거의 비슷한 반면에 SSD는 읽기 성능과 쓰기 성능이 다르다. 제품마다 다르지만 페이지를 읽는 시간(read time)이 수백 ns 수준이라면 쓰는 시간(write time)은 us 단위이고, 초기화(erase)는 ms 단위이다.

초기화는 한 영역에 대해서 동시에 진행하기 때문에 칩 전체를 초기화하거나 몇몇 페이지를 초기화하거나 보통 동일한 시간이 소요된다. 그래서 일반적으로 여러 페이지의 묶음인 섹터나 블록 단위로 초기화를 수행하도록 구성한다.

플래시 메모리의 특성상 섹터 당 초기화 횟수에 한계(보통 수만~수십만 정도)가 있다. 그래서 FAT에서 처럼 특정 부분이 자주 갱신되는 일이 없도록, 논리 블록 주소에 대한 물리 블록 주소를 다르게 매핑하여 각 섹터별 초기화 횟수가 고르게 되도록 한다. 이러한 방법을 wear leveling이라 부른다.

특정 페이지의 내용을 기존의 위치에서 변경하려면 초기화를 하고 쓰기를 수행해야 한다. 그러나 wear leveling을 적용하면, 이미 초기화된 페이지로 물리적인 주소를 옮겨서 쓸 수 있기 때문에 초기화 작업 없이 쓰기를 수행할 수 있다. 단, 이것도 빈 공간을 제때 확보하지 못하면 결국 한계에 다다를 수 있다.

이러한 특성들 때문에 SSD의 I/O 특성은 HDD와 많이 다르다.

읽기의 경우에는 HDD와 다르게 seek time, rational latency 없이 data transfer time만 소요되기 때문에 random read에서도 일정한 응답 속도가 보장된다. 그러나 쓰기의 경우에는 wear leveling을 진행하다 비어 있는 공간이 없으면 섹터 단위로 초기화하게 되고 이 작업 동안 해당 섹터에 대한 I/O 작업이 모두 대기 상태가 된다.

DBMS의 데이터 버퍼

DBMS의 데이터 버퍼는 일종의 캐시이다. 메모리는 빠르고 디스크 드라이브는 상대적으로 많이 느리며, 최근에 자주 사용한 데이터는 일정 시간 동안 앞으로도 더 자주 사용될 수 있기 때문에, 자주 사용하는 데이터는 가급적 디스크 드라이브가 아닌 메모리에서 읽을 수 있도록 한 것이다.

DBMS의 데이터 버퍼는 운영체제의 디스크 캐시와 다르게 트랜잭션을 고려하여 동작할 수 있다. 또한 LRU(Least Recently Used) 알고리즘을 기반으로 하고 있지만, hot zone과 cold zone을 분리하여 LRU 관리 비용을 줄인다.

DBMS의 I/O 요청에 대한 전체 처리 시간은 다음과 같이 나타낼 수 있다.

total access time = A * HR + B * (1-HR)

각 항목의 의미는 다음과 같다.

• A: 메모리의 액세스(access) 시간
• B: 스토리지의 평균 액세스 시간
• HR: 버퍼 히트율

전체 처리 시간이 위와 같기 때문에 HDD와 SSD의 처리 시간 차이인 'B * (1-HR)'의 값은 히트율이 클수록 차이가 줄어든다. 일반적인 DBMS의 히트율은 90%대 후반이다.

데이터 버퍼 설정에 따른 HDD와 SSD의 성능 비교 실험

데이터 버퍼와 저장매체의 변경에 따른 DBMS의 성능변화를 시험해 보았다. 시험은 나머지 사양은 동일하고 저장 매체로 HDD와 SSD를 사용하는 두 DBMS에 대해 데이터 버퍼의 크기를 변경해 가며 부하를 가하는 방식이다. 이를 통해 데이터 버퍼의 크기에 따른 여러 응답 특성이 저장 매체에 따라 어떻게 다른지 관찰할 수 있다.

실험 환경과 시나리오

실험에 사용한 DBMS 서버 사양은 다음과 같다.

• CPU: Xeon® CPU L5650 (2.27GHz 2*6 cores)
• Memory: 16GB
• HDD: 300GB * 2
• SSD: 64GB * 4
• 운영체제: CentOS 5.3 x86_64
• DBMS: CUBRID 2008 R4.1 (8.4.1.0516) (64bit release build for linux_gnu)

부하 발생기는 YCSB 프로그램을 사용했다. YCSB는 Yahoo!에서 클라우드 서비스의 스토리지를 벤치마킹하기 위해 개발한 도구로, 쿼리 패턴이나 분포를 설정하여 분석할 수 있다. 이번 실험에서는 Latest 분포(변형된 Zipfian 분포로서 밀집도가 높은 패턴)로 DBMS에 SELECT 요청을 보냈다. 실험에서 동시에 진행한 트랜잭션은 60개이다.

동일한 장비에서 저장 매체만 변경하고, DBMS의 데이터 버퍼를 2~12GB까지 1GB 단위로 변경해가며 TPS, 히트율 및 초당 처리 I/O 요청 횟수를 측정하며 실험을 진행했다.

실험 결과

실험을 통해 다음과 같은 결과를 얻었다.

먼저 TPS 추이 그래프는 그림 4와 같다.

DBMS의 데이터 버퍼가 커질수록 SSD, HDD의 TPS가 모두 증가한다. 상대적으로 HDD가 더 느리기 때문에 HDD에서 페이지 버퍼 크기를 늘릴수록 TPS도 증가한다.

SSD의 그래프는 2~4GB 구간의 결과를 제외하면 단순 비례 관계를 보여 준다. 반면 HHD의 그래프는 10GB 부근에서 변곡점이 있는 S자형 곡선을 보여 준다.

그림 4 데이터 버퍼 크기에 따른 TPS 추이

그림 5는 DBMS가 운영체제에 요청한 I/O 요청 추이를 나타낸 것으로 CUBRID의 stat dump로 수집했다. I/O 요청의 결과는 SSD를 사용했을 때는 버퍼크기에 따라 단순 감소하는 지수함수 형태를 띄고 있다. 반면 HDD의 경우에는 TPS의 그래프와 유사하게 변곡점이 있는 그래프를 보여 주나 변곡점의 위치가 6GB 근방이다.

그림 5 데이터 버퍼 크기에 따른 I/O 요청 처리 횟수 추이

DBMS의 데이터 버퍼에 대한 히트율 그래프는 그림 6과 같다. 동일한 분포로 실험했기 때문에 SSD와 HDD가 같은 형태를 보이고 있다. 히트율은 동일하지만 처리 속도 차이 때문에 I/O 요청은 그림 5와는 다른 양상을 보인다.

그래프 모양은 100% 를 접선으로 하는 지수함수 형태로 버퍼 크기가 커질수록 기울기가 완만해진다.

그림 6 데이터 버퍼 크기에 따른 히트율 추이

결과 분석 및 시사점

실험 결과와 같이 DBMS의 성능은 데이터 버퍼의 히트율에 민감하게 반응한다. 그렇기 때문에 DBMS의 성능을 향상시키는 데에는 데이터 버퍼가 충분한 히트율을 유지하도록 관리하는 것이 가장 중요하다.

데이터 버퍼가 주요 워킹셋을 포함할 수 있도록 적정한 규모로 설정해야 하며, DBMS의 스키마와 응용의 요청 패턴이 주요 워킹셋을 구성하도록 설계해야 한다. 이 방법으로도 만족할 만한 히트율을 유지하지 못하게 되었을 때는 성능을 일정 수준 이상 유지하기 위해 SSD 도입을 고려할 수 있다.

이 결론에 따라 실험 결과를 다시 자세히 분석해 보겠다.

먼저 시험에 사용된 응용은 Zipfian 분포로 워킹셋이 잘 구성되어 있는 모델이다. 그러면 이제 DBMS의 데이터 버퍼가 워킹셋을 적절히 커버하도록 구성해야 하는데, 데이터 버퍼의 크기에 따른 히트율 변화 그래프는 그림 6과 같은 형태이다.

워킹셋의 분포에 따라 그래프의 기울기가 변하겠지만 추세는 보통 그림 6과 같은 형태이다(100%를 접선으로 하는 지수함수). 이때 버퍼 사이즈와 비용은 정비례하지만 히트율의 증가는 기울기가 감소하므로 데이터 버퍼의 증설이 갖는 비용 대 성능 비는 점차 감소하게 된다. 그래서 일단 그래프의 기울기가 완만하게 접어들기 시작하는 8GB를 적정 데이터 버퍼의 크기로 볼 수 있다.

직관적으로 TPS는 히트율 그래프와 비례할 것으로 예상할 수 있으나 그림 4와 같이 저장 매체의 I/O 특성에 따라 다른 패턴을 보인다. SSD의 경우에는 '읽기' 작업이 빠르기 때문에 TPS는 완만하게 감소했다. 반면 HDD의 경우에는 변곡점이 있는 패턴을 보인다. 그림 4에서 사각형 안에 있는 부분은 SSD와 HDD의 성능비가 단순 비례하는 모습을 보이지만 이 부분을 지나가면 HDD의 TPS성능이 급감하다가 다시 완만하게 감소한다.

이 현상은 그림 5의 I/O 요청 횟수 추이와 연관 지어서 볼 수 있는데, 10~12GB의 구간 A에서는 히트율 감소에 따라 늘어나는 I/O 요청 처리 횟수를 HDD가 충분히 처리하고 있는 모습을 볼 수 있다. 때문에 TPS 그래프는 SSD에 비해 순전히 물리적인 성능만큼의 차이를 보여 준다.

반면 버퍼사이즈가 10GB이하로 내려가기 시작하면서(구간 B), 버퍼 미스에 따라 증가하는 I/O 요청 처리 횟수를 HDD가 단위 시간 내에 충분히 처리하지 못하고 정체되는 모습을 보인다. 이런 I/O 요청 처리 횟수의 정체가 TPS 그래프의 급격한 감소를 유발시켰다 이는 운영체제의 I/O 스케줄링이 제대로 동작하지 못하고 있는 상태이다.

반면 데이터 버퍼가 더 작아지면서(구간 C), 단위시간 내의 I/O 요청 처리 횟수가 증가하기 시작하는데 이 부분은 누적된 I/O 요청 처리 횟수가 증가하면서 운영체제의 I/O 스케줄링이 효율적으로 동작하기 시작하는 것을 의미한다. 때문에 TPS의 감소폭이 완만해지기 시작했다. 단, I/O 요청 처리 횟수가 증가 하더라도 히트율은 감소하기 때문에 전체 TPS는 감소한다.

이 사실을 종합해 보면 히트율은 8GB 부분부터 완만해지기 시작하나 TPS는 오히려 기울기가 커지다 10GB에서 변곡점을 맞는다. 결국 8~10GB 부근에서 데이터 버퍼의 비용 대 성능 향상 효과가 가장 커진다. 이런 환경에서는 데이터 버퍼를 10GB 수준으로 증설하는 것이 저장 매체를 SSD로 변경하는 것보다 비용에 대비해 성능을 더 효율적으로 높일 수 있다.

NBP DBMS개발랩 이기열

2008년부터 DBMS개발랩에서 CUBRID개발을 해오고 있다. 시스템 프로그래밍에 관심이 많으며 개발 커뮤니티 orca-lang.or.kr을 운영하고 있다.