[Real MySQL 8.0] MySQL 엔진 아키텍처

MySQL 서버는 크게 머리 역할을 하는 MYSQL 엔진과 손발 역할을 담당하는 스토리지 엔진으로 구성된다. 기본으로 제공되는 스토리지 엔진으로는  InnoDB과 MyISAM 등이 있고, 핸들러 API를 만족하면 누구든지 스토리지 엔진을 추가하여 MYSQL 서버에 추가할 수 있다.

 

1. MYSQL 전체 구조

 

MySQL 고유의 C API부터 JDBC나 ODBC, 그리고 .NET의 표준 드라이버를 제공하며,
이러한 드라이버를 이용하여 C/C++, PHP, 자바, 펄, 파이썬, 루비, .NET 등 모든 언어로 MYSQL 서버에서 쿼리를 사용할 수 있게 지원한다.

MySQL 엔진

• Client로부터의 접속 및 쿼리 요청을 처리하는 커넥션 핸들러
• SQL 파서 및 전처리기
• 쿼리의 최적화된 실행을 위한 옵티마이저

위 구성요소가 MySQL 엔진의 중심을 이룬다.

MySQL은 표준 SQL 문법을 지원하기 때문에 표준 문법에 따라 작성된 쿼리는 다른 DBMS와 호환되며, 
MySQL 엔진은 요청된 SQL 문장을 분석하거나 최적화하는 등 DBMS의 두뇌와 같은 역할을 하며 MYSQL 서버에서 단 하나만 존재한다.

스토리지 엔진

실제 데이터를 디스크 스토리지에 저장하거나 디스크 스토리지로부터 데이터를 읽어오는 부분은 스토리지 엔진이 전담한다.
MySQL 엔진과는 다르게 여러개의 스토리지 엔진을 동시에 사용할 수 있다.

아래와 같이 해당 테이블이 사용할 스토리지 엔진을 지정하면 이후 테이블의 모든 읽기 작업이나 변경 작업은 정의된 스토리지 엔진이 처리한다.

CREATE TABLE member (age INT) ENGINE=INNODB;

각 스토리지 엔진은 성능 향상을 위해 아래와 같은 기능을 내장하고 있다.

• MyISAM: 키 캐시
• InnoDB: 버퍼 풀

핸들러 API

MYSQL 엔진의 쿼리 실행기에서 데이터를 쓰거나 읽어야 할 때는 각 스토리지 엔진에 쓰기 또는 읽기를 요청하는데,
이를 Handler 요청이라 한다. 이때 사용되는 API를 Handler API라고 한다.

정리하자면, 이 핸들러 API를 통해 스토리지 엔진이 MYSQL 엔진과 데이터를 주고 받는 것이다.

2. MySQL 스레딩 구조

MySQL 서버는 Process 기반이 아니라 Thread 기반으로 작동하며, Foreground Thread와 Background Thread 로 구분할 수 있다.

Foreground 스레드 (클라이언트 스레드)

Foreground 스레드는 최소한 MySQL 서버에 접속된 클라이언트의 수만큼 존재하며, 주로 각 클라이언트 사용자가 요청하는 쿼리 문장을 처리한다. 클라이언트 사용자가 작업을 마치고 커넥션을 종료하면 해당 커넥션을 담당하던 스레드는 다시 스레드 캐시로 되돌아간다.
이때 이미 스레드 캐시에 일정 개수 이상의 스레드가 대기중이면 캐시에 넣지 않고 스레드를 종료시켜 일정 개수를 유지한다.

포그라운드 스레드는 데이터를 MySQL의 데이터 버퍼나 캐시로부터 가져오며, 버퍼나 캐시에 없는 경우에는 직접 디스크의 데이터나 인덱스 파일로부터 데이터를 읽어와서 작업을 처리한다.

MyISAM 테이블은 디스크 쓰기 작업까지 포그라운드 스레드가 처리하지만,
InnoDB 테이블은 데이터 버퍼나 캐시까지만 포그라운드 스레드가 처리하고, 나머지 버퍼로부터 디스크까지 기록하는 작업은 백그라운드 스레드가 처리한다.

Background 스레드

InnoDB의 경우 다음과 같이 여러 가지 작업이 백그라운드로 처리된다.

• Insert Buffer를 병합하는 스레드
• 로그를 Disk로 기록하는 스레드
• InnoDB Buffer Pool의 데이터를 Disk에 기록하는 스레드
• 데이터를 버퍼로 읽어 오는 스레드
• 잠금이나 데드락을 모니터링하는 스레드

가장 중요한 백그라운드 스레드는 Log Thread와 Write Thread이다.
InnoDB에서도 데이터를 읽는 작업은 주로 Foreground Thread에서 처리되기 때문에 읽기 스레드는 많이 설정할 필요가 없지만,
Write Thread의 경우 아주 많은 작업을 백그라운드로 처리하기 때문에 일반적인 내장 디스크를 사용할 때는 2~4 정도를 설정하고, DAS나 SAN과 같은 스토리지를 이용할 때는 디스크를 최적으로 사용할 수 있을 만큼 충분히 설정하는게 좋다.

사용자의 요청을 처리하는 도중 데이터의 쓰기 작업은 지연(버퍼링)되어 처리될 수 있지만 데이터의 읽기 작업은 절대 지연될 수 없다.
그래서 일반적인 상용 DBMS에서는 대부분 쓰기 작업을 버퍼링해서 일괄 처리하는 기능이 탑재되어 있고 InnoDB도 그렇게 동작한다.
하지만, MyISAM은 그렇지 않고 사용자 스레드가 쓰기 작업까지 함께 처리하도록 설계되어 있다.

따라서, InnoDB는 INSERT, UPDATE, DELETE 쿼리에 대해서 데이터가 변경되는 경우 데이터가 디스크에 저장될 때까지 기다리지 않아도 되지만 MyISAM의 경우에는 쓰기 버퍼링 기능을 사용할 수 없어서 대기해야 한다.

3. 메모리 할당 및 사용 구조

MySQL에서 사용되는 메모리 공간은 크게 글로벌 메모리 영역과 로컬 메모리 영역으로 구분된다.
글로벌 메모리 영역은 MySQL 서버가 시작되면서 OS로부터 할당된다.
글로벌 메모리 영역과 로컬 메모리 영역은 MySQL 서버 내에 존재하는 많은 스레드가 공유해서 사용하는 공간인지 여부에 따라 구분된다.

글로벌 메모리 영역

일반적으로 포그라운드 스레드의 수와 무관하게 하나의 메모리 공간만 할당된다. 필요에 따라 2개이상의 메모리 공간을 할당받을 수 있지만 포그라운드 스레드와는 무관하며 생성된 글로벌 영역이 여러개더라도 모든 스레드에 의해 공유된다.
글로벌 메모리 영역의 종류는 아래와 같다.

• 테이블 캐시
• InnoDB 버퍼 풀
• InnoDB 어댑티브 해시 인덱스
• InnoDB 리두 로그 버퍼

 

로컬 메모리 영역

세션 메모리 영역이라고도 표현하며, MySQL 서버상에 존재하는 클라이언트 스레드가 쿼리를 처리하는데 사용하는 메모리 영역이다.
클라이언트가 MySQL 서버에 접속하면 서버내에서는 클라이언트 커넥션으로부터의 요청을 처리하기 위해 클라이언트 스레드를 하나씩 할당하게 되는데, 클라이언트 스레드가 사용하는 메모리 공간을 클라이언트 메모리 영역이라고 한다. 클라이언트와 MySQL 서버와의 커넥션을 세션이라고 하기 때문에 로컬 메모리 영역을 세션 메모리 영역이라고도 한다.

로컬 메모리 영역은 각 클라이언트 스레드별로 독립적으로 할당되며 절대 공유되지 않는다는 특성이 있다. 또 다른 특징으로는 각 쿼리의 용도별로 필요할 때만 공간이 할당되고 필요하지 않은 경우에는 메모리 공간을 할당하지 않을 수 있다. 커넥션 버퍼와 결과 버퍼는 커넥션이 열려있는 동안 계속 할당된 상태이지만, 소트 버퍼나 조인 버퍼는 쿼리를 실행하는 순간에만 할당했다가 다시 해제한다.

로컬 메모리 영역의 종류는 아래와 같다.

• 정렬 버퍼
• 조인 버퍼
• 바이너리 로그 캐시
• 네트워크 버퍼

4. 플러그인 스토리지 엔진 모델

수많은 사용자의 요구 조건을 만족시키기 위해 기본적으로 제공되는 스토리지 엔진 이외에 부가적인 기능을 더 제공하는 스토리지 엔진을 직접 개발하여 플러그인에 추가할 수 있다. 또한 전문 검색 엔진을 위한 검색어 파서(인덱싱할 키워드를 분리하는 작업)과 사용자 인증 도구 등을 모두 플러그인으로 구현되어 제공된다.

컴포넌트

MySQL 8.0 부터는 기존의 플러그인 아키텍처를 대처하기 위해 컴포넌트 아키텍처가 지원된다. MySQL 서버의 플러그인은 몇 가지 단점이 있는데, 컴포넌트는 이러한 단점들을 보완해서 구현되었다.

5. 쿼리 실행 구조

MySQL 엔진이 각 스토리지 엔진에게 데이터를 읽어오거나 저장하도록 명령하려면 반드시 핸들러를 통해야 한다.
MyISAM이나 InnoDB와 같이 다른 스토리지 엔진을 사용하는 테이블에 대해 쿼리를 실행하더라도 MySQL의 처리 내용을 동일하며 데이터 읽기와 쓰기 영역의 처리 차이가 있을 뿐이다. 실질적으로 복잡한 GROUP By나 ORDER BY 등 복잡한 처리는 스토리지 엔진 영역이 아니라 MySQL 엔진의 처리 영역인 SQL 실행기에서 처리된다.

쿼리 파서

쿼리 파서는 사용자 요청으로 들어온 쿼리 문장을 토큰(MySQL이 인식할 수 있는 최소 단위의 어휘나 기호)으로 분리해 트리 형태의 구조로 만들어 내는 작업을 의미한다. 쿼리 문장의 기본 문법 오류는 이 단계에서 발견되고 사용자에게 오류 메시지를 전달하게 된다.

전처리기

쿼리 파서 과정에서 만들어진 파서 트리를 기반으로 쿼리 문장에 구조적인 문제점이 있는지 확인한다. 각 토큰을 테이블 이름이나 컬럼 이름, 또는 내장 함수와 같은 개체를 매핑해 해당 객체의 존재 여부와 객체의 접근 권한등을 확인하는 과정을 이 단계에서 수행한다. 실제 존재하지 않거나 권한상 사용할 수 없는 개체의 토큰은 이 단계에서 걸러진다.

옵티마이저

사용자의 요청으로 들어온 쿼리 문장을 저렴한 비용으로 가장 빠르게 처리할지를 결정하는 역할을 담당하며 DBMS의 두뇌에 해당한다.

실행 엔진

옵티마이저가 두뇌라면 실행 엔진과 핸들러는 손과 발에 비유할 수 있다. 
실행 엔진은 만들어진 계획대로 각 핸들러에게 요청해서 받은 결과를 또 다른 핸들러 요청의 입력으로 연결하는 역할을 수행한다.

스토리지 엔진 (핸들러)

MySQL 서버의 가장 밑단에서 실행 엔진의 요청에 따라 데이터를 디스크로 저장하고 읽어오는 역할을 담당한다.
핸들러라고도 부르며, MyISAM 테이블을 조작하는 경우에는 핸들러가 MyISAM 스토리지 엔진이 되고 InnoDB 테이블을 조작하는 경우에는 InnoDB 스토리지 엔진이 핸들러가 된다.

6. 쿼리 캐시

쿼리 캐시는 빠른 응답을 필요로 하는 웹 기반 응용 프로그램에서 매우 중요한 역할을 담당했지만, 테이블의 데이터가 변경되면 캐시에 저장된 결과 중에서 변경된 테이블과 관련된 것들은 모두 삭제해야 하므로 심각한 동시 처리 성능 저하를 유발했다.

MySQL 8.0 에서는 쿼리 캐시는 완전히 제거되었다.

7. 스레드 풀

스레드 풀은 내부적으로 사용자의 요청을 처리하는 스레드 개수를 줄여서 동시 처리되는 요청이 많다 하더라도 MySQL 서버의 CPU가 제한된 개수의 스레드 처리에만 집중할 수 있게 해서 서버의 자원 소모를 줄이는 것이 목적이다.

스레드 풀이 실제 서비스에서 눈에 띄는 성능 향상을 보여주는 경우는 드물다. 스케줄링 과정에서 CPU 시간을 제대로 확보하지 못하는 경우에는 쿼리 처리가 더 느려지는 사례도 발생할 수 있다는 점에 주의해야 한다.

제한된 수의 스레드만으로 CPU가 처리하도록 적절히 유도한다면 CPU의 프로세스 친화도도 높이고 운영체제 입장에서는 불필요한 Context Switch를 줄여서 오버헤드를 낮출 수 있다.

스레드 그룹의 모든 스레드가 일을 처리하고 있다면 스레드 풀은 해당 스레드 그룹에 새로운 작업 스레드(Worker Thread)를 추가할지, 아니면 기존 작업 스레드가 처리를 완료할 때까지 기다릴지 여부를 판단해야 한다. 스레드 풀의 타이머 스레드는 주기적으로 스레드 그룹의 상태를 체크해서 thread_pool_stall_limit 시스템 변수에 정의된 밀리초만큼 작업 스레드가 지금 처리중인 작업을 끝내지 못하면 새로운 스레드를 생성해서 스레드 그룹에 추가한다. 이때 전체 스레드의 개수는 max 값을 넘을 수 없다. 
따라서, 모든 스레드 그룹의 스레드가 작업을 처리중이라면 새로운 쿼리 요청이 들어오더라도 thread_pool_stall_limit 밀리초만큼은 기다려야만 새로운 작업을 처리할 수 있다는 뜻이다. 응답 시간에 민감하다면 해당 시스템 변수를 적절히 낮춰서 사용해야 한다. 0에 가깝게 설정할 것이라면 차라리 스레드 풀을 사용하지 않는게 좋다.

MySQL 서버 엔터프라이즈 에디션에서만 스레드 풀을 제공하며, 커뮤니티 에디션에서는 지원하지 않는다. 플러그인을 설치하면 사용할 수 있기 하다.

8. 트랜잭션 지원 메타데이터

데이터베이스 서버에서 테이블의 구조 정보와 스토어드 프로그램 등의 정보를 메타데이터라고 한다.
MySQL 서버 5.7 버전까지 테이블의 구조를 파일으로 관리했다. 하지만, 이러한 파일 기반의 메타데이터는 생성 및 변경 작업이 트랜잭션을 지원하지 않기 때문에 테이블의 생성 또는 변경 도중에 MySQL 서버가 비정상적으로 종료되면 일관되지 않은 상태로 남는 문제가 있었다.

따라서, MySQL 8.0 부터는 테이블 구조 정보나 스토어드 프로그램의 코드 관련 정보를 모두 InnoDB의 테이블에 저장하도록 개선하였다.
또한, MySQL 서버가 작동하는데 기본적으로 필요한 테이블들을 시스템 테이블이라고 하는데, 대표적으로 사용자의 인증과 권한에 관련된 테이블들이 있다. MySQL 8.0 부터는 이 시스템 테이블 또한 InnoDB 스토리지 엔진을 사용하도록 개선하였다.