[RD] 레시피 저장소 프로젝트 회고

wodnr_P·2023년 6월 20일

기록하는 시기가 조금 늦었지만 2023.02 ~ 2023.05 까지 약 3개월간의 프로젝트를 하면서 배운점을 기록에 남기고자 정리해봅니다.
~~3월 중순 이후 부터 사실상 한달 반 이상은 다른 공부하느라 프로젝트를 제대로 진행하지 않았던점은 반성중...~~

1. 프로젝트 소개

개발 인원: 1명 (개인 프로젝트)
https://github.com/wodnrP/Recipe_project

RD 레시피 저장소 프로젝트는 요리 애호가, 요리가 취미인 사람들을 위해 개발한 간편 레시피 저장 및 공유 앱 입니다.

❓개발 동기

요리를 취미로 가지면서 가장 불편했던 점이 레시피를 찾기 위해서는 여러 웹페이지를 찾아 다녀야 하고, 각종 광고 혹은 판매 물품들이 함께 보여서 복잡하고 번잡하다는 느낌을 받았습니다. 그래서 이 문제를 해결해보고자 음악 플레이리스트 처럼 간편한 RD 레시피 저장소를 기획하고 개발했습니다.

⭐️ 구현 목표

레시피 작성과 공유를 위한 레시피 CRUD 기능, 조회수 확인을 위한 조회수 기능, 사용자 마다 가지는 레시피 저장소 기능(장바구니와 유사), 검색기능과 API 요청시 item수 제한 기능, 실제 서비스 확장성을 고려한 서버설계 (컨테이너 형식의 배포, https 배포 등)

🛠️ Skill

환경
- Mac OS, VisualStudioCode, Git, Github

FE
- FlutterFlow

BE
- Python, Django, DRF, AWS RDS(MySQL 8.0)

Server
- Docker, Nginx, Gunicorn, AWS EC2, AWS S3 (이미지 저장용), Route53

기타
- Notion (API 명세, 공부 기록용), Figma (UI 설계)

백엔드는 Django Restframework로 API개발을 진행하였고, 프론트엔드는 Flutter 기반의 드래그앤드롭 tool과 커스텀 flutter 함수를 활용하여 개발했고 Android apk 파일을 배포하여 사용 테스트까지 마쳤습니다.

백엔드를 배포한 서버는 AWS EC2 ubuntu 환경에서 Docker로 Web server와 Django WAS, DB를 올려 Docker-compose로 build를 진행 했으며, 보안을 위해 AWS의 Route53과 로드밸런서를 활용하여 HTTPS 배포까지 마무리 했습니다. 배포 서버는 현재(2023.06.20)까지 가동 중 입니다.
BE 배포 서버 : https://rdproject.site

기타 API 명세, ERD 등의 설계는 제 Github에 정리해뒀습니다.

Why? 기술 스택 선정 이유

Django : 익숙한 프레임워크이기도 하고, 빠른 개발을 위해 django-restframework를 채택했다.
gunicorn : uWSGI를 활용해본 경험이 있으나 Docker 설정이 다소 복잡했고, 인터페이스 자체가 무거워서 리소스를 크게 잡아먹을 필요가 없음을 판단하여 보다 가벼운 WSGI인 gunicorn을 채택했다.
Nginx : 실제 서비스를 할 경우를 대비해서 대용량의 트래픽이 발생할 수 있다고 판단하여 Apache보다 대량 접속에 유리한 Nginx를 채택했다.
MySQL : 실제 서비스를 한다면 기존의 sqLite 보다 대용량의 RDB 관리에 안정적일 것이라 판단했고, 테이블 상속과 함수 오버로딩과 같은 기능(PostgreSQL)은 현재 필요 없다고 생각하여 MySQL을 채택했다.
Docker : AWS 환경에서 빠르고 쉽게 배포하고, 관리하기 위한 점과 실 서비스와 같이 백그라운드에서 실행하여 무중단 배포를 하기 위해 Docker 배포를 선택했다.
AWS : 기존 배포는 heroku를 이용해 배포했지만 작년 11월 이후 유료화 된 부분이 있고, 비용적인 측면을 봤을 때 AWS가 더 유리하다고 판단했다. 또한 물리서버가 없는 환경에서 클라우드 컴퓨팅 서비스가 필요했고, 이미 이미지 파일은 S3 서비스를 활용하고 있기 때문에 연동성과 비용 측면을 고려하여 선택했다.
route53, ELB : HTTPS 배포를 통해 보안을 더 강화하고, 이후 애플 로그인, 카카오 로그인 등 오픈 API의 활용과 같은 확장성을 위해 선택했다. (애플 로그인 기능일 경우 HTTPS를 필수로 요구함)

2. 프로젝트 이슈

개발하며 겪었던 주요 문제 상황들을 위주로 정리 했습니다.

로컬 Dockerizing 중 MySQL 2003 Error

원인 : docker-compose.yml에서 DB 컨테이너의 volumes의 디렉토리 및 파일 손상 혹은 잘못된 경로

해결

빌드된 컨테이너와 이미지를 모두 초기화 후 volumes의 경로 재설정

Docker-compose up -build 후 컨테이너 작동 확인하면 다음과 같은 에러 재발생
--> (2003, "Can't connect to MySQL server on 'mysql' ([Errno 8] nodename nor servname provided, or not known)")

WAS와 DB migrate를 진행하지 않았기 때문에 발생한 문제로 도커 컨테이너 내부에서 다음 코드 실행
 docker-compose run web python manage.py migrate

docker-compose와 mysql 연동은 처음 시도한 경험이라 에러의 원인을 찾기까지 많은 시간이 걸렸습니다. 처음에는 단순 migration 문제라고 생각했지만, docker container의 로그 탐색과 수많은 구글링 결과 DB container의 volumes가 잘못 되었을 수도 있겠다고 판단했고 volumes의 경로를 재설정 해줌으로써 원인을 발견했습니다.

AWS 서버 Dockerizing 중 web django(WAS) container down

원인 : Docker file에 작성한 RUN python manage.py collectstatic --noinput가 정상 작동하지 않은 문제

해결

빌드된 web 컨테이너 내부에 접속하여 python manage.py collectstatic --noinput 명령어 실행
sudo Docker-compose exec web(django service명) python manage.py collectstatic --noinput

AWS EC2 ssh 연결 시 오류

에러 : port22 : Connection timed out
원인 : 보안 그룹 설정을 잘못해줌, 인터넷에서 해당 포트번호 차단

해결

1번째 시도 - 보안 그룹에서 인바운드 규칙 & 아웃바운드 규칙
- ssh / 포트번호 22 / anyware ipv4,ipv6로 모두 설정

하지만 wifi의 문제일 경우도 있다고 해서 핫스팟을 사용한 결과 문제없이 해결됨
--> SKT에서는 보안을 위해 일부 포트를 차단 해놓는다는 것을 알게됨,

결국 aws 인스턴스 접근시 핫스팟으로 해결

HTTPS 적용 시 오류

에러 : 반복적인 502 에러 발생, restframework css, js 깨짐 현상
원인 : 로드밸런싱 과정 중 타켓그룹 생성 과정에서 발생 --> 타겟 그룹에 포트 443과 80 모두 펜딩하여 오류 발생

해결

펜딩은 80번 포트만 해주고, 433 포트 펜딩과정은 생략

3. 느낀점

기획부터 서비스 파일 배포까지 오로지 혼자서 구현해 본 프로젝트는 사실상 처음이라서 부족한 점도 많았고 시간도 많이 걸렸지만 AWS 환경에서의 Dockerizing 방법은 많이 배워서 만족합니다.

단순히 구현된 기능만 본다면 프로젝트에 소요된 시간이 굉장히 많이 걸린 것이라고 생각합니다. 사실상 로직 구현은 이전 졸업 프로젝트에서 쇼핑몰 웹서비스를 제작하면서 얻은 지식 덕분에 얼마 걸리지 않았습니다. 쿼리 페이지네이션을 통한 검색기능과 API item 수 제한, 저장 기능 등을 경험해봤기 때문인 것 같습니다. 하지만 시간이 오래걸렸던 이유는 Docker를 활용한 AWS환경에서의 배포가 익숙하지 않았다는 점과 비효율적인 테스트 방법 때문이라고 생각합니다.

이번 프로젝트에서는 AWS 환경에서 Docker 배포는 처음에다가 서버에 대해 공부하며 진행하느라 시간이 많이 소요 된 것 같습니다. 하지만 무엇보다 Test code의 중요성을 느꼈습니다. 현재까지는 Postman을 활용한 API 테스트 정도만 진행했지만 이 방법은 API의 개수가 많을 때, 그리고 이후 기능 추가 및 유지보수에 있어서 Test code를 작성하여 UnitTest를 진행하는 것에 비해 더 많은 시간이 소요될 것이라 느꼈습니다. 어디서 시간이 이렇게 많이 걸렸을까 고민해보니 디버깅과 테스트 과정에서 반복적인 Postman을 활용한 API 수동 테스트는 생각보다 시간을 많이 잡아 먹었던것 같습니다. 그래서 그동안 안일하게 생각하고 테스트 코드를 따로 작성하지 않은 점은 반성하게 되었습니다.

아직 스스로가 많이 부족하다고 느끼는 프로젝트였지만 그만큼 더 성장할 수 있다는 말이기에 항상 열심히 더 공부하고 더더 노력해보겠습니다!!

혹시라도 이슈, 프로젝트에 대해 피드백 해주실 분은 두 팔 벌려 언제든 환영입니다. 항상 열린 마음으로 경청하고 고민할 준비되어 있습니다 :D