AWS RDS 비용 줄이는 방법 (성능 개선 도우미)

AWS RDS 비용 줄이는 방법 및 최적화 하기 

 

서론 ( 안 읽어도 됨)

 

현재 필자가 다니는 회사는 예약관리 서비스를 하고 있습니다.

처음 입사 했을 때는 사용자가 그리 많지 않아서 T시리즈를 이용해도 문제가 없었지만,

 

입사 후 갑자기 폭팔적인 서비스 성장으로 인해 순간 동접 1만을 넘는 거대한 서비스가 되었고,

현재 해당 분야 업계 1위가 되었습니다.

 

서비스 성장은 언제나 즐겁지만, 스타트업들의 개발 코드는 여기서부터 문제입니다.

서비스를 위한 기능 추가만 하다보니 코드가 그렇게 깔끔하지 않을 뿐더러, 

ORM 코드들의 최적화되지 않은 쿼리도 문제였습니다.

 

이 문제는 우리 회사도 다르지 않았습니다.

 

처음 MariaDB 를 사용하고 있었는데..

DB 의 CPU 가 90프로를 넘기는 경우가 종종 있었고, 업글을 해도 그 다음달이면 똑같은 문제가 계속 생겼습니다.

아 이제부터가 문제이구나 ....

 

 

본론

 AWS 서비스를 이용하다보면 아무래도 RDS 비용이 제일 부담스럽습니다.

하지만 잘만 이용하면 RDS 비용을 많이 줄일수 있습니다.

저희 회사는 정점 일때 매달 16k 달러의 AWS RDS 비용을 지불했습니다 .다른 서비스 비용까지 하면 금액은 천문학적입니다.

(빌링 리포트에서 예상금액이 18k로 나왔을 때 심각성을 느끼고 최적화 작업을 시작했다.)

그래서 AWS 컨설팅도 받고, 여러가지 DB 튜닝등의 경험으로 현재 8K 로 줄인 경험을 나누고자 합니다.

 

13K 일 당시 요금 (16K일때는 스샷을 찍지 못했습니다.)

 

1. RDS의 성능을 업하는 것보다, 갯수를 늘리는 것이 저렴합니다 (이왕이면 오토 스켈링)

- EC2와 마찬가지로 RDS도 읽기전용DB를 이용하여 갯수를 늘릴수 있습니다. 물론 쓰기보다 읽기가 많은 서비스에 한해서 가능합니다. 저희 서비스는 24시간 항상 사용자가 많은 것이 아니기 때문에, AWS API 를 통하여 사용자가 많은 시간에만 읽기전용 DB를 늘려서 사용했습니다. 오로라 디비를 사용하면 CPU와 connect 수로도 자동조절 가능하지만, 우리는 정확한 시간 때에 사람이 몰리기 때문에 스케쥴링을 쓰고 있습니다. (새벽에는 읽기를 모두 없애고 쓰기/읽기 겸용 디비 1대만 돌리는 전략을 쓴다.)

 

현재시간 읽기전용DB가 2개 돌아가고 있다. (피크 타임 때는 읽기만 5개돌리고 있습니다.)

 

2. 캐시DB를 적극 활용하자.

- 처음 이회사에 왔을 때 Redis를 사용하지 않고 있었습니다. 피크타임 때에는 모든 데이터가 초단위로 바뀌기 때문에 의미가 없었다고 생각했던 것 같았습니다. 물론 특정 서비스는 캐시를 사용할 수 없을 수도 있습니다. 그런데 잘 찾아보면 있을수도 있습니다. 이부분을 찾아주면 정말 큰 도움이 됩니다. 우리 서비스는 예약관련 상품들의 횟수가 중요하기 때문에 모든 부분이 캐시를 할수 없다고 생각되었지만, 의외로 자주 쓰는 부분이 잘 변하지 않은 고정값인 것을 찾았습니다. 바로 제한 부분인데..

예약할때 제한 부분은 잘 바뀌지 않은 부분이고 예약이 이루어질 때 항상 검증해야하는 부분이기 때문에 캐시화 했을 때 성능에 큰 이득을 보았습니다. Redis, Memcahced는 할수 있다면 최대한 활용하면 좋습니다.

 

3. Slow Query 를 찾습니다.

 - ORM을 쓰다보면 개발 속도와 OOP적 개발은 쉽지만, 디비 쿼리 이슈가 종종 발생합니다. 자신들의 슬로우 쿼리르 각자들이 쓰고 있는 Framework에서도 잡을수 있지만, 로컬에서는 문제 없지만 실DB에서는 느려지는 이상한 아이들이 존재할수 있음으로 실DB의 Slow Query 의 존재를 항상 확인해주는 습관이 좋습니다.

 

DB 구성에 보면 CloudeWatch Log 에 슬로우 쿼리가 쌓이고 있다. (만일 없다면 슬로우 쿼리를 활성화해주면 된다)

 

 

통계 쿼리를 제외하고는 슬로우 쿼리가 존재하지 않는다. (우리는 통계를 테이블용 테이블이 별도로 존재하지 않아 조금 느리다.)

 

4. 최적화된 DB 찾기

 DB를 엔진을 선택할 때에 당연히 오라클이 좋다. 하지만 모든 회사가 오라클을 쓸수 없기 때문에, mysql, mariadb 등등을 고려하지만, 최적화된 DB를 찾는 것이 중요합니다. 실예로 로그 디브는 형식이 다양하기 때문에 관계형 DB 즉 RDS 보다는 document DB 를 쓰는 것이 바람직하며 성능에도 훨씬 도움이 된다.

 

5. 성능개선 도우미 이용하기 (강추)

 AWS에는 성능 개선 도우미라는 기능을 제공한다. Log 를 장기 보관하면, DB 클래스 별로 vCpu 댓수 만큼 가격이 나가지만, 그 값어치는 충분히합니다. 필자가 추천하는 체크 사항은 

 

아래와 같습니다. 각 항목별로 보는 방법은 아마 두세번 클릭해보면 바로 이해가 될것입니다.

필자가 추천하는 성능 개선에 필요한 참고항목들 입니다.

 

잘 모르겠을 때에는 RDS모니터링에서 DB가 부하 걸리는 시간을 확인한 후에 위에 항목들을 모두 체크하고 해당 시간을 확인합니다.

문제가 되는 부분을 확인한 후에 최하단 상위 query 에 나온 색깔을 확인후에 자신의 문제 쿼리를 찾으면 됩니다.

 

보통 Slow Query만 찾기 십상인데.. Slow Query 말고도 디비를 느리게 하는 경우가 은근히 있습니다.

그리고 무조건 where에 많이 사용한다고 index를 남발하면 index_merge가 발생할수 있습니다.

EXPLAIN을 잘 사용하여 query 전략을 잘 짜도록 합시다.