클라우드 비용 절감기, 월 천만 원을 절약한 스케일 다운

인프라 다이어트

회사는 계속 성장해 왔다.

많은 도전을 해왔고, 그만큼 레거시가 쌓였다.

 

더 이상 운영하지 않는 서비스도 많고,

기대에 못 미치며 운영되고 있는 서비스도 많다.

 

이번 클라우드 비용 절감기에선 그런 레거시 인프라를 정리하여,

운영 비용를 크게 절감할 수 있었던 경험을 소개하고자 한다.

 

1. 월 천만 원을 절약한 스케일 다운

2. 70억 개의 무의미한 데이터, Atlas MongoDB 부수기

3. AWS RI (예약형 인스턴스) 사용

 

AWS 자원 정리

가장 먼저 사용하지 않는 AWS 자원을 정리했다. 

더 이상 사용하지 않고 있던 테스트 용 리소스부터,

타겟 그룹이 없는 LB 들이나 연결되지 않은 EIP 같은 자잘한 낭비들을 제거했다.

사용하지 않는 CDN을 내리고, S3를 압축하여 사내 공용 드라이브에 정리했다.

 

문제는 남겨야 하는 서버들도 있다는 것이었다.

클러스터나 가상 머신을 전부 내리면 편하겠지만, 일부는 최소 사양으로라도 운영을 유지해야 했다.

 

주로 아직 서비스 종료 공지가 안된 경우이거나,

사용자는 없지만, 회사 간의 계약 문제로 남겨야 하는 리소스들이었다.

 

스케일 다운

최소 사양으로 운영을 지속해야 하는 서비스들을 분류했다.

그리고 그들을 다시 띄울 수 있는 방법을 공부했다.

 

1. BitBucket 파이프라인, Github actions 코드
2. k8s Deployment 코드
3. DockerFile, Docker compose 파일
4. 흐릿하게 남아있던 Readme의 설명서

 

어떻게든 다시 띄울 수 있는 방법을 찾아갔다. 

막상 또 해보니까 되더라.

 

도저히 빌드 환경 변수를 못 찾았던 프로젝트가 한 개 있었는데,

k8s deployment에 ECR에서 끌어다가 배포하는 것을 확인하고, ECR의 컨테이너 이미지로 실행하는 것으로 해결했다.

코드 수정이 불필요한 프로젝트라 천만다행이었다.

 

서비스 유지에 필요한 최소 사양의 EC2를 고르고, 그 인스턴스에 서비스를 몰아 두었다. 

유지하는 서비스에 필요하지 않은 서비스들을 내릴 수 있었다. (특히 MSK, ES..)

가상 머신 스펙과 개수를 크게 줄일 수 있었다.

 

서비스 간 의존 확인

서비스 간 의존을 꼼꼼히 확인했지만, 그래도 서비스를 내릴 땐 어쩔 수 없이 무서웠다.

그래서 더 꼼꼼하게 테스트하려 했다.

 

같은 VPC 안에 새로운 EC2를 만들어 배포했다.

기존 Ingress(ALB)에 새로운 EC2를 엮는 것이 아니라, 아예 새로운 ALB를 따로 두고 테스트 도메인을 묶었다.

테스트 도메인에서 정상 동작을 꼼꼼히 확인했다.

 

 

서비스 간 연관도 다시 확인했다.

새로 배포한 서비스들이 기존 클러스터의 서비스를 사용하고 있는 것은 아닌지 더블 체크했다.

 

ACL에 IP DENY 정책을 추가해서, 기존 Subnet에 새로 배포한 서비스들이 접속하지 못하게 막았다.

MSK나 ES 같은 서비스들에도 마찬가지로 연결을 제한하고, 정상 동작을 확인했다.

인지하고 있었던 RDS를 제외한 서비스 간 연간은 없었다.

 

DNS 레코드 갱신

마지막으로 Route53에서 도메인 레코드를 새로 생성한 ALB로 전환해 주었다.

 

Route53는 GSLB로 가중치 기반 라우팅이 가능하다.

계획에선 점차 라우팅 가중치를 늘리는 방향이었지만, 실제로는 한 번에 100% 새로 구성한 서비스로 전환되도록 설정했다.

 

 

다만, 기존 자원들은 DNS 캐시를 고려하여, 반나절 정도 유지 후에 제거했다.

기존 자원들과 새로 배포한 서비스가 공존하는 기간이 발생하지만, 문제 되지 않음을 미리 생각하고 있었다.

 

책임

그 밖에 AWS 자원, 써드 파티 정리가 많았고, 

이번 작업으로 월에 최소 천만 원의 서버비를 절감할 수 있었다.

너무 속 시원한 작업이었다.

 

점점 코딩 잘하는 사람이 좋은 개발자가 아니라는 생각이 많은 요즘이다.

어쩌면 시야가 넓은 사람일 수 있고,

어쩌면 컨텍스트 스위칭이 빨라서 여러 업무를 동시에 쳐내는 사람일 수 있고,

아니면 문제 대처가 안정적인 사람일 수도 있을 것 같다.

 

그리고 이번 경험에서는 누군가는 해야만 하는 일에 앞장서고,

그 일에 책임을 지기 위해 더 많이 고민하는 사람이 좋은 개발자는 아닐까 생각해 봤다.

 

회피하는 사람은 매번 회피만 하고,

도전하는 사람은 본인 말에 책임을 지기 위해 더 성장하는 것처럼 보였다.

 

나는 앞으로도 도전하는 사람이 되고 싶다.