[AWS 트러블슈팅] AWS 운영 비용 절감하기

1. 들어가며

1.1 히스토리 ( 썰풀기 )

이전까지는 "인프라는 팀장님!" 이라는 수식어가 붙어 있었던만큼 해볼 기회가 많이 없었다.

하지만, 기존 인력들이 대거 퇴사하고 내가 서버쪽에 모든 업무를 담당하게 되고 직무가 벡엔드 개발자로 변경됨에 따라 자연스럽게 AWS 서비스들의 운영과 관리등의 업무도 내 담당이 되었다.

 

 

이제는

서버에 문제가 생기면, 

CS 가 들어오면,

신규 기능 추가 요청이 들어오면,

새로운 이슈가 생기면 

 

내 이름이 노티되기 시작했다. 

 

1.2 다시 현재로

전 담당자분이 퇴사하시기전까지는 한달에 약 5**만원 정도의 AWS 비용이 청구되고 있었다.

예전에 아무것도 모를때는 이 비용이 당연한것인줄 알았는데, AWS 서비스들을 공부하고 현재 우리 회사 서비스들의 유저수/트래픽 대비 너무 과다한 비용이 발생하고 있다는것을 알게 되었다.

 

2. 비용 절감 작업

2.1 목적 정의

이번에 투자 시장이 얼어붙으면서 회사에서도 기존에 예상한 런웨이 기간보다 버터야하는 기간이 길어진것 같았다.

현재 가장 많은 비용이 발생하고 있는것은 EC2/RDS 였고 이에 대한 비용 절감이 이번 작업의 목표였다.

 

2.2 작업 정의

작업을 진행기 앞서서 체크리스트를 작성하여 체크해야되는 부분들을 정리한뒤 작업을 진행했다. 

메인 절감을 AWS 비용에 있어서 큰 비율을 차지하는 EC2/RDS 위주로 작성되었지만, S3, Config 등도 비용 절감 작업에 포함되었다.

 

1. 작업전 EC2 일별 발생 비용
2. 작업전 RDS 일별 발생 비용
3. 동작하고 있는 EC2 인스턴스 정보
4. 동작하고 있는 RDS 클러스터 ( 하위 인스턴스 ) 정보
5. 기타

 

3. 작업 내역

3.1 EC2

청구 비용의 비율이 제일 큰 서비스만큼 현재 구성되어 있는 인스턴스상에서도 문제점들이 많았다.

 

첫번째는 과거 MVP 프로젝트 또는 IR 발표를 위해 임시로 생성한 EC2 인스턴스들이 아직도 구동되고 있었다. 인스턴스 타입 ( 예시 : xlarge, large, medium 등 ) 은 낮은편에 속해 있어 비교적 비용 부담이 적을 수 있다고 생각 할 수 있지만, 그 갯수가 약 10개 가량되었다. 

 

두번째는 앞서 설명한 EC2 들에 EIP, EBS 등이 추가되어 비용이 발생하고 있었다는점이었다.

 

세번째는 베타 서비스 과정에서 외국 region 에 새롭게 설정해놓은 EC2 인스턴스들이 현재는 사용되지 않는 않고 있었다.

 

네번째는 굵직굵직한 비용을 발생시키고 있는 인스턴스 타입 ( 예 : large, xlarge ) 의 인스턴스들의 경우에는 쉽게 건들 수 없었는데

그 이유는 몇몇 인스턴스에서는 어떤 서비스/서버가 구동되고 있는지 그 누구도 모르기 때문이다. 이 때문에 해당 인스턴스 타입 변경 이후 재부팅시 발생할 수 있는 사이드 이펙트를 누구도 알 수 없었다. 

일부는 내가 작업한 프로젝트이기 때문에 알고 있지만, 내가 입사하기도전에 작업이 마무리된 프로젝트들도 있기 때문에 Github 에 업로드 되어 있는 프로젝트들의 Github Action CI/CD 의 workflow 파일을 일일이 확인해가며 확인한뒤 작업을 진행했다. 

 

 

3.2 RDS

시작한지 얼마되지 않은 서비스들의 경우 상황에 따라서 '돈' 으로 해결하는 경우가 있다.

특히 슬로우 쿼리 같은 부분은 서비스 초기에는 발생하지 않고 어느정도 규모가 커지고 데이터 레코드가 쌓이기 시작하며 문제가 발생하는 경우가 많기 때문에 RDS 의 CPU 점유율을 모니터링하고 있다가 CPU 피크가 발생할때 작업을 진행한다. 이를 위해서 slack/teams/discord 등에 채널 훅을 사용하여 슬로우 쿼리 모니터링 알림을 보내고 있다. ( 이를 위해서는 슬로우 쿼리 필털이 기준을 설정해야 하는데 보통 3 ~ 5초 정도를 설정하는것 같다. )

 

우리 회사도 서비스 출시 이후 급격히 몰리는 트래픽과 성능상 이슈 처리에 대한 임시방편으로 현재 운영 환경에서 사용하고 있는 RDS 인스턴스의 타입을 ( 예시 : xlarge, large 등 ) 수정하여 대응한적이 있다.

 

변명아닌 변명을 하자면 이렇게 하지 않으면, DB 는 CPU 점유율 99% 찍어놓은 상태에서 추가적으로 계속해서 서버에서 요청을 받는다. 

DB 는 해당 요청을 처리하여 데이터를 추출하지 못하기 때문에 서버의 요청에 대해서 데이터를 반환하지 못하게 되는 악순환이 지속된다.

 

따라서 

 

1. 서버 장애 공지

2. 사용자의 API 요청 제한

3. DB 인스턴스 타입 변경

4. 서버 재부팅 

5. 개발자 테스트

6. 서비스 운영 재개

7. 기타

 

등등의 방법으로 진행한다.

 

이야기가 잠시 다른데로 샜는데... ( 이거에 대해서 트러블 슈팅했을떄가 떠올라 울컥했다... )

다시 본래의 이야기로 돌아와 이야기를 해보자면, 앞서 설명한 이슈들로 인해 일시적으로 한사이즈 업그레이드 했던 RDS 인스턴스 타입을 이슈가 해결된 이후에 원복을 하지 않은 상태였다. ( 물론 이와 관련해서도 여러가지 히스토리가 있다. )

 

그래서 이번 작업은 RDS 의 인스턴스 타입을 다시 원복하고 운영 서비스를 재개했을때의 RDS 의 CPU 점유율을 모니터링하면서 

혹시나 발생할 수 있는 사이드 이펙트들을 대응하였다. 

 

 

3.3 Config

Config 와 관련하여 불 필요해 보이는 규칙들이 많이 설정되어 있었다..

이게 1초당 약 10개 정도가 처리되는것을 확인 할 수 있었는데.....

자세한 설명은 생략하겠다...

 

3.4 Nat Gateway

외주 개발자분과 함께 기존에 운영되고 있는 서비스 마이그레이션 작업을 진행하였다.

이 과정에서 AWS 인프라도 전면 리팩토링 되었는데 VPC 내 설정한 Nat Gateway 과도한 비용이 발생하게 되었다.

 

Terraform 으로 AWS 인프라를 작업한 개발자분도 이렇게까지 비용이 많이 발생할것이라고 미쳐 생각하지 못하신것 같았다. 

 

이거 하나만으로도 1월 청구 비용이 3/1 줄어든다. ( 1월에 이것 떄문에 비용이 많이 나와 현재 AWS Support 에 문의글 넣어놓은 상태이다... ) 

 

 

 

 

4. 작업 결과

AWS cost explorer 에서 일별 비용을 뽑아 결과를 비교해보았을때 3/1 정도로 비용이 절감된것을 확인 할 수 있었다.

아직은 Saving Plan 을 사용하지 않은 상황인데 Saving Plan 을 적용하였을때 추가적인 비용 절감 효과를 볼 수 있을것 같다.

cost explorer

 

 

4. 마무리글

지금까지 AWS 서비스 비용을 지출한게 내 돈이라는 생각을 해보면 머리가 아찔해진다...

 

회사에서 비용 절감 작업을 맡아 진행하게된 업무였지만, 이번 업무를 통해서 각 서비스별 비용 산출 방법 및 서비스의 인스턴스 타입별 특징 및 Saving Plan/RI 등 비용절감에 대한 다양한 개념을 학습할 수 있었다. 

 

나도 내 서비스를 만들떄 이런 경험들에 유의하며 작업해야겠다는 생각이든다...

그때는 회사돈이 아닌 내돈이니까..

 

더불어 개발분야는 공부할께 끝도 없음을 새삼 다시 느낀다. ( 개발, DB, 업무 도메인, 인프라, 네트워크등... 이제는 비용까지... )

 

 

5. 참고자료

https://aws.amazon.com/ko/blogs/korea/10-things-you-can-do-today-to-reduce-aws-costs/

https://calculator.aws/#/

https://aws.amazon.com/ko/ec2/instance-types/