PostgreSQL 에서 Vacuum 이 필요한 이유 (MVCC, XID)

 

 

🧹 PostgreSQL을 사용한다면 Vacuum에 대해 반드시 잘 이해하고 적절하게 관리해야 합니다.
얼마전 운영하고있던 서비스에 Vacuum 을 통한 관리가 제대로 되지 않았던 이유로 DB부하가 심하게 와서 장애가 발생한 적이 있습니다. 이번 포스팅에서는 신경쓰지 않으면 서비스에 치명적일 수 있는 Vacuum 의 역할에 대해 자세히 알아보려고 합니다.

 

 

---

 

 

Vacuum 의 첫 번째 역할, 공간확보!

Vacuum의 사전적 의미는 "진공청소기를 이용한 청소" 입니다. UPDATE 와 DELETE 를 통해 변경 또는 삭제된 자료들이 차지 하고 있는 디스크 공간을 다시 사용하기 위해 불필요한 쓰레기 데이터들을 정리하고, 디스크 공간의 효율성을 높입니다.

왜 불필요한 쓰레기 데이터가 공간을 차지하는걸까요?

 

 

다중 버전 동시성 제어

PostgreSQL에서는 UPDATE나 DELETE 작업 대상이 된 해당 자료의 옛 버전을 작업 완료 후 바로 버리지 않습니다. 이 작업은 다중 버전 동시성 제어(multiversion concurrency control, MVCC) 기법을 구현하는데 이점이 있기 때문입니다. 동시에 여러 개의 데이터 버전을 제공할 수 있는 기법으로 이해하시면 쉽습니다. 삭제된 자료를 다른 트랜잭션에서 사용하고 있다면, 그 자료가 삭제되면 안되기 때문에 여러 개의 버전으로 관리하는 것이죠.

 

하지만, 다른 트랜잭션이 더 이상이 그 옛 버전 자료에 대한 접근이 필요 없다면, 옛 버전 자료는 쓸모 없는 자료가 됩니다. 이 상태로 계속 운영 된다면, 디스크에는 쓸모 없는 자료들이 넘처나게 되는데, 이 사용해서는 안될 자료들을 정리해서 그 자료가 있었던 공간을 정리하는게 vacuum의 역할입니다. Vacuum이 공간을 정리하는 방법은 자세히 2가지로 나뉩니다.

 

 

Vacuum이 공간을 정리하는 두 가지 방법

1. 오래된 이전 버전 레코드 삭제 작업을 통한 공간 확보 - Vacuum

첫번째 작업은 쓸모없는 자료를 정리하고, 그 자리를 다른 자료가 저장될 수 있도록 빈공간으로 표시하는데요. 사실 이 작업은 운영체제 입장에서 디스크 여유 공간을 확보하는 것을 의미하지는 않고 채워질 수 있게 비워주는 것을 의미합니다. 

 

 

 

2. 오래된 이전 버전 레코드 삭제 작업 후에 공간 압축 - Vacuum Full

이와 반대로 Vacuum Full 작업은 해당 테이블의 사용할 수 있는 자료들만 따로 모아 아예 새 파일에 저장하는 방식입니다. 실제 디스크 여유 공간을 확보하고 해당 테이블을 최적의 물리적 크기로 만드는 작업이죠. 하지만 반드시 주의해야할 사항은 이들 명령은 테이블 대상으로 배타적 잠금을 한다는 점입니다. 표준 vacuum 작업과는 달리 DML과 락 호환성이 없고 심지어는 SELECT 를 수행하는 세션도 락을 대기해야합니다. 즉, 이 작업이 완료되기 전까지 그 테이블을 대상으로 하는 다른 모든 작업들을 다른 세션에서는 할 수 없게 됩니다. 추가로, 이들 작업은 작업 도중 원본과 다른 새로운 복사본 자료를 만들기 때문에 그만큼의 디스크 공간이 필요하다는 것도 기억해야합니다.

 

 

3. 권장되는 전략은? autovacuum!

일반적으로 권장되는 전략은 첫번째 표준 vacuum 을 주기적으로 작업을 해서 꾸준히 빈 공간을 확보해서, 두번째 작업인 full vacuum을 해야하는 상황을 방지하는 것입니다. 디스크가 어느 정도 커지지 않도록 계속해서 다른 자료가 저장될 수 있도록 자리를 확보해주는 것이죠. 이 전략을 위해 표준 vacuum을 자동으로 실행해주는 autovacuum 기능을 활용합니다. 물론 더이상 변경/삭제가 없을 테이블의 정리를 통해 디스크 공간을 확보하길 원한다면 full vacuum 작업을 선택하는 것도 방법입니다. 

만약 autovacuum 기능을 사용하지 않는다면, 해당 데이터베이스 서버에서 사용하고 있는 모든 데이터베이스에 대해서 관리자가 직접 VACUUM 작업을 해야합니다. 일반적으로 하루에 한 번 밤시간에 지정하는 것이 일반적이며, 자료가 빈번하게 변경되는 테이블에 대해서는 더 자주 vacuum 작업 하기도 합니다. (아주 빈번한 테이블에 대해서 몇 분에 한 번씩 작업 하도록 설정하기도 합니다.)

 

 

---

 

 

Vacuum 의 두 번째 역할, XID Frozen!

 사실 공간 재활용을 위한 Vacuum은 필수 사항은 아닙니다. 단지 디스크 사용 효율과 테이블 내의 공간 활용 효율이 떨어질 뿐이죠. 하지만 XID Frozen을 위한 vacuum 작업은 반드시 수행해야하는 작업입니다. autovacuum을 활용하지 않는다면 반드시 수동 vacuum을 해야하는 이유이기도 합니다.

 

 

XID 가 뭔데?

PostgreSQL에서는 트랜잭션 자료에 대해 MVCC 기법을 활용한다고 위에서 언급했습니다. MVCC는 쿼리가 수행한 시점의 데이터 버전을 읽을 수 있는 기능을 제공하는데, 이때 '수행한 시점'의 기준은 트랜잭션 ID (XID) 입니다. 테이블 내에 이전 데이터와 현재 데이터가 동시에 저장되기 때문에, 시점에 맞는 데이터를 추출하기 위해 레코드 별로 XID를 지정했다고 생각하면 됩니다. XID를 숫자로 처리하고 그것을 비교하는 방식을 활용하여 쿼리가 시작된 시점의 XID와 같거나 작은 데이터 버전을 읽는 것이 MVCC의 핵심이죠. Read와 Write 작업 간의 블로킹을 완벽히 제거함으로써 동시성을 높일 수 있기 때문입니다. 

 

사실 레코드 별로 XID가 존재한다는 것은 공간 사용 측면에서 매우 비효율적입니다. XID 를 저장하기 위해서는 레코드당 4바이트가 추가로 필요하기 때문입니다. 그래서 PostgreSQL은 FrozenXID 라는 특별 XID를 미리 예약 해 두어 사용합니다. 일반적인 비교 대상에서 항상 보여지는 XID, 즉 어떠한 XID보다 작은 Frozen XID를 적용하여 항상 visible 한 상태로 유지하는 것입니다.

 

 

Frozen XID ?

항상 보여지는 XID 라는 개념을 좀 더 자세히 알아보겠습니다. 일반적인 XID 비교 방법은 2의 32승 나머지 연산을 이용합니다. 이 말은 20억 개의 "옛" XID와, 20억 개의 "새" XID 로 나누고, 이 XID 값은 계속 순환 하며 사용한다는 뜻입니다. 그래서 한 XID로 저장 되었다면, 그 이후 20억 개의 트랜잭션이 생기기 전까지는 그 자료는 "옛" XID로 처리되지만, 그 이상의 트랜잭션이 생기면 그 옛 XID는 앞으로 저장될 XID로 간주해 버립니다. 이 문제를 피하는 방법은 20억 트랜잭션이 생기기 전에, 그 옛 XID 자료의 XID 값을 FrozenXID로 바꾸는 것입니다. 이렇게 영구 보관용 자료로 바꿔 놓으면, 트랜잭션 XID 비교 작업에서 항상 제외 되기 때문에, XID 겹침 오류를 피해갈 수 있게 되고, 이 XID 변경 작업을 바로 VACUUM (anti-wraparound autovacuum) 이 합니다.

 

---

 

 

Vacuum 의 세 번째 역할, 실자료 지도 갱신

vacuum 작업은 실자료 지도를 갱신하는 작업을 합니다. 실자료 지도(visibility map, vm)란 현재 작업 중인 트랜잭션들(또는 그 자료들이 변경 되기 전까지 이용할 미래의 모든 트랜잭션들)이 실제로 사용할 자료들에 대한 각 테이블별 지도입니다.

이 지도 정보는 인덱스 전용 쿼리들에 대해서 빠른 응답을 제공하는데 사용됩니다. PostgreSQL에서 어떤 자료를 해당 세션에게 보여 주어야 할지를 결정 하는 정보는, 그 자료의 테이블 페이지까지 살펴 보아야 알 수 있습니다. 하지만 인덱스 전용 검색인 경우에는 테이블 페이지를 검색하지 않고 먼저 이 실자료 지도를 검색해서 이곳에 해당 자료가 있다면 그것을 사용합니다. 그만큼 테이블 페이지 읽기 작업을 줄일 수 있고, 특히나 테이블 크기가 큰 경우라면 디스크 읽기 작업을 상당히 줄이는 효과를 볼 수 있습니다. 왜냐하면, 실제 테이블 페이지 보다, 이 실자료 지도의 크기는 훨씬 작기 때문이죠.

 

---

 

 

Vacuum 의 네 번째 역할, 실행계획 통계 정보 갱신

PostgreSQL 쿼리 실행 계획기는 쿼리의 좋은 실행 계획을 짜기 위해서 각 테이블에 저장된 자료를 바탕으로 수집된 통계 정보를 이용하는데, 이 통계 정보는 ANALYZE 명령을 이용해서 만들어집니다. 그리고 VACUUM 명령을 수행하면서 옵션으로 ANALYZE 작업을 할 수도 있습니다. 통계 정보 갱신 작업이 제대로 되지 않으면 의도 되지 않은 쿼리 실행 계획이 짜여지고, 전체적으로 데이터베이스 성능을 떨어뜨리는 결과를 초래하기 때문에 바른 통계 정보 갱신 작업을 주기적으로 하는 것은 매우 중요합니다.

 

위에서 설명한 autovacuum 기능을 이용한다면, 통계 정보를 갱신해야할 필요성이 있는 테이블들에 대해서 주기적으로 ANALYZE 명령을 자동으로 수행합니다. 통계 정보 갱신 작업도 디스크 여유 공간 확보를 위한 vacuum 작업과 마찬가지로 테이블의 자료 변화량이 많은 경우는 빈번하게 진행하는 것이 좋고, 그 반대인 경우는 좀 더 드물게 진행하는 것이 좋습니다. 물론, 테이블의 자료가 빈번하게 변경된다고 하더라도 그 변경 내용이 수집할 통계 정보와 관련 없는 것이라면 당연히 통계 정보 갱신 작업도 필요 없습니다.

 

 

 

---

 

이번 포스팅에서는 vacuum이 필요한 이유와 역할에 4가지에 대해 알아보았습니다.

이렇게 vacuum이 필수적인 관리가 필요하다면, 과연 어떻게 적절히 설정하고 활용해야 성능에 문제가 없을지도 알아봐야겠죠? 다음 포스팅에서 정리해보겠습니다. 👋🏻

 

 

 

 

- 참고자료

https://www.postgresql.eu/events/pgconfeu2019/sessions/session/2748/slides/242/vacuum_future_pgconf_eu_2019.pdf

https://www.interdb.jp/pg/pgsql06.html

https://bstar36.tistory.com/308

https://www.postgresql.kr/docs/9.4/routine-vacuuming.html

https://techblog.woowahan.com/9478/