배포가 왜 중요한가?
우리가 만들고 있는 웹 서비스가 배포가 되지 않는다면 아무도 쓰는 사람이 없으므로 의미를 가지지 못한다. 이는 대학원이나 연구소에서 어떠한 발견을 했지만 논문이 아직 저널에 실리지 않은 것과 같은 맥락에서 이해될 수 있다. (publish or perish)
가상화 기술의 발전과 AWS의 등장은 클라우드 컴퓨팅에 혁신을 불러일으켰습니다.
클라우드 등장 이전에는 전산실에 컴퓨터를 배치하고 인터넷을 연결하여 서비스를 제공했습니다. 서버가 요청에 대한 수용 능력이 한계에 도달하게 된다면 어떻게 될까?
같은 공간에 더 많이 컴퓨터를 배치하여 한 대가 해결할 수 있는 요청을 여러 대가 나누는 방식을 이용할 수 있습니다. 혹은 컴퓨터 한 대의 성능을 높이는 방식을 사용할 수 있습니다.
그러나 이러한 방식에는 몇가지 문제점을 가지고 있습니다.
1. 서버실에는 종종 고장이 나거나 인터넷과 연결이 되지 않는 컴퓨터가 생기기도 합니다. 이런 상황이 발생한다면 이를 해결하기 위한 인력 및 비용이 투입되어야 했습니다. 그러나 점차 관리해야 하는 컴퓨터 및 다른 전자기기의 수가 많아지는 만큼 투입되어야 하는 인력 및 비용도 증가하기 시작했습니다.
2. 공간의 한계가 있습니다. 예전의 방식은 서버실이라는 공간에 컴퓨터를 배치해 두고 필요할 때마다 컴퓨터를 추가하는 방식으로 수용 능력을 향상해 왔습니다. 하지만 이런 방식은 공간이 부족하여 컴퓨터를 더는 배치할 수 없는 문제에 직면하게 됩니다.
이런 상황에서 서버의 컴퓨팅 능력을 늘리려는 방법은 컴퓨터의 성능을 높이고 부피를 줄여 좀 더 많은 컴퓨터를 같은 공간에 배치하는 방법이었습니다.
=> 추가적인 서버 증설이 어려워짐 => 일부 거대 기업은 데이터 센터라는 거대한 건물을 세우기 시작했음. 이 때부터 데이터 센터의 유휴 자원을 대여하는 서비스가 등장하기 시작했음.
즉 서버의 자원과 공간, 및 네트워크 환경을 빌리는 클라우드 컴퓨팅이 시작된 순간이다.
데이터 센터에서는 서버의 자원과 공간, 및 네트워크 환경을 제공합니다. (온프레미스라고 함)
현대의 클라우드 컴퓨팅은 앞서 설명한 데이터 센터와 비슷한 역할을 하지만 물리적인 컴퓨터가 아닌 가상 컴퓨터를 대여한다는 점이 다릅니다. 이는 가상화 기술의 발전(virtualization)으로부터 비롯되었습니다.
*가상화(virtualization)의 장점
1. 필요할 때마다 컴퓨팅 능력을 유연하게 조절할 수 있습니다.
2. 고정적인 비용이 들어가는 온프레미스와는 달리 사용한 만큼의 요금만 지불하면 됩니다.
3. 컴퓨터의 스냅샷(이미지)을 이용해 다른 컴퓨터로 즉시 이주(migration)가 가능합니다.
*클라우드 환경의 단점
운영 환경 자체가 클라우드 제공자에게 종속되어 버리므로, 클라우드 서비스에 문제가 생기면 내가 배포하고 관리하는 환경에도 영향을 미칩니다.
운영환경이 특정 클라우드 사업자(vendor)에게 종속된다는 얘기는, 백엔드 구성 자체가 특정 회사의 기술로만 구성해야만 하는 경우가 발생할 수도 있다는 이야기입니다. 따라서 AWS와 같은 대표적인 클라우드 사업자가 제공하는 기술을 익히는 것도 중요하지만, 그만큼 이 인프라 자체에 대한 이해가 더욱 중요합니다.
- 클라우드 서비스의 형태
SaaS (Software as a Service): 클라우드 제공자가 당장 사용 가능한 소프트웨어를 제공하는 경우 대부분 SaaS에 해당합니다.
PaaS (Platform as a Service): 클라우드 제공자가 데이터베이스, 개발 플랫폼까지 제공하는 경우 대부분 PaaS에 해당합니다.
IaaS (Infrastructure as a Service): 클라우드 제공자가 가상 컴퓨터까지 제공하는 경우 대부분 IaaS에 해당합니다. (AWS)
Deploy(배포): 배포란 개발한 서비스를 사용자가 이용가능하게 하는 과정입니다. 기본적으로 4단계를 거쳐서 개발한 서비스를 배포하게 됩니다.
-
Development: 각자의 컴퓨터에서 코드를 작성하고 테스트하는 과정입니다. 개발 단계이기 때문에 실제 데이터를 이용하지 않고 더미 데이터를 이용해서 테스트합니다.
-
Integration: 각자의 컴퓨터에서 작성한 코드를 합치는 과정입니다. 내가 작성한 코드가 다른 코드를 침범해서 오류를 일으키지 않는지, 코드 간에 conflict가 있지는 않은지 확인하는 과정을 거칩니다.
-
Staging: 실제 출시 단계인 Production 단계와 가장 유사한 환경에서 테스트를 진행합니다. 실제 데이터를 복사해서 문제가 있지 않은지 등 다양한 환경에서 테스트를 진행합니다. 서비스와 관련된 부서 혹은 인원의 확인 과정을 거칩니다. 예를 들면 작성된 코드가 마케팅팀 혹은 디자인 팀이 예상했던 결과인지 확인을 거치는 과정입니다.
-
Production: 개발된 서비스를 출시하는 단계입니다. 사용자가 접속할 수 있는 Production 환경에서 코드를 구동하고 서비스를 제공합니다. 실제 데이터를 가지고 서비스가 운영되기 때문에 문제가 생기면 안 되는 단계입니다.
배포에서는, 환경의 차이를 이해하고 환경 설정을 코드와 분리하는 것이 중요합니다.
작성한 코드가 다른 환경에서 정상 작동할 수 있게 하려면?
1. 절대경로 대신 상대경로를 사용합니다.
2. 환경에 따라 포트를 분기할 수 있도록 환경변수를 설정해 줍니다.
3. (Advanced) Docker와 같은 개발 환경 자체를 통일시키는 솔루션을 사용합니다.
EC2란 아마존 웹 서비스에서 제공하는 클라우드 컴퓨팅 서비스입니다. 클라우드 컴퓨팅은 인터넷(클라우드)을 통해 서버, 스토리지, 데이터베이스 등의 컴퓨팅 서비스를 제공하는 서비스입니다. 아마존에서 가상 컴퓨터를 한 대 빌리는 것과 같습니다.
EC2 서비스도 이런 후불제 pc방과 같이 사용한 만큼 비용을 지불하기 때문에 '탄력적인'이라는 의미의 Elastic이라는 단어가 붙어 있습니다. Elastic은 비용적인 부분 뿐만이 아니라 필요에 따라 성능, 용량을 자유롭게 조절할 수 있다는 의미도 가지고 있습니다.
정리하자면 EC2 서비스는 AWS에서 비용, 성능, 용량 면에서 탄력적인 클라우드 컴퓨터를 제공하는 서비스라고 할 수 있습니다.
*EC2 서비스의 장점
1. 구성하는데 필요한 시간이 짧다. 만약 PC를 구매한다면 구매해서 배송받기까지의 시간이 필요하지만 EC2 서비스는 몇 번의 클릭만으로 PC를 구성할 수 있습니다.
2. AMI를 통해서 필요한 용도에 따라 다양한 운영체제에 대한 선택이 가능하다. EC2에서는 AMI라는 다양한 템플릿을 제공하고 있어서 필요에 따라 손쉽게 운영체제를 선택하고 구성할 수 있습니다.
3. 운영체제 뿐만 아니라 CPU와 RAM, 용량까지도 손쉽게 구성할 수 있습니다.
EC2는 컴퓨터를 한 대 빌리는 것이므로 컴퓨터로 할 수 있는 모든 일을 할 수 있습니다.
빌린 컴퓨터는 직접 사용하는 컴퓨터와 다르게 아마존이 전 세계에 만들어 놓은 데이터 센터(인프라)에 만들어져 있기 때문에 컴퓨터를 조작하기 위해 네트워크(인터넷)를 통해 컴퓨터를 제어해야 한다는 차이점이 있을 뿐 일반적인 컴퓨터와 다른 점은 없습니다.
아마존 EC2를 통해서 할 수 있는 가장 기본적인 일은 웹서버를 설치하고 웹서버를 통해서 사용자가 웹 브라우저를 통해 요청하는 서비스를 제공하는 것입니다.
인스턴스는 1대의 컴퓨터를 의미하는 단위이고 AWS에서 컴퓨터를 빌리는 것을 인스턴스를 생성한다고 합니다.
AMI (amazon machine image)는 소프트웨어 구성이 기재된 템플릿입니다.
이미지 종류는 단순히 운영체제(윈도우, 우분투 리눅스 등)만 깔려있는 템플릿을 선택할 수도 있고, 아예 특정 런타임이 설치되어 있는 템플릿이 제공되는 경우도 있습니다. (우분투 + node.js, 윈도우+JVM 등)
세팅되어 있는 AMI 이외에도 필요에 따라 직접 AMI를 구성할 수도 있습니다.
AWS EC2 인스턴스를 생성한다는 것은 AMI를 토대로 운영체제, CPU, RAM 혹은 런타임 등이 구성된 컴퓨터를 빌리는 것입니다.
RDS(Relational Database Service): AWS에서 제공하는 관계형 데이터베이스 서비스
EC2는 가상의 컴퓨터를 임대하는 서비스이다. EC2 인스턴스에 MySQL같은 관계형 데이터베이스 엔진을 설치하면 굳이 RDS를 사용할 이유가 없지 않을까요? 데이터베이스만 따로 분리해서 서비스를 이용해야 할 이유가 있을까요?
EC2 인스턴스에 관계형 데이터베이스 엔진을 설치해서 데이터를 관리할 때와 RDS를 통해 데이터를 관리할 때의 차이: 개인소유 차량과 렌터카 회사에서 대여한 차량
데이터베이스 엔진을 직접 설치할 때: 직접 인스턴스를 관리해야 하는 시간과 수고가 큼. 가용성과 내구성이 확보되지 않기 때문에 데이터베이스에 저장된 데이터가 유실되거나 정상적으로 사용하지 못할 확률이 커지며, 후에 필요에 따라 데이터베이스의 규모를 확장하기 어렵습니다.
RDS를 이용하는 것은 렌터카 회사에서 대여한 차량과 비슷합니다. 대여한 차량에 대한 유지 보수 등에 들어가는 시간과 수고를 렌터카 회사에서 대신해 주기 때문에 우리는 운전만 하면 됩니다. 사용자가 해야 할 일은 초기설정을 제외하고 데이터베이스에 저장된 데이터를 관리하는 일 밖에 없기에 큰 편의성을 느낄 수 있습니다.
기타 RDS 이용시 얻을 수 있는 장점으로는 다양한 데이터베이스 엔진 선택지를 제공한다는 점을 들 수 있습니다. 개인들은 자신의 필요에 맞게 데이터베이스를 선택하여 효율성을 높일 수 있습니다.
클라우드 스토리지란 인터넷 공간에 데이터를 저장하는 저장소입니다. 컴퓨터의 부품으로 비유하면 하드디스크에 해당됩니다. 컴퓨터의 하드디스크에 저장된 파일에 접근하기 위해서는 해당 컴퓨터를 이용해야 합니다. 그러나 클라우드 스토리지를 이용하면 웹 환경이라면 언제 어디서나 파일에 접근이 가능합니다.
S3는 simple storage service의 약자로 aws에서 제공하는 클라우드 스토리지 서비스입니다. s3도 뛰어난 접근성을 가지고 있습니다.
*s3를 사용했을 때 얻을 수 있는 이점
1. 높은 확장성, 확장성이 뛰어나면 많은 시간과 수고를 들이지 않고 스토리지 규모를 확장 축소할 수 있습니다.
2. s3에서는 스토리지 용량을 무한히 확장할 수 있습니다. 그리고 사용한 만큼만 비용을 지불하면 되기 때문에 비용적인 측면에서 매우 효율적입니다.
3. s3는 내구성이 높다. 내구성이 높으면 저장한 파일을 유실할 가능성이 적어집니다.
4. 가용성이 높다. 가용성이 높으면 스토리지에 저장된 파일들을 정상적으로 사용할 수 있는 시간이 길어집니다. 1년동안 s3에 파일을 저장했을 시 8.76시간 동안만 스토리지를 이용하는데 있어서 장애가 발생한다는 뜻입니다.
*aws는 어떤 원리로 높은 내구성과 높은 가용성을 보장하는 것일까요?
주황색 동그라미가 쳐진 지역이 있습니다. 이 지역을 리전이라고 부릅니다. 리전이란 aws에서 클라우드 서비스를 제공하기 위해서 운영하는 물리적인 서버의 위치를 뜻합니다. 주황색 동그라미 안에 숫자가 있는데 이는 리전에 위치한 가용영역의 수를 뜻합니다. 가용영역이란 각 리전 안에 존재하는 데이터 센터를 뜻합니다. 가용영역은 각각 개별적인 위치에 떨어져서 존재합니다. 그 이유는 한 가용영역이 재난으로 인하여 가동이 불가능해지는 상황에서도 다른 가용영역에 백업을 해놓은 데이터를 이용해서 문제없이 서버가 가동되게 하기 때문입니다.
S3가 제공하는 스토리지 클래스: 저장소를 어떤 목적으로 활용하는지에 따라서 결정됨
1. Standard 클래스: 데이터에 빠른 속도로 접근을 할 수 있고, 데이터 액세스 요청에 대한 처리 속도가 빠르다. 데이터를 오래 보관하는 목적으로는 효율적인 선택지가 아니다. 보관 비용이 오래 발생하기 때문이다.
2. Glacier 클래스: 데이터에 액세스하는 속도는 느리지만, 데이터를 보관하는 비용이 매우 저렴하다.
S3 사용 시의 이점: 정적 웹 사이트 호스팅이 가능하다.
정적 파일: 서버의 개입없이 생성된 파일.
동적 파일: 클라이언트가 서버에 요청을 보내면, 서버가 요청에 맞추어 그 자리에서 생성한 파일.
웹 호스팅: 서버의 한 공간을 빌려주어 웹 사이트의 배포, 운영이 가능하게 만들어주는 서비스.
버킷: 사용자들이 정적 웹 사이트를 배포할 수 있는 공간을 제공, 버킷이라는 저장 공간에 정적 파일을 업로드하고 버킷을 정적 웹 사이트 호스팅 용도로 구성하면 정적 웹 사이트를 배포할 수 있다.
버킷: S3에 저장되는 파일들이 담기는 바구니이다. 파일을 저장하는 최상위 디렉터리.
S3에서 저장되는 모든 파일은 버킷안에 저장되어야 하고, 버킷에는 무한한 양의 파일을 저장할 수 있다. 각각의 버킷은 이름을 가지고 있는데, 버킷의 이름은 속해있는 리전에서 유일해야 한다.
버킷 정책을 생성하여 해당 버킷에 대한 다른 유저의 접근 권한을 수정할 수 있다.
S3에서 버킷에 담기는 파일을 객체라고 부릅니다. 왜 객체라고 부를까? S3에서 저장소에 데이터(파일)를 저장할 때 키-값 페어 형식으로 데이터를 저장하기 때문이다.
파일의 값에는 실제 데이터를 저장합니다. 데이터의 최대 크기는 5TB입니다.
파일의 키는 각각의 객체를 고유하게 만들어주는 식별자 역할을 합니다. 파일의 키를 이용하여 원하는 객체를 검색할 수 있습니다.
메타데이터는 객체의 생성일, 크기, 유형과 같은 객체에 대한 정보가 담긴 데이터입니다. 객체를 설명해주는 데이터이다. 모든 객체는 고유한 URL 주소를 가지고 있다. URL 주소는 http://[버킷의 이름].S3.amazonaws.com/[객체의 키]의 형태를 띠고, URL 주소를 통해서도 원하는 데이터에 접근할 수 있습니다.
배포란?
1. 클라이언트
개발할 서비스를 사용자들이 이용할 수 있게 함. AWS 서비스 중의 하나인 S3를 이용해 사용자들에게 client application을 제공할 수 있습니다.
클라이언트 앱을 정적 파일로 빌드하여 제공합니다. 따라서 S3를 이용해서 클라이언트를 배포합니다. 이때 필요한 것이 빌드이다. 빌드란 실행할 수 있는 파일로 만드는 과정을 말한다. 예를 들어 exe같은 파일.
빌드란 불필요한 데이터를 없애고, 여러 갈래로 퍼져있는 데이터들을 통합 압축하여 배포하기에 최적화된 상태를 만드는 것입니다. 빌드하기 전과 비교했을 때 데이터의 용량이 줄어들고, 웹 사이트의 로딩 속도가 빨라진다는 장점이 생긴다. React 앱의 경우에는 npm run build를 실행하여 정적파일 형태의 결과물을 만들어 낸 후 배표하면 된다.
만약 사용자가 지구 반대편에 있다면 어떻게 해야 할까? AWS에서 제공하는 CDN 서비스인 CloudFront를 통해서 각지의 데이터 센터에 데이터를 분산시켜서 저장해 뒀다가 가까운 지역에서 데이터를 주는 방식으로 사용자에게 더 빠르게 서비스를 제공할 수 있습니다.
-
서버
Server Application은 어떻게 배포해야 할까? AWS EC2 서비스를 통해 손쉽게 서버를 구성하고 서비스를 제공할 수 있습니다. -
데이터베이스
AWS에서는 데이터베이스 특화 서비스인 RDS를 제공하고 있다. RDS 서비스를 이용하여 EC2를 통해 배포된 Server Application의 데이터를 저장, 제공하는 데이터베이스를 배포할 수 있습니다.
처음 배포된 여러분의 서비스는 도메인 주소를 통해 접근할 수 있을까요?
S3, EC2를 이용해서 배포된 서비스는 IP 주소 혹은 AWS에서 제공하는 여러분의 서비스와는 전혀 상관없는 긴 도메인 주소 www.todolist.ap-northeast-2.compute.amazonaws.com 를 통해 접근하게 됩니다.
직관적이고 짧은 주소(www.todolist.com)로 접근하기 위해서는 Route53 서비스를 이용하면 됩니다.
