개요
MySQL에 필요한 4가지 기본 리소스는 CPU, 메모리, 디스크, 네트워크 리소스이다. 네트워크는 심각한 병목 현상을 거의 나타내지 않지만, CPU, 메모리, 디스크는 확실히 자주 나타낸다. CPU, 메모리, 디스크 간의 관계는 복잡하여, 한 영역의 문제가 종종 다른 곳에서 나타난다. 어떤 문제에 자원을 투입하기 전에 다른 문제에 자원을 대신 투입해야하는지 자문하는 과정이 필요하다. 이 장에서는 MySQL의 적절한 성능을 위해 하드웨어와 운영 체제를 어떻게 구성해나가는 것이 필요한지 다룬다.
MySQL의 성능을 제한하는 요소
MySQL의 가장 흔한 병목 현상은 "CPU 고갈"이다. MySQL이 병렬로 너무 많은 쿼리를 실행하려고 하거나 수가 적더라도 CPU에서 쿼리가 너무 오랫동안 실행될 때 CPU 포화가 발생할 수 있다. ( 이는 현재 내가 개발에 참여하고 있는 다글로 서버에서도 운영 초기에 마주했던 문제이기도 하다 )
물론 I/O 포화도 발생할 수 있다지만, CPU 고갈보다는 훨씬 드물다. CPU 고갈은 주로 SSD (Solid State Drive) 사용으로의 전환 때문에 발생한다. 과거, 작업을 메모리에서 하지 않고 HDD 에서 수행할 때는 특히나 성능 저하가 극심했다.
MySQL용 CPU를 선택하는 방법
일반적으로 서버에는 2가지 목표가 있다.
1. 짧은 대기 시간 ( 빠른 응답 )
- 이를 위해서, 각 쿼리가 하나의 CPU만 사용하기 때문에 빠른 CPU가 필요하다.
2. 높은 처리량
- 동시에 여러 쿼리를 실행하고자 한다면, 멀티 CPU의 이점을 통해 쿼리를 처리할 수 있다.
따라서 현재 하드웨어를 업그레이드하거나 새로 구매해야하는 상황이라면, 워크로드가 CPU에 종속되는지 여부를 고려해야 한다. CPU 전체 부하량만 보는 대신, 가장 중요한 쿼리에 대한 CPU 사용률과 I/O 균형을 살펴보고 CPU가 고르게 로드되었는지 확인해야한다.
워크로드가 모든 CPU를 활용하지 않는 경우, MySQL은 InnoDB 버퍼 삭제, 네트워크 작업 등과 같은 백그라운드 작업에 추가 CPU를 사용할 수 있다는 점을 고려해야 한다. 다만, 이런 작업들은 일반적으로 쿼리를 실행하는 것에 비해 미미한 수준이다.
메모리 및 디스크 리소스의 균형 유지
MySQL이 메모리를 사용하는 주된 이유는 결국 성능에 있다. 궁극적으로 느린 디스크 I/O 대신 메모리에 있는 데이터에 엑세스하는 것이 성능 상에서 더 많은 이점을 지닌 것이다. 따라서 메모리의 크기, 속도, 비용 등을 적절히 조절하여 워키로드 성능을 향상 시키는 것이 중요하다.
읽기, 쓰기, 캐싱
만약 메모리가 매우 충분하면, 읽기 요청으롭퉈 디스크를 완전히 차단할 수 있다. 서버의 캐시가 준비되면 모든 읽기가 캐시 히트 ( cache hit )하게 된다. 즉, 메모리에서 논리적 읽기가 지속되지만, 디스크에서의 물리적 읽기는 없는 셈이다.
하지만 쓰기는 다르다. 읽기와 마찬가지로 쓰기 역시 메모리에서 수행할 수 있지만, 어디까지나 "지연" 정도의 역할이다. 빠르게 디스크에 기록해서 데이터를 영구적으로 만드는 작업은 불가피하고, 결국 캐시는 쓰기를 완전히 배제할 수 없다.
그럼에도 불구하고, 캐시를 사용하면 쓰기를 두 가지 중요한 방식으로 함께 그룹화할 수 있다.
1. 다수의 쓰기 & 한 번의 플러시
- 모든 새 값을 디스크에 기록하지 않고도 단일 데이터 조각을 메모리에서 여러 번 변경할 수 있다. 변경 후, 데이터가 디스크로 플러시되면 마지막 물리적 쓰기 이후 발생한 모든 수정 사항은 영구적이다. 가령, 많은 쓰기 작업이 테이블 메타데이터 내 Row count를 변경시킬 수 있는데, 여기서 모든 쓰기 작업마다 디스크에 접근하는 것이 아닌 count를 한 번에 증가시키고 디스크에 기록하는 방식이다. 이러한 방식으로 여러 쓰기 작업을 하나로 그룹화할 수 있다.
2. I/O 병합
메모리에서 다양한 데이터 조각을 수정할 수 있고, 수정 사항을 수집 가능하므로 단일 디스크 작업으로 물리적 쓰기를 수행할 수 있다.
이러한 그룹화된 쓰기가 바로 트랜잭션 시스템이 로그 선행 기법 전략을 사용하는 이유이다. 로그 선행 기법을 사용하면, 디스크에 대한 변경 내용을 플러시하지 않고 메모리에 순차 로그 파일의 변경 사항에 대한 기록을 작성한다. 이 기록을 바탕으로 백그라운드 스레드는 수정된 데이터를 나중에 디스크로 플러시할 수 있으며, 쓰기를 최적화할 수 있다.
결국 쓰기는 랜덤 I/O를 순차적인 I/O로 변환하기 때문에 비동기( 버퍼링 )의 이점이 크다. 비동기 쓰기는 일반적으로 운영 체제에서 처리되며, 디스크에 보다 효율적으로 플러시할 수 있도록 일괄 처리된다.
작업세트
모든 애플리케이션에는 데이터의 '작업 세트'가 있다.
작업 세트란?
실제로 작업을 수행하는 데 필요한 데이터
메모리에 있어야 하는 데이터는 MySQL의 모든 데이터가 아닌 작업 세트만 있으면 된다. 책상과 컴퓨터에 빗대어 보면, 책상 내 서랍들은 MySQL 데이터 베이스, 반면 컴퓨터는 메인메모리, 작업세트는 컴퓨터 바탕화면에 있는 폴더 정도이다.
솔리드 스테이트 스토리지
솔리드 스테이트 ( 플래시 ) 저장 장치는 자기 플래터 대신 셀로 구성된 비휘발성 플래시 메모리 칩 ( NonVolatile Random Access Memory )을 사용한다. 움직이는 부품이 없어 하드 드라이브와 매우 다르게 작동한다.
솔리드 스테이트 스토리지는 대부분의 데이터베이스 시스템의 표준으로, 특히 온라인 트랜잭션 ( OLTP ) 에서 주로 사용된다. 2015년을 전후로 SSD 가격이 크게 하락하면서, HDD보다 월등히 성능이 좋은 솔리드 스테이트 스토리지는 대부분의 HDD 데이터 베이스를 대체했고, HDD는 결국 매우 큰 데이터 웨어하우스나 레거시 시스템에만 남게 되었다.
솔리드 스테이트 저장 장치의 장점은 아래와 같이 정리 가능하다.
1. HDD에 비해 훨씬 우수한 랜덤 읽기 및 쓰기 성능
2. HDD에 비해 조금 우수한 순차 읽기 및 쓰기 성능
3. HDD보다 월등하게 나은 동시성 지원
플래시 메모리 개요
하드 드라이브에 물리적으로 고유한 한계와 특성이 있는 것과 마찬가지로 플래시 메모리 위에 구축된 솔리드 스테이트 스토리지에도 한계가 있다. 어떤 면에서는 플래시 메모리의 한계는 매우 심각하고 극복하기 어려우며, 일반적인 솔리드 스테이트 스토리지는 추상화나 캐싱 등의 복잡한 아키텍처를 지니고 있다.
플래시 메모리의 가장 큰 특징은 여러 번 빠르게 작은 단위로 읽을 수 있지만 쓰기는 더 어렵다는 점이다. 셀은 특별한 지우기 작업 없이는 다시 쓸 수 없으며, 지우기 주기가 느려지면 블록이 마모된다. 나아가 지우기 작업은 큰 블록( 512 KB 등 )을 위주로만 진행할 수 있다.
결국 이러한 쓰기에 대한 제한이 솔리드 스테이트 스토리지의 복잡성을 야기한다. 쓰기 작업이 잘 수행되고 플래시 메모리 블록이 너무 일찍 마모되는 것을 방지하려면 장치가 페이지를 재배치하고 가비지 컬렉션, 이른바 웨어 레벨링을 수행할 수 있어야 한다.
플래시 블랙의 마모란?
플래시 메모리 셀은 프로그램-삭제( P/E Cycles ) 회수가 제한되어 있다. 예를 들어, SSD 가 하나의 NAND 플래시 메모리 셀에만 접근하여 읽기 / 삭제 작업을 수행한다면, 해당 셀은 빠르게 P/E Cycles를 넘게 되고, 결국 SSD 컨트롤러는 이 셀을 사용 불가능으로 마킹하게 된다. [출처]
가비지 컬렉션
솔리드 스테이트 스토리지는 일부 블록을 최신 상태로 유지하고 새로운 쓰기를 유지하기 위해 블록을 회수하는 과정을 거친다. 이를 가비지 컬렉션이라고 하는데, 이 작업을 수행하기 위해 장치는 약간의 여유 공간이 필요하다. 장치 내부에 보이지 않는 일부 예약된 공간이 있거나 완전히 채우지 않도록 직접 공간을 예약해야 한다. 장치가 가득차면 가비지 컬렉션이 일부 블록을 깨끗하게 유지하기 위해 저 열심히 일해야 하므로 쓰기 증폭 계수 ( write amplification factor ) 가 증가한다.
쓰기 증폭 계수란?
부분 블록 쓰기로 인해 데이터를 이곳저곳 이동하거나 데이터 및 메타데이터를 여러 번 기록하면서 발생하는 추가 쓰기이다.
SSD는 페이지 단위의 쓰기가 발생하는데, 가령 페이지가 32KB 라면, 1 BYTE의 데이터만 기록할 때도 32 KB의 페이지를 사용해야하는 셈이다. 이는 필요 이상의 오퍼레이션을 유발한다. [출처]
'Database > High Performance MySQL' 카테고리의 다른 글
| 스키마 설계와 관리 (2) | 2023.10.26 |
|---|---|
| 서버 설정 최적화 (0) | 2023.09.10 |
| Performance Schema (2) (0) | 2023.08.17 |
| Performance Schema (1) (0) | 2023.08.15 |
| 신뢰성 엔지니어링 환경에서의 모니터링 (2) | 2023.07.31 |