이번 기회에 회사에서 트래픽이 낮고 앞으로 높아질 일이 없는 서비스들의 시스템 비용을 줄이기로 했다.
회사 서비스의 대부분은 aws를 통해 호스팅 되고 있다.
내가 맡은 일은 AWS elastic beanstalk에 배포 되어있는 서비스를 lightsail로 이전하는 것이다.
eb와 lightsail의 비용 차이가 트래픽이 낮은 경우에는 거의 10배 정도 난다.(omg...😱)
금방 끝나겠지 했는데... 역시나 내 예상과는 다른 그 이상의 허들이 항상 있기 마련이다..^^
1. vpc's private subnet 내부 RDS를 통해 현재 서비스의 DB가 구동되고 있는 상황에 lightsail의 server instance와 VPC 내부에 있는 RDS가 통신 할 방법이 없었다.
결국 lightsail의 값싼 instance를 사용하기 위해 lightsail에서 제공하는 DB를 써야했다. dump 파일 만들고 db마이그레이션을 진행...
2. 원래는 Application Load Balancer(ALB)를 퍼블릭 서브넷에 두고 alb를 통해 네트워크 세팅을 했다. 때문에 route53과 ALB의 연동으로 DNS 사용 및 SSL 인증 등의 문제를 매우 쉽게 처리할 수 있었다. 비용 절감을 위해 로드밸러서는 사치인 상황. 그리고 기존 route53에 구성된 호스팅 영역을 그대로 사용해야 되는 상황이었다.
ssl인증을 해야 했으며(letsencrypt) 로드밸런서를 사용하지 않고 docker를 통해 단일 인스턴스 내부에 웹 서버 및 애플리케이션 서버(was)를 구축해야했다.(docker, docker-compose, gunicorn, nginx, letsencrypt... 해야 될게 많다.)
lightsail로의 서비스 이전이 성공적으로 마무리 되었다.
몇년 전 나는 들뜬 마음으로 기존 서비스 환경인 eb의 고 가용성 및 높은 트래픽을 처리할 수 있는 시스템을 구축했던 기억이 난다.
다시 시스템을 축소하려고하니 마음이 좋지 않았다.😭
당연하게도 큰 시스템 인프라를 구축 하는게 더 대단하고 힘든일이라고 생각했었다. 하지만 이번 기회로 최소화된 인프라를 구축하는 작업 또한 못지 않게 힘든 일임을 알 수 있었다.
규모가 있는 시스템을 구축하는 경우 이미 잘 만들어진 aws의 다른 서비스를 시스템의 구성 요소로 활용 할 수 있다.(비용의 절감도 중요하지만 서비스 퀄리티가 우선시 되는 그런 상황?...ㅋㅋ 말해놓고도 이상하긴한데)
하지만 이번 경우에는 비용 절감을 위해 시스템의 거의 모든 부분들을 스스로 구현하고 세팅해야 했다.
이번 기회에 애매하게 알고 있었던 부분들에 대해서 깊게 공부할 수 있었다.