정리중 #1 엔진 아키텍처

📌 MySQL 엔진 아키텍처

MySQL Server는 다른 DB에 비해 구조가 독특한 편이다. 이로 인해 추가적인 혜택을 가질 수 있지만, 반대로 다른 DB에서 문제가 되지 않는 부분이 문제가 될 수 있다.

 

MySQL은 크게 나누면 앞단의 [MySQL 엔진]과 [Storage 엔진]으로 나누어진다.

대부분의 작업이 [MySQL 엔진]에서 처리되고, 데이터 읽기/쓰기만 [Storage 엔진]에서 처리한다. 

 

@ MySQL 엔진

요청된 SQL 문장을 분석하고 최적화한다.

전처리기, 옵티마이저, SQL Parser, Connection Handler 등이 포함된다.

실질적인 데이터 읽기/쓰기를 제외하고 Group By 나 Order By 같은 복잡한 쿼리 처리는 모두 여기에 있는 쿼리 실행기에 의해 이루어진다.

그럼 Storage 엔진이 하는게 뭐에요? 라고 물어볼 수 있지만, 데이터베이스의 파일처리는 내 컴퓨터에 있는 C드라이브처럼 단순하지 않다. 단순해보이는 데이터 읽기/쓰기가 다양한 기능과 성능을 보장하려면 얼마나 복잡해지는가를 나중에 배우게 될 것이다.

@ Handler API

MySQL 엔진의 쿼리 실행기가 데이터를 쓰거나 읽을 때는 스토리지 엔진에 요청해야한다.

이 요청에 사용하는 API를 Handler API 라고 한다.

해당 API를 통해 얼마나 많은 레코드 작업이 있었는지 확인할 수 있다.

 

@ 스토리지 엔진 (InnoDB, MyISAM)

여담으로 기존 사용하던 MyISAM은 MySQL Indexed Sequential Access Method 의 약어이고

오라클이 2005년 Innobase 사를 인수하여 InnoDB 라이센스를 가져왔고, Sun사 인수 이후 MySQL에 적용시킨 것이다.

실제 데이터를 디스크에 저장하거나, 읽어오는 역할을 담당한다.

MySQL 서버에서 [MySQL 엔진]은 하나 밖에 존재 못하지만, [Storage 엔진]은 여러개를 동시에 사용 할 수 있다.

실제로 아래와 같이 테이블에 특정 스토리지 엔진을 지정해두면, 해당 테이블의 모든 작업이 특정 스토리지를 사용한다.

mysql> CREATE TABLE test (fd1 INT, fd2 INT) ENGINE=INNODB;

그 외 엔진 성능을 향상 시키기위해 키 캐시, 버퍼 풀과 같은 기능을 내장하고 있다.

 

 

---

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

MySQL의 독특한 구조중 대표적인 것이 플러그인 모델이다. 엔진을 플러그인해서 사용하는 구조이다.

다만 Storage 엔진만 플러그인 할 수 있는게 아니라, 필요하다면 MySQL 엔진에 전문 검색을 위한 플러그인, 보안 인증플러그인 등을 필요한걸 추가하여 사용할 수 있다.

 

기본적으로 제공되는 스토리지 엔진 이외에 부가적인 기능을 제공하는 스토리지가 필요할 수 있으며, 전문 개발회사가 만드는 플러그인도 있지만 필요하다면 사용자가 직접 커스텀하여 개발할수도 있다.

 

참고로 MySQL 8.0 부터는 기존의 플러그인 아키텍처 대신, 컴포넌트 아키텍처가 지원된다.

플러그인에서 컴포넌트로 이름을 바꾼 이유는, 아래와 같은 플러그인의 단점을 개선시켰기 때문이다.

• 플러그인은 오직 MySQL 서버와 인터페이스 할 수 있고, 플러그인 끼리는 통신 불가능하다.
• 플러그인은 MySQL 서버의 변수나 함수를 직접 호출한다. (추상화, 캡슐화 되지않아 위험하다)
• 플러그인은 상호 의존 관계를 설정할 수 없다. 초기화가 어렵다.

 

---

📌 MySQL 스레딩 구조

MySQL은 프로세스 기반이 아니라 스레드 기반으로 동작한다.

한 프로세스 내에 foreground 와 background 스레드로 구분하여 동작한다.

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

Foreground는 서버에 접속된 클라이언트 수 만큼 존재하며, 각 클라이언트가 요청하는 쿼리 문장을 처리한다. 단 작업이 종료되면 Thread_Pool로 돌아가며 스레드의 개수를 시스템 변수로 조절할 수 있다. (thread_cache_size) 

 

Foreground 스레드는 MySQl의 데이터 버퍼나 캐시로부터 가져오며, 없는 경우에만 직접 디스크를 읽는다.

기존의 MyISAM은 디스크 쓰기 작업까지 가능했지만 InnoDB는 불가능하다. 오직 버퍼와 캐시, 디스크 읽기만 가능하다.

즉 버퍼에 기록된 데이터를 디스크에 기록하는건 백그라운드 스레드만 할 수 있다.

 

@ 백그라운드 스레드 (Background)

MyISAM은 클라이언트 스레드가 모든걸 처리했지만, InnoDB는 백그라운드 스레드의 역할이 분리되었다.

• 인서트 버퍼를 병합하는 스레드
• 로그를 디스크로 기록하는 스레드
• InnoDB 버퍼 풀의 데이터를 디스크에 기록하는 스레드
• 데이터를 버퍼로 읽어오는 스레드
• 잠금이나 데드락을 모니터링하는 스레드

클라이언트의 요청을 처리하는 도중 쓰기 작업은 지연(버퍼링)될 수 있지만, 읽기는 지연 될 수 없다. 그래서 일반적인 상용 DB는 대부분 쓰기 작업을 버퍼링해서 일괄처리하는 기능이 탑재되어 있으며 이는 InnoDB도 마찬가지이다.

 

이러한 이유로 InnoDB에서는 Insert, Update, Delete 쿼리로 데이터가 변경되더라도 디스크에 완전히 저장 될 때까지 기다리지 않아도 읽을 수 있다.

 

---

📌 메모리 할당 및 사용 구조

MySQL 메모리는 글로벌과 로컬로 나누어진다.

 

@ 글로벌 메모리 영역

글로벌 메모리는 MySQL 서버가 시작될 때 운영체제로부터 할당된다. 클라이언트 스레드 숫자와는 무관하며, 일반적으로 하나의 메모리 공간에 할당되고 모든 스레드가 공유하여 사용한다. 

 

다만 자바 static 영역처럼 무조건 처음부터 100% 할당되는건 아니고, 운영체제의 할당 방식에 따라 예약해두고 필요할 때 조금씩 할당해주는 경우도 있다.

 

@ 로컬 메모리 영역

로컬메모리는 세션, 커넥션 메모리라고도 부른다.

MySQL 서버 상에 클라이언트 스레드가 사용하는 메모리이며 스레드 별로 독립적으로 할당되고 절대 공유하지 않는다. 필요하지 않다면 아예 메모리 공간조차 할당하지 않는 경우도 있다. 이는 Sort, Join 버퍼도 마찬가지이다.

 

로컬 메모리의 생명주기는 버퍼에 따라 달라진다.

Connection, Result 버퍼는 클라이언트 커넥션이 열려있는 동안 계속 메모리 공간이 남아있으나 Sort, Join 버퍼는 쿼리를 실행하는 순간에만 할당했다가 다시 해제하게 된다.

 

---

📌 쿼리 실행구조

@ Qurey Cache (MySQL 8.0에 제거됨)

쿼리 캐시는 빠른 응답을 필요로 하는 웹 기반 서비스에서 중요한 역할을 담당했다.

SQL의 실행 결과를 캐시하여 동일한 SQL 쿼리가 실행되면 테이블을 읽지 않고 즉시 반환하는 캐시 메모리이다.

 

하지만 MySQL 8.0으로 넘어오며 쿼리 캐시는 MySQL 서버의 기능에서 시스템 변수를 포함한 모든 기능이 제거 되었다. 성능이 빠르다고 해도 테이블의 데이터가 변경되면 캐시에서 해당 데이터를 찾아서 삭제하는 것이 동시성능 처리에 심각한 영향을 주었고, 실제 서비스에서 쿼리 캐시가 성능에 큰 도움이 된 경우가 거의 없었기 때문이다.

무엇보다 수 많은 버그의 원인으로 지목되었기 때문에 제거된 것도 있다.

 

@ Query Parser

쿼리문을 토큰으로 분리해 트리 구조로 만들어 낸다. 토큰이 올바른지 확인하는 작업

 

@ PreProcessor

파서 트리를 기반으로 구조적인 문제점을 파악한다. 쿼리 파서는 토큰의 유효성만 검사한다면, 문법구조를 파악하는 작업. 이 단계에서 내장 함수를 매핑하고, 객체의 존재 여부, 접근 권한 또한 함께 확인한다.

  

@ Query Optimizer

전처리까지 완료된 유효한 쿼리를 최적화 시켜 Storage Engine에 넘길 실제 실행계획을 생성해낸다.

 

@ Query execution engine (api calls)

생성된 실행 계획을 바탕으로 Storage engine의 Handler API를 호출한다.

실질적인 API 호출과 클라이언트에게 결과 반환이 이루어지는 곳이다.

예를 들어 GROUP BY 라는 실행계획은 아래와 같은 작업이 진행된다.
1. 실행 엔진이 Handler API로 임시 테이블을 만들라고 요청
2. 실행 엔진은 WHERE 절에 일치하는 레코드를 읽어오라고 Handler API 요청
3. 읽어온 레코드들을 임시테이블에 저장하라고 Handler API 요청
4. 데이터가 준비된 임시 테이블에서 필요한 방식으로 데이터를 읽어오라고 Handler API 요청
5. 최종적으로 실행 엔진은 결과를 사용자나 다른 모듈로 넘김

 

@ Storage engines (Handler)

MySQL 서버 가장 밑단에서 데이터를 디스크에 저장하고, 읽어오는 역할을 담당한다.

즉 MyISAM, InnoDB 같은 Storage Engine을 Handler라고 부를 수 있다.

 

 

@ Thread Pool

MySQL의 기본 Thread Pool은 엔터프라이즈 버전에만 포함되어 있다.

그래서 여기에서는 커뮤니티에도 사용 가능한 Percona 플러그인을 통한 스레드 풀에 대해 간단히 설명하도록 하겠다.

 

스레드 풀은 내부적으로 사용자의 요청을 처리하는 스레드 개수를 줄여 CPU의 컨텍스트 스위치와 자원의 소모를 줄이는 것이 목적이다. 다만 많은 사람들이 그냥 스레드 풀을 사용하면 무조건 성능이 높아질 것이라 기대하는데 아무생각없이 설정한다면 각 스레드가 CPU 처리 시간을 확보 받지 못해 더 느려지는 사례도 발생할 수 있다는 걸 유의하자.

 

Percona Server 스레드풀은 기본적으로 CPU 코어 개수만큼 스레드 그룹을 생성한다. 

스레드 그룹의 모든 스레드가 일을 처리하고 있다면, 스레드 풀에서는 작업 스레드를 추가할지, 아니면 스레드 반환을 기다릴지 선택해야 한다. 이는 thread_pool_stall_limit 변수에 설정된 밀리초만큼 기다렸다가 생성하는데 thread_pool_max_threads 변수로 생성 가능한 최대 스레드 개수를 제한할 수 있다.

 

또한 후순위, 선순위 큐를 이용하여 SQL의 순서를 해당 트랜잭션의 Lock이 빠르게 풀리도록 조정하여 전체적인 성능을 향상시키는 기능도 가지고 있다.

 

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

MySQL 5.7 까지는 테이블 구조를 db.frm (format) 확장자 파일에 저장하고, 일부 stored program 또한 파일(.trn .trg .par)로 관리 했었다. 단순히 파일에 저장하는 메타데이터는 자체적인 트랜잭션을 지원할 수 없기 때문에 테이블 생성 & 변경 도중 MySQL 서버가 오류가 나서 종료되면 파일 내용이 일관되지 않는 문제가 있었다.

 

그래서 MySQL 8.0 부터는 테이블의 구조 정보, Stored Program등 메타데이터들을 InnoDB 에 시스템 테이블을 만들어 따로 저장한다. 즉 DB 데이터처럼 작업을 원자적으로 관리하여 MySQL의 서버가 비정상적으로 종료되더라도 문제가 없도록 바뀌었다.