Today I Learned ...
오늘은 우리 서비스를 AWS 클라우드를 통해 배포했다!
🖥️ 번쩍 팀프로젝트 #27
우리 서비스는 프론트엔드와 백엔드 모두 개발하였는데, 프론트엔드는 편의성을 위해 vercel을 사용하고, 백엔드는 AWS 클라우드를 사용하기로 하였다!
위와 같은 아키텍처대로 배포를 진행했다!
사실 처음에는 인터넷 게이트웨이, NAT 게이트웨이 모두 사용하지 않고 간단하게만 배포하려고 했었다.
오토 스케일링도 사용하지 않을거라 ALB도 사용하지 않으려고 했었다.
하지만, Vercel에서 채팅 관련 내용을 배포하기 위해서는 HTTPS를 사용해야만 했고, 그래서 ACM을 통해 HTTPS 인증서를 발급받았다.
그런데, 이 인증서 등록이 ALB를 통해서 진행해야 하더라.
그래서 오토 스케일링을 사용하지 않음에도 불구하고 ALB를 사용해야만 했다.
우리는 서버들을 모두 private 서브넷 안에 배치시켰는데, 이때 docker를 통해 필요한 내용들을 설치하기 위해 22번 포트를 열어야만 했다.
그래서 처음에는 bastion 서버를 운영하여, bastion 서버를 통해 필요한 서버들에 접근할까 생각해보았지만,
우리처럼 소규모 프로젝트에서 bastion 서버까지 추가하는 것은 비용 낭비라고 생각해 다른 방법들을 찾아보았다.
AWS에서 SSM, Systems Manager라는 인프라를 중앙에서 관리할 수 있도록 하는 운영 허브를 제공하더라.
이를 통하면 SSH를 위한 22번 포트를 열 필요 없이 인스턴스에 접속할 수 있게 된다.
그래서 SSM을 도입하기 위해 NAT 게이트웨이를 통해 private 서브넷이 인터넷에 통신할 수 있도록 열어주고, SSM을 위한 IAM role을 만들어 EC2에 할당하였다.
MongoDB에 대해서는 ec2에서 도커를 통해 사용할지, Atlas를 사용할지 고민했는데,
우리 서비스에서는 채팅 기능을 위해서만 MongoDB를 사용하기 때문에 비용 측면에서는 Atlas도 큰 부담이 되지 않을 것이라 판단하였다.
그렇다면 EC2를 통해 직접 관리하기보다는 Atlas에 운영을 전부 맡겨버리는 편이 낫겠다고 생각하여 Atlas를 도입하기로 결정하였다.
우리 팀이 작성한 코드는 깃허브를 통해 업로드해두었다.
GitHub 보러가기
🙃 오늘의 느낀점
사실 인프라 설계를 공부하며 AWS에서 nginx와 tomcat을 통해 서버를 띄워본 적은 있었다.
하지만, 그때 공부했던 내용들은 web 서버 2대, was 서버 2대, rds를 가지고 정말 간단한 3-tier 환경을 구축하는 것 뿐이었다.
그래서 이번에 redis와 es를 도입하며 어떻게 설계하는 것이 좋을지 정말 많이 고민하였다.
그래도 이렇게 하나씩 찾아보고, 고민하며 구축해가는 과정이 정말 재미있었다.
