[Deploy] Amazon Web Service

이성은·2023년 2월 2일

aws deploy 코드스테이츠

1. Amazon Web Service

아마존 웹 서비스(AWS)
- 아마존이 자사의 노하우를 살려 제공하고 있는 ‘클라우드 컴퓨팅 서비스'
- 컴퓨팅, 스토리지, 데이터베이스, 분석, 네트워킹, 모바일, 개발자 도구, 관리 도구, IoT, 보안, 엔터프라이즈 애플리케이션 등 다양한 서비스가 준비되어 있으며, AWS의 다양한 서비스를 조합하여 모든 애플리케이션과 인프라를 구축할 수 있기도 하다.
- 일전에는 여러 사업자에게 각각 빌려야 했던 인프라를 일괄로 빌릴 수 있게 됐으며, 필요에 따라 운영체제(OS), 웹 서버, DB 서버 등 필요한 소프트웨어까지 통째로 사용할 수 있는 편리한 서비스이다.
AWS 특징
- 서비스를 조합하기 쉽다. AWS에서만 제공하는 서비스로도 필요한 기능을 대부분 구축 가능하며, AWS와 AWS 외부 시스템을 조합하여 구축하기 쉽다.
- 앞으로 사용할 양을 미리 생각하지 않고 현재 필요한 만큼만 사용하고 부족해지면 그때마다 추가할 수 있으며, 같은 양을 계속 빌려야 하는 정액제와 차별점이 있다.
- 네트워크 및 서버가 매우 큰 규모가 아니라면 네트워크나 서버 전문가가 아니더라도 사용 가능하다.
- 전세계 21개 리전 66개의 시설(가용 영역)에서 데이터 센터 운영하고 있어, 글로벌로 확장 시 확장하고자 하는 지역과 지리적으로 가까운 리전에서 서비스 시작 가능하다.
- 한국어 지원 및 원화 결제 가능하며, 보안 관련하여 법령, 규정, 프라이버시 기준을 준수하고 있는 안전한 서비스이다.

1-1. Cloud Computing

기존서버의 방식
- 서버실과 같은 곳에 컴퓨터를 배치하고 인터넷을 연결하여 서비스를 제공
- 주기적인 관리가 필요
- 공간의 한계가 있다.
최근의 가상화 기술을 사용하는 클라우드 서비스
- 장점
  - 필요할 때마다 컴퓨팅 능력을 유연하게 조절
  - 고정적인 비용이 들어가는 온프레미스와는 달리 사용한 만큼의 요금만 지불
  - 컴퓨터의 스냅샷("이미지"라고 부릅니다) 을 이용해 다른 컴퓨터로 즉시 이주(migration)가 가능
- 단점
  - 운영 환경 자체가 클라우드 제공자에게 종속되어 버리므로, 클라우드 서비스에 문제가 생기면 내가 배포하고 관리하는 환경에도 영향이 미친다.
- 클라우드 서비스의 형태
  - Software as a Service(SaaS) : 클라우드 제공자가 당장 사용 가능한 소프트웨어를 제공하는 경우 대부분 SaaS에 해당
  - Platform as a Service(PaaS) : 클라우드 제공자가 데이터베이스, 개발 플랫폼까지 제공하는 경우 대부분 PaaS에 해당
  - Infrastructure as a Service(IaaS) : 클라우드 제공자가 가상 컴퓨터까지 제공하는 경우 대부분 IaaS에 해당
AWS는 IaaS에 가깝다

1-2. EC2

EC2 (Elastic Compute Cloud)
- 아마존 웹 서비스에서 제공하는 클라우드 컴퓨팅 서비스
- 클라우드 컴퓨팅은 인터넷(클라우드)을 통해 서버, 스토리지, 데이터베이스 등의 컴퓨팅 서비스를 제공하는 서비스
- 즉 아마존에서 가상의 컴퓨터를 한 대 빌리는 것
- 사용한 만큼비용을 지불
- AWS에서 비용, 성능, 용량 면에서 탄력적인 클라우드 컴퓨터를 제공하는 서비스
- EC2를 통해서 할 수 있는 가장 기본적인 일은
  웹서버를 설치하고 웹 서버를 통해서 사용자가 웹 브라우저를 통해 요청하는 서비스를 제공하는 것
EC2 장점
- 구성하는 데 필요한 시간이 짧다
- AMI를 통해서 필요한 용도에 따라 다양한 운영체제에 대한 선택이 가능, CPU와 RAM, 용량까지도 손쉽게 구성
- 컴퓨터를 한 대 빌리는 것이므로 컴퓨터로 할 수 있는 모든 일을 할 수 있다.
AMI(Amazone Machine Image)
- 소프트웨어 구성이 기재된 템플릿
- 이미지 종류로는 단순히 운영체제(윈도우, 우분투 리눅스 등)만 깔려있는 템플릿을 선택할 수도 있고, 아예 특정 런타임이 설치되어 있는 템플릿이 제공되는 경우도 있다. (우분투 + node.js, 윈도우 + JVM 등)
- Instance는 선택한 AMI를 토대로 구성
- 세팅되어 있는 AMI 이외에도 필요에 따라 직접 AMI를 구성할 수도 있다.

1-3. RDS

RDS(Relational Database Service)
- AWS에서 제공하는 관계형 데이터베이스 서비스
왜 RDS를 사용할까?
- EC2 인스턴스를 사용하면 데이터베이스와 관련해서 자동으로 관리를 담당하는 부분이 매우 적기 때문에, 사용자가 일일이 시간을 투자하여 데이터베이스 엔진의 설치와 버전 관리, 데이터 백업을 해야 한다.
  게다가 가용성과 내구성이 확보되지 않기 때문에 데이터베이스에 저장된 데이터가 유실되거나 정상적으로 사용하지 못할 확률이 커지며, 후에 필요에 따라 데이터베이스의 규모를 확장하기 어렵다.
- RDS를 이용하면 데이터베이스 유지 보수와 관련된 일들을 RDS에서 전적으로 자동 관리한다. 사용자가 해야 할 일은 초기 설정을 제외하고 데이터베이스에 저장된 데이터를 관리하는 일 밖에 없기에 큰 편의성을 느낄 수 있다.
- 또한 RDS 이용 시 얻을 수 있는 장점으로 다양한 데이터베이스 엔진 선택지를 제공한다.

1-4. S3

클라우드 스토리지
- 인터넷 공간에 데이터를 저장하는 저장소
- 구글의 Google Drive, 네이버의 MYBOX, 마이크로소프트의 Onedrive와 같은 서비스
- 장점 : 클라우드 스토리지 서비스는 뛰어난 접근성을 가지고 있다. 웹 환경이라면 언제 어디서나 저장된 파일에 접근할 수 있다.
S3(Simple Storage Service)
- AWS에서 제공하는 클라우드 스토리지 서비스
- 뛰어난 접근성
- 높은 확장성 : 확장성이 높으면 많은 시간과 수고를 들이지 않고 스토리지 규모를 확장/축소할 수 있다.
- 스토리지의 용량을 무한히 확장할 수 있다. 그리고 사용한 만큼만 비용을 지불하면 되기 때문에 비용적인 측면에서 매우 효율적이다.
- 스토리지의 내구성이 높다.
- 가용성이 높다. => 스토리지에 저장된 파일들을 정상적으로 사용할 수 있는 시간이 길어진다.
리전(Region)
- 리전이란 AWS에서 클라우드 서비스를 제공하기 위해서 운영하는 물리적인 서버의 위치
- 리전(Region)은 전세계 여러 지역에 서버와 데이터 센터를 갖고 있으며 이를 지리적으로 분류한 것
- 가용 영역(AZ)은 각각 물리적으로 격리되어 있으나, 좋은 품질의 네트워크 연결을 통해 논리적으로 연결되어 있어 서비스의 완전 중단을 방지한다.
- 리전(Region)에 따라 제공되는 서비스와 제공되지 않는 서비스가 있으며, 제공하지 않는 서비스는 다른 리전(Region)을 선택해 사용해야 한다.
- 각 리전(Region)에는 여러 가용 영역(AZ)이 각각 물리적으로 독립된 설비로 설치되어 있다. 이는 데이터 센터의 설비가 여러 장소에 분산되어 있는 격과 같다.
- 지도를 다시 보시면 주황색 동그라미 안에 숫자가 새겨져 있는데, 이 숫자는 리전에 위치한 가용 영역의 수
- 가용 영역(Availability Zone)이란 각 리전 안에 존재하는 데이터 센터(IDC)를 뜻한다.
- 가용 영역은 각각 개별적인 위치에 떨어져서 존재한다. 그래서 한 곳의 가용 영역이 재난이나 사고로 인해 가동이 불가능해지더라도 다른 가용 영역에 백업을 해놓은 데이터를 활용하여 문제없이 서버가 가동되게 한다.
S3는 다양한 스토리지 클래스를 제공
- Standard 클래스
  - 범용적인 목적으로 사용
  - 데이터에 빠른 속도로 접근할 수 있고, 데이터 액세스 요청에 대한 처리 속도가 빠르다.
  - 대신 보관 비용이 높게 발생하기 때문에, 데이터를 오래 보관하는 목적으로는 효율적인 선택지가 아니다.
- Glacier 클래스
  - 장기적인 보관 목적으로 스토리지를 사용
  - 비록 저장된 데이터에 액세스하는 속도는 느리지만, 데이터를 보관하는 비용이 매우 저렴하다는 장점이 있다.
- 이 외에도 Standard-IA, One Zone-IA, S3 Glacier Deep Archive 등등 여러 가지 스토리지 클래스가 존재하여 사용자의 이용 목적에 따라 다양한 스토리지 클래스를 사용할 수 있다.
S3 사용 시 얻는 이점
- 정적 웹 사이트 호스팅이 가능
  - 정적 파일 : 서버의 개입 없이 생성된 파일
  - 동적 파일 : 반대로 클라이언트가 서버에 요청을 보내면, 서버가 요청에 맞추어 그 자리에서 생성한 파일
  - 웹 호스팅(Web Hosting) : 서버의 한 공간을 임대해 주는 서비스
- S3에서는 버킷이 사용자들이 정적 웹 사이트를 배포할 수 있는 공간을 제공
  - 버킷이라는 저장 공간에 정적 파일을 업로드하고, 버킷을 정적 웹 사이트 호스팅 용도로 구성하면 정적 웹 사이트를 배포할 수 있다.
버킷
- S3에 저장되는 파일들이 담기는 바구니
- 파일을 저장하는 최상위 디렉터리라고도 설명할 수 있다.
- S3에서 저장되는 모든 파일은 버킷 안에 저장되어야 하고, 버킷에는 무한한 양의 파일을 저장할 수 있다.
- 각각의 버킷은 이름을 가지고 있는데, 버킷의 이름은 버킷이 속해 있는 리전(버킷이 생성된 지역)에서 유일해야 한다.
- 버킷 정책을 생성하여 해당 버킷에 대한 다른 유저의 접근 권한을 수정할 수 있다.
객체
- S3에서 버킷에 담기는 파일
- S3에서 저장소에 데이터를 저장할 때 키-값 페어 형식으로 데이터를 저장
- 객체는 고유한 URL 주소를 가지고 있다.
  => URL 주소는 http://[버킷의 이름].S3.amazonaws.com/[객체의 키]의 형태를 띠고, URL 주소를 통해서도 원하는 데이터에 접근
- S3에 저장되는 객체는 파일과 메타데이터로 구성
  - 파일
    - 키-값 페어 형식으로 데이터를 저장, 파일의 값에는 실제 데이터를 저장(최대 크기는 5TB)
    - 파일의 키는 각각의 객체를 고유하게 만들어주는 식별자 역할, 파일의 키를 이용하여 원하는 객체를 검색할 수 있다.
  - 메타데이터
    - 객체의 생성일, 크기, 유형과 같은 객체에 대한 정보가 담긴 데이터,
    - 객체를 설명하는 데이터

1-5. 배포 전략

client application 배포

AWS에서 제공하는 서비스인 S3라는 서비스를 통해 사용자들에게 client application 제공
클라이언트 앱을 정적 파일로 빌드하여 제공, 따라서 S3를 이용해서 클라이언트를 배포
빌드
- 불필요한 데이터를 없애고, 여러 갈래로 퍼져있는 데이터들을 통합/ 압축하여 배포하기에 최적화된 상태를 만드는 것
- 빌드 과정을 진행하기 전과 비교했을 때 데이터의 용량이 줄어들고, 웹 사이트의 로딩 속도가 빨라진다는 장점이 생긴다.
- 웹 앱은 배포 가능한 정적 파일(static files)의 형태로 만들어 줘야 한다.
- asset 자체가 정적인 경우, 있는 그대로 배포
- React의 경우 npm run build와 같은 명령을 사용해서, 정적 파일 형태의 결과물을 만들어 낸 후 배포
AWS에서 제공하는 CDN 서비스인 CloudFront를 통해서 각지의 데이터 센터에 데이터를 분산시켜서 저장해 뒀다가 가까운 지역에서 데이터를 주는 방식으로 사용자에게 더 빠르게 서비스를 제공할 수 있다.

Server Application 배포

AWS EC2 서비스를 통해 손쉽게 서버를 구성하고 서비스를 제공
AWS에서는 Database 특화 서비스인 RDS 서비스를 제공
AWS가 유지 보수 작업을 담당하는 RDS를 이용하여 즉시 데이터베이스를 사용할 수 있다.
RDS 서비스를 이용하여 EC2를 통해 배포된 Server Application의 데이터를 저장, 제공하는 데이터베이스를 배포할 수 있다.
AWS에서 제공하는 Route 53 서비스를 이용하면 직관적인 도메인 주소를 통해서 서비스에 접근하도록 할 수 있다.

1-6. Deploy

배포: 여러분이 개발한 서비스를 사용자들이 이용 가능하게 하는 일련의 과정
Development 단계
- 각자의 컴퓨터에서 코드를 작성하고 테스트하는 과정
- 개발 단계이기 때문에 실제 데이터를 이용하지 않고 더미 데이터를 이용해서 테스트
Integration 단계
- 각자의 컴퓨터에서 작성한 코드를 합치는 과정
- 내가 작성한 코드가 다른 코드를 침범해서 오류를 일으키지 않는지, 코드 간에 conflict가 있지는 않은지 확인하는 과정을 거친다.
Staging 단계
- 실제 출시 단계인 Production 단계와 가장 유사한 환경에서 테스트를 진행
- 실제 데이터를 복사해서 문제가 있지 않은지 등 다양한 환경에서 테스트를 진행
- 서비스와 관련된 부서 혹은 인원의 확인 과정을 거친다.
Production 단계
- 개발된 서비스를 출시하는 단계
- 사용자가 접속할 수 있는 Production 환경에서 코드를 구동하고 서비스를 제공
- 실제 데이터를 가지고 서비스가 운영되기 때문에 문제가 생기면 안 되는 단계

2. 백엔드 배포 실습

IAM 확인 및 로그인 튜토리얼

섹션 시작 전에, 자신의 메일로 AWS IAM 정보를 전달받는다.
AWS IAM에 로그인
리전을 서울로 변경

EC2 인스턴스 연결 튜토리얼

실습에서 사용하는 EC2는 미리 생성이 되어있다.
AWS 콘솔에서 EC2를 검색하거나, 직접 클릭해서 EC2 대시보드로 이동

3.실행중인 인스턴스에서 자신의 IAM 로그인을 검색, 자신만 사용할 수 있는 EC2 인스턴스를 클릭하고, "연결"을 클릭
세션 매니저 이용해서 웹브라우저 환경에서 터미널 실행
터미널을 bash 로 변경

$ bash
$ cd ~

EC2 인스턴스 상에서 서버 실행 튜토리얼

1. 인스턴스에 개발 환경 구축하기

$ sudo apt update
$ nvm install node 
$ sudo apt install npm

2. git을 통해 서버 코드 클론 받기

Git 환경설정에서 SSH키 생성

SSH키 : CLI 환경(터미널)에서 다른 PC에 접속하거나 요청할 때 사용하며, 비대칭키를 이용해 사용자를 인증

ssh-keygen

생성된 키 페어 중 공개키를 복사하여 gitub에 등록

공개키(Public Key) 복사

cat ~/.ssh/id_rsa.pub

3. Github에 공개키 등록=> 우측 상단의 프로필 이미지를 클릭하고, Settings=> 왼쪽의 내비게이션에서 SSH and GPG keys 를 선택

New SSH Key 를 클릭
등록한 SSH 공개키를 구분할 수 있도록 사용자 임의로 Title을 작성
그리고 Key에는 복사해둔 공개키를 붙여 넣고, Add SSH Key 버튼을 클릭

4.홈 디렉토리로 이동

ssm-user@ip-172-31-33-2:~$ cd ~

git clone

ssm-user@ip-172-31-33-2:~$ git clone https://github.com/codestates-seb/fe-sprint-practice-deploy.git
Cloning into 'fe-sprint-practice-deploy'...
...

git clone 확인

ssm-user@ip-172-31-33-2:~$ ls
fe-sprint-practice-deploy

터미널을 통해 스프린트 코드 안의 server 디렉토리로 이동

cd fe-sprint-practice-deploy/server/

server 폴더로 이동한 뒤, npm install 명령어를 입력해서 필요한 모듈을 다운

3. EC2 인스턴스에서 서버 실행하기

sudo npm start

4. EC2 인스턴스의 IP 주소로 접근하기

EC2 인스턴스의 IP 주소로 접근해서 테스트를 진행
=> IP 주소는 EC2 대시보드에서 생성한 EC2 인스턴스를 클릭하면 확인
두 가지 형태의 주소가 존재하는 것을 확인 => 둘 중 어떤 주소를 사용해도 문제가 없다.
EC2 인스턴스의 IP 주소로 접속했을 때(이번에 구현한 서버는 HTTP로 통신), hello world를 확인할 수 있으면 성공

3. 프론트엔드 배포 실습

S3 정적 웹 호스팅 튜토리얼

AWS 콘솔에서 S3를 검색
자신의 github login id로 검색하면 자신의 버킷을 검색

3.배포 시 정확한 서버로 요청을 보내기 위해 .env 파일을 생성
=> REACT_APP_API_URL의 값으로 EC2 서버의 주소를 넣는다.

4.npm install, npm run build후에 build 디렉터리에서 확인
5. build 디렉터리의 모든 파일을 자신의 버킷의 루트 경로에 넣는다. build 폴더 자체를 넣지 않도록 주의!!=> 업로드 성공 확인 => 닫기 => 자신의 버킷으로 돌아가기

6. 파일들 업로드 확인

7. 속성 탭으로 들어가,맨 밑의 정적 웹 사이트 호스팅 섹션을 확인
=> 버킷 웹 사이트 엔드포인트가 생성되어 있는 걸 확인, 해당링크로 접근

8. 화면이 뜨는 것을 확인

9. 아이디에 김코딩, 비밀번호는 1234