AWS 불필요한 리소스 찾아 비용절감하기
AWS 비용절감은 개발자의 의지만으로 되지 않는 경우가 많습니다. 이글에서 공유하고 싶은 포인트는 2가지입니다.
첫째, “AWS의 불필요한 리소스 제거”는 기술적인 어려움보다 조직 내 히스토리 파악과 합의를 이끌어내는 것이 필요하다는 점입니다. 개발자가 제거하는 실무 역할을 담당하지만 이 업무는 조직 내의 열린 소통과 이해가 필요하며 담당자의 인내심과 오너십이 필요합니다.
둘째, 인프라 리소스의 꾸준한 모니터링과 정리가 필요합니다.
이와 관련된 4가지 사례를 이 글에서 공유하려고 합니다.
AWS 서비스 중 사용하지 않는 리소스를 제거함으로써 비용절감을 했던 4가지 사례를 묶어서 정리했습니다.
개발 산출물은 코드 작성이 끝나는 순간 레거시다라는 말이 있습니다. 레거시는 기술부채로 여겨지고 유지보수 용이라는 목표 아래 지속적인 관리를 해주어야 합니다.
인프라도 똑같습니다. 목표를 가지고 설정했던 라이브했던 인프라들이 관리가 되지 않으면 그대로 방치되는 경우가 많습니다. 이는 그대로 비용 지출로 이어집니다. 데이터베이스를 새로 구성하고 사용하는 시점엔 목표가 있습니다. 그러나 업무가 우선순위에 밀려 흐지부지되기도 하고, 담당했던 사람이 퇴사를 하면서 인수인계에 구멍이 생기는 경우도 있습니다. 2-3년만 넘게 인프라를 운영했다면 그렇게 남겨진 인프라가 여전히 라이브되고 있어도 히스토리를 몰라서 함부로 삭제를 할 수 없게 됩니다.
따라서 인프라 리소스를 지속적으로 모니터링하고 불필요한 것을 제거하는 것은 DevOps나 개발 조직의 누군가에게 지속적인 역할로 부여해주는 것이 좋습니다.
히스토리를 모르고 있는 상황에서 불필요한 리소스인지 판단하고 정리하려면
사내 문서에서 관련 서비스를 사용한 흔적을 찾고,
담당자가 아니더라도 알고 있는 사람들에게 설명을 듣고,
마지막으로 지표를 통해 해당 서비스에 접속이 있는지 확인해야 합니다.
예를 들어 RDS의 지표는 아래 정보를 판단하는게 좋습니다.
Cloudwatch 지표
Performance Insights
Performance Insights를 활성화했다면 아래 그림처럼 RDS > 성능개선 도우미에서 해당 리소스를 선택하여 활동을 볼 수 있습니다. 최근 7일, 또는 30일 동안 쿼리 실행 기록이 없는지를 보면 됩니다. Performance Insights는 7일간 성능 데이터를 보존할 경우 무료이기 때문에 평소에도 활성화해두는게 좋습니다.
CloudTrail로 실시간 정보를 추적하거나 스토리지 사용량이 변화하는 추적할 수도 있습니다. 그러나 위 Cloudwatch와 Performance Insights 지표로 오랜 기간 사용하지 않는 것을 확인하는 것이 중요하고 그걸로 충분하다고 판단됩니다.
AWS 비용을 줄이기 위해 가장 쉽게 접근할 수 있는 것은 사용하지 않은 것, 불필요한 리소스를 찾아 제거하는 것입니다. 내부에서는 크게 4가지가 사용하지 않는다고 판단되었습니다.
Crawling 목적으로 운영했던 RDS 인스턴스
Ampitude → 데이터웨어하우스 적재 스케줄러
GA4 → 데이터웨어하우스 적재 스케줄러
Elasticsearch 서버 인스턴스
1번의 경우 판단하기가 용이했습니다. 위에 언급한 것처럼 지표를 확인했을 때 활성화가 되어 있지 않음이 분명했습니다. 내부 구성원들과 히스토리를 파악했고 사용하지 않음을 확인한 후 가장 먼저 제거할 수 있었습니다. db.r6g.xlarge를 사용하고 있었기 때문에 월 비용 $457.71를 절감할 수 있었습니다.
참고로 서버 비용은 아래 사이트에서 찾아보면 편합니다.
그러나 2번과 3번은 즉시 제거하는 것을 판단하기 어려웠습니다. 이런 경우는 비용절감을 하려는 목표를 가진 담당자가 오너십을 가지고 히스토리를 파악하고 리소스를 지우는 것이 문제 없는지를 판단할 수 있어야 합니다.
Ampitude → 데이터웨어하우스 적재 스케줄러
이 작업을 통해 S3의 저장 비용과, Data Warehouse의 서버내 볼륨의 저장 비용을 절감할 수 있었습니다. Amplitude의 데이터는 아래와 같은 플로우로 적재가 이루어지고 있었습니다.
Amplitude → S3 → Data Warehouse
먼저 이 데이터를 Data Warehouse에 적재하기 위한 논의 문서를 파악했습니다. 그러나 데이터를 적재하고 난 이후에 활용에 대한 시도가 없었습니다. 내부에서 AWS Quicksight를 Biz 분석 툴로 활용하고 있었기 때문에 관련된 Datamart table이 생성되었는지도 파악했으나 없음을 확인했습니다.
위 내용을 미루어 사용하지 않는 것을 공유했고 제거하는 승인이 났습니다.
제거 순서는 다음과 같이 이루어졌습니다.
Amplitude → S3 연동 스케줄러 제거
Amplitude의 설정에서 쉽게 진행 가능합니다
S3 → Data Warehouse 연동 스케줄러
내부에서 Data Warehouse 서버에서 스케줄러를 동작해 연동되는 것을 파악했습니다. 해당 스케줄러를 disable시키고 Task 실행파일을 가지고 있는 폴더는 Deprecated 처리했습니다. 그리고 모든 작업은 나중에 혹시 사용할 수 있음을 감안 데이터 수집 코드를 백업하고 문서화했습니다.
Data Warehouse 적재된 테이블 삭제 및 백업데이터 S3 보관GA4 → 데이터웨어하우스 적재 스케줄러
이 작업은 EC2 서버 2대 제거, Data Warehouse 데이터 저장 비용 감축에 도움을 주었습니다. 더불어 관리되지 않고 방치되었던 github repository와 CodeDeploy에 남겨진 배포 설정도 제거했습니다.
GA4의 데이터웨어하우스 적재도 위 Amplitude와 목적이 비슷한 것으로 보였습니다. 내부에서 GA4 → Ampitude로 지표 모니터링 서비스를 변경했는데 그 이전의 작업물이 여전히 남아있는 것으로 보였습니다. Amplitude와 달랐던 점은 데이터가 퀵사이트에서 내부 구성원에게 서비스되고 있다는 점이었습니다.
내부 공유를 통해 해당 메뉴의 데이터를 사용하고 있는지를 확인하고, 사용하지 않음에 따라 제거 승인이 났습니다. GA4 → 데이터웨어하우스의 적재는 EC2 서버에서 관리되고 있었습니다. Conjob으로 매일 12시에 데이터를 적재하고 있었고 해당 스크립트도 같은 서버에서 실행되었습니다.
제거는 다음과 같은 순서로 이루어졌습니다
서버 내 스케줄러 중지
코드디플로이 제거
github repository archiving
퀵사이트 Dashboard, Analysis, Dataset 삭제
DW 데이터 삭제 및 백업데이터 S3 보관
RDS 내 테스트용 관련 테이블 제거
개발환경과 운영환경 두 셋으로 구성되어 있어 위 프로세스를 개발과 운영에서 두번 진행했습니다.
Elasticsearch 서버 인스턴스 제거
이 작업을 통해 EC2 서버 2대를 제거할 수 있었습니다.
내부에서 Elasticsearch는 AWS Open service로 사용하고 있었습니다. 그럼에도 EC2 서버내 Elasticsearch가 구현된채로 라이브되고 있었고 아무도 히스토리를 모르는 상황이었습니다.
해당 서비스는 셀러가 상품을 등록할 때 상품의 속성 정보를 분류하고 추천해주는 기능을 하고 있었습니다. 확인 결과 데이터가 쌓이고 있었고 실제 서비스에서 동작을 하고 있었습니다. 다만 그 활용도가 매우 떨어지는 상황이었고 저장한 속성 정보가 의미있게 활용되고 있지 않았습니다. 특히 정책 가이드가 있었음에도 데이터는 오염이라 할 수 있을 정도로 정제되지 않은 상황이었습니다. 이런 맥락을 공유하고 제거 승인을 받았습니다.
제거는 아래와 같은 순서로 이루어졌습니다.
상품등록에서 해당 서비스 기능 제거
운영배포해서 서비스에 이상 없을을 3일간 모니터링
서버 중지 (만일을 대비 삭제 하지 않고 중지시킴)
EC2 서버가 중지된 상황이라도 해당 서버에 사용되는 볼륨이 있다면 해당 볼륨의 유지 비용은 계속 지출되니 주의해야 합니다.
4가지의 서비스를 제거한 사례를 공유했습니다. 위 서비스가 모두 제거되기까지는 한달 정도 소요되었습니다.
AWS 비용절감을 하기 위해서는 TF성 조직 구성이 필요합니다. 개발 조직에서 독자적으로 일을 처리하기에는 어려운 지점이 많습니다. 사용하는 서비스는 그 서비스가 처음 구성할 때의 목적과 맥락이 있습니다. 그것을 모두 파악해야 하고 합의를 이끌어내야 합니다. 불필요한 리소스인지 판단하는 과정은 조직 내 히스토리를 파악해야 하고 유관부서와 얘기를 나누어야 하는 등 시간이 소요됩니다.
또한 평소에서 사용하지 않는 리소스를 모니터링하고 정리하는 관리 역할이 필요합니다.
결국 비용절감이라는 목표를 명확히 하고 오너십을 부여해야 일이 진행될 수 있습니다.
FinOps 커뮤니티에 함께 하실래요?
저는 최근 48%, $36000의 AWS 비용절감을 달성했습니다.
클라우드 비용을 효율화하고 싶은 분들, 비슷한 고민을 나누고 싶다면 제가 운영 중인 AWS-FINOPS-KR Slack 커뮤니티에 참여하세요. 실제 절감 사례, 질문, 전략 공유를 나누실 수 있습니다.
