[티챠] AWS 배포 후기

작업 내용

https://github.com/ticha-ai/ticha-BE/issues/17

✨[Feat] AWS 배포 · Issue #17 · ticha-ai/ticha-BE

 

✅ TODO

• 팀 AWS 계정 설정
• Github Actions 설정
• AWS EC2 인스턴스 생성
• EC2 서버에 도커 설치
• 개발환경과 배포환경의 분리
• GitHub Actions에서 EC2 자동 배포
• FastAPI + MySQL 컨테이너 실행
• #23📢 Notes

✅ 배포와 데이터 베이스(완료)

• AWS EC2에 서버 및 데이터베이스를 배포하는 것으로 진행 중
• 비용 문제 때문에 데이터베이스는 도커를 통해 EC2 서버에 설치 진행
• 향후에 RDS 전환 시 별도로 .env 파일 설정 등을 변경을 해야함

✅ git secrets 설정(완료)

| 환경변수를 추가할 때 로컬에서는 .env에 반영하되 통합 및 배포시 github secrets에 추가해야합니다!

• .env 파일을 ec2에서도 생성해야 서비스가 온전히 작동함
• github secrets 기능을 통해 비밀키들을 업로드
• deploy.yml에서 github secrets들을 통해 자체적으로 ec2에서 .env 파일을 생성할 수 있도록 설정 변경

✅ oauth 수정을 해야함(완료)

| 로컬과 테스트 배포 환경 모두 oauth 접근이 가능하도록 수정필요

• 현재는 로컬환경에서 작업을 할 때를 전제고 oauth 로그인 및 회원가입 설정을 해놨음
• 배포환경을 같이 구축한 결과 코드 수준으로 배포 url에서 접속이 가능하도록 수정해야함

✅ 인프라 구조 변경

| 백엔드 로컬 개발에서는 도커를 활용하되 테스트 배포환경에서는 EC2와 RDS를 함께 사용

• 현재 AWS에서 임대한 인스턴스는 프리티어 버전으로 t2.micro이다
• t3.micro는 램이 1GB에 불과하여 Docker, MySQL, FastAPI까지 돌리게 되면 서버가 죽는다.
• 따라서 데이터베이스는 아마존에서 제공하는 rds t3.micro 프리티어를 임대하여 환경을 구축하였다.

---

회고

배포 성공....

 

로컬환경과 배포환경은 처음부터 정하는 것이 좋다는 것을 경험하게 되었다. 그리고 CICD 플로우도 정해놓고 개발하는 것이 좋다는 것을 경험하게 되었다.

기획단계 때만 해도 자원이 빵빵한 내 노트북과 친구들의 환경을 보고 배포환경도 마찬가지라고 생각했다. 이는 틀린 생각이었다.

돈이 없는 자는 손발이 부지런해야한다. 이는 AWS 프리티어를 사용할 때도 마찬가지였다.

EC2와 RDS 프리티어를 임대했다. 처음에는 EC2 서버 하나에 FastAPI 서버, 도커, MySQL 컨테이너를 올렸더니 서버가 EC2 서버가 죽어버렸다. CPU가 100%로 치솟아버리더니 마치 수화기 건너편에 무서운 귀신에게 잡아먹힌 주인공처럼 묵묵부답이었다.

EC2 서버를 강제 중지 후 실행을 시켰더니 다시 EC2가 돌아왔다. 아마 이런 심폐소생술 같은 임시방편은 내 소중한 서버를 혹사를 시켰으리라. 그래서 로컬환경과 배포환경을다르게 구축해야겠다는 생각이 들었다.

 

내 맥북은 램이 8G였기에 EC2보다 8배나 더 센놈이었다. 따라서 EC2 서버의 체급에 맞게 부하들을 분산시킬 필요가 있었다.

 

나를 포함하여 내 동료들은 모두 직장인들은 아니었기에 금전적인 부담을 지기에는 힘들었다. 다행히 최근에는 다시 정책이 바뀌어서 그런지 아마존에서 RDS 프리티어를 제공하고 있었다.

 

RDS를 임대하고 EC2와 통신을 할 수 있도록 보안규칙을 세팅하였다. 로컬에서는 다른 프로그램과의 충돌을 위해 MySQL 포트를 3309로 했지만 이번에는 관례대로 3306으로 했다. 챗지피티의 도움 덕분에 환경설정들은 막힐 때마다 물어보면서 빠르게 해결해나갔다.

 

하지만 GPT는 정보를 탐색하는 시간을 줄여줄 뿐, 결국 나는 맞는 질문을 해야 맞는 답을 얻을 수 있고 맞는 답을 실천을 해야 원하는 결과를 얻을 수 있었다.

GPT가 정보 탐색에 있어서 시간을 줄여주는 녀석이라는 것이 엄청나지만 환경을 구축하고 손발이 되어 뛰어다니는 것은 결국 나의 몫이었다. 물론 GPT가 없었으면 개발 기간은 적어도 10배는 늘어났으리라....

하여튼 이번에 서비스 인프라를 어쩌다 보니 맡게 되면서 자동통합과 자동 배포 및 로컬과 배포 환경의 차이 및 프로그램 자체가 주는 부하를 고려해야한다는 것을 배우게 되었다. 코드의 균일성 자동화, 스크립트를 활용한 CICD 자동화, 클라우드를 활용한 원격 서버와 데이터베이스 구축, SSH 연결 모두 의미 있는 경험이었다.

 

 

아 그리고 혹시나 해서 첫 ec2 인스턴스에 등록한 pem키를 다른 인스턴스에 그대로 사용하려고 하니까 보안누수가 났다고 AWS에서 알람을 보냈다. 나처럼 쉽게 가는 마음으로 별도의 서버로 하나의 pem키를 공유하려는 보안을 마치 콩밥에서 콩 빼는 사람이 되지는 말자.

 

 

이제 남은 것은 pdf 형태로 이뤄진 문제지 데이터를 가공해서 데이터베이스에 넣고 RAG 환경을 구축하여 사용자가 답안지와 질문을 통해 AI와 문답하는 시스템을 만들어야하는데... 이번 주 안에 되겠지.....?