Cloud Computing

클라우드 컴퓨팅의 등장 배경

기존 서버의 방식

• 서버실과 같은 곳에 컴퓨터를 배치

클라우드 등장 이전의 방식은 흔히 말하는 전산실 등에 컴퓨터를 배치하고 인터넷을 연결하여 서비스를 제공했다

그런데 만약 서버가 요청에 대한 수용 능력이 한계에 도달한다면 어떻게 대처할까?

기존 서버의 방식

• 같은 공간에 더 많은 컴퓨터를 추가
• 혹은 컴퓨터 성능 업그레이드

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

혹은 컴퓨터 한 대의 성능을 높이는 방식을 사용할 수도 있다

하지만 이런 방식은 몇 가지 문제점들을 가지고 있다

기존 방식의 한계

• 주기적인 유지 관리가 필요하다
• 공간의 한계
  • 데이터셍터의 등장
  • 유휴자원 대여

첫째. 주기적인 관리가 필요하다
흔히 말하는 서버실에는 종종 고장이 나거나 인터넷과 연결이 되지 않는 컴퓨터가 생기기도 한다
이런 상황이 발생한다면 이를 해결하기 위한 인력 및 비용이 투입되어야 했다

그러나 점차 관리해야 하는 컴퓨터 및 다른 전자기기의 수가 많아지는 만큼 투입되어야 하는 인력 및 비용도 증가하기 시작했다

둘째. 공간의 한계가 있다
예전의 방식은 서버실이라는 공간에 컴퓨터를 배치해 두고 필요할 때마다 추가적인 컴퓨터를 추가하는 방식으로 수용 능력을 향상해 왔다
하지만 이런 방식은 공간이 부족하여 컴퓨터를 더는 배치할 수 없는 문제에 직면하게 된다

이런 상황에서 서버의 컴퓨팅 능력을 늘리려는 방법은 컴퓨터의 성능을 높이고 부피를 줄여 좀 더 많은 컴퓨터를 같은 공간에 배치하는 방법이었다

이런 상황에서 추가적인 서버 증설이 어렵게 되자 일부 거대 기업은 데이터센터라는 거대한 건물을 세우기 시작했다
이때부터 데이터센터의 유휴 자원을 대여하는 서비스가 등장하기 시작했다

즉 서버의 자원과 공간, 및 네트워크 환경을 제공을 빌려 사용하는 클라우드 컴퓨팅이 시작된 순간이다

클라우드의 등장

• 서버의 자원과 공간, 및 네트워크 환경 제공
• 필요할 때마다 컴퓨팅 능력을 유연하게 조절
• 사용한 만큼의 요금만 지급
• 다른 컴퓨터로 즉시 이주(migration)가 가능

위와 같이 데이터 센터에서는 서버의 자원과 공간, 및 네트워크 환경을 제공한다
(이러한 환경을 "온프레미스"라고 부른다)

현대의 클라우드 컴퓨팅은 앞서 설명한 데이터 센터와 비슷한 역할을 하지만,

물리적인 컴퓨터가 아닌, 가상 컴퓨터를 대여한다는 점이 다르다
이는 가상화(Virtualization) 기술의 발전으로부터 비롯되었다

따라서, 최근의 가상화 기술을 사용하는 클라우드 서비스는 기존의 온프레미스 형식과는 달리 다음과 같은 장점이 있다

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

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

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

Cloud

클라우드의 단점

• 클라우드 서비스 종속
• 서비스에 영향을 미친다

클라우드 환경에도 단점이 존재한다

간혹 뉴스 등을 통해 아마존 웹 서비스의 장애로 특정 서비스의 서버가 지연되었다는 기사를 봤을거다

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

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

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

이런 클라우드는 모든 것을 서비스화하는 것을 목표로 한다

대표적인 클라우드 서비스의 형태는 SaaS, IaaS, PaaS 세 가지다

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

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

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

예를 들어 여러분이 피자라는 서비스를 제공해준다고 생각해보자

서비스의 범위는 여러분이 어떤 식으로 피자를 제공해주는지에 따라 달려있다

레스토랑과 같이 모든 테이블과 탄산음료 등의 서비스를 전부 제공해줄 수도 있고,
처음부터 끝까지 내가 모든 피자 조리와 재료, 심지어 서빙까지 스스로 해야 할 수도 있다

클라우드 제공자로부터 얼마만큼의 서비스를 제공받느냐에 따라서, 이러한 서비스의 형태가 구분된다

질문: 여러분이 사용하고 있는 서비스가 어떤 형태에 포함되나?
AWS는 IaaS에 가깝다

GitHub는 어떨까?
Google Drive와 같은 서비스는 어떤 형태로 볼 수 있을까?

Deploy

지금까지는 로컬환경에서 코드를 작성했다

작성한 코드가 그저 로컬환경에서 구동된다면 다른 사람들은 여러분이 개발한 서비스를 이용할 수 없다

Deployment

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

회사마다 추가적인 과정이 있을 수 있지만, 기본적으로 4단계를 거쳐서 개발한 서비스를 배포하게 된다

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

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

Staging단계에서는 실제 출시단계인 Production단계와 가장 유사한 환경에서 테스트를 진행한다
실제 데이터를 복사해서 문제가 있지 않은지 등 다양한 환경에서 테스트를 진행한다
또한 서비스와 관련된 부서 혹은 인원의 확인 과정을 거친다
예를 들면 작성된 코드가 마케팅팀 혹은 디자인팀 예상했던 결과인지에 확인을 거치는 과정이다

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

Development 환경과 Production 환경은 서로 다를 수가 있다

개발부터 배포까지 모든 것을 통제할 수 있는 상황이라면, 크게 걱정 없이 Production 환경을 구성할 수 있다
그러나, 여러 명이 함께 작업하는 프로젝트라면 어떨까?
node 버전도 제각각일 거고, 인증 정보나 데이터베이스 등에 접근하기 위해 사용하는 엔드포인트도 제각각일 것이다

예를 들어보자
내 로컬에 설치된 데이터베이스 비밀번호는 rlazheld1234! 인 데, 클라우드에 설치된 데이터베이스 비밀번호는 supersecret! 일 수 있다

이 모든 케이스를 코드 안에 담을 수 있을까? 아니다.
이처럼 Development 환경과 Production 환경은 서로 다를 수가 있다

마치, 우리나라에서 잘 자라는 식물을 사막 한가운데에서 똑같은 방식으로 재배한다고 잘 자라지 않는 것과 비슷하다

따라서 배포에서는, 환경의 차이를 이해하고 환경 설정을 코드와 분리하는 것이 중요하다

작성한 코드가 다른 환경에서 정상 작동할 수 있게 하려면 ?

• 절대경로 대신 상대경로를 사용한다
• 환경에 따라 포트를 분기할 수 있도록 환경변수를 설정해 준다
• Docker와 같은 개발 환경 자체를 통일시키는 솔루션을 사용한다

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

환경 변수는 코드 변경 없이 쉽게 배포 때마다 쉽게 변경할 수 있다
설정 파일과 달리, 잘못해서 코드 저장소에 올라갈 가능성도 낮다

애플리케이션의 모든 설정이 정상적으로 코드 바깥으로 분리되어 있는지 확인할 수 있는 간단한 방법은 어떠한 인증정보도 유출시키지 않고 코드가 지금 당장 오픈 소스가 될 수 있는지 확인하는 것이다

위와 같은 내용은 이러한 환경 설정을 코드로부터 분리하는 방법론을 이야기하고 있다

코드상의 모든 곳에 절대 경로가 아닌 상대 경로를 사용해야 하며, .env 등을 이용해 환경 변수를 설정하자

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

배포를 위한 굉장히 다양한 플랫폼들이 있다

EC2 (Elastic Compute Cloud)

Amazon EC2(Elastic Compute Cloud)

AWS에서 제공하는 클라우드 컴퓨팅 서비스

AWS에서 원격으로 제어할 수 있는 가상의 컴퓨터를 한 대 빌리는 것

EC2란 아마존 웹 서비스에서 제공하는 클라우드 컴퓨팅 서비스다

클라우드 컴퓨팅은 인터넷(클라우드)을 통해 서버, 스토리지, 데이터베이스 등의 컴퓨팅 서비스를 제공하는 서비스다
정리하면 아마존에서 가상의 컴퓨터를 한 대 빌리는 것과 같다

AWS에서 제공하는 Elastic Compute Cloud서비스 앞에 붙은 Elastic이라는 단어는 어떤 의미일까?

해당 단어는 고사양 게임을 플레이하는 것에 비유하여 설명하면 이해하기 편하다

집에서 고사양 게임을 하기 위해서는 게임을 1시간을 하던지 10시간을 하던지 간에 기본적으로 지출해야 하는 돈이 있다

그런데 후불제PC방에 간다면, 집에서 게임을 하기 위해서 기본적으로 지출해야 하는 돈은 필요 없이 게임을 한 대해서만 비용을 지불하면 된다

EC2서비스도 이런 후불제 PC방과 같이 사용한 만큼비용을 지불하기 때문에 탄력적인 이라는 의미의 Elastic이라는 단어가 붙어있다

Elastic은 비용적인 부분 뿐만이 아니라 필요에 따라 성능, 용량을 자유롭게 조절할 수 있다는 의미도 가지고 있다

정리하자면 EC2서비스는 AWS에서 비용, 성능, 용량면에서 탄력적인 클라우드 컴퓨터를 제공하는 서비스라고 할 수 있다

EC2 사용의 이점

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

EC2 서비스의 장점 중

첫 번째는 구성하는 데 필요한 시간이 짧다는 것

만약 PC를 구매한다면 구매해서 배송되는 데까지의 시간이 필요하지만
EC2 서비스는 몇 번의 클릭만으로 PC를 구성할 수 있다

2.다양한 운영체제에 대한 선택이 가능하다

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

EC2에서는 AMI라는 다양한 템플릿을 제공하고 있어서 필요에 따라 손쉽게 운영체제를 선택하고 구성할 수 있다

운영체제뿐만이 아니라 CPU와 RAM, 용량까지도 손쉽게 구성할 수 있다

인스턴스를 생성

EC2는 컴퓨터를 한 대 빌리는 것이므로 컴퓨터로 할 수 있는 모든 일을 할 수 있다

빌린 컴퓨터는 직접 사용하는 컴퓨터와 다르게 아마존이 전 세계에 만들어 놓은 데이터 센터(인프라)에 만들어져 있기 때문에,
컴퓨터를 조작하기 위해 네트워크(인터넷)를 통해서 컴퓨터를 제어해야 한다는 차이점이 있을 뿐 일반적인 컴퓨터와 다른 점은 없다

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

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

AMI(Amazon Machine Image)

AMI는 소프트웨어 구성이 기재된 템플릿이다

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

AWS에서 빌릴 PC는 사용용도에 맞게 운영체제, 런타임 등이 구성된 Setting을 선택할 수 있다

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

상당히 많은 양의 Image가 AWS에 미리 준비되어 있으며, 선택된 image를 바탕으로 Instance의 운영체제가 결정된다

Instance는 선택한 AMI를 토대로 구성된다

AWS에는 상당히 많은 양의 AMI 셋팅이 준비되어 있기 때문에 손쉽게 인스턴스의 운영체제를 구성할 수 있다

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

EC2인스턴스 생성의 의미

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

RDS (Relation Database Service)

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

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

왜 RDS를 사용할까?

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

데이터베이스만 따로 분리해서 서비스를 이용해야 할 이유가 있을까?

RDS 사용의 이점

1. 데이터베이스 유지보수와 관련된 일들을 RDS에서 전적으로 자동 관리한다

EC2 인스턴스에 관계형 데이터베이스 엔진을 설치해서 데이터를 관리할 때와 RDS를 통해 데이터를 관리할 때의 차이는 렌터카 회사에서 대여한 차량과 개인 소유 차량으로 비유할 수 있다

EC2 인스턴스에 데이터베이스를 설치하여 데이터를 관리하는 것은 개인 소유 차량을 이용하는 것과 비슷하다
개인 소유 차량을 이용하면 유지보수, 보험처리 같은 일들을 온전히 운전자가 부담한다
차량 정비를 위해서 정비소에 주기적으로 방문해야 하고, 기타 차량과 관련된 다른 일이 생길 때 들여야 하는 시간과 수고가 크다

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

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

그에 반해 RDS를 이용하는 것은 렌터카 회사에서 차량을 대여하는 것과 비슷하다
렌터카 회사에서 차량을 대여하면 대여 차량과 관련하여 시간이 들어가는 일들을 렌터카 회사에서 대신 처리한다
운전자는 차량을 관리하는 일에 대해서 시간을 따로 쏟을 필요없이 운전만 하면 되기에 매우 편리하다

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

2. 다양한 데이터 베이스 엔진 선택지 제공

기타 RDS 이용 시 얻을 수 있는 장점으로 다양한 데이터베이스 엔진 선택지를 제공한다는 점이다

회사에서 근무하고 있는 실무자는 회사에 필요한 데이터베이스 엔진을 취사선택하여 이용할 수 있다

그 외 일반 사용자는 데이터베이스 엔진마다 제공하는 기능이 조금씩 다르기에 필요와 목적에 맞게 데이터베이스 엔진을 선택하여 효율성을 높일 수 있다

S3 (Simple Storage Service)

클라우드 스토리지란?
인터넷 공간에 데이터를 저장하는 저장소

S3가 무엇인지 알아보기 전에, 클라우드 스토리지 개념에 대해 잠시 알아보는 시간을 가져보자

클라우드 스토리지란 무엇일까?

클라우드 스토리지란 쉽게 말해서 인터넷 공간에 데이터를 저장하는 저장소다
컴퓨터 부품으로 비유하면 하드디스크의 역할을 하는 서비스다

우리는 알게 모르게 클라우드 스토리지 서비스를 이용해왔다
구글의 Google Drive, 네이버의 MYBOX, 마이크로소프트의 Onedrive와 같은 서비스가 좋은 예시다

클라우드 스토리지 서비스의 장점으로는 어떤 것이 있을까?

클라우드 스토리지 서비스는 뛰어난 접근성을 가지고 있다
컴퓨터의 하드디스크에 저장된 파일에 접근하기 위해서는 해당 컴퓨터를 이용해야만 한다
그러나 클라우드 스토리지를 이용하면 웹 환경이라면 언제 어디서나 저장된 파일에 접근할 수 있다 또한 컴퓨터뿐만 아니라 웹에 접속이 가능한 다른 전자기기를 활용하여 클라우드 스토리지에 저장된 데이터에 접속할 수 있다

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

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

S3도 마찬가지로 뛰어난 접근성을 가지고 있다

뛰어난 접근성 외에도 S3 사용 시 얻을 수 있는 이점은 여러 가지 있다

S3 사용 시 이점

1. 확장성

데이터를 무한히 저장 가능하다

먼저 S3 사용 시 얻을 수 있는 이점으로 높은 확장성이 있다
확장성이 높으면 많은 시간과 수고를 들이지 않고 스토리지 규모를 확장/축소할 수 있다

또한 S3에서는 스토리지의 용량을 무한히 확장할 수 있다
그리고 사용한 만큼만 비용을 지불하면 되기 때문에 비용적인 측면에서 매우 효율적이다

2. 강력한 내구성

스토리지의 내구성이 높으면 저장된 파일을 유실할 가능성이 적어진다
S3는 99.999999999%의 내구성을 보장한다

길을 걷다가 벼락을 맞을 확률(약 0.0000007%의 확률)이 S3에 저장된 파일을 잃어버릴 확률의 700배 라는 점을 생각하시면 S3 스토리지의 내구성이 얼마나 대단한지 가늠이 된다

3. 가용성 보장

가용성이 높으면 스토리지에 저장된 파일들을 정상적으로 사용할 수 있는 시간이 길어진다
S3는 연간 99.99%의 스토리지 가용성을 보장하도록 설계가 되어 있다
이는 다른 말로 1년 동안 S3에 파일을 저장했을 시, 8.76 시간 동안만 스토리지를 이용하는 데 있어서 장애가 발생한다는 뜻이다

EC2, RDS, S3의 해당 서비스들이 공통적으로 '높은 가용성'과 '높은 내구성'을 보장한다는 점이다

AWS는 어떤 원리로 해당 서비스들의 높은 가용성과 내구성을 보장할 수 있는 걸까?

위와 같이 첨부된 지도를 보시면 주황색 동그라미가 쳐진 지역이 있다
이 지역을 '리전(Region)' 이라고 부른다

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

그리고 지도를 다시 보시면 주황색 동그라미 안에 숫자가 새겨져 있는데, 이 숫자는 리전에 위치한 가용영역의 수를 뜻한다

가용 영역(Availability Zone)이란 각 리전 안에 존재하는 데이터 센터(IDC)를 뜻한다

가용 영역은 각각 개별적인 위치에 떨어져서 존재한다
그래서 한 곳의 가용 영역이 재난이나 사고로 인해 가동이 불가능해지더라도 다른 가용 영역에 백업을 해놓은 데이터를 활용하여 문제 없이 서버가 가동되게 한다
이런 가동 방식 덕분에 AWS에서 제공하는 서비스들은 높은 가용성과 내구성을 보장한다

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

• 가장 일반적으로 사용되는 스토리지 클래스
• 데이터에 자주 엑세스해야 할 경우 사용

또 다른 특징으로 S3는 다양한 스토리지클래스를 제공한다
저장소를 어떤 목적으로 활용할지에 따라 효율적으로 선택할 수 있는 스토리지 클래스가 달라진다

S3 사용자들이 대표적으로 많이 선택하는 스토리지 클래스는 두 가지가 있다
Standard 클래스와 Glacier 클래스다

Standard 클래스

Standard 클래스는 범용적인 목적으로 사용하기 좋다
데이터에 빠른 속도로 접근할 수 있고, 데이터 액세스 요청에 대한 처리 속도가 빠르다
대신 데이터를 오래 보관하는 목적으로는 효율적인 선택지가 아니다
보관 비용이 높게 발생하기 때문이다 (오랜기간 저장 비추)

Glacier 클래스

• 데이터의 장기보관 목적
• 데이터를 보관하는 데 드는 비용이 저렴

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

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

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

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

• 정적파일: 서버의 개입 없이 클라이언트에 제공될 수 있는 파일
• 웹 호스팅: 서버의 한 공간을 빌려주어 웹 사이트의 배포, 운영이 가능하게 만들어주는 서비스
• S3에서는 버킷을 통해 정적 웹 사이트 호스팅이 가능 - 버킨이란 ?

S3 사용 시 얻는 이점 중 하나로, 정적 웹 사이트 호스팅이 가능하다
정적 웹 사이트 호스팅이란 뭘까?

먼저 정적 웹 사이트 호스팅이 무엇인지 알기 위해 '정적' 파일에 대한 이해가 선행되어야 한다

정적 파일은 서버의 개입 없이 생성된 파일을 뜻한다

반대로 클라이언트가 서버에 요청을 보내면, 서버가 요청에 맞추어 그 자리에서 생성한 파일을 '동적' 파일이라고 부른다

그럼 웹 호스팅(Web Hosting)이란 뭘까?

웹 호스팅이란 서버의 한 공간을 임대해주는 서비스를 뜻한다
구글에 '웹 호스팅'이란 단어를 검색하시면 여러 웹 호스팅 업체의 목록이 뜨시는 것을 확인할 수 있다
웹 호스팅 업체들을 통해 개인 또는 단체가 웹 호스팅 업체가 제공하는 서버의 한 공간을 빌려서 원하는 서비스를 배포할 수 있다

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

S3의 핵심 개념

버킷

• 버킷은 파일을 담는 바구니(최상위 디렉토리)
• 무한히 많은 파일을 저장 가능
• 버킷의 이름은 각 리전에서 고유해야 한다
• 버컷의 정책을 생성하여 엑세스 권한을 부여 가능

버킷이란 S3에 저장되는 파일들이 담기는 바구니다
파일을 저장하는 최상위 디렉토리라고도 설명할 수 있다

S3에서 저장되는 모든 파일은 버킷 안에 저장되어야 하고, 버킷에는 무한한 양의 파일을 저장할 수 있다
그리고 각각의 버킷은 이름을 가지고 있는데, 버킷의 이름은 버킷이 속해 있는 리전(버킷이 생성된 지역)에서 유일해야 한다

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

객체

• 객체는 버킷에 담기는 파일
• 객체는 파일과 메타데이터로 구성
• 모든 객체는 고유한 키를 가진다
• URL 주소를 통해서 객체에 접근 가능
• URL 주소 형식 : http://[버킷이름].S3.amazonaws/[객체의키]

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

S3에 저장되는 객체는 파일과 메타데이터로 구성된다
파일에 대해서 먼저 알아보자

파일은 위에 설명한 대로 키-값 페어 형식으로 데이터를 저장한다

파일의 값에는 실제 데이터를 저장한다
S3 객체의 값으로써 저장될 수 있는 데이터의 최대크기는 5TB이다

파일의 키는 각각의 객체를 고유하게 만들어주는 식별자 역할을 한다
파일의 키를 이용하여 원하는 객체를 검색할 수 있다

메타데이터는 객체의 생성일, 크기, 유형과 같은 객체에 대한 정보가 담긴 데이터다
객체를 설명하는 데이터라고 이해하시면 좋다

모든 객체는 고유한 URL 주소를 가지고 있다

URL 주소는 http://[버킷의 이름].S3.amazonaws.com/[객체의 키]의 형태를 띠고,
URL 주소를 통해서도 원하는 데이터에 접근할 수 있다

배포 전략 (Deploy Strategy)

개발한 Client, Server, Database를 어떻게 배포할 것인 가?

지금까지는 로컬 환경에서 클라이언트와 서버, 데이터베이스를 띄워서 작성한 코드를 구동하고 확인했다

외부에서 접속하게 된다면 ?

개발한 서비스를 외부에서 사용자들이 접속할 수 있게 하려면 어떻게 해야 할까?

개발한 서비스를 사용자가 이용할 수 있도록 하는 것을 배포라고 한다

결국 어떻게 사용자들이 여러분이 개발한 서비스를 이용할 수 있게 할 수 있을까?
사용자들에게 localhost:3000의 주소로 들어오라고 할 수는 없을 것이다

그렇다면 사용자들에게 Client를 어떻게 제공할지,
그리고 Client를 받은 사용자들이 서비스를 이용하기 위한 요청을 처리할 Server를 어떻게 제공할 것인지,
Server의 데이터를 저장하고 제공할 Database는 어떻게 제공할 것인지 생각해 봐야 한다

Client 배포

AWS서비스 중 하나인 S3을 이용해서 사용자에게 client application을 제공할 수 있다

작성한 Client 코드를 사용자들에게 어떻게 제공할지 생각해 보자

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

클라이언트를 위해 EC2 인스턴스를 사용해야 할까 ?

로컬 환경에서는 자체 개발 서버 (예, create-react-app)를 이용해서 클라이언트 앱을 실행시키는 것이 보통이다
그럼, 클라이언트를 위해서 EC2 인스턴스를 사용해야 할까?

클라이언트를 정적파일로 빌드하여 배포한다
따라서 S3를 이용해 배포한다

그렇지 않다
클라이언트 앱을 정적 파일로 빌드하여 제공한다
따라서 S3를 이용해서 클라이언트를 배포한다

빌드란 ?

• 불필요한 데이터를 없애고, 통합/압축하여 배포하기 최적화된 상태를 만드는 것
• 데이터의 용량이 줄어들고 웹사이트 로딩 속도가 빨라진다

이때 필요한 것이 빌드 다

빌드란 쉽게 말해서 불필요한 데이터를 없애고, 여러 갈래로 퍼져있는 데이터들을 통합/ 압축하여 배포하기에 최적화된 상태를 만드는 것이다

빌드 과정을 진행하기 전과 비교했을 때 데이터의 용량이 줄어들고, 웹 사이트의 로딩 속도가 빨라진다는 장점이 생긴다

하지만 일반적인 의미의 빌드는,
소스코드를 실행 가능한 번들로 변환하는 컴파일 과정을 의미한다
웹 앱에서와같이 HTML, CSS, JS의 형태로 배포하는 경우는 조금 다르다
웹 앱은 배포 가능한 정적 파일(static files)의 형태로 만들어 줘야 한다

asset 자체가 정적인 경우, 있는 그대로 배포하면 된다

React의 경우 npm run build 와 같은 명령을 사용해서, 정적 파일 형태의 결과물을 만들어 낸 후 배포하면 된다

사용하고 있는 환경에 따라 빌드 과정은 다를 수 있다

---

사용자들이 더빠르게 파일을 받을 수 있게 하는 다른 방법이 없을까?
AWS에서 제공하는 CDN 서비스인 CloudFront를 통해서 사용자에게 콘텐츠를 더 빨리 배포할 수 있다

S3로 사용자들에게 Client Application을 제공하고 있는데, 사용자가 지구 반대편에 있다면 어떻게 빠르게 서비스를 제공할 수 있을까?

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

사용자들이 S3와 CloudFront를 통해서 Client Application을 제공받았다

Client Applocation을 통해서 용청과 응답을 주고 받을 Server는 어떻게 배포해야 할까?

사용자들이 제공받은 Client Application을 통해서 요청을 전달할 Server Application은 어떻게 배포해야 할까?

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

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

Database 배포

AWS에서는 관계형 데이터베이스 특화 서비스인 RDS 서비스를 제공하고 있다

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

AWS에서는 Database 특화 서비스인 RDS 서비스를 제공하고 있다

AWS가 유지 보수 작업을 담당하는 RDS를 이용하여 즉시 데이터베이스를 사용할 수 있다

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

DNS

Google과 같은 웹사이트에 접속할때 www.google.con이라는 도메인을 통해 접속이 가능하다

여러분이 지금까지 이용했던 서비스는 www.google.com과 같은 도메인 주소를 이용해서 접근할 수 있었다

google 사이트에 접속하기 위해서 172.217.161.228이라는 IP주소를 입력하지는 않았을 것이다

처음 배포된 여러분의 서비스는 도메인주소를 통해 접근할 수 있을까?

하지만 배포한 서시브는 현재 IP주소 혹은 AWS에서 제공한 서비스와는 전혀 연관이 없는 도메인으로 접속한다

S3, EC2를 이용해서 배포된 서비스는 IP주소 혹은 AWS에서 제공하는 여러분의 서비스와는 전혀 상관없는 긴 도메인주소를 통해 접근하게 된다

TodoList 서비스를 제공한다고 생각해보자
www.todolist.ap-northeast-2.compute.amazonaws.com 주소보다는 www.todolist.com주소 일 때,
직관적으로 서비스를 이해할 수 있고 짧은 주소를 통해 서비스에 접근할 수 있다

도메인을 통해 서비스에 접속하려면, AWS의 서비스 중 Route53을 이용한다

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