디스크의 데이터 파일이 크면 클 수록 쿼리를 처리하기 위해서 더 많은 데이터 페이지를 InnoDB 버퍼풀로 읽어야 하거나, 새로운 페이지가 버퍼 풀로 적재되기 때문에 그만큼 더티 페이지가 더 자주 디스크로 기록돼야 한다.
페이지 압축 VS 테이블 압축
페이지 압축 : 서버가 디스크에 저장하는 시점에 데이터 페이지가 압축되어 저장되고, 디스크에서 데이터 페이지를 읽어 올때 압축이 해제된다.
즉 버퍼 풀에 데이터 페이지가 한 번 적재되면 InnoDB 스토리지 엔진은 압축이 해제된 상태로만 데이터 페이지를 관리한다.
문제점 은 압축한 결과가 얼마나 될지 예측 불가능하고, 하나의 테이블은 동일한 크기의 페이지로 통일되어야 한다.
펀치 홀 : 페이지 압축 기능은 운영체제별로 특정 버전의 파일 시스템에서만 지원된다. (압축된 데이터의 빈 공간)
펀치홀이 생성되면 압축 데이터 공간 + 펀치홀 공간이 합쳐서 읽힌다.
데이터 파일을 해당 서버에만 머무는 것이 아니라 백업했다가 복구하는 과정에서 데이터 파일 복사 과정이 실행된다. 실제 데이터 크기가 1GB 이라고 해도 CP같은 파일 복사 명령 같은 툴이 파일을 복사하면 펀치홀이 다시 채워져 10GB가 될수 있어,
페이지 압축은 많이 사용되지 않는다.
테이블 압축 : 데이터베이스에서 저장된 테이블의 크기를 줄이기 위해 데이터를 효율적으로 저장하는 방법을 말한다.
하지만 단점이 있다.
1. 버퍼 풀 공간 활용률이 낮음
2. 쿼리 처리 성능이 낮음
3. 빈번한 데이터 변경시 압축률이 떨어짐
테이블 압축을 사용하기 위해서는 별도의 테이블 스페이스를 사용해야한다.
InnoDB엔진은 압축된 테이블에 대해서는 버퍼 풀의 공간을 이중으로 사용함으로써 메모리를 낭비하는 효과를 가진다.
, 압축된 페이지에서 데이터를 읽거나 변경하기 위해서 압축을 해제해야하는데 이때 CPU를 상대적으로 많이 소모한다.
해결방안 : Unzip_LRU 리스트를 별도로 관리하고 있다가 MySQL서버로 유입되는 요청 패턴에 따라서 처리한다.
Unzip_LRU 이란 ?
Unzip_LRU는 데이터베이스 시스템에서 자주 사용되는 압축 데이터의 비압축 버전을 메모리에 캐싱하여 성능을 최적화하는 기술이다
이 기술은 특히 데이터가 압축된 상태로 저장되지만, 자주 읽히거나 사용되는 데이터를 비압축 상태로 빠르게 접근할 수 있도록 하는 데 유용하다
주요 개념
- LRU (Least Recently Used): LRU는 캐시 관리 알고리즘 중 하나로, 가장 최근에 사용된 데이터는 캐시에 남겨두고, 오래된 데이터는 캐시에서 제거하는 방식. 이를 통해 자주 사용되는 데이터가 캐시에 남아있어 빠르게 접근할 수 있게 된다.
- Unzip (비압축): 압축된 데이터를 비압축 상태로 변환하는과정. 비압축된 데이터는 크기가 크지만, 접근 속도가 더 빠르다.
MySQL InnoDB의 Unzip_LRU:
- 읽기 집중 워크로드: 특정 데이터가 자주 읽히는 상황에서 압축된 데이터를 비압축 상태로 캐싱하여 빠른 읽기 성능을 제공.
- 메모리 제한 환경: 메모리가 제한된 환경에서 자주 사용되는 데이터의 비압축 버전만을 메모리에 유지함으로써 메모리 사용을 최적화한다.
1. 버퍼풀의 공간이 필요한 경우
- LRU리스트 에서 원본 데이터 페이지는 유지하고 Unzip_LRU 리스트에서에서 압축 해제된 버전은 제거해 버퍼 풀의 공간을 확보한다.
2. 압축된 페이지가 자주 사용되는 경우
- Unzip_LRU 리스트에 압축 해제된 페이지를 계속 유지하면서 압축 및 압축 해제 작업을 최소화 한다.
3. 압축된 데이터 페이지가 사용되지 않아서 LRU 리스트에서 제거되는 경우
- Unzip_LRU 리스트에서도 함께 제거된다.
LRU알고리즘 : 가장 오랫동안 참조되지 않은 페이지를 교체하는 기법
데이터 암호화
MySQL 8.0 버전 부터 데이터 파일 뿐만 아니라 리두로그, 언두로그, 바이너리 로그 등 암호화 기능을 지원한다.
서버의 암호화 기능은 DB서버와 디스크 사이의 데이터를 읽고 쓰는 지점에 암호화 , 복호화를 수행한다.
테이블이 암호화가 되어있든 말든 MySQ 는 동일한 처리과정을 거친다.
투명하게 데이터를 암호화(TDE) 한다는 것으로, 응용 프로그램의 수정 없이 DB 내부에서 컬럼, 테이블 스페이스 레벨의 암호화를 진행하는 것으로 해석할 있다.
이러한 암호화 방식을 TDE 방식이라고 한다
TDE 작동방식
- 마스터 키 생성: 데이터베이스 서버에서 마스터 키를 생성하고 이를 안전하게 저장. 마스터 키는 보통 운영 체제의 보안 기능을 사용하여 보호.
- 데이터베이스 암호화 키 생성: 암호화할 데이터베이스에서 DEK를 생성하고, 이를 마스터 키로 암호화한다. DEK는 데이터베이스 파일을 암호화하는 데 사용된다/.
- 데이터베이스 파일 암호화: TDE를 활성화하면 데이터베이스 엔진이 데이터베이스 파일과 백업 파일을 자동으로 암호화한다. 이 과정은 투명하게 진행되며, 사용자는 특별한 조치를 취할 필요가 없다.
- 데이터 접근 시 자동 복호화: 데이터베이스 엔진이 데이터를 읽을 때 DEK를 사용하여 데이터를 자동으로 복호화한다. 사용자는 암호화
- 여부를 인지하지 못한 채 평소와 동일하게 데이터를 사용할 수 있다.
장점
- 데이터 보안 강화
- 사용자 작업에 영향을 주지 않으면서 데이터 보호
- 데이터 일관성
TDE 암호화 키 는 키링 플러그인에 의해 관리된다.
키링 플러그인 이란
시스템에서 암호화 키를 안전하게 저장하고 관리하기 위해 사용되는 플러그인이다. 키링 플러그인은 데이터베이스 자체 내에 암호화 키를 저장하지 않고, 외부 저장소나 안전한 키 관리 시스템에 키를 저장하여 보안성을 높인다.
키링 플러그인 이란 2단계 키 관리 방식을 사용하한다.
위 그림과 같이 MySQL 서버는 Vault 같은 외부 키 관리 솔루션(KMS) 또는 디스크의 파일에서 마스터 키를 가져오고, 암호화된 테이블이 생성될 때마다 해당 테이블을 위한 임의의 테이블스페이스 키를 발급한다. 그리고 MySQL 서버는 마스터 키를 이용해 테이블스페이스 키를 암호화해서 각 테이블의 데이터 파일 헤더에 저장한다. 만약 마스터 키를 변경하면, 기존의 마스터 키를 이용해 각 테이블의 테이블스페이스 키를 복호화한 다음 새로운 마스터 키로 다시 암호화 한다.
SQL 서버의 데이터는 마스터 키와 테이블스페이스키(Private key)를 가지고 있다.
마스터 키가 변경되는 동안 MySQL 테이블스페이스 키 자체와 데이터 파일의 데이터는 젼혀 변경되지 않는다.
마스터 키는 레플리카 로 복제되지 않는다.
소스 서버와 레플리카 서버는 서로 각자의 마스터 키와 테이블스페이스 키를 관리한다. -> 데이터 파일이 암호화 되기전 같은 값이라도 암호화가 되면 내용이 완전히 달라진다.
CREATE TABLE x (
id INT,
data VARCHAR(100),
PRIMARY KEY(id)
) ENCRYPTION='Y';
ENCRYPTION = "Y" 를 붙여주면 TDE를 이용하게 된다.
테이블의 데이터가 디스크에 기록될 때는 데이터가 자동으로 암호화되어 저장되고, 다시 디스크에서 메모리로 읽어올 때 복호화된다.
왜 이렇게 사용해 ?
이렇게 사용하는 이유는 암호화 키 변경으로 인한 과도한 시스템 부하를 피하기 위함이다. 테이블스페이스 키가 변경되면, 모든데이터를 복호화 했다가 다시 암호화 하기 때문에 엄청난 작업이 필요하며, 사용자 쿼리를 처리하는데 상당한 영향을 미친다.
테이블 스페이스키는 AES-256ECB 알고리즘을 이용해 암호화되고
실제 데이터 파일은 AES-256CBC 알고리즘으로 암호화 된다.
ECB : 블록단위로 순차적인 암호화, 한 개에 블록이 해독되면 나머지 블록도 해독되는 단점이 있다.
동작방식 :
-
- ECB 모드에서 메시지는 고정 크기의 블록(128비트)으로 나뉘며, 각 블록은 동일한 키를 사용하여 개별적으로 암호화됩니다.
- AES-256은 256비트 키를 사용하여 각 블록을 암호화합니다.
CBC : 블록 암호화 운영 모드 중 보안 성이 제일 높은 암호화 방법으로 가장 많이 사용된다. 병렬처리가 아닌 순차적 수행되어야한다.
동작방식
- CBC 모드에서 각 평문 블록은 암호화되기 전에 이전 암호문 블록과 XOR 연산을 수행합니다.
- 첫 번째 블록을 처리할 때는 초기화 벡터(IV)가 사용됩니다.
- 각 블록은 IV 또는 이전 암호문 블록과 XOR 연산 후 암호화됩니다.
디스크로부터 한 번 읽은 데이터 페이지는 복호화되어 InnoDB 의 버퍼풀에 적재된다.
버퍼풀 : InnoDB가 액세스 할 때 테이블 및 인덱스 데이터를 캐시하는 메인 메모리 영역이다
즉 한 번 적재되면 암호화되지 않은 테이블과 동일한 성능을 보인다. 하지만, 동기화 할때 다시 저장하기 때문에 추가로 시간이 걸린다.
암호화를 한다고 해서 InnoDB 버펄풀의 효율이 달라지거나 메모리 사용 효율이 떨어지지는 않는다.
압축 vs 암호화
암호화 된 결과문은 랜덤한 바이트의 배열을 가져 압축률을 떨어뜨린다.
-> 압축을 한 후에 암호화를 적용한다.
테이블스페이스를 사용한 데이터 백업
테이블을 다른 서버로 복사해야 하는 경우, 특정 테이블의 데이터 파일만 백업했다가 복구하는 경우 테이블 스페이스의 이동 기능 을 사용해 레코드를 덤프했다가 복구하는 방식보다 훨씬 효율적이다.
mysql> flush table source_table for export;
암호화 되지 않은 테이블의 Table Space 복사 과정
- source_table 의 저장되지 않은 변경 사항을 모두 디스크로 기록한다.
- 더 이상 source_table 에 접근할 수 없게 잠금을 건다.
- 동시에 source_table 의 구조를 cfg 파일로 기록해 둔다.
- 복사가 완료되면 unlock table 명령을 실행해. source_table 을 사용할 수 있게 한다.
TDE 로 암호화된 테이블은 복사과정
- 위에 명령을 실행하면 임시 사용할 마스터 키를 발급해서 .cfp 파일로 기록한다
- 테이블 스페이스 키 기존 마스터 키로 복호화후, 다시 암호화 해서 데이터 파일의 헤더 부분에 저장한다.
- * 암호화 된 테이블의 경우 테이블 이동시, 데이터 파일과 임시 마스터 키가 저장된 *.cfp 파일을 함께 복사해야한다.
임시 마스터 키가 저장된 *.cfp 를 함께 복사해야하는 이유
.cfg 파일은 파일이 없어지면 경고만 발생하고 테이블스페이스 복구가 가능하다.
.cfp 파일은 없어지면 복구가 불가능하다.
댓글