AWS

클라우드 컴퓨팅

• 서버의 자원과 공간, 네트워크 환경 제공 ("온프레미스")
• 컴퓨팅 능력을 유연하게 조절
• 사용한 만큼의 요금만 지급
• 다른 컴퓨터로 즉시 이주 가능
• 가상 컴퓨터를 대여
• 운영 자체가 클라우드 제공자에게 종속되므로, 클라우드 서비스에 문제가 생기면 나의 배포, 관리 환경에도 문제가 된다.

클라우드 서비스 형태

• SaaS (Software as a Service)
  : 당장 사용 가능한 소프트웨어인 경우
• PaaS (Platform as a Service)
  : 데이터베이스, 개발 플랫폼까지 하는 경우
• IaaS (Infrastructure as a Service)
  : 가상 컴퓨터까지 제공하는 경우

Deploy

배포란?
: 개발한 서비스를 사용자가 이용가능하게 하는 과정

유의할 점
1) 환경의 차이를 이해하고 환경 설정을 코드와 분리하는 것이 중요하다.
2) 절대 경로 대신 상대 경로를 사용한다.
3) 환경에 따라 포트를 분기할 수 있도록 환경 변수를 설정한다. 'env'
4) Docker와 같은 개발 환경 자체를 통일시키는 솔루션을 사용한다. (환경 자체를 메타데이터로 담아서 아예 모든 개발 환경을 통일)

EC2 (Elastic Compute Cloud)

: aws에서 원격으로 제어할 수 있는 가상의 컴퓨터를 한 대 빌리는 것
: aws에서 제공하는 클라우드 컴퓨팅 서비스다.
: 클라우드 컴퓨팅 서비스다.(클라우드를 통해 서버, 스토리지, 데이터베이서 등의 컴퓨팅 서비스를 제공하는 것)

EC2 특징

• 구성하는데 필요한 시간이 짧다.
• AMI를 통해 다양한 운영체제 선택이 가능하다.
  => CPU, RAM, 용량까지 손쉽게 구성
• 컴퓨터를 한 대 빌리는 것이므로 컴퓨터로 할 수 있는 모든 일을 할 수 있다. (하나의 Instance)
  => 이 컴퓨터는 데이터센터에 있음

AMI(Amazon Machine Image)

: 소프트웨어 구성이 기재된 탬플릿이다.

• 이미지 종류로는 단순히 운영체제(윈도우, 우분투 리눅스 등)만 깔려있는 템플릿을 선택할 수도 있고, 아예 특정 런타임이 설치되어 있는 템플릿이 제공되는 경우도 있다. (우분투 + node.js, 윈도우 + JVM 등)
  

결론

즉, AWS EC2 인스턴스를 생성한다는 것은 AMI를 토대로 운영체제, CPU, RAM, 런타임 등이 구성된 컴퓨터를 빌리는 것이다.

RDS (Relational Database Service)

: AWS에서 제공하는 관계형 데이터베이스 서비스

EC2 인스턴스에 데이터베이스 설치 VS RDS

EC2 인스턴스에 MySQL 같은 관계형 데이터베이스 엔진을 설치하면 굳이 RDS를 사용할 이유가 없지 않을까?

=> RDS를 이용하면, 사용자가 초기 설정을 제외하고 데이터베이스에 저장된 데이터를 관리하는 일 밖에 없어 큰 편의성을 느낄 수 있다.

RDS 사용의 이점

=> 데이터베이스 엔진마다 제공하는 기능이 조금씩 다르기 때문에 필요와 목적에 맞게 데이터베이스 엔진을 선택해 효율성을 높이자.

S3 (Simple Storage Service)

클라우드 스토리지

:인터넷 공간에 데이터를 저장하는 저장소
예) 구글의 Google Drive, 네이버의 MYBOX, 마이크로소프트의 Onedrive

클라우드 스토리지 서비스 장점

• 뛰어난 접근성

S3

: AWS에서 제공하는 클라우드 스토리지 서비스다.

특징)

• 높은 확장성
  => 많은 시간과 수고를 들이지 않고 스토리지 규모를 확장/축소할 수 있다.
• 용량을 무한히 확장할 수 있다.
• 사용한 만큼만 비용을 지불하면 된다.
• s3 내구성이 높아, 저장된 파일을 유실할 가능성이 적다.
• 가용성이 높다.
  => 스토리지에 저장된 파일들을 정상적으로 사용할 수 있는 시간이 길어진다.
• 다양한 스토리지 클래스를 제공한다.
  => 어떤 목적으로 저장소를 활용할지에 따라 효율적으로 스토리지 클래스를 선택한다.
  => Standard 클래스와 Glacier 클래스가 대표적이다.

Standard 클래스와 Glacier 클래스

Standard 클래스

• 범용적인 목적
• 데이터에 빠른 속도로 접근
• 데이터 액세스 요청에 대한 처리 속도가 빠르다.
• 데이터를 오래 보관하는 목적으로는 보관 비용이 높게 발생
  Glacier 클래스
• 데이터의 장기보관 목적
• 저장된 데이터에 액세스하는 속도는 느리다.
• 데이터를 보관하는 비용이 매우 저렴하다.

S3 사용시 이점

정적 웹 사이트 호스팅이 가능

• 정적 파일은 서버의 개입 없이 생성된 파일을 발한다. (동적 파일은 클라이언트가 서버에 요청을 보내면, 서버가 요청에 맞추어 그 자리에서 생성한 파일)
• 웹 호스팅이란 서버의 한 공간을 임대해주는 서비스
  => 웹 호스팅 업체가 제공하는 서버의 한 공간을 빌려서 원하는 서비스를 배포할 수 있다.

결론) S2에서는 버킷이 사용자들이 정적 웹 사이트를 배포할 수 있는 공간을 제공한다. 버킷이라는 저장 공간에 정적 파일을 업로드하고 버킷을 정적 웹 사이트 호스팅 용도로 구성하면 정적 웹 사이트를 배포할 수 있다.

버킷

• S3에 저장되는 파일들이 담기는 바구니
• 파일을 저장하는 최상위 디렉터
• 무한한 양의 파일을 저장할 수 있다.
• 각각의 버킷은 이름을 가지고 있다.
• 버킷의 이름은 버킷이 속해 있는 리전에서 유일해야 한다.
• 버킷 정책을 생성해 해당 버킷에 대한 다른 유저의 접근 권한 수정 가능

객체

• 버킷에 담기는 파일
• S2에서 저장소에 데이터를 저장할 때 키-값 페어 형식으로 데이터를 저장하기 때문에 객체라 부른다.
• 객체는 파일과 메타데이터로 구성된다.
  1) 파일
  => 실제 데이터를 저장한다.
  => S3 객체의 값으로써 저장할 수 있는 데이터 최대 크기 5TB
  => 파일의 키는 각각의 객체를 고유하게 만들어주는 식별자 역할
  => 파일의 키를 이용하여 원하는 객체를 검색할 수 있다.
  2) 메타데이터
  => 객체의 생성일, 크기, 유형과 같은 객체 정보가 담김
  => 객체를 설명하는 데이터임
  => 모든 객체는 고유한 url주소를 가지고 있다.
  => URL 주소를 통해 객체에 접근 가능
  => URL 주소형식: http://[버킷의 이름].S3.amazonaws.com/[객체의 키]

배포 전략 (Deploy Strategy)

그동안은, 로컬 환경에서 클라이언트와 서버와 데이터베이스를 띄어서 작성한 코드를 구동하고 확인했다.

내가 개발한 서비스를 외부에서 사용자들이 접속할 수 있게 하려면 배포를 해야한다

1. 사용자들에게 Client 어떻게 제공?

AWS에서 제공하는 서비스인 S3라는 서비스를 통해 사용자들에게 Client를 제공할 수 있다.

의문) 클라이언트를 위해서 EC2 인스턴스도 사용해야 할까?
=> 아니다. 클라이언트 앱을 정적 파일로 빌드해 제공한다.
즉, S3만 이용해 클라이언트를 배포한다.

빌드란?

• 불필요한 데이터를 없애고 통합/압축해 배포하기 위한 최적화 상태
  => 데이터의 용량이 줄어든다.
  => 웹 사이트 로딩 속도가 빨라진다.

일반적인 의미의 빌드

• 소스코드를 실행 가능한 번들로 변환하는 컴파일 과정을 의미한다.
• 웹 앱에서와 같이 HTML,CSS,JS의 형태로 배포할때는 배포 가능한 정적 파일의 형태로 만들어줘야 한다.
• assert 자체가 정적이라면 그대로 배포하고
• react 경우 npm run build 명령어를 사용해 정적 파일 형태의 결과물을 만들어 낸 후 배포하면 된다.

멀리 있는 사용자에게 더 빠르게 서비스를 제공하고 싶을 때

: AWS에서 제공하는 CDN 서비스인 CloudFront를 통해서 각지의 데이터 센터에 데이터를 분산시켜서 저장해 뒀다가 가까운 지역에서 데이터를 주는 방식으로 사용자에게 더 빠르게 서비스를 제공할 수 있다.

2. Client 받은 사용자들이 서비스를 이용하기 위한 요청을 처리할 Server를 어떻게 제공?

AWS EC2 서비스를 통해 손쉽게 서버를 구성하고 서비스를 제공할 수 있다.

3. Server의 데이터를 저장하고 제공할 Database 어떻게 제공?

• AWS에서는 Database 특화 서비스인 RDS 서비스를 제공한다.
• AWS가 유지 보수 작업을 담당하는 RDS를 이용하여 즉시 데이터베이스를 사용할 수 있다.

RDS 서비스를 이용하여 EC2를 통해 배포된 Server Application의 데이터를 저장, 제공하는 데이터베이스를 배포할 수 있다.

DNS

우리가 처음 배포한 서비스는 도메인 주소를 통해 접근할 수 없다.
=> S3, EC2를 이용해서 배포된 서비스는 IP 주소 혹은 AWS에서 제공하는 우리의 서비스와는 전혀 상관없는 긴 도메인 주소를 통해 접근해야 한다.
어렵겠지?
=> www.todolist.ap-northeast-2.compute.amazonaws.com
쉽겠지?
=> www.todolist.com

AWS에서 제공하는 Route 53 서비스를 이용해 직관적인 도메인 주소로 서비스에 접근할 수 있다.