최근 신규 프로젝트 개발을 마치고 릴리즈를 앞두고 있었습니다.
릴리즈 전 부하테스트를 하다 AWS ElastiCache for Redis에서 네트워크 대역폭의 허용 범위를 넘게 되었는데요.
겪었던 문제와 해결한 경험을 가볍게 소개드리려 합니다.
목차
1. 네트워크 대역폭이란?
- 네트워크 대역폭의 기본 개념
- AWS ElastiCache for Redis에서의 대역폭 중요성
2. Network Bandwidth Out Allowance Exceeded의 의미
- AWS ElastiCache for Redis 인스턴스 스펙
- Baseline bandwidth vs Burst bandwidth
3. 해결 방법
- 데이터 압축
- 요청 딜레이 적용
- 스케일업 및 스케일 아웃
마치며
Reference
1. 네트워크 대역폭이란?
네트워크 대역폭의 기본 개념
네트워크 대역폭의 중요성을 이해하기 위해서는 네트워크 IO (입출력)의 개념을 살펴볼 필요가 있습니다. 네트워크 IO는 데이터가 시스템의 네트워크 인터페이스를 통해 들어오고 나가는 과정을 의미합니다. 이는 데이터베이스 읽기 및 쓰기, 사용자 요청의 처리, 데이터의 동기화 등 다양한 작업에서 발생합니다.
AWS ElastiCache for Redis에서의 대역폭 중요성
AWS ElastiCache for Redis에서 네트워크 IO는 특히 중요한 역할을 합니다. Redis는 인메모리 데이터 저장소로, 빠른 읽기 및 쓰기 작업을 수행하여 고속 데이터 처리를 가능하게 합니다. 이러한 작업들은 모두 네트워크 IO를 통해 이루어지므로, 네트워크 대역폭의 문제는 직접적으로 Redis의 성능에 영향을 미칩니다. 네트워크 대역폭이 충분하지 않으면, 데이터의 이동 속도가 느려지고, 이는 IO 병목 현상으로 이어질 수 있습니다. 따라서, ElastiCache for Redis를 효율적으로 사용하기 위해서는 네트워크 대역폭과 IO 성능을 균형 있게 관리하는 것이 중요합니다.
2. Network Bandwidth Out Allowance Exceeded의 의미
'Network Bandwidth Out Allowance Exceeded' 오류는 AWS ElastiCache for Redis에서 네트워크 대역폭 사용량이 할당된 한도를 초과했음을 나타냅니다. 이는 짧은 시간 동안 높은 네트워크 사용량이 발생했을 때 주로 나타납니다. 대규모 데이터베이스 쿼리, 대용량 파일의 업로드/다운로드, 트래픽 급증 등으로 인해 발생할 수 있습니다. 이러한 버스트는 잠시 동안만 지속되지만, 많은 양의 데이터가 네트워크를 통해 이동하게 됩니다.
위 그래프는 네트워크 out 용량이고 아래는 대역폭 초과 개수입니다. 잘 보시면 out 용량이 튈 때도 대역폭 초과 수가 적을 때가 있습니다. 이는 해당 시간에 네트워크 출력 용량이 많아도 한 번에 요청이 아닌 약간의 딜레이가 있었기 때문에 네트워크 대역폭이 초과하지 않은 경우입니다.
AWS ElastiCache for Redis 인스턴스 스펙
AWS ElastiCache for Redis 인스턴스는 특정한 네트워크 대역폭 한도를 가지고 있으며, 이 한도는 인스턴스의 유형과 크기에 따라 달라집니다. 'Network Bandwidth Out Allowance Exceeded' 오류가 발생하면, 이는 인스턴스가 잠시 동안 너무 많은 데이터를 전송하려고 시도했음을 의미합니다. 이러한 상황은 네트워크 성능 저하, 응답 시간의 증가, 심지어 서비스 중단과 같은 문제를 일으킬 수 있습니다. 따라서, 네트워크 사용량을 모니터링하고 적절하게 관리하는 것은 AWS ElastiCache for Redis를 효과적으로 운영하는 데 매우 중요합니다.
Redis를 선택할 때 AWS 메인 페이지에서 스펙을 확인하면 아래와 같습니다. (elasticache-redis 가격)
처음 인프라를 설정할 때 위 네트워크 성능만 보고 결정하였습니다.
네트워크 성능이 최대 5/10기가비트라니?! 문제 없겠군!
하지만 부하 테스트를 해보니 네트워크 대역폭 에러가 발생했습니다.
Redis가 지원하는 네트워크 대역폭이 5 Gbps / 10 Gbps이니 절대 넘칠 일이 없겠다 생각했지만, 이는 스펙을 제대로 보지 않았던 것입니다. 🥲
Baseline bandwidth vs Burst bandwidth
지원되는 노드 유형 (AWS - ElastiCache for Redis) 의 상세한 스펙을 살펴보면 네트워크 대역폭이 2개로 나뉘어 있습니다.
AWS가 제공하는 네트워크 대역폭은 기준 대역폭(baseline)과 버스트 대역폭으로 구분됩니다.
예를 들어 cache.t4g.medium 인스턴스는 기준 0.256 Gbps / 버스트 5.0 Gps입니다. 기준 대역폭이 넘게 되면 추가 네트워크 대역폭을 확보하기 위해서 네트워크 I/O 크레딧 메커니즘을 사용하여 기본 대역폭 이상으로 버스트하게 됩니다. 인스턴스 크기에 따라 일반적으로 5~60분의 제한된 시간 동안 버스트 대역폭을 사용할 수 있다고 합니다.
인스턴스는 시작 시 최대 네트워크 I/O 크레딧 수를 받습니다. 인스턴스가 네트워크 I/O 크레딧을 모두 소진하면 기본 대역폭으로 돌아갑니다. 실행 중인 인스턴스는 기본 대역폭보다 적은 네트워크 대역폭을 사용할 때마다 네트워크 I/O 크레딧을 얻습니다. 중지된 인스턴스는 네트워크 I/O 크레딧을 획득하지 않습니다. 버스트 대역폭은 공유 리소스이므로 인스턴스 버스트는 인스턴스에 사용 가능한 크레딧이 있는 경우에도 최선을 다해 수행됩니다. (Amazon EC2 인스턴스 네트워크 대역폭)
정리하자면 Network Bandwidth Out Allowance Exceeded가 발생한 이유는 짧은 시간에 기본 대역폭 넘게 네트워크를 통해 데이터를 전송했고, 네트워크 I/O 크레딧을 사용하여 버스트 네트워크를 사용한 것입니다.
+a) 과거 CPU 크레딧을 다써서 서버가 죽은 경험이 있었는데 이번에는 네트워크 크레딧 상황을 마주하게 되었네요.
3. 해결 방법
신규 프로젝트만의 특징이 있었습니다.
- 대규모 트래픽이 발생한다.
- 트래픽이 갑자기 튀기도 한다.
- 트래픽이 많으니 원천 데이터는 모두 캐싱을 바라본다.
- 이를 위해서 로컬 캐시를 주로 사용한다.
- 데이터 업데이트 시 이벤트를 발행해 한 대의 서버에서만 원천 e.g. RDB에서 데이터를 읽어 레디스를 업데이트한 뒤에 모든 서버에서 글로벌 캐시(레디스)에서 데이터를 읽어 로컬 캐시를 리프레시한다.
위 프로젝트에서 레디스 네트워크 대역폭 초과가 발생한 이유는 xx 대의 서버가 배치를 돌면서, 또는 업데이트된 경우 로컬 캐시를 리프레시를 하기 위해 동시에 레디스에서 데이터를 읽기 때문에 발생한 것입니다.
이를 위해 애플리케이션 관점에서 2가지 / 인프라 관점에서 1가지를 적용할 수 있었습니다.
3.1 데이터 압축
레디스에 데이터를 압축하여 저장합니다.
- 장점: 데이터 압축은 전송되는 데이터의 크기를 줄여 네트워크 부하를 감소시킵니다. 이는 네트워크 대역폭 사용량을 줄이는 데 효과적입니다.
- 단점: cpu 사용률이 증가하고, 응답 시간이 늘어날 수 있습니다.
- 구현 방법: 클라이언트 측에서 데이터를 압축하여 Redis에 저장하고, 데이터를 검색할 때 다시 압축을 해제합니다. 이를 위해 zlib, gzip 등의 압축 라이브러리를 사용할 수 있습니다.
3.2 레디스 요청 시 랜덤 딜레이 적용
모든 서버가 한 번에 레디스를 조회할 때 랜덤하게 딜레이를 주어 네트워크 부하를 분산시킵니다.
이는 서비스 정책마다(업데이트 시간) 다르지만, 신규 서비스 정책 상 0 ~ x000 ms 늦는 것은 괜찮다고 판단되었습니다.
- 요청 간 딜레이: 한 번에 많은 양의 데이터를 요청하는 대신, 요청 간에 약간의 지연을 두어 네트워크 부하를 분산시킬 수 있습니다.
- 구현 방법: 애플리케이션 로직에 딜레이를 추가하거나, 데이터를 여러 작은 배치로 나누어 순차적으로 요청합니다.
3.3 레디스 - 스케일업 및 스케일 아웃
- 스케일업: 스케일업은 인스턴스를 더 큰 유형으로 변경하여 기본 네트워크 대역폭을 증가시킵니다. 이는 더 많은 트래픽을 처리할 수 있게 해 줍니다.
- 스케일 아웃: 스케일 아웃은 클러스터에 더 많은 노드를 추가하여 네트워크 부하를 분산시킵니다. 이는 각 인스턴스의 네트워크 부하를 줄이는 데 도움이 됩니다.
서비스 상황에 맞게 스케일업 또는 아웃을 하면 됩니다.
저의 경우 처음엔 스케일 아웃 방식으로 리더노드를 3대 추가하여 부하를 분산하였지만, 비용을 계산해 보니 스케일 업하는 것이 비용이나 스펙적인 측면에서 유리하여 스케일 업으로 변경하였습니다.
마치며
AWS ElastiCache for Redis의 'Network Bandwidth Out Allowance Exceeded' 문제는 적절한 네트워크 관리 전략을 통해 효과적으로 해결할 수 있습니다. 이를 위해 데이터 압축, 요청 최적화, 적절한 스케일업 및 스케일 아웃을 하여 해결할 수 있었습니다.
감사합니다.
Reference
- 지원되는 노드 유형 (AWS - ElastiCache for Redis)
- 블로그 페페 개구리 이미지 직접 생성
'👾 Server > 👻 장애' 카테고리의 다른 글
| 주니어 백엔드 개발자가 서비스/서버 운영하며 배운 몇 가지 (5) | 2024.03.02 |
|---|---|
| [서버 장애] HTTPS -> HTTP 통신 불가(웹 브라우저의 Mixed Content 차단) (0) | 2022.07.02 |
| [서버 장애] AWS 프리티어 배포 후 장애 - CPU 사용률 100%, 크레딧 0개 이후 ssh 접속도 안되는 상황과 해결 (HW / SW(페이징 limit 문제) (4) | 2022.06.09 |
댓글