[Develop] 배포 및 트러블 슈팅 시작

챗지피티는 그날 전체 1시간 30분이면 배포작업을 완료할 수 있다고 말했다..............그러나.........ㅋㅋㅋㅋ

 

며칠간 새 글을 쓰지 못했던 이유는 배포를 진행하며 남은 4월 기간동안 트러블 슈팅을 해보기 위함이었다. 

최초에 목표로 했던 것은

 

Docker를 사용한 배포(Spring 과 RDS사용)

RDS 사용이유?

왜 RDS?
일단 많은 회사들이 RDS를 써본 사람을 선호하는 것을 본 적이 있기도 하고, 

비용이 상대적으로 비싸긴 하지만, AWS가 성능을 최적화해주기 때문에 내가 특별히 신경쓰지 않아도 된다는 큰 장점.

보안도 AWS가 알아서 해주고, 장애복구도 AWS가 해주고, 버전관리도 내가 딱히 할 필요가 없다는 점이

빠른 배포 및 트러블슈팅을 원하는 나에게 가장 적합하다고 생각했기 때문이었다.

Docker 사용이유?

도커를 사용한 이유도 위와 비슷하다.

도커 사용경험이 있는 지원자를 선호하는 회사가 많고,

도커를 사용하면 서버 환경차이에 영향받지 않는다고 하며, 일관성/배포속도에서 압도적(이지 못했지만...)

그리고 추후 스케일 아웃 구조로 확장하기도 쉽다고 한다.

아, 그리고 Dockerfile로 환경설정을 해놓으면 이 구성이 자동화된다는 강점이 있었따.

Vercel을 활용한 프론트엔드 간단 배포

그리고 EC2에서 Nginx를 통해 Https 연동시키는 것이었다.

Nginx + HTTPS를 추가?

보안성을 좀 더 높여보고 싶었기 때문이다. 또한 내 실력향상 목표도 당연히 있음

현대의 프로토콜은 거의 https를 사용하므로 그에 맞추고 싶었다.

로컬 개발은 http로도 충분하지만, 실제 배포환경에 적합한 개발을 하고싶었기 때문

또한 나중에 해보니 http만 사용했을때는 'https가 아니라 위험하다'는 식의 알림이 계속 뜨기도 했다.

 

 

특히 Docker에서 Ngrinder를 사용해본 경험으로 Docker기반의 배포를 꼭 하고 싶었는데 문제가 발생했다.

비용문제로 EC2는 프리티어를 사용했는데, Docker를 돌리니까 지속적으로 SSH 연결이 끊기고 리소스 부족한 문제가 발생.

즉 EC2가 Docker를 견뎌내지 못하는 문제!

도커파일도 만들고 잘 하고있었지만 프리티어로는 어려움이 있었다.

그래서 아쉽지만 Docker는 사용하지 않고, EC2에 톰캣을 설치하는 일반적인 방식의 배포를 진행하기로 했다.

 

1차 배포후(톰캣 배포 + Vercel 배포) 실행했을때 https를 사용해야한다는 오류 발생

Nginx를 통해 HTTPS를 연동해주기로 했다. 

 

위를 성공해서 2차 배포하니, 지난번 팀플젝때 했던 것처럼 어찌저찌 로그인은 되지만 세션이 전혀 유지가 되지 않는 문제가 발생했다. 또한 CORS오류도 한 번 발생하여, @CrossOrigin 어노테이션 대신 전역적 CORS설정 하는 것으로 Config 파일 추가해주었다. 

 

세션 유지 되지 않는 문제는 login시에 서버에서 세션을 만들어내긴 하지만, 다음 api들에서는 세션이 하나도 유지되지 않기때문에 발생하는 문제였다. 지난번에도 해결하지 못했던 문제였기때문에 이번엔 꼭 해결하고 싶었다.

https://velog.io/@goat_hoon/React-Spring-%EB%A1%9C%EA%B7%B8%EC%9D%B8-%EC%84%B8%EC%85%98%EC%9D%B4-%EB%B6%88%EA%B0%80%EB%8A%A5%ED%95%9C-%EC%9D%B4%EC%9C%A0

React + Spring - 로그인 세션이 불가능한 이유?

하지만 이런 글도 찾아버리고...ㅎㅎ

지난번 며칠간의 CORS 설정에 재설정에도 되지 않았던 경험을 떠올렸을때, 이번에는 조금 다른 방식이 필요하다는 생각이 들었다. 내가 지금 지향하는 것은 빠른 배포 및 트러블 슈팅이기에, 다른 방법을 찾아보다가 redis를 사용해서 세션을 서버가 아닌 다른 메모리에 저장하는 방법을 선택했다. 

 

그래서 며칠 동안 또 redis 설정을 했다. redis 설정은 다시 정리해서 올려보아야겠다.

 

redis  설정하면서 이번에도 느낀건 챗지피티만으로는 모든 것을 해결할 수가 없다는 것이다.

모르는 부분을 챗지피티만을 사용해서 해결하려고 하면 어느 순간 분명히 길을 잃는다. 내가 처음해보는 것들은 차라리 같은 시도를 해본 다른 블로그들을 참고해서 첫 토대를 잡고, 고쳐나가는 것만 챗지피티를 사용하는 편이 성공률이 높은 것 같다.

 

3차 배포후, redis에 세션이 잘 만들어져서 저장은 되지만, 다음 api에서 그 세션을 읽어오지 못해서 계속해서 세션을 생성하기만 하는 문제 발생.....이 과정에서 수많은 CookieFilter의 수정과, RedisConfig 수정과... swagger와 버전 안맞아서 버전 바꾸었다가 다시 되돌리기도 하고.. 몇번이나 EC2에 배포에 재배포를 했는지 모르겠다. 이 과정에서 자동배포라인을 구축하면 초기단계에 빠른 배포 및 추가개발에 좋겠다는 생각을 몇 번이나 한 것 같다. 

 

그리고 n차 배포후에, 쿠키가 전달되지 않는 것이 결국은 도메인 불일치로 인한 문제라는 것을 알게되었고 (request header에 set-cookie헤더가 절대절대 붙지않았다...그게 제일 필요한데ㅠㅠ) 프론트와 백을 같은 도메인으로 통합해서 cors 문제 자체를 없애버리는 방식을 택했다. 

비록 vercel을 활용한 프론트엔드의 간단배포는 물건너가서, 코드 수정하면 또 재배포해주어야하지만..

그래도 이제 안정적으로 배포에 성공했다.

그리고 도메인 이름도 vercel.app같은게 붙지 않으니 진짜 하나의 웹페이지같은 느낌을 준다.

가비아에서 도메인을 하나 샀는데, ~.site 사용료가 2500원이었다. ㅋㅋ 그래서 앞에 wherethereis라는 도메인명을 붙여서 사주었다 ㅋㅋㅋㅋ

도메인을 사야했던 이유는 

HTTPS 인증서(특히 무료 SSL 인증서인 Let's Encrypt)를 적용하기 위해서는 도메인 검증이 필요했기때문이다. 

도메인이 있어야만 인증서를 발급해주는 시스템이기 때문에!

그리고 좀 더 찾아보니, 브라우저는 IP주소 기반 HTTPS 연결을 기본적으로 신뢰하지 않는다고 한다.

그 외에도 ~~vercel.app과 같은 주소는 정돈되지 않은 느낌을 주기도하고, wherethereis.site는 외우기 쉬워서 사용자 접근이 용이하기도 하고... 비록 탄력적 IP를 할당하기는 했지만 도메인은 더더욱 고정적이기 때문에 지속가능성도 있다고 생각되었다.

그래서 더 쓰지못한 우여곡절도 많았지만, 드디어 최종 배포가 성공되었고 이제부터 트러블 슈팅이 본격 시작이다.

 

배포하면서 가장 뿌듯했던 부분은 드디어 세션이 안정적으로 유지된다는 사실

 

지금 모든 API 요청에서 같은 쿠키가 사용되는 것을 볼 수 있다! 매우 뿌듯

근데 열심히하면서 오류화면 캡쳐도 좀 해둘걸. 너무 많은 오류와 싸워와서 지금 뭐가얼마나 있었는지 기억이 나지를 않는다ㅠㅠ

 

여러가지 문제가 발생되고 있으므로 또 수정해나가야겠다:)