AWS RDS와 EC2 간 네트워크 대역폭 문제 트러블 슈팅

 

 

최근 회사에서 서버 환경에서의 원인 모를 데이터베이스 쿼리 성능 저하 문제를 겪어 며칠간 고생했던 경험이 있습니다. AWS RDS와 EC2 간 네트워크 대역폭 문제를 트러블 슈팅하는 과정을 공유하고 기록하고자 글을 쓰려고 합니다.

 

문제 상황

 

어느날 AWS RDS를 모니터링 하다가 AWS RDS 성능 개선 도우미를 확인해봤는데 , CPU 사용률이 일시적으로 급증하고  세션이 8코어인 처리 속도를 웃도는 50개의 세션이 차있는것을 발견했습니다. 

 

트래킹을 하다보니,평균 15초 정도 소요되는 메소드를 발견했습니다. 단순히 쿼리에 이상인줄 알았지만,  로컬 환경에서는 동일한 쿼리가 300ms도 걸리지 않았습니다.

문제가 되는 쿼리는  20개 컬럼에 450건 정도의 데이터를 조회하는 단순한 조회 쿼리였습니다. 쿼리 실행 계획을 분석한 결과 검색 조건에 인덱싱이 잘 되어 있었고, 코스트도 매우 낮게 나왔습니다.

CP풀에 문제인가 확인하기 위하여 HikariCP 커넥션 풀의 상태를 확인한 결과, 20개 이상의 커넥션이 idle 상태였고, 네트워크 지연을 확인하기 위해 traceroute를 실행했을 때도 30ms 아래로 큰 문제가 없었습니다. 

 

문제 해결의 실..!

 

그래서 며칠간 집와서 도대체 뭐가 문제일까, heap dump도 캡쳐해서 분석해보고 여러가지 가능성을 생각해봐도 인스턴스에 따라 다른것은 네트워크밖에 없다고 생각이 들었습니다.

 

그러다가 우연한 기회에 AWS Summit을 가게 되었는데, 거기서 AWS 엔지니어분과 짧은 미팅을 통해 네트워크 IO문제 일 수 도 있다는 말을 듣게되었습니다. 바로 해당 부분에 대한 설정을 찾아봤습니다. 

 

 

 

네트워크 출력 병목이 걸린 그래프

 

그랬더니 위 그래프와 같이 일정시간 병목 현상이 걸린 그래프를 찾았습니다.해당 시간은 메소드의 수행시간이 매우 느린 시간과도 일치했습니다.

하지만 원인은 찾아도 해당 이슈가 잘 이해가 되진 않아서 네트워크와 메소드의 수행 시간에 대한 연관관계를 좀 더 알아봤습니다.이유는 크게 2가지로 볼 수 있었습니다. 

 

 

1. EC2 인스턴스의 네트워크 대역폭에 대한 차이

 

EC2 인스턴스의 네트워크 대역폭은 인스턴스 타입에 따라 다릅니다. 예를 들어, t2.micro 인스턴스는 최대 72 Mbps의 대역폭을 제공하지만, c5n.18xlarge 인스턴스는 최대 100 Gbps의 대역폭을 제공합니다.

 

 

2. EC2와 RDS 간의 네트워크 대역폭 비율

 

 RDS 인스턴스가 높은 대역폭을 제공하더라도, EC2 인스턴스의 대역폭이 낮다면 전체 네트워크 성능이 EC2 인스턴스의 대역폭에 의해 제한됩니다.

 

* 해당 내용은 정리 할게 너무 많아 따로 포스팅으로 작성해보려고 합니다. 

 

 

해결 방안

 

그리고 문제의 쿼리가 자주 호출하는 값이 없을때는 메모리에 로컬 캐싱을 쌓아놓는 구조로 변경하여 최대한 로우를 적게 가져오도록 변경했습니다. 

또한 문제 해결을 위해 현재 사용 중인 EC2 인스턴스 타입을 더 높은 대역폭을 제공하는 인스턴스로 업그레이드 했습니다.  t2.medium 인스턴스에서 t3.large 인스턴스로 업그레이드한 결과, 네트워크 대역폭이 크게 증가했습니다. 

 

마치며 

 

비록 여러가지 검증으로 골머리를 앓고 시간도 오래 걸리기는 했지만, 문제를 해결하려고 하는 과정에서 여러가지 툴들과 많은 레퍼런스(AWS, Visual VM) 등을 찾아본 계기가 되었던것 같습니다. 

혹시라도 비슷한 케이스인 간헐적인 DB조회의 속도 차이가 발생한다면 네트워크 IO를 확인해 보시는걸 추천합니다.