hubtwork commented 4 months ago

Chapter Ownership @CHOICORE

CHOICORE commented 4 months ago

데이터 압축 (Data Compression)

데이터 파일의 크기는 일반적으로 쿼리의 처리 성능과도 직결되지만 백업 및 복구 시간과도 밀접하게 되어있다. 디스크의 데이터 파일이 크면 클수록 쿼리를 처리하기 위해서 더 많은 데이터 페이지를 InnoDB 버퍼 풀로 읽어야 할 수도 있고, 새로운 페이지가 버퍼 풀로 적재되기 때문에 그만큼 더티 페이지가 더 자주 디스크로 기록된다.

데이터 파일이 크면?

비용 증가
- 저장 공간 증가 (디스크 공간 차지)
성능 저하
- 쿼리 처리 성능 저하 (디스크 I/O 증가)
- 백업 및 복구 시간 증가

데이터 압축 방식

페이지 압축 (Transparent Page Compression) (OS, HW 지원의 제약으로 잘 사용되지 않는다.)

MySQL 서버가 디스크에 저장하는 시점에 데이터 페이지가 압축되어 저장되고, 디스크에서 읽어올 때 압축을 해제하여 읽는 방식이다. MySQL 서버의 내부 코드에서는 압축 여부와 관계 없이 "투명(Transparent)"하게 처리되기 때문에 사용자는 압축 여부를 신경 쓸 필요가 없다.

버퍼 풀에 데이터 페이지가 한번 적재되면 InnoDB Storage Engine은 압축이 해제된 상태로만 데이터 페이지를 관리한다.

문제점

데이터 페이지를 압축한 용량을 예측할 수 없다. 이를 위해 테이블은 동일한 크기의 페이지(블록)로 통일돼야 한다. 이를 해결하기 위해 페이지 압축 기능은 펀치 홀(Punch Hole) 기능을 사용한다.

페이지 압축 기능은 운영체제별로 특정 버전의 파일 시스템에서만 지원되는 펀치 홀(Punch hole)이라는 기능을 사용한다.

MySQL 서버는 특정 테이블에 대해 16KB 크기의 페이지를 유지하면서도 압축된 다양한 크기의 데이터 페이지를 디스크에 저장하고 압축된 만큼의 공간을 절약할 수 있다.

OS 별 펀치홀을 지원하는 파일 시스템

Linux: Ext4, XFS
Windows: NTFS
macOS: APFS

MySQL 페이지 압축은 펀치 홀 기능이 운영체제뿐만 아니라 하드웨어 자체에서도 해당 기능을 지원해야 사용 가능하다는 점과 아직 파일 시스템 관련 명령어(유틸리티)가 펀치 홀을 지원하지 못한다는 점으로 인해 많이 사용되지 않는 상태이다.

하드웨어 자체에서도 해당 기능을 지원해야 사용 가능하다는 점에서

SSD는 기본적으로 블록 단위로 데이터를 읽고 쓰기 때문에 해당 블록에 빈 공간을 재활용할 수 있게 하는 기능이 기본적으로 제공된다. 그래서 SSD를 쓰고 있다면 지원할 것 같다. (NAND 플래시 메모리의 특성, TRIM, UNMAP).
HDD는 데이터를 물리적인 디스크 플래터에 저장하고, 이 플래터를 회전시키면서 데이터를 읽고 쓰고, 삭제하는 방식은 실제로 데이터를 지우는 것이 아니라, 파일에 대한 주소를 없애고 해당 섹터에 데이터를 덮어쓰는 방식이라 지원하기 어렵지 않나 싶다.

페이지 압축을 이용하려면 테이블을 생성하거나 변경할 때 COMPRESSION 옵션을 사용하여 압축 방식을 지정할 수 있다.

-- 테이블 생성 시
CREATE TABLE t1 (c1 INT) COMPRESSION="zlib";

-- 테이블 변경 시
ALTER TABLE t1 COMPRESSION="zlib";
OPTIMIZE TABLE t1;

테이블 압축 (Table Compression)

테이블 압축은 운영체제나 하드웨어에 대한 제약 없이 사용할 수 있다.

일반적으로 페이지 압축보다 활용도가 높고, 디스크의 데이터 파일 크기를 줄일 수 있지만 다음과 같은 단점이 있다.

버퍼 풀 공간 활용률 저하
쿼리 처리 성능 저하
빈번한 데이터 변경 시 압축률 저하

압축을 사용하려는 테이블이 별도의 테이블 스페이스를 사용해야 한다.

SET GLOBAL innodb_file_per_table=ON;

CREATE TABLE t1 (c1 INT) ROW_FORMAT=COMPRESSED KEY_BLOCK_SIZE=8;

KEY_BLOCK_SIZE 옵션은 2n(n은 2 이상)으로만 설정할 수 있으며, 페이지 크기가 32KB 또는 64KB인 경우 테이블 압축을 적용할 수 없다. e.g. innodb_page_size = 16KB 이면 KEY_BLOCK_SIZE=8 or 4 만 가능하다.

innodb_page_size = 16KB, KEY_BLOCK_SIZE=8 인 경우

16KB 데이터 페이지를 압축 1.1 압축된 결과가 8KB 이하이면 그대로 디스크에 저장(압축 완료) 1.2 압축된 결과가 8KB 초과하면 원본 페이지를 스플릿해서 2개의 페이지에 8KB씩 저장
나뉜 페이지 각각에 대해 1번 과정을 반복

정말 DBA 형님들 존경한다. 이런 것들을 다 알아야 한다니...

일반적으로 8KB가 적당하다고 한다.

InnoDB Storage Engine은 압축된 테이블의 데이터 페이지를 버퍼 풀에 적재하면 압축된 상태(LRU LIST), 압축 해제 된 상태 (UNZIP_LRU_LIST)로 관리한다.

07. 데이터 암호화

7.1 MySQL 서버의 데이터 암호화

MySQL 서버(InnoDB Storage Engine)의 I/O 레이어에서만 데이터의 암호화 및 복호화 과정이 실행된다.

TDE(Transparent Data Encryption)는 데이터베이스의 암호화를 위한 기술로, 암호화 및 복호화 과정을 데이터베이스 사용자가 인지하지 못하도록 하는 것을 목표로 한다. 디스크에 저장된 단계에서만 암호화가 이루어지기 때문에, 데이터베이스 서버의 메모리나 네트워크 전송 과정에서는 신경 쓸 필요가 없다.

암호화 성능

버퍼풀에 캐시된 데이터는 암호화되지 않은 상태로 저장되므로, 버퍼풀에 캐시된 데이터를 읽을 때는 성능 저하가 발생하지 않는다.
암호화된 데이터를 읽을 때는 암호화된 데이터를 복호화하는 과정이 필요하므로, 암호화된 데이터를 읽을 때는 성능 저하가 발생한다.

테이블 암호화

CREATE TABLE t1 (a INT, b CHAR(20)) ENCRYPTION='Y';

응용 프로그램에서 암호화한 경우 암호화된 값을 기준으로 정렬된 인덱스를 생성했기 때문에 암호화 되기 이전의 값을 기준으로 정렬된 인덱스를 사용할 수 없다.

언두, 리두 로그 암호화

디스크로 저장된 데이터만 암호화되서 저장되므로 메모리에 존재하는 데이터는 평문으로 존재한다. 8.0.16 부터는 언두, 리두 로그도 암호화가 가능하게 변경되었다.

SHOW GLOBAL VARIABLES LIKE 'innodb_redo_log_encrypt';
SET GLOBAL innodb_redo_log_encrypt = ON;

바이너리 로그 암호화

기본적으로 네트워크 구간의 암호화를 하지 않는다, 네트워크 구간의 암호화를 위해서는 SSL을 사용해야 한다.

mysqlbinlog 암호화된 바이너리 로그 읽기

트랜잭션의 내용을 추적하거나 백업 복구를 위해 암호화된 바이너리 로그를 평문으로 복호화 할 일이 있을 때 사용한다.

zinokim commented 4 months ago

Chapter 06~07. 데이터 압축 및 데이터 암호화

후기

데이터 압축 챕터에서는 이전 챕터에 비해 Low Level Technology 챕터라는 생각이 들었다. Application Engineer로서 알고 있으면 당연히 유익한 내용이지만, 과연 데이터 압축 관련 업무를 해야할 일이 있을지 애매하기도 했고 판단이 어려웠다. 전문적인 DevOps나 DBA Engineer라면 어떤 데이터 압축 업무를 하게 될지 약간 궁금했다.

데이터 암호화 챕터는 Application Engineer로서 데이터 암호화 관련 업무를 할 수도 있을 것 같다는 생각을 했지만, 굳이 Database의 데이터 암호화를 사용하는 것보다는 Application 레벨의 암호화 방식을 선호하지 않을까 추측해본다. 데이터 암호화 챕터를 읽으며 언두 로그, 리두 로그, 바이너리 로그 등이 지속적으로 언급되는 것으로 보아 언두 로그, 리두 로그, 바이너리 로그의 개념이 MySQL에서 상당히 중요하다고 여겨진다.

언두 로그, 리두 로그, 바이너리 로그... 결국 또두 로그, 또이너리 로그...

그 밖에 생각해보고 싶은 점

데이터를 암호화하여 저장한다는 것은 주민등록번호, 개인 계좌정보와 같은 민감정보들을 암호화한다는 것인데, 암호화된 정보를 어떻게 활용하는지 구체적 사례들을 고민해보고 싶다. 예를 들어 주민등록번호 또는 생년월일을 활용해서 연령별, 성별 통계 등의 데이터로써 활용할 때 어떤 아키텍처를 설계하고 이를 구현해 나갈 것인지 고민해보고 싶다.

사실 주민등록번호, 생년월일 말고는 구체적 사례가 떠오르지 않아...

암호화를 Database에 위임하는 것보다 Application에 위임하는 것이 비용 측면에서 이점이 있지 않을까 생각해봤는데, 실제 Database 서버에서의 암호화 또한 구체적 활용은 쉽지 않을 것 같다.

hubtwork commented 3 months ago

후기 데이터 압축, 암호화 Chapter 는 공부라기보다 영감을 주는 챕터였다. MySQL 이 데이터 페이지를 관리할 수 있도록 압축/해제 해서 디스크에 저장, 삭제 하는 방식이라던가 하는 부분들을 통해 요즘 캐시에 적재하고 있는 대량의 데이터나 DB 테이블에 적재하고 있는 raw data 를 적절하게 Column 을 여러개로 쪼개서 압축 인코딩된 스트링을 적재한다던지.. 뭐 이런 아이디에이션이 다양하게 될 수 있도록 도와주었다. 암호화에서는 예전에 MySQL 터지거나 누군가 잘못 건드려서 데이터 날아갔을 때 스냅샷 + 바이너리 로그 기반으로 트랜잭션 수행을 되살려 정합성까지 맞추며 살려낸다던지 하는 작업하는 걸 구경했던 적이 있는데 mysqlbinlog 와 같은 도구들은 암호화를 적용하면서 해당하는 바이너리 로그의 관리 주체 서버만 다시 살려낼 수 있다는 점을 보고 의문은 좀 든다.

A : 아, DB 서버 설정 잘못 건들다가 죽었어요. ( 못 살리는 상태 )
B : 그거 바이너리 로그 mysqlbinlog 로 읽어보려 하는데 이쪽 새로 띄운 호스트에서는 안 읽히는데요 ?

이 상황에서 config 다 들고 가서 같은 서버인 척 하면... 되살릴 수 있으려나 ?

KangHun-Lee commented 3 months ago

후기

아키텍처 챕터와 같은 느낌(실제로 뭔가 적용하기 보다는 이런게 있구나. 이런 걸 어떻게 활용해볼 수 있을까 하는 정도) 데이터 압축은 한번도 써본 적은 없지만 데이터 암호화는 1번 써본 적이 있다. 첫 직장에서 솔루션을 만들 때 이력서 관련 정보들을 암호화해서 썼던 기억이 있는데, 잘 기억은 나지 않는다...

데이터 압축은 3가지 단점이 너무 크다고 생각해, 어떻게 쓸 생각도 못하겠다.. DBA 는 과연 사용할까.. 알아볼 필요는 있을 거 같다
책 내용에서도 언급되어 있지만 마스터 키 자체를 외부 파일을 이용하다보니 보안에 취약하다

이번 챕터는 그냥 정말 이런게 있구나 하고 읽었던 거 같다.. 궁금증이 생기지도 않았다...

hlab-books / real-mysql-8.0-1

Chapter 6 & 7. 데이터 압축 & 암호화 #4