글 쓰는 시간

RDS

지금까지 EC2 인스턴스를 생성하고 이 인스턴스에서 서비스를 배포까지 하였다.

DB는 어떤 서비스든 필요할테니 이제 애플리케이션과 DB를 연동해야 한다.

스프링 서버와 동일한 EC2 인스턴스에서 인메모리로 데이터를 저장할 수도 있지만

이 경우 하나의 EC2 인스턴스가 죽을 경우 DB 데이터 또한 사라진다.

결국 여러 경우를 생각하면 DB는 따로 서버를 둬야한다는 결론이 나온다.

여기서 간단하게 생각하면 두 가지 선택지가 생긴다.

• DB를 띄운 EC2 인스턴스를 DB 서버로 이용한다.
• AWS RDS를 이용한다.

두 가지를 비교하자면 비용적인 측면에서는 EC2 인스턴스가 더 저렴하다.

반면 AWS RDS에서는 기본적인 설정은 AWS에서 마친 상태의 DB 서버를 제공해주므로 직접 설정해야하는 DB 설정이 많이 줄어든다.

매니지드(RDS) vs 언매니지드(EC2) 라고 할 수 있다.

프리티어로 RDS도 제공하므로 우선 RDS를 사용하고 추후 DB 설정 공부를 하고 EC2로 직접 DB 서버를 띄워보기로 했다.

1. RDS 인스턴스 생성

1-1. RDS 인스턴스 생성 페이지로 이동

1-2. DB 종류 선택

원하는 종류의 DB를 선택하면 된다.

본인은 써본게 이것 뿐이라 MySQL 8 버전을 선택하겠다.

1-3. 템플릿 선택

프리 티어를 선택하면 가용성 및 내구성은 설정할 수 없다.

1-4. DB 정보 설정

DB 이름, 마스터 이름, 비밀번호를 설정한다.

추후 애플리케이션이나 DBeaver에서 DB에 접근할 때 여기서 입력한 정보로 접속한다.

1-5. 인스턴스 구성 및 스토리지 설정

프리티어를 사용하므로 선택지는 거의 없다.

과금 가능성이 있는 설정만 주의하자.

1-6. 보안 그룹 설정 

EC2 컴퓨팅 리소스에 연결 안 함, 퍼블릭 액세스

로컬에서 DBeaver나 인텔리제이 등에서 MySQL로 DB를 직접 확인해보기 위해 퍼블릭 액세스를 열어두려 한다.

따라서 EC2 컴퓨팅 리소스에 연결 안 함, 퍼블릭 액세스를 허용하겠다.

VPC 보안 그룹

해당 보안 그룹을 통해 들어온 요청만 3306 포트로 받아주겠다는 의미다.

기존 항목을 선택해 내가 만든 EC2 인스턴스의 보안 그룹(여기서는 launch-wizard-1)을 선택하면 EC2 인스턴스의 요청을 받는다.

로컬에서도 DB에 접근하기 위해서는 default 보안 그룹을 추가하고 이 보안 그룹을 조금 수정할 것이다.

1-7. 추가 구성

그림에서 생략된 부분은 기본 설정을 따라가면 된다고 생각해서 굳이 추가하지 않았다.

2. RDS 인스턴스 생성 확인

위와 같이 설정하고 데이터베이스 생성을 하면 아래처럼 생성된 RDS 인스턴스를 확인할 수 있다.

인스턴스 생성까지 시간이 좀 걸린다.

RDS 인스턴스를 다시 만들어서 위 설정과는 DB 식별자가 조금 다를테지만 신경쓰지 않아도 된다.

참고 자료

보안그룹

보안 그룹은 AWS 에서 제공하는 방화벽 모음이다.
서비스를 제공하는 애플리케이션이라면 상관 없지도 모르지만,

RDS나 S3처럼 외부에서 함부로 접근하면 안되는 인스턴스는 허용된 IP 에서만 접근하도록 설정해야한다.

• 인바운드 (Inbound): 외부 -> EC2 인스턴스 내부 허용
• 아웃바운드 (Outbound): EC2 인스턴스 내부 -> 외부 허용

1. EC2 인스턴스의 보안 그룹 설정

1-1. 인스턴스에 적용된 보안 그룹 확인

인스턴스의 보안 탭으로 이동하면 현재 인스턴스에 적용된 보안 그룹을 확인할 수 있다.

인스턴스를 생성할 때 설정했던 SSH 트래픽 허용 설정도 보인다.

이제 이 보안 그룹의 인바운드/아웃바운드 설정을 편집할것이다.

1-2. 사이드 바에서 보안 그룹으로 이동 후 편집 창으로 이동

1-3. 원하는 인바운드 규칙으로 편집

인바운드 규칙은 위에서 설명했듯 외부에서 EC2 인스턴스로의 접근을 관리한다.

우선 로컬에서 SSH로 접근하는것과 8080 포트로 오는 요청만 허용한다.

필요 시 다른 포트도 추가하면 된다.

아웃바운드 규칙은 딱히 건들 필요 없으니 모든 IP에 대해 열어두는 기본 설정을 유지한다.

1-4. 인스턴스로 이동해서 인바운드 규칙 변경 확인

EC2 인스턴스 정보에서 보안 규칙이 잘 변경 됐는지 확인한다.

2. 보안 그룹 설정 변경 후 EC2의 스프링 부트 서버 접속

변경된 보안 규칙이 적용되는데 시간이 조금 걸릴 수 있으니 조금 기다렸다가 접속한다.

다시 요청을 하면 아래처럼 서버가 제대로 떠있고, 접속할 수 있음을 확인할 수 있다.

(본인은 스프링 부트 서버를 8082 포트로 열어서 인바운드 규칙을 8082로 바꿨다.)

EC2 인스턴스에 Spring Boot 서버 띄우기

저번 글에서 EC2로 jar 파일을 이동시켰다.

이제 이 jar 파일로 서버를 띄우기만 하면 된다.

하지만 EC2는 아직 생성한 상태 그대로이기 때문에 자바가 설치되어있지 않기 때문에 설치해야한다.

1. EC2 인스턴스에 JDK 설치

1-1. OS에 맞는 패키지 관리자로 JDK 설치

OS마다 패키지 관리자가 다르기 때문에 OS에 맞는 패키지 관리자로 JDK를 설치하면 된다.

본인은 ubuntu로 OS를 설정했기 때문에 apt를 사용한다.

설치는 되게 간단하게 아래 두 줄이면 JDK를 바로 설치할 수 있다.

// EC2 인스턴스에서
sudo apt-get update
sudo apt-get install openjdk-17-jdk

// apt나 apt-get이나 큰 차이는 없어서 뭘 쓰든 상관없다.

1-2. 자바 버전 확인

아래처럼 java -version 명령어로 자바 버전을 확인해서 확인 가능하면 설치가 잘 된것이다.

2. EC2에서 스프링 부트 서버 띄우기

jar 파일이 있는 경로에서

아래처럼 명령어를 입력하면 jar 파일로 스프링부트 서버를 띄울 수 있다.

또한 종료는 ctrl + C로 스프링 부트 서버를 종료시킬 수 있다.(종료까지 시간이 좀 걸릴 수 있음)

java -jar {jar파일 이름} &   

// 위에서 &는 안붙여도 되지만 &를 붙이면 백그라운드에서 실행 시켜서 다른 작업 가능

3. EC2에서 띄운 스프링 부트 서버에 접속

이제 http://{탄력적 IP}:8080 으로 접속하면 아래와 같은 창을 확인할 수 있다.

(실패하는게 당연함)

4. 실패한 이유

다른 설정을 하지 않고 이대로 접속하면 접속이 차단되는것은 정상적인 응답이다.

인스턴스의 보안 그룹 설정을 하지 않았기 때문에 기본 설정이 외부에서 오는 차단을 막기 때문이다.

따라서 다음 글에서 처럼 인바운드/아웃바운드 보안 그룹 설정을 하도록 한다.

scp(secure copy)

scp는 로컬 호스트와 원격 호스트 또는 두 개의 호스트 간에 파일을 전송하는 수단이다. 

SSH(Secure Shell)을 통한 파일 전송 방식이며 별도의 FTP 클라이언트를 설치하지 않아도 파일 송수신이 가능하다.

파일 전송을 하기 위해 비슷한걸로 rsync라는 것도 있다고 한다.

여기서는 scp를 통해 로컬에서 빌드한 jar 파일을 EC2 인스턴스로 전송해보도록 한다.

1. 스프링 빌드 파일 생성

1-1. 스프링 프로젝트 경로로 이동해서 빌드 파일 생성

본인은 빌드하다가 자바 버전 문제 때문에 이런 오류를 만나서 고생했다.

사용하는 CLI에 따라 명령어가 다를테지만 윈도우/Git Bash 기준으로는 아래처럼 한다.

1-2. 빌드 된 jar 파일 확인

사용 환경에 따라 맞는 방식으로 빌드를 하고 build/libs 폴더로 가면 

아래처럼 두가지의 jar 파일을 확인할 수 있다.

여기서 두 jar 파일을 간단히 설명하자면 아래와 같다.

• 위의 용량이 적은 plain이 붙은 jar 파일은 라이브러리 없이 순수한 jar 파일
• 아래의 용량이 큰 jar 파일은 라이브러리를 포함한 jar 파일

이 중 우리가 사용할건 아래의 jar 파일이다.

2. scp로 로컬 -> EC2로 파일 전송

2-1. 파일 전송 확인을 위해 EC2 접속

로컬과 EC2 두가지 상태를 동시에 비교하기 위해 CLI 창을 아래처럼 두개 이용한다.

2-2. scp를 이용해 파일 전송

scp는 ssh와 입력 파라미터가 비슷한데, 아래와 같은 양식으로 작성한다.

작성 코드 길이를 줄이기 위해 EC2 접속 방법 중 EC2 경로를 연결한 탄력적 IP 주소를 입력하는 방식을 선택했다.

scp -i {키 페어 파일 경로} {전송할 파일 경로} {전송받을 위치 경로}

전송받을 경로는 EC2에서 아래처럼 리눅스 명령어 pwd로 확인할 수 있다.

3. EC2에서 전송받은 파일 확인

로컬에서 EC2로 scp를 통해 파일을 전송하고 EC2에서 확인해보면 아래처럼 파일이 전송된걸 확인할 수 있다.

참고로 로컬 -> EC2로 파일 전송도 가능하지만, EC2 -> 로컬로도 파일 전송이 가능하다.

아래처럼 작성하면 EC2에서 로컬로 파일 전송을 할 수 있다.

SSH(Secure Shell Protocol)

SSH란 네트워크 프로토콜 중 하나이다.

컴퓨터와 컴퓨터가 인터넷과 같은 Public Network를 통해 서로 통신을 할 때  보안적으로 안전하게 통신을 하기 위해 사용한다.

대표적인 사용의 예는 다음과 같다.

• 원격 제어
• 데이터 전송

SSH를 통해 내 컴퓨터(로컬)에서 EC2 인스턴스로 접속해볼것이다.

그러면 로컬에서 EC2로 접속해서 인스턴스를 이리저리 건드려볼 수 있다.

이후 데이터 전송까지 진행해서 EC2 인스턴스에 스프링 부트 애플리케이션을 띄워볼것이다.

1. SSH로 EC2 인스턴스에 접속

1-1. 인스턴스로 이동해서 연결 버튼 클릭

1-2. 인스턴스 연결 방법 확인

AWS에서 EC2 인스턴스에 연결하는 방법을 너무 친절히 잘 알려줘서 적혀있는걸 따라만 해도 된다.

아래부터는 순전히 여기 적혀있는걸 따라하는 과정이다.

1-3. CLI(Git Bash)로 키 페어 위치로 이동

위 사진은 이전 EC2 인스턴스를 생성할 때 생성했던 키 페어 사진이다.

이제부터 EC2 인스턴스에 접근할 때 이때 만들었던 키 페어가 필요하다.

기본적으로 download 폴더에 있을 것이다.

본인은 이걸 바탕화면으로 옮겼기 때문에 desktop 경로로 이동했다.

1-4. 키 페어 권한 변경

chomd 커맨드로 키 페어의 권한을 변경해준다.

1-5. EC2 인스턴스 접속

이제 키 페어로 EC2 인스턴스로 이동하려면 아래와 같은 양식으로 입력하면 된다.

유저 이름은 OS마다 조금씩 다른데, 본인은 OS를 ubuntu로 했기 때문에 유저 이름은 ubuntu이다.

ssh -i {키 페어 파일 이름} {유저이름}@{EC2 인스턴스 주소}

혹은 아래 처럼 연결해둔 탄력적 IP나 public IP 주소로 접근도 가능하다.

(my-key.pem를 감싸는 " "는 생략 가능)

2. EC2 인스턴스 접속 확인

첫 접속때는 위와 같은 라인이 뜰 수도 있는데, yes를 입력하면 된다.

입력 커서가 가리키는 부분이 빨간 표시 영역처럼 바뀌면 접속에 성공한것.

참고로 EC2 인스턴스 접속을 끝내고 싶다면 ctrl + D 를 누르면 된다.

참고자료

탄력적 IP 

AWS 인스턴스는 중지/종료되면 새로운 IP를 할당받아 실행된다.

만약 오류가 생겨서 인스턴스를 종료하고 다시 실행해야 한다면 그때마다 IP가 변경되기 때문에 관련 설정을 다시 해줘야한다.

특히 배포 상태일 때는 도메인 관련해서도 IP를 매번 바꿔줘야하므로 탄력적 IP를 설정하는게 편하다.

중지 후 재 실행 결과

그래서 AWS로부터 고정된 IP를 할당 받아서 사용하는 기능이 탄력적 IP 이다.

탄력적 IP는 할당받으면 그대로 과금이 된다.

인스턴스에 적용하지 않아도 요금제 계산은 들어가니 필요한 만큼만 할당받아야 한다.

1. 탄력적 IP 할당

1-1. 탄력적 IP 탭으로 이동 후 탄력적 IP 주소 할당

1-2. 탄력적 IP 주소 할당

딱힌 건들 필요 없이 기본 설정대로 할당 받으면 된다.

1-3. 탄력적 IP 주소 연결

2. 탄력적 IP 연결 확인

번외) 탄력적 IP 릴리즈

프리티어가 끝나면 EC2 인스턴스를 종료해도 탄력적 IP는 남기 때문에 반드시 릴리즈 해줘야한다.

탄력적 IP 주소 연결 해제 후 릴리즈 하면 된다.

참고자료

서비스 배포

AWS EC2로 서비스 할 스프링 애플리케이션을 배포해보려고 한다.

이전 프로젝트에서도 배포는 내가 맡았지만 그땐 생각없이 따라했던게 컸던것 같다.

복습도 하면서 아직도 남아있는 배포에 대한 두려움도 지울겸 배포 과정을 정리해보려 한다.

EC2 인스턴스를 생성하고 Spring Boot 서버를 띄워보는 것까지 진행한다.

AWS 계정 만드는건 생략하고 진행한다.

1. EC2 인스턴스 생성

1-1. AWS Region 선택 후 EC2 탭으로 이동

아무래도 인스턴스 위치가 가까울 수록 속도도 나을테니 서울을 선택한다.

1-2. 리전 확인 후 인스턴스 시작

1-3. 인스턴스 이름 및 OS 설정

인스턴스 이름은 필요하다면 설정하고 OS는 편한걸 고르면 된다.

본인은 Ubuntu로 진행하려 한다.

1-4. 인스턴스 유형 설정

프리티어를 이용하기 때문에 사실 t2.micro 외엔 대안이 없긴 하다.

과금 의향이 있다면 규모에 맞는 인스턴스를 선택하면 된다.

1-5. 키 페어 생성

키 페어(로그인) 탭에서 새 키 페어 생성 버튼을 클릭하여 키 페어를 생성한다.

EC2 인스턴스와 SSH 접속을 할 때 이 키 페어가 필요하다.

한 번 다운 받으면 다시 받을 수 없으니 안전한 곳에 보관한다.

1-6. 네트워크 설정

내 IP에서 SSH 연결을 할 수 있도록 보안 그룹을 생성해서 등록한다.

추후 필요 시 보안그룹을 추가로 생성한다.

1-7. 스토리지 설정

인스턴스의 볼륨을 설정한다.

프리티어는 최대 30GB까지 지원하므로 30GB로 설정한다.

2. 생성된 EC2 인스턴스 확인

인스턴스 탭으로 이동하면 설정한대로 인스턴스가 만들어진걸 확인할 수 있다.

참고자료