[이슈리포트] 내 생애 첫 배포

 우리 프로젝트에서 내가 담당한 파트는 주로 인프라 쪽이었다. 그렇게 나는 첫 배포를 맡아 좌충우돌하며 겨우 성공했었다.. ㅎㅎ 지금부터 첫 배포를 하며 겪었던 이슈들을 적으려고 한다.

(AWS를 이용한 클라우드 배포 기준입니다.)

# 프론트엔드 배포? 백엔드 배포?

 처음 배포를 할 때는 당연히 하나의 서버로 배포하는 것이라 생각했다. AWS EB를 통해 서버 환경을 구성하고 Docker를 실행해서 배포했다. 이 과정에서 정적 파일들(html, js 등)은 EB 생성 시 자동으로 생기는 S3에 담겨 함께 배포됐다. 하지만 이 방법이 순탄하지 많은 않았다.

 EB로 구성된 환경에서 S3에 접근하지 못해서 자꾸 정적 파일들을 불러오는 데에 오류가 발생했다. 알고 보니 S3에 접근하는 권한 설정이 필요한데 그 설정을 하지 못했던 것이다. 또한, ECR을 이용해서 컨테이너 환경을 만들어주었는데 ECR로의 로그인 실패 오류가 자꾸 발생했다. 해당 오류도 EB에 'ECR 읽기 접근 권한'을 설정해주지 못했기 때문에 발생했었다. 단순한 권한 설정 오류이지만, 해결 과정은 쉽지 않았다. 'S3 denied ...', ' ECR Login ...' 어쩌고 오류만 반복하는 상태에서 다른 부분에서 잘못된 것이 있나라는 생각부터 하게 되니 꽤 시간이 오래 걸렸던 것 같다. 이 일로 서비스 관련 오류가 생기면 권한 설정부터 의심해봐야겠다는 생각이 들었다.

 

# CORS 오류 넌 또 뭐야..?

 그래도 서버는 프론트와 백을 따로 배포하는 것이 효율적이다. 즉, 서버가 각각 필요하다는 말이다. AWS에는 정적 파일들을 위한 S3, CloudFront와 동적 파일들을 위한 EB, Lambda 등의 서비스가 있다. 이처럼 나누어 관리하는 가장 큰 이유는 효율성이다. 표면적으로도 서버 한 곳에 모든 파일을 몰아두었다고 생각하면 당연히 느려질 것이다. 뿐만 아니라, 데이터를 출력하는 것과 로직을 통해 처리하는 것은 명백히 다르기 때문에 분리해서 관리할 때 훨씬 효율적이다.

 단, 두 개의 다른 서버가 서로 통신하려면 CORS 오류가 발생하게 된다. 포트, IP, 도메인 등 네트워크 속성이 다른 서버끼리 통신을 하려면 CORS 허용을 해야 한다. 스프링에서는 꽤 간단한 방법으로 해결할 수 있는데, WebMvcConfigurer 클래스를 이용하면 된다. addCorsMappings 메서드를 통해서 허용할 도메인과 http 메서드를 지정해주면, 손쉽게 해결할 수 있다. 마지막으로 Cors 허용을 Default로 지정했었는데 allowedMethods 메서드를 찾아보니, Default 값은 GET, POST, HEAD만 허용해서 PUT, DELETE 등의 메서드까지 허용하려면 새로이 모두 지정해주어야 한다.