Cloud Computing
예전에는 컴퓨터의 능력을 늘리기 위해 추가적인 컴퓨터를 같은 공간에 배치하여 서버를 증설하는 방법이었습니다. 그리고 컴퓨터의 성능을 높이고 부피를 줄이는 방법을 사용해왔습니다. 하지만 아무리 부피를 줄이고 성능을 높이더라도 공간의 한계가 오기마련이기 때문에 기업들은 데이터센터라는 거대한 건물을 세우기 시작했습니다.
이때부터 데이터센터의 유휴 자원을 대여하는 서비스가 등장하기 시작했습니다. 즉 서버의 자원과 공간, 및 네트워크 환경을 제공을 빌려 사용하는 클라우드 컴퓨팅이 시작된 순간입니다.
데이터 센터에서는 서버의 자원과 공간, 및 네트워크 환경을 제공합니다. 이러한 환경을 "온프레미스"라고 부릅니다. 현대의 클라우드 컴퓨팅은 앞서 설명한 데이터 센터와 비슷한 역할을 하지만, 물리적인 컴퓨터가 아닌, 가상 컴퓨터를 대여한다는 점이 다릅니다. 이는 가상화(Virtualization) 기술의 발전으로부터 비롯되었습니다.
장점
-
필요할 때마다 컴퓨팅 능력을 유연하게 조절할 수 있습니다.
-
고정적인 비용이 들어가는 온프레미스와는 달리 사용한 만큼의 요금만 지불하면 됩니다.
-
컴퓨터의 스냅샷("이미지"라고 부릅니다) 을 이용해 다른 컴퓨터로 즉시 이주(migration)가 가능합니다.
단점
운영 환경 자체가 클라우드 제공자에게 종속되어 버리므로, 클라우드 서비스에 문제가 생기면 내가 배포하고 관리하는 환경에도 영향이 미칩니다.
클라우드는 모든 것을 서비스화하는 것을 목표로 합니다.
클라우드 서비스의 형태
SaaS는 Software as a Service의 약자입니다.
클라우드 제공자가 당장 사용 가능한 소프트웨어를 제공하는 경우 대부분 SaaS에 해당합니다.
PaaS는 Platform as a Service의 약자입니다.
대부분 클라우드 제공자가 데이터베이스, 개발 플랫폼까지 제공하는 경우 대부분 PaaS에 해당합니다.
IaaS는 Infrastructure as a Service의 약자입니다.
클라우드 제공자가 가상 컴퓨터까지 제공하는 경우 대부분 IaaS에 해당합니다.
궁금한 점
- 깃허브는 iaas인가?
- 구글드라이브도 iaas아닐까 -> 구글드라이브는 s3이다!
Deployment
배포랑 개발한 서비스를 사용자가 이용가능하게 하는 과정입니다.
과정
-
development - 각자의 컴퓨터에서 코드를 작성하고 테스트 하는 과정입니다. 개발단계이기 때문에 실제 데이터를 이용하지 않고 더미데이터를 이용해서 테스트합니다.
-
intergration - 각자의 컴퓨터에서 작성한 코드를 합치는 과정입니다.
내가 작성한 코드가 다른 코드를 침범해서 오류를 일으키지 않는지, 코드간에 conflict가 있지는 않는지 확인하는 과정을 거칩니다. -
staging - 실제 출시단계인 Production단계와 가장 유사한 환경에서 테스트를 진행합니다.
실제 데이터를 복사해서 문제가 있지 않은지 등 다양한 환경에서 테스트를 진행합니다.
또한 서비스와 관련된 부서 혹은 인원의 확인 과정을 거칩니다. 예를 들면 작성된 코드가 마케팅팀 혹은 디자인팀 예상했던 결과인지에 확인을 거치는 과정입니다. -
production - 개발된 서비스를 출시하는 단계입니다.
사용자가 접속할 수 있는 Production환경에서 코드를 구동하고 서비스를 제공합니다.
실제 데이터를 가지고 서비스가 운영되기 때문에 문제가 생기면 안되는 단계입니다.
AWS(Amazon Web Service)
EC2(elastic compute cloud)
EC2란 아마존 웹 서비스에서 제공하는 클라우드 컴퓨팅 서비스입니다.
클라우드 컴퓨팅은 인터넷(클라우드)을 통해 서버, 스토리지, 데이터베이스 등의 컴퓨팅 서비스를 제공하는 서비스입니다.
정리하면 EC2는 아마존에서 가상의 컴퓨터를 한 대 빌리는 것과 같습니다. 사용한 만큼 비용을 지불하기 때문에 탄력적인 이라는 의미의 Elastic이라는 단어가 붙어있습니다.
Elastic은 비용적인 부분 뿐만이 아니라 필요에 따라 성능, 용량을 자유롭게 조절할 수 있다는 의미도 가지고 있습니다.
정리하자면 EC2서비스는 AWS에서 비용, 성능, 용량면에서 탄력적인 클라우드 컴퓨터를 제공하는 서비스라고 할 수 있습니다.
장점
-
구성하는 데 필요한 시간이 짧다.
만약 PC를 구매한다면 구매해서 배송되는 데까지의 시간이 필요하지만, EC2 서비스는 몇 번의 클릭만으로 PC를 구성할 수 있습니다. 또한, 이후에 설명할 AMI를 통해서 필요한 용도에 따라 다양한 운영체제에 대한 선택이 가능하다는 것입니다. EC2에서는 AMI라는 다양한 템플릿을 제공하고 있어서 필요에 따라 손쉽게 운영체제를 선택하고 구성할 수 있습니다. 실제 EC2 인스턴스를 만들 때 저는 프리티어에서 우분투를 사용했지만 여러가지의 os들을 사용할 수 있는 것을 확인했습니다. 운영체제뿐만이 아니라 CPU와 RAM, 용량까지도 손쉽게 구성할 수 있습니다. -
EC2는 컴퓨터를 한 대 빌리는 것이므로 컴퓨터로 할 수 있는 모든 일을 할 수 있습니다.
빌린 컴퓨터는 직접 사용하는 컴퓨터와 다르게 아마존이 전 세계에 만들어 놓은 데이터 센터(인프라)에 만들어져 있기 때문에
컴퓨터를 조작하기 위해 네트워크(인터넷)를 통해서 컴퓨터를 제어해야 한다는 차이점이 있을 뿐 일반적인 컴퓨터와 다른 점은 없습니다.
AMI(amazon machine image)
AMI는 소프트웨어 구성이 기재된 템플릿입니다.
이미지 종류로는 단순히 운영체제(윈도우, 우분투 리눅스 등)만 깔려있는 템플릿을 선택할 수도 있고, 아예 특정 런타임이 설치되어있는 템플릿이 제공되는 경우도 있습니다. (우분투 + node.js, 윈도우 + JVM 등)
AWS EC2 인스턴스를 생성한다는 것은 AMI를 토대로 운영체제, CPU, RAM 혹은 런타임 등이 구성된 컴퓨터를 빌리는 것입니다.
SSH 프로토콜
SSH 프로토콜은 서로 다른 PC가 인터넷과 같은 Public Network를 통해 통신을 할 때 보안상 안전하게 통신을 하기 위한 통신 규약입니다. ec2에 접속하기 위해서는 pem으로 안전하게 통신을 해야한다. 인스턴스를 생성할 때 pem없이는 해당 인스턴스로 접속할 수 없습니다.
RDS
RDS는 Relational Database Service의 약자로 AWS에서 제공하는 관계형 데이터베이스 서비스입니다.
왜 RDS를 사용할까?
EC2 인스턴스를 사용하면 데이터베이스와 관련해서 자동으로 관리를 담당하는 부분이 매우 적기에, 사용자가 일일이 시간을 투자하여 데이터베이스 엔진의 설치와 버전 관리, 데이터 백업을 해야 합니다. 게다가 가용성과 내구성이 확보되지 않기에 데이터베이스에 저장된 데이터가 유실되거나 정상적으로 사용하지 못할 확률이 커지며, 후에 필요에 따라 데이터베이스의 규모를 확장하기 어렵습니다.
😀️RDS를 이용하면 데이터베이스 유지보수와 관련된 일들을 RDS에서 전적으로 자동 관리합니다. 사용자가 해야할 일은 초기 설정을 제외하고 데이터베이스에 저장된 데이터를 관리하는 일 밖에 없기에 큰 편의성을 느낄 수 있습니다.
기타 RDS 이용 시 얻을 수 있는 장점으로 다양한 데이터베이스 엔진 선택지를 제공한다는 점을 들 수 있습니다.
회사에서 근무하고 있는 실무자는 회사에 필요한 데이터베이스 엔진을 취사선택하여 이용할 수 있습니다 .
그 외 일반 사용자는 데이터베이스 엔진마다 제공하는 기능이 조금씩 다르기에 필요와 목적에 맞게 데이터베이스 엔진을 선택하여 효율성을 높일 수 있습니다.
S3
우리는 알게 모르게 클라우드 스토리지 서비스를 이용해왔습니다. 클라우드 스토리지란 쉽게 말해서 인터넷 공간에 데이터를 저장하는 저장소입니다. 컴퓨터 부품으로 비유하면 하드디스크의 역할을 하는 서비스입니다. 구글의 Google Drive, 네이버의 MYBOX, 마이크로소프트의 Onedrive등이 있습니다.
클라우드 스토리지 서비스의 장점으로는 1. 뛰어난 접근성을 가지고 있습니다. 컴퓨터의 하드디스크에 저장된 파일에 접근하기 위해서는 해당 컴퓨터를 이용해야만 합니다. 그러나 클라우드 스토리지를 이용하면 웹 환경이라면 언제 어디서나 저장된 파일에 접근할 수 있습니다. 또한 컴퓨터뿐만 아니라 웹에 접속할 수 있는 다른 전자기기를 활용하여 클라우드 스토리지에 저장된 데이터에 접속할 수 있습니다.
S3는 Simple Storage Service의 약자로 AWS에서 제공하는 클라우드 스토리지 서비스입니다.
클라우드 스토리지 서비스가 뛰어난 접근성을 가지고 있다는 점을 배웠습니다. S3도 마찬가지로 뛰어난 접근성을 가지고 있습니다.
장점
- 높은 확장성
확장성이 높으면 많은 시간과 수고를 들이지 않고 스토리지 규모를 확장/축소할 수 있습니다. 또한 S3에서는 스토리지의 용량을 무한히 확장할 수 있습니다. 그리고 사용한 만큼만 비용을 지불하면 되기 때문에 비용적인 측면에서 매우 효율적입니다.
2.높은 내구성
스토리지의 내구성이 높으면 저장된 파일을 유실할 가능성이 적어집니다. S3는 99.999999999%의 내구성을 보장합니다. - 높은 가용성
가용성이 높으면 스토리지에 저장된 파일들을 정상적으로 사용할 수 있는 시간이 길어집니다. S3는 연간 99.99%의 스토리지 가용성을 보장하도록 설계가 되어 있습니다.
-> AWS에서 클라우드 서비스를 제공하기 위해서 운영하는 물리적인 서버의 위치를 뜻하는 리전마다 위치한 여러개의 데이터센터가 서로 백업을 해준다. 전세계에 리전은 여러군데가 있고 그 리전안에 가용영역, 즉 데이터센터가 여러개가 있다. -> 내구성, 확장성, 가용성이 높은 이유
S3는 다양한 스토리지 클래스를 제공합니다. 저장소를 어떤 목적으로 활용할지에 따라 효율적으로 선택할 수 있는 스토리지 클래스가 달라집니다.
S3 사용자들이 대표적으로 많이 선택하는 스토리지 클래스는 두 가지가 있습니다. Standard 클래스와 Glacier 클래스입니다.
Standard 클래스는 범용적인 목적으로 사용하기 좋습니다. 데이터에 빠른 속도로 접근할 수 있고, 데이터 액세스 요청에 대한 처리 속도가 빠릅니다. 대신 데이터를 오래 보관하는 목적으로는 효율적인 선택지가 아닙니다. 보관 비용이 높게 발생하기 때문입니다.
장기적인 보관 목적으로 스토리지를 사용하실 때는 Glacier를 사용하는 것이 효율적입니다. 비록 저장된 데이터에 액세스하는 속도는 느리지만, 데이터를 보관하는 비용이 매우 저렴하다는 장점이 있습니다.
- 정적 웹 사이트 호스팅이 가능
정적 웹 페이지는 파일 서버에 미리 저장된 파일을 그대로 사용자에게 전달하는 웹 페이지입니다. 저장된 파일이 변경되지 않는 한 서버는 클라이언트의 요청에 항상 동일한 파일을 전달합니다. -> ip마다 다른 모습을 보여줘야한다면 동적 웹 페이지가 될 것이다!
웹 호스팅 업체들을 통해 개인 또는 단체가 웹 호스팅 업체가 제공하는 서버의 한 공간을 빌려서 원하는 서비스를 배포할 수 있습니다.
S3에서는 버킷이 사용자들이 웹 페이지를 배포할 수 있는 공간을 제공합니다. 버킷에 정적 웹 페이지를 업로드하고 정적 웹 사이트 호스팅 용도로 구성을 바꾸시면, 다른 사용자가 버킷에 저장된 정적 웹 페이지에 접근할 수 있습니다.
버킷이란 S3에 저장되는 파일들이 담기는 바구니입니다. 파일을 저장하는 최상위 디렉터리라고도 설명할 수 있습니다.
S3에서 저장되는 모든 파일은 버킷 안에 저장되어야 하고, 버킷에는 무한한 양의 파일을 저장할 수 있습니다. 그리고 각각의 버킷은 이름을 가지고 있는데, 버킷의 이름은 버킷이 속해 있는 리전(버킷이 생성된 지역)에서 유일해야 합니다.
또한 버킷 정책을 생성하여 해당 버킷에 대한 다른 유저의 접근 권한을 수정할 수 있습니다.
S3에서 버킷에 담기는 파일을 객체라고 부릅니다. S3에서 저장소에 데이터를 저장할 때 키-값 페어 형식으로 데이터를 저장하기 때문입니다.
S3에 저장되는 객체는 파일과 메타데이터로 구성됩니다. 파일에 대해서 먼저 알아보겠습니다.파일은 위에 설명한 대로 키-값 페어 형식으로 데이터를 저장합니다.
파일의 값에는 실제 데이터를 저장합니다. S3 객체의 값으로써 저장될 수 있는 데이터의 최대크기는 5TB입니다.
파일의 키는 각각의 객체를 고유하게 만들어주는 식별자 역할을 합니다. 파일의 키를 이용하여 원하는 객체를 검색할 수 있습니다.
메타데이터는 객체의 생성일, 크기, 유형과 같은 객체에 대한 정보가 담긴 데이터입니다. 객체를 설명하는 데이터라고 이해하시면 좋습니다.
모든 객체는 고유한 URL 주소를 가지고 있습니다.
URL 주소는 http://[버킷의 이름].S3.amazonaws.com/[객체의 키]의 형태를 띠고, URL 주소를 통해서도 원하는 데이터에 접근할 수 있습니다.
배포하는법
클라이언트 앱을 정적 파일로 빌드하여 제공합니다.
따라서 S3를 이용해서 클라이언트를 배포합니다.
빌드란 쉽게 말해서 불필요한 데이터를 없애고, 여러 갈래로 퍼져있는 데이터들을 통합/ 압축하여 배포하기에 최적화된 상태를 만드는 것입니다
😀️빌드 과정을 진행하기 전과 비교했을 때 데이터의 용량이 줄어들고, 웹 사이트의 로딩 속도가 빨라진다는 장점이 생깁니다.
일반적인 의미의 빌드는, 소스코드를 실행 가능한 번들로 변환하는 컴파일 과정을 의미합니다. 웹 앱에서와같이 HTML, CSS, JS의 형태로 배포하는 경우는 조금 다릅니다. 웹 앱은 배포 가능한 정적 파일(static files)의 형태로 만들어 줘야 합니다.
asset 자체가 정적인 경우, 있는 그대로 배포하면 됩니다. React의 경우 npm run build와 같은 명령을 사용해서, 정적 파일 형태의 결과물을 만들어 낸 후 배포하면 됩니다. 사용하고 있는 환경에 따라 빌드 과정은 다를 수 있습니다.
S3로 사용자들에게 Client Application을 제공하고 있는데, 사용자가 지구 반대편에 있다면 어떻게 빠르게 서비스를 제공할 수 있을까요?
AWS에서 제공하는 CDN 서비스인 CloudFront를 통해서 각지의 데이터센터에 데이터를 분산시켜서 저장해 뒀다가 가까운 지역에서 데이터를 주는 방식으로 사용자에게 더 빠르게 서비스를 제공할 수 있습니다.
AWS에서 제공하는 Route 53 서비스를 이용하면
직관적인 도메인 주소를 통해서 서비스에 접근하도록 할 수 있습니다.
->
서버는 ec2를 통해서 rds에 저장
클라이언트는 정적파일로 빌드하여 s3로 저장
보안그룹
보안그룹이란 인스턴스로 들어가고 인스턴스에서 나가는 트래픽에 대한 가상 방화벽입니다.
인스턴스로 들어가는 트래픽은 인바운드
인스턴스에서 나가는 트래픽을 아웃바운드라고 합니다.
인바운드규칙은 EC2 인스턴스로 들어오는 트래픽에 대한 규칙입니다.
인바운드 규칙에 허용되지 않은 규칙은 인스턴스로 접근하지 못하도록 필터링 됩니다.
아웃바운드 규칙은 EC2 인스턴스에서 나가는 트래픽에 대한 규칙입니다.
프로세스 매니지먼트 도구 PM2
프로세스는 엄밀하게 이야기하면, 컴퓨터 프로그램이 실행될 때 프로그램 실행에 필요한 내용이 컴퓨터 메모리에 적재된다는 의미를 담고 있습니다. 이 말이 조금 어렵다면, "실행 중인 프로그램"이라는 의미로 기억해도 무방합니다.
😀️pm2를 사용하면 웹 서버가 구동 중인 node 프로세스가 종료되지 않게끔 만들어줍니다.
PM2는 node.js로 실행되는 프로그램(프로세스)를 관리해주며, 백그라운드에서 실행되게 만들 수 있습니다.
pm2 start --.js
pm2 stop --.js
pm2 restart --.js
pm2 ls
스프린트를 하면서 헤맸던 부분
-
pm2 client index.js
sudo npm start app.js 하면 일단 스프린트는 안꺼진다
-> 좋은방법이 아닌 것 같음 -
80번 포트에서 관리자권한으로 pm2를 실행해주어야하는데 잘 되지 않는다.
authbind로 관리자 권한을 주어서 실행을 하니 에러가 뜨지 않고 정상적으로 프로세스가 실행되는 것을 확인했다.
정적 웹 사이트를 호스팅하는 과정은
1. 구현이 완성된 정적 웹 페이지를 빌드합니다.
-
빌드 과정이 끝나면 S3 대시보드에 접속하여 버킷을 생성하고, 생성한 버킷을 정적 웹 사이트 호스팅 용으로 구성합니다.
-
그 다음으로 빌드된 정적 웹 페이지를 버킷에 업로드합니다. 업로드가 완료되면 퍼블릭 액세스 차단 설정을 해제하고, 다른 사용자의 접근 권한을 부여하는 버킷 정책을 생성합니다.
-
모든 과정이 끝나면 다른 사용자들이 버킷에 업로드된 정적 웹 페이지에 접속할 수 있습니다.
빌드란 작성한 코드의 불필요한 데이터를 없애고, 통합 및 압축하여 배포하기 이상적인 상태를 만드는 과정을 말합니다.
-> 빌드 과정을 통하여 코드를 담고 있는 데이터의 용량이 줄어들고, 웹 사이트의 로딩 속도가 빨라진다고 한다!
Office Hour
클라우드 컴퓨팅 다시 한번 확인하기
버추얼머신 검색해보기!
도커?
운영체제, 개발환경에 대한 템플릿
이미지를 바탕으로 만든 가상 컴퓨터
ec2 주로 서버를 올린다.
s3 정적 파일 올린다. 빌드 된 파일
rds 관계형데이터베이스
클라우드 프론트 https + cdn
라우트53 도메인 이름 변경
acm, iam ??? 확인하기
환경설정을 해야하는 이유? > env > 환경변수를 지정해주어야 하는 이유
1. 보안을 위해서.
2. 서버, 클라이언트 프로그램이 어떤값으로 연결되어있는지 확인하기 위해서
빌드 필요성, 정적 웹사이트 배포
서버애플리케이션을 프로세스로 관리하는 이유
-> 서버를 키고 터미널을 끄면 서버가 꺼진다. 이를 방지하기 위함
aws
이미지: 운영체제 템플릿, 우분투 리눅스, 윈도우
인스턴스: 이미지를 가상으로 만든 가상 컴퓨터
보안그룹: 방화벽 ip 주소, 포트 웰논포트 검색
버킷: 객체 저장단위
iam정책: aws에서 어떤 리소스에 접근가능하고 불가능한지 정책을 정해준다.
aws 버지니아에 인스턴스 만들어서 해보기
-> 2021.04.22일 다시 진행해보니 cloudfront 까지 성공했다
AWS IAM
사용자, 그룹의 권한을 부여하고 관리가 가능할수 있도록 해주는 서비스
권한을 세분화 하지 않는경우 모든 리소스에 접근하기 위한 계정을 여러 인원들이 공유할수도 있습니다.
하지만 일부 인원들은 이런 계정이 그렇게 까지 필요하지 않을수도 있습니다.
다른 부분에서 권한을 세분화 하는 이유를 찾을수 있습니다.
세밀한 관리가 필요한 매우 중요한 서비스, 리소스들이 적당한 예입니다.
대체로 이런 서비스, 리소스들은 권한을 가지지 못한 사람들이 접근할수 없습니다.
만약 이런 서비스, 리소스를 대상으로한 공격이 있다 하더라도 특정 권한이 없는한 공격이 성사될수 없습니다.
이러한 이유로 권한을 세분화하여 특정 그룹, 특정 사용자들만 특정 리소스에 접근할수 있도록 하는것이 일반적입니다.
cloudfront
cdn을 활용하여 콘텐츠를 좀더 빠르고 효율적으로 제공한다. 세계 곳곳에 분포하는 데이터 센터에 콘텐츠를 저장해두었다가 콘텐츠 요청을 받으면 지리적으로 가장 가까운 데이터 센터에서 콘텐츠를 제공해주는 방식이다.
CDN이 다룰수 있는 콘텐츠의 종류는 정적 콘텐츠와 동적 콘텐츠로 구분된다. 정적 콘텐츠는 동영상, HTML 파일과 같이 변화가 거의 없는 콘텐츠와 더불어 뉴스 기사등 개인화 되지 않은 대중적인 콘텐츠에 해당합니다. 이런 콘텐츠들은 변화가 거의 없기때문에 CDN의 캐시 센터에 저장하는것이 적합합니다.
-> 그렇기 때문에 앱을 npm run build를 해서 정적 웹 호스팅을 하는 것인가?
동적콘텐츠는 위치, IP 주소등 접근할때 마다 내용이 달라진다. 또한 카드번호, 전화번호등 개인화된 정보가 포함되어 있을 수 있다. CDN에 저장되어 있는 콘텐츠들은 내용이 바뀔때마다 CDN 서버들에도 변경내용이 전파되어야 하는데 내용이 자주 바뀌는 동적 콘텐츠 자체는 CDN 네트워크가 지원하기 어렵다고 한다!
데이터 센터 곳곳에 저장 되어있기 때문에 서버의 수용량보다 훨씬 많은 요청을 보내 서버를 사용 불가능하게 만드는 ddos의 공격으로 특정 데이터 센터가 사용이 불가능해지더라도 다른 데이터 센터에서 콘텐츠를 제공받을 수 있다.
두번째 장점으로는 로딩속도가 향상되어 페이지의 사용자가 증가할 수 있다고한다!
마지막으로는 서버 곳곳에서 컨텐츠를 받아오기 때문에 서버 한곳에서 컨텐츠를 받아올 때보다 과부하가 덜걸린다. 한곳에서 모든 요청을 처리한다면 엄청난 비용이 발생하게 되지만 이를 분산함으로서 비용을 상대적으로 줄일 수 있다
Route53
커스텀 도메인을 이용해 요청을 원하는 곳으로 라우팅할 수 있다.
DNS가 무엇인가 -> ip 주소들을 알아보기 편하도록 구성해 놓은 문자열? 정도로 이해했다. 예로 네이버는 어려운 ip주소 대신에 www.naver.com 라는 dns를 사용하여 접속을 편하게 했다.
커스텀 도메인을 이용해 인증서를 발급받고 SSL을 적용할 수 있다.
-> freenom 을 이용하여 minsung.ga라는 dns를 가진 웹페이지를 생성했다
