RadDog 서버는 원래 self-hosted였는데, 집 인터넷이 끊기거나 / 집 컴퓨터가 꺼지면 당연히 서버 접속이 안되는 일들이 생기기에, 발로 짠 코드를 그대로 AWS에 옮겨놨었다.
그리고 첫 1년은 프리티어니까, ec2랑 rds 제일 작은 인스턴스를 띄워서 잘 썼었는데...
문제는 1년 지난 뒤 부터, 과금이 되는걸 알면서, 아직까지도 귀찮아서 그냥 두고 돈을 내고 있었단 것이다.
한 달에 치킨 3마리가 날라가고 있었는데 말이다..
사실 RadDog 서버가 해 주는 일은 1) 바코드에 매칭되는 캐싱된 결과값 보내주기 (i.e., DB 읽기) 2) 바코드가 캐시에 없는 경우 검색 로직을 이용해 data fetching + caching 하는 일 밖에 없었다. 그러면 굳이 EC2 + RDS를 써야 하느냐... 전혀 아니었다. 그리고 AWS는 적당히 쓰면 평생 무료인 대체 가능한 두 서비스가 있으니..
RDS --> DynamoDB, EC2 --> Lambda로 대체가 가능하다. 그래서 이 것들을 각개격파 하기로 했다.
RDS --> DynamoDB Data Migration
사실 DB 키 구조가 PK밖에 안쓰는 매우 단순한 구조여서 RDB --> NOSQL migration은 식은죽 먹기였다. 그냥 1) 데이터 json으로 덤프 떠 놓은 다음에 (중간에 뻗으면 또 읽어야 하니...), 2) PK를 파티션키로 잡아서 밀어넣어주면 된다. 올릴때는 조금 인텐시브하게 쓰니까, provisioning 꺼놓고 autoscaling으로 해 주면 금방 밀어넣을 수 있다. DB 크기가 한 500메가밖에 안돼서..
EC2 --> Lambda 대체
요건 좀 tricky할 수 있는데, 일단 DB access하는 코드를 다 바꿔야 하기 때문이다. 그 외에는 사실 크게 코드를 고칠게 없었다. 그냥 api별로 잘라서 lambda function 하나씩 만들어주고, api gateway에 붙이면 끝. 간만에 API 작업하니까 CORS때문에 잠시 헤맸다. Lambda function에서 apigateway로 result 보내줄 때 header에 allow-cross-origin을 직접 넣어줘야 하더라. (링크) 그 외는 별거 없었다.
그렇게 해서, dev api에다가 deployment 해서 테스트 한 후, 문제 없음을 확인 했다. 그리고 production api에 deploy 후 잘 도는지 확인까지 완료!
기존에 있던 ec2, rds 인스턴스는 일단 스탑 시켜놓고 서비스에 지장이 있는지 경과를 봤다. 그래도 트래픽이 아직 좀 들어오기에, 한 한 시간동안 문제 없어보이면 terminate시켜버리면 된다.
한 시간정도 삽질하니 이렇게 월 5만원이 아껴지는데 난 도대체 얼마나 게을렀던 것인가... 반성하고 돈 좀 아끼면서 살아야겠다. 흑흑 ㅠㅠ
