brunch

You can make anything
by writing

C.S.Lewis

by 박정호 Sep 28. 2020

AWS RDS 비용 폭탄 사건

Anomaly Detection 그리고 CS Case Open 까지

https://brunch.co.kr/magazine/cloud-finops



이번에 소개드릴 비용관리 케이스는 바로 저희팀의 내용입니다.


며칠 전에 큰 사건이 터질 뻔 했습니다. 아니 터졌다고 해도 될 것 같습니다.


저희 팀에서는 RDB로 AWS Aurora 를 사용하고 있습니다.  

기본적으로 AWS의 다른 RDS 서비스들은 Open Source 를 AWS 인프라에 올려서 서비스하는 것이고, Aurora는 AWS가 직접 소스코드 레벨까지 손을 대서 AWS화해서 제공하는 서비스입니다. 같은 MySQL 엔진을 사용하고 있지만, 인프라만 제공하는 다른 RDS 서비스에 비해서 DB 엔진과 인프라 전체를 망라하여 Aurora에 대한 AWS의 책임범위가 아주아주 넓을 수 밖에 없습니다.


DB는 고객에게 제공되는 화면들의 성능과 아주 많이 연관되어 있기 때문에 쉼없이 튜닝과 개선을 진행하는 대상인데, 얼마전인 9월 17일에 Aurora Parallel Query 한국 리전 적용 뉴스가 날라왔습니다.  


https://aws.amazon.com/ko/about-aws/whats-new/2020/09/announcing-aurora-parallel-query-region-expansion-and-mysql-5-7-compatibility/


Amazon Aurora 병렬 쿼리는 데이터를 별도의 시스템으로 복사할 필요 없이 현재 데이터에 대한 분석 쿼리를 더 빠르게 제공하는 Amazon Aurora 데이터베이스의 기능입니다. 핵심 트랜잭션 워크로드의 처리량을 높게 유지하면서 쿼리 속도를 최대 100배로 높일 수 있습니다.
일부 데이터베이스는 하나 또는 몇 개 서버의 CPU에 걸쳐 쿼리 처리를 병렬화할 수 있지만, 병렬 쿼리는 Aurora의 고유한 아키텍처를 활용하여 Aurora 스토리지 계층에 있는 수천 개의 CPU 전체로 쿼리 처리를 푸시 다운하여 병렬화합니다. 병렬 쿼리는 분석 쿼리 처리를 Aurora 스토리지 계층으로 오프로딩하여 트랜잭션 워크로드의 네트워크, CPU 및 버퍼 풀 경합을 줄입니다.


위의 AWS 공식 블로그에서 발췌한 내용을 보면, 쿼리 속도를 100배까지... ㄷㄷㄷ  물론 일부 쿼리의 경우는 병렬쿼리가 제대로 동작하기 위해서는 재개발도 해야겠지만, 일단 단순 조회용 쿼리, 특히 몇달치 비용데이터를 조회하는 등의 단순하지만 데이터량이 많은 쿼리의 경우에는 도움이 될 것 같으니 한번 적용해서 성능의 변화를 살펴보기로 했습니다. 


"Parallel Query = ON"으로 설정값 하나만 바꾸는 아주 간단한 작업으로 완료. 

이제 지켜보면서 화면 기준으로 속도를 측정해 보자고...... 


그런데, 걸어놓은 이상비용 탐지에 알람이 뜨기 시작합니다. 


왼쪽 이미지는 이번달 현재까지 발생한 비용과 지난달의 동일 기간을 비교하는 탐지 규칙입니다.

"심각" 하다는 빨간 표시와 함께 AWS 비용이 급증하고 있는 것을 알려주고 있습니다.


오른쪽 이미지는 지난 3일과 그 이전 3일을 비교하는 이상비용 탐지 규칙입니다. 

마찬가지로 "심각" 표시와 함께 3일 기준으로 비용이 거의 100% 증가했음을 알려주고 있습니다.  


  


갑작스러운 이상 비용에 팀은 바빠집니다. 원인을 파악하기 위하여 분주해 집니다.

폭주한 read iops 를 확인됩니다.......

21일 부터 올라가기 시작해서 22일부터 엄청난 증가를 보이고 있습니다. 

하루 20~30만회의 read IOPs 가 하루에 3,500만회로 치솟았습니다... 

고객이 늘어서 치솟아도 IOPs 가 이렇게 급증하면 비용 부담에 기겁을 했을텐데, 

병렬쿼리 옵션 하나로 이런 일이 벌어지다니..... 

도대체 병렬쿼리라는 녀석은 무슨 짓을 하고 있는거지............ ㅠㅠ

허걱............ 우리는 미쳤습니다.....

100배의 성능 향상을 기대했지만, 비용이 이렇게 올라가면 안되지.........ㅠㅠ 


IOPs Count 차트입니다. 잔잔하던 그래프가 22일부터 급증하는 것을 확인할 수 있습니다.


아래는 read IOPs 에 의한 비용 증가입니다.

이전에 설명드린 적이 있는데, 클라우드의 비용 체계는 CPU, Memery, Storage Size 등에 의한 비용과 사용하면서 발생하는 read, write 비용, 네트워크 비용 등의 개별로 반영이 됩니다. 


사용하는 인스턴스의 사양이 동일하고, 저장된 데이터량에는 큰 변화가 없지만, 아래 이미지에서 보이는 것과 같이 IOPs 증가에 의한 비용 폭탄이 이상비용으로 탐지가 된것 입니다.  


비용은 발생했지만, 일단 이상비용 탐지 기능 덕분에 더 이상의 비용이 발생하지 않도록 빠르게 조치를 취할 수 있었고, 이어서 AWS CS Case Open 을 진행합니다.


.....

저희가 이번 IOPS 증가에 대해서 받은 인상은 굉장히 충격적입니다.
병렬 쿼리가 어느 정도 IOPS 증가를 유발할 것이라고는 생각을 했지만, 이렇게 수십배나 되는 많은 요금을 지불하게 될 것으로는 생각지 못했습니다.
분당 IOPS가 10~20만 수준에서 3500만으로 늘어난다는 것이 가당키나 한 말인가요?게다가 병렬 쿼리가 DB 인스턴스보다 더 많은 비용을 유발한다는 사실에 충격받은 상태입니다.
DB 인스턴스 하루 사용 비용이 대략 170달러 이하인데... 병렬 쿼리에 의한 IOPS 비용이 하루 약 1000달러씩 나왔습니다.

......


DB에 대한 request 가 증가한 것이 아닌 상태에서 이렇게 심각하게 비용이 증가할 수 있는 소지가 있으면 사용자에게 충분한 인지를 시켜주어야 하는 것 아닌가요? 그렇게 때문에 이번에 발생한 비용 $3234.305639에 대하여 환불을 요청합니다. 


환불 요청이 받아질지는 잘 모르겠습니다. 

만약 저희가 비용 모니터링을 하지 않고 있다면, 그냥 모르고 있다가 인보이스가 발행되었을 때 약 4천만원 가까운 폭탄을 맞았을 것으로 생각이 됩니다. 

이 모든 것이 설정값 하나 ON 으로 바꾼 것에서 시작되었다는 것을 분명히 알아야 합니다. 

클라우드를 사용하는 것은 개발팀원들 각자에게 한도 무제한의 법인카드를 준 것과 같다는 말이 있습니다.

개발자 누구나 RDS의 설정을 바꾸어 볼 수 있고, 새로운 리소스를 생성할 수 있기 때문에 그렇습니다. 

그렇다고, 클라우드를 쓰면서 설정을 바꾸고, 리소스를 만들 때 마다 개발팀, 재무팀, 정보시스템관리팀, 보안팀, 인프라운영팀의 5단 결재를 받게 하실건가요? 

클라우드 비용관리와 거버넌스를 도와주는 Cloud Management Solution이 필요한 이유입니다.   




"Cloud 관리를 위한 FinOps" - 전체 내용 보기 (https://brunch.co.kr/@cebi750/17)

AWS RDS 비용 폭탄 사건

브런치는 최신 브라우저에 최적화 되어있습니다. IE chrome safari