[AWS Aurora PostgreSQL] 개념 공부

Aurora PostgreSQL 의 아키텍처는 기본적으로 Aurora의 아키텍처와 동일하게 구성되어있다.

1. 권한

• CREATE ROLE, ALTER ROLE, GRANT, REVOKE 등의 명령은 온프레미스 데이터베이스에서 작동하는 것과 마찬가지로 작동하며, 데이터베이스와 스키마, 테이블을 직접 수정할 때도 동일.
• rds_superuser은 RDS 구축시 생성하는 계정에만 부여 가능하다.
  rds_superuser는 다음과 같은 구문으로 생성된다.
  CREATE ROLE postgres WITH LOGIN NOSUPERUSER INHERIT CREATEDB CREATEROLE NOREPLICATION VALID UNTIL 'infinity'

PostgerSQL DB, 롤, 계정 추가

PUBLIC 스키마 제한
REVOKE CREATE ON SCHEMA public FROM PUBLIC;

DB 생성
CREATE DATABASE lab_db;

PUBLIC 스키마 권한 회수
REVOKE ALL ON DATABASE lab_db FROM public;

ROLE 생성.
CREATE ROLE minjae_role;

ROLE에 권한 추가 (커넥트)
GRANT CONNECT ON DATABASE minjae_db TO minjae_role;

ROLE에 권한 추가 (전체 권한)

GRANT ALL PRIVILEGES ON DATABASE minjae_db TO minjae_role;

사용자 생성 및 권한 추가
CREATE ROLE minjae_user LOGIN PASSWORD 'password1!';

ROLE에 계정 추가
GRANT minjae_role TO minjae_user;

 

2. 최적화된 읽기

최적화된 읽기의 문서에는 다음과 같이 기재되어있다.

Aurora 최적화된 읽기로 Aurora PostgreSQL의 쿼리 처리 속도를 높일 수 있습니다. Aurora 최적화된 읽기를 사용하는 Aurora PostgreSQL DB 인스턴스는 DB 인스턴스의 메모리 용량을 초과하는 대규모 데이터 세트를 보유한 애플리케이션에서 쿼리 지연 시간이 최대 8배 개선되고 비용이 최대 30% 절감됩니다.

 

최적화된 읽기가 활성화된 계층형 캐시 - 계층형 캐시를 사용하면 DB 인스턴스 캐싱 용량을 인스턴스 메모리의 최대 5배까지 확장할 수 있습니다. 이렇게 하면 트랜잭션 측면에서 가장 최근의 일관성 있는 데이터를 포함하도록 캐시가 자동으로 유지되므로 애플리케이션은 외부 결과 집합 기반 캐싱 솔루션의 데이터 흐름을 관리하는 오버헤드에서 벗어날 수 있습니다. 이전에 Aurora 스토리지에서 데이터를 가져오던 쿼리에 대해 최대 8배 더 개선된 지연 시간을 제공합니다.

Aurora에서 기본 파라미터 그룹의 shared_buffers 값은 일반적으로 사용 가능한 메모리의 약 75%로 설정됩니다. 하지만 r6gd 및 r6id 인스턴스 유형의 경우 Aurora는 최적화된 읽기 캐시에 대한 메타데이터를 호스팅하기 위해 shared_buffers 공간을 4.5% 줄입니다.

최적화된 읽기가 활성화된 임시 객체 - 임시 객체를 사용하면 PostgreSQL에서 생성된 임시 파일을 로컬 NVMe 스토리지에 배치하여 보다 빠르게 쿼리를 처리할 수 있습니다. 이렇게 하면 네트워크를 통해 Elastic Block Storage(EBS)로 전송되는 트래픽이 줄어듭니다. DB 인스턴스에서 사용할 수 있는 메모리 용량을 초과하는 대량의 데이터를 정렬, 조인 또는 병합하는 고급 쿼리에 대해 최대 2배 더 개선된 지연 시간과 처리량을 제공합니다.

Aurora I/O 최적화 클러스터에서 최적화된 읽기는 계층형 캐시와 NVMe 스토리지의 임시 객체를 모두 사용합니다. 최적화된 읽기가 활성화된 계층형 캐시 기능을 통해 Aurora는 인스턴스 메모리의 2배를 임시 객체에 할당하고, 스토리지의 약 10%는 내부 작업으로, 나머지 스토리지는 계층형 캐시로 할당합니다. Aurora Standard 클러스터에서 최적화된 읽기는 임시 객체만 사용합니다.

NVMe 스토리지를 사용하고 각 인스턴스별 로컬 스토리지를 사용하여 캐시 접근 속도를 빠르게하는 처리가 아닌가 싶다.

 

3. 디스크 확인

SELECT * FROM aurora_show_volume_status();

위 구문을 통해  DISK와 NODE 정보를 확인할 수 있다.

• Disks : DB 클러스터 볼륨에 대한 데이터의 총 논리 블록 수
• Nodes : DB 클러스터 볼륨의 총 스토리지 노드 수

 

Aurora PostgreSQL의 공유 메모리

shared_buffers 

Aurora PostgreSQL 캐시 영역. 공유 버퍼 풀은 디스크에서 읽은 데이터 블록을 캐시한다.

각 블록에는 행에 해당하는 여러 튜플이 포함되어 있고. 튜플은 모든 페이지에 저장할 수 있다.

메모리에서 클렌징하는 정책은 클럭 스윕 알고리즘에 의해 구현되었다.

WAL 버퍼

Aurora PostgreSQL은 WAL 메커니즘을 사용하여 장애 발생 후 데이터 복구 및 디스크에 빈번한 쓰기를 방지하여 디스크 I/O 감소시킨다.

클라이언트가 데이터를 변경하면 Aurora PostgreSQL이 변경 사항을 WAL 버퍼에 기록. 클라이언트가 COMMIT을 발행하면 WAL 라이터 프로세스는 트랜잭션 데이터를 WAL 파일에 쓴다.

 

Aurora PostgreSQL의 로컬 메모리

작업 메모리 영역

작업 메모리 영역은 정렬 및 해시를 수행하는 쿼리에 대한 임시 데이터를 보유.  

즉 ORDER BY, 해시 조인 및 집계에서 해시 테이블을 사용한다.

work_mem 파라미터는 임시 디스크 파일에 쓰기 전에 내부 정렬 작업 및 해시 테이블에서 사용할 메모리 양으로 기본값은 4MB.

유지 관리 작업 메모리 영역

유지 관리 작업 메모리 영역은 유지 관리 작업을 위해 데이터를 캐시합니다. 이러한 작업에는 베큠, 인덱스 생성 및 외래 키 추가가 포함된다.

maintenance_work_mem 파라미터는 유지 관리 작업에서 사용할 최대 메모리 양을 지정하고 기본값은 64MB. 

임시 버퍼 영역

임시 버퍼 영역에서는 각 데이터베이스 세션에 대한 임시 테이블을 캐시한다.

각 세션은 사용자가 지정한 한도까지 필요에 따라 임시 버퍼를 할당하고 세션이 끝나면 서버는 버퍼를 지운다.

 

백그라운드 프로세스

• WAL 라이터
  버퍼의 로그 데이터를 파일에 쓰는 역할.
• 백그라운드 라이터
  메모리 버퍼에서 데이터 파일로 더티 페이지를 주기적으로 데이터 파일로 동기화. 
• Autovacuum 데몬
  데몬은 다음 구성 요소로 이루어져 있다.
  • Autovacuum 시작 관리자
  • Autovacuum 작업자 프로세스
• Autovacuum은 삽입되고 업데이트되거나 삭제된 튜플 수가 많은 테이블이 있는지 확인하고 다음과 같은 작업을 한다.
  
  • 업데이트되거나 삭제된 행이 차지하는 디스크 공간 복구 또는 재사용
  • 플래너가 사용하는 통계 업데이트
  • 트랜잭션 ID 랩어라운드로 인해 이전 데이터 손실 방지
• Autovacuum 기능은 VACUUM과 ANALYZE 명령을 자동화한다.