오랜 시간 동안 DAS(Direct Attached Storage)는 비교적 저렴한 가격에 적당한 성능과 안정성을 지원하는 ‘나름 괜찮은’ 솔루션으로 여겨져 왔습니다. 또한 DAS는 수십 년 동안 개인용 컴퓨터와 서버에 사용되어 왔습니다. RAID처럼 데이터 전송 프로토콜 및 데이터 보호 방식의 혁신 기술에 힘입어 DAS는 서버 상에서 수명이 연장되었습니다. 그러나 이렇게 연장된 수명도 이제 점점 한계점에 다다르고 있습니다. DAS도 세월을 이기지는 못하는 모양입니다.
워크로드를 확장하려고 할 때 DAS의 한계는 더 극명하게 드러납니다. IOP가 감소하고 레이턴시는 늘어납니다. SSD로 상황을 개선시킬 수는 있지만, 이 문제를 해결할 정도는 아닐 것입니다. RAID 컨트롤러를 하나 더 설치하거나 디스크를 추가하는 것은 본질적인 문제를 덮는 것에 불과합니다. 수백 대의 서버를 관리하기 어려운 것은 둘째 치고, 다른 서버를 추가하기가 여의치 않은 상황도 많습니다.
그렇다면 잘 구성되어 있고 관리하기 쉬운 솔루션이라면 이런 문제를 해결할 수 있을까요? 그 질문에 대한 해답은 안정성, 예측성, 확장성, 그리고 신뢰성을 겸비한 퓨어스토리지의 공유형 데이터 스토리지에 있습니다.
하지만 성능은 어떨까요? 일반적으로 DAS의 성능이 스토리지 어레이보다 우수하지만 올플래시 스토리지가 발전하면서 전세가 역전되었습니다. 이를 증명할 데이터가 준비되어 있습니다. 퓨어스토리지는 DAS와 퓨어스토리지의 플래시어레이//X90 R3의 성능을 비교하기 위해 MySQL 8로 여러 차례 테스트를 진행했습니다.
예상한 대로 대부분의 테스트에서 플래시어레이//X90이 DAS를 능가했습니다. 결과를 살펴보기에 앞서 테스트 환경의 사양부터 살펴보겠습니다(그림 1 참조).
플래시어레이와 DAS의 테스트 환경 비교
테스트 환경은 다음과 같은 요소로 구성되었습니다.
다음 사양으로 구성된 서버 한 대:
- 각기 24개의 코어가 탑재되고 하이퍼스레딩(hyperthreading) 기술이 활성화된 인텔® 제온® 플래티넘(Intel® Xeon® Platinum) 8160 CPU(2.10GHz) 2개
- 512GB 용량의 메모리
- 12G 모듈식 RAID 컨트롤러와 2GB 캐시
- 800GB SAS SSD 2개 – RAID 0
- NVMe-oF RoCE용 Mellanox ConnectX-4 Lx 듀얼 포트 NIC
소프트웨어:
- CentOS 7.7
- 시스벤치(Sysbench) 0.19
- InnoDB 엔진이 지원되는 MySQL 8.0.19 Community Edition
통합 스토리지:
- 4개의 50Gb/s NVMe-oF RoCE 포트(컨트롤러당 2개)가 장착된 플래시어레이//X90 R3
- 퓨리티(Purity) 3.2
- 4개의 볼륨 추가 경로
플래시어레이와 DAS의 테스트 조건 비교
스토리지
DAS와 플래시어레이를 테스트하기 위해 XFS로 포맷된 단일 볼륨에 데이터베이스를 구축했습니다. 이때 DAS에는 RAID 0(스트라이프)으로 구성된 2개의 SAS SSD를 설치했습니다. RAID 0은 성능이 뛰어나 테스트에 많이 사용됩니다. 그러나 내결함성이 부족하여 운영 환경 데이터베이스에는 적합하지 않습니다. 다행히 스토리지 관리자들은 플래시어레이에 볼륨을 생성할 때는 가용성과 성능 중 하나를 포기하지 않아도 됩니다. 데이터는 항상 RAID-HA로 보호되기 때문입니다.
워크로드
워크로드를 생성하기 위해 MySQL 호스트에 시스벤치 버전 1.0.19를 설치했습니다. 시스벤치는 MySQL 드라이버가 이미 컴파일되어 있는 무료 성능 벤치마킹 툴입니다. 이 툴은 스크립트 방식으로 많은 가용 데이터베이스 워크로드와의 호환성을 지원합니다. 퓨어스토리지는 해당 테스트에 TPCC와 유사한 Percona 스크립트를 사용했습니다.
데이터베이스(MySQL)
그리고 32GB 버퍼 풀로 데이터베이스 서버를 구성했습니다. 버퍼 풀의 크기를 줄였더니 IO의 부담이 증가했습니다.
테스트 실행
벤치마크는 다음과 같은 단계로 진행했습니다.
- 데이터베이스 생성
- mysql 프롬프트(prompt)에서 ‘create database <database_name>;’ 명령 실행
- 테이블 및 데이터 준비
- 쉘(shell)에서 다음 명령 실행
‘sysbench <path_to_tpcc.lua>/tppc.lua –threads=<threads> –tables=10 –scale=100 –db-driver=mysql –mysql-db=<database_name> –mysql-user=<mysql_user> –mysql-password=<password> prepare
-
- 예시:
/usr/bin/sysbench /usr/share/sysbench/tpcc.lua –threads=48 –tables=10 –scale=100 –db-driver=mysql –mysql-db=sysbench10x100W –mysql-user=admin –mysql-password=’password’ prepare
- 벤치마크 실행
- 쉘에서 다음 명령 실행
‘sysbench <path_to_tpcc.lua>/tppc.lua –threads=<threads> –time=<run_time[s]> –tables=<number_of_tables> –scale=<number_of_warehouses> –db-driver=mysql –mysql-db=<database_name> –mysql-user=<mysql_user> –mysql-password=<password> run > <output_file>
-
- 예시:
/usr/bin/sysbench /usr/share/sysbench/tpcc.lua –threads=48 –time=300 –tables=10 –scale=100 –db-driver=mysql –mysql-db=sysbench10x100W –mysql-user=admin –mysql-password=’password’ run > ~/results/5min/r3/32GBP10x100WFA48.out
퓨어스토리지는 테스트용 데이터베이스에 100개의 웨어하우스를 구현하고 10개의 데이터 세트를 추가했습니다. 구성 변경의 영향을 더 정확히 추산하기 위해 스레드(사용자)를 8가지(8, 16, 24, 32, 48, 64, 96, 128)로 설정하여 테스트했습니다. 시스벤치 테스트는 MySQL 서버에서 각기 5분 동안 실행되었으며, 테스트를 마칠 때마다 30초의 유휴 시간을 두었습니다.
DAS 구성으로도 같은 테스트 단계를 반복했지만, DAS 데이터베이스 볼륨 설치 지점이 제대로 반영되도록 MySQL datadir 파라미터(parameter)를 수정했습니다.
블로그 맨 하단의 부록 A에는 시스벤치의 샘플 결과가 제시되어 있습니다.
결과
테스트의 결과는 간단했습니다. 플래시어레이//X가 DAS를 능가합니다!
그림 2와 3에서 볼 수 있듯이, TPCC와 유사한 워크로드를 사용할 때 퓨어스토리지의 최신 세대 플래시어레이//X R3에 데이터베이스 볼륨을 구현한 MySQL이 성능 최적형 DAS 구성을 능가했습니다. 활성 상태인 데이터베이스 사용자 수, 즉 스레드 수를 늘릴수록 성능 격차는 훨씬 더 벌어졌습니다. 실제로, 플래시어레이//X의 초당 트랜잭션(tps)이 50% 이상 높았고, 레이턴시는 최대 34% 더 낮았습니다.
엔드-투-엔드 NVMe 및 MySQL 기반의 플래시어레이//X는 표준 SAS SSD DAS 스토리지보다 성능이 뛰어납니다. 또한 퓨리티//FA(Purity//FA)가 검증된 고가용성과 편리한 비즈니스 연속성, 재해 복구 옵션, 그리고 업계 최고의 데이터 압축 기술을 비롯한 다채로운 데이터 서비스를 지원한다는 점을 고려하면 플래시어레이//X에 MySQL 운영 환경을 구현하는 것이 당연한 선택입니다. MySQL 데이터베이스를 DAS에서 퓨어스토리지로 이전하면 이 모든 이점을 고스란히 누릴 수 있습니다.
플래시어레이//X R3에 대한 추가 정보
- 제품 페이지: 플래시어레이//X가 귀사의 업무를 어떻게 간소화할 수 있는지 자세히 알아보십시오.
- 블로그 게시물: 고성능 블록 스토리지를 제공하는 퓨어스토리지의 최신 플래시어레이//X
- 블로그 게시물: 한층 더 향상된 SAP HANA 성능
추가 참고 자료
부록 A
# 환경 설정 변경 방법은 아래 링크를 참조하십시오.
# https://dev.mysql.com/doc/refman/8.0/en/server-configuration-defaults.html
[mysqld]
default-authentication-plugin=mysql_native_password
datadir=/r3data/mysql
# datadir=/das/mysql
socket=/var/lib/mysql/mysql.sock
bind-address=0.0.0.0
log-error=/var/log/mysqld.log
pid-file=/var/run/mysqld/mysqld.pid
# general
max_connections=4000
table_open_cache=8000
table_open_cache_instances=16
back_log=1500
default_password_lifetime=0
ssl=0
performance_schema=OFF
# binlog_row_image=minimal
# max_prepared_stmt_count=128000
max_prepared_stmt_count=512000
skip_log_bin=1
character_set_server=latin1
collation_server=latin1_swedish_ci
skip-character-set-client-handshake
transaction_isolation=REPEATABLE-READ
# innodb_page_size=32768
# files
innodb_file_per_table
innodb_log_file_size=1024M
innodb_log_files_in_group=32
innodb_open_files=4000
innodb_log_compressed_pages=off
# buffers
innodb_buffer_pool_size=32G
innodb_buffer_pool_instances=16
innodb_log_buffer_size=32M
# tune
innodb_doublewrite=0
innodb_thread_concurrency=0
innodb_flush_log_at_trx_commit=1
innodb_max_dirty_pages_pct=90
innodb_max_dirty_pages_pct_lwm=10
join_buffer_size=32K
sort_buffer_size=32K
innodb_use_native_aio=1
innodb_stats_persistent=1
innodb_spin_wait_delay=6
innodb_max_purge_lag_delay=300000
innodb_max_purge_lag=0
innodb_flush_method=O_DIRECT_NO_FSYNC
innodb_checksum_algorithm=none
innodb_io_capacity=10000
innodb_io_capacity_max=30000
innodb_lru_scan_depth=9000
innodb_change_buffering=none
innodb_read_only=0
innodb_page_cleaners=4
innodb_undo_log_truncate=off
# perf special
innodb_adaptive_flushing=1
innodb_flush_neighbors=0
innodb_read_io_threads=16
innodb_write_io_threads=16
innodb_purge_threads=4
innodb_adaptive_hash_index=0
# monitoring
innodb_monitor_enable=’%’
