[MySQL] 고성능 스토리지 기반의 DB통합 : MySQL 컨솔리데이션(Consolidation)

고성능 스토리지 기반의 DB통합 : MySQL 컨솔리데이션(Consolidation)

고성능 스토리지 기반의 DB통합

MySQL 컨솔리데이션(Consolidation)

작게 시작했던 서비스가 점점 커져 DB용량이 한계에 다다르면 수평으로 부하를 분산하는 스케일아웃(Scale out) 방식으로 확장할 것인지 해당 DB의 용량 자체를 올리는 스케일업(Scale Up) 방식을 사용할지 고민하게 된다. MySQL과 같은 오픈소스 데이터베이스를 이용하는 경우 스케일아웃 방식을 많이 적용한다.

스케일아웃만이 정답일까 이번 글에서는 최근 각광받고 있는 Fusion IO와 같은 PCI-E 기반 SSD등 고성능 스토리지를 기반으로 한 효과적인 MySQL 스케일업과 컨솔리데이션에 대해 알아본다.

스케일아웃(Scale out)과 스케일업(Scale up)

일반적으로 MySQL의 경우 마스터(Master) DB 한 대와 복제(Replication)로 구성되는 하나의 슬레이브(Slave) DB로 구성하여 서비스를 시작하게 된다. 이 구성은 기본적인 DB 장애 예방과 이중화를 실현하는 좋은 구성이지만 서비스가 이 두대의 DB서버로 감당하기 어려운 수준으로 성장하면서 문제에 봉착한다.



<그림 1> 스케일아웃과 스케일업

처음부터 확장을 염두에 두고 응용어플리케이션이나 서비스를 개발한 경우는 비교적 수월하지만 그렇지 않은 경우 몇 가지 선택지를 고민하게 된다. 기본적으로 읽기(Read) 중심의 서비스라면 <그림 2>의 슬레이브(Slave) 서버 추가의 형태로 읽기를 필요한 용량에 따라 확장해 Slave 서버들 앞 단에 L4등으로 부하를 분산하는 것으로 해결할 수 있다. 쓰기(Write)가 많은 서비스라면 Master를 2개 이상으로 분리하는 형태로 확장을 해야 한다. 미리 확장을 고려한 형태로 설계되지 않았다면 응용이나 서비스 단의 변경이 반드시 필요하다.



<그림 2> 읽기분산과 쓰기분산

일반적으로 <그림 2>의 읽기분산으로 해결 가능한 경우 더 이상의 고민 없이 스케일아웃을 선택하게 되지만 문제는 쓰기 분산의 경우이다. 앞서 이야기했던 것처럼 Master 데이터를 분산하여야 하지만 처음부터 고려되지 않은 경우 응용단의 변경이 어려울수도 있고 Master DB의 데이터가 반드시 하나의 DB 내에서 처리되어야 하는 경우도 있다. 이러한 경우 스케일업을 고려하게 된다. 말 그대로 기존의 Master DB보다 더 나은 하드웨어 성능을 가진 서버로 대체하는 형태로 업그레이드하는 것이다.

스케일아웃과 스케일업의 장단점

두 가지 방식모두 명확한 장단점을 가지고 있다. 먼저 스케일아웃과 스케일업 방식의 장단점을 간략히 표로 정리해 보면 다음과 같다.



<표 1> 스케일아웃과 스케일업 비교

스케일아웃이냐 스케일업이냐를 고려할 때 앞으로의 지속적 서비스 성장 가능성을 생각해야 하므로 기본적으로는 스케일아웃 형태의 지속적 확장이 가능한 방법을 고려하게 된다. 또한 비용문제 역시 일반적으로 하이엔드급의 서버나 스토리지가 로우엔드급에 비해 작게는 수배, 많게는 수십배의 비용을 유발하게 되므로 선택에서 제외되는 경우가 많았다.

DB에서 스케일업을 위해서는 서버 자체의 성능도 중요하지만 그것보다 중요한 것이 디스크 I/O 성능이다. MySQL의 경우 쿼리 수행 계획 수립을 위해 비용기반 쿼리 옵티마이저(Cost Based Optimizer)를 사용하고 있으며, 여기서 이야기 하는 비용이란 4KB 데이터 페이지에 대한 랜덤 읽기를 이야기한다.

이와 같이 데이터베이스에서 I/O 성능은 데이터베이스 성능의 매우 큰 부분을 차지하며 사실 그 동안 MySQL에서 스케일업이 어려웠던 부분은 SAN과 같은 고가의 엔터프라이즈 장비를 사용하지 않는 한 서버에 설치되는 로컬 스토리지로는 디스크 I/O 성능을 올릴 수 있는 한계가 있었기 때문이다.

하지만 기업에서 적용 가능한 수준의 성능과 신뢰도를 가진 엔터프라이즈급 SSD와 Sandisk사의 Fusion IO나 HGST의 Virident 같은 고성능 PCI-E 기반 스토리지의 출현과 지속적인 가격 하락이 많은 부분을 바꿔놓았다. 지금까지 MySQL에서의 데이터베이스 확장이 대부분 스케일아웃의 형태였다면, 이제 스케일아웃과 스케일업을 동시에 고려할 수 있는 하드웨어 환경이 됐다.

고성능 스토리지와 MySQL

사실 데이터베이스에서의 SSD와 같은 고성능 스토리지의 사용이 이제 막 시작된 새로운 기술은 아니다. SSD가 대중화 되기 시작한 2010년을 전후하여 데이터베이스에서 SSD 적용을 통한 성능향상에 대한 연구와 테스트 등이 활발하게 이루어졌고, 비용 대비 성능 측면에서 기존 SATA나 SAS 디스크와 견줄 수 있는 수준이 된 2012년부터는 실 서비스에 대한 검토 및 적용이 본격적으로 시작됐다.

올해 들어 SSD보다 더 나은 성능과 대용량을 장점으로 삼성, 화웨이, 인텔 등 다양한 벤더에서 기업용 PCI-E 기반 SSD들을 출시하고 일반기업에서 도입 가능한 수준의 가격대인 서버포함 500만원~1000만원 수준을 형성하면서 본격적인 대중화가 진행되고 있다.



<그림 3> HDD, SSD, PCI-E SSD

SSD와 PCI-E SSD

SSD(Solid State Drive)는 이미 데스크톱이나 노트북 등 개인용 PC환경에서도 널리 사용되면서 대중화되어 있다. 간략하게 설명하자면 HDD와 동일한 SATA나 SAS방식의 인터페이스를 사용하고 데이터의 물리적인 저장을 플래터를 이용하지 않고 비휘발성 플래시 메모리를 사용함으로써 디스크 I/O 성능을 대폭 높인 것이다. 이로 인하여 기존 HDD를 사용하던 서버에 SSD를 바로 장착하여 사용이 가능하지만 SATA나 SAS의 인터페이스 대역폭의 한계를 그대로 가진다. (SATA3 기준 6Gbps)

PCI-E SSD의 경우 내부적으로는 SSD와 거의 동일하나 기존 SATA나 SAS방식의 대역폭의 한계를 극복하기 위해 PCI Express 슬롯을 이용하는 방식이다. PCI-E 3.0 기준으로 최대 32Gbps까지 지원이 가능하다. 하지만 PCI-E SSD의 경우 SATA나 SAS방식과 달리 PCI-E SSD만으로는 부팅이 불가능하다는 문제점이 있었으나 기존 SATA 방식을 위한 AHCI가 아닌 SSD를 위한 새로운 규격인 NVMe(Non-Volatile Memory Express) 인터페이스를 지원하는 서버와 OS에서는 부팅이 가능하며 추가적인 성능향상도 기대할 수 있다.

MySQL의 경우 아직 직접적인 SSD 지원은 없으나 2013년 정식 릴리즈된 5.6 버전부터 innodb_io_capacity와 innodb_lru_scan_depth를 SSD에 맞게 조절함으로써 성능 향상을 얻을 수 있으며, 내년 상반기 중 출시될 예정인 5.7 버전에서는 옵티마이저 옵션으로 디스크 성능을 추가하여 디스크 성능에 따른 쿼리 최적화가 되도록 하였고, Fusion I/O 사용 시 페이지 레벨 압축을 통한 I/O 성능 향상 등을 지원 예정이다.

마리아(Maria)DB의 경우 10버전부터 DirectFS를 통한 Atomic Write를 지원하고 있으며 Fusion I/O 장비와 함께 사용 시 테스트에서 최대 3배의 쓰기 성능 향상을 확인할 수 있었다. 자세한 테스트 결과는 성능 테스트 부분에서 다루도록 한다.

고성능 스토리지 기반의 MySQL 컨솔리데이션

이번 글에서 다루고자 하는 내용은 SSD나 PCI-E SSD등의 고성능 스토리지 기반의 MySQL DB 통합이다. 기존 MySQL 환경에서는 앞서 이야기 했다시피 스케일아웃이 주된 확장 방법이었고 그러다 보니 서비스의 성장이 계속 이어지는 경우 하나의 서비스를 위한 서버가 수십에서 많게는 수 백대까지 증가하게 된다. 이 시점이 되면 스케일아웃의 여러 가지 장점보다 단점이 더 크게 부각되는 경우가 발생하는데 바로 운영비용의 증가이다.



<그림 4> 마스터, 슬레이브 모두 스케일아웃된 서비스

위 <그림 4>와 같이 읽기와 쓰기 모두를 분산시키기 위해 마스터DB를 3개의 샤드로, 슬레이브가 각 마스터에 10대씩 있는 서비스를 가정해보자. 이렇게 마스터 슬레이브가 모두 확장된 복잡한 서비스의 경우 고려할 운영비용은 다음과 같다.

-DB 관리의 어려움: 데이터베이스의 버전업이나 컬럼의 추가, 삭제 또는 데이터 타입의 변경, 인덱스추가 등의 DDL작업이 이루어질 경우 각 슬레이브를 서비스에서 하나씩 제거하면서 작업 후 마지막에 마스터를 변경하는 등의 작업을 서비스가 한산한 시간을 택해 수동으로 해 주어야 하며, 대수가 많을 경우 이는 관리의 어려움과 함께 서비스 기능 변경 등을 느리고 어렵게 하는 요소가 된다

-서버 오류의 증가: 투입된 장비 대수가 증가할수록 자연스럽게 서버의 CPU, Memory, Disk, Raid카드 등 파트의 오류 가능성도 증가한다

-복제 지연으로 인한 문제: 각 마스터당 10대의 슬레이브가 추가되어 읽기 부하를 분산한 상황에서 MySQL Single thread 복제로 인한 심한 복제지연이 발생할 경우 서비스에 따라 장애에 준하는 상황이 될 수 있다.

-전력 및 상면 비용의 증가: 저렴한 서버로 확장하는 것이 장점이 될 수 있으나 총소유비용(TCO)의 관점에서 볼 때 전력 및 상면 비용도 적지 않다. 약 3년간의 비용을 따져보면 이 비용이 서버의 구입가격을 훨씬 상회하기도 한다.

그렇다면 이러한 어려움을 어떻게 감소시킬 수 있을까 방법으로 제시하는 것이 바로 고성능 스토리지 기반의 MySQL 통합이다.

MySQL DB통합의 핵심: 통합 가능 대수의 확인

앞서 이야기 한 것과 같이 기존 MySQL 통합이 어려웠던 이유는 외부에 엔터프라이즈급 스토리지를 사용하는 방법을 제외하곤 디스크 I/O 성능을 향상시키기 어려웠기 때문이다. 고성능 스토리지를 사용함으로써 얼마나 많은 서버를 통합할 수 있을까 물론 벤더에서 제공하는 IOPS등으로 대략의 디스크 I/O 성능의 향상을 예측할 수는 있겠으나 벤더에서 제공하는 정보는 어디까지나 그들의 제품이 최상의 성능을 낼 수 있는 환경에서 테스트 된 데이터일 뿐이다. 그러므로 일반적으로 아래와 같은 두 가지 과정을 거쳐 X:1 통합이 가능한지 그 X를 뽑아내게 된다.

-벤치마크 도구를 이용한 테스트: 기존 장비와 새롭게 투입하고자 하는 장비를 놓고 기본적인 성능 테스트를 실시한다. 일반적으로 MySQL 기반의 시스템 성능을 측정하기 위해서는 sysbench를 이용한다. 읽기에 집중된 환경, 쓰기에 집중된 환경, 읽기/쓰기가 혼합된 환경을 주로 측정하게 된다. -실 서비스 테스트: 1번의 벤치마크 도구를 이용한 테스트를 통해 기본 성능 데이터를 얻고 난 후 실 서비스 테스트를 실시하게 되는데 가장 기본적으로 할 수 있는 방법은 신규 도입 하고자 하는 장비를 실 서비스에 슬레이브 중 하나로 추가하여 기존 슬레이브와 성능을 비교하는 방법이다. 물론 가장 좋은 방법은 로드런너나 nGrinder와 같은 서비스를 시뮬레이션 할 수 있는 도구를 기반으로 실 서비스 환경에서의 마스터와 슬레이브 DB의 성능을 측정하고, 복제지연 여부를 확인하는 것이다.

위와 같은 테스트를 통해 기존 장비 대비 성능 향상 비율을 측정하고, 복제 지연이 발생하지 않는 Write QPS등을 확인하여 기존장비 몇 대를 신규장비 1대로 통합할 수 있는지 통합 가능대수를 확인한다.

경축! 아무것도 안하여 에스천사게임즈가 새로운 모습으로 재오픈 하였습니다.
어린이용이며, 설치가 필요없는 브라우저 게임입니다.
https://s1004games.com

MySQL에서의 기본 성능 테스트 결과

앞서 언급한 두 가지 테스트 중 2번인 실 서비스 테스트 결과는 각 서비스의 특징을 반영하여 직접 측정할 수 밖에 없지만 1번, 즉 MySQL에서 표준적인 시스템 성능 벤치마크 도구로 사용되는 Sysbench 기반의 대략적인 성능 테스트 결과는 테스트 환경 및 테스트 옵션과 함께 살펴보는 것으로 각 스토리지의 성능비에 대한 대략의 기준을 잡을 수 있다. 물론 공개해 드리는 테스트 결과는 어디까지나 참고용일 뿐이며, 데이터베이스 설정, MySQL의 버전, 서버의 사양, Sysbench 테스트옵션, 각 스토리지 유형별 제품군 등에 따라 크게 달라질 수 있다

1.테스트 환경
MySQL VersionMySQL 5.6.16, MariaDB 10.0.12
Sysbench Version Sysbench-0.4.12.5
OSCentOS 6.3
File SystemEXT4
CPU6 core cpu(Intel E5-2630L) x 2
Memory 16GB (innodb_buffer_pool = 10GB)
HDDSAS 15Krpm 300G * 6 (Raid 1+0)
4K rand. Read : 400 IOPS / Disk
4K rand. Write : 400 IOPS / Disk
Read Bandwidth : 0.5 GB/Sec
Write Bandwidth : 0.4 GB/Sec
SSDSSD 400GB * 6 (Raid 5),
4K rand. Read : 75,000 IOPS / Disk
4K rand. Write : 11,000 IOPS / Disk
Read Bandwidth : 0.5 GB/Sec
Write Bandwidth : 0.46 GB/Sec
PCI-E SSDPCI-E SSD 1.x TB
4K rand. Read : 130,000 IOPS
4K rand. Write : 240,000 IOPS
Read Bandwidth : 1.5 GB/Sec
Write Bandwidth : 1.3 GB/Sec

2.Sysbench Option
읽기위주 테스트 (select 75%)
--oltp-table-size=30000000 --oltp-num-tables=16 --test=oltp
--num-threads=$thds --max-requests=0 --max-time=1800
--oltp-index-updates=1 --oltp-non-index-updates=1 쓰기위주 테스트 (select 20%)
--oltp-table-size=30000000 --oltp-num-tables=16 --test=oltp
--num-threads=$thds --max-requests=0 --max-time=1800
--oltp-index-updates=25 --oltp-non-index-updates=25

3.읽기위주 테스트 결과


<그림 5> 읽기위주 테스트 결과

4.쓰기위주 테스트 결과


<그림 6> 쓰기위주 테스트 결과

테스트 결과 요약

먼저 주지해야 할 사실은 읽기, 쓰기 대역폭(Read, Write Bandwidth)과 IOPS(Input/Output Operation Per Second)등에 대한 이해이다. 위의 테스트 환경을 보면 벤더에서 제공하는 디스크당 4K 랜덤 읽기, 쓰기 기준의 IOPS와 읽기, 쓰기 대역폭을 표시해 두었는데 이는 각 디스크 당 성능이므로 전체 디스크의 수와 레이드(raid) 구성에 따라 달라지게 되고 디스크의 캐시 및 컨트롤러의 성능 등에 따라 달라지게 되므로 기대성능에 대한 참고수치 정도로 보아야 한다. 또한 특정 제품의 성능이 아닌 각 스토리지 종류별 대략의 성능을 파악하고자 하는 것이므로 제품명을 생략하였다.

-읽기위주 테스트 결과: SAS와 SSD, PCI-E SSD는 1:4:6의 성능비율을 보임. 실제 사용시에는 데이터 억세스 패턴 및 레이드 캐시 사용여부에 따라 SSD와 PCI-E SSD의 성능이 크게 차이 나지 않을 수 있다.
-쓰기위주 테스트 결과: 쓰기위주의 경우 SAS, SSD, PCI-E SSD가 최대 1:3:6의 성능비율을 보였다. 위 그래프에는 표시하지 않았으나 MariaDB 10 버전 이상에서 DirectFS를 사용하여 Atomic Write를 적용했을 때 PCI-E SSD기준 위 성능의 최대 2.5배까지의 성능향상을 볼 수 있었다. 본 기능은 MySQL 5.7에서 탑재 예정이다.

전체적인 성능을 보았을 때 일반 SAS 장비를 사용했을 때 대비 4~6배 정도의 성능을 기대할 수 있었으며 복제지연을 고려하여 write의 최소치를 기준으로 할 경우 SAS:PCI-E SSD가 1:4의 통합이 가능하다. 이 경우 위 <그림4>의 서비스를 통합한다고 보았을 때 마스터 장비를 3대에서 1대로 줄이고 Slave 장비의 경우 30대에서 8대 정도로 통합 하여 아래의 <그림 7>과 같이 구성하는 것이 가능하다.



<그림 7> 마스터 DB 1대와 슬레이브 8대로 통합

DB의 확장 및 통합에 정답은 없다

서비스의 투입된 DB의 경우 서비스의 흥망성쇠에 따라 그 사용량 역시 큰 변화를 맞게 되며 때로는 이번 글에서 살펴본 것과 같이 서비스가 잘 되는 상황에서 운영비용의 절감을 위해 통합을 하는 경우도 있고, 서비스의 사용량이 감소하여 통합을 하게 되는 경우도 있다.

어떠한 경우에도 정답은 없다. 하지만 MySQL과 같은 오픈소스 데이터베이스를 사용할 때는 무조건 스케일아웃을 통한 수평확장만이 정답이라고 생각하는 사람들도 많은 것이 사실이며 이번 강의는 그러한 선입견을 깨고 빠르게 변화하는 하드웨어의 변화에 발맞춰 유연한 구조를 구상할 수 있도록 하기 위함이다. 서비스에 맞는 최적의 성능, 비용, 운영효율성의 3박자를 모두 고려한 DB구성을 하기 바란다.

출처 : 마이크로소프트웨어 1월호

제공 : 데이터전문가 지식포털 DBguide.net

[출처] https://dataonair.or.kr/db-tech-reference/d-lounge/technical-data/?pageid=16&mod=document&uid=235888