24일차 AWS

클라우딩 컴퓨터

 

클라우딩                                                                                                              전산실

 

과거에는 흔히 말하는 전산실 등에 컴퓨터를 배치하고 인터넷을 연결하여 서비스를 제공하였으며 서버가 요청에 대한 수용 능력이 한계에 도달하면 컴퓨터 한 대의 성능을 높이거나 컴퓨터를 추가를 하여 해결하였다. 이처럼 전산실에 직접 설치해 운영하는 방식을 온프레미스라 하며 이는 주기적인 관리와 공간의 한계가 있어 이 점들을 보안하기 위해 일부 거대 기업들은 데이터 센터를 세우기 시작했고 유후 자원을 대여하는 서비스를 시작했다.

 

 

즉, 서버의 자원과 공간, 및 네트워크 환경을 제공을 빌려 사용하는 클라우드 컴퓨팅이 시작된 순간이다.

 

데이터 센터에서는 서버의 자원과 공간, 및 네트워크 환경을 제공하며 온프레미스라고 부른다. 현대의 클라우드 컴퓨팅은 앞서 설명한 데이터 센터와 비슷한 역할을 하지만, 물리적인 컴퓨터가 아닌, 가상 컴퓨터를 대여한다는 점이 다르다. 가상화(Virtualization) 기술의 발전으로부터 비롯되었으며 최근의 가상화 기술을 사용하는 클라우드 서비스는 기존의 온프레미스 형식과는 달리 다음과 같은 장점이 있습니다.

• 1. 필요할 때마다 컴퓨팅 능력을 유연하게 조절할 수 있다.
• 2. 고정적인 비용이 들어가는 온프레미스와는 달리 사용한 만큼의 요금만 지불하면 된다.
• 3. 컴퓨터의 스냅샷("이미지"라고 부릅니다)을 이용해 다른 컴퓨터로 즉시 이주(migration)가 가능하다.

 

장점만 있을거 같은 클라우딩 서비스에서 단점은 존재한다.

운영 환경 자체가 클라우드 제공자에게 종속되어 버리므로, 클라우드 서비스에 문제가 생기면 내가 배포하고 관리하는 환경에도 영향이 미친다. 운영환경이 특정 클라우드 사업자(vendor)에게 종속된다는 얘기는, 백엔드 구성 자체가 특정 회사의 기술로만 구성해야만 하는 경우가 발생할 수도 있다.

 

 

따라서 AWS와 같은 대표적인 클라우드 사업자가 제공하는 기술을 익히는 것도 중요하지만, 그만큼 이 인프라 자체에 대한 이해가 더욱 중요하다.

 

클라우드 서비스의 종류

 

SaaS

• Software as a Service의 약자입니다.
• 클라우드 제공자가 당장 사용 가능한 소프트웨어를 제공하는 경우 대부분 SaaS에 해당합니다.

PaaS

• Platform as a Service의 약자입니다.
• 클라우드 제공자가 데이터베이스, 개발 플랫폼까지 제공하는 경우 대부분 PaaS에 해당합니다.

IaaS

• Infrastructure as a Service의 약자입니다.
• 클라우드 제공자가 가상 컴퓨터까지 제공하는 경우 대부분 IaaS에 해당합니다.

 

피자 먹고싶다..

 

Cloud Computing - AWS

 

클라우드 컴퓨팅의 세가지 모델

 

Software as a Service(SaaS)

SaaS는 서비스 공급자에 의해 실행되고 관리되는 완전한 제품을 제공하며 대부분의 경우 SaaS라고 하면 웹 기반 이메일과 같은 최종 사용자 애플리케이션을 말한다. SaaS 오퍼링의 경우 서비스를 유지 관리하는 방법이나 기본 인프라를 관리하는 방법에 대해 생각할 필요가 없으며 특정 소프트웨어를 어떻게 사용할지만 생각하면 된다.

 

예시 : 웹 메일, 구글 클라우드, 네이버 클라우드, MS오피스365, 드롭박스 등

 

Platform as a Service(PaaS)

PaaS를 사용하면 기본 인프라(일반적으로 하드웨어와 운영 체제)를 관리할 필요가 없어 애플리케이션 개발과 관리에 집중할 수 있으며 

즉, 애플리케이션 실행과 관련된 리소스 구매, 용량 계획, 소프트웨어 유지 관리, 패치 작업 또는 다른 모든 획일적인 작업에 대한 부담 없이 더욱 효율적으로 운영할 수 있다.

 

제공 업체 : Heroku, Google App Engine, IBM Bluemix, OpenShift, SalesForce 등

 

Infrastructure as a Service(IaaS)

IaaS에는 클라우드 IT를 위한 기본 빌딩 블록이 포함되어 있으며, 일반적으로 네트워킹 기능, 컴퓨터(가상 또는 전용 하드웨어) 및 데이터 스토리지 공간에 대한 액세스를 제공한다. IaaS는 IT 리소스에 대한 최고 수준의 유연성과 관리 제어 기능을 제공하며 이는 많은 IT 부서 및 개발자에게 익숙한 기존 IT 리소스와 가장 유사하다.

 

예시 : AWS의 EC2 등

 

 

 

클라우드 컴퓨팅 세가지 배포 모델

 

올 인 클라우드(All in Cloud)

AWS 같은 클라우드 서비스 제공자를 통해 애플리케이션을 배포하는 방식을 퍼블릭 클라우드(Public Cloud) 혹은 올 인 클라우드(All in Cloud)라고 부른다. 퍼블릭 클라우드의 이용 방식은 크게 두 가지가 있다. 하나는 클라우드에서 새 애플리케이션을 개발 및 제공하는 방법과 다른 하나는 기존의 애플리케이션을 클라우드로 이전하는 방법이 있다.

 

클라우드 기반 애플리케이션은 낮은 수준의 인프라상에 구축할 수 있고 또는 주요 인프라를 관리, 설계 및 확장할 필요가 없는 높은 수준의 서비스를 사용할 수 있다.

 

대표적인 사례로는 넷플릭스가 있으며, 모든 데이터 센터와 스트리밍 콘텐츠 서비스를 AWS에서 제공합니다.

하이브리드 클라우드(Hybrid Cloud)

애플리케이션 중 일부는 퍼블릭 클라우드에서 나머지는 온프레미스 환경에서 제공하는 방식이다. 이 두 가지 환경을 긴밀하게 연결하면, 기존 데이터 센터의 확장 개념에서 퍼블릭 클라우드를 이용할 수 있고, 클라우드 전환 또한 쉽게 진행할 수 있다.

 

현대 대부분의 기업들은 이미 방대한 인프라와 데이터를 온프레미스 데이터 센터에 축적해두었기 때문에 일시에 클라우드로 이전하기는 어렵고, 이 경우 하이브리드 클라우드를 사용한다.

온프레미스와 프라이빗 클라우드(On premise, Private Cloud)

온프레미스는 물리적 서버라고도 하며, 회사나 개인이 자체적으로 보유하며 운영하는 서버를 말한다. 온프레미스 서버를 운영하기 위해서는 유지보수, 관리 인력, 공간 등의 추가적인 비용들이 발생하며 직접 설치하는 과정에서 공간과 시간의 비효율이 발생하기도 한다. 그래서 경우에 따라 온프레미스를 클라우드로 옮기기도 하며 이를 마이그레이션(Migration)이라고 부릅니다.

 

비슷하게 외부 클라우드 사업자의 서비스를 이용하지 않고 서비스를 위한 인프라를 직접 구축하는 방법으로는 프라이빗 클라우드도 있다.

이 둘의 가장 큰 차이점은 클라우드의 핵심 능력인, 신속함과 확장성을 가지고 있는지의 여부이다.

 

프라이빗 클라우드는 서비스에 사용자가 몰리면, 해당 서비스를 위한 인프라를 유연하게 사용하여 안정화시킬 수 있다는 장점이 있습니다.

 

 

 

클라우드 글로벌 인프라

 

AWS 리전

AWS는 245개 국가에서 리전(Region), 가용 영역(Availability Zone), 상호접속 위치(Points of Presence) 등으로 구성된 글로벌 클라우드 인프라를 제공하며, 지속적으로 확장하고 있다. 더불어 안정적인 글로벌 서비스를 위해 25개 리전과 5개 대륙에 각각 하나의 로컬 리전을 두고 있다.

 

 

리전(Region)

AWS 클라우드 서비스용 데이터 센터 클러스터가 위치한 물리적인 장소를 의미한다. 다시 말해, AWS의 서비스를 제공하는 지리적 위치를 나타내며 리전에 속한 데이터는 AWS 고객의 명시적인 동의 없이 리전 외부로 이동할 수 없다.

가용 영역(Availability Zone)

각 리전에는 AZ라고 부르는 가용 영역(Availability Zone)이 존재하며 하나의 AZ에는 1~6개의 데이터 센터로 구성되며, 전력 공급망과 네트워크망이 중첩적으로 구현된다.

 

현재 총 81개의 AZ가 존재하며, 해당 지역의 자연재해 등에 영향받지 않도록 분산 설계가 되어있어 하나의 AZ가 셧다운 되더라도 인접한 다른 AZ에 동일한 피해가 가지 않도록 한다. 동일 리전 내 AZ는 저비용성, 고응답성, 고보안성의 조건을 충족하는 광케이블 네트워크로 연결하기 때문에 AZ 간 응답성은 매운 높은 수준이며, 이러한 특징은 특정 AZ가 자연재해 등으로 작동이 멈춘 경우에도 자동으로 다른 AZ가 가동되는 아키텍처를 구성할 수 있게 한다.

 

리전 기사 및 aws 예시

 

AWS 보안과 준수해야 할 원칙

 

AWS 서비스 로드맵

 

서비스 명	AWS 분류 기준	학습 콘텐츠	연관 챕터
EC2	컴퓨팅	AWS	핵심 서비스
Lambda	컴퓨팅,서버리스	마이크로서비스
RDS	데이터베이스	AWS	핵심 서비스
DynamoDB	데이터베이스,서버리스	AWS	핵심 서비스
ElastiCache	데이터베이스	AWS	그밖의 서비스
Redshift	데이터베이스	AWS	그밖의 서비스
DocumentDB (MongoDB 호환)	데이터베이스	AWS	그밖의 서비스
S3	스토리지,서버리스	AWS	핵심 서비스
EBS	스토리지	AWS	EC2 인스턴스
EFS	스토리지	AWS	EC2 인스턴스
ECS	컨테이너	Docker
EKS	컨테이너	Docker
Fargate	컨테이너,서버리스	Docker
ECR	컨테이너	Docker
CodeBuild	개발자 도구	배포 자동화
CodeDeploy	개발자 도구	배포 자동화
CodePipeline	개발자 도구	배포 자동화
CloudWatch	관리 및 거버넌스	서비스 모니터링
CloudFormation	관리 및 거버넌스	Infrastructure as Code
VPC	네트워크 및 콘텐츠 전송	AWS	핵심 서비스
CloudFront	네트워크 및 콘텐츠 전송	AWS	서비스 노출
Route 53	네트워크 및 콘텐츠 전송	AWS	서비스 노출
Elastic Load Balancing	네트워크 및 콘텐츠 전송	AWS	핵심 서비스
IAM	보안 자격 증명 및 규정 준수	AWS	핵심 서비스
Secrets Manager	보안 자격 증명 및 규정 준수	지속적 통합
Certificate Manager	보안 자격 증명 및 규정 준수	AWS	보안
API Gateway	서버리스,네트워크 및 콘텐츠 전송	마이크로서비스
SNS	서버리스	AWS	그밖의 서비스
SQS	서버리스	AWS	그밖의 서비스

 

 

컴퓨트(Compute)

컴퓨트 서비스에는 클라우드에서 확장성 높은 컴퓨팅 파워를 제공하기 위한 다양한 제품과 서비스가 포함되어 있다. 컴퓨트 서비스에는 서버 기반 및 서버리스 기반의 환경 설정 기능이 제공되며, 리소스 확장의 자동화 도구와 애플리케이션의 신속한 배포를 돕는 도구 등이 포함되어 있다. 

 

Ex) Elactic Compute Cloud(EC2), EC2 Auto Scaling, Lambda, EC2 Container, Elastic Kubernetes, Fargate, Elastic   , Beanstalk

 

네트워킹(Networking)

네트워킹은 AWS의 핵심 서비스 중 하나로 기업의 클라우드 인프라를 다른 요소와 격리/연결시킬 수 있는 방법을 제공한다. AWS는 네트워킹에 대한 다양한 옵션을 제공하며, 이를 통해 애플리케이션 아키텍처를 최적화할 수 있다. 

 

Ex) Virtual Private Cloud, Route 53, Elastic Load Balancing, Direct Connect, App Mesh, Global Accelerator

 

보안 및 준수 규정

클라우드 보안은 AWS의 최우선 순위 요소이다. 고객의 데이터와 인프라를 보호하기 위한 다양한 보안 레이어가 제공되고, 인프라와 관련된 다수의 준수 규정 프로그램 또한 제공된다. 

 

Ex) Identity and Access Management(IAM) ,Inspector, Certificate Manager, Directory Service, GuardDuty, Shield, Web Application Firewall, Macie, Secrets Manager, KMS

 

 

스토리지와 콘텐츠 딜리버리

AWS는 방대한 데이터 저장 서비스를 제공하고, 고객은 각자의 비즈니스 니즈에 따라 스토리지 솔루션을 선택할 수 있다. 

 

Ex) Simple Shared Storage(S3), Amazon Glacier, Elastic Block Store (EBS), Elastic File System (EFS), Storage Gateway

, CloudFront

 

데이터베이스

AWS는 관계형(RDBMS) 및 비 관계형(NoSQL) 데이터베이스 서비스와 웨어하우징 서비스, 인메모리 캐싱 서비스를 제공한다.

 

Ex) Relational Database Service(RDS), DynamoDB, Redshift, ElastiCache, Aurora, DocumentDB

 

개발자 도구

AWS는 개발 환경 설정과 같은 부수적인 업무에서 벗어나 좀 더 신속하게 목표하는 코드를 개발 및 배포할 수 있는 다수의 서비스를 제공하며 소프트웨어 개발 생애주기 동안 해야 할 다양한 업무를 연속적으로 처리할 수 있도록, 다양한 개발 언어 및 플랫폼에서 사용할 수 있는 여러 SDK 및 도구를 제공하며 이를 이용해 작성한 코드를 즉시 배포할 수 있다.

 

Ex) CodeCommit, CodePipeline, CodeBuild, CodeDeploy

 

관리 도구

AWS는 시스템 통합 관리, IT 인프라 관리를 위한 다양한 서비스와 개발자가 하이브리드 또는 클라우드 인프라 및 자원을 쉽게 관리하고 모니터링할 수 있는 서비스를 제공하며 AWS 및 온프레미스 자원을 자동화된 프로비전, 운영, 환경 설정, 관리할 수 있는 다양한 서비스가 있다. 실시간 대시보드로 시스템 로그 및 성능 지표를 모니터링하고 보안 이슈가 발생할 경우 경고 메시지를 내보낸다.

 

Ex) CloudFormation, OpsWorks, CloudWatch, Config, CloudTrail

 

메시징(Messaging)

클라우드로부터의 공고 수신, 애플리케이션에서 메시지 발송, 구독자에 배포, 메시지 큐 관리 등 메시징을 위한 폭 넓은 서비스를 제공한다.

 

Ex) Simple Notification Service (SNS), Simple Email Service (SES), Simple Queue Service (SQS)

 

Amazon EC2(Elastic Compute Cloud)

EC2는 아마존 웹 서비스에서 제공하는 클라우드 컴퓨팅 서비스이다.

클라우딩 컴퓨팅 서비스는 인터넷(클라우드)을 통해 서버, 스토리지, 데이터베이스 등의 컴퓨팅 서비스를 제공하는 서비스이다.

 

즉, 아마존에서 가상의 컴퓨터 한 대를 빌리는 것과 같다.

 

이해하기 쉽게 피시방을 예를 들어 보겠다.

 

고사양의 게임을 하려면 두 가지 방법이 있다. 고사양의 컴퓨터를 사거나 고사양 컴퓨터가 있는 피시방에 가는 것이다. 전자는 1시간을 해도 10시간을 해도 지불해야 하는 금액(컴퓨터, 주변기기 구매 금액)이 일정하다. 그러나 피시방은 내가 사용한 만큼 비용을 지불한다.

 

EC2도 피시방과 비슷한 개념이다. 내가 사용한 만큼 금액을 지불하기 때문에 Elastic이라 하며 이는 탄력적이라는 뜻이다.

비용만 탄력적인 게 아닌 필요에 따라 성능, 용량을 자유롭게 할 수 있다.

 

즉, EC2 서비스는 AWS에서 비용, 성능, 용량 면에서 탄력적인 클라우드 컴퓨터를 제공하는 서비스라고 할 수 있습니다.

 

또한 EC2는 클라우드에서 거의 무한대에 가까운 확장 가능 컴퓨팅 용량을 제공하며 EC2를 사용하면 하드웨어에 투자할 필요 없이 빠르게 애플리케이션을 개발하고 배포할 수 있으며, 원하는 만큼 가상 서버를 구축하고 보안 네트워킹을 구성하며, 스토리지를 관리할 수 있다.

 

EC2는 컴퓨터를 한 대 빌리는 것이므로 컴퓨터로 할 수 있는 모든 일을 할 수 있다. 빌린 컴퓨터는 직접 사용하는 컴퓨터와 다르게 아마존이 전 세계에 만들어 놓은 데이터 센터(인프라)에 만들어져 있기 때문에 컴퓨터를 조작하기 위해 네트워크(인터넷)를 통해서 컴퓨터를 제어해야 한다는 차이점이 있을 뿐 일반적인 컴퓨터와 다른 점은 없다. 아마존 EC2를 통해서 할 수 있는 가장 기본적인 일은 웹서버를 설치하고 웹 서버를 통해서 사용자가 웹 브라우저를 통해 요청하는 서비스를 제공하는 것이며 인스턴스는 1대의 컴퓨터를 의미하는 단위이고 AWS에서 컴퓨터를 빌리는 것을 인스턴스를 생성한다고 합니다.

 

AMI(Amazon Machine Image)

 

AMI는 소프트웨어 구성이 기재된 템플릿입니다. 이미지 종류로는 단순히 운영체제(윈도우, 우분투 리눅스 등)만 깔려있는 템플릿을 선택할 수도 있고, 아예 특정 런타임이 설치되어 있는 템플릿이 제공되는 경우도 있다. (우분투 + node.js, 윈도우 + JVM 등)

클라우드에서 실행되는 서버에 대한 모든 소프트웨어 환경 설정 정보를 포함한 기본 설계도 또는 청사진과 같으며 AMI에는 운영체제, 애플리케이션 서버 그리고 그 위에서 실행되는 애플리케이션 등에 대한 세부 내용을 모두 담고 있다. AMI로 서버 또는 인스턴스를 론칭하면 모든 요소가 상속되어 만들어진다. 사용자는 AMI를 통해 자신이 원하는 수만큼 인스턴스를 생성할 수 있다.

EC2의 장점

 

1. 구성 시간이 짧다.

 

만약 pc를 구매하면 배송받기까지의 시간이 걸리지만 EC2는 클릭 몇 번으로 PC를 구성할 수 있다.

 

2. AMI를 통해서 필요한 용도에 따라 다양한 운영체제에 대한 선택이 가능하다

 

EC2에서는 AMI라는 다양한 템플릿을 제공하고 있어서 필요에 따라 손쉽게 운영체제를 선택하고 구성할 수 있다. 또한 운영체제뿐만이 아니라 CPU와 RAM, 용량까지도 손쉽게 구성할 수 있다.

 

 

 

AWS EC2 인스턴스를 생성한다는 것은 AMI를 토대로 운영체제, CPU, RAM 혹은 런타임 등이 구성된 컴퓨터를 빌리는 것이다.

 

 

인스턴스(Instances)

 

가상 컴퓨팅 환경으로, 하나의 가상 컴퓨터(서버)이다.

 

인스턴스에서 실행하려는 애플리케이션 또는 소프트웨어에 필요한 메모리 양과 컴퓨팅 파워를 기준으로 인스턴스 유형을 선택한다.

 

인스턴스 유형

인스턴스를 시작할 때 지정하는 인스턴스 유형에 따라 인스턴스에 사용되는 호스트 컴퓨터의 하드웨어가 결정되며 각 인스턴스 유형은 서로 다른 컴퓨팅, 메모리, 스토리지 용량을 제공하며, 이 용량에 따라 한 인스턴스 패밀리로 분류된다.

 

레퍼런스     분석 블로그

 

 

 

 

 

인스턴스의 라이프 사이클

 

 

인스턴스	상태설명	인스턴스 사용 요금
pending	인스턴스는 running 상태로 될 준비를 하고 있습니다. 인스턴스를 처음 시작하거나 pending 상태의 인스턴스를 다시 시작하면 stopped 상태가 됩니다.	미청구
running	인스턴스를 실행하고 사용할 준비가 되었습니다.	청구
terminated	인스턴스가 영구적으로 삭제되었으며 시작할 수 없습니다.	미청구
shutting-down	인스턴스가 종료할 준비를 하고 있습니다.	미청구
stopped	인스턴스가 종료되고 사용이 불가합니다. 언제든지 인스턴스를 다시 시작할 수 있습니다.	미청구
stopping	인스턴스가 중지 또는 중지-최대 절전 모드로 전환할 준비를 하고 있습니다.	중지 준비중인 경우 미청구, 최대 절전모드로 전환 준비 중인 경우 청구

 

인스턴스 구입 옵션

 

On-Demand

온디맨드 인스턴스를 사용하면 장기 약정 없이 초 단위로 컴퓨팅 용량을 구입할 수 있다. 온디맨드 인스턴스를 구매할 때 장기 약정은 필요 없으며 온디맨드 인스턴스가 running 상태인 시간(초)에 대해서만 지불하면 된다. 실행 중인 온디맨드 인스턴스에 대한 초당 요금은 고정 요금이며 중단할 수 없는 불규칙한 단기 워크로드가 있는 애플리케이션의 경우 온디맨드 인스턴스를 사용하는 것이 좋습니다.

 

Reserved

예약 인스턴스는 온디맨드 인스턴스 요금과 비교하여 EC2 비용을 대폭(최대 75%) 절감하는 효과를 제공하며 예약 인스턴스는 사용량이 거의 확정된 프로덕션 워크로드용 인스턴스 실행에 적합하다. 기업 애플리케이션에 대한 트래픽이 안정적이거나 성능에 대한 요구 수준이 예측 가능한 경우 예약 인스턴스를 사용하는 것이 좋다. 이때 예약 기간은 1년 또는 3년 약정이 적용되므로 계약 실행 전 워크로드를 파악하는 것이 좋다. 리전 또는 특정 AZ의 인스턴스를 예약할 수도 있다. 또 예약 인스턴스는 모두 선불, 일부 선불, 선결제 없음의 결제 옵션도 제공한다.

 

Spot

스팟 인스턴스는 온디맨드 가격보다 저렴한 비용으로 제공되는 예비 EC2 용량을 사용하는 인스턴스이다. 스팟 인스턴스는 큰 할인율로 미사용 EC2 인스턴스를 요청할 수 있게 해주므로 사용자는 Amazon EC2 비용을 대폭 낮출 수 있으며 스팟 인스턴스는의 시간당 가격을 스팟 가격이라 한다. 각 가용 영역 내 인스턴스 유형별 스팟 가격은 Amazon EC2에서 설정하며, 스팟 인스턴스의 장기적 공급 및 수요에 따라 점진적으로 조정된다. 스팟 인스턴스는 용량이 가용 상태이고 요청에 대한 시간당 최고가가 스팟 가격보다 더 높을 때마다 실행된다. 스팟 인스턴스는 애플리케이션이 실행되는 시간을 유연하게 조정할 수 있고 애플리케이션을 중단할 수 있는 경우에 선택하는 비용 효율적인 방법이다. 예를 들어 스팟 인스턴스는 데이터 분석, 배치 작업, 백그라운드 프로세싱 및 선택적 작업에 적합하다.

 

스팟인스턴스 사용 전략

애플리케이션에 대해 보장된 컴퓨팅 리소스를 최소 수준으로 유지하기 위한 한 가지 전략은 온디맨드 인스턴스의 코어 그룹을 시작하고 기회가 생기면 스팟 인스턴스로 이를 보완하는 것입니다

 

 

 

스토리지 - 인스턴스 루트 볼륨(Instance Root Volume)

인스턴스 루트 디바이스에는 인스턴스 부팅을 위한 이미지가 포함되어 있으며 이 루트 디바이스는 Elastic Block Store 혹은 인스턴스 스토어 볼륨 중 하나이다.

처음 EC2 인스턴스가 론칭되면 모든 루트 디바이스는 S3로부터 론칭에 필요한 정보를 가져온다. 이와 같이 S3를 통해 백업되는 인스턴스 루트 디바이스를 인스턴스 스토어 기반이라고 부릅니다.

 

AWS가 EBS를 제공한 이후 이미지를 EBS 볼륨 기반으로 제공하는데 인스턴스를 론칭할 때마다 루트 디바이스가 EBS 볼륨에서 론칭되고 EBS 스냅샷을 통해 생성되며 이런 인스턴스를 EBS 기반 인스턴스라고 부른다.

인스턴스 스토어 기반 인스턴스(임시 스토리지로 적합)

인스턴스는 하나 이상의 인스턴스 스토어 볼륨을 자동으로 사용할 수 있으며, 이러한 볼륨 중 하나가 루트 디바이스 볼륨 역할을 합니다. 인스턴스가 시작되면 인스턴스를 부팅하는 데 사용된 이미지가 루트 볼륨으로 복사됩니다. 인스턴스 유형에 따라 다른 인스턴스 스토어 볼륨을 사용할 수도 있습니다.

 

인스턴스 스토어 볼륨의 모든 데이터는 인스턴스가 실행되는 동안 유지되지만, 인스턴스가 종료되거나 장애가 발생하면 데이터가 삭제된다.

인스턴스 스토어가 지원하는 인스턴스는 종료되거나 장애가 발생할 경우 복원이 불가능하며 Amazon EC2 인스턴스 스토어가 지원하는 인스턴스를 사용하려는 경우 여러 가용 영역의 인스턴스 스토어로 데이터를 분산하는 것이 좋다.

 

또한 인스턴스 스토어 볼륨의 중요한 데이터를 정기적으로 영구 스토리지로 백업해야 합니다.

EBS 기반 인스턴스(영구 스토리지로 적합)

EBS를 루트 디바이스로 사용하는 인스턴스에는 자동으로 EBS 볼륨이 연결되며 EBS 지원 인스턴스를 시작하면 사용하는 AMI가 참조하는 각 EBS 스냅샷에 대한 EBS 볼륨이 생성된다. 인스턴스 유형에 따라 다른 EBS 볼륨이나 인스턴스 스토어 볼륨을 사용할 수도 있다.

EBS 지원 인스턴스는 중지한 후 다시 시작해도 연결된 볼륨에 저장된 데이터에 아무런 영향이 없다. EBS 지원 인스턴스가 중지 상태일 때 다양한 인스턴스 및 볼륨 관련 태스크를 수행할 수 있다.

 

보안

 

키 페어

EC2는 퍼블릭-프라이빗 키 방식을 사용하며, 이는 로그인 정보의 암호화-복호화 모델을 따른 것이다. 암호화 기법 측면에서 퍼블릭 키는 데이터 암호화에, 프라이빗 키는 데이터 복호화에 사용된다. 사용자는 EC2 인스턴스 연결을 위해 프라이빗 키를 사용해야 한다. 블릭 키와 프라이빗 키 조합인 키 페어를 생성하는 방법에는 AWS 콘솔, CLI, API 호출 방식으로 생성할 수 있으며, AWS 고객은 자신의 키를 가져와서 시스템에 업로드해놓고 사용할 수도 있다.

 

EC2는 SSH-2 RSA 키를 사용하며, 리전당 최대 5,000개의 키 페어를 사용할 수 있습니다.

 

보안 그룹(Security Group)

하나 혹은 다수의 인스턴스에 대한 트래픽을 통제하는 가상의 방화벽이다. 인스턴스를 론칭한 뒤 해당 인스턴스에 하나 혹은 다수의 보안 그룹을 연결할 수 있고, 이를 통해 해당 인스턴스로 유입되거나 해당 인스턴스에서 유출되는 트래픽에 대한 처리 규칙을 설정할 수 있다. 보안 그룹의 내용은 언제든 수정할 수 있으며, 새로운 규칙이 추가되면 해당 보안 그룹에 포함된 모든 인스턴스에 자동으로 적용된다. 각 인스턴스에 특정 트래픽이 도달할지 여부는 해당 인스턴스에 연결된 모든 보안 그룹 규칙에 따라 정해진다.

 

보안 그룹의 규칙이 지닌 특징은 다음과 같습니다.

• 기본적으로 보안 그룹은 모든 아웃바운드 트래픽을 허용
• 보안 그룹 규칙은 언제나 허용 여부만 정할 수 있고 거부 여부는 정할 수 없다.
• 보안 그룹은 스테이트풀(Stateful) 속성을 지니며 인스턴스에서 요청을 보내면, 해당 요청에 대한 응답 트래픽은 보안 그룹의 인바운드 규칙과 무관하게 전달이 허용된다.
• 보안 그룹 규칙은 언제든 추가 또는 삭제할 수 있다. 변경 사항은 짧은 시간 내에 해당 시큐리티 그룹에 연결된 모든 인스턴스에 적용됩니다.
• 하나의 인스턴스에 여러 개의 시큐리티 그룹을 연결할 경우 각 시큐리티 그룹의 규칙은 단일 규칙 세트로서 인스턴스에 적용되고 사용자는 이 규칙 세트를 통해 트래픽의 허용 여부를 결정할 수 있다.

 

네트워킹 - Instance IP 주소 지정

프라이빗 IPv4

프라이빗 IPv4 주소는 인터넷을 통해 연결할 수 없는 IP 주소이다. 프라이빗 IPv4 주소는 동일 VPC에서 인스턴스 간의 통신을 위해 사용하며 인스턴스를 시작할 때 인스턴스에 기본 프라이빗 IPv4 주소와 내부 DNS 호스트 이름이 할당됩니다.

퍼블릭 IPv4

퍼블릭 IP 주소는 인터넷을 통해 연결할 수 있는 IPv4 주소이다. 퍼블릭 주소는 인스턴스와 인터넷의 상호 통신을 위해 사용될 수 있으며 인스턴스가 중지되거나 최대 절전 모드로 전환되거나 종료되면 인스턴스의 퍼블릭 IP 주소는 해제된다. 중지되거나 최대 절전 모드로 전환된 인스턴스가 시작되면 새 퍼블릭 IP 주소가 할당된다.

 

따라서 필요에 따라 인스턴스 간에 연결할 수 있는 영구 퍼블릭 IP 주소가 필요한 경우 탄력적 IP(Elastic IP) 주소를 대신 사용해야 한다.

Elastic IP

탄력적 IP 주소는 동적 클라우드 컴퓨팅을 위해 고안된 정적 IPv4 주소이다. 탄력적 IP 주소는 AWS 계정에 할당되며 해제할 때까지 할당된 상태로 유지된다. 탄력적 IP 주소를 사용하면 주소를 계정의 다른 인스턴스에 신속하게 다시 매핑하여 인스턴스나 소프트웨어의 오류를 마스킹할 수 있으며 도메인이 인스턴스를 가리키도록 도메인에 대한 DNS 레코드에 탄력적 IP 주소를 지정할 수 있다. 주의해야 할 점은 연결 해제한 탄력적 IP 주소는 명시적으로 릴리스할 때까지 계정에 할당되어있으므로 실행 중인 인스턴스와 연결되지 않은 탄력적 IP 주소에 대해서는 소액의 시간당 요금이 부과된다.

 

Storage

 

파일 스토리지

파일 스토리지는 일상적인 컴퓨터 사용 시 볼 수 있는 윈도우의 탐색기, 맥OS의 파인더를 떠올리면 됩니다. 파일 시스템은 종이 파일 및 폴더가 캐비넷이 정리되는 방식을 모방한 계층적 구조를 갖고 있습니다.

파일 스토리지는 흔히 주차장 건물에 비유됩니다. 주차되어 있는 차가 많을수록 그 깊이가 깊어지고 그만큼 구조가 복잡해져 주차하거나 차를 되찾는 과정이 힘들어집니다.

파일 스토리지는 데이터 양이 늘어나면서 파일과 폴더를 계속 추적하기 위한 자원 요구가 늘어나 성능이 떨어질 수 있습니다.

이러한 문제가 있음에도, 파일 스토리지는 개인용 컴퓨터와 서버에서 일상적인 작업을 잘 수행하여 널리 사용됩니다. 파일 스토리지는 일반적으로 NAS(Network Attached Storage)에 사용됩니다.

블록 스토리지

블록 스토리지는 그 이름에서 알 수 있듯이, 단일 스토리지 볼륨을 ‘블록’이라는 개별 단위로 분할하여 저장하는 방식입니다. 블록 스토리지는 주차장으로, 블록은 주차장의 구획된 한 면으로 비유할 수 있습니다. 블록은 파일보다 하위 개념의 저장 단위입니다.

블록 스토리지는 파일 스토리지 시스템이 구축되는 기반으로 생각할 수 있습니다. 블록 스토리지에서 데이터는 블록 단위의 일정한 크기의 조각으로 나누어 저장됩니다. 각 블록은 저장된 위치에 대한 고유한 주소를 가지고 있어 만약 서버에서 파일을 요청하면 블록들을 재구성해 하나의 데이터로 서버에 전달하게 됩니다.

클라우드 환경에서 블록 스토리지의 각 블록은 가상머신 인스턴스에 위치하며, 마치 일반 컴퓨터에 하드디스크를 추가하여 C드라이브, D드라이브와 같이 구분하여 사용하는 것과 같습니다. 블록 스토리지는 SAN(Storage Area Network) 또는 가상머신의 디스크로 사용됩니다.

객체 스토리지

객체 스토리지는 각 데이터 조각을 가져와서 객체로 지정하고, 개별 단위로 저장하는 유형입니다. 객체 스토리지는 흔히 대리주차 방식에 비유되곤 합니다. 사용자는 주차 위치를 알 필요가 없고 키를 제시하며 주차를 요청하거나 차를 가져와달라고 하기만 하면 됩니다.

객체 스토리지에서 모든 객체는 파일 스토리지와 다르게 중첩된 계층 구조 없이 단일한 평면적인 주소 공간에 저장됩니다. 이 평면 주소 공간에는 고유 식별자가 있고 객체는 별도의 파일 시스템 테이블이나 색인의 일부가 아닌 객체 자체로 저장되므로 접근이 더 쉬워집니다. 객체 스토리지 시스템에서는 객체의 키(이름)만 알고 있으면 빠르고 쉽게 대상을 검색할 수 있습니다.

오늘날 많은 사용자가 사용하는 이미지, 영상 등 복잡하고 대용량인 비정형 데이터의 처리를 효율적으로 할 수 있어 대부분의 서비스 백엔드 스토리지로 사용되고 있습니다.

 

클라우드 스토리지

 

인터넷 공간에 데이터를 저장하는 저장소이며 구글의 Google Drive, 네이버의 MYBOX, 마이크로소프트의 Onedrive와 같은 서비스가 좋은 예시이다.

 

 

S3(Simple  Storage Service)

 

AWS에서 제공하는 클라우드 스토리지 서비스이며 많은 이점들이 있다.

• 높은 확장성 - 많은 시간과 수고를 들이지 않고 스토리지 규모를 확장/축소할 수 있으며 스토리지의 용량을 무한히 확장할 수 있다.                             그리고 사용한 만큼만 비용을 지불하면 되기 때문에 비용적인 측면에서 매우 효율적이다.
• 강력한 내구성 - 스토리지의 내구성이 높으면 저장된 파일을 유실가능성이 적으며, S3는 99.999999999%의 내구성을 보장한다.
• 높은 가용성 - 가용성이 높으면 스토리지에 저장된 파일들을 정상적으로 사용할 수 있는 시간이 길어지며 S3는 연간 99.99%의 스토                       리지 가용성을 보장하도록 설계가 되어 있습니다.

EC2, RDS, S3의 개념을 학습하고 있는데, 해당 서비스들이 공통적으로 '높은 가용성'과 '높은 내구성'을 보장한다는 점을 알 수 있다. 

그 이휴는 리전과 가용 영역때문이다. 리전은 물리적 지역이고 가용 영역은 데이터 센터인데 한 리전에 최소 2개 이상의 가용 영역이 있어야 하며 만약 하나의 가용 영역에 오류나 재난 상황으로 인해 가동이 불가해진다하여도 다른 가용 영역에 백업을 해놓은 데이터를 활용하여 문제없이 서버를 가동 시킨다.

 

• 다양한 스토리지 제공 - 저장소를 어떤 목적으로 활용할지에 따라 효율적으로 선택할 수 있는 스토리지가 다양하다.

Standard 클래스는 범용적인 목적으로 사용하기 좋다. 데이터에 빠른 속도로 접근할 수 있고, 데이터 액세스 요청에 대한 처리 속도가 빠르지만 대신 데이터를 오래 보관하는 목적으로는 효율적인 선택지가 아니다. 왜냐하면 보관 비용이 높기 때문이다.

 

Glacier클래스는 장기적인 보관 목적으로 사용하기 좋다. 저장된 데이터에 액세스하는 속도는 느리지만, 데이터를 보관하는 비용이 매우 저렴하다는 장점이 있다.

 

그 밖에도 Standard-IA, One Zone-IA, S3 Glacier Deep Archive 등등 여러 가지 스토리지 클래스가 존재한다.

 

• 정적 웹 사이트 호스팅 가능 - 버킷을 통해 정적 웹 사이트 호스팅이 가능하다.

정적 파일은 서버의 개입없이 생성된 파일을 일컫는다. 반대로 클라이언트가 서버에 요청을 보내면, 서버가 요청에 맞추어 그 자리에서 생성한 파일을 '동적' 파일이라고 부릅니다.

ex) 네이버 로고 이미지파일은 정적, 실시간 검색어는 동적

 

웹 호스팅(Web Hosting)은 서버의 한 공간을 임대해 주는 서비스를 뜻이며 S3에서는 버킷이 사용자들이 정적 웹 사이트를 배포할 수 있는 공간을 제공한다. 

 

버킷

버킷은 객체를 저장하는 컨테이너 역할을 하며, 컴퓨터로 비유하자면 파일을 담는 폴더 역할을 한다. 따라서 한 버킷 내에 여러 개의 폴더를 생성할 수도 있습니다.

 

버킷 생성 시 주의해야 할 점은 버킷 이름을 붙일 때 여러 리전에서 유일무이한 이름을 사용해야 한다. 그래야 사용자가 버킷 URL을 통해 해당 데이터에 접근할 수 있다.

 

버킷은 어떤 리전에서나 생성할 수 있고, 명시적으로 복제 작업을 수행하지 않으면, 한 다른 리전에 특정 버킷의 데이터가 복제 되지 않는다. 또한 S3 버킷은 버전 부여 기능을 제공하므로 객체가 버킷에 추가될 때마다 해당 객체에 유일한 ID가 할당된다.

객체

앞서 언급했듯 객체란 문서, 이미지, 비디오 등 비교적 단순한 구조에 메타데이터을 포함하고 있는 데이터로, 버킷에 저장한 모든 것을 객체라고 부르며 이는 가장 기본적인 요소로, 각 객체는 데이터와 메타데이터를 가진다. 메타데이터는 해당 객체를 설명하는 이름-값 쌍으로 표시하며 여기에는 최종 수정일, 파일 타입 등 부가 정보가 기록된다. 객체는 이름, 키 또는 버전 ID를 통해 식별할 수 있으며, 키를 통해 버킷에서 유일한 것으로 식별한다. 따라서 버킷에 존재하는 모든 객체는 단 하나의 키를 가진다.

 

접근성 통제

접근성 통제(Access Control)란, S3 버킷에 누가 어떻게 접근하도록 할 것인지를 정의하는 것을 말한다. 접근성 통제 방식은 주로 JSON을 이용해 작성된 정책(Policy)를 통해 이루어지며, 접근 정책, 버킷 정책, 접근 제어 목록 등의 방식을 사용한다. 정책을 만드는 JSON 파일의 구조는 아래와 같다. 하나의 Statement에는 하나의 permission 정보가 포함되며 정책에 포함된 다수의 statement은 논리합(Logical OR) 관계를 맺는다.

 

• ID : 정책의 ID 값으로, UUID를 사용하기를 권장합니다.
• SID : Statement ID로 statement 를 구분하기 위해서 사용합니다.
• Effect : 정책의 효과를 나타내며, 허용할 것인지 거부할 것인지를 선택할 수 있습니다.
• Principal : 대상 및 주체를 지정합니다. Users, Services 등이 될 수 있습니다.
• Action : 정책을 통해 승인 혹은 거절할 동작을 의미합니다.
• Resource : Action이 영향을 미치는 리소스 리스트를 지정합니다.
• Condition : 조건이 충족되는 경우에는 해당 정책을 적용시킬 수 있습니다.

 

접근 정책(Identity-based policies)

IAM, 즉 신분 및 접근 관리 정책으로 S3의 객체를 매우 세분화해 통제할 수 있다. 먼저 유저, 그룹, 롤 등 IAM 정책을 정의한다. 예를 들어, S3 풀 액세스 정책을 생성하고, 10명의 유저가 포함된 그룹에 해당 정책을 할당하면 해당 그룹에 속한 10명의 회원 모두 S3 버킷에 대한 풀 액세스 권한에 접근 가능하다.

 

IAM과 S3를 이용하면 특정 IAM 유저와 공유되고 있는 버킷을 선택할 수 있고, 특정 유저가 해당 버킷에 접근하도록 허용할 수 있다. 또한 특정 버킷의 내용을 회원 모두 혹은 일부 회원이 열람하도록 할 수 있고, 고객 또는 파트너가 특정 버킷에 객체를 추가하도록 허용할 수 있다.

 

    {
       "Version":"2012-10-17",
       "Statement":[
          {
             "Effect":"Allow",
             "Action": "s3:ListAllMyBuckets",
             "Resource":"*"
          },
          {
             "Effect":"Allow",
             "Action":["s3:ListBucket","s3:GetBucketLocation"],
             "Resource":"arn:aws:s3:::awsexamplebucket1"
          },
          {
             "Effect":"Allow",
             "Action":[
                "s3:PutObject",
                "s3:PutObjectAcl",
                "s3:GetObject",
                "s3:GetObjectAcl",
                "s3:DeleteObject"
             ],
             "Resource":"arn:aws:s3:::awsexamplebucket1/*"
          }
       ]
    }

 

이 예제에서는 AWS 계정 의 IAM 사용자에게 버킷 중 하나인 awsexamplebucket1에 대한 액세스 권한을 부여하고 이 사용자에게 객체를 추가, 업데이트, 삭제하도록 허용하려 한다.

 

1. s3:PutObject, s3:GetObject 및 s3:DeleteObject 권한을 사용자에게 부여합니다.

 

2. 이 정책에서는 s3:ListAllMyBuckets, s3:GetBucketLocation 및 s3:ListBucket 권한 역시 부여합니다. 이러한 권한은 콘솔에 필요한 추가 권한입니다.

 

3.콘솔에서 객체를 복사, 자르기 및 붙여넣기를 할 수 있으려면 s3:PutObjectAcl 및 s3:GetObjectAcl 작업이 필요합니다. 따라서 총 세 개의 statement가 하나의 정책으로 작성된 것을 확인 할 수 있고, 이렇게 작성된 정책을 그룹, 유저 등에 할당하여 사용할 수 있습니다.

 

간단히 사람에게 제한을 거는 정책이다.

 

버킷 정책(Resource-based policies)

 

버킷 정책이란 버킷 레벨에서 생성한 정책을 의미하며, S3 버킷을 세분화된 방식으로 제어할 수 있도록 한다.

대표적인 버킷 정책의 사례는 특정 버킷에 있는 객체에 대한 익명의 사용자로부터의 리드 온리 접근을 허용하는 케이스이다. 이는 S3 리소스 기반의 정적 웹 사이트를 운영하거나, 웹을 통해 불특정다수의 접근을 허용할 때 자주 사용되는 방법으로 버킷에 GetObject 액세스 권한을 부여하면 된다.

{
      "Version":"2012-10-17",
      "Statement":[
        {
          "Sid":"PublicRead",
          "Effect":"Allow",
          "Principal": "*",
          "Action":["s3:GetObject"],
          "Resource":["arn:aws:s3:::devopscodestates/*"]
        }
      ]
    }

devopscodestates 버킷의 모든 리소스를 GetObject 작업으로 누구나 접근할 수 있음을 Principal 필드의 값을 통해 확인할 수 있다.

 

간단히 객체에게 제한을 거는 정책이다.

 

접근과 버킷을 구분하는 방법은 Principal값이 있으면 버킷, 없으면 객체이다.

 

 

Storage - EBS(Elastic Block Store)

 

EBS는 EC2 인스턴스에 사용할 수 있는 블록 수준 영구 스토리지 볼륨이며 영구 스토리지는 EC2 인스턴스의 수명주기를 넘어서서 존재할 수 있는 스토리지의 의미이다. EBS 볼륨은 형식이 지정되지 않은 원시 블록 디바이스처럼 동작하며 볼륨 위에 파일 시스템을 생성하거나 하드 드라이브와 같은 블록 디바이스를 사용하는 것처럼 볼륨을 사용할 수 있다. 인스턴스에 연결된 볼륨의 구성을 동적으로 변경할 수 있다.

 

EBS 볼륨은 EC2 인스턴스의 부트 파티션으로 사용되거나 실행 중인 EC2 인스턴스의 표준 블록 디바이스로 사용된다. EC2 인스턴스에 EBS 볼륨을 부착하면, 서버를 위한 하드 드라이브와 같은 기능을 수행하게 된다.

 

그 뿐만 아니라 하나의 EC2에 여러 개의 EBS 볼륨을 부착 할 수도 있는데 이렇게 하면 부트 볼륨과 데이터 볼륨을 별도로 관리 할 수 있어서 편리하다.

 

EC2에 부착한 EBS 볼륨은 언제든 분리할 수 있고, 다른 EC2에 부착도 가능하지만, EBS 볼륨은 특정 AZ에 속한 자원이기도 하므로, 서로 다른 AZ 간의 EC2에 EBS 볼륨을 분리하고 부착하는 것은 불가능하다.

EBS 볼륨은 부트 파티션으로도 사용할 수 있으며 이때는 EC2 인스턴스가 정지 후 재시동돼 해당 인스턴스 상태를 유지하기 위한 스토리 리소스로서의 기능만 담당하게 된다. 또한 EBS 볼륨은 서버 재시동 후에도 유지되므로 기존에 저장된 내용은 그대로 남게 된다. EBS 볼륨은 EC2 인스턴스의 로컬 스토리지에 비해 훨씬 높은 수준의 견고성을 제공한다.

 

EBS는 볼륨에 대한 특정 시점의 스냅샷을 지속적으로 작성해 S3에 저장하는 방식으로 다수의 AZ에서 자동 복제 기능을 제공한다. 이렇게 생성된 스냅샷은 또 다른 EBS 볼륨 생성을 위한 시작점으로 활용할 수 있으며, 장기간 서버와 관련된 데이터를 안전하게 보호할 수 있다.  스냅샷은 리전 간 복제해서 사용할 수도 있으므로 재난 복구, 데이터센터 마이그레이션 등에도 편리하게 사용할 수 있다.

 

Storage - EFS(Elastic File System)

 

EFS는 서버를 사용하지 않는 간단한 탄력적인 파일 시스템을 제공한다. EFS 로 파일 시스템을 생성하고 EC2 인스턴스에 파일 시스템을 탑재한 후 파일 시스템에 데이터를 작성하거나 파일 시스템에서 데이터를 읽을 수 있다.

 

애플리케이션을 중단하지 않고 온디맨드 방식으로 페타바이트 규모까지 확장되도록 구축되어, 사용자가 파일을 추가하고 제거할 때 자동으로 확장/축소되므로 데이터 증가에 맞춰 용량을 프로비저닝 및 관리할 필요가 없다.

 

EFS 는 파일 시스템을 빠르고 쉽게 만들고 구성할 수 있는 간편한 웹 서비스 인터페이스를 제공하며 이 서비스에서 모든 파일 스토리지 인프라를 관리해 주므로 사용자는 복잡한 파일 시스템 구성을 배포, 패치 및 유지 보수하는데 따르는 복잡성에서 벗어날 수 있다.