[TIL] 2022-04-21 / 24일차

 

 

오늘 배운 내용

 

AWS S3

 

AWS S3는 Simple Storage Service의 약자로 파일 서버의 역할을 하는 것이다. 일종의 파일만 저장하는 서비스로(html, css, js, img 등등) 프론트엔드의 정적인 요소들을 S3에 올리는 것으로(클라우드 서버를 거치지 않고) 다른 사람들이 이용할 수 있게 배포가 가능해진다. 아마존 콘솔에서 S3로 접속한 후 버킷을 생성해 사용할 수 있다. 버킷은 파일을 저장할 폴더라고 생각하면 된다. 버킷에 파일들을 올린 후 퍼블릭으로 전환해주면 url로 접속할 수 있게 된다. 그러나 실제 서비스에처럼 특정 도메인으로 연결하는 방식이 아니라 제공해준 url로 접속하게 된다.

 

AWS S3로 배포하기

 

강의에서는 AWS Cloudfront와 S3를 같이 사용했지만, Cloudfront가 안되고 있어(어떤 이유인지 아직 모르겠다..) S3로만 배포하는 과정을 따라 해 보기로 했다.

 

1-1

 

1-1 AWS S3 접속

 

우선 AWS 콘솔로 이동해 S3를 검색해 들어가고, 새로운 버킷 만들기 버튼을 통해 버킷을 생성한다. 

 

1-2

 

1-2 버킷 이름 생성

 

당연스럽게 새로 생성했으니 이름을 입력해 준다. 이름은 리전과 상관없이 무조건 고유한 이름이어야 한다.

 

1-3

 

1-3 퍼블릭 액세스 차단 설정

 

퍼블릭 액세스 차단에 관한 설정이 있는데, 프라이빗 레포의 PR에 링크를 걸어둘 예정이라(이후에 삭제할 예정) 퍼블릭 액세스를 모두 허용하도록 설정을 해준다. 설정을 안 해주면 접근 권한을 부여할 수 없어 확인할 수 없다(처음 시도했을 땐 그랬는데, 다른 방법이 있는지는 모르겠다).

실무에서 사용하는 경우 퍼블릭으로 데이터를 제공하는 경우가 아니라면 서비스 환경에 맞추어 모든 액세스를 차단하거나 ACL을 이용해 액세스를 차단해주는 것이 좋다고 한다.

 

1-4

 

1-4 생성된 버킷

 

다른 설정들은 default로 설정하고 버킷을 생성하면 생성된 버킷을 확인할 수 있다.

 

2-1

 

2-1 버킷에 파일 업로드

 

1-5에서 생성된 버킷에 들어온 후 파일 업로드를 해준다. 업로드 부분에 드래그 앤 드롭으로 파일을 올릴 수가 있다. 파일 업로드가 완료되면 아래 사진처럼 업로드한 파일을 확인할 수 있다.

 

2-1 버킷에 파일 업로드

 

2-2

 

2-2 파일(객체) url로 접속하기

 

업로드된 index.html 파일(객체)을 클릭해 속성 페이지로 들어오면 객체 URL을 확인할 수 있다. 해당 URL로 접속을 해보면 아래와 같은 액세스 거부 메시지 화면이 나타나게 된다.

 

 

이렇게 에러가 발생하면 퍼블릭 객체로 변경해 주어야 하는데, 그렇게 하기 위해서는 사용자 권한을 변경해야 한다.

 

2-3

 

2-3 퍼블릭 객체로 변경 불가

 

다시 생성한 버킷으로 돌아와 업로드한 파일을 퍼블릭 객체로 변경하기 위해 작업 탭을 누르고 활성화시키려 했지만 불가능하다는 표시가 되어 있다.

 

2-3 버킷 -> 권한 탭

ACL 정책을 변경하기 위해, 버킷의 권한 탭으로 들어간 후 밑으로 내려보면 ACL(액세스 제어 목록)을 확인할 수 있다. 여기서 편집 버튼을 눌러 퍼블릭 액세스에 읽기 권한을 부여해야 하는데, 버킷 소유자 설정이 적용되어 편집 권한이 없다고 나온다.

 

2-3 ACL -> 버킷 소유자 설정

 

빨간색 부분의 링크를 클릭해 아래 그림처럼 ACL을 활성화하고 나면 퍼블릭 액세스에 읽기 권한을 부여할 수 있다.

 

2-3 객체 소유권 - ACL 활성화

 

이후에 다시 ACL(액세스 제어 목록)으로 돌아와 편집 탭을 눌러 아래 그림과 같이 읽기 권한을 부여해 주고 변경 사항을 저장해 준다.

 

2-3 퍼블릭 액세스에 읽기 권한 부여

 

2-4

 

2-4 버킷 메인 - 퍼블릭 액세스 가능

 

ACL(액세스 제어 목록)을 활성화하고, 퍼블릭 액세스에 읽기 권한을 부여한 후 버킷의 메인으로 돌아오면 퍼블릭 액세스가 가능하다는 표시가 나타난다.

 

2-4 ACL을 이용해 퍼블릭으로 설정하기

 

그리고 다시 업로드한 파일에 ACL을 사용해 퍼블릭으로 설정을 하고, index.html 파일(객체)의 url로 접속을 해보면 다음과 같이 접속이 되는 것을 확인할 수 있다.

 

2-4 index.html 파일(객체) url로 다시 접속

2-5 

 

2-4에서 마지막에 index.html 객체의 url로 성공적으로 접속은 했지만, 문제가 있다. 새로고침을 했을 때나 잘못된 url로 접속한 경우 404 에러 페이지가 발생하거나 액세스 거부 화면이 나타나게 된다.

 

History API 기반의 SPA를 배포하면, 배포하는 서비스에서 404 에러에 대한 처리를 해주어야 하는데, 현재 S3 내에서 index.html url로 접속한 경우 그 설정이 되어 있지 않기 때문에 발생하는 에러다. History API 기반의 SPA는 index.html은 한 개인데 여러 경로에 해당하는 index.html(새로고침이나 다른 url로 접속할 때)가 없기 때문에 발생한다. 임시방편으로 404 에러에 대한 설정을 해주면 간단하게나마 해결할 수 있다.

 

버킷의 속성 탭에서 제일 아래로 드래그해서 내려가면 정적 웹 사이트 호스팅이라는 필드가 있다.

 

2-5 정적 웹 사이트 호스팅 필드

 

해당 필드에서 편집 버튼을 눌러 정적 웹사이트 호스팅을 활성화시킨다.

 

2-5 정적 웹 사이트 호스팅 편집

 

정적 웹 사이트 호스팅을 활성화하고, 인덱스 문서는 index.html로 설정하고, 오류 문서도 index.html로 설정한다. 여기서 오류 문서가 404 에러가 발생했을 때 index.html로 돌아가게 설정하는 것이다. 정적 

 

2-5 정적 웹 사이트 호스팅 활성화 후 url

 

정적 웹 사이트 호스팅 활성화 후 생성된 url로 접속하면, index.html 객체의 url로 접속했을 때 생겼던 문제(새로고침, url 경로 변경)가 해결된 것을 확인할 수 있다.

 

 

부족한 점 & 느낀 점

• Deploy
• Cloudfront
• S3 ACL에 대한 이해

예전에 스프링을 잠깐 공부하면서 EC2를 살짝 맛보았는데(그때도 마무리하지 못했다), 배포는 너무 어렵게 느껴진다. 학부생 때 배포에 대한 생각을 해본 적이 없었다. 조그만 프로젝트라도 배포까지 꼭 마무리해보라는 얘기를 많이 들어봤는데 이제와 처음 시도하는 것 같아 후회스럽다. 그리고 배포만 띡 하면 끝인 줄 알았는데 SPA 프로젝트는 에러 처리에 대해 옵션을 설정해 주어야 하는지도 몰랐다. 이번 노션 클로닝 과제가 바닐라 자바스크립트로만 이루어진 이유가 자바스크립트에 대한 이해도가 높으면 프레임워크와 라이브러리 사용에 익숙하고 편리하게 느껴지기 위함인데, AWS나 Firebase 등을 이용해 배포를 경험해보는 것도 비슷한 이유이기 때문에 꼭 배포 경험을 해야겠다고 생각된다. 서버에 직접 호스팅 하는 방법이 가장 자유도가 높지만 가장 난이도가 높다고 한다. 서버를 빌려 호스팅 하는 경우 서버가 어떻게 뜨고, 사용되고, 접속 방법은 무엇인지 등 인프라 지식에 대한 요구가 있는데 인프라 지식이 많으면 다양한 서비스를 활용하는데 많은 도움이 된다고 한다. 강의 내용을 통해 Cloudfront에 S3를 연결하고자 했는데, 아직 문제가 있어 해결하지 못했다. 이 부분은 꼭 이번 주 내로 해결해서 프로젝트를 배포해 보고 싶다!