서비스 업체 장점
- 신속한 인프라 구축
- 유연한 인프라 관리
- 예상치 못한 트래픽 폭주 대응
- 손쉬운 글로벌 서비스
- 강력한 보안과 장애 없는 서비스
- 합리적인 요금제
이젠 클라우드를 통해 클릭 몇 번, 또는 코드 몇 줄로 거대한 서버실에 해당하는 네트워크를 구축할 수 있게 되었습니다.
사용한 만큼 비용을 지불하는 온디맨드(On-Demand)
AWS
클라우드 컴퓨팅 서비스
AWS에는 컴퓨팅, 스토리지, 데이터베이스, 분석, 네트워킹, 모바일, 개발자 도구, 관리 도구, IoT, 보안, 엔터프라이즈 애플리케이션 등
다양한 서비스가 준비되어 있으며, AWS의 다양한 서비스를 조합하여 모든 애플리케이션과 인프라를 구축할 수 있기도 합니다.
일전에는 여러 사업자에게 각각 빌려야 했던 인프라를 일괄로 빌릴 수 있게 됐으며,
필요에 따라 운영체제(OS), 웹 서버, DB 서버 등 필요한 소프트웨어까지 통째로 사용할 수 있는 편리한 서비스
AWS 특징
- 서비스를 조합하기 쉽습니다. AWS에서만 제공하는 서비스로도 필요한 기능을 대부분 구축 가능하며,
AWS와 AWS 외부 시스템을 조합하여 구축하기 쉽습니다. - 앞으로 사용할 양을 미리 생각하지 않고 현재 필요한 만큼만 사용하고 부족해지면 그때마다 추가할 수 있으며,
같은 양을 계속 빌려야 하는 정액제와 차별점이 있습니다. - 네트워크 및 서버가 매우 큰 규모가 아니라면 네트워크나 서버 전문가가 아니더라도 사용 가능합니다.
- 현재를 기준으로 전 세계 31개의 지리적 리전 내에 99개의 가용 영역을 운영하고 있어,
글로벌로 확장 시 확장하고자 하는 지역과 지리적으로 가까운 리전에서 서비스 시작 가능합니다. - 한국어 지원 및 원화 결제 가능하며, 보안 관련하여 법령, 규정, 프라이버시 기준을 준수하고 있는 안전한 서비스입니다.
클라우드 컴퓨팅
서버가 요청에 대한 수용 능력이 한계에 도달한다면?
문제점들
첫째. 주기적인 관리가 필요합니다.
흔히 말하는 서버실에는 종종 고장이 나거나 인터넷과 연결이 되지 않는 컴퓨터가 생기기도 합니다.
이런 상황이 발생한다면 이를 해결하기 위한 인력 및 비용이 투입되어야 했습니다.
그러나 점차 관리해야 하는 컴퓨터 및 다른 전자기기의 수가 많아지는 만큼 투입되어야 하는 인력 및 비용도 증가하기 시작했습니다.
둘째. 공간의 한계가 있습니다.
예전의 방식은 서버실이라는 공간에 컴퓨터를 배치해 두고 필요할 때마다 추가적인 컴퓨터를 추가하는 방식으로
수용 능력을 향상해 왔습니다.
하지만 이런 방식은 공간이 부족하여 컴퓨터를 더는 배치할 수 없는 문제에 직면하게 됩니다.
이런 상황에서 서버의 컴퓨팅 능력을 늘리려는 방법은
컴퓨터의 성능을 높이고 부피를 줄여 좀 더 많은 컴퓨터를 같은 공간에 배치하는 방법이었습니다.
이런 상황에서 추가적인 서버 증설이 어렵게 되자 일부 거대 기업은 데이터 센터라는 거대한 건물을 세우기 시작했습니다.
이때부터 데이터 센터의 유휴 자원을 대여하는 서비스가 등장하기 시작했습니다.
즉 서버의 자원과 공간, 및 네트워크 환경을 제공을 빌려 사용하는 클라우드 컴퓨팅이 시작된 순간입니다.
온프레미스 : 데이터 센터에서는 서버의 자원과 공간, 및 네트워크 환경을 제공
클라우드 서비스가 기존의 온프레미스 형식과 다른 장점
1. 필요할 때마다 컴퓨팅 능력을 유연하게 조절할 수 있습니다.
2. 고정적인 비용이 들어가는 온프레미스와는 달리 사용한 만큼의 요금만 지불하면 됩니다.
3. 컴퓨터의 스냅샷("이미지"라고 부릅니다) 을 이용해 다른 컴퓨터로 즉시 이주(migration)가 가능합니다.
단점
클라우드 서비스 종속 서비스에 영향을 미침
운영환경이 특정 클라우드 사업자(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에 가깝습니다.
EC2(Elastic Compute Cloud) : 돈 내
아마존 웹 서비스에서 제공하는 클라우드 컴퓨팅 서비스입니다.
클라우드 컴퓨팅은 인터넷(클라우드)을 통해 서버, 스토리지, 데이터베이스 등의 컴퓨팅 서비스를 제공하는 서비스입니다.
정리하면 아마존에서 가상의 컴퓨터를 한 대 빌리는 것과 같습니다.
장점
구성하는데 필요한 시간이 짧다
다양한 운영체제에 대한 선택이 가능하다
AWS에서 빌리는 컴퓨터를 인스턴스라 한다
AMI(템플릿)
AWS에서 빌릴 PC는 사용용도에 맞게 운영체제, 런타임 등이 구성된 Setting을 선택할 수 있습니다.
AWS EC2 인스턴스를 생성한다는 것은 AMI를 토대로 운영체제, CPU, RAM 혹은 런타임 등이 구성된 컴퓨터를 빌리는 것입니다.
RDS(Relational Database Service) : 렌트
관계형 데이터베이스 서비스
왜 써?
렌터카 회사에서 차량을 대여하는 것과 비슷
운전자는 차량을 관리하는 일에 대해서 시간을 따로 쏟을 필요 없이 운전만 하면 되기에 매우 편리
유지 보수와 관련된 일들을 RDS에서 전적으로 자동 관리
S3(Simple Storage Service) : MYBOX
클라우드 스토리지란 쉽게 말해서 인터넷 공간에 데이터를 저장하는 저장소입니다.
컴퓨터 부품으로 비유하면 하드디스크의 역할을 하는 서비스입니다
구글의 Google Drive, 네이버의 MYBOX, 마이크로소프트의 Onedrive와 같은 서비스가 좋은 예시
클라우드 스토리지 서비스의 장점으로는 어떤 것이 있을까요??
클라우드 스토리지 서비스는 뛰어난 접근성을 가지고 있습니다.
컴퓨터의 하드디스크에 저장된 파일에 접근하기 위해서는 해당 컴퓨터를 이용해야만 합니다.
그러나 클라우드 스토리지를 이용하면 웹 환경이라면 언제 어디서나 저장된 파일에 접근할 수 있습니다.
또한 컴퓨터뿐만 아니라 웹에 접속이 가능한 다른 전자기기를 활용하여
클라우드 스토리지에 저장된 데이터에 접속할 수 있습니다.
장점
S3 사용 시 얻을 수 있는 이점으로 높은 확장성이 있습니다.
확장성이 높으면 많은 시간과 수고를 들이지 않고 스토리지 규모를 확장/축소할 수 있습니다.
스토리지의 용량을 무한히 확장할 수 있습니다.
그리고 사용한 만큼만 비용을 지불하면 되기 때문에 비용적인 측면에서 매우 효율적입니다.
스토리지의 내구성이 높으면 저장된 파일을 유실할 가능성이 적어집니다. S3는 99.999999999%의 내구성을 보장합니다.
리전이란 AWS에서 클라우드 서비스를 제공하기 위해서 운영하는 물리적인 서버의 위치를 뜻합
S3 사용자들이 대표적으로 많이 선택하는 스토리지 클래스는 두 가지가 있습니다. Standard 클래스와 Glacier 클래스
Standard 클래스는 범용적인 목적으로 사용하기 좋습니다. 데이터에 빠른 속도로 접근할 수 있고, 데이터 액세스 요청에 대한 처리 속도가 빠릅니다. 대신 데이터를 오래 보관하는 목적으로는 효율적인 선택지가 아닙니다. 보관 비용이 높게 발생하기 때문입니다.
장기적인 보관 목적으로 스토리지를 사용하실 때는 Glacier를 사용하는 것이 효율적입니다.
비록 저장된 데이터에 액세스하는 속도는 느리지만, 데이터를 보관하는 비용이 매우 저렴하다는 장점이 있습니다.
이 외에도 Standard-IA, One Zone-IA, S3 Glacier Deep Archive 등등 여러 가지 스토리지 클래스가 존재하여
사용자의 이용 목적에 따라 다양한 스토리지 클래스를 사용할 수 있습니다.
S3 사용 시 얻는 이점 중 하나로, 정적 웹 사이트 호스팅이 가능합니다.
정적 웹 사이트 호스팅이란 뭘까요? 차근차근 알아보도록 하겠습니다.
먼저 정적 웹 사이트 호스팅이 무엇인지 알기 위해 '정적' 파일에 대한 이해가 선행되어야 합니다.
정적 파일은 서버의 개입 없이 생성된 파일을 뜻합니다.
반대로 클라이언트가 서버에 요청을 보내면, 서버가 요청에 맞추어 그 자리에서 생성한 파일을 '동적' 파일이라고 부릅니다.
그럼 웹 호스팅(Web Hosting)이란 뭘까요?
웹 호스팅이란 서버의 한 공간을 임대해 주는 서비스를 뜻합니다.
구글에 '웹 호스팅'이란 단어를 검색하시면 여러 웹 호스팅 업체의 목록이 뜨시는 것을 확인하실 수 있습니다.
웹 호스팅 업체들을 통해 개인 또는 단체가 웹 호스팅 업체가 제공하는 서버의 한 공간을 빌려서 원하는 서비스를 배포할 수 있습니다.
S3에서는 버킷이 사용자들이 정적 웹 사이트를 배포할 수 있는 공간을 제공합니다.
버킷이라는 저장 공간에 정적 파일을 업로드하고 버킷을 정적 웹 사이트 호스팅 용도로 구성하면 정적 웹 사이트를 배포할 수 있습니다.
여기서 또 생소한 '버킷'이라는 개념이 나왔습니다.
버킷이란 S3에 저장되는 파일들이 담기는 바구니입니다.
파일을 저장하는 최상위 디렉터리라고도 설명할 수 있습니다.
S3에서 저장되는 모든 파일은 버킷 안에 저장되어야 하고, 버킷에는 무한한 양의 파일을 저장할 수 있습니다.
그리고 각각의 버킷은 이름을 가지고 있는데,
버킷의 이름은 버킷이 속해 있는 리전(버킷이 생성된 지역)에서 유일해야 합니다.
또한 버킷 정책을 생성하여 해당 버킷에 대한 다른 유저의 접근 권한을 수정할 수 있습니다.
S3에서 버킷에 담기는 파일을 객체라고 부릅니다.
왜 객체라고 부를까요?? S3에서 저장소에 데이터를 저장할 때 키-값 페어 형식으로 데이터를 저장하기 때문입니다.
S3에 저장되는 객체는 파일과 메타데이터로 구성됩니다.
파일에 대해서 먼저 알아보겠습니다. 파일은 위에 설명한 대로 키-값 페어 형식으로 데이터를 저장합니다.
파일의 값에는 실제 데이터를 저장합니다.
S3 객체의 값으로써 저장될 수 있는 데이터의 최대 크기는 5TB입니다.
파일의 키는 각각의 객체를 고유하게 만들어주는 식별자 역할을 합니다.
파일의 키를 이용하여 원하는 객체를 검색할 수 있습니다.
메타데이터는 객체의 생성일, 크기, 유형과 같은 객체에 대한 정보가 담긴 데이터입니다.
객체를 설명하는 데이터라고 이해하시면 좋습니다.
모든 객체는 고유한 URL 주소를 가지고 있습니다.
URL 주소는 http://[버킷의 이름].S3.amazonaws.com/[객체의 키]의 형태를 띠고, URL 주소를 통해서도 원하는 데이터에 접근할 수 있습니다.
배포 전략
AWS에서 제공하는 서비스인 S3라는 서비스를 통해 사용자들에게 Client를 제공할 수 있습니다.
클라이언트를 위해서 EC2 인스턴스를 사용해야 할까요?
그렇지 않습니다.
클라이언트 앱을 정적 파일로 빌드하여 제공합니다.
따라서 S3를 이용해서 클라이언트를 배포합니다.
빌드
빌드란 쉽게 말해서 불필요한 데이터를 없애고,
여러 갈래로 퍼져있는 데이터들을 통합/ 압축하여 배포하기에 최적화된 상태를 만드는 것입니다.
빌드 과정을 진행하기 전과 비교했을 때 데이터의 용량이 줄어들고,
웹 사이트의 로딩 속도가 빨라진다는 장점이 생깁니다.
하지만 일반적인 의미의 빌드는, 소스코드를 실행 가능한 번들로 변환하는 컴파일 과정을 의미합니다.
웹 앱에서와같이 HTML, CSS, JS의 형태로 배포하는 경우는 조금 다릅니다.
웹 앱은 배포 가능한 정적 파일(static files)의 형태로 만들어 줘야 합니다.
asset 자체가 정적인 경우, 있는 그대로 배포하면 됩니다.
React의 경우 npm run build와 같은 명령을 사용해서, 정적 파일 형태의 결과물을 만들어 낸 후 배포하면 됩니다.
사용하고 있는 환경에 따라 빌드 과정은 다를 수 있습니다.
지구 반대편 사람들한테는?
AWS에서 제공하는 CDN 서비스인 CloudFront를 통해서
각지의 데이터 센터에 데이터를 분산시켜서 저장해 뒀다가 가까운 지역에서 데이터를 주는 방식으로
사용자에게 더 빠르게 서비스를 제공할 수 있습니다.
사용자들이 제공받은 Client Application을 통해서 요청을 전달할 Server Application은 어떻게 배포해야 할까요?
AWS EC2 서비스를 통해 손쉽게 서버를 구성하고 서비스를 제공할 수 있습니다.
AWS에서는 Database 특화 서비스인 RDS 서비스를 제공하고 있습니다.
AWS가 유지 보수 작업을 담당하는 RDS를 이용하여 즉시 데이터베이스를 사용할 수 있습니다.
RDS 서비스를 이용하여 EC2를 통해 배포된 Server Application의 데이터를 저장, 제공하는 데이터베이스를 배포할 수 있습니다.
여러분이 지금까지 이용했던 서비스는 www.google.com과 같은 도메인 주소를 이용해서 접근할 수 있었습니다.
google 사이트에 접속하기 위해서 172.217.161.228이라는 IP 주소를 입력하지는 않았을 것입니다.
처음 배포된 여러분의 서비스는 도메인 주소를 통해 접근할 수 있을까요?
S3, EC2를 이용해서 배포된 서비스는 IP 주소 혹은 AWS에서 제공하는 여러분의 서비스와는 전혀 상관없는
긴 도메인 주소를 통해 접근하게 됩니다.
TodoList 서비스를 제공한다고 생각해 봅시다. www.todolist.ap-northeast-2.compute.amazonaws.com 주소보다는 www.todolist.com 주소 일 때, 직관적으로 서비스를 이해할 수 있고 짧은 주소를 통해 서비스에 접근할 수 있습니다.
AWS에서 제공하는 Route 53 서비스를 이용하면 직관적인 도메인 주소를 통해서 서비스에 접근하도록 할 수 있습니다
Deploy
development → integration → staging → production
Development 단계는 각자의 컴퓨터에서 코드를 작성하고 테스트하는 과정입니다.
개발 단계이기 때문에 실제 데이터를 이용하지 않고 더미 데이터를 이용해서 테스트합니다.
Integration 단계는 각자의 컴퓨터에서 작성한 코드를 합치는 과정입니다.
내가 작성한 코드가 다른 코드를 침범해서 오류를 일으키지 않는지, 코드 간에 conflict가 있지는 않은지 확인하는 과정을 거칩니다.
Staging 단계에서는 실제 출시 단계인 Production 단계와 가장 유사한 환경에서 테스트를 진행합니다.
실제 데이터를 복사해서 문제가 있지 않은지 등 다양한 환경에서 테스트를 진행합니다.
또한 서비스와 관련된 부서 혹은 인원의 확인 과정을 거칩니다.
예를 들면 작성된 코드가 마케팅팀 혹은 디자인팀이 예상했던 결과인지 확인을 거치는 과정입니다.
Production 단계는 개발된 서비스를 출시하는 단계입니다.
사용자가 접속할 수 있는 Production 환경에서 코드를 구동하고 서비스를 제공합니다.
실제 데이터를 가지고 서비스가 운영되기 때문에 문제가 생기면 안 되는 단계입니다.
Development 환경과 Production 환경은 서로 다를 수가 있습니다.
여러분이 개발부터 배포까지 모든 것을 통제할 수 있는 상황이라면,
크게 걱정 없이 Production 환경을 구성할 수 있을 겁니다.
그러나, 여러 명이 함께 작업하는 프로젝트라면 어떨까요?
node 버전도 제각각일 거고, 인증 정보나 데이터베이스 등에 접근하기 위해 사용하는 엔드포인트도 제각각일 겁니다.
예를 들어봅시다. 내 로컬에 설치된 데이터베이스 비밀번호는 rlazheld1234! 인 데,
클라우드에 설치된 데이터베이스 비밀번호는 supersecret! 일 수 있을 거예요.
이 모든 케이스를 코드 안에 담을 수 있을까요?
아니죠. 이처럼 Development 환경과 Production 환경은 서로 다를 수가 있습니다.
마치, 우리나라에서 잘 자라는 식물을 사막 한가운데에서 똑같은 방식으로 재배한다고 잘 자라지 않는 것과 비슷해요.
따라서 배포에서는, 환경의 차이를 이해하고 환경 설정을 코드와 분리하는 것이 중요합니다.
작성한 코드가 다른 환경에서 정상 작동할 수 있게 하려면, 설정을 환경 변수(envvars나 env라고도 불림)에 저장해야 합니다.
환경 변수는 코드 변경 없이 배포 때마다 쉽게 변경할 수 있습니다.
설정 파일과 달리, 잘못해서 코드 저장소에 올라갈 가능성도 낮습니다.
애플리케이션의 모든 설정이 정상적으로 코드 바깥으로 분리되어 있는지 확인할 수 있는 간단한 방법은
어떠한 인증정보도 유출시키지 않고 코드가 지금 당장 오픈 소스가 될 수 있는지 확인하는 것입니다.
슬라이드에 나온 내용은 이러한 환경 설정을 코드로부터 분리하는 방법론을 이야기하고 있습니다.
코드 상의 모든 곳에 절대 경로가 아닌 상대 경로를 사용해야 하며, `.env` 등을 이용해 환경 변수를 설정하세요.
그 외에도 docker와 같은 가상화 도구는 환경 자체를 메타데이터로 담아서 아예 모든 개발 환경을 통일시킵니다.