1. 사건의 발단
사건 발생은 바야흐로 8월 초...
기존 EC2 서비스에서 ECS로 서버를 마이그레이션하는 작업을 수행중이었다.
일요일에 연구실에서 열심히 ECS로 마이그레이션을 진행을 마무리했고 그대로 노트북을 덮었다.
그 주 화요일에 팀별 멘토링 시간에서, 멘토님의 AWS 비용 개선 .. 내용을 듣다가 불현듯
이번에 ECS로 바꿨는데... 뭐 많이 나온거 없겠지?
라는 생각이 머리속을 스치고 지나갔다.
그대로 바로 결제 및 비용관리 탭에 들어가보니 CloudWatch로"$1500"가 찍혀있었다.
난 내가 잘못본줄 알았다ㅋㅋㅋ
진짜 머리속이 새하얘지고.. 눈비비고 다시봐도 그대로인게 공포
만약 ECS로 1500달러 나왔으면 조금이라도 이해를 하겠는데, CloudWatch로 1500달러인게 더 이해가 안됐다;;
2. 과금 원인 분석
최근 설정을 변경한 부분은 ECS 로 마이그레이션을 진행한 것이었기 때문에, ECS의 로그 수집 부분을 살펴 보았다.
(당시 사건 발생 후 컨테이너를 모두 지웠기 사진은 없고, 다른 블로그 글의 사진을 가져와서 설명용으로 첨부한다.)
스프링프로젝트를 ECS 컨테이너로 돌리는 중이었는데, 서비스 문제로 컨테이너가 오류 로그를 무수히 쏟아내고 죽었고 자동으로 다시 컨테이너가 살아나는것이 무한반복되는 상황이었다.
예를 들면 이런식으로 스프링을 처음 시작할때 로그가 몇페이지씩 나오는데, 이게 한줄 한줄 모두 ECS 컨테이너 로그로 기록되고 있었다.
그래서 약 3일동안 약 2테라바이트의 로그가 쌓여있었고, 이것이 과금 폭탄의 원인이었다.ㅠㅠ
기가바이트도 아니고 테라바이트
근데 왜 이렇게 CloudWatch 로그가 많이 쌓여있던걸까???
이유는.. ECS의 태스크를 생성할 때 무심코 선택한 옵션 때문이었다.
이전에 EC2를 사용할때도 로그를 수집했었고 비용도 거의 나오지 않았었다.
그렇기에 ECS에서도 로그 수집을 추가로 선택했는데.. 오류 로그 한줄 한줄이 로그 과금으로 이어질줄을 전혀 예상을 못했었다.
CloudWatch의 과금 정책은 서울리전 기준 GB당 USD 0.76 이다.
ㅎㅎ.. 그러면 약 2TB의 로그가 쌓여있으면 $1500 과금이 계산이 맞긴하다 ㅎ
3. 문제 대응
일단 모든 ECS 클러스터, 태스크를 다 삭제했고 로그 그룹들을 모두 삭제해서 더 이상 과금이 발생하지 않도록 리소스들을 삭제했다.
그리고 AWS 요금폭탄 발생에 대한 다른 블로그 글들을 보니, 처음 이런 과금이 발생한 경우나 대학생인 경우에는 어느정도 면제를 해주는것 같았다.
근데 보통은 IAM Access Key를 실수로 깃허브에 업로드했고, 악의적인 유저가 Access Key를 활용해 암호화페 채굴에 사용했해서 요금 폭탄이 발생한 경우가 대부분인듯 했다.
ㅠㅠ 나는 위 사례와 다르게 순전히 부주의한 사용법 미숙에 졸업 6개월차에 발생한 과금이라 100%는 변제받지 못할것으로 생각했다.
그래도 일단 조금이라도 빌어보고자 AWS 지원센터에 사례를 남겨봤다.
ECS를 처음 사용하고 3일만에 이런 과금이 발생했고.. 취업준비를 위한 토이프로젝트 진행중이었고.. 나의 사용 미숙으로 이런 일이 발생해서 귀사의 리소스를 낭비해서 너무 죄송하고.. 팀원들에게도 너무 미안하고.. 이런식으로 길게 작성했던것 같다.
처음에는 영문으로 작성했는데, 한국인은 AWS 한국 고객지원팀에서 답변을 해주는 듯 했다. 그래서 이후로는 한국어로 메일을 주고받았다.
메일을 보내고 답변을 받기까지 보통 2일정도 소요됐다.
메일을 주고 받고, 최종적으로 약 7일이라는 시간만에 CloudWatch로 발생한 과금을 100% 변제 받을 수 있게되었다. ㅠㅠ
현재 대학생 신분이 아니라서 걱정을 많이 했는데, 최초 1회는 도움을 주는것 같다.
4. 배운 점
첫째, AWS는 유료서비스이며, 신중하게 사용해야한다.
AWS는 전세계 기업들의 비즈니스 파트너이며, 당연히 '유료'로 서비스를 제공한다.
나는 프로젝트를 진행하며 50만원이라는 큰 지원금이 있었는데, 그러다보니 AWS 리소스들을 이용할 때 하루이틀 쯤은 켜놔도 비용이 부담되진 않았다. 그렇기에 비용과금 정책에 대해 좀 더 안일하게 생각했던것 같다.
이 사건 이후로는 AWS에서 리소스 생성할때 옵션마다 과금 정책을 꼼꼼히 따져보고, 정말 필요한 최소한의 옵션만을 선택하도록 노력했고
더이상 사용하지 않은 리소스는 바로바로 삭제하거나 중지하여 과금을 줄이는 습관을 길렀다.
둘째, 처음 사용하는 서비스는 모니터링이 필수다.
아무리 옵션을 꼼꼼하게 선택했다 하더라도, 처음 사용하는 서비스에서는 실수가 생길 수 있다.
그렇기에 ECS 이후 EKS로 진행한 프로젝트에서는 처음 리소스를 생성한 이후 30분마다 로그 그룹과 비용 청구서를 조회하며 예상치 못한 과금이 발생하는 것을 모니터링을 통해 초기에 방지하고자 노력했다.
셋째, 예산 기능을 적극 활용하자.
나는 Free-Tier를 사용하고 있었기 때문에 CloudWatch의 최초 5GB의 limit alert를 메일로 받았었다.
부끄럽지만 AWS 리소스 관련 메일들을 항상 확인하는건 아니었기에 초기 경고를 보지 못했었다..
이 사건 이후로는 AWS 제로예산기능을 사용하여, 1달러 초과 과금마다 메일이 오도록 설정했고 예산 초과에 관련된 메일들은 한번도 빠짐없이 확인하고 주기적으로 비용 및 청구서 조회를 하고있다.
이렇게 빡세게 과금 관리를 한 덕분인지, 나머지 1달 반의 프로젝트 기간에서는 예상치못한 과금으로 인한 문제는 없었다.
이번 사태로 배운점이 정말 많고, 더 뼈저리게 느꼈다.
AWS의 비용 결제가 내 카드에 연결되어 있으니 더 무서웠다ㅠㅠ
잘 해결이 되어서 다행이긴하지만, 정말 실무에서 이런실수를 했다면.. 시말서로 끝나지 않을 것 같기에..
지금 톡톡히 배워서 두번 다시는 같은 실수를 하지 않으려고 노력하고자 한다!!
