while(1) work();
article thumbnail
반응형

올해 초, 한 애플리케이션의 유지보수를 맡게 되었다.

기존 개발사에서 더 이상 유지보수를 해줄 수 없다고 했다고 한다.

해당 애플리케이션을 개발한 개발자가 퇴사하여 아무도 유지보수 할 수 있는 사람이 없다는데..

그게 말이 되는 이야기인지는 모르겠지만 뭐, 덕분에 일거리가 하나 더 생겼다.

 

소스코드는 MVC구조로 잘 짜여져 있었지만 곳곳에 개발용 코드들이 남아있었고

SQL 쿼리는 수천건의 row가 있는 테이블끼리 다중 join하는 쿼리로 짜여져 있어서

상당히 난해했고, 질의 시간도 굉장히 오래걸렸다.

 

하지만 그런 부분을 해결하는것이 문제가 아니라

과도하게 청구되고 있는 AWS 요금을 먼저 해결해야 했다.

 

일일 이용자수가 천명 미만인 서비스인데, 월 900불 이상의 요금이 청구되고 있었다.

 

AWS 아키텍처를 확인해보니

Amplify (FE 배포)

Beanstalk (BE 배포)

RDS (DB)

로 이루어져 있었고, 대부분의 요금은 RDS에서 청구되었다.

 

RDS는 db.m5.xlarge 인스턴스를 읽기 전용 복제본과 함께 사용하고 있었고, 각각 월 $400 정도의 비용이 청구되고 있음을 확인하였다. (합쳐서 $800)

 

우선, 읽기 트래픽이 많은 상황이 아니였고, 부하가 집중되는 오전 6시경(애플리케이션의 특성상 해당 시간에 부하 집중됨)에도 CPU 사용량 등 여러 지표가 높은 수준이 아니였기 때문에 인스턴스를 수직 축소하고, 읽기 전용 복제본을 제거해 보기로 했다.

 

먼저 읽기 전용 복제본을 제거하고 약 일주일간 상황을 모니터링하였다.

애플리케이션의 성능에는 아무런 영향이 없었으며, 약 400불/월 의 비용을 절감할 수 있었다.

매월 1일은 VAT가 청구되기 때문에 높게 튄다. 해당 부분을 제외하고 읽기 전용 복제본을 제거한 3월 24일부터 요금을 보면 된다.

 

 

 

이후, 다시 인스턴스를 수직 축소하여(m5.xlarge -> m5.large) 다시 한번 비용을 감소시켰다.

 

 

구체적으로 어떤 서비스인지, 그리고 왜 수직 축소와 복제본 제거를 결정했는지는

계약 내용 상 보안 유지 의무가 있어 밝힐 수 없다.

 

하지만 여전히 애플리케이션의 규모에 비해 요금이 높다고 생각하고,

부하가 특정 시간에만 집중되는 특성을 가진 서비스이기 때문에

서버리스 데이터베이스로 이전하는 것을 고려중이다.

 

반응형
profile

while(1) work();

@유호건

❤️댓글은 언제나 힘이 됩니다❤️ 궁금한 점이나 잘못된 내용이 있다면 댓글로 남겨주세요.

검색 태그