[슬축생 프로젝트] 6. AWS로 이사 시도.. 하지만 어림도 없지

개요

배포를 해서 약 100명 정도 되는 사람들이 사용을 한지 약 3개월 정도 되어 가고 있다, 시간이 참 빠른것 같다. 

중간에 이런저런 이슈가 있었지만 크게 문제가 되는 부분은 없었고 무난하게 지속적인 기능 추가를 해 나가면서 운영을 했다.

 

그러다가 나는 이런 생각을 해보았다. 아 솔직히 지금 인프라 아키텍쳐가 너무 짜쳐놓은것 같다.. 이거 한번 제대로 설계 해볼까?

 

현재 많은 회사들이 AWS에 서비스를 올려놓고 사용하고 있다. 나도 AWS의 서비스들에 고등학생 시절부터 굉장히 관심 많았지만 고2때 EC2 프리티어를 사용하다가 3만원인가? 요금이 나온것이 그렇게 공포로 기억에 자리 잡아서 그 뒤로 AWS 공포증이 생겨 사용하지 않았다

 

그렇게 계속 공부를 하면서 AWS를 계속 외면할 수는 없으니까 이번에 AWS로 이전해보면서 공부 해보자~ 해서 과금 이유, 프리티어 제한등에 대해서 열심히 공부를 하고 프리티어 내에서 사용할 수 있는 서비스들로 아키텍쳐를 다시 설계하게 된다. 

기존 서버 아키텍쳐

기존에는 위처럼 프론트엔드는 가비아 클라우드, 백엔드는 오라클 무료 클라우드를 사용해서 그 안에 다 꾸겨놓았다...

처음에 이렇게 구성한 이유는 당장 과금 걱정 없이 사용할 수 있던 성능 좋은 클라우드가 있기도 했고 서비스를 오픈했을때 아무리 타켓팅된 사용자들 이라고 하지만 트래픽 예측이 안되어 프리티어를 사용할 수 있을까 고민도 되서 초반엔 이렇게 구성하게 되었다.

 

서비스를 오픈한지 시간이 좀 지나고 계속해서 개발을 진행하면서 공부를 하는 동안 여러가지 강의들이나 유튜브 채널을 보면서 다른 백엔드 개발자들의 이력서들도 보게 되었다. 대부분 포트폴리오의 프로젝트 소개에 aws를 이용한 여러 아키텍쳐들을 구성하였다.

 

문득 나도 여러가지 기술 스택들 (redis, elk등..)과 aws 서비스(S3, elastic cache등..)을 사용해보고 싶다는 생각에 좀 설레게 되었다.

하지만 아무리 직장인이라고 한들 예상되지 않는 aws요금은 내게 부담이였고 최대한 프리티어내에서 아키텍쳐를 설계해보게 된다.

새로 설계한 서버 아키텍쳐 (AWS 프리티어 활용)

AWS 서비스로 새롭게 아키텍쳐를 설계해봤는데 프리티어의 한도를 명확하게 이해하고 모두 프리티어 안에서 설계한것이다.

제일 먼저 신경쓰였던 부분은 기존의 코드 자동 배포였다, 기존에는 jar를 빌드하고 sftp로 서버로 옮겨서 수동으로 재시작했다.

그런 기존의 불편함 때문에 Github Actions, S3, Code Deploy를 이용해서 새로운 자동배포화 플로우를 설계했다.

 

그리고 프론트단의 php 클라이언트도 아마존 라이트세일로 옮기려고 했다, 기존의 가비아 클라우드를 사용하는것이 맘에 안 들었다.

당연히 서버는 EC2로 마이그레이션하고 RDS과 Mysql 조합을 활용해서 기존의 서버 아케텍쳐를 그대로 마이그레이션 하였다.

 

또한 이참에 항상 써보고 싶었던 redis를 사용하고자 aws에서 제공해주는 Aws Elastic Cache라는 Sass 형태로 redis를 사용하려 했다.

현재는 JWT를 재발급 없이 만료되면 세션이 끊어지는 방식으로 하고 있는데 redis를 도입하면서 토큰 재발급까지 구축해보려고 했다. 

로그 부분을 좀 개선하고 싶어서 elastic search를 적용해보려고 생각했었다. 마침 프리티어에 Sass 형태로 제공해주는 서비스가 있었다. 기존에는 컨트롤러에 로그를 덕지덕지 붙여서 CLI로 확인하곤 했는데 로그 형식을 정해서 AOP로 묶어서 다 elastic search로 보내고 ELK 스택을 모두 활용해서 키바나로 시각화를 하거나 따로 데이터들을 긁어와서 시각화를 해주는 웹을 만들어서 개선해볼까 생각했었다.

 

마지막으로 AWS하면 제일 써보고 싶었던 CloudWatch였다. 데이터베이스의 슬로우 쿼리 등등 여러가지 AWS 서비스들의 이벤트 알림을 수집하고 슬랙이나 기타 써드파티 알림툴로 포워딩해주는 서비스이다. 나도 아마 AWS를 사용했으면 디스코드 로거나 기타 알림 시스템을 직접 안 만들지 않았을까? 싶다.

다 준비해놓고 AWS로 옮기지 못한 이유..

사실 배포 자동화까지도 이미 다 구성해놓은 상태였다, S3 버킷을 만들고 이런저런 role들을 생성하고 github에서 main으로 커밋하면 자동으로 ec2에 배포되어서 기존 프로세스 정지 후 실행까지 모두 다 구성해놨었다. 구성한 다음날 aws 콘솔에 들어와서 프리티어 사용량을 보고 있는데 유난히 눈에 띄는 반절 정도 소모된 항목이 있었다. 항목의 이름은 AWS Data Transfer였다. 깜짝 놀라서 여기저기 검색해본 결과 AWS는 달에 약 100GB 정도의 네트워크 트래픽을 무료로 지원해준다고 되어 있었다, 한마디로 그 이상을 넘기면 요금이 과금되는것이다.. 그래서 당장 현재 사용하고 있는 오라클 클라우드에 들어가서 이번달의 네트워크 트래픽 용량이 어느정도인지 확인해보았다. 

서비스 직후 지금까지 약 2테라 정도의 네트워크 트래픽 용량을 사용된것을 확인할 수 있었다. 난 솔직히 이 정도는 아니라고 생각이 들었다. 내가 오라클 모니터링 툴을 잘 사용 못하는 것 일수도 있고 나중에 모니터링 시스템을 붙여서 한번 트래픽 분석을 따로 해봐야할것 같다.

 

사용자가 100명 남짓하고 DT(체류시간)도 짧은 서비스인데 도대체 어떻게 해야지 세달만에 2테라의 네트워크 트래픽이 쌓인건지 아직은 트래픽에 관한 감이 없어서 잘 모르겠다. 다행인 부분은 오라클은 달마다 1테라씩 무료로 제공해줘서 오라클에서는 별도의 과금이 없었다.

마무리하며

배포 후 3명뿐인 프로젝트팀 인원이 7명까지 증원되기도 하였고 (여전히 친구와 나랑 둘이 개발하지만)  기타 여러가지 일들이 많이 겹쳐서 블로그에 신경을 많이 못 썻었다. 슬로우쿼리나 여러 알림 처리한 부분에 대해서 따로 글을 쓰고 싶었는데 조만간 정리해서 다 업로드 할 예정이다. 현재는 멘탈이 좀 안 좋아서.. 축구하다가 십자인대가 완전 파열이 나서 곧 수술한다 ㅎㅎㅎㅎ... 하아..