이전 게시글에서 Mysql 데이터베이스, 서버를 배포해 보았다.
이번 게시글에서는 서버를 배포하면서 겪었던 에러들과 그 해결방법에 대해 적어 보겠다.

RDS 데이터베이스 관련 에러

처음 RDS를 통해 Mysql을 동작시킬 때 로컬에서 Mysql Workbench로 테스트를 해 보려 했을 때 연결에 실패하였다.

이 경우 rds 데이터베이스의 보안 그룹을 수정하면 된다.
보통의 경우 Everywhere, 즉 0.0.0.0/0 에만 보안 그룹 규칙이 적용되어 있을 것이다. 이 때, 자신의 IP주소도 인바운드 규칙에 포함시키면 된다. 이번 프로젝트의 경우 IPv6 Everywhere, IPv4 Everywhere, 내 IP 이렇게 세 가지의 인바운드 규칙을 만들어 수정하였다.

서버 배포시 발생했던 에러

서버를 배포하는 데 수많은 에러들을 만났다. 최대한 모든 에러와 그 해결방안에 대해 적어보도록 하겠다.

1. bootJar 에러

Elastic Beanstalk에 대해서 알게 되고, 우리 프로젝트를 Elastic beanstalk를 통해 배포하기로 결정한 다음, jar 파일이 필요하다는 것을 알게 되었다.

처음에는 jar 파일에 대해 잘 모르고 구글링해서 나오는
File -> Project Structure -> Artifacts
build -> build Artifact
이 단계를 통해 jar 파일을 만들었다. 하지만, Elastic Beanstalk에는 실행 가능한 jar 파일이 필요하다는 것을 알게 되고, gradle의 bootJar를 찾아 사용하게 되었다.

처음 발생했던 에러는 bootJar를 실행시켰을 때 발생한

Entry META-INF/MANIFEST.MF is a duplicate but no duplicate handling strategy has been set.

duplicate MANIFEST 에러이다.

이것과 관련하여 많은 검색을 해 보고 한번씩 적용시켜 보았지만, 방법이 따라하기 힘들 정도로 복잡한 것도 많았고, jar 파일을 만들었을 때 제대로 실행되지 않는 경우도 있었다. 우리 프로젝트에서 사용한 방법은 build.gradle 에 다음 코드를 추가하는 것이었다.

tasks.withType(Jar) {
    duplicatesStrategy = DuplicatesStrategy.EXCLUDE
}

이론은 bootJar가 실행될 때, build task가 같이 실행되기 때문에 MENIFEST 파일이 중복되거나 덮어씌워져서 생기는 현상이라는 듯 하다.

참고로 bootJar가 아닌 그냥 jar 파일을 만들었을 때는 MENIFEST 파일과 경로가 담겨 있었지만, 제대로 읽지 못하더라..

2. Elastic Beanstalk 심각 에러

bootJar로 만든 jar를 Elastic Beanstalk에 넣고 배포를 하였을 때, Elastic Beanstalk 에서는 서버의 상태를 확인, 경고, 심각 세 단계로 나타내어 준다. 만약 단계가 심각이라면 서버가 실행조차 되지 않거나 실행되어도 제대로 동작하지 않는다는 뜻이다.

우리 프로젝트의 경우는 명확한 해답인지는 잘 모르겠지만, upload 폴더에 있었던 듯 하다. 이번 프로젝트의 서버에서는 upload라는 폴더가 프로젝트 최상위 바로 아래 경로에 존재하였고, 그곳에서 프로필 사진을 저장하여 서비스하고 있었다.

하지만, jar로 만든 파일을 압축해제하여 안을 들여다 보면, 어딜 보아도 upload 폴더가 존재하지 않았다.

그래서 처음에는 upload 폴더가 jar 안에 없어? resources 폴더 안에 넣어 보자. 해서 resources 폴더 안에 넣어 보았지만, 이번에는 application.property에서 적용시켜 놓았던 file.upload-dir의 주소가 그곳을 가리키고 있지 않았다.

application.properties

file.upload-dir=upload
app.upload.path=upload

결국, 미리 만들어 놓은 폴더를 jar 안에 넣는 것이 아니라 java 함수를 통해 생성하기로 하였다. (PostMapping 주소를 하나 만들어 요청이 오면 실행시키는 느낌으로 만들었다.)

File Folder = new File(uploadDir);
if (!Folder.exists()) {
	try { Folder.mkdir(); }
	catch (Exception e) {}
}

이 코드를 추가하여 jar 파일을 cmd에서 java -jar 파일이름.jar 로 실행시킨 다음, 폴더를 만들었더니....

jar 파일이 있는 폴더에 생성이 되었다!

아무래도 jar 파일 안에서 데이터를 수정하거나 하는 것은 안되는 듯 하고 이런 방식으로 바깥의 폴더에서 접근해야 하는 듯 하다.

3. 502 Bad Gateway 에러

앞선 방법으로 jar 파일까지 만들고, Elastic Beanstalk의 상태까지 확인이 뜬 것을 보고 수많은 억까를 뚫고 드디어 성공했구나 싶었지만 502 에러가 뜨게 된다....

원래대로라면 스프링부트의 home 페이지가 떠야 할 것이고, 우리 프로젝트의 경우 페이지가 없으니 404에러가 떠야 정상이었다.

이 경우 한번 jar 파일을 다시 Elastic Beanstalk에 업로드 해 보길 바란다. 로컬에서 bootJar로 만든 jar가 잘 돌아간다면, 그리고 상태가 확인으로 떠 있다면 안될 이유가 없다.

찾아보니 Elastic Beanstalk에서 서버를 돌리려면 서버의 포트번호가 5000에서반 돌아간다고 한다.
서버의 포트를 5000으로 수정하고 배포에 성공하였다.

application.properties

server.port=5000

4. NET::err_connection_timed_out 에러

서버를 등록하고, 동작 확인을 주소창에 GetMapping으로 아무거나 요청해 보고, 프론트 서버에 백엔드 서버의 주소를 등록하였다.

그리고 NET::err_connection_timed_out 에러가 발생하게 된다...

검색을 해 보니 서버와 데이터베이스의 연결이 안되었다는 곳도 있었고, AIM 설정을 해야 된다는 곳도 있었고, 서버가 느려서 응답받는 데 너무 오래 걸려서라는 곳도 있었다.

하지만, 주소창에 GetMapping 주소를 입력했을 때는 꽤나 빠르게, 그리고 데이터베이스에 저장되어 있는 정보를 표시하는것으로 보아 위의 경우는 아닌 듯 했다.

그리고 찾아냈다...! 프론트에 변수로 저장해 놓았던 API서버의 주소가 https로 되어 있었던 것이다!

javascript

const path = "https://Sekkison-env-1.eba-qrr3cbmm.ap-northeast-2.elasticbeanstalk.com";

그래서 https를 http로 바꾸었다.
그러고 나니 다른 에러가 뜨게 되었는데...

5. Mixed Content 에러

Mixed Content Error가 뜬 것이다.
프론트의 주소는 https였고, 백엔드의 주소는 http였기 때문에 발생한 상황이었다.

이번에도 수많은 구글링으로 다음 코드를 html에 전부 넣어 보았다.

<meta http-equiv="Content-Security-Policy" content="upgrade-insecure-requests">

하지만 이렇게 하면 안된다는 것을 알게 되었다.

이렇게 작성한다면 4번의 NET::err_connection_timed_out을 또 보게 될 것이다.
위의 메타 코드는 단순히 http 요청을 https로 바꾸어 주는 것이기 때문이다.

https가 지원되지 않는 http url이 저 코드로 인해 변환된다면, 4번에서 path를 https로 저장한 것이나 다름이 없는 것이다.

찾아보니 Elastic Beanstalk의 주소를 https로 바꾸는 방법이 있었다.
우리 프로젝트에서는 https에서만 동작하는 로직들이 많아 거의 필수적이었기에, 번거로웠지만 SSL인증서를 통해 https를 지원하기로 하였다.

참고 : https://omty.tistory.com/47
백엔드 서버를 위한 도메인을 구해 설정하였다.

이후는 문제없이 잘 동작하였다.