[TIL] 2022-04-26 / 27일차

 

25일 월요일 강의를 듣고, 오후 7시 30분 로토(김태희 강사)님 특강 세션이 있어 오프라인을 다녀왔다. 지난 오프라인 때 참석 못했는데, 이번에 처음 참여하게 되어 너무 재밌었다. 구 찬희팀(임시팀) 분들과 만나서 인사도 나누고 현 요한팀 분들과 만나 밥도 먹고 간단한 얘기도 나누고 했었다.

 

특강 끝나고 집에오니 12시가 다 되어 다른 일은 못하고 강의만 듣고 하루를 마무리했다(아침에 부지런할 필요가..). 그 덕에 26일 차 TIL은 또 생략되었다...😥

 

오늘 배운 내용

 

오늘 하루 일정을 코드 리뷰로 시작했고, 리뷰가 끝난 후 지난번에 노션 클론 프로젝트를 AWS S3로 배포한 것을 cloudfront까지 접목해 배포했다.

 

AWS cloudfront로 배포하기

 

https://docs.aws.amazon.com/ko_kr/AmazonCloudFront/latest/DeveloperGuide/Introduction.html

Amazon CloudFront란 무엇입니까? - Amazon CloudFront

 

AWS S3와 Cloudfront에 대한 공부도 필요한데.. 우선 배포를 먼저 신경써서 나중에 차차 공부할 수 있도록 한다(언젠가는).

 

간단하게 이해한 바로는, S3에 올린 정적인 파일들(html, css, js)을 사용자가 Cloudfront로 접속을 하고, 접속을 받은 cloudfront는 요청이 들어온 것을 S3에서 꺼내와 제공하는 방식이다. S3와 다르게, 404 page 에러, 대체 도메인 등을 해결할 수 있다. 대체 도메인을 사용하려면 Route 53 설정을 통해 도메인을 설정하고(비용 발생) cloudfront를 생성할 때 

사용자 정의 SSL 인증서를 넣으면 사용이 가능해진다. 아직 이렇다 할 프로젝트가 아니기 때문에 대체 도메인은 생략하고 진행해 보았다.

 

 

1.1 cloudfront 배포 생성

 

1.1 cloudfront 배포 생성

 

우선 AWS 콘솔 창에서 Cloudfront를 검색해 들어간 뒤, 보이는 화면에서 배포 생성 버튼을 클릭해 과정을 진행한다.

 

1.2 원본 도메인 설정

 

1.2 원본 도메인 설정

 

cloudfront와 연결하고자 하는 S3(지난번에 생성한)를 넣어주면 된다. 원본 경로를 입력하면 "원본 도메인/원본 경로/요청 파일"로 호출이 된다.

 

1.3 OAI 설정

 

1.3 OAI 설정

 

cloudfront를 통해 S3 객체를 가져오기 위해 OAI를 설정한다. 해당 기능을 사용하기 위해 OAI가 없다면 "새 OAI 생성" 버튼을 클릭해 새 OAI를 생성해 준다.

 

1.3-1 새 OAI 생성

 

OAI에 대한 읽기 액세스를 허용하도록 버킷 정책을 "예"로 설정해준다.

 

1.3-2 버킷 정책 업데이트

 

마지막으로 기본값 루트 객체를 index.html로 입력하고 설정을 마무리한다.

 

1.3-3 기본값 루트 객체 설정

 

1.4 cloudfront 배포 생성 완료

 

1.4 cloudfront 배포 생성 완료

 

배포 생성이 완료되면 위와 같이 배포된 도메인을 확인할 수 있다. 해당 도메인을 접속해 확인해보면 정상작동이 된다.

 

1.4-1 배포 도메인으로 접속 / Document 선택

 

2. 404 페이지 에러 대처

 

2. 404 에러

 

그러나, 루트 경로에서의 동작(문서 간 이동, 뒤로 가기 등)은 되지만 새로고침을 하면 위와 같이 AccessDenied 에러 페이지가 나온다. S3를 배포할 때, 에러 페이지 핸들링을 했었는데(임시방편으로 에러 페이지가 나오면 index.html로 돌아가기) cloudfront에서도 같은 설정을 해주어야 한다.

 

2.1 오류 응답 생성

 

2.1-1 오류 응답 생성하기

 

생성된 배포의 "오류 페이지" 탭으로 들어가 사용자 정의 오류 응답을 생성해준다.

 

2.1-2 사용자 오류 응답 생성 - 404 에러 핸들링

 

새로 고침 후, 404 에러가 나오면 루트 경로(/index.html)로 돌아가도록 설정하고, 응답 코드로 200을 보내도록 설정해 준다. SPA 특성에서 기인하는 것인데, 특정 에러가 발생하면 200 응답 코드를 내리고 /index.html로 바꾸도록 하는 것이다.

해당 문제에 대해 참고한 블로그 -> 링크

 

2.1-3 사용자 오류 응답 생성 완료

 

사용자 정의 오류 응답을 생성하면 위와 같이 새로운 응답 오류가 생성된 것을 볼 수 있다.

 

2.2 S3 버킷 - 정적 웹 사이트 호스팅 수정

 

그리고 이 cloudfront에 연결되어 있는 S3 버킷의 "속성" 탭에서 "정적 웹 사이트 호스팅" 필드로 돌아가 오류(404 에러)가 발생하면 반환될 문서를 수정해 주어야 한다.

 

2.2-1 S3 버킷 - 속성 - 정적 웹사이트 호스팅 필드

 

"편집" 버튼을 클릭한 후, 아래와 같이 오류 문서에 돌아갈 페이지(index.html)를 지워준다.

 

2.2-2 정적 웹사이트 호스팅 오류 문서 필드 수정

 

그리고 다시 cloudfront의 도메인으로 들어가 동작을 확인해보면 새로고침 후 동작이 잘 될 줄 알았지만, 403 에러가 발생해 403 에러에 대한 사용자 요류 응답을 새로 추가해 주었다.

 

2.2-3 403 오류 응답 생성

 

404 에러와 마찬가지로 에러가 발생하면 /index.html로 돌아가게 하고 200 응답을 내리도록 설정한다. 그리고 동작을 확인해 보면 정상 동작하는 것을 알 수 있다.

 

Cloudfront + S3를 통해 배포한 프로젝트

 

Notin Clone

 

부족한 점 & 느낀 점

 

어찌어찌 Cloudfront와 S3로 배포까진 했다. 엣지 로케이션, 콘텐츠 캐싱, Cloudfront 동작원리 등은 세세하기 알지 못하지만, 첫 배포라서 뿌듯한 느낌이 있다(도메인 설정은 못했지만).

 

404 에러와 403 에러가 났을 때 처리를 못해 오늘에서야 해결했다. 꽤 오래 걸렸는데, Cloudfront에서 redirect를 403 에러로 막기 때문에 이에 대한 조치가 필요했던 것이다. 이것도 모르고 계속 애꿎은 Cloudfront 배포와 S3 버킷만 삭제, 생성을 반복했다.

 

노션 프로젝트가 끝나고 나서부터 시간이 엄청 빡빡하게 느껴진다. 강의를 들어야 하고, 코드 리뷰를 해야 하고, 리뷰를 반영해야 하고, TIL도 작성해야 하고, TIL을 작성하기 위해 공부도 더 해야 하는데 아침에 부지런히 일어나서 할 수 있도록 해야겠다. 더 이상 미루면 많이 힘들듯하다..... 3번의 코드 리뷰(다른 분의 코드를 보고 리뷰를 달아주는)를 하면서 느낀 건데 "내가 많이 부족하면 다른 사람이 피해를 볼 수 있겠다."라는 생각이 든다. 코드에 대한 피드백을 드리지 못해 내가 아닌 다른 사람에게 리뷰를 받았다면 더 좋았을 텐데 라는 생각이 든다. 다른 분들은 코드 리뷰를 잘해주시는데 많이 부족한 것 같아 죄송스러운 마음이 든다.