2023.07.24 코드스테이츠 73회차. ( AWS )
Cloud ComPuting
기존 방식 ( 클라우드 등장 이전 ) 은 전산실 등에 컴퓨터를 배치하고 인터넷을 연결하여 서비스를 제공하였다.
- 같은 공간에 더 많은 컴퓨터를 추가하여 한대가 해결 할 수 있는 요청을 여러대가 나누는 방식이나 컴퓨터 한대의 성능을 높이는 방식으로 사용 하였다.
기존 방식의 한계로는 주기적인 유지관리가 필요하다는 것과 공간의 한계가 있다는 점이다.
이러한 방식을 탈피하는 방법으로 클라우드가 등장하였다.
- 서버의 자원과 공간, 네트워크 환경을 제공하고 필요할 때마다 컴퓨팅 능력을 유연하게 조절한다.
- 사용한 만큼만 요금을 지급하고, 다른 컴퓨터로 즉시 이주(Migration)가 가능하다.
클라우드의 단점은
- 클라우드 서비스에 종속 되기 때문에 클라우드 서비스에 문제가 생기면 내가 배포하고 관리하는 환경에도 영향을 끼친다.
- 클라우드는 모드 것을 서비스화 하는 것을 목표로 한다
- 대표적인 클라우드 서비스의 형태는 SaaS, IaaS, PaaS 이다
SaaS는 Software as a Service의 약자입니다.
클라우드 제공자가 당장 사용 가능한 소프트웨어를 제공하는 경우 대부분 SaaS에 해당합니다.
PaaS는 Platform as a Service의 약자입니다.
클라우드 제공자가 데이터베이스, 개발 플랫폼까지 제공하는 경우 대부분 PaaS에 해당합니다.
IaaS는 Infrastructure as a Service의 약자입니다.
클라우드 제공자가 가상 컴퓨터까지 제공하는 경우 대부분 IaaS에 해당합니다.
- 클라우드 제공자로부터 얼마만큼의 서비스를 제공 받느냐에 따라서 이러한 서비스의 형태가 구분된다.
AWS는 IaaS에 가깝다.
Deploy
- 로컬 환경에서 작성한 코드가 그저 로컬환경에서만 구동된다면 다른 사람들이 서비스를 이용할 수 없다.
- 배포는 개발한 서비스를 사용자들이 이용 가능하게 하는 일련의 과정이다
Development 단계는 각자의 컴퓨터에서 코드를 작성하고 테스트하는 과정입니다.
개발 단계이기 때문에 실제 데이터를 이용하지 않고 더미 데이터를 이용해서 테스트합니다.
Integration 단계는 각자의 컴퓨터에서 작성한 코드를 합치는 과정입니다.
내가 작성한 코드가 다른 코드를 침범해서 오류를 일으키지 않는지, 코드 간에 conflict가 있지는 않은지 확인하는 과정을 거칩니다.
Staging 단계에서는 실제 출시 단계인 Production 단계와 가장 유사한 환경에서 테스트를 진행합니다.
실제 데이터를 복사해서 문제가 있지 않은지 등 다양한 환경에서 테스트를 진행합니다. 또한 서비스와 관련된 부서 혹은 인원의 확인 과정을 거칩니다. 예를 들면 작성된 코드가 마케팅팀 혹은 디자인팀이 예상했던 결과인지 확인을 거치는 과정입니다.
Development 환경과 Production 환경은 서로 다를 수가 있습니다.
배포에서는 환경의 사이클을 이해하고 환경 설정을 코드와 분리하는 것이 중요하다!
작성한 코드가 다른 환경에서 정상 작동할 수 있게 하려면?
- 절대경로 대신 상대경로를 사용한다
- 환경에 따라 포트를 분기할 수 있도록 환경변수를 설정해 준다
- (Advanced) Docker와 같은 개발 환경 자체를 통일시키는 솔루션을 사용한다
작성한 코드가 다른 환경에서 정상 작동할 수 있게 하려면, 설정을 환경 변수(environment variable; envvars나 env라고도 불림)에 저장해야 한다
환경 변수는 코드 변경 없이 배포 때마다 쉽게 변경할 수 있습니다.
설정 파일과 달리, 잘못해서 코드 저장소에 올라갈 가능성도 낮습니다.
애플리케이션의 모든 설정이 정상적으로 코드 바깥으로 분리되어 있는지 확인할 수 있는 간단한 방법은 어떠한 인증정보도 유출시키지 않고 코드가 지금 당장 오픈 소스가 될 수 있는지 확인하는 것입니다. 슬라이드에 나온 내용은 이러한 환경 설정을 코드로부터 분리하는 방법론을 이야기하고 있습니다. 코드 상의 모든 곳에 절대 경로가 아닌 상대 경로를 사용해야 하며, `.properties` 등을 이용해 환경 변수를 설정해야 한다
EC2
EC2는 아마존 웹 서비스에서 제공하는 클라우드 컴퓨팅 서비스이다.
클라우드 컴퓨팅은 인터넷 ( 클라우드 ) 를 통해 서버, 스토리지, 데이터베이스 등의 컴퓨팅 서비스를 제공하는 서비스이다.
EC2 ( Elastic Compute Cloud )
- 사용한 만큼의 비용을 지불하기 때문에 '탄력적인' 이라는 의미의 Elastic 단어가 붙어있다
- 비용적인 부분뿐만 아니라 필요에 따라 성능, 용량을 자유롭게 조절할 수 있다는 의미도 가지고 있다.
- AWS에서 비용, 선능, 용량 면에서 탄력적인 클라우드 컴퓨터를 제공하는 서비스이다.
EC2 의 장점
- 구성하는 데 필요한 시간이 짧다.
- 다양한 운영체제에 대한 선택이 가능하다
( AMI이라는 다양한 템플릿을 제공하고 있어서 필요에 따라 손쉽게 운영체제를 선택하고 구성할 수 있다 )
- CPU, RAM, 용량까지도 손쉽게 구성할 수 있다
-
EC2는 컴퓨터를 한 대 빌리는 것이므로 컴퓨터로 할 수 있는 모든 일을 할 수 있습니다. 빌린 컴퓨터는 직접 사용하는 컴퓨터와 다르게 아마존이 전 세계에 만들어 놓은 데이터 센터(인프라)에 만들어져 있기 때문에 컴퓨터를 조작하기 위해 네트워크(인터넷)를 통해서 컴퓨터를 제어해야 한다는 차이점이 있을 뿐 일반적인 컴퓨터와 다른 점은 없습니다.
AMI는 소프트웨어 구성이 기재된 템플릿이다
- 이미지 종류로는 단순히 운영체제 ( 윈도우, 우분투, 리녹스 등) 만 깔려있는 템플릿을 선택할 수도 있고, 특정 런타임이 설치되어 있는 템플릿이 제공되는 경우도 있다. ( 우분투+ node.js, 윈도우+JVM 등 )
Instance는 선택한 AMI을 토대로 구성된다
AWS에는 상당히 많은 양의 AMI세팅이 준비되어 있기 때문에 손쉽게 인스턴스의 운영체제를 구성할 수 있다
세팅되어 있는 AMI 이외에도 필요에 따라 직접 AMI을 구성 할 수 있다
AWS EC2 인스턴스를 생성한다는 것은 AMI을 토대로 운영체제, CPU, RAM, 런타임 등이 구성된 컴퓨터를 빌리는 것이다
RDS
EC2 인스턴스에 관계형 데이터 베이스 엔진을 설치해서 데이터를 관리할 때와 RDS를 통해 데이터를 관리할 때의 차이는 개인 소유 차량과 렌터카 회사에서 대여한 차량으로 비유 할 수 있다
EC2 인스턴스에 데이터베이스를 설치하여 데이터를 관리하는 것은 개인 소유 차량을 이용하면서 유지보수, 보혐처리 같은 일들을 온전히 운전자가 부담하는 상황이다
EC2 인스턴스를 사용하면 데이터 베이스와 관련해서 자동으로 관리를 담당하는 부분이 매우 적기 때문에 사용자가 일일이 시간을 투자하여 데이터베이스 엔진의 설치과 버전관리, 데이터 백업을 해야한다
가용성과 내구성이 확보되지 않기 때문에 데이터베이스에 저장된 데이터가 유실되거나 정상적으로 사용하지 못할 확률이 커지며, 후에 필요에 따라 데이터 베이스의 규모를 확장하기 어렵다
RDS를 사용하는 것은 렌터카를 사용하는 것과 비슷하다
RDS를 이용하면 데이터베이스 유지보수와 관련된 일들을 RDS에서 전적으로 자동 관리한다
사용자가 해야 할 일은 초기 설정을 제외하고 데이터베이스에 저장된 데이터를 관리하는 일 밖에 없기에 큰 편의성을 느낄 수 있다
기타 RDS 이용 시 얻을 수 있는 장점으로 다양한 데이터베이스 엔진 선택지를 제공한다는 점을 들 수 있습니다.
회사에서 근무하고 있는 실무자는 회사에 필요한 데이터베이스 엔진을 취사선택하여 이용할 수 있습니다.
그 외 일반 사용자는 데이터베이스 엔진마다 제공하는 기능이 조금씩 다르기에 필요와 목적에 맞게 데이터베이스 엔진을 선택하여 효율성을 높일 수 있습니다.
S3
클라우드 스토리지?
- 인터넷 공간에 데이터를 저장하는 저장소
( 하드디스크 역할 )
( 구글의 드라이버, 네이버의 MyBOX 등 )
클라우드 스토리지의 장점
- 뛰어난 접근성 ( 컴퓨터의 하드디스크에 접근하기 위해서는 해당 컴퓨터를 이용해야 하지만, 클라우드 스토리지를 이용하면 웹 환경이라면 언제 어디서나 저장된 파일에 접근할 수 있다. 또한 컴퓨터 뿐만 아니라 웹에 접속이 가능한 다른 전자기기를 활용하여 저장된 데이터에 접근이 가능하다 )
S3는 Simple Storage Service의 약자로 AWS에서 제공하는 클라우드 스토리지 서비스이다
S3를 사용시 얻을 수 있는 이점으로는 높은 확장성이 있다.
- 확장성이 높으면 많은 시간을 들이지 않고 스토리지 규모를 확장/ 축소 할 수 있다.
- S3에서는 스토리지의 용량을 무한히 확장할 수 있다.
- 사용한 만큼만 비용을 지불하기 때문에 비용적인 측면에서도 효율적이다
S3는 강력한 내구성을 보장한다
- 내구성이 높을수록 데이터를 유실할 확률이 적어진다
S3는 높은 가용성을 보장한다
- 가용성이 높으면 스토리지에 저장된 파일들을 정상적으로 사용할 수 있는 시간이 길어진다
파란색으로 동그라미가 쳐진 지역이 있습니다. 이 지역을 '리전(Region)'이라고 부릅니다. 리전이란 AWS에서 클라우드 서비스를 제공하기 위해서 운영하는 물리적인 서버의 위치를 뜻합니다. (주황색으로 동그라미 쳐진 지역은 곧 개설될 리전을 의미합니다.)
S3는 다양한 스토리지 클래스를 제공한다
- 저장소를 어떤 목적으로 활용할지에 따라 효율적으로 선택할 수 있는 클래스가 달라진다
S3 사용자들이 대표적으로 많이 선택하는 스토리지 클래스는 두 가지가 있습니다.
Standard 클래스와 Glacier 클래스입니다.
장기적인 보관 목적으로 스토리지를 사용하실 때는 Glacier를 사용하는 것이 효율적이다
S3를 이용시 정적 웹 사이트 호스팅이 가능하다
정적파일?
- 서버의 개입 없이 생성된 파일을 의미한다
( 클라이언트가 서버에 요청을 보내면 서버가 요청에 맞추어 그 자리에서 생성한 파일을 동적파일 이라 부른다 )
웹 호스팅?
- 서버의 한 공간을 임대해 주는 서비스
- 웹 호스팅 업체를 통해 개인 또는 단페가 웹 호스팅 업체가 제공하는 서버의 한 공간을 빌려서 원하는 서비스를 배포 할 수 있다
S3에서는 버킷이 사용자들이 정적 웹 사이트를 배포할 수 있는 공간을 제공한다
버킷이라는 저장공간에 정적 파일을 업로드하고 버킷을 정적 웹 사이트 호스팅 용도로 구성하면 정적 웹 사이트를 배포 할 수 있다
버킷은 S3에 저장되는 파일들이 담기는 바구니? 이다
- 파일을 저장하는 최상위 디렉터리.
S3에서 저장되는 모든 파일은 버킷 안에 저장되어야 하고, 버킷에는 무한한 양의 파일을 저장할 수 있다
- 각각의 버킷은 이름을 가지고 있는데 버킷의 이름은 버킷이 속해 있는 리전( 버킷이 생성된 지역 )에서 유일해야 한다
S3에서 버킷에 담기는 파일을 객체라고 한다
- S3에서 저장소에 데이터를 저장 할 때 키-값 페어 형식으로 데이터를 저장하기 때문이다
S3에서 저장되는 객체는 파일과 메타데이터로 구성된다
파일의 값에는 실제 데이터를 저장한다
- S3객체의 값으로써 저장 될 수 있는 데이터의 최대 크기는5TB이다
- 파일의 키는 각각의 객체를 고유하게 만들어주는 식별자 역할을 한다
( 파일의 키를 이용하여 원하는 객체를 검색할 수 있다 )
메타데이터는 객체의 생성일, 크기, 유형과 같은 객체의 대한 정보가 담긴 데이터이다
- 객체를 설명하는 데이터
모든 객체는 고유한 URL주소를 가지고 있다
3 Tier-Architecture 배포 전략
AWS에서 제공하는 서비스인 S3 서비스를 통해 사용자들에게 Client를 제공할 수 있다
클라이언트 앱의 정적 파일 그 자체를 사용하거나 정적파일로 빌드하여 제공한다
( S3를 이용해서 클라이언트를 배포한다 )
S3로 사용자들에게 Client Application을 제공하고 있는데, 사용자가 지구 반대편에 있다면 어떻게 빠르게 서비스를 제공할 수 있을까요?
AWS에서 제공하는 CDN 서비스인 CloudFront를 통해서 각지의 데이터센터에 데이터를 분산시켜서 저장해 뒀다가 가까운 지역에서 데이터를 주는 방식으로 사용자에게 더 빠르게 서비스를 제공할 수 있습니다.
사용자들이 제공받은 Client Application을 통해서 요청을 전달할 Server Application은 어떻게 배포해야 할까요?
AWS EC2 서비스를 통해 손쉽게 서버를 구성하고 서비스를 제공할 수 있습니다.
AWS에서는 Database 특화 서비스인 RDS 서비스를 제공하고 있습니다.
AWS가 유지 보수 작업을 담당하는 RDS를 이용하여 즉시 데이터베이스를 사용할 수 있습니다.
처음 배포된 여러분의 서비스는 도메인주소를 통해 접근할 수 있을까요?
S3, EC2를 이용해서 배포된 서비스는 IP주소 혹은 AWS에서 제공하는 여러분의 서비스와는 전혀 상관없는 긴 도메인주소를 통해 접근하게 됩니다.
AWS에서 제공하는 Route 53 서비스를 이용하면 직관적인 도메인 주소를 통해서 서비스에 접근하도록 할 수 있습니다.
