프리티어 만료
며칠 전, AWS에서 메일하나가 왔다.
벌써 AWS 프리티어를 사용한지 1년이 다되어가나보다.
아래는, 프리티어에 대한 총 사용량과, 문제의 지지난달 요금이다.
추가로, 로드밸런서의 로깅용으로 S3를 사용했는데 따로 잡히지는 않은 모습이다.
다른 프리티어 사용자분들께 여쭤보고, 포스팅도 찾아보고 해봤지만, 나처럼 요금이 많이 나오는 경우가 잘 없나보다. 만료가 되고서야 한 3~5만원정도 요금이 잡히는 것 같았다.
처음부터 많이 나오지는 않았는데, 과금이 많이 발생한 시점이 사이드 프로젝트를 프론트, 백엔드 모두 배포하여 사용하면서 개발 컨테이너, 프로덕션 컨테이너까지 분리하여 총 네개의 컨테이너를 사용한 시점부터였다.
관련 기술블로그들을 정독해봤지만, 당최 무슨말인지 이해하려면 너무 오래걸릴 것 같아서, 우선적으로 할 수 있는것만 진행해보기로했다. 학습을 해나가면서 추가적으로 적용할 수 있는 부분들을 계속 해나가면 될 것이다.
VPC IPv4 비용 절감하기
2월 1일부터, 모든 퍼블릭 IPv4주소에 대해 시간, IP당 0.005달러씩 부과된단다.. 1년동안 디폴트로 냅뒀었는데, 이제서야 확인해보니 자동 할당되는 4개의 서브넷을 확인할 수 있었다. 미리 체크하지 못해 돈이 줄줄 새고있었던 모양이다..
한달에 14달러면 2만원꼴이다.. ㅋㅋㅋㅋ
부랴부랴 서브넷의 퍼블릭 IPv4 자동할당을 해제해줬다.
ALB 사용량 줄이기
이제 남은 백엔드 컨테이너들의 과금요소를 줄여보기 위해 우선 사용량이 높은 로드밸런서부터 봐야했다. 각각의 컨테이너마다 타겟 그룹을 생성할 때, 프로덕션과 개발 모두 동일한 간격을 설정해서 사용하다보니, 힐스체크 주기가 짧아서 사용량이 많지 않았나 생각했다.
프로덕션은 짧은 주기를 가져가는것이 바람직하다고 생각했고, 가능하다면 힐스체크가 여러번 실패하면, 백업 타겟그룹으로 트래픽을 전환하는 람다를 구성해서 사용할 생각이었다.
개발서버는 프로덕션에 올리기전에 테스트용도로 사용하고 있으니, 간격을 최대한 늘려주었다.
프로젝트의 초기 인프라 구성을 간단히 그려봤는데, 그려놓고 보니 로드밸런서를 사용하는 목적에 맞지 않게 구성해서 사용하고 있다는 느낌이 빡 들었다. 따로 스케일아웃을 ALB에서 수행하지않고 nginx에서 구성해서 사용하고 있었다.
헬스 체크와, SSL/TLS의 관리를 위해(ALB생성 시 ACM을 구성) 사용하고 있었으니까.
비용 절감을 위해 ALB자체를 걷어내고 nginx에서 직접 SSL/TLS처리를 하는 것이 합리적인 선택일 것 같아 SSL/TLS를 nginx에 직접 구성하여 사용하기로 했다.
이제 로드밸런싱 관련 비용은 제로가 될 것이고, VPC 내 로드밸런서와 관련된 비용 절감도 기대할 수 있다. VPC요금이 줄어드는 것은 지켜볼 예정이다.
프론트를 버셀로 배포하기
EC2의 볼륨도 줄일겸, 프론트로의 요청-응답 사이클이 줄어들면 과금이 줄어들 것 같아 사이드의 프론트를 전부 버셀로 전환했다.
처음에 AWS에 배포하겠다고 헤매던 것을 생각하면, 버셀은 정말 딸깍 몇번이면 끝이더라, 물론 경험치가 쌓이면서 쉬워진 것도 없지 않겠지만, 로그인 후 깃 레포를 등록하고 기존 Route53 도메인을 사용하기 위한 세팅만 해주었는데 끝이났다.
route53 도메인을 사용하기 위해 아래 블로그를 참고했다.
마무리
언젠가 NestJS 최신버전에서 무엇이 달라졌나요? 라고 물었던 질문에 쭈뼛거리면서 "아마 Node 12버전 이하는 지원하지 않을걸요?" 라는 대답을 했다.
저런 질문을 받을 당시에는 그냥 넘어갔는데, 이 포스팅을 하는 내내 내가 사용하고 있는 모든 기술들에 지속적인 관심을 가지고 변경된 것이 무엇이 있는지에 대해 무관심했구나 라는 반성을 하게 된다. 가야할 길은 멀지만, 앞만 보고 달리는 것이 아닌 지금 내 주변을 단단하게 다질 필요가 있다. 그래서 더 좋은 경험이었다고 생각한다.
언젠가 다른 이슈로 비용절감 포스팅을 더 할 것 같아 (ex. 람다) 제목에 색인을 남겨둔다.
References.
2023.04 ~ 백엔드 개발자의 기록
포스팅이 좋았다면 "좋아요❤️" 또는 "구독👍🏻" 해주세요!