Spec

사용된 서비스

• mongoDB
• AWS EC2
• AWS S3
• AWS lambda
• Travis CI
• AWS CodeDeploy
• Docker
• nginx

정적 파일 서버 분리

지덕체는 주 컨텐츠가 이미지 파일이기 때문에 서버에 대한 과부화를 막고 효율적으로 운영 정책을 설계하기 위하여 정적 파일 서버를 분리하였습니다.

S3

정적 파일 서버는 비교적 쉽게 구성할 수 있고 레퍼런스가 많은 S3를 이용하였습니다.
정적 파일 서버를 분리한 가장 큰 이유가 백엔드 서버에 대한 트래픽 부담을 줄이기 위해서였기 때문에 이미지가 백엔드 서버를 거치지 않고 클라이언트와 정적 파일 서버가 직접 소통할 수 있는 방법을 찾아야했습니다.
S3에서 preSigned URL이라는 방식을 이용하여 클라이언트와 S3 버킷이 직접 통신할 수 있는 방법을 제공하여 이를 이용했습니다.

lambda

사용자가 실수로 파일을 삭제하거나 오류로 삭제되었을 때 복구할 수 있도록 삭제 후 30일간 더 보관하다가 완전 삭제되도록 파일 관리 운영 정책을 설계했고 이를 위해 30일이 지난 파일을 삭제해주는 배치 프로그램을 제작해야했습니다.

faas인 AWS lambda와 AWS EventBridge를 이용하여 함수의 작동을 스케줄링 할 수 있었고 매일 아침 9시에 삭제된지 30일이 지난 파일이 삭제되도록 설계하였습니다.

EC2 서버 배포

완성된 서버는 AWS EC2에 ubuntu를 기반으로 배포하였습니다.
애플리케이션 서버이기 때문에 nginx가 필요하지는 않았지만 리버스 프록시 환경을 구성하기 위하여 nginx를 사용하였습니다.

무중단 배포 환경 구성

지속적인 개발과 빠른 장애 대응을 위하여 무중단 배포환경을 구성하였습니다.
github과 Travis CI를 연동하여 git push 후 자동으로 빌드가 되도록 설정하였고 이후 Travis CI에서 AWS CodeDeploy를 호출하여 EC2에 배포 및 스크립트가 실행되도록 하였습니다.
nginx의 upstream 기능과 docker를 이용하여 새로운 버전이 배포되었을 때 기존 컨테이너에서 새 컨테이너로 로드밸런싱이 가능하도록 설정하였습니다.

앞으로 개선할 방향

1. 서버 분리

현재 하나의 서버에 백엔드와 프론트엔드가 같이 존재하는데 이를 분리하는 작업을 진행하고 싶습니다.

2. 자체 db 구성

지금 사용 중인 mongoDB는 별도 aws 서버에서 관리되고 있습니다.
이를 mysql 등으로 마이그레이션하여 자체 DB를 구성해 관리해보고 싶습니다.