애플리케이션

"포스트그레SQL에 날개 달기" EDB 15 버전의 핵심 기능 3가지

Adam Wright | InfoWorld 2022.12.02
엔터프라이즈DB(EDB)는 인기 있는 오픈소스 데이터베이스인 포스트그레SQL을 완벽하게 활용할 수 있게 해주는 엔터프라이즈급 소프트웨어와 서비스를 제공한다. MERGE SQL 명령을 비롯해 최근 포스트그레SQL 15 릴리스에서 EDB가 기여하는 모습을 보면 이 업체가 커뮤니티와 포스트그레SQL의 혁신에 지속해서 관심을 기울이고 있음을 알 수 있다.
 
ⓒ Getty Images Bank

EDB가 새로 출시한 포스트그레SQL 15.1용 EDB 툴 및 확장 릴리스(EDB PG 15)는 포스트그레SQL을 표준 엔터프라이즈 데이터베이스로 손쉽게 배포할 수 있게 해준다. 많은 수의 새로운 확장과 툴이 포함된 이번 릴리스는 기업에서 최신 버전의 포스트 그래 SQL을 사용해 새롭고 현대적인 애플리케이션을 구축하는 데 도움이 된다.

EDB PG 15에서 EDB는 온프레미스 또는 클라우드, 자체 관리 또는 EDB 빅애니멀(BigAnimal)을 사용한 완전 관리형 등 배포 형태와 관계없이 포스트그레SQL 15.1을 지원한다. 또한 EDB PG 15 릴리스는 인프라 현대화를 위한 속도와 효율성, 보호를 위해 클라우드네이티브PG(CloudNativePG)를 활용하는 쿠버네티스용 EDB 포스트그레SQL도 지원한다.

오픈소스 포스트그레SQL 데이터베이스를 한층 더 확장하는 EDB PG 15의 주요 기능은 크게 3가지다. EDB 어드밴스드 스토리지 팩(EDB Advanced Storage Pack), EDB 포스트그레스 튜너(EDB Postgres Tuner), EDB LDAP 싱크(EDB LDAP Sync)다. 각 기능에 대해 살펴보자.
 

EDB 어드밴스드 스토리지 팩

레퍼런스 데이터 스토리지 최적화(Reference Data Storage Optimization)와 오토 클러스터링 스토리지 최적화(Auto Clustering Storage Optimization)로 구성된 EDB 어드밴스드 스토리지 팩은 클러스터링된 데이터에 대한 더 빠른 액세스 속도와 외래 키 관계에 대한 성능 및 확장성 향상 효과를 제공한다.

EDB는 일단 두 가지 플랫폼 중립적인 스토리지 엔진, 또는 포스트그레SQL 용어로 테이블 액세스 방법(TAM)을 지원한다. 두 스토리지 엔진은 데이터가 다양한 사용 사례에 따라 디스크에 저장되고 액세스되는 방식을 최적화하도록 설계됐다. 특수한 하드웨어가 필요 없고 자체 서버나 퍼블릭 클라우드에서 모두 작동한다. TAM은 데이터베이스의 확장 형태로 제공되며 EDB 사용자는 커뮤니티 포스트그레SQL과 EDB 포스트그레스 어드밴스드 서버(EDB Postgres Advanced Server)에서 모두 TAM을 활용할 수 있다.

먼저 릴리스되는 두 TAM은 EDB 오토 클러스터(EDB Auto Cluster)와 EDB 레프 데이터(EDB Ref Data)로, 각각 클러스터링된 데이터에 대한 액세스 속도를 높이고 외래 키 관계를 최적화한다. EDB는 IoT, 감사, 데이터 로깅, 이벤트 및 프로세스 데이터 워크로드를 위한 수집과 저장을 최적화하는 TAM을 추가로 개발 중이다. 앞으로 나올 확장도 EDB 오토 클러스터 및 EDB 레프 데이터와 마찬가지로 특수한 하드웨어나 특정 클라우드 제공업체가 필요 없다.

EDB 오토 클러스터 TAM은 사이드 테이블의 모든 값에서 마지막으로 삽입된 행을 추적한다. 따라서 새 행이 이전 행과 동일한 데이터 블록에 추가되어 데이터 클러스터가 유지되고 관련 데이터에 대한 액세스 시간이 줄어든다.

예를 들어 애플리케이션의 액세스 패턴이 ‘주어진 주식 종목명에 대한 모든 거래 불러오기’인 Trades라는 테이블이 있다고 가정하자. 오토 클러스터 TAM을 사용해 삽입 작업에서 주어진 주식 종목명의 행을 데이터베이스의 같은 위치에 저장할 수 있다. 이렇게 하면 모든 거래를 불러오기 위해 액세스해야 하는 페이지의 수가 줄어들고 결과적으로 데이터베이스 페이지 캐시의 사용 효율성이 높아지고 데이터베이스에서 애플리케이션으로 더 빠르게 결과를 전달할 수 있다.

다음은 EDB 내의 독립적인 성능 엔지니어링 팀이 제시한 오토 클러스터 TAM을 사용하는 경우와 그렇지 않은 경우의 쿼리 실행 계획이다(실행 전 시스템 캐시 비움).

오토 클러스터 사용
 

Limit  (cost=27058.18..27058.43 rows=100 width=49) (actual time=67.934..67.952 rows=100 loops=1)
   Buffers: shared hit=6 read=77
   ->  Sort  (cost=27058.18..27115.67 rows=22996 width=49) (actual time=67.932..67.942 rows=100 loops=1)
         Sort Key: size DESC
         Sort Method: top-N heapsort  Memory: 48kB
         Buffers: shared hit=6 read=77
         ->  Index Scan using i_file_user on file  (cost=0.57..26179.28 rows=22996 width=49) (actual time=3.384..67.095 rows=5884 loops=1)
               Index Cond: ("user" = 667)
               Buffers: shared hit=3 read=77
 Planning:
   Buffers: shared hit=103 read=19
 Planning Time: 10.887 ms
 Execution Time: 68.836 ms

 

오토 클러스터 미사용
 

Limit  (cost=7216.82..7217.07 rows=100 width=49) (actual time=3071.083..3071.104 rows=100 loops=1)
   Buffers: shared hit=7 read=6059
   ->  Sort  (cost=7216.82..7232.15 rows=6134 width=49) (actual time=3071.081..3071.094 rows=100 loops=1)
         Sort Key: size DESC
         Sort Method: top-N heapsort  Memory: 49kB
         Buffers: shared hit=7 read=6059
         ->  Index Scan using i_file_user on file  (cost=0.57..6982.38 rows=6134 width=49) (actual time=3.800..3068.449 rows=5988 loops=1)
               Index Cond: ("user" = 667)
               Buffers: shared hit=4 read=6059
 Planning:
   Buffers: shared hit=110 read=17
 Planning Time: 8.473 ms
 Execution Time: 3071.149 ms

 

두 실행 계획은 동일하다. 인덱스 스캔에서 반환하는 행 수의 차이는 미미하지만(~1.74%) 버퍼 읽기의 경우 77 대 6059로 큰 차이가 난다. 오토 클러스터 사용 시 실행 시간은 97.7% 줄어든다. 다음은 EDB 레프 데이터의 실제 동작 예제다.
 

CREATE TABLE department (
            department_id SERIAL PRIMARY KEY,
            department_name       TEXT
) USING refdata;
CREATE TABLE employee (
            ...
            department_id NOT NULL REFERENCES department(department_id)
);

 

employee 테이블은 표준 힙 테이블이며, department 테이블에서만 레프 데이터 TAM을 사용한다. employee 테이블의 삽입과 업데이트는 department 테이블의 행 수준 잠금을 해제하지 않으므로 쿼리 시간이 절약되고 department 테이블의 행을 업데이트할 필요가 없고 참조된 department 테이블 행을 디스크와 쓰기 전(write-ahead) 로그에 쓸 필요가 없다.
 

EDB 포스트그레스 튜너

EDB 포스트그레스 튜너는 자동화된 권장 사항을 위한 15년 이상의 EDB 포스트그레SQL 튜닝 전문 기술을 활용해 성능을 높인다. EDB는 미션 크리티컬 환경에서 포스트그레SQL을 실행하는 고객을 15년 이상 지원해왔다. EDB의 성능 엔지니어링 팀은 다양한 실제 환경의 성능 테스트를 실행하며 그 결과는 EDB 지원 부서가 사용자에게 제공하는 권장 사항, 핵심 데이터베이스 서버 향상을 위한 아이디어, 그리고 공유 버퍼 활용 및 성능 혜택 얻기와 같은 성능 심층 분석에 반영된다.

EDB는 EDB 포스트그레스 튜너를 통해 이러한 경험과 지원, 성능 연구의 대부분을 EDB 고객에게 확장 형태로 제공한다. 포스트그레SQL에는 350여 가지의 구성 매개변수가 있으며 대부분은 조정할 필요가 거의 없지만 일부는 데이터베이스의 성능, 그리고 몇 년 동안의 데이터 변경 후에도 최적으로 데이터베이스를 실행하는 역량에 직접적으로 영향을 미친다. 이 확장은 포스트그레SQL 튜닝을 위한 DBA의 오버헤드를 대폭 줄여준다.

EDB는 시스템 하드웨어가 변경된 경우에만 바뀌는 정적 매개변수, 데이터베이스의 활동에 따라 달라지는 동적 구성 매개변수와 같이 서로 다른 클래스의 구성 매개변수를 EDB에서 개발한 알고리즘을 사용해 분리했다.

EDB 포스트그레스 튜너를 사용하면 자동으로 튜닝 권장 사항을 적용하거나 튜닝 권장 사항을 보고 선별적으로 적용할 수 있다. 워크로드가 변경되고 사용량이 많은 시스템에서 시간 경과에 따라 더 나은 제안을 얻을 수 있다. 예를 들어 checkpoint_completion_target과 같은 포스트그레SQL 매개변수는 일관적인 I/O를 보장하기 위해 항상 동일한 권장 사항이 제시된다. 반면 max_wal_size와 같은 매개변수는 디스크 공간을 소진하지 않으면서 체크포인트 시간을 유지하도록 균형을 맞춘다. 이 두 요소를 위해서는 EDB의 max_wal_size 튜닝 문서에서 자세히 설명된 대로 데이터베이스 서버의 최신 상태를 알아야 한다.

이 튜닝 문서에 따르면, max_wal_size는 성능에 큰 영향을 미칠 수 있다. 이제 EDB 포스트그레스 튜너를 사용하면 max_wal_size와 같이 성능에 영향을 미치는 세부 사항에 대해 알 필요 없이 포스트그레SQL을 대상으로 쓰기 작업이 많은 워크로드를 실행할 수 있다.
 

EDB LDAP 싱크

EDB LDAP 싱크는 데이터베이스와 LDAP, 두 곳에서 사용자를 관리해야 할 필요성을 없애 기업의 LDAP 지원을 간소화한다. EDB는 LDAP 또는 액티브 디렉터리 자격 증명으로 데이터베이스 사용자를 인증하는 많은 사용자와 협력한다. LDAP에 대해 포스트그레SQL 인증을 수행하려면 포스트그레SQL 데이터베이스에 수동으로 사용자를 추가해야 한다. 즉, 단일 소스를 대상으로 인증을 수행하지만 여전히 포스트그레SQL과 LDAP, 두 곳에서 모두 사용자를 관리해야 한다.

EDB LDAP 싱크는 여러 툴의 모음으로, 데이터베이스에서 작업을 예약하고 오픈소스 ldap2pg 툴을 호출해 LDAP 검색 결과에 따라 LDAP에서 역할 또는 사용자를 생성하는 방법으로 포스트그레SQL 데이터베이스에서 사용자를 관리해야 하는 부담을 없애 준다. 또한 사용자가 조직에서 떠난 경우 이 기능이 다음 예약된 실행 시 LDAP(기업에서 직원 확인을 위한 소스로 흔히 사용됨)에 해당 계정이 더 이상 존재하지 않으면 데이터베이스에서 사용자를 삭제하므로 신속한 대응이 가능하다.
 

EDB의 향후 계획

EDB PG 15 이후 EDB의 다음 주 릴리스는 2023년 초로 예정된 EDB 포스트그레스 어드밴스드 서버(EPAS)와 EDB 포스트그레스 디스트리뷰티드(EDB Postgres Distributed)다. 이 릴리스에는 데이터베이스 수준에서 데이터를 암호화하고 DBA에 완전한 통제 기능을 부여하는, 많은 사용자가 요청한 투명한 데이터 암호화(Transparent Data Encryption: TDE)가 포함된다. TDE는 우발적인 노출 및 필요한 해독 키가 없는 위협 행위자의 무단 액세스로부터 기밀 데이터와 기타 클라우드 데이터 자산을 보호하는 데 도움이 될 수 있다. 이 보안 기능은 클라우드를 적극 도입한 대기업에 특히 유익할 것이다.

포스트그레SQL 및 포스트그레SQL 커뮤니티의 주요 기여자 중 하나인 EDB는 기술 혁신을 적극적으로 이끌고 있다. 데이터베이스를 확장하는 EDB PG 15의 새로운 제품과 기능은 기업이 포스트그레SQL을 사용하는 모든 곳에서 기업을 지원한다.
editor@itworld.co.kr
Sponsored

회사명 : 한국IDG | 제호: ITWorld | 주소 : 서울시 중구 세종대로 23, 4층 우)04512
| 등록번호 : 서울 아00743 등록발행일자 : 2009년 01월 19일

발행인 : 박형미 | 편집인 : 박재곤 | 청소년보호책임자 : 한정규
| 사업자 등록번호 : 214-87-22467 Tel : 02-558-6950

Copyright © 2024 International Data Group. All rights reserved.