클라우드 서비스를 제공하는 밴더사 중 하나인 AWS에 대해 알아보고 배포해보자!
통칭 밴더사, 클라우드 서비스를 제공하는 회사를 뜻한다.
이러한 요소들을 장점으로 가지고 있다.
또 다양한 회사들이 있는데 오라클, 마이크로소프트 아주르, 파이어베이스, 아마존 웹 서비스, 헤로쿠 등이 있는데 가장 유명한 것이 아마존의 AWS.
우리는 AWS로 배포를 해볼 것이다!!!@
인터넷(클라우드)을 통해 서버, 스토리지, 데이터베이스 등의 컴퓨팅 서비스를 제공하는 서비스
이러한 장점이 있다!
컴퓨터가 생기고 웹, 앱, 게임 등 여러 상호작용할 수 있는 프로그램이 늘어가면서 당연히 서버도 많이 필요로 하게 됐다. 서비스를 제공하기 위해 전산실 등에 컴퓨터들을 놓았다. 당연히 서버가 요청에 대한 수용 능력이 한계에 도달한다면 더 컴터들을 놓았다.
하지만 주기적인 관리와 공간적 한계 때문에 서버를 증축하기 어려워지자 이러한 수요를 포착한 거대 기업들은 데이터 센터라는 거대한 전산실을 구축했고, 이때부터 데이터 센터의 유휴 자원을 대여하는 서비스가 등장하기 시작했다.
이러한 개념에 착안해 가상화(Virtualization) 기술의 발전으로부터 비롯되고, 물리적인 컴퓨터가 아닌(온프레미스) 가상 컴퓨터를 대여하는 Cloud 서비스도 생겨났다!
즉, 서버의 자원과 공간, 및 네트워크 환경을 제공을 빌려 사용하는 Cloud Computing 시대가 열린 것이다!
배포, 우리가 개발한 서비스를 사용자들이 이용 가능하게 하는 일련의 과정
여기서 문제가 Development 환경과 Production 환경은 서로 다를 수 있기에 생기는 간극이다.
나 혼자면 모르겠다만 여러 명이 함께 작업하는 프로젝트라면 어떨까요? node 버전도 제각각일 거고, 인증 정보나 데이터베이스 등에 접근하기 위해 사용하는 엔드포인트도 제각각인 것 등 통일 시켜야하는 부분들이 생긴다.
예를 들어 내 로컬에 설치된 데이터베이스 비밀번호는 rlazheld1234!
인데, 클라우드에 설치된 데이터베이스 비밀번호는 supersecret!
일 수가 있다.
즉! 배포에서는, 환경의 차이를 이해하고 환경 설정을 코드와 분리하는 것이 중요하다!
통일시키고 해결하는 방법은 무엇이 있을까?
3가지 방법이 있는데 1. 코드 상의 모든 곳에 절대 경로가 아닌 상대 경로를 사용해야 하고, 2. .env
등을 이용해 환경 변수를 설정하자! 3. 또 docker와 같은 가상화 도구는 환경 자체를 메타데이터로 담아서 아예 모든 개발 환경을 통일시킬 수 있다.
환경 설정을 코드로부터 분리하는 방법론을 배워서 해결 해보도록 하자!
이제 기본적인 구조는 배웠다. AWS의 기본 개념에 대해 배워보자.
그전에 당연히 AWS의 리소스를 사용하는 만큼 온디맨드 방식으로 비용을 지불하는 것은 당연한 원칙이므로 돈을 써야한다. 코스에서 지원해준다니 개꿀! 하지만 아쉽게도 유효기간이 이번주 목요일까지다.. 슬퍼
지원하는 AWS는 이렇다. 코스에서 가입한 AWS IAM User 계정으로 로그인하자!
Elastic Compute Cloud
AWS에서 비용, 성능, 용량 면에서 탄력적인 클라우드 컴퓨터를 제공하는 클라우드 컴퓨팅 서비스
Elastic의 뜻은 '탄력적인'이다. 즉! 후불제 PC방과 같이 사용한 만큼비용을 지불하고, 필요에 따라 성능, 용량을 자유롭게 조절할 수 있다는 의미도 가지고 있다는 걸 뜻한다!
AWS EC2 인스턴스를 생성한다는 것은 AMI를 토대로 운영체제, CPU, RAM 혹은 런타임 등이 구성된 컴퓨터를 빌리는 것이다.
Relational Database Service
AWS에서 제공하는 관계형 데이터베이스 서비스
왜 RDS를 사용할까? 개인이 EC2 인스턴스에 MySQL 같은 관계형 데이터베이스 엔진을 설치하면 굳이 RDS를 사용할 이유가 없지 않을까? 데이터베이스만 따로 분리해서 서비스를 이용해야 할 이유가 있을까?
기존 DB 엔진을 개인이 관리한다면 데이터 백업, 설치/관리, 규모 및 가용성, 내구성 확보 등 할 게 많아진다. 하지만 AWS에선 RDS를 이용하면 데이터베이스 유지 보수와 관련된 일들을 RDS에서 전적으로 자동 관리해줘 사용자는 초기 설정과 BD에 저장된 데이터를 관리하는 일 밖에 없어 편하다!
다양한 DB 엔진이 있으니 실무에 맞게 취사 선택하여 공부하자
그 전에 클라우드 스토리지 개념을 알고가야한다. 클라우드 스토리지란 인터넷 공간에 데이터를 저장하는 저장소이다. 즉, 웹 환경만 있으면 언제든지 저장하고 꺼내 쓸 수 있어 뛰어난 접근성이 있어 이점을 가지고 있다.
구글의 Google Drive, 네이버의 MYBOX, 마이크로소프트의 Onedrive, 애플의 icloud와 같은 서비스가 그 예다.
그렇다면 S3는?!
Simple Storage Service
AWS에서 제공하는 클라우드 스토리지 서비스
http://[버킷의 이름].S3.amazonaws.com/[객체의 키]
)특이하게도 S3는 다양한 스토리지 클래스를 제공해 저장소를 어떤 목적으로 활용할지에 따라 효율적으로 선택 가능!
보통 우리는 Standard 클래스와 Glacier 클래스를 사용한다.
시작하자!
localhost의 주소로 배포하면 안되고, Production 환경을 고려해 전략을 짜보면
를 고려해보자.
S3라는 서비스를 통해 사용자들에게 Client를 제공하면 된다.
로컬에선 CRA로 npm start
를 해서 클라이언트를 실행시켰다. AWS에선 클라이언트를 위해서 EC2 인스턴스를 사용하나? 놉! 클라이언트 앱을 정적 파일로 빌드하여 제공하자! 그래서 S3를 이용해서 클라이언트를 배포하는 것.
빌드의 의미는 쉽게 말해 불필요한 데이터를 없애고, 여러 갈래로 퍼져있는 데이터들을 통합/압축하여 배포하기에 최적화된 상태를 만드는 것이다. 그냥 소스코드를 실행 가능한 번들로 변환하는 컴파일하는 빌드를 해 웹앱을 배포 가능한 정적 파일(static files)의 형태로 만들어 줘야한다.
또 S3로 사용자들에게 Client Application을 제공하고 있는데, 사용자가 지구 반대편에 있다면 어떻게 빠르게 서비스를 제공할 수 있을까?
AWS에서 제공하는 CDN 서비스인 CloudFront
를 통해 각지의 데이터 센터에 데이터를 분산시켜서 저장해 뒀다가 가까운 지역에서 데이터를 주는 방식으로 사용자에게 더 빠르게 서비스를 제공하자!
사용자들이 제공받은 Client Application을 통해서 요청을 전달할 Server Application은 어떻게 배포해야 할까?
AWS EC2 서비스를 통해 손쉽게 서버를 구성하고 서비스를 제공 가능!
아까 AWS에서는 Database 특화 서비스인 RDS 서비스를 제공한다고 배웠다. 다시 말해 AWS가 유지 보수 작업을 담당하는 RDS를 이용하여 즉시 데이터베이스를 사용 가능하다는 얘기다.
즉! RDS 서비스를 이용하여 EC2를 통해 배포된 Server Application의 데이터를 저장, 제공하는 데이터베이스를 배포할 수 있다!
도메인 주소를 커스텀하고 싶다면? AWS에서 제공하는 Route 53
서비스를 이용하면 된다! 직관적인 도메인 주소를 통해서 서비스에 접근 가능!
서버와 클라이언트 두개를 일반적으로 배포할 것이다.
실습엔 이미 EC2 인스턴스가 만들어져 있지만 나중에 생성 할때 도움 될 것들을 필기한다.
% chmod 400 ~/Downloads/[다운 받은 pem 파일 지정 경로]
.pem
키가 필요한 것 연결시켜보자.