[TIL - 29일 차] AWS 클라우드 (4)

배포부터 서비스 구성까지

AWS service를 사용하기 전에 이를 연결할 백엔드 프로젝트를 생성하고, 초기 세팅을 한 뒤 github의 repo에 업로드한다. 강의에서는 spring boot를 사용하였다.

구성도

VPC

Available Zone(AZ)은 두 개(2a, 2c)가 존재하며, 각각의 AZ는 public subnet과 private subnet으로 나뉜다.

VPC

VPC 생성

미리보기 형태는 다음과 같고 구성도처럼 AZ가 두 개 존재하고, 내부에 private subnet과 public subnet이 하나씩 존재하는 것을 확인할 수 있다. 또한 하나의 AZ에서 NAT 게이트웨이를 생성해 주었다. NAT 게이트웨이는 AWS에서 제공하는 네트워크 주소 변환 서비스로 private subnet 내의 인터넷, AWS service에 접근 가능하게 하고 외부에서는 해당 EC2에 대한 접근을 막기 위해 사용한다.

VPC

VPC 생성

Elastic Beanstalk & EC2

Elastic Beanstalk & EC2

Elastic Beanstalk 생성

각 private subnet에는 Elastic Beanstalk가 존재한다. 애플리케이션 이름, 환경 이름 등을 적절히 입력해주고 위에서 생성했던 VPC의 private subnet을 선택 후 Elastic Beanstalk를 생성한다.

Elastic Beanstalk 생성

EC2 생성

AZ 2a의 public subnet에는 baston host라는 EC2가 존재한다. 이름과 OS, 키페어 등의 설정을 해준 후 네트워크를 생성한 VPC의 public subnet으로 설정해 준다.

EC2 생성

Elastic Beanstalk 접속

콘솔을 통해 private subnet에 존재하는 Elastic Beanstalk에 접속하는 실습을 진행한다. 위에서 생성했던 EC2는 public subnet에 설치되었기 때문에 public ip로 자유롭게 접속이 가능하지만, Elastic Beanstalk는 private subnet이기 때문에 public ip로 접속이 불가능하다. 따라서 public subnet에 존재하는 EC2를 경유하여 접속해야 한다.

키페어 등록

public subnet의 EC2와 동일한 키페어로 Elastic Beanstalk 구성의 '보안' 목록에서 키페어를 등록해 준다. 실습에서는 동일한 키페어를 사용했는데, 다른 키페어를 사용해도 되는지는 모르겠다.

EC2 접속 및 키 저장

public subnet의 EC2에 접속하여 Elastic Beanstalk에 등록한 키페어의 키를 .ssh 폴더에 저장한다.

Elastic Beanstalk 접속

이전까지는 서버 외부에서 public ip를 통해 서버에 접속했지만, 여기서 Elastic Beanstalk에 접속하기 위해서는 public subnet의 EC2에 접속 한 뒤 private ip를 입력하고 접속해야 한다. 

## EC2에 먼저 접속
ssh -i key.pem ec2-user@public_ip

## Elastic Beanstalk에 접속
ssh -i key.pem ec2-user@private_ip

RDS

RDS도 Elastic Beanstalk처럼 private subnet 영역에 존재하기 때문에 외부에서 바로 접속이 불가능하다. 여기서도 위와 마찬가지로 baston host를 경유하여 RDS에 접속이 가능하다. SSH 터널링을 통해 baston host -> RDS 경로로 접속이 되며, SSH Hostname에는 baston의 public ip, username에는 ec2-user, key file에는 키페어에 등록된 키를 넣어주면 된다.

RDS

SSH 터널링을 통한 RDS 접속

DB subnet 그룹 생성

RDS를 생성하기 전에 VPC의 private subnet을 선택하여 DB subnet 그룹을 생성한다.

DB subnet 그룹 생성

RDS 생성

미리 생성했던 VPC와 DB subnet 그룹 및 AZ를 선택하고 RDS를 생성한다. 보안 그룹의 인바운드 규칙에는 꼭 3306 포트가 존재해야 접속이 가능하다.

RDS 생성

프론트 구성

S3 버킷 생성을 통해 프론트를 서비스할 수 있다. 강의에서는 react를 기준으로 설명한다.

Amazon S3

S3 버킷 생성

버킷 이름은 사용할 도메인 주소과 동일하게 작성하고 생성한다. 또한 정적 웹 사이트 호스팅 편집에서 build된 react 파일들을 업로드하고, 퍼블릭 액세스 차단을 해제 및 정책 생성기를 통해 S3 정책을 생성한다. 이후 S3의 앤드포인트에 접속하면, 해당 웹 사이트에 접속이 가능하게 된다.

S3 정책 생성

CI/CD

CI/CD

CodePipeline 생성

적절한 이름을 작성해 주고, 소스는 github를 선택하여 연결해 준다. 강의에서는 CodeBuild, CodeDeploy를 미리 생성해 두었기 때문에 바로 진행될 수 있었지만, 그렇지 않다면 CodePipeline을 생성하기 전에 생성해 두면 된다.

CodePipeline 생성

CodeBuild

CodeDeploy

아래와 같이 적은 appspec.yml 파일을 생성해서 프로젝트의 최상단에 위치시켜야 Deploy가 올바르게 작동한다.

// appspec.yml
version: 8.8
os: linux
files:
  - source: /
    destination: /home/ec2-user/build/

Route53 & Cloud Front

호스팅을 하기 위한 방법은 두 가지가 있다. AWS에서 도메인을 구입해 사용하는 것과 외부 도메인 사이트에서 구입한 도메인을 활용하는 것이다. Route53까지 설정을 완료하면 'www.citron.com'과 같은 도메인으로 해당 페이지에 접속이 가능해진다. 도메인에서 S3를 직접 저장하는 것이 아니라 Cloud Front를 구성하여 진행한다.

route53 & Cloud Front

Cloud Front 생성

이전에 생성했던 S3 버킷을 연결하고, Certification Manager에서 서비스할 도메인의 SSL을 생성하여 등록한다.

Route53 생성

도메인 이름에 사용할 도메인을 입력하고 Route53을 생성한다. 이후 레코드 생성을 통해 단순 레코드를 정의해 준다. 만약 CloudFront를 사용하는 것이 아니라 바로 S3을 통해 배포를 하려면, 라우팅 대상을 'S3 웹 사이트 엔드포인트에 대한 별칭'을 선택하면 된다.

Route53 생성

AWS CLI

아래의 명령어로 AWS CLI를 설치하고 설치 유무를 확인해 볼 수 있다.

## install
msiexec.exe /i https://awscli.amazonaws.com/AWSCLIV2.msi

## install check
aws --version

AWS configure

AWS CLI를 설치한 이후 aws configure을 통해 설정을 해주어야 한다. 초기 설정을 통해 본인의 계정의 인스턴스에 접근하여 작업할 수 있다. 그전에 IAM의 사용자를 먼저 생성해야 한다.

IAM 사용자 생성 및 액세스 키 생성

cli-test라는 사용자를 생성하였다. AWS CLI를 사용하기 위해서는  해당 사용자의 액세스 키를 생성해주어야 한다.

IAM 사용자 생성

사용자 액세스 키 생성

aws configure

위에서 생성한 키를 바탕으로 aws configure을 진행하면 된다. 액세스 키와 비밀 액세스 키를 입력하고, 지역에는 'ap-northeast-2'를 입력해 주었다. 이후 aws configure list를 통해 정보를 확인할 수 있다.

aws configure list

명령어

존재하는 s3을 확인할 수 있다.

aws s3 ls

'name'이라는 이름을 가진 s3을 생성한다.

aws s3 mb s3://name

현재 폴더의 파일을 s3에 저장한다.

aws s3 sync . s3://name

s3에 존재하는 파일을 모두 제거한다. 여기서 --recursive는 하위 폴더까지 모두 제거하는 것을 의미한다.

aws s3 rm s3://name --recursive

참고링크

AWS NAT gateway란?

https://jaykos96.tistory.com/12