EPAS 17과 PostgreSQL 17, 확장성과 성능이 두 배 향상된 비결
작성자: Alessandro Ferraresi
2024년 12월 2일
높은 트랜잭션 성능과 오라클 호환성, 강화된 엔터프라이즈 기능이 필요한 워크로드를 운영하고 계신가요? EDB Postgres Advanced Server(EPAS) 17은 PostgreSQL 17의 주요 개선 사항과 EPAS 고유의 최적화를 바탕으로 고동시성 환경의 확장성과 성능을 향상합니다.
PostgreSQL을 발전시키는 오픈소스 커뮤니티의 기여를 기반으로 EPAS 17은 확장 효율성에서 큰 발전을 이루었으며, 이전 버전인 EPAS 16보다 성능이 거의 두 배 향상되었습니다. 이 글에서는 PostgreSQL 17과 EPAS 17의 주요 개선 사항을 살펴보고, HammerDB 벤치마크를 통해 성능 차이를 확인합니다.
이러한 성과는 어떻게 가능했을까요? 혹시 ‘작은 요정들을 더 불러온 것 아닐까요?’ 물론 실제로 그런 것은 아닙니다. 굳이 비유하자면 저장소에 SHA-256 해시 이름을 가진 코드 요정들이 살고 있고, 이들이 모두 힘을 합쳤다고 할 수 있습니다.
EPAS 17과 PostgreSQL 17의 주요 성능 개선 사항
- WAL 삽입 잠금 최적화
PostgreSQL 17은 I/O 계층 성능을 지속적으로 개선하고 있습니다. 높은 동시성 워크로드는 쓰기 선행 로그(WAL) 처리 개선을 통해 최대 2배 높은 쓰기 처리량을 경험할 수 있습니다. 새로운 스트리밍 I/O 인터페이스는 테이블 전체 데이터를 읽는 순차 스캔과 ANALYZE의 통계 업데이트 속도도 향상합니다. - 쿼리 실행 성능 개선
PostgreSQL 17에서는 IN 절을 사용하는 쿼리의 B-tree 인덱스 성능이 향상되었습니다. - 파일 시스템 읽기를 그룹화하는 새로운 시스템 변수
io_combine_limit도입
이러한 결과는 PostgreSQL 커뮤니티가 이룬 발전을 기반으로 하며, 이를 통해 EPAS도 크게 향상되었습니다. EPAS와 EDB Postgres Extended Server(PGE)는 커뮤니티 PostgreSQL을 매우 밀접하게 따르며, 일부 “PostgreSQL 호환” 제품과는 차이가 있습니다. EDB는 패치와 기능 개선, 코드 리뷰, 신규 커뮤니티 구성원 멘토링 등의 활동을 통해 커뮤니티 PostgreSQL에 직접 기여하고 있습니다.
PostgreSQL의 개선 사항 외에도 EPAS 17은 성능을 지원하는 추가 기능을 제공합니다. 예를 들어, EPAS 17은 파티셔닝 과정에서 프루닝 후 잠금을 획득하도록 수정되어 파티션이 많은 환경에서 더 나은 성능을 제공합니다. 개선 정도는 워크로드에 따라 달라질 수 있습니다.
HammerDB 기반 EPAS 16·17 성능 벤치마크 설계
벤치마크에서는 투명성과 재현 가능성이 중요합니다. 따라서 동일한 테스트를 실행할 수 있도록 테스트 방법론과 환경 사양, 구성 정보를 함께 제공합니다.
이번 테스트에서는 온라인 트랜잭션 처리(OLTP) 워크로드를 실행하는 TPC-C 유사 벤치마크 도구인 HammerDB를 사용해 EPAS 16과 EPAS 17의 성능을 비교했습니다. 다른 도구를 사용할 수도 있지만, HammerDB는 오라클 데이터베이스, Microsoft SQL Server, IBM Db2, MySQL, MariaDB, PostgreSQL 등 주요 데이터베이스를 지원하는 벤치마킹 및 부하 테스트 소프트웨어입니다.
HammerDB는 널리 알려진 TPC-C와 TPC-H 벤치마크를 공정하게 구현한 오픈소스 소프트웨어입니다. 소스 코드는 TPC의 GitHub에 호스팅되며 TPC-OSS 하위 위원회에서 관리합니다.
이번 테스트는 메모리에 맞는 데이터셋에서 HammerDB를 실행하도록 설계했습니다. 이를 통해 스토리지 병목 현상의 영향을 줄이고 EPAS 16과 EPAS 17의 성능 차이를 확인했습니다.
HammerDB는 사용자 지연 없이 최대한 많은 트랜잭션을 수행하도록 설계되었습니다. 실제 환경에는 사용자 지연이 존재할 수 있지만, 이 방식은 높은 부하 조건에서 시스템 성능을 관찰하는 데 도움이 됩니다. 성능 검증을 위해 벤치마크 테스트 중 New Orders Per Minute(NOPM)를 측정했습니다.
NOPM은 서로 다른 데이터베이스 엔진을 비교하는 데 사용할 수 있는 지표입니다.
테스트에는 최신 하드웨어 리소스를 갖춘 시스템이 필요했으며, EDB의 파트너인 Supermicro가 이를 지원했습니다.
테스트 환경 사양
- 운영 체제(OS):
RHEL 9.5 (5.14.0-503.14.1.el9_5.x86_64) - CPU:
2x Intel® Xeon® Gold 6538N (32코어) - RAM:
1024GB - 스토리지:
- 4x SSD U.2 NVMe 7.68TB PCIe v5 – RAID 10 (Postgres 데이터)
- 2x SSD U.2 NVMe 7.68TB PCIe v5 – RAID 0 (Postgres WAL)
- 1x SSD M.2 NVMe 960GB (운영 체제)
HammerDB 벤치마크 설정
다음은 HammerDB를 사용해 데이터셋을 생성하고 워크로드를 실행하기 위한 구성 코드입니다.
데이터베이스 스키마 생성
#!/bin/tclsh
puts "SETTING CONFIGURATION"
dbset db pg
diset connection pg_host "localhost"
diset connection pg_port "5444"
diset tpcc pg_defaultdbase "postgres"
diset tpcc pg_count_ware 5000
diset tpcc pg_num_vu 128
diset tpcc pg_raiseerror true
diset tpcc pg_superuser "enterprisedb"
diset tpcc pg_superuserpass "123"
diset tpcc pg_user "tpcc"
diset tpcc pg_pass "tpcc"
diset tpcc pg_oracompat false
diset tpcc pg_storedprocs false
diset tpcc pg_partition true
buildschema
puts "BUILD COMPLETE"
벤치마크 실행
#!/bin/tclsh
puts "SETTING CONFIGURATION"
dbset db pg
diset connection pg_host "localhost"
diset connection pg_port "5444"
diset tpcc pg_raiseerror true
diset tpcc pg_defaultdbase "postgres"
diset tpcc pg_superuser "enterprisedb"
diset tpcc pg_superuserpass ""
diset tpcc pg_user "tpcc"
diset tpcc pg_pass "tpcc"
diset tpcc pg_driver timed
diset tpcc pg_duration 10
diset tpcc pg_rampup 4
diset tpcc pg_timeprofile false
diset tpcc pg_allwarehouse true
diset tpcc pg_oracompat false
diset tpcc pg_storedprocs false
diset tpcc pg_vacuum true
puts "SEQUENCE STARTED"
foreach z { 1 4 8 16 32 64 96 128 192 256 320 } {
puts "VU TEST $z "
loadscript
vuset vu $z
vuset logtotemp 0
vucreate
vurun
vudestroy
}
puts "TEST SEQUENCE COMPLETE"
exit
데이터베이스 매개변수(postgresql.conf 변경 사항)
max_connections = 1000
shared_buffers = 256GB
effective_cache_size = 512GB
work_mem = 8MB
maintenance_work_mem = 64GB
effective_io_concurrency = 200
maintenance_io_concurrency = 200
max_worker_processes = 128
max_parallel_maintenance_workers = 64
checkpoint_timeout = 1d
max_wal_size = 2500GB
min_wal_size = 64GB
random_page_cost = 1.0
vacuum_cost_limit = 8000
autovacuum = off
autovacuum_freeze_max_age = 1000000000
autovacuum_multixact_freeze_max_age = 1000000000
max_locks_per_transaction = 512
edb_dynatune = 0
PostgreSQL 17·EPAS 17 성능 벤치마크 결과
초기 가상 사용자(Virtual User, VU) 구간에서는 EPAS 16과 EPAS 17의 성능이 유사해 보입니다. 그러나 32VUs부터 EPAS 17의 성능 개선이 나타나기 시작해 11.5%의 향상률을 기록했습니다. 성능 향상률은 64VUs에서 62%, 최고점인 320VUs에서 132%까지 증가했습니다.
이번 테스트는 캐싱을 기반으로 설계되었으므로 I/O의 영향을 배제하고 EPAS 16과 EPAS 17의 CPU 활용도 및 확장성 차이를 관찰하는 것이 중요합니다.
그래프를 보면 EPAS 17이 CPU를 훨씬 효율적으로 활용해 높은 동시성 수준에서 확장성을 크게 향상했으며, 100% 이상의 성능 개선을 달성한 것을 확인할 수 있습니다.
데이터베이스 엔진에서 CPU 처리 성능을 효과적으로 활용하는 것은 매우 중요합니다. EPAS 17은 이 부분에서 큰 발전을 이루었습니다.
PostgreSQL의 새로운 주요 버전으로 업그레이드하는 일이 항상 흥미로운 것은 아니지만, 이번에는 이야기가 다릅니다. 기존 하드웨어만으로도 성능을 크게 향상할 수 있다면 추가 비용 없이 상당한 이점을 얻을 수 있습니다.
데이터베이스의 트랜잭션 성능을 최대한 끌어올리고 싶다면 이 요정들, 즉 코드를 잘 활용해 보세요. 😉
EPAS 17과 PostgreSQL 17 성능 FAQ
EPAS 17의 성능이 EPAS 16보다 향상된 이유는 무엇인가요?
EPAS 17은 PostgreSQL 17의 WAL 처리, 쿼리 실행 및 스트리밍 I/O 개선 사항을 기반으로 합니다. 여기에 파티션 프루닝 후 잠금을 획득하도록 수정된 EPAS 고유의 개선 사항이 더해져 고동시성 환경의 확장성이 향상되었습니다.
PostgreSQL 17의 WAL 개선은 어떤 효과를 제공하나요?
PostgreSQL 17은 WAL 삽입 잠금을 최적화했습니다. 이에 따라 높은 동시성 워크로드에서 최대 2배 높은 쓰기 처리량을 경험할 수 있습니다.
EPAS 16과 EPAS 17의 성능은 어떻게 비교했나요?
TPC-C 유사 OLTP 워크로드를 실행하는 HammerDB를 사용해 두 버전을 비교했습니다. 스토리지 병목의 영향을 줄이기 위해 메모리에 맞는 데이터셋을 사용하고 New Orders Per Minute(NOPM)를 측정했습니다.
EPAS 17은 HammerDB 벤치마크에서 얼마나 향상되었나요?
본문의 테스트 결과에 따르면 EPAS 17은 32개의 가상 사용자에서 11.5%, 64개의 가상 사용자에서 62%의 성능 향상을 보였습니다. 320개의 가상 사용자에서는 EPAS 16보다 132% 높은 성능을 기록했습니다.
io_combine_limit은 무엇인가요?
io_combine_limit은 PostgreSQL 17에 도입된 시스템 변수입니다. 파일 시스템 읽기를 그룹화하는 범위를 제어하는 데 사용됩니다.
원문: Scaling Breakthrough: EPAS 17 Scales Twice as Well, Thanks PostgreSQL!