문제 인식
DB 서버의 I/O 성능 개선을 위해 EBS 볼륨의 Provisioned IOPS를 8,000까지 올렸습니다. 그런데 CloudWatch에서 실제 IOPS 지표를 확인해보니 4,000~6,000 사이에서만 사용되고 있었고, 설정한 8,000에 도달하지 못했습니다.
인터페이스가 집중되는 시간대에 DB 응답 지연이 반복적으로 발생했고, IOPS를 충분히 올렸음에도 지연이 해소되지 않아 원인 파악이 필요했습니다.
| 항목 | 값 |
|---|---|
| EBS 설정 IOPS | 8,000 |
| CloudWatch 실제 IOPS | 4,000 ~ 6,000 |
| 인스턴스 유형 | t3.xlarge |
| 증상 | 인터페이스 집중 시 DB 응답 지연 |
원인 분석: EC2 인스턴스의 EBS 성능 제한
EBS 자체의 IOPS 설정에는 문제가 없었습니다. 원인은 EC2 인스턴스 유형에 있었습니다.
EBS 성능은 "볼륨"만의 문제가 아니다
AWS에서 EBS 성능은 두 가지 요소에 의해 결정됩니다:
- EBS 볼륨 자체의 성능 (Provisioned IOPS, 볼륨 유형 등)
- EC2 인스턴스의 EBS 최적화 성능 한도
실제 EBS 성능은 이 두 가지 중 더 낮은 쪽에 의해 제한됩니다. 아무리 EBS 볼륨의 IOPS를 높여도, EC2 인스턴스가 그만큼의 I/O를 처리할 수 없다면 의미가 없습니다.
t3.xlarge EBS 성능 스펙
| 항목 | 값 |
|---|---|
| Baseline Bandwidth | 695 Mbps |
| Maximum Bandwidth | 2,780 Mbps |
| Baseline IOPS | 4,000 |
| Max Burst IOPS | 15,700 |
| Baseline Throughput | 86.88 MB/s |
| Maximum Throughput | 347.50 MB/s |
핵심은 Baseline IOPS가 4,000이라는 점입니다.
IOPS Credit 메커니즘
t3 계열 인스턴스는 CPU뿐만 아니라 EBS I/O에도 크레딧 기반의 버스트 모델을 사용합니다.
- Baseline 이하 사용 시: IOPS 크레딧이 축적됩니다
- Baseline 초과 사용 시: 축적된 크레딧을 소모하며 최대 15,700 IOPS까지 버스트 가능
- 크레딧 소진 시: Baseline인 4,000 IOPS로 제한됩니다
버스트 가능 시간은 크레딧 잔량에 따라 다르지만, 일반적으로 최대 약 30분 정도 유지됩니다. 크레딧이 바닥나면 아무리 EBS에 8,000 IOPS를 프로비저닝해놨어도 인스턴스 레벨에서 4,000 IOPS로 강제 제한됩니다.
실제 발생한 시나리오
시간 흐름 →
[크레딧 충분] [크레딧 소진 시작] [크레딧 바닥]
8,000 IOPS 사용 가능 6,000 IOPS 수준으로 하락 4,000 IOPS로 제한
├─── 약 30분 ───┤ ├─── 점진적 하락 ───┤ ├─── 지연 발생 ──→
- 서비스 시작 시에는 크레딧이 충분하여 8,000 IOPS 근처까지 사용 가능
- 지속적으로 Baseline(4,000)을 초과하는 I/O가 발생하면서 크레딧 소모
- 약 30분 후 크레딧이 소진되면서 IOPS가 4,000으로 떨어짐
- 인터페이스가 몰리는 시간대에 I/O 병목 → 응답 지연 발생
CloudWatch에서 4,000~6,000 사이의 IOPS가 관측된 이유는, 크레딧이 남아있을 때는 버스트로 6,000 이상을 쓰다가 크레딧이 소진되면 4,000으로 떨어지는 패턴이 반복되었기 때문입니다.
CloudWatch에서 확인하는 방법
이 문제를 진단할 때 확인해야 할 CloudWatch 지표:
- EBSIOBalance%: EBS I/O 크레딧 잔량 (퍼센트). 이 값이 0%에 가까워지면 IOPS 제한이 걸리고 있다는 의미
- EBSByteBalance%: EBS 대역폭 크레딧 잔량
- VolumeReadOps / VolumeWriteOps: 실제 IOPS 사용량
EBSIOBalance%가 지속적으로 감소하다가 0% 근처에서 머무르는 패턴이 보인다면, 인스턴스 레벨의 IOPS 제한에 걸리고 있는 것입니다.
해결 방안
1. 인스턴스 유형 변경 (권장)
Baseline IOPS가 충분한 인스턴스 유형으로 변경합니다.
| 인스턴스 유형 | Baseline IOPS | 비고 |
|---|---|---|
| t3.xlarge | 4,000 | 크레딧 기반, 버스트 제한 있음 |
| m5.xlarge | 18,750 | 고정 성능, 크레딧 제한 없음 |
| m6i.xlarge | 20,000 | 고정 성능, 크레딧 제한 없음 |
| r5.xlarge | 18,750 | 메모리 최적화 + 고정 EBS 성능 |
m5, m6i, r5 등의 범용/메모리 최적화 인스턴스는 크레딧 기반이 아닌 고정 Baseline 성능을 제공하므로, 지속적으로 높은 IOPS가 필요한 워크로드에 적합합니다.
2. t3 계열을 유지해야 하는 경우
- t3.2xlarge로 스케일업: 다만 t3 계열은 2xlarge까지도 Baseline IOPS가 4,000으로 동일하므로 근본적 해결이 안 됩니다
- EBS I/O 사용 패턴 최적화: 불필요한 I/O를 줄이거나, 캐싱 레이어를 도입하여 Baseline 이하로 유지
3. 스토리지 아키텍처 개선
- 읽기 부하가 큰 경우: ElastiCache 등 인메모리 캐시 도입
- 로그/임시 데이터: Instance Store(NVMe) 활용
- 데이터 분산: 여러 EBS 볼륨으로 I/O 분산
4. EBS Burst Balance 모니터링 추가
CloudWatch의 EBSIOBalance% 지표를 알람에 추가하여 Credit 소진을 사전 감지합니다.
고민과 반성
EBS IOPS만 보고 EC2 제한을 간과한 점
"IOPS가 부족하네? EBS IOPS 올리면 되지." 이렇게 단순하게 생각했던 게 문제였습니다. EBS 볼륨의 IOPS만 보고, 그 위에 있는 EC2 인스턴스의 성능 한도는 전혀 고려하지 않았거든요. 인프라를 다루면서 한 레이어만 보고 판단하는 습관이 있었다는 걸 깨달았습니다.
"EBS 성능 = EBS 설정값"이라는 단순한 사고에서 벗어나, EC2 ↔ EBS 간의 I/O 경로 전체를 하나의 파이프라인으로 이해해야 한다는 것을 배웠습니다. 가장 좁은 구간이 전체 성능을 결정합니다.
앞으로는 성능 이슈가 생겼을 때 볼륨 → 인스턴스 → 네트워크 순서로 각 레이어의 한도를 먼저 확인하는 습관을 들여야겠다고 다짐했습니다.
t3 계열의 Burst 모델에 대한 이해 부족
t3 인스턴스의 CPU Credit 시스템은 잘 알고 있었지만, EBS I/O에도 동일한 Credit 기반 Burst 모델이 적용된다는 사실은 이번에 처음 인지했습니다. 특히 t3 계열이 CPU뿐 아니라 EBS I/O에도 크레딧 기반 버스트 모델을 쓴다는 건, 알고 나면 당연한 건데 모르면 절대 떠올리기 어려운 부분이었습니다.
평상시에는 Burst로 정상 동작하다가 부하가 집중되는 순간 갑자기 성능이 떨어지는 패턴이라, 문제를 재현하고 원인을 특정하는 데 시간이 걸렸습니다.
AWS 콘솔에서 IOPS 설정 시 경고가 없었던 점에 대한 아쉬움
EBS 볼륨의 IOPS를 변경할 때, AWS 콘솔에서는 해당 인스턴스 유형의 EBS 성능 제한에 대한 경고나 안내가 표시되지 않았습니다. 예를 들어 이런 안내가 있었으면 좋겠습니다:
⚠️ 이 볼륨이 연결된 인스턴스(t3.xlarge)의 Baseline EBS IOPS는 4,000입니다. 설정하신 8,000 IOPS를 지속적으로 사용하려면 인스턴스 유형 변경을 권장합니다.
이런 한 줄짜리 경고만 있었어도 삽질하는 시간을 크게 줄일 수 있었을 겁니다. 물론 AWS 문서에는 이 내용이 잘 정리되어 있습니다. 하지만 문서를 꼼꼼히 읽지 않으면 놓치기 쉬운 부분이고, 실제 운영 중에 콘솔에서 바로 확인할 수 있다면 훨씬 실수를 줄일 수 있을 거라 생각합니다.
AWS re:Post 및 콘솔 Feedback 제출
이 아쉬움을 단순히 개인적인 반성으로 끝내지 않고, 실제로 AWS re:Post에 Feature Request를 작성하고 AWS 콘솔의 Feedback을 통해서도 제출했습니다. 요지는 "EBS IOPS를 변경할 때, 연결된 EC2 인스턴스의 Baseline EBS 성능을 초과하는 경우 경고를 표시해달라"는 것입니다.
단순히 원인 파악에 시간이 걸리는 것을 넘어서, DB 서버처럼 I/O가 서비스 품질에 직결되는 워크로드에서는 설정값과 실제 성능의 괴리를 모른 채 운영하면 장애로 이어질 수 있는 문제입니다. 이런 피드백이 실제 서비스 개선으로 이어지길 바랍니다.
교훈
EBS 성능 튜닝 시, 볼륨의 IOPS만 올리면 끝이 아닙니다. 반드시 EC2 인스턴스 유형의 EBS 성능 한도를 함께 확인해야 합니다.
특히 t3 계열처럼 크레딧 기반으로 동작하는 인스턴스는 CPU뿐 아니라 EBS I/O에도 버스트 제한이 있다는 점을 기억해야 합니다. 지속적으로 높은 IOPS가 필요한 프로덕션 워크로드에서는 t 계열보다 m, r, c 계열 등 고정 성능 인스턴스를 선택하는 것이 안전합니다.