회사에 매달 청구되는 aws 비용을 1,000 달러이상 절감했던 이야기

null

현 회사에 JAVA 백엔드 개발자로 입사한 지 8개월차로 접어들었습니다. 입사 초반에는 백엔드 개발업무를 주로 하다가Amazon Web Service (AWS)도 다뤄볼 수 있는 기회를 얻게 되었습니다.

 

기존에는 제 개인계정으로 EC2, RDS, S3 등 간단하게 프리티어로 이용해본게 전부인데 실무에서 잘 할 수 있을지 걱정이 많았지만 일단 해보기로 했습니다.

 

AWS 계정을 받고 처음 딱 접속을 해보니 저희 회사는 AWS의 많은 서비스를 이용하고 있었고 그 중에는 실질적으로 쓰이지 않고 리소스만 점유하고 있는 자원들도 굉장히 많았고 24시간 풀로 가동되지 않아도 될 서비스들도 24시간 풀로 서비스 되고있는 자원도 많았습니다.

 

그걸보고 느낀점은 사용하지 않는 자원, 또는 효율적이지 못한 자원을 제거하면서 리소스들을 효율적으로 사용하여 비용을 절감하게끔 구성해야겠다 라고 생각했습니다.

 

그 결과 정확한 수치는 말씀드리기 곤란하지만 회사에 매달 청구되는 aws 비용을 1,000 달러이상 절감에 성공하였습니다.그러면 이제 제가 어떻게해서 절감에 성공하였는지 간략하게 말씀드리겠습니다.

 

AWS 오픈톡방

null

먼저 AWS 서비스들을 이해를 해야 된다고 생각하여 공식문서를 보기 시작했습니다. 하지만 공식문서는 내용이 좀 어렵고 낯선단어가 많아서 이해하기 힘들었습니다. 그래서 AWS 오픈 카카오 채팅방에 들어가 흘러가는 대화를 보거나 질문을 통해서 지식을 얻어가기로 했습니다.

 

어느정도 지식을 쌓은 뒤 다시 공식문서의 글을 읽어보니 그제서야 내용이 이해하기 시작했습니다. (아는만큼 보인다...)

사용하지 않는 자원을 제거

사실 이 부분은 제일 단순하면서도 제일 위험했던 작업이었습니다. 단순히 제거하는 작업이지만 이 자원들이 정말 아무곳에서 쓰이지 않는걸까에 대한 보장은 없었습니다. 사용하지 않는 자원은 대부분 EC2 였습니다.

 

처음에는 이 자원들을 추적하여 이것과 연관된 모든 서비스들을 다 조사하였습니다. 회사에서 운영하고 있는 애플리케이션 서버들의 설정파일들도 해당 EC2 엔드포인트를 참조하고 있는지 체크하였습니다.

 

정말로 쓰여지는곳이 없는 걸 확인했을 때 제거를 하려고 했지만 그 전에 EC2를 1주정도 중지한 후 아무일이 발생되지 않았을 때 종료시키는 방향으로 진행했습니다.

효율적이지 못한 자원을 제거

예전에 애플리케이션의 요청 / 응답을 추적하여 디버깅에 많은 도움을 줄 수 있다고 하여 회사내에서 AWS X-RAY를 적용해보자고 얘기가 나와서 적용한 적이 있었는데 비효율적이다 라고 판단하여 제거하게 되었습니다.

 

비효율적이다 라고 판단한 근거는 다음과 같습니다.

• 활용도가 매우 적고 애플리케이션에 버그가 발생되더라도 X-RAY에서 로드맵을 보기가 불편하다.
• 비용도 엄청 비싸다.
• X-RAY의 요청/응답을 추적하기 위해 Segment를 생성해야하는데 이 생성로직을 애플리케이션 로직에 심어줘야하거나, javaagent를 별도로 추가해줘야 하는데 해당 SDK를 확인해본 결과 거의 Deprecated된 코드들이 많다. (쓰이지 않는 코드인 것 같은데 딱히 업데이트를 하지는 않는 것 같다)
• X-RAY는 마이크로서비스 아키텍처로 구성된 서비스에 적합한데 저희 회사 서비스 특성상 X-RAY를 도입하기엔 적합하지 않다고 판단

 

이러한 경험을 통해 좋아 보이는 서비스여도 회사에서 운영하는 서비스에 적합한걸 도입해야겠다고 생각했습니다.

리소스들을 효율적으로 사용하여 비용을 절감

회사 AWS 계정에는 스테이지, 프로덕션용 EC2와 RDS가 있고 24시간 돌아가고 있습니다.
그런데 스테이지용 EC2와 RDS는 굳이 24시간 돌리지 않고 회사에서 업무를 보는 시간에 돌리고 퇴근시간 + 주말에는 돌리지 않게끔 구성하면 충분히 많은 비용을 절감할 수 있다는 생각이 들었습니다.

 

알아보니 AWS에서는 이미 Instance-scheduler 라는걸 제공하고 있습니다.

 

이걸 이용하여 Event Bridge와 Lambda를 접목시켜서 EC2, RDS를 원하는 시간대에 스케줄링을 하게끔 구성하였고 이후 청구되는 비용이 절감되었습니다.

 

후기

백엔드 개발업무를 진행하면서 팀원들에게 공부한 내용 공유, 사용자가 원하는 기능, 불편했던 기능을 개선하는 등의 많은 업무를 처리하여 서비스 품질을 높혀왔었습니다.

 

하지만 이번에 처리했던 aws 비용절감은 개발업무보다 더 만족도가 높았던 것 같습니다. 서비스의 품질을 높혀도 비용이 줄어들지는 않았지만 서비스 품질은 높혀가면서 발생되는 비용을 줄인다는 메리트가 굉장히 크다고 느꼈기 때문입니다.

 

위 사례말고도 더 다양한 사례가 있지만 너무 많은걸 오픈하면 문제가 될 소지가 있기도 하고 기억에 남는 몇개만 추출해서 설명해보았습니다.

 

앞으로도 회사에 계속 많은걸 기여하고 같이 일하고 싶어하는 개발자가 되겠습니다.