04. 아키텍처 [4.2 InnoDB 스토리지 엔진 아키텍처 / 4.3, 4.4]

4.2 InnoDB 스토리지 엔진 아키텍처

I. 들어가며

MySQL의 주요 스토리지 엔진인 InnoDB의 핵심 개념과 내부 동작 방식을 개발자와 DBA 관점에서 설명합니다. InnoDB는 높은 안정성, 성능, 동시성 처리 능력을 제공하는 것이 특징이며, 그 아키텍처는 데이터를 저장하고, 동시성을 제어하며, 성능을 높이고, 데이터를 보호하는 메커니즘을 중심으로 이해할 수 있습니다.

• 데이터를 어떻게 저장하는가 (저장 방식)
• 동시성 이슈를 어떻게 처리하는가 (동시성 제어)
• 성능을 어떻게 높이는가 (메모리 활용)
• 데이터를 어떻게 보호하는가 (복구 메커니즘)

II. 주요내용

1. 데이터 저장 방식: 프라이머리 키와 클러스터링

InnoDB는 데이터를 디스크에 저장하는 방식에 있어 독특하고 효율적인 접근 방식을 사용합니다.

• 주요 원리: 프라이머리 키(PK) 기반 클러스터링
  • InnoDB의 가장 근본적인 특징은 모든 테이블 데이터를 프라이머리 키(PK) 순서대로 디스크에 물리적으로 정렬하여 저장한다는 점입니다. 이 구조를 '클러스터링 인덱스' 또는 '클러스터링 테이블'이라고 부릅니다.
  • 상세 설명 및 실무적 의의:
    • PK 기반 조회 성능 극대화: PK를 이용한 데이터 검색(조회)은 디스크 상에서 이미 정렬되어 있기 때문에 매우 빠릅니다. 따라서 쿼리의 대부분이 PK를 조건으로 하는 테이블 설계가 중요합니다.
    • 세컨더리 인덱스의 동작: 프라이머리 키 이외의 모든 인덱스(세컨더리 인덱스)는 데이터의 물리적 주소 대신 PK 값을 저장합니다. 따라서 세컨더리 인덱스로 데이터를 조회할 경우, 먼저 세컨더리 인덱스에서 PK 값을 찾고, 이 PK 값으로 다시 클러스터링 인덱스를 찾아 실제 데이터를 가져오는 두 번의 탐색 과정이 필요합니다.
    • PK 선택의 중요성: AUTO_INCREMENT처럼 순차적으로 증가하는 값을 PK로 사용하는 것이 가장 이상적입니다. UUID와 같이 무작위적인 값을 PK로 사용하면, 데이터 삽입 시 데이터 페이지의 분할(Page Split)이 빈번하게 발생하여 디스크 I/O가 늘어나고 성능이 크게 저하될 수 있습니다.
    • PK가 없는 테이블 처리: 테이블에 명시적인 PK가 없으면, InnoDB는 내부적으로 숨겨진 컬럼을 PK로 사용합니다. 이는 관리 및 성능 예측을 어렵게 하므로, 모든 테이블에 명시적으로 PK를 생성하는 것이 필수적입니다.
    • 외래 키(Foreign Key) 지원: InnoDB는 데이터 무결성을 보장하기 위해 외래 키를 지원합니다. 이는 MyISAM과 같은 다른 스토리지 엔진과의 중요한 차이점입니다.

2. 동시성 제어: MVCC와 잠금 없는 읽기

여러 트랜잭션이 동시에 데이터에 접근할 때 데이터의 일관성을 유지하면서도 처리 성능을 높이는 것은 InnoDB의 핵심 기술입니다.

• 주요 원리: MVCC (Multi Version Concurrency Control)
  • InnoDB는 MVCC (다중 버전 동시성 제어)라는 기술을 사용하여 동시성을 효율적으로 제어합니다. 이 원리는 특정 레코드에 변경이 발생할 때 기존 데이터를 바로 덮어쓰지 않고, 언두 로그(Undo Log) 영역에 이전 데이터를 백업해 두는 것입니다.
  • 상세 설명 및 실무적 의의:
    • 높은 동시성 처리: MVCC 덕분에 여러 트랜잭션이 각기 다른 버전의 데이터를 보면서 작업을 수행할 수 있습니다. 이는 읽기 작업이 쓰기 작업을 막지 않고, 쓰기 작업도 읽기 작업을 막지 않는 형태로, 일반적인 웹 서비스 환경에서 매우 높은 처리량을 제공하는 핵심 원리입니다.
    • 잠금 없는 일관된 읽기 (Non-Locking Consistent Read): MVCC를 통해 일반적인 SELECT 쿼리는 다른 트랜잭션이 데이터를 수정하고 있더라도 잠금을 기다리지 않고 언두 로그에 백업된 이전 버전의 데이터를 읽어올 수 있습니다. 이는 조회 성능 저하 없이 데이터의 일관성을 보장합니다.
    • 잠금 및 데드락 처리: InnoDB는 레코드(행) 단위의 잠금을 제공하여 동시성을 높이며, 여러 트랜잭션 간에 교착 상태(Deadlock)가 발생하면 이를 자동으로 감지하여 하나의 트랜잭션을 강제로 롤백시켜 문제를 해결합니다.
      • Undo 레코드를 적게 가진것은 롤백을 해도 Undo 처리를 해야할일이 남아있으므로 부하가 덜 유발됨

3. 성능 향상을 위한 메모리 구조

InnoDB는 디스크 I/O를 최소화하고 데이터 접근 속도를 극대화하기 위해 다양한 메모리 공간을 효과적으로 활용합니다.

• 주요 원리: 메모리 캐싱 및 쓰기 최적화
  • 데이터와 인덱스를 메모리에 캐싱하고(버퍼 풀), 쓰기 작업을 효율화하며(체인지 버퍼), 자주 접근하는 데이터에 대한 빠른 조회 경로를 자동으로 생성(어댑티브 해시 인덱스)하여 성능을 높입니다.
  • 상세 설명 및 실무적 의의:
    • InnoDB 버퍼 풀 (InnoDB Buffer Pool): InnoDB 아키텍처에서 가장 핵심적인 부분으로, 디스크의 데이터 파일이나 인덱스 정보를 메모리에 캐싱해두는 공간입니다. 디스크에서 직접 읽는 것보다 훨씬 빠르기 때문에, 버퍼 풀의 크기와 관리가 InnoDB 성능에 결정적인 영향을 미칩니다. DB 서버 전체 메모리의 50~80%를 버퍼 풀에 할당하는 것이 일반적인 권장 사항이며, 이는 튜닝의 제1순위입니다. LRU(Least Recently Used) 리스트를 통해 사용 빈도가 낮은 페이지를 밀어내고 새로운 페이지를 적재하는 방식으로 캐시를 관리합니다.
    • 체인지 버퍼 (Change Buffer): INSERT, UPDATE, DELETE 작업 시 유니크하지 않은 보조 인덱스(Secondary Index)에 대한 변경을 바로 디스크에 쓰지 않고 이 버퍼에 모아두었다가 나중에 한 번에 병합(Merge)합니다. 이는 랜덤 디스크 I/O를 줄여 DML(데이터 조작 언어) 성능을 크게 향상시키는 효과가 있습니다.
    • 어댑티브 해시 인덱스 (Adaptive Hash Index): InnoDB가 자주 사용되는 데이터에 대해 해시 인덱스를 자동으로 생성하여 B-Tree 인덱스를 거치지 않고 더 빠르게 데이터에 접근할 수 있도록 돕는 기능입니다. 특히 동등 조건(=) 검색 속도를 크게 높여주며, DBA나 개발자가 직접 제어하는 것이 아니라 InnoDB가 스스로 판단하여 생성하고 관리하는 자동 최적화 기능입니다.

4. 데이터 무결성 및 복구를 위한 메커니즘

InnoDB는 서버가 비정상적으로 종료되더라도 데이터 손실을 방지하고, 데이터베이스를 일관된 상태로 복구하기 위한 강력한 메커니즘들을 갖추고 있습니다.

• 주요 원리: 트랜잭션의 ACID 속성 보장
  • 트랜잭션의 원자성(Atomicity), 일관성(Consistency), 격리성(Isolation), 지속성(Durability)을 보장하기 위해 변경 사항을 기록하고, 데이터 손상을 방지하며, 비정상 종료 시에도 자동 복구될 수 있도록 설계되었습니다.
  • 상세 설명 및 실무적 의의:
    • 리두 로그 (Redo Log)와 로그 버퍼: 모든 데이터 변경 사항은 디스크의 데이터 파일에 적용되기 전에 리두 로그라는 별도의 로그 파일에 먼저 기록됩니다. 이를 Write-Ahead Logging(WAL)이라고 하며, 트랜잭션의 지속성(Durability)을 보장하는 핵심 원리입니다. 서버가 비정상 종료되더라도 InnoDB는 재시작 시 리두 로그를 참조하여 미처 디스크에 기록되지 못한 커밋된 변경 사항을 복구합니다. innodb_flush_log_at_trx_commit 파라미터는 성능과 안정성 간의 중요한 트레이드오프 지점입니다.
    • 언두 로그 (Undo Log): 트랜잭션이 롤백(ROLLBACK)될 때 데이터를 이전 상태로 되돌리는 데 사용되며, MVCC를 구현하는 데도 활용됩니다. 이는 트랜잭션의 원자성(Atomicity)과 격리성(Isolation)을 보장하는 핵심 메커니즘입니다. 장시간 실행되는 트랜잭션은 언두 로그를 계속 점유하여 성능에 영향을 줄 수 있으므로 주의해야 합니다.
    • 이중 쓰기 버퍼 (Double Write Buffer): InnoDB 버퍼 풀의 데이터 페이지를 실제 데이터 파일에 기록하기 전에, 중간 단계의 임시 공간에 먼저 기록하는 이중 쓰기 메커니즘입니다. 이는 데이터 페이지를 디스크에 쓰는 도중 서버가 비정상 종료되어 페이지 일부만 기록되는 '파셜 라이트(Partial Write)' 현상을 방지하여 언제나 깨끗한 원본 페이지를 보장하고 데이터의 무결성을 지켜줍니다.
    • 자동화된 장애 복구: 서버가 비정상적으로 종료되었다가 재시작될 때, InnoDB는 리두 로그를 사용하여 커밋된 트랜잭션의 변경 내용을 재적용하고, 커밋되지 않은 트랜잭션은 언두 로그를 이용하여 취소하여 데이터베이스를 일관된 상태로 자동 복구합니다.

III. 나가며

InnoDB 스토리지 엔진은 프라이머리 키 기반의 클러스터링 저장 구조를 바탕으로, MVCC를 통해 높은 동시성을 구현하고, 버퍼 풀, 체인지 버퍼, 어댑티브 해시 인덱스와 같은 메모리 구조로 성능을 최적화하며, 리두 로그, 언두 로그, 이중 쓰기 버퍼 등의 메커니즘을 통해 데이터의 안정성과 복구 능력을 보장하는 매우 정교하고 통합적인 아키텍처를 가지고 있습니다. 실무에서는 이러한 각 구성 요소의 역할과 원리를 깊이 이해하고, 시스템의 워크로드에 맞춰 관련 파라미터들을 적절히 튜닝하는 것이 중요하다

---

4.3 MyISAM 스토리지 엔진 아키텍처

MyISAM은 InnoDB와 함께 MySQL에서 사용되는 주요 스토리지 엔진 중 하나였지만, MySQL 5.5부터 InnoDB가 기본 스토리지 엔진으로 대체되었으며, MySQL 8.0에서는 MyISAM 스토리지 엔진이 더 이상 사용되지 않거나 사라질 것으로 예상됩니다. MyISAM은 InnoDB와 달리 트랜잭션을 지원하지 않으며 데이터 무결성 및 복구 기능이 제한적입니다.

• 주요 원리: 인덱스 캐싱과 단순한 파일 구조
  MyISAM은 인덱스 정보만을 메모리에 캐싱하고, 데이터 파일은 운영체제의 파일 시스템 캐시에 의존하며, 데이터와 인덱스 파일을 물리적으로 분리하여 저장합니다.
• 1. 키 캐시 (Key Cache)
  • 핵심 개념: InnoDB의 버퍼 풀(Buffer Pool)과 유사한 역할을 하지만, MyISAM의 키 캐시는 오직 인덱스 정보만을 메모리에 캐싱합니다. 데이터 페이지는 키 캐시에 포함되지 않습니다.
  • 실무적 의의 및 활용:
    • 인덱스 읽기 및 쓰기 작업 시 디스크 I/O를 줄여 성능을 향상시킵니다.
    • key_buffer_size 파라미터로 키 캐시의 크기를 설정하며, 여러 개의 키 캐시를 생성하여 특정 인덱스를 특정 캐시에 할당할 수도 있습니다.
    • 키 캐시 적중률(Hit rate)은 (100 - (Key_reads / Key_read_requests) * 100) 공식을 통해 모니터링할 수 있습니다.
  • 주의사항: 데이터는 캐싱되지 않으므로, 데이터 파일에 대한 접근은 여전히 디스크 I/O를 유발할 수 있습니다.
• 2. 운영체제의 캐시 및 버퍼 (OS Cache and Buffer)
  • 핵심 개념: MyISAM 스토리지 엔진은 데이터 파일에 대한 자체적인 캐싱 메커니즘을 가지고 있지 않습니다. 데이터 파일에 대한 읽기/쓰기 작업은 전적으로 운영체제의 파일 시스템 캐시와 버퍼링 기능에 의존합니다.
  • 실무적 의의 및 활용:
    • 운영체제 캐시의 효율성에 따라 MyISAM 테이블의 성능이 크게 달라질 수 있습니다.
    • 운영체제 메모리를 충분히 확보하는 것이 중요하며, InnoDB와 같은 전용 버퍼 풀이 없기 때문에 데이터 접근 시 디스크 I/O가 자주 발생할 수 있습니다.
• 3. 데이터 파일과 프라이머리 키(인덱스) 구조 (Data file and Primary Key (Index) structure)
  • 핵심 개념: InnoDB가 프라이머리 키(PK) 순서대로 데이터를 물리적으로 저장(클러스터링)하는 것과 달리, MyISAM 테이블의 데이터 파일(Heap)은 프라이머리 키와 무관하게 저장됩니다.
  • 인덱스 동작: MyISAM의 모든 인덱스(프라이머리 키 인덱스, 세컨더리 인덱스)는 데이터 레코드의 물리적 위치(ROWID)를 포인터로 가집니다.
  • ROWID: MAX_ROWS 옵션을 통해 테이블 생성 시 ROWID의 길이를 지정할 수 있으며, ROWID는 고정 길이 또는 가변 길이로 저장될 수 있습니다. myisam_data_pointer_size 시스템 변수를 통해 ROWID의 크기를 설정할 수 있습니다.

---

4.4 MySQL 로그 파일

MySQL 서버는 다양한 종류의 로그 파일을 통해 서버의 동작 상태, 발생한 문제, 실행된 쿼리 등을 기록합니다. 이 로그 파일들은 시스템 운영 및 문제 해결에 필수적인 정보를 제공합니다.

• 주요 원리: 서버 활동 기록을 통한 모니터링 및 복구 지원
  MySQL의 로그 파일들은 서버의 비정상 종료 시 복구를 돕고(에러 로그), 모든 쿼리를 기록하여 감사 및 디버깅을 지원하며(제너럴 쿼리 로그), 성능 문제를 일으키는 쿼리를 식별하는(슬로우 쿼리 로그) 등 다양한 목적으로 활용됩니다.
• 1. 에러 로그 파일 (Error Log File)
  • 역할: MySQL 서버의 시작 및 종료 정보, 서버 실행 중 발생한 모든 에러 메시지, 경고 메시지 등이 기록되는 파일입니다.
  • 실무적 의의 및 활용:
    • 서버 비정상 종료 시 재시작 과정에서 발생한 문제나 예기치 않은 서버 다운의 원인을 파악하는 데 가장 먼저 확인해야 할 로그 파일입니다.
    • log_error 파라미터를 통해 에러 로그 파일의 위치를 지정할 수 있습니다.
    • 클라이언트 연결 끊김(aborted connection)과 같은 문제에 대한 메시지도 기록되어, 애플리케이션 연결 문제 해결에도 도움을 줍니다.
• 2. 제너럴 쿼리 로그 파일 (General log)
  • 역할: MySQL 서버에서 실행되는 모든 클라이언트의 쿼리 요청과 처리 결과를 기록하는 파일입니다.
  • 실무적 의의 및 활용:
    • 특정 시간 동안 서버에서 어떤 쿼리들이 실행되었는지 전체적인 워크로드를 파악하거나, 애플리케이션에서 잘못된 쿼리가 발생하는지 등을 확인할 때 유용합니다.
  • 주의사항: 모든 쿼리를 기록하므로 파일 크기가 매우 빠르게 증가하며, 이로 인해 성능 오버헤드가 발생할 수 있습니다. 따라서 운영 환경에서는 특정 문제 분석 시에만 일시적으로 활성화하는 것이 일반적입니다.
  • general_log 파라미터로 활성화하고, log_output 파라미터로 로그를 파일로 저장할지, 또는 mysql.general_log 테이블에 저장할지 설정할 수 있습니다.
• 3. 슬로우 쿼리 로그 (Slow Query Log)
  • 역할: long_query_time 시스템 변수에 설정된 시간(기본값 1초)보다 오래 걸리는 쿼리들을 기록하는 파일입니다.
  • 실무적 의의 및 활용:
    • 데이터베이스 성능 저하를 일으키는 주범이 되는 느린 쿼리를 식별하고 최적화하는 데 매우 중요한 도구입니다.
    • 로그에는 쿼리 실행 시간, 잠금 대기 시간, 스캔한 레코드 수(Rows_examined) 등 상세한 정보가 포함되어 있어, 쿼리 분석 및 튜닝에 큰 도움을 줍니다.
    • log_output 파라미터로 로그를 파일 또는 mysql.slow_log 테이블에 저장할 수 있으며, pt-query-digest와 같은 외부 도구를 사용하여 슬로우 쿼리 로그를 효과적으로 분석할 수 있습니다.

이처럼 MyISAM은 단순한 구조로 특정 읽기 위주의 워크로드에 사용될 수 있지만 트랜잭션 안전성 부족으로 인해 현대적인 DBMS 환경에서는 InnoDB가 더 선호됩니다. 또한, MySQL의 다양한 로그 파일들은 서버 운영과 문제 해결에 있어 필수적인 정보를 제공하므로, 각 로그 파일의 역할을 이해하고 적절히 활용하는 것이 중요합니다.