베어 메탈 vs. AWS RDS: NUMA 인식 튜닝 및 PostgreSQL 성능 심층 탐구
Source: Dev.to
위에 있는 Source 라인만 그대로 두고, 번역하고 싶은 본문 텍스트를 제공해 주시면 해당 내용을 한국어로 번역해 드리겠습니다.
설정: 32‑Core NUMA‑Aware 머신
비교를 공정하게 유지하기 위해 모든 환경(베어 메탈 vs 클라우드)에는 2 vCPU / 8 GB RAM이 할당되었습니다.
하지만 기본 “하드웨어”에는 근본적인 차이가 있습니다. 우리의 베어‑메탈 노드는 강력합니다:
| Feature | Description |
|---|---|
| CPU | 32 코어 (물리 16 + 하이퍼스레딩 16) |
| Architecture | NUMA‑aware |
| Storage | 로컬 SSD (SAS) |
하이퍼바이저 위에서 “소음이 있는 이웃”과 함께 실행되는 클라우드 VM(t3.large)과 달리, 베어‑메탈 호스트는 PostgreSQL 프로세스가 물리 코어와 전용 메모리 뱅크에 직접 접근하도록 합니다. 그래서 베어 메탈의 2 vCPU ≠ 클라우드의 2 vCPU 입니다.
테스트 구성
| Label | Description |
|---|---|
| CNPG Local ① | CloudNativePG, local-path 스토리지, 기본 튜닝 |
| CNPG Local ② | 동일 클러스터, work_mem + 연결 튜닝 |
| CNPG Local ③ | 동일 클러스터, shared_buffers 최대화 |
| CNPG Longhorn | CloudNativePG, Longhorn 분산 스토리지 |
| RDS Standard | AWS RDS PostgreSQL 17.6, t3.large |
| Aurora IO‑Opt | AWS Aurora PostgreSQL 17.4, I/O‑Optimized |
| Aurora Standard | AWS Aurora PostgreSQL 17.4, Standard |
1. 벤치마크 결과 (평균 TPS)
전체 매트릭스를 여러 번 반복한 후, 최종 평균 성능 순위표는 다음과 같습니다:
| 환경 | 평균 TPS (읽기‑쓰기) | 성능 상태 |
|---|---|---|
| AWS RDS (t3.large) | 4,826.39 | 최고 성능 (버스트 가능) |
| AWS Aurora (I/O‑Prov.) | 3,480.31 | 고성능 (비쌈) |
| CNPG + Tuning ③ | 3,350.58 | 효율성의 왕 (베어 메탈) |
| AWS Aurora Standard | 3,325.89 | AWS 표준 티어 |
| CNPG + Tuning ② | 3,214.43 | 고성능 |
| CNPG + Longhorn | 1,654.84 | 분산 스토리지 오버헤드 |
2. 피크 읽기 전용 TPS (최대 읽기)
모든 클라이언트/스레드 조합에서 달성된 최대 읽기 처리량:
| 환경 | 피크 읽기 TPS | 최적 구성 |
|---|---|---|
| RDS Standard | 13,955 | 10 c / 4 t |
| Aurora IO‑Optimized | 10,928 | 10 c / 1 t |
| Aurora Standard | 10,020 | 10 c / 1 t |
| CNPG Local ③ | 8,325 | 10 c / 1 t |
| CNPG Local ② | 8,065 | 10 c / 1 t |
| CNPG Longhorn | 6,165 | 10 c / 8 t |
| CNPG Local ① | 4,758 | 10 c / 8 t |
RDS Standard는 원시 읽기에서 앞서지만, 동일한 하드웨어인 CNPG ①와 ③ 사이의 75 % 차이는 구성(configuration)이 기본 하드웨어만큼이나 중요함을 증명합니다.
3. 피크 읽기‑쓰기 TPS (최대 쓰기)
| 환경 | 피크 쓰기 TPS | 최적 구성 |
|---|---|---|
| RDS Standard | 2,839 | 25 c / 8 t |
| CNPG Local ③ | 2,539 | 25 c / 1 t |
| Aurora IO‑Opt | 1,622 | 100 c / 1 t |
| Aurora Standard | 1,557 | 100 c / 8 t |
| CNPG Longhorn | 1,318 | 25 c / 8 t |
| CNPG Local ① | 1,254 | 25 c / 1 t |
결과: 튜닝된 베어‑메탈이 두 Aurora 변형보다 우수합니다. Aurora의 쓰기 경로는 분산 스토리지 복제를 포함해 지연 시간이 증가합니다. 우리의 NUMA‑인식 물리 코어와 로컬 SSD SAS 조합이 원시 쓰기 처리량에서 뛰어났습니다.
4. 모든 것을 바꾼 튜닝 발견
| 단계 | 구성 | TPS | 지연시간 |
|---|---|---|---|
| CNPG Local ① (baseline) | Default | 1,116 | 0.896 ms |
| Step 1 – Memory Contention (Tuning ②) | work_mem 32 → 4 MB, max_connections 800 → 200 | 2,402 | 0.416 ms |
| Step 2 – Buffer‑Pool Maximization (Tuning ③) | shared_buffers = 6 GB, enable HugePages | 3,350 | 0.394 ms |
Step 1의 수학적 근거
800 connections × 32 MB = 25.6 GB potential RAM pressure on an 8 GB node → constant swapping. Capping connections stabilized the system.
Step 2 leveraged the host’s direct memory access and NUMA affinity, slashing latency by 56 % without any hardware change.
① 0.896 ms ████████████████████████
② 0.416 ms ███████████
③ 0.394 ms ██████████5. 최종 결론: 성능 vs. 비용 효율성
“RDS Standard는 t3.large 인스턴스의 버스트 특성 때문에 피크 TPS가 더 높게 나타났지만, CPU 크레딧이 소진된 후에는 가격이 크게 상승하고 장기 성능이 예측하기 어려워집니다. 비용 효율성이 중요한 일관된 프로덕션 워크로드에서는 Bare Metal 위의 CNPG가 명확한 승자이며, 비용의 1/10에 약 70 % 수준의 성능을 제공합니다.”
버스트형 CPU 함정
AWS t3 인스턴스는 크레딧 기반 시스템에 의존합니다. 크레딧이 소진되면 성능이 급격히 떨어집니다. 우리의 32‑코어 Bare Metal은 전용 리소스를 제공하므로 CPU 크레딧도 없고 “소음이 나는 이웃”도 없습니다. CPU를 100 % 언제든 사용할 수 있습니다.
ROI 요인
우리의 Bare‑Metal 호스트(IDCloudHost Paket 13)는 512 GB RAM을 탑재하고 있습니다. AWS에서 512 GB RAM 인스턴스를 사용하면 비용이 천문학적이지만, Bare Metal에서는 이 한 대의 머신에 수십 개의 고성능 클러스터를 배치할 수 있으며, 월 약 ~Rp 7 M / mo의 고정 요금으로 운영할 수 있습니다.
주요 요점
| # | 인사이트 |
|---|---|
| 1 | 스토리지는 모든 것이다. Longhorn을 사용한 테스트에서 성능이 크게 떨어지는 것을 확인했다. 데이터베이스의 경우 로컬 SSD SAS 튜닝은 협상할 수 없는 필수 조건이다. |
| 2 | ‘클라우드 세금’은 실제이다. “관리형”이라는 라벨에 프리미엄을 지불한다. CNPG를 사용하면 K8s에서 Postgres를 관리하는 것이 실현 가능하고 훨씬 저렴해진다. |
| 3 | 워크로드를 파악하라. 예측할 수 없는 급증이 있다면 RDS 버스트 용량이 훌륭하다. 안정적이고 트래픽이 많은 시스템에는 베어 메탈이 기반이다. |
| 4 | 기본 설정이 적이다. work_mem과 max_connections 사이의 상호작용은 비선형이다. 기본값을 절대 신뢰하지 말라. |
| 5 | 베어 메탈이 본질적으로 느린 것은 아니다. 적절히 튜닝하면 자체 하드웨어에서 **RDS 쓰기 처리량의 69 %**를 달성했다. |
| 6 | Aurora의 쓰기 경로 오버헤드. 분산 스토리지는 내구성과 읽기 확장을 최적화하며, 순수한 단일 노드 쓰기 속도를 목표로 하지 않는다. |
| 7 | 스토리지 선택 = 설정 선택. 선택한 스토리지 계층이 조정해야 할 튜닝 노브를 결정한다. |
ghorn vs. local‑path
성능 차이는 **33–50 %**입니다. 스토리지 백엔드는 DB 구성만큼 주의를 기울여야 합니다.
환경 세부 정보
- CloudNativePG: v1.24 on K8s 1.31
- Host: 베어‑메탈 32‑core (16 physical / 16 HT), NUMA‑aware
- Storage: RAID 1 (SAS 인터페이스) 구성의 2 × Samsung SM863a Enterprise SSD. NVMe 없이도 적절한 튜닝으로 Aurora Standard 성능의 **100 %**를 달성했습니다.
- AWS Region: ap‑southeast‑3 (Indonesia)
- Scale Factor: 100 (10 M rows)
— 이완 세티아완, Hybrid Cloud & Platform Architect
portfolio.kangservice.cloud