AWS 배포

 드디어 AWS 배포를 마무리했다. 빨리 끝날줄 알았는데 정말 많은 버그들을 겪다보니 생각보다 훨씬 오래 걸렸다.

HTTP 환경에서 HTTPS 환경으로 넘어가는데 처음 경험해보는 환경이다보니 많은 시행착오와 삽질이 있었지만 그래도 결국에는 구현해냈다! 버그를 잡아내 정상적으로 구동됐을때 얼마나 기뻤는지 모른다. 이 마음이 식기전에 만든것들을 한번 정리해보려고 한다.

 

---

서버 구성

 

 프론트쪽의 구성도다. HTTPS를 활용하기 위해서 도메인을 구매했고, 이 도메인에 ACM을 활용해 인증서를 발급받아 HTTPS로 구성했다. 로드밸런서를 통해 80포트로 들어온 요청은 443포트쪽으로 리다이렉트 시켜 HTTPS를 사용하도록 했고, 기존 리액트는 NGINX에 올려 요청을 처리하도록 했다.

 

 

 백앤드의 구성도다. 프론트쪽에서 요청이 들어오면 톰캣의 8080포트를 통해 데이터가 들어오고, 스프링 시큐리티의 기능을 활용해 8443 포트로 요청이 들어오도록 했다. 그외에 RDS를 사용했는데 비용이 생각보다 많이 나오더라... 약 3주간 사용했는데 도메인 2개의 가격을 포함해서 거의 10만원이 나왔다. 계속해서 서버를 유지하기는 쉽지 않을듯하다.

 

전체적인 구성도

 

 

---

시행착오들

 

HTTP -> HTTPS 

 대부분의 삽질은 이 HTTP에서 HTTPS로 옮기는 과정에서 나왔다. 별 처리를 안하고 구성만 한 뒤에 프론트에서 요청을 날렸을 때, Mixed Content라며 요청을 거부하는 상황이 있었다. 이거에 대한 해결책은 스프링 시큐리티의 WebSecurityConfigurerAdapter config에 .requiresChasnnel()을 붙여주면, 모든 요청이 8443포트로 리다이렉트되어 처리된다. 이 방법으로 MixedContent 이슈를 처리했었다.

 

 

CORS

 분명 로컬에서는 CORS를 다 잡고 왔었는데, AWS에 배포를 진행하면서 CORS 이슈가 다시 일어났었다. 정말 많은 해결책을 시도했던 것 같다. MvcConfigurer를 구현해 CORS를 register시켜보기도 하고, Filter를 사용해 CORS를 등록시켜보기도 하고, WebSecurityConfigurerAdapter에 corsConfigurationSource도 설정해봤지만 그래도 되지 않았다. 대체 뭐가 문제인지 이틀 삼일을 계속해서 고생했었는데 결과는 허무하게도 MvcConfigurer와 Filter를 사용한 CORS가 둘 다 있을경우 동작하지 않았다. MvcConfigurer의 설정을 제거하고, Filter만 남겼더니 정상적으로 작동되었다.

 

 

TOO_MANY_REDIRECT

 AWS에서 서버를 구성할 때 흔한 이슈중 하나라고 한다. 백서버내에서 리다이렉트가 일어날 경우 날 수 있는 문제라고 하여 원인을 파악했고, 내 서버에서 뭐가 문제인지 확인해봤다. 문제는 Spring Security의 디폴트 로그인 성공 핸들러가 로그인을 성공하고나면 다른 페이지('/')로 리다이렉트 시키는것이였다. 이를 해결하기 위해 리다이렉트는 내지 않고 상태 코드만 내려보내도록 Success Handler를 새로짰고, 문제는 해결되었다.

 

 

 그 외에도 많은 삽질이 있었지만 위에 적어둔 것은 처음 해보는 것이다 보니 해결하는데 많은 시간이 걸렸다. 대부분 2일 이상의 시간이 소요되었다. 그래도 이렇게 버그를 전부 해결하고 AWS에 배포하고나니 상당히 뿌듯하다!

 

 

현재 배포중인 페이지

https://whatishouldeat.com/

React App

 

 아무래도 AWS 비용이 많이 나가다보니 오래동안 유지하기는 힘들 것 같다. 크게 복잡하지 않은 기능이니 챗봇같은 방식을 채용하는 것도 괜찮을 듯 하다. 우선 엉망이된 코드를 리팩토링하고 기능을 하나씩 추가해나가보자.