여러분, 혹시 "DB 복제, 하는 게 무조건 좋을까?" 고민해 보신 적 있나요? 
고가용성(HA)을 생각하면 필수지만, 막상 성능이 얼마나 떨어질지 걱정되기도 하죠.
그래서 저희가 직접 팔을 걷어붙였습니다!
실제 전자상거래 환경을 그대로 재현한 TPC-C 벤치마크를 통해, EPAS에서 복제 설정이 성능에 어떤 영향을 주는지 아주 심층적으로 파헤쳐 봤습니다. 함께 보시죠!
TPC-C가 도대체 뭐길래?
간단히 말해, "DB 체력장"이라고 보시면 됩니다.
단순히 개별 쿼리 성능을 재는 게 아니라, 현실에서 발생하는 조회와 변경 업무가 복합적으로 뒤섞인 상황을 재현해 DBMS의 진짜 처리 능력을 측정하는 표준 방법론입니다.
이번 테스트에서 살펴본 트랜잭션들과 테스트 케이스입니다!
Transaction name | Query TYPE |
New-Order | SELECT 1 → SELECT 2 → UPDATE → INSERT |
Payment | SELECT 1 → UPDATE 1→ SELECT 2 → UPDATE 2 → SELECT 3 → SELECT 4 → SELECT 5 → UPDATE 3 → SELECT 6 → UPDATE 4 → INSERT |
Delivery | SELECT MIN() → DELETE → SELECT 1 → UPDATE 1 → UPDATE 2 → SELECT 2 → UPDATE 3 |
Order-status | SELECT 1 → SELECT 2 → COUNT → SELECT(정렬) → SELECT 3 → SELECT 4 |
Stock-Level | SELECT → Count(DISTINCT) (RANGE SELECT) |
테스트 케이스 | 테스트 항목 | 테스트 방법 |
Data Set 100G / Running Session 10 / 수행시간 10분 | Single | TPC Tool 데이터 적재 및 수행 |
Streaming Replication(ASYNC) | ||
Streaming Replication(SYNC) | ||
Data Set 100G / Running Session 20 / 수행시간 10분 | Single | |
Streaming Replication(ASYNC) | ||
Streaming Replication(SYNC) | ||
Data Set 100G / Running Session 40 / 수행시간 10분 | Single | |
Streaming Replication(ASYNC) | ||
Streaming Replication(SYNC) |
실험 결과: "누가누가 잘하나?"
Running Session 10: "가벼운 부하에서는?"
- Single
- ASYNC
- SYNC
- Single
- ASYN
- SYNC
•
TPM 지표: Single → ASYNC → SYNC 순으로 성능이 좋게 나타났습니다. Single 모드는 복제본으로 데이터를 보내고 기다리는 과정이 아예 없어서 처리량이 가장 높았죠.
•
SYNC vs ASYNC: SYNC 모드는 Primary 서버가 복제본으로부터 "WAL 잘 받았다!"라는 확인 응답(ACK)을 받을 때까지 트랜잭션 커밋을 대기합니다. 이 때문에 네트워크 지연만큼 성능이 조금 떨어지게 됩니다.
•
CPU 사용량: ASYNC → Single → SYNC 순으로 높았습니다. 보통 복제 구성은 WAL 전송 작업이 추가되어 Single보다 CPU를 더 쓰는데, 특히 ASYNC는 응답을 기다리지 않고 계속 WAL을 전송하기 때문에 가장 바쁘게 움직입니다.
•
잠깐! SYNC의 CPU가 왜 낮죠? SYNC 모드는 확인 응답을 기다리는 동안 CPU 자원을 쓰지 못하고 유휴 상태로 머물기 때문이에요. 겉으로는 조용해 보이지만 사실은 '대기 중'인 상태인 거죠!
Running Session 20: "최적의 밸런스 지점!"
- Single
- ASYNC
- SYNC
- Single
- ASYNC
- SYNC
세션을 20으로 늘렸더니 모든 모드에서 TPM과 CPU 사용량이 함께 올라갔습니다.
순위는 Session 10과 동일하게 유지되었는데요. 흥미로운 건, 이 구간이 이번 테스트 환경의 '최적 부하 지점'이었다는 사실입니다!
자원 활용 효율(CPU 사용량 대비 TPM)이 가장 극대화된 구간이었거든요.
Running Session 40: "고부하 상황의 반전!"
- Single
- ASYNC
- SYNC
- Single
- ASYNC
- SYNC
여기서 놀라운 결과가 나왔습니다.
TPM 지표가 Single → SYNC → ASYNC 순으로 바뀌며 SYNC와 ASYNC의 순위가 역전되었습니다!
•
ASYNC의 고전: 40개 세션이 미친 듯이 커밋을 시도하니 WAL 생성과 전송에 필요한 자원이 부족해졌습니다. 특히 walsender가 파일을 읽어 보내는 과정에서 다른 프로세스들과 디스크 I/O 경합이 극심해지며 처리 속도가 뚝 떨어졌죠.
•
SYNC의 의외의 선전: 반면 SYNC는 복제본 응답을 기다리는 대기 메커니즘 덕분에 디스크 I/O 경합이 강제적으로 제한되었습니다. 이 대기 시간이 오히려 시스템이 과부하로 무너지지 않게 안정적인 속도를 유지해 주는 완충 작용을 한 셈입니다.
•
효율성: 다만, Session 20 때보다 TPM은 줄고 CPU 사용량은 늘어난 것으로 보아, 이미 서버의 처리 능력을 초과한 과부하 상태임을 알 수 있었습니다.
TPC-C 성능 측정 최종 결론
테스트 부하 | Single | ASYNC | SYNC |
Running Session 10 | TPMC : 72526.40TPM TOTAL : 161137.30 | TPMC : 69271.00TPM TOTAL : 153663.30 | TPMC : 63489.70TPM TOTAL : 140911.60 |
Running Session 20 | TPMC : 78017.80TPM TOTAL : 173400.10 | TPMC : 76231.90TPM TOTAL : 169708.50 | TPMC : 72766.20TPM TOTAL : 161860.00 |
Running Session 40 | TPMC : 72814.40TPM TOTAL: 162237.30 | TPMC : 71255.10TPM TOTAL : 158398.50 | TPMC : 71608.20TPM TOTAL : 159208.90 |
1.
최적 성능 지점: 우리 테스트 환경에서는 Running Session 20에서 가장 높은 효율을 보였고, Single 모드가 가장 우수했습니다.
2.
복제 도입의 비용: 모든 케이스에서 Single 모드가 가장 빨랐으며, 복제 구성 시 약 6~9% 정도의 처리량 감소와 그에 따른 CPU 사용량 증가가 수반되었습니다.
3.
고부하 역전 현상: 시스템이 포화 상태인 Session 40 시나리오에서는 오히려 SYNC 모드가 ASYNC보다 안정적이고 약간 더 높은 성능을 기록했습니다.
마치며
EPAS 복제 구성은 쿼리 부하 분산과 고가용성 확보라는 측면에서 아주 강력한 장점이 있습니다.
다만, 테스트 결과처럼 부하 정도와 복제 방식에 따라 처리 효율이 달라질 수 있다는 점을 꼭 유의해야 합니다.
이번 리포트가 여러분이 서비스에 딱 맞는 복제 전략을 선택하시는 데 큰 도움이 되기를 바랍니다!
더 궁금한 점이 있으시면 언제든 말씀해 주세요. 다음에 더 알찬 정보로 돌아오겠습니다. 안녕!
참고 자료
•
TPC-C Homepage: https://www.tpc.org/tpcc/
이영준 프로
오픈소스사업부 오픈소스기술팀
오픈소스 DBMS 엔지니어로서, 삼성 그룹 계열사 및 대외 금융권 기업들의 DBMS 기술지원 업무를 수행하고 있습니다.