4.1 아키텍처

4.1.1 Mysql 전체 구조

(사실 아키텍처는 책의 4장이다. 1,2,3 장은 설치와 설정 및 사용권한이기에 가볍게 읽어보고 넘어가기로 했다.)

 

 Mysql 서버는 사람의 머리 역할을 담당하는 Mysql 엔진과 손발 역할을 담당하는 스토리지 엔진으로 구분할 수 있다. 손과 발의 역할을 담당하는 스토리지 엔진은 핸들러 API를 만족하면 누구든 스토리지 엔진을 구현해서 Mysql 서버에 추가해서 사용할 수 있다. 이번 장에서는 Mysql 엔진과 Mysql 서버에서 기본적으로 제공되는 InnoDB 스토리지 엔진, MyISAM 스토리지 엔진을 구분해서 볼 것이다.

 

Mysql 서버는 크게 MySQL 엔진과 스토리지 엔진으로 구분할 수 있는데, 이 책에서는 Mysql의 쿼리파서나 옵티마이저 등과 같은 기능을 스토리지 엔진과 구분하고자 위처럼 하였다. 이 둘을 모두 합쳐서 Mysql 또는 Mysql 서버라고 표현하겠다.

 

MySQL 엔진 : 클라이언트로부터 접속 및 쿼리 요청을 처리하는 커넥션 핸들러와 SQL 파서 및 전처리기, 쿼리의 최적화된 실행을 위한 옵티마이저가 중심을 이룬다. Mysql은 표준 SQL 문법을 지원하기 때문에 표준 문법에 따라 작성된 쿼리는 타 DBMS와 호환되어 실행될 수 있다.

 

스토리지 엔진 : Mysql 엔진은 요청된 SQL 문장을 분석하거나 최적화하는 등 DBMS의 두뇌에 해당하는 처리를 수행하고, 실제 데이터를 디스크 스토리지에 저장하거나 디스크 스토리지로부터 데이터를 읽어오는 부분은 스토리지 엔진이 전담한다. Mysql 서버에서 Mysql 엔진은 하나지만 스토리지 엔진은 여러개를 동시에 사용할 수 있다. 아래와 같이 테이블이 사용할 스토리지 엔진을 지정하면 해당 테이블의 모든 읽기 작업이나 변경 작업은 정의된 스토리지 엔진이 처리한다.

 

(mysql > CREATE TABLE test_table (fd1 INT, fd2 INT) ENGINE=INNODB;) 이제 test_table에 INSERT, UPDATE 등이 발생하면 InnoDB 스토리지 엔진이 그러한 처리를 담당한다. 그리고 각 스토리지 엔진은 성능 향상을 위해 키 캐시(MyISAM 스토리지 엔진)나 InnoDB 버퍼 풀(InnoDB 스토리지 엔진)과 같은 기능을 내장하고 있다.

 

핸들러 API : Mysql 엔진의 쿼리 실행기에서 데이터를 쓰거나 읽어야 할 때는 각 스토리지 엔진에 쓰기 또는 읽기를 요청하는데 이를 핸들러 요청이라고 하고, 여기서 사용되는 API를 핸들러 API라고 한다. InnoDB 스토리지 엔진 또한 이 핸들러 API를 이용해 Mysql 엔진과 데이터를 주고받는다. 이 핸들러 API를 통해 얼마나 많은 데이터 작업이 있었는지 확인할 수 있다.

 

 

4.1.2 백그라운드, 포그라운드 스레드

 

 

Mysq 서버는 스레드 기반으로 작동하며, 크게 포그라운드 스레드와 백그라운드 스레드로 구분할 수 있다.

 

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

 

 또한 포그라운드 스레드는 데이터를 Mysql의 데이터 버퍼나 캐시로부터 가져오며, 버퍼나 캐시에 없는 경우에는 직접 디스크의 데이터나 인덱스 파일로부터 데이터를 읽어서 작업을 처리한다. MyISAM 테이블은 디스크 쓰기 작업까지 포그라운드 스레드가 처리하지만 InnoDB 테이블은 데이터 버퍼나 캐시까지만 포그라운드 스레드가 처리하고, 나머지 버퍼로부터 디스크까지 기록하는 작업은 백그라운드 스레드가 처리한다.

 

 

백그라운드 스레드 : InnoDB는 다음과 같이 여러가지 작업이 백그라운드로 처리된다.

1) 인서트 버퍼를 병합하는 스레드

2) 로그를 디스크로 기록하는 스레드 (중요)

3) InnoDB 버퍼 풀의 데이터를 디스크에 기록하는 스레드 (중요)

4) 데이터를 버퍼로 읽어오는 스레드

5) 잠금이나 데드락을 모니터링하는 스레드

 

 

 모두 중요하지만 가장 중요한 것은 로그 스레드와 버퍼의 데이터를 디스크로 내려쓰는 작업을 처리하는 쓰기 쓰레드일 것이다.

InnoDB 에서 데이터를 읽는 작업은 주로 클라이언트 스레드에서 처리되기 때문에 읽기 스레드는 많이 설정할 필요가 없지만, 쓰기 스레드는 많은 작업을 백그라운드로 처리하기 때문에 일반적인 내장 디스크를 사용할 때는 2~4 정도, DAS나 SAN과 같은 스토리지를 사용할 때는 디스크를 최적으로 사용할 수 있을 만큼 충분히 설정하는 것이 좋다.

 

 사용자 요청 처리 중 쓰기 작업은 지연되어 처리될 수 있지만, 데이터의 읽기 작업은 절대 지연되지 않기 때문에 InnoDB를 포함한 일반적인 사용 DBMS에는 대부분 쓰기 작업을 버퍼링해서 일괄 처리하는 기능이 탑재되어 처리됩니다.

 

 그래서 InnoDB에서는 INSERT, DELETE, UPDATE 쿼리를 작업하기 위해 데이터 변경이 필요한 경우, 데이터가 디스크의 데이터 파일로 완전히 저장될 때 까지 기다리지 않아도 됩니다 .하지만 MyISAM는 사용자 스레드가 쓰기 작업까지 함께 처리되도록 설계되어 있으며 일반적인 쿼리는 쓰기 버퍼링 기능을 사용할 수 없습니다.

 

 

4.1.3 메모리 영역

  Mysql에서 사용되는 메모리 공간은 크게 글로벌 메모리 영역과 로컬 메모리 영역으로 구분할 수 있다. 글로벌 메모리의 영역의 모든 메모리 공간은 Mysql 서버가 시작되면서 운영체제로부터 할당된다. 단순하게 Mysql의 시스템 변수로 설정해 둔 만큼 운영체제로부터 메모리를 할당받는다고 생각해도 된다. 글로벌 메모리, 로컬 메모리 영역은 Mysql 서버 내에 존재하는 많은 스레드가 공유해서 사용하는 공간인지 여부에 따라 구분되며 아래와 같은 특성이 있다.

 

글로벌 메모리 영역 : 일반적으로 클라이언트 스레드의 수와 무관하게 하나의 메모리 공간만 할당된다. 단 필요에 따라 2개 이상의 메모리 공간을 할당받을 수 있지만, 클라이언트의 스레드 수와는 무관하고 생성된 글로벌 영역이 N개라 하더라도 모든 스레드에 의해 공유된다. 대표적인 글로벌 메모리 영역은 위와 같다.

 

로컬 메모리 영역 : 세션 메모리 영역이라고 표현하며, Mysql 서버상에 존재하는 클라이언트 스레드가 쿼리를 처리하는데 사용하는 메모리 영역이다. 대표적으로 커넥션 버퍼와 정렬 버퍼 등이 있다. 위 그림 4.2에서 클라이언트가 Mysql 서버에 접속하면 Mysql 서버에서는 클라이언트 커넥션으로부터 요청을 처리하기 위해 스레드를 하나씩 할당하게 되는데, 클라이언트 스레드가 사용하는 메모리 공간이라고 해서 클라이언트 메모리 영역이라고도 한다. 

 

클라이언트와 Mysql 서버간 커넥션을 세션이라고 하기 때문에 세션 메모리 영역이라고 할 수 있는 것이다. 로컬 메모리는 각 클라이언트 스레드별로 독립적으로 할당되며 절대 공유되어 사용되지 않는 특징이 있다.

 

 

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

 Mysql은 독특하게 플러그인 모델이다. 플러그인 해서 사용할 수 있는 것이 스토리지 엔진만 있는 것이 아니라, 검색어 파서, 사용자 인증 등 다양한 플러그인이 구현되어 제공된다. 

 Mysql 쿼리가 실행되는 과정을 위처럼 크게 나눈다면 거의 대부분의 작업이 Mysql 엔진에서 처리되고, 마지막 '읽기/쓰기' 작업만 스토리지 엔진에 의해 처리된다. 각 처리 영역에서 읽기/쓰기 작업은 대부분 1건의 레코드 단위로 처리된다. 그리고 Mysql을 사용하다 보면 핸들러라는 단어를 자주 접하게 된다. Mysql 서버에서 Mysql 엔진은 사람 역할을 하고, 각 스토리지 엔진은 자동차 역할을 하는데, Mysql 엔진이 스토리지 엔진을 조정하기 위해 "핸들러" 라는 것을 사용하게 된다.

 

 간단하게 얘기하면 Mysql 엔진이 각 스토리지 엔진에게 데이터를 읽어오거나 저장하도록 명령하려면 반드시 핸들러를 통해야 한다는 점만 기억하자. Handler_로 시작하는 상태 변수가 있는데, 'Mysql 엔진이 각 스토리지 엔진에게 보낸 명령의 횟수를 의미하는 변수' 라고 이해하면 된다.

 

 Mysql에서 MyISAM이나 InnoDB와 같이 다른 스토리지 엔진을 사용하는 테이블에 대해 쿼리를 실행하더라도 Mysql의 처리 내용은 대부분 동일하며, 읽기/쓰기 영역의 차이만 있을 뿐이다. 실질적인 GROUP BY, ORDER BY 등 복잡한 처리는 스토리지 엔진 영역이 아니라 Mysql 엔진의 처리 영역인 '쿼리 실행기'에서 처리된다.

 

일단 현재 챕터에서 중요한 내용은 '하나의 쿼리 작업은 여러 하위 작업으로 나뉘는데, 각 하위 작업이 Mysql 엔진 영역에서 처리되는지 아니면 스토리지 엔진 영역에서 처리되는지 구분할 줄 아는 것이 중요하다.' 각 단위 작업을 거쳐 영역의 차이를 설명하는데 목적이 있기 때문이다.

 

 

4.1.5 컴포넌트

 Mysql 8.0 부터 기존의 플러그인 아키텍처를 대체하기 위해 컴포넌트 아키텍처가 지원된다. 예전 플러그인의 단점은

1) 플러그인은 오직 Mysql 서버와 인터페이스할 수 있고, 플러그인끼리는 통신X

2) 플러그인은 Mysql 서버의 변수나 함수를 직접 호출하기 때문에 안전X

3) 플러그인은 상호 의존 관계를 설정할 수 없기에 초기화가 어려움

 

 

4.1.6 쿼리 실행 구조

 

 위는 쿼리를 실행하는 관점에서 Mysql 구조를 간략하게 그림으로 표현한 것이고, 기능별로 나누어 보았다. 

 

1) 쿼리 파서

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

 

 

2) 전처리기

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

 

 

3) 옵티마이저

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

 

 

4) 실행엔진

 : 옵티마이저가 두뇌라면, 실행 엔진과 핸들러는 손과 발에 비유할 수 있다. 예로 옵티마이저가 GROUP BY를 처리하기 위해 임시 테이블을 사용하기로 결정했다고 해보자. (아래는 가벼운 예시이다.)

[ 실행 엔진이 핸들러에게 임시 테이블을 만들라고 요청 => 다시 실행 엔진은 WHERE절에 일치하는 레코드를 읽어오라고 핸들러에게 요청 => 읽어온 레코드들을 1번에서 준비한 임시 테이블로 저장하라고 다시 핸들러에게 요청 => 데이터가 준비된 임시테이블에서 필요한 방식으로 데이터를 읽어오라고 핸들러에게 다시 요청 => 최종적으로 실행엔진은 결과를 사용자나 다른 모듈로 넘김 ]

즉 실행 엔진은 만들어진 계획대로 각 핸들러에게 요청해서 받은 결과를 또 다른 핸들러 요청의 입력으로 연결하는 역할을 수행한다.

 

 

5) 핸들러(스토리지 엔진)

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

 

 

4.1.7 스레드 풀

 Mysql 엔터프라이즈 스레드 풀 기능은 Mysql 서버 프로그램에 내장돼 있지만 Percona Server의 스레드 풀은 플러그인 형태로 작동하게 구현돼 있다는 차이점이 있다. 스레드 풀은 내부적으로 사용자의 요청을 처리하는 스레드 개수를 줄여서 동시 처리되는 요청이 많더라도 Mysql 서버의 CPU가 제한된 개수의 스레드 처리에만 집중할 수 있게 해서 서버의 자원 소모를 줄이는 것이 목적이다. 

 

 일반적으로 CPU 코어의 개수와 스레드 풀 개수를 맞추는 것이 CPU 프로세서 친화도를 높이는데 좋다. 모든 스레드 그룹의 스레드가 각자 작업을 처리하고 있는 상태에서 새로운 쿼리 요청이 들어오더라도 스레드 풀은 thread_pool_stall_limit 시간 동안 기다려야만 새로 들어온 요청을 처리할 수 있다. 

 

 

4.1.8 트랜잭션 지원 메타데이터

 DB 서버에서 데이블의 구조 정보, 스토어드 프로그램 등 정보를 데이터 딕셔너리 또는 메타 데이터라고 하는데, Mysql 서버는 5.7 버전까지 테이블의 구조를 FRM 파일에 저장하고 일부 스토어드 프로그램 또는 파일기반으로 관리했다. 이런 파일 기반의 메타데이터는 생성 및 변경 작업이 트랜잭션을 지원하지 않기에 Mysql 서버가 비정상 종료되면 일관되지 않은 상태로 남는 문제가 있었다. 이를 'DB나 테이블이 깨졌다'라고 표현한다.

 

 Mysql 8.0 버전부터 메타데이터 등 정보를 모두 InnoDB 테이블에 저장하도록 개선됐다. Mysql 서버가 작동하는 데 기본적으로 필요한 테이블들을 묶어서 시스템 테이블이라고 하는데, 대표적으로 사용자 인증과 권한에 관련된 테이블이 있다. 모두 트랜잭션 기반의 InnoDB 스토리지 엔진에 저장되도록 개선되며 스키마 변경 작업 중간에 비정상 종료에도 안전했고, 문제를 예방할 수 있었다.

 

 하지만 MyISAM이나 CSV 같은 스토리지 엔진의 메타 정보는 여전히 저장할 공간이 필요하다. Mysql 서버는 InnoDB 스토리지 엔진 이외의 스토리지 엔진을 사용하는 테이블들을 위해 SDI 파일을 사용한다. 이 파일은 기존의 FRM파일과 동일한 역할을 한다. 

SDI -> 이름 그대로 직렬화를 위한 포맷이고, InnoDB 테이블도 이 구조로 변환할 수 있다. (Serialized Dictionary Information)