[프로젝트 배포] RDS, S3 설정 및 프로젝트 배포

승등·2024년 6월 2일
S3awsec2rds배포

배포

목록 보기
2/3
post-thumbnail

앞선 포스트에서 EC2 인스턴스를 생성하고 ubuntu 서버에 jdk설치까지 진행하였다.
이번 포스트에서는 RDS 및 S3 설정을 완료하고 서버에 프로젝트를 배포하는 과정까지 정리해본다.

RDS 설정

RDS 생성

옵션

AWS 서비스 목록 중 RDS를 찾아 데이터베이스 생성부터 해준다.

  • 생성 방식 : 표준 생성
  • 엔진 옵션 : MariaDB (기존 프로젝트에서 사용한 DB와 동일하게 선택해준다.)
  • 템플릿 : 프리 티어

설정

  • 인스턴스 식별자 : 임의로 작성해주자. 기본값을 사용하여도 상관없으나 하나의 AWS계정에서 이미 사용한 DB인스턴스 식별자는 재사용 할 수 없다.
  • 마스터 사용자 이름 : DB 접속 시 사용하는 마스터 이름이며 임의로 작성하거나 기본값(admin) 그대로 사용해주면 된다.
  • 마스터 암호 : DB 접속 시 사용하는 비밀번호. 추후 변경이 가능.

인스턴스 구성 및 스토리지

  • 인스턴스는 프리 티어 디폴트 설정을 유지한다.

  • 스토리지 역시 프리 티어 디폴트 설정을 유지하나 스토리지 자동 조정은 체크 해제 해주자.

연결

  • 마찬가지로 기본 설정을 유지한 채 퍼블릭 엑세스만 '예'로 체크해준다.
    '아니요'로 체크할 시 DB가 속한 VPC 외부에서 DB에 접속할 수 없다.

나머지 설정은 모두 기본값으로 둔 채 데이터베이스 생성을 눌러준다.

데이터베이스가 정상적으로 생성되었다.

보안 그룹 설정

인바운드 설정

  • 유형을 MYSQL/Aurora 로 선택해준다. (유형에 MariaDB는 따로 없다.)

아웃바운드 설정

  • 인바운드와 동일하게 추가해준다.

로컬PC에서 RDS 접속

프로젝트 데이터 소스로 mariaDB를 선택하여 추가해준다.

  • 이름 : 앞서 RDS 생성 시 입력한 DB이름을 입력
  • 호스트 : DB의 엔드포인트를 입력
  • URL : 호스트 입력 시 자동으로 설정된다.
  • 사용자/비밀번호 : RDS 생성 시 입력한 마스터 사용자 이름 / 마스터 암호

연결 테스트를 진행해보면 정상적으로 연결됐음을 알 수 있다.

파라미터 그룹 설정

DB의 시간 설정이나 char-set 설정을 위해 파라미터 그룹을 생성, 변경해준다.

변경할 옵션은 크게 세가지

  • time_zone
  • character-set
  • max-connection

파라미터 그룹부터 생성 해준다.
파라미터 그룹 패밀리는 RDS 생성 시 선택한 DB버전과 일치하도록 선택해준다.

생성 된 파라미터 그룹은 편집해준다.

  • time_zone : Asia/Seoul 로 변경
  • character_set : character을 검색해서 나오는 항목을 모두 utf8mb4 로 변경해준다.
    (utf8mb4: 기존 utf-8 에 더해 이모지까지 저장할 수 있다.)

    + collation을 검색해서 나오는 항목을 모두 utf8mb4_general_ci 로 변경해준다.

 

  • max-connections : 기본 설정은 인스턴스 사양에 따라 결정되며, 프리 티어의 경우 별도 설정이 없다면 60 정도가 된다고 한다. 여유있게 150으로 설정해주었다.

    + connect_timeout : DB와의 커넥트 유지 시간을 따로 설정해주지 않으니 too many connections 에러가 발생하였다. 아래와 같이 180으로 설정해주었다.

 

설정을 변경한 파라미터 그룹을 앞서 생성한 RDS에 적용해준다.

기존 localDB 데이터 옮기기

mysqldump 명령어를 사용하여 손쉽게 데이터를 옮길 수 있었다.
자세한 내용은 AWS RDS에서 로컬 MariaDB 데이터 불러오기 참고

S3 설정

S3 버킷 생성

객체 : S3에 저장되는 컨텐츠, 하나의 객체는 하나의 파일이라고 볼 수 있다.
버킷 : 객체가 저장되는 컨테이너


앞서 RDS 인스턴스를 만든 것 처럼 AWS 서비스 목록에서 S3를 찾아 버킷부터 생성한다.

버킷 이름은 임의로 작성해도 되지만 고유해야 한다.
또한 정해진 작성 규칙 내에서 작성해야 한다. 공식문서 참고

모든 퍼블릭 엑세스 차단 이 기본적으로 체크 되어있다.
외부 사용자에게 공개되는 프로젝트이기 때문에 체크를 해제해줬다.

버킷 버전 관리 - 직접 관리 할 경우 삭제된 객체를 복원 할 수도 있다고 하지만, 매번 관리 할 것도 아니고 비용이 추가 발생한다고 하니 비활성화 해둔다.
기본 암호화 - 객체 저장 시 암호화, 다운로드시 복호화를 지원해준다고 한다.

고급 설정은 별도로 변경하지 않는다.
여기까지 설정을 완료했다면 버킷을 생성해준다.

권한 설정

버킷이 생성됐다면 권한을 설정해준다.
권한 하단의 버킷 정책에서 편집을 선택한다.

버킷 정책 작성을 위한 정책 생성기를 지원한다.

step1 : Select Type of Policy - S3 Bucket Policy 를 선택
step2 : Principal - *
Actions - Get Object Put Object Delete Object를 선택
ARN - 앞서 버킷 정책 편집 창에서 확인한 ARN을 복사하여 입력

Add Statement - Generate Policy 클릭

생성된 정책 json 코드를 복사한다.

정책 편집 창에서 복사한 json 코드를 붙여넣고 변경사항을 저장한다.

관련 트러블

Action does not apply to any resource(s) in statement 에러가 발생했다.

해결
정책 json의 Resource 항목의 value(ARN)의 뒤에 /* 을 추가로 붙여주고 변경사항을 저장한다.
참고 - [AWS] AWS S3 버킷 만들기

버킷 테스트

이미지를 업로드하니 정상적으로 업로드 된다.

url로 이동 시 업로드한 이미지가 정상 출력되는 것을 확인하였다.
다운로드 및 삭제까지 문제 없이 동작한다.

프로그램을 통한 S3제어

프로젝트에서 S3에 접근하여 제어하기 위해서는 추가적인 보안 설정이 필요하다.

AWS 서비스 목록 중 IAM을 검색하여 이동한다.

사용자를 생성해준다.

AmazonS3FullAccess 정책을 체크 한다.

사용자를 생성한다.

주의
프로그램에서 S3에 접근하기 위해서는 버킷의 [객체 소유권]에서 ACL 활성화됨을 체크해줘야 한다.

사용자가 생성되었다면 [보안 자격 증명]에서 엑세스 키를 만들어준다.

엑세스 키 까지 생성 완료하였다.

S3 설정 파일 및 파일 업로드 로직 변경

여기까지 완료하였다면 나머지는 프로젝트에서 S3 관련 설정과 기존 파일 업로드 비즈니스 로직을 변경해주면 된다.

관련 설정 및 변경된 코드는 배포에 중점을 둔 포스트 성격을 고려하여 따로 작성하였다.
[Spring Boot] 다중 파일 업로드 및 로컬 이미지 출력 / 로컬 업로드 S3로 전환

프로젝트 배포

필요한 기본적인 설정을 모두 끝냈으니 EC2 인스턴스 상의 서버에 배포 해보기로 했다.

서버에서 프로젝트를 직접 배포하는 방법으론 크게 아래의 두가지 방법을 사용하는 듯 했다.

  1. 서버에서 git 레포지토리를 clone 하여 build 하는 방법
  2. 서버에 jar파일을 직접 전달하는 방법

우선 git clone 방법을 먼저 해보기로 했다.

git clone

프로젝트를 클론하여 빌드하기 위해 git을 설치해준다.

sudo apt install git
git --version

프로젝트를 받을 경로를 생성하고 이동한다.

mkdir dulle dulle
cd dulledulle

프로젝트 레포지토리의 url을 사용하여 프로젝트를 클론한다.

gradlew 파일을 실행하기 위해 프로젝트 폴더 내부로 이동,
gradlew 파일을 빌드하기 위해 권한을 변경하고 bulid해준다.

build가 완료되었다면 build > libs 로 이동 후 jar파일을 실행해준다.

cd build
cd libs
sudo nohup java -jar <프로젝트 이름>-0.0.1-SNAPSHOT.jar &
  • nohup : 터미널의 세션이 끊기더라도 지속적으로 동작하도록 하는 명령어
  • & : 프로그램을 백그라운드에서 실행

만약, 이미 해당 포트로 실행 중인 프로그램이 있다면 아래의 방법으로 pid를 조회 후 종료시켜준 후 실행한다.

sudo netstat -tnlp
sudo kill -9 <pid>

관련 트러블

QueryDSL을 사용하다 보니 Q클래스 문제로 build 단계에서 오류가 발생하였다.

Q클래스는 빌드 과정에서 자동으로 생성되며, 기존 생성된 Q클래스 파일이 이미 존재하고 있는 상황에서 빌드를 시도하면 기존 Q클래스 파일과 새로 생성할 Q클래스 파일이 다르다고 판단하여 오류가 발생할 수 있다.

해결
./gradlew clean 을 먼저 실행해 Q클래스가 생성된 경로를 지운 후 다시 ./gradlew build 하는 것으로 정상적으로 build 할 수 있었다.

오류에 대한 해결책일 뿐 근본적인 해결 방법은 아닌 듯 하다.
문제가 발생한 근본적인 원인은 생성된 Q클래스를 포함하여 레포지토리에 올린 것이다.

QueryDsl 설정 시 지정한 Q클래스가 생성되는 경로(src/main/generated)를 .gitignore 파일에 등록해주자.

정상적인 경우라면 위 과정으로 build 및 jar 파일 실행까지 문제없이 처리하여 프로젝트 배포를 완료할 수 있다.

하지만 보안상의 이유로 각종 보안키 들을 작성해둔 application.properies 파일이 github 레포지토리에서 제외해뒀기 때문에 이것을 clone하여 build한 jar 파일을 실행하는 위 과정에서 실행 중 에러가 발생했다.

CI/CD를 구축했을 경우, Github Actions에서 제공하는 Secrets에 application.properies의 내용을 등록해 배포 시 자동으로 application.properies를 생성할 수 있으나, CI/CD 구축 이전에 프로젝트 배포를 우선적으로 마무리 해볼 요량으로 개발환경(로컬)에서 build를 완료한 jar 파일을 서버에 직접적으로 전달하여 실행해보는 방법을 찾아보았다.

jar 파일 직접 전달

jar 파일 전달에는 FileZilla 를 사용하였다.

FileZilla
오픈 소스 FTP 클라이언트 소프트웨어로 사용자와 서버간 파일 송수신을 위한 프로그램

  1. 사이트 관리자 설정 실행
  2. 호스트에 앞서 설정한 EC2의 퍼블릭 IP 입력
  3. 로그온 유형을 키 파일로 선택
  4. 사용자에 사용자 이름(ubuntu 서버의 경우 ubuntu) 입력
  5. 키 파일(.pem 파일) 이 저장된 경로 선택
  6. 연결 확인
  7. 정상적으로 서버와 연결되었다면 로컬에 저장된 프로젝트 jar 파일을 서버의 저장경로에 전송(jar 파일 더블클릭)

이후 jar 파일 실행 방법은 위 과정과 똑같다.

sudo netstat -tnlp
sudo kill -9 <pid>
sudo nohup java -jar <프로젝트 이름>-0.0.1-SNAPSHOT.jar &

프로젝트 배포가 완료되었다.
이제 할당받은 퍼블릭 IP로 접근 할 경우 배포한 프로젝트에 정상적으로 접속할 수 있다.

레퍼런스

AWS RDS로 데이터베이스 환경을 만들어보자
Spring Boot로 AWS의 EC2 서버, RDS, S3 연결하기
[Spring] Spring Boot jar 파일을 AWS EC2에 배포하는 법
[프로젝트] QueryDSL 사용 시 Q클래스 import 불가 문제 해결 (gradle)

profile
승등
기록, 코딩보다 어렵다-!
이전 포스트

[프로젝트 배포] AWS EC2 인스턴스 생성

다음 포스트

[프로젝트 배포] Docker를 활용한 배포 및 CI/CD 구축

0개의 댓글