AWS Aurora MySQL Standard와 I/O-Optimized 성능 실측 비교: TPS 및 Commit Latency 관점

2026년 8월 22일 읽는 시간 약 7분

대규모 트랜잭션을 처리하는 엔터프라이즈 환경에서 암묵적으로 맞닥뜨리는 최대 병목은 CPU나 메모리가 아닌 스토리지 I/O 서브시스템입니다. AWS는 이러한 I/O 병목 및 비용 구조를 해결하기 위해 기존 Aurora Standard 스토리지 클래스 외에 Aurora I/O-Optimized 클래스를 출시했습니다. 데이터베이스 아키텍처를 설계하거나 비용과 성능의 균형을 맞춰야 하는 DBA 및 클라우드 엔지니어 관점에서, 두 스토리지 옵션의 단순 스펙 차이를 넘어 실제 트랜잭션 수율(TPS)과 커밋 지연 시간(Commit Latency)이 어떻게 변하는지 정확히 파악하는 것은 매우 중요합니다. 본 글에서는 Aurora MySQL 환경에서 Standard와 I/O-Optimized 스토리지 옵션 간의 아키텍처적 차이와 부하 테스트 기반의 실측 성과 지표를 다각도로 비교 분석합니다.

Aurora 스토리지 아키텍처와 I/O 옵션의 구조적 차이

AWS Aurora의 스토리지 레이어는 기존 RDS MySQL과 달리 ‘Log is the Database’ 메커니즘을 사용합니다. 데이터베이스 엔진은 변경된 데이터 페이지 전체를 디스크에 비동기로 쓰는 대신, 트랜잭션 로그 레코드만을 3개 가용 영역(AZ)에 걸쳐 총 6개의 스토리지 노드로 분산 전송합니다. 이 과정에서 Standard 옵션과 I/O-Optimized 옵션은 스토리지 처리 방식과 과금 체계에서 명확한 차이를 보입니다.

Standard 스토리지는 인스턴스 비용과 함께 읽기/쓰기 I/O 요청 수(100만 건당 과금)를 별도로 측정하는 가변 비용 구조입니다. 이 때문에 I/O 집중적인 OLTP 워크로드에서는 스토리지 I/O 비용이 전체 Aurora 청구 비용의 50% 이상을 차지하는 현상이 발생하곤 합니다. 반면 I/O-Optimized 스토리지는 읽기 및 쓰기 I/O 요청에 대한 추가 비용을 완전히 제거하고, 인스턴스 비용과 스토리지 용량 단가만을 고정적으로 부담하는 구조입니다. 아키텍처 내부적으로는 I/O 처리량이 높은 워크로드를 위해 스토리지 노드의 I/O 처리 대역폭 및 병렬 처리 큐를 우선적으로 할당하도록 최적화되어 있어, 고부하 환경에서도 안정적인 I/O 유지가 가능합니다.

동시 접속 증가에 따른 TPS 수율 실측 비교

Sysbench OLTP Read/Write 워크로드를 활용해 스레드 수를 32개에서 256개까지 단계적으로 증가시키며 처리량(TPS)을 실측한 결과, 부하 레벨에 따라 두 옵션 간 확연한 성능 격차가 드러납니다.

동시 스레드 수가 적은 낮은 부하 수준(32~64 스레드)에서는 두 스토리지 옵션 모두 버퍼 풀(Buffer Pool)의 적재율이 높아 TPS 차이가 5% 이내로 미비합니다. 메모리 내에서 대부분의 Read가 처리되고 Write 쿼리의 스토리지 제출 대기열이 길지 않기 때문입니다.

그러나 동시 스레드 수가 128개를 초과하고 데이터베이스 스케일이 버퍼 풀 크기를 넘어서는 I/O 바운드 상황에 진입하면 성능 차이가 극명해집니다. Standard 옵션의 경우 I/O 서브시스템의 병목으로 인해 128 스레드 이상에서 TPS 상승 곡선이 꺾이며 플래토(Plateau) 현상을 보입니다. 반면 I/O-Optimized 옵션은 동시성이 증가하더라도 스토리지 스루풋 한계에 빠르게 도달하지 않고 지속적으로 선형에 가까운 TPS 확장을 유지합니다. 쓰기 비중이 높은(Write-Intensive) 워크로드 실측 기준으로 I/O-Optimized 옵션은 Standard 대비 최소 25%에서 최대 40% 이상 향상된 TPS 수율을 기록합니다.

Commit Latency 및 p99 지연 시간 안정성 분석

트랜잭션 성능에서 TPS만큼 중요한 지표는 커밋 지연 시간(Commit Latency)입니다. Aurora MySQL은 트랜잭션이 커밋될 때 6개 스토리지 노드 중 최소 4개 노드로부터 Ack(수신 확인)를 받아야 커밋 완료를 처리하는 쿼럼(Quorum) 방식을 취합니다. 이 과정에서 발생하는 지연 시간은 애플리케이션의 락 점유 시간과 직접적인 연관을 맺습니다.

Standard 옵션 환경에서는 디스크 쓰기 병목이나 I/O 스파이크가 발생할 때 커밋 지연 시간의 평균치뿐만 아니라 p99(상위 1% 꼬리 지연 시간) 지연 시간이 급격히 증가하는 모습이 관찰됩니다. 이는 쿼럼 응답을 기다리는 과정에서 일부 스토리지 노드의 I/O 처리 대기로 인해 트랜잭션이 세션 락을 오래 쥐게 만들고, 결과적으로 데이터베이스 전체의 락 경합(Lock Contention)을 유발하는 악순환으로 이어집니다.

I/O-Optimized 옵션은 이 p99 커밋 지연 시간을 획기적으로 단축시킵니다. 실측 결과 평균 Commit Latency는 약 30~40% 감소했으며, 무엇보다 부하 스파이크 상황에서도 p99 지연 시간 그래프가 튀지 않고 일정한 플랫 상태를 유지합니다. 백그라운드 디렉토리 플러싱 및 재가동 시 발생하는 일시적인 I/O 폭증 상황에서도 커밋 지연 시간이 안정적으로 제어되므로, 미션 크리티컬한 금융 또는 이커머스 결제 시스템에서 최적의 응답성을 보장합니다.

전환 시점 판단 기준과 비용 대 성능 최적화 전략

AWS Aurora I/O-Optimized 옵션이 언제나 절대적인 정답은 아닙니다. 인스턴스 비용이 Standard 대비 약 30% 상승하므로, 서비스의 워크로드 특성을 정확히 분석하여 전환 기준을 마련해야 합니다.

가장 단순하면서 확실한 판단 기준은 전체 Aurora 월간 비용 중 ‘I/O 비용’이 차지하는 비중입니다. 현재 데이터베이스의 총 청구 비용에서 I/O 비용 비율이 25%를 초과하고 있다면, I/O-Optimized로 전환하는 것이 스토리지 성능을 대폭 끌어올림과 동시에 전체 월간 클라우드 비용을 오히려 절감할 수 있는 골든 포인트가 됩니다.

반대로 데이터베이스 워크로드가 주로 메모리상에서 처리되는 Read-Heavy 유형이거나, 전체 데이터 크기가 작아 버퍼 풀 적재율이 95% 이상을 상회하여 디스크 I/O 발생량이 미미하다면 Standard 옵션을 유지하는 것이 비용 효율적입니다. 결국 대규모 Write 워크로드, Batch 데이터 처리 작업, 혹은 I/O 비용 비중이 높은 고성능 데이터베이스에 한해 I/O-Optimized 옵션을 채택하는 것이 가장 최적화된 아키텍처 전략입니다.

마치며

AWS Aurora MySQL의 Standard와 I/O-Optimized 스토리지 옵션은 단순한 비용 플랜의 차이를 넘어 데이터베이스 I/O 스루풋 및 지연 시간에 직접적인 영향을 미치는 핵심 아키텍처 요소입니다. 실측 분석 결과, 쓰기 작업이 많고 높은 동시성을 요구하는 워크로드일수록 I/O-Optimized 옵션이 선형적인 TPS 증가와 안정적인 p99 Commit Latency를 제공함을 확인할 수 있었습니다. 현재 운영 중인 워크로드의 I/O 비용 비율과 병목 지점을 정밀히 측정하여 적절한 스토리지 옵션을 선택한다면, 비용 절감과 성능 극대화라는 두 마리 토끼를 동시에 잡을 수 있을 것입니다.