Cloud Computing

기존 서버의 방식

같은 공간에 더 많은 컴퓨터를 제공하여 한 대가 해결할 수 있는 요청을 여러 대가 나누는 방식을 사용하거나 컴퓨터 한 대의 성능을 높이는 방식을 사용

기존 방식의 한계

• 주기적인 유지 관리가 필요

• 공간의 한계

데이터 센터가 등장하고 유휴 자원을 대여하기 시작하면서 서버의 자원과 공간 및 네트워크 환경(온프레미스)을 제공을 빌려 사용하는 클라우드 컴퓨팅이 시작되었다.

최근의 가상화 기술을 사용하는 클라우드 서비스는 기존의 온프레미스 형식과는 다른 장점

1. 필요할 때마다 컴퓨팅 능력을 유연하게 조절 가능

2. 고정적인 비용이 들어가는 온프레미스와는 달리 사용한 만큼의 요금만 지불

3. 컴퓨터의 스냅샷("이미지"라고 부릅니다) 을 이용해 다른 컴퓨터로 즉시 이주(migration)가 가능

클라우드 단점

운영 환경 자체가 클라우드 제공자에게 종속되므로, 클라우드 서비스에 문제가 생기면 내가 배포하고 관리하는 환경에도 영향을 미침

=> 운영환경이 특정 클라우드 사업자(vendor)에게 종속된다는 얘기는, 백엔드 구성 자체가 특정 회사의 기술로만 구성 해야만 하는 경우가 발생 가능

따라서 AWS와 같은 대표적인 클라우드 사업자가 제공하는 기술을 익히는 것도 중요하지만, 그만큼 이 인프라 자체에 대한 이해가 더욱 중요

대표적인 클라우드 서비스의 형태

1. SaaS

SaaS는 Software as a Service의 약자
클라우드 제공자가 당장 사용 가능한 소프트웨어를 제공하는 경우 대부분 SaaS에 해당

2. PaaS

PaaS는 Platform as a Service의 약자
클라우드 제공자가 데이터베이스, 개발 플랫폼까지 제공하는 경우 대부분 PaaS에 해당

3. IaaS

IaaS는 Infrastructure as a Service의 약자
클라우드 제공자가 가상 컴퓨터까지 제공하는 경우 대부분 IaaS에 해당

Deploy

배포란 개발한 서비스를 사용자들이 이용 가능하게 하는 일련의 과정

배포 단계

1. Development

Development단계는 각자의 컴퓨터에서 코드를 작성하고 테스트 하는 과정
개발단계이기 때문에 실제 데이터를 이용하지 않고 더미데이터를 이용해서 테스트

2. Intergration

Intergration단계에서는 각자의 컴퓨터에서 작성한 코드를 합치는 과정
=> 내가 작성한 코드가 다른 코드를 침범해서 오류를 일으키지 않는지, 코드간에 conflict가 있지는 않는지 확인하는 과정

3. Staging

Staging단계에서는 실제 출시단계인 Production단계와 가장 유사한 환경에서 테스트를 진행
=> 실제 데이터를 복사해서 문제가 있지 않은지 등 다양한 환경에서 테스트를 진행하고 서비스와 관련된 부서 혹은 인원의 확인 과정

4. Production

Production단계에서는 개발된 서비스를 출시하는 단계
사용자가 접속할 수 있는 Production환경에서 코드를 구동하고 서비스를 제공
실제 데이터를 가지고 서비스가 운영되기 때문에 문제가 생기면 안되는 단계

배포에서는 여러가지 개발 단계의 환경의 차이를 이해하고 환경 설정을 코드와 분리하는 것이 중요

작성한 코드가 다른 환경에서 정상 작동할 수 있게 하려면, 설정을 환경 변수 (envvars나 env라고도 불림)에 저장

환경 변수는 코드 변경 없이 쉽게 배포 때마다 쉽게 변경 가능

설정 파일과 달리, 잘못해서 코드 저장소에 올라갈 가능성도 낮음

환경 설정을 코드로부터 분리하는 방법론

1. 코드상의 모든 곳에 절대 경로가 아닌 상대 경로를 사용

2. .env 등을 이용해 환경 변수를 설정

3. docker와 같은 가상화 도구는 환경 자체를 메타데이터로 담아서 아예 모든 개발 환경을 통일

AWS (Amazon Web Service)

배포를 위한 다양한 플랫폼들 중 가장 많이 사용하는 AWS

EC2(Elastic Compute Cloud)

EC2 서비스는 AWS에서 비용, 성능, 용량면에서 탄력적인 클라우드 컴퓨터를 제공하는 서비스

EC2 장점

1. 구성하는 데 필요한 시간이 짧다

2. AMI를 통해서 필요한 용도에 따라 다양한 운영체제에 대한 선택이 가능

EC2에서는 AMI라는 다양한 템플릿을 제공하고 있어서 필요에 따라 손쉽게 운영체제를 선택하고 구성 가능 (운영체제뿐만이 아니라 CPU와 RAM, 용량까지도 손쉽게 구성 가능)

아마존 EC2를 통해서 할 수 있는 가장 기본적인 일은 웹서버를 설치하고 웹 서버를 통해서 사용자가 웹 브라우저를 통해 요청하는 서비스를 제공하는 것이 가장 기본적인 사용 방법

인스턴스는 1대의 컴퓨터를 의미하는 단위이고 AWS에서 컴퓨터를 빌리는 것을 인스턴스를 생성한다고 함

AMI(Amazon Machine Image)

AMI는 인스턴스를 생성하는데 필요한 소프트웨어 구성(운영체제, 애플리케이션 서버, 애플리케이션)이 포함된 템플릿

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

셋팅되어 있는 AMI 이외에도 필요에 따라 직접 AMI를 구성 가능

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

RDS

RDS는 Relational Database Service의 약자로 AWS에서 제공하는 관계형 데이터베이스 서비스

EC2 인스턴스에서 DB를 사용하면 데이터베이스와 관련해서 자동으로 관리를 담당하는 부분이 매우 적기에, 사용자가 일일이 시간을 투자하여 데이터베이스 엔진의 설치와 버전 관리, 데이터 백업을 해야 함

가용성과 내구성이 확보되지 않기에 데이터베이스에 저장된 데이터가 유실되거나 정상적으로 사용하지 못할 확률이 커지며, 후에 필요에 따라 데이터베이스의 규모를 확장하기 어려움

RDS를 이용하면 데이터베이스 유지보수와 관련된 일들을 RDS에서 전적으로 자동 관리함
=> 사용자가 해야할 일은 초기 설정을 제외하고 데이터베이스에 저장된 데이터를 관리하는 일 밖에 없기에 큰 편의성을 느낌
=> 다양한 데이터베이스 엔진 선택지를 제공함

S3

클라우드 스토리지

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

클라우드 스토리지 서비스는 뛰어난 접근성을 가짐

S3는 Simple Storage Service의 약자로 AWS에서 제공하는 클라우드 스토리지 서비스

S3 사용 시 장점

1. 높은 확장성

확장성이 높으면 많은 시간과 수고를 들이지 않고 스토리지 규모를 확장/축소 가능
사용한 만큼만 비용을 지불하면 되기 때문에 비용적인 측면에서 매우 효율적

2. 강력한 내구성

S3는 99.999999999%의 내구성을 보장하기 때문에 저장된 파일을 유실할 가능성이 현저히 낮음

3. 99.99%의 가용성 보장

가용성이 높으면 스토리지에 저장된 파일들을 정상적으로 사용할 수 있는 시간이 길어짐

AWS region

리전이란 AWS에서 클라우드 서비스를 제공하기 위해서 운영하는 물리적인 서버의 위치

리전에 위치한 가용 영역은 각 리전 안에 존재하는 데이터 센터(IDC)

가용 영역은 각각 개별적인 위치에 떨어져서 존재

한 곳의 가용 영역이 재난이나 사고로 인해 가동이 불가능해지더라도 다른 가용 영역에 백업을 해놓은 데이터를 활용하여 문제 없이 서버가 가동되게 함

이런 가동 방식 덕분에 AWS에서 제공하는 서비스들은 높은 가용성과 내구성을 보장함

4. 다양한 스토리지 클래스를 제공

저장소를 어떤 목적으로 활용할지에 따라 효율적으로 선택할 수 있는 스토리지 클래스가 달라짐

대표적인 스토리지 클래스

1.Standard 클래스

범용적인 목적으로 사용하기 좋음

데이터에 빠른 속도로 접근할 수 있고, 데이터 액세스 요청에 대한 처리 속도가 빠름

보관 비용이 높게 발생하기 때문에 데이터를 오래 보관하는 목적으로는 효율적인 선택지가 아님

데이터에 자주 엑세스해야 할 경우 사용

2.Glacier 클래스

장기적인 보관 목적으로 스토리지를 사용할 때는 Glacier를 사용하는 것이 효율적

비록 저장된 데이터에 액세스하는 속도는 느리지만, 데이터를 보관하는 비용이 매우 저렴하다는 장점

이 외에도 Standard-IA, One Zone-IA, S3 Glacier Deep Archive 등 여러 가지 스토리지 클래스가 존재하여 사용자의 이용 목적에 따라 다양한 스토리지 클래스를 사용가능

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

정적 파일은 서버의 개입 없이 생성된 파일

웹 호스팅이란 서버의 한 공간을 빌려주어 웹 사이트의 배포, 운영이 가능하게 만들어주는 서비스

S3에서는 버킷이 사용자들이 정적 웹 사이트를 배포할 수 있는 공간을 제공함

버킷이라는 저장 공간에 정적 파일을 업로드하고 버킷을 정적 웹 사이트 호스팅 용도로 구성하면 정적 웹 사이트를 배포 가능

버킷이란 S3에 저장되는 파일들이 담기는 바구니(파일을 저장하는 최상위 디렉터리)

S3에서 저장되는 모든 파일은 버킷 안에 저장되어야 하고, 버킷에는 무한한 양의 파일을 저장 가능

버킷의 이름은 버킷이 속해 있는 리전(버킷이 생성된 지역)에서 유일해야함

버킷 정책을 생성하여 해당 버킷에 대한 다른 유저의 접근 권한을 수정 가능

S3에서 저장소에 데이터를 저장할 때 키-값 페어 형식으로 데이터를 저장하기 때문에 버킷에 담기는 파일을 객체라고 함

S3에 저장되는 객체는 파일과 메타데이터로 구성됨

1.파일
키-값 페어 형식으로 데이터를 저장

파일의 값에는 실제 데이터를 저장

S3 객체의 값으로써 저장될 수 있는 데이터의 최대크기는 5TB

파일의 키는 각각의 객체를 고유하게 만들어주는 식별자 역할

파일의 키를 이용하여 원하는 객체를 검색 가능

2.메타 데이터
객체의 생성일, 크기, 유형과 같은 객체에 대한 정보가 담긴 데이터(객체를 설명하는 데이터)

모든 객체는 고유한 URL 주소를 가짐
URL 주소는 http://[버킷의 이름].S3.amazonaws.com/[객체의 키]의 형태
URL 주소를 통해서도 원하는 데이터에 접근 가능

배포 전략 (Deploy Strategy)

1. Client 배포

AWS에서 제공하는 서비스인 S3라는 서비스를 통해 사용자들에게 Client를 제공
클라이언트 앱을 정적 파일로 빌드하여 제공, 따라서 S3를 이용해서 클라이언트를 배포

빌드란 불필요한 데이터를 없애고, 여러 갈래로 퍼져있는 데이터들을 통합/ 압축하여 배포하기에 최적화된 상태를 만드는 것
데이터의 용량이 줄어들고, 웹 사이트의 로딩 속도가 빨라진다는 장점

일반적인 의미의 빌드는, 소스코드를 실행 가능한 번들로 변환하는 컴파일 과정을 의미

asset 자체가 정적인 경우, 있는 그대로 배포
React의 경우 npm run build와 같은 명령을 사용해서, 정적 파일 형태의 결과물을 만들어 낸 후 배포
사용하고 있는 환경에 따라 빌드 과정은 다를 수 있음

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

2. Server 배포

안정적으로 서비스를 제공하기 위해 가상의 PC(AWS EC2)를 빌려 서버 코드를 구동 가능

3. DB 배포

RDS 서비스를 이용하여 EC2를 통해 배포된 Server Application의 데이터를 저장, 제공하는 데이터베이스를 배포 가능

4. DNS

S3, EC2를 이용해서 배포된 서비스는 IP주소 혹은 AWS에서 제공하는 서비스와는 전혀 상관없는 긴 도메인주소를 통해 접근하게 됨
=> AWS에서 제공하는 Route 53 서비스를 이용하면 직관적인 도메인 주소를 통해서 서비스에 접근 가능