모든 개발이 완료가 되고 마지막 배포작업을 하게 되었다.
서버 배포는 처음 해보는 일이라서 어떤 툴을 써야할지도 모르고 여러 난관이 있었다.
또 https 때문에 엄청 고생했던 기억이 난다.
프론트엔드 배포는 vercel을 통해서 간단하게 배포하였다.
마감을 하루 남겨두고 배포작업을 하게 되어서 최대한 쉽게 배포할 수 있는 방법이 필요했고 awsEB가 굉장히 간단하게 배포가 가능하다는 것을 찾아서 도전하게 되었다.
awsEB는 서버 소스코드를 압축파일로 만든 후 업로드하면 배포가 되고 관리 또한 간단하게 할 수 있는 서비스였다.
프론트엔드와 완전 다른 도메인으로 배포되었기 때문에 cors옵션에 유의하여 코드를 수정 후에 배포해주었다. 정말 간단하게 배포가 되었고, 엔드포인트를 통해서 api들을 테스트 했을때도 문제가 없었다.
하지만 프론트엔드와 무슨짓을 해도 연결이 안되는 오류를 만났다. 프론트엔드에서 서버쪽에 요청을 해도 응답을 받지를 못했다. 알고보니 vercel을 통해 배포하게 되면 https로 배포가 되기때문에 프론트엔드는 https를 사용하지만 백엔드는 http를 사용하여 서로 통신이 되지 않는 것이었다.
우리는 https를 사용하기 위해 검색을 하였고, aws ACM을 통해서 인증서를 발급받을 수 있다는 것을 찾았다. route53을 이용하여 도메인을 등록하고 ACM에서 인증서를 발급받았다. 여기서 또 문제가 생겼다. 서버 도메인에 인증서를 발급받아서 https로 만들어야 했는데 우리는 프론트엔드에 또 인증서를 발급받아야한다고 착각한 것이다. 무료 도메인 사이트에서 도메인 하나를 발급받아 프론트엔드 도메인을 새로 등록하고 여기에 ACM인증서를 입혔다. 당연히 ACM에서 인증서가 잘오지 않아서 고생하고 우여곡절 끝에 인증서를 받았지만 문제를 해결하지 못했다. 모두가 새로운 생각을 못하고 같은 것을 반복하면서 좌절하고 있었다.
대략 9시간 이상을 붙잡고 있다가 밥을 먹고 휴식을 잠시 취해보자는 의견이 나왔고 휴식을 취하러 갔다.
나도 이때 쉬려고 잠시 누웠는데 문득 백엔드 도메인을 https로 만들어야한다는 생각이 스쳤다. 바로 다시 컴퓨터 앞에 앉아서 진행했고 다른 분들도 다시 돌아와서 백엔드에 도메인을 등록하고 인증서를 발급받아서 https로 재배포 하였다.
해결이 되었다!!!
서로 요청이 잘오고 사이트가 문제없이 동작하는 것을 확인할 수 있었다.
하지만 또 문제가 있었다. 쿠키는 보통 sameSite에서 사용하기 때문에 완전히 다른 도메인을 가진 우리 사이트는 쿠키가 제대로 오가지 않는 문제가 있었다. 그래서 또 설정을 수정해주었다.
이외에도 프론트엔드와 백엔드의 배포서버가 서로 멀리 떨어져있는지 요청이 조금 느리다는 이슈가 있다. 모든 api요청이 1초정도 딜레이가 있다. 실제 사용하기 불편함을 느낄정도로 버벅임이 느껴진다.
조사를 해보면서 보통은 같은 서버에서 배포를 하는데 같은 도메인을 사용하더라도 서브도메인을 이용하여 따로 사용하는 게 일반적이라는 것 같다. 이런식으로 배포를 하게 되면 쿠키관련 이슈도 해결이 가능하고 api요청이 느린 것도 해결할 수 있을 것 같다.
정말 배포과정은 우당탕탕 그 자체였다. 10시간 넘게 붙잡고 이것저것 해보는데 정말 괴로웠다. 하지만 덕분에 배포가 뭔지 제대로 이해했고, 코드를 고칠때마다 재배포하면서 배포자동화가 왜 필요한지 절실히 느꼈다. 젠킨스 등을 사용하면 배포자동화를 할 수 있다고 하는데 ci/cd를 구현하기 위해서 공부를 해보면 좋을 것 같다.
또 컨테이너 기반으로 환경을 구축해서 개발하는 방법을 공부해보려고 한다.
