마지막으로 S3를 이용하여 프론트엔드를 배포해보았다. 개발 과정에서 데이터베이스는 RDS 인스턴스로 사용하였고, 프론트엔드와 백엔드는 로컬에서 개발하고 있었다. 프로젝트가 얼추 완성된 시점에서 기존에 수행했던 방식으로 EC2 인스턴스로 백엔드를 배포하였고, 이번에는 S3를 이용하여 프론트엔드를 배포할 때가 되었다.
1. 작업 순서
프론트엔드 파일 빌드
S3 버킷 생성
테스트
2. 오..
GitHub 저장소 링크만 올리면 알아서 다 배포해주던 Vercel보다는 AWS S3쪽이 확실히 복잡하고 번거롭긴 하다.
그래도 EC2랑 RDS를 생각하면, S3는 너무나도 간편하고 손쉽게 배포할 수 있는 수준이다.
S3 버킷 생성
S3 버킷에서 접근 제어 목록의 사용 여부와 퍼블릭 엑세스 차단 여부를 설정하는 부분. 접근 제어 목록의 경우 AWS에서 권장하는건 비활성화이므로 그대로 두고, 퍼블릭 엑세스의 경우 이걸 그냥 차단해버리면 외부에서 버킷에 접근할 수가 없다.
이쪽은 이해하는게 어려워서 ChatGPT의 지원을 받아 체크하라는 부분만 체크하고 넘어갔다.
버전 관리는 Git에서 하는 것 처럼 버킷 파일의 버전을 관리하고, 필요에 따라서 이전 버전으로 파일을 되돌릴 수 있는 기능을 제공한다.
암호화의 경우 아래로 갈 수록 더 강한 보안 수준을 갖지만, 프리티어에서는 일정 사용량이 초과하면 과금이 발생한다. 이번 프로젝트에서는 기본 설정의 암호화 방식을 선택하였다.
이렇게 하면 S3 버킷이 생성된다.
파일 업로드
빌드한 프론트엔드 파일들을 버킷에 업로드해주면 된다. PuTTY를 이용해서 복잡하게 파일을 가져오던 EC2와 다르게 AWS 콘솔에서 바로 파일을 업로드 할 수 있다.
스토리지는 프리티어이고, 사용량이 많지 않으므로 기본 스탠다드를 설정하면 된다.
이러면 이제 버킷도 생성하고, 프론트엔드 파일도 업로드 되었으며, 배포된 프론트엔드에 접속할 엔드포인트 주소도 제공된다. 테스트를 해보니..
2. 아오..
무언가 순탄하게 진행된다고 생각했는데, 아니나다를까..
퍼블릭 엑세스 차단 설정
오류의 원인은 해당 버킷에 대한 접근 권한이 없기 때문.
문제의 원인은 버킷 생성시에 퍼블릭 엑세스를 차단시켜두었기 때문이었다. 이 부분도 무작정 해제시켜둘 설정이 아닌것 같지만, 우선 배포 작업이 먼저이기 때문에 엑세스를 허가해두었다
구글링을 해보니, ACL 설정에서 버킷 소유자 이외에게는 읽기 권한만 부여해야 한다고 해서 설정을 변경하였다.
그리고 다시 테스트를 해보니..
버킷의 시작 경로 설정
403 오류가 404 오류로 바뀌었다. 여전히 배포가 제대로 되지 않는건 답답한 일이지만, 기존에 발생하던 에러가 사라졌다는 것은 일단 문제 하나는 해결되었다는 뜻이다.
404 오류의 원인은, S3 버킷의 시작 경로에서 설정한 index 파일이 제대로 인식되지 않는다는 뜻이다.
설정을 다시 살펴보니, 빌드 파일은 dist/index.html의 경로로 들어가고 있었는데 설정에서는 그냥 index.html로 되어있어 파일을 찾지 못하고 있었다.
경로를 변경할까도 해봤지만, 경로 설정에 폴더를 포함시키는건 권장되지 않는 행동이라고 해서 파일을 다시 업로드하였다.
그러자 드디어 프론트엔드가 제대로 배포되는 것을 확인하였다!
환경변수 설정
프론트엔드는 정상적으로 출력되는데, 백엔드로 가는 요청이 CORS 문제로 거부되었다.
이 문제는 빠르게 해결되었다. 이미 백엔드를 배포한 시점에서 코드 내부에 CORS 문제를 발생시키지 않도록 필요한 코드가 작성되어 있었다.
여기에는 특정 URL에서 들어오는 요청은 CORS 문제를 발생시키지 않고 통과시키도록 설정해주고 있었는데, 로컬 환경에서 개발할때 사용하던 'localhost:5173' 부분을 AWS 엔드포인트로 변경하지 않은 것이 문제였다.
또한 기존에 사용하던 프론트엔드 환경변수의 경우, 따로 조치하지 않아도 프로젝트 빌드 과정에서 적절하게 변환되어 빌드 파일에 포함된다는 사실도 파악하였다.
문제가 되는 부분을 수정하고, 다시 테스트하니.. 모두 문제없이 잘 동작하였다.
3. 드디어!
이로써 AWS S3, EC2, RDS 서비스를 이용한 프론트엔드, 백엔드, 데이터베이스 배포에 성공하였다. 내가 구현한 기능들도 모두 문제없이 동작하고 있다.
배포도 순탄하게 돌아가고는 있지만, 아직 할 일이 남아있다. 각 서비스의 보안 설정들을 더 세부적으로 조정할 필요가 있기 때문. 대부분의 경우에는 엑세스 권한을 완전 개방해둔 상태라서 보안의 관점에서 그리 좋은 상태라고 할 수는 없다.
AWS에 대해 더 공부할 필요가 있는 것이다.
