Amazon Web Service 배포
Amazon Web Service
클라우드 컴퓨팅 & 배포
- 웹 개발자라면 간단한 배포 정도는 혼자 할 수 있어야 합니다.
- 배포를 위한 클라우드 서비스 Amazon Web Service(이하 AWS)를 이용해서 웹 애플리케이션을 배포합니다.
- 가상화 기술의 발전과 AWS의 등장은 클라우드 컴퓨팅에 혁신을 불러일으켰습니다. 만일 AWS가 없었더라면 우리는 아래와 같이 직접 서버를 구축하고, 관리해야 했을지도 모릅니다.
성취 목표
- Cloud와 Deployment의 의미를 각각 알고, 내 코드를 남에게 배포할 수 있다.
클라우드 컴퓨팅이 무엇인지 설명할 수 있다.
클라우드 컴퓨팅은 인터넷(“클라우드”)을 통해 서버, 스토리지, 데이터베이스, 네트워킹, 소프트웨어, 분석, 인텔리전스 등의 컴퓨팅 서비스를 제공하는 것입니다
과거에는 물리적 컴퓨터만을 이용한 온프레미스 환경이였는데 이 한계점(주기적 관리, 공간의 한계)를 극복하기 위해 가상화 기술의 발전으로부터 비롯되었습니다.
- 장점
- 필요할 때마다 컴퓨팅 능력을 유연하게 조절할 수 있습니다.
- 고정적인 비용이 들어가는 온프레미스와는 달리 사용한 만큼의 요금만 지불하면 됩니다.
- 컴퓨터의 스냅샷(“이미지”라고 부릅니다) 을 이용해 다른 컴퓨터로 즉시 이주(migration)가 가능합니다.
- 단점
운영환경이 특정 vendor(사업자)에게 종속됩니다. 백엔드 구성 자체가 특정 회사의 기술로만 구성 될 수 있어서 자체적인 서비스 해결에 불리합니다. 그러므로 벤더가 제공하는 기술을 익히는 것 뿐만 아니라 이 인프라 자체에 대한 이해가 중요합니다.
이런 클라우드는 모든 것을 서비스화하는 것을 목표로 합니다.
대표적인 클라우드 서비스의 형태는 SaaS, IaaS, PaaS 세 가지입니다.
- 장점
애플리케이션 배포가 어떻게 변화되어 왔는지 이해할 수 있다.
The Evolution of App Deployment and Packaging: 1990 to Now
- 전통적인 배포 시대 : 초기 조직은 애플리케이션을 물리 서버에서 실행했었다. 한 물리 서버에서 여러 애플리케이션의 리소스 한계를 정의할 방법이 없었기에, 리소스 할당의 문제가 발생했다. 예를 들어 물리 서버 하나에서 여러 애플리케이션을 실행하면, 리소스 전부를 차지하는 애플리케이션 인스턴스가 있을 수 있고, 결과적으로는 다른 애플리케이션의 성능이 저하될 수 있었다. 이에 대한 해결책은 서로 다른 여러 물리 서버에서 각 애플리케이션을 실행하는 것이 있다. 그러나 이는 리소스가 충분히 활용되지 않는다는 점에서 확장 가능하지 않았으므로, 물리 서버를 많이 유지하기 위해서 조직에게 많은 비용이 들었다.
가상화된 배포 시대 : 그 해결책으로 가상화가 도입되었다. 이는 단일 물리 서버의 CPU에서 여러 가상 시스템(VM)을 실행할 수 있게 한다. 가상화를 사용하면 VM간에 애플리케이션을 격리하고 애플리케이션의 정보를 다른 애플리케이션에서 자유롭게 액세스 할 수 없으므로, 일정 수준의 보안성을 제공할 수 있다.
가상화를 사용하면 물리 서버에서 리소스를 보다 효율적으로 활용할 수 있으며, 쉽게 애플리케이션을 추가하거나 업데이트할 수 있고 하드웨어 비용을 절감할 수 있어 더 나은 확장성을 제공한다. 가상화를 통해 일련의 물리 리소스를 폐기 가능한(disposable) 가상 머신으로 구성된 클러스터로 만들 수 있다. 각 VM은 가상화된 하드웨어 상에서 자체 운영체제를 포함한 모든 구성 요소를 실행하는 하나의 완전한 머신이다.
컨테이너 개발 시대 : 컨테이너는 VM과 유사하지만 격리 속성을 완화하여 애플리케이션 간에 운영체제(OS)를 공유한다. 그러므로 컨테이너는 가볍다고 여겨진다. VM과 마찬가지로 컨테이너는 자체 파일 시스템, CPU 점유율, 메모리, 프로세스 공간 등이 있다. 기본 인프라와의 종속성을 끊었기 때문에, 클라우드나 OS 배포본에 모두 이식할 수 있다.
컨테이너는 다음과 같은 추가적인 혜택을 제공하기 때문에 인기가 있다.
- 기민한 애플리케이션 생성과 배포 : VM 이미지를 사용하는 것에 비해 컨테이너 이미지 생성이 보다 쉽고 효율적임.
- 지속적인 개발, 통합 및 배포 : 안정적이고 주기적으로 컨테이너 이미지를 빌드해서 배포할 수 있고 (이미지의 불변성 덕에) 빠르고 효율적으로 롤백할 수 있다.
- 개발과 운영의 관심사 분리 : 배포 시점이 아닌 빌드/릴리스 시점에 애플리케이션 컨테이너 이미지를 만들기 때문에, 애플리케이션이 인프라스트럭처에서 분리된다.
- 가시성은 OS 수준의 정보와 메트릭에 머무르지 않고, 애플리케이션의 헬스와 그 밖의 시그널을 볼 수 있다.
- 개발, 테스팅 및 운영 환경에 걸친 일관성 : 랩탑에서도 클라우드와 동일하게 구동된다.
- 클라우드 및 OS 배포간 이식성 : Ubuntu, RHEL, CoreOS, 온-프레미스, 주요 퍼블릭 클라우드와 어디에서든 구동된다.
- 애플리케이션 중심 관리 : 가상 하드웨어 상에서 OS를 실행하는 수준에서 논리적인 리소스를 사용하는 OS상에서 애플리케이션을 실행하는 수준으로 추상화 수준이 높아진다.
- 느슨하게 커플되고, 분산되고, 유연하며, 자유로운 마이크로서비스 : 애플리케이션은 단일 목적의 머신에서 모놀리식 스택으로 구동되지 않고 보다 작고 독립적인 단위로 쪼개져서 동적으로 배포되고 관리될 수 있다.
- 리소스 격리 : 애플리케이션 성능을 예측할 수 있다.
- 자원 사용량 : 리소스 사용량 : 고효율 고집적.
AWS의 각 서비스가 어떤 목적에 부합하는지 이해할 수 있다.
S3의 목적과, 정적 웹 사이트 배포 방법을 이해할 수 있다.
S3(Simple Storage Service) : AWS에서 제공하는 클라우드 스토리지 서비스
- 뛰어난 접근성
- 확장성
- 강력한 내구성
- 99.99% 가용성
S3 사용자들이 대표적으로 많이 선택하는 스토리지 클래스는 두 가지가 있습니다. Standard 클래스와 Glacier 클래스입니다.
Standard 클래스는 범용적인 목적으로 사용하기 좋습니다. 데이터에 빠른 속도로 접근할 수 있고, 데이터 액세스 요청에 대한 처리 속도가 빠릅니다. 대신 데이터를 오래 보관하는 목적으로는 효율적인 선택지가 아닙니다. 보관 비용이 높게 발생하기 때문입니다.
장기적인 보관 목적으로 스토리지를 사용하실 때는 Glacier를 사용하는 것이 효율적입니다.
비록 저장된 데이터에 액세스하는 속도는 느리지만, 데이터를 보관하는 비용이 매우 저렴하다는 장점이 있습니다.
이 외에도 Standard-IA, One Zone-IA, S3 Glacier Deep Archive 등등 여러 가지 스토리지 클래스가 존재하여 사용자의 이용 목적에 따라 다양한 스토리지 클래스를 사용할 수 있습니다.
S3 사용 시 얻는 이점 중 하나로, 정적 웹 사이트 호스팅이 가능합니다.
- 정적 파일: 서버의 개입 없이 클라이언트에 제공될 수 있는 파일
- 웹 호스팅: 서버의 한 공간을 빌려주어 웹사이트의 배포, 운영이 가능하게 만들어주는 서비스
- S3에서는 버킷을 통해 정적 웹 사이트 호스팅이 가능
버킷
- 버킷은 파일을 담는 바구니(최상위 디렉토리)
- 무한히 많은 파일을 저장 가능
- 버킷의 이름은 버킷이 속한 리전에서 유일해야 함
- 버킷의 정책을 생성하여 액세스 권한을 부여 가능
객체
- 객체는 버킷에 담기는 파일
- 객체는 파일과 메타데이터로 구성
- 모든 객체는 고유한 키를 가짐
- URL 주소를 통해서 객체에 접근 가능
- URL 주소 형식 : http://버킷이름.S3.amazonaws.com/객체의키
EC2의 주요 용어를 이해할 수 있다. (AMI, 인스턴스, 인스턴스 유형, 스토리지 타입, 퍼블릭/프라이빗 IP)
- EC2 서비스는 AWS에서 비용, 성능, 용량 면에서 탄력적인 클라우드 컴퓨터를 제공하는 서비스라고 할 수 있습니다.
- AWS에서 컴퓨터를 빌리는 것을 인스턴스를 생성한다고 합니다.
- AMI는 소프트웨어 구성이 기재된 템플릿입니다.
- AWS EC2 인스턴스를 생성한다는 것은 AMI를 토대로 운영체제, CPU, RAM 혹은 런타임 등이 구성된 컴퓨터를 빌리는 것입니다.
Client 배포
빌드
- 불필요한 데이터를 없애고, 통합/압축하여 배포하기 최적화된 상태를 만드는 것
- 데이터의 용량이 줄어들고 웹 사이트 로딩 속도가 빨라진다
하지만 일반적인 의미의 빌드는, 소스코드를 실행 가능한 번들로 변환하는 컴파일 과정을 의미합니다. 웹 앱에서와같이 HTML, CSS, JS의 형태로 배포하는 경우는 조금 다릅니다. 웹 앱은 배포 가능한 정적 파일(static files)의 형태로 만들어 줘야 합니다.
asset 자체가 정적인 경우, 있는 그대로 배포하면 됩니다. React의 경우 npm run build와 같은 명령을 사용해서, 정적 파일 형태의 결과물을 만들어 낸 후 배포하면 됩니다. 사용하고 있는 환경에 따라 빌드 과정은 다를 수 있습니다.
S3로 사용자들에게 Client Application을 제공하고 있는데, 사용자가 지구 반대편에 있다면 어떻게 빠르게 서비스를 제공할 수 있을까요?
AWS에서 제공하는 CDN 서비스인 CloudFront를 통해서 각지의 데이터 센터에 데이터를 분산시켜서 저장해 뒀다가 가까운 지역에서 데이터를 주는 방식으로 사용자에게 더 빠르게 서비스를 제공할 수 있습니다.
사용자들이 제공받은 Client Application을 통해서 요청을 전달할 Server Application은 어떻게 배포해야 할까요?
AWS EC2 서비스를 통해 손쉽게 서버를 구성하고 서비스를 제공할 수 있습니다.
AWS에서는 Database 특화 서비스인 RDS 서비스를 제공하고 있습니다.
AWS가 유지 보수 작업을 담당하는 RDS를 이용하여 즉시 데이터베이스를 사용할 수 있습니다.
RDS 서비스를 이용하여 EC2를 통해 배포된 Server Application의 데이터를 저장, 제공하는 데이터베이스를 배포할 수 있습니다.
S3, EC2를 이용해서 배포된 서비스는 IP 주소 혹은 AWS에서 제공하는 여러분의 서비스와는 전혀 상관없는 긴 도메인 주소를 통해 접근하게 됩니다.
AWS에서 제공하는 Route 53 서비스를 이용하면 직관적인 도메인 주소를 통해서 서비스에 접근하도록 할 수 있습니다
EC2의 인스턴스 시작/중지/종료에 대해 이해할 수 있다.
RDS와 EC2에서의 MySQL 사용이 어떻게 다른지 이해할 수 있다.
RDS : AWS에서 제공하는 관계형 데이터 베이스 서비스
- EC2 인스턴스를 사용하면 데이터베이스와 관련해서 자동으로 관리를 담당하는 부분이 매우 적기 때문에, 사용자가 일일이 시간을 투자하여 데이터베이스 엔진의 설치와 버전 관리, 데이터 백업을 해야 합니다.
게다가 가용성과 내구성이 확보되지 않기 때문에 데이터베이스에 저장된 데이터가 유실되거나 정상적으로 사용하지 못할 확률이 커지며, 후에 필요에 따라 데이터베이스의 규모를 확장하기 어렵습니다
- RDS를 이용하면 데이터베이스 유지 보수와 관련된 일들을 RDS에서 전적으로 자동 관리합니다. 사용자가 해야 할 일은 초기 설정을 제외하고 데이터베이스에 저장된 데이터를 관리하는 일 밖에 없기에 큰 편의성을 느낄 수 있습니다.
- RDS 이용 시 얻을 수 있는 장점으로 다양한 데이터베이스 엔진 선택지를 제공한다는 점을 들 수 있습니다.
리전, 가용 영역
EC2, RDS, S3의 개념을 학습하고 있는데, 해당 서비스들이 공통적으로 ‘높은 가용성’과 ‘높은 내구성’을 보장한다는 점을 배우셨을 겁니다. AWS는 어떤 원리로 해당 서비스들의 높은 가용성과 내구성을 보장할 수 있는 걸까요?
첨부된 지도를 보시면 주황색 동그라미가 쳐진 지역이 있습니다. 이 지역을 ‘리전(Region)’이라고 부릅니다. 리전이란 AWS에서 클라우드 서비스를 제공하기 위해서 운영하는 물리적인 서버의 위치를 뜻합니다.
그리고 지도를 다시 보시면 주황색 동그라미 안에 숫자가 새겨져 있는데, 이 숫자는 리전에 위치한 가용 영역의 수를 뜻합니다. 가용 영역(Availability Zone)이란 각 리전 안에 존재하는 데이터 센터(IDC)를 뜻합니다. 가용 영역은 각각 개별적인 위치에 떨어져서 존재합니다. 그래서 한 곳의 가용 영역이 재난이나 사고로 인해 가동이 불가능해지더라도 다른 가용 영역에 백업을 해놓은 데이터를 활용하여 문제없이 서버가 가동되게 합니다. 이런 가동 방식 덕분에 AWS에서 제공하는 서비스들은 높은 가용성과 내구성을 보장합니다.
- CloudFront의 목적을 이해할 수 있다. (Advanced)
- 로드 밸런서 중 ELB, 그중에서 Application Load Balancer의 목적을 이해할 수 있다. (Advanced)
- Route 53의 목적을 이해하고, 도메인을 연결해 HTTPS로 배포할 수 있다. (Advanced)
배포 시 발생하는 문제를 이해하고 고칠 수 있다.
서버를 프로세스로 작동시키고, 로그를 확인할 수 있다.
프로그램과 프로세스
- 프로세스는 컴퓨터 프로그램의 인스턴스
- 같은 프로그램을 여러 개 실행하는 경우, 여러 개의 프로세스가 존재함
- 일반적으로 “실행 중인 프로그램”을 의미
- 프로세스를 보는 방법
windows환경: 작업 관리자
맥 환경: 활성 상태 보기
리눅스 : “ps”명령어
여러분이 ssh 프로그램을 통해 EC2에 접속하고, 터미널을 강제 종료한다고 가정해 봅시다.
이때 과연 어떤 일이 발생할까요. 첫 번째로는, 로컬에 띄워져 있던 ssh 프로세스가 강제 종료됩니다.
ssh 프로세스는 강제 종료 시, EC2 상의 프로세스도 같이 종료시킵니다. 따라서 EC2 상의 node 프로세스도 종료됩니다(다른 말로 실행되고 있던 서버가 종료됩니다)
빌드 및 배포 시 필요한 환경 설정을 할 수 있다.