EC2

• 스토리지, 네트워크, 보안 등 서버 속성 제어
• 최소의 시간 투자, 서버의 각종 환경 설정 가능
• 간단한 서버 획득, 부팅 작업, 대량의 서버 배포
• 워크로드에 따라 신속하게 스케일업/스케일다운

AMI : 가상 서버 생성용 이미지

EBS : 블록 스토리지

ASG : 서버 확장 및 축소 자동화

ELB : 요청량에 따라 다수의 서버에 부하 분산

VPC : 기업 전용 가상 네트워크

AMI - EC2 인스턴스 생성 방법

• 가상 서버의 S/W 구성 정보를 포함한 설계도
• OS, 앱 서버 S/W 응용 S/W 등 세부 요소 포함
• 기업 업무에 최적화된 AMI를 이용하여 해외 지사 등에 신속하게 다수의 가상 서버를 배포 가능

하나의 설계도(AMI)를 가지고 한개 혹은 여러개의 서버를 만들 수 있다.

 

활용하기

본사(서울 리전)의 AMI를 두바이 지사(UAE 리전)와 공유하기

 

1. 본사에서 오랜 기간 사용하며 업무 특성에 최적화한 커스텀 이미지 (AMI)
2. 해외지사 내 다른 계정 유저에게 이미지를 복사하여 전달
3. 전달받은 AMI로 EC2 인스턴스 생성

부팅 방식별 AMI 유형

인스턴스 스토어 기반 AMI : S3에 저장된 부팅 이미지로 EC2 인스턴스 시작

EBS 기반 : EBS 볼륨에 저장된 부팅 이미지로 EC2 인스턴스 시작

EC2 환경설정 옵션

OS : 리눅스, 윈동우, 맥

연산 및 입출력 성능 : CPU, RAM

스토리지 : Instance Store, EBS, EFS

네트워크 : VPC, CIDR, Subnet, IGW

방화벽 : SG

초기 서버 환경 설정 : user-data

구매옵션

온디맨드 : 1년 미만, 사용량 예측 어려운 경우

예약 : 1년 이상, 사용량 예측 용이, 3가지 세부 옵션

스팟 : 입찰 방식으로 저렴, 단기적 활용, 작업 중단 대비

전용 인스턴스 : 고객 전용 하드웨어 할당 

전용 호스트 : 고객 요구에 맞춘 커스텀 하드웨어

 

EC2 멀티 테넌시 모델

하드웨어 리소스 가상화, 다수 사용자가 공유

하나의 물리적 서버, 다수의 EC2 인스턴스 실행

16cpu 서버 생성 요청 : 16 cpu 리소스 할당

전용 물리적인 서버 대시, 성능 저하 가능성

EC2 인스턴스의 스토리지

EBS 볼륨 : 네트워크 드라이브 볼륨 역할

EFS :  윈도우즈 운영체제의 공유 폴더나 구글 드라이브처럼 여러 컴퓨터가 동시에 접근할 수 있는 스토리지

Instance Store : 하드 드라이브 볼륨 역할

 

EBS 볼륨 타입

범용 스토리지(gp2/gp3 ssd) : 저비용 고성능, 개발 및 테스트 워크로드

PIOPS 스토리지(io1/io2 PIOPS SSD)  : I/O 처리성능 최대화, IOPS 자원 소모(읽고 쓰는것 자체가 자원, 다사용시 구매 필요할 수 있음), DB 워크로드

마그네틱 스토리지(st1/sc1 HDD): 저렴, 중요성 낮은 워크로드

st1: 빅데이터, 데이터웨어하우스 (입출력 속도가 중요하지 않을 때)

인스턴스스토어

EC2 인스턴스에 고정된 고성능 하드 디스크

인스턴스와 생애주기 동일한 스토리지

IOPS 성능은 EBS 대비 월등, 버퍼, 캐시 용으로 적합

백업 권장

확장성, 가용성

수직적 확장성

• H/W 업그레이드 컨셉
• 인스턴스 용량 상향 또는 하향
• 데이터베이스(비분산형 시스템)
• RDS, ElastiCache

 

수평적 확장성

• 탄력성
• 인스턴스의 수 증가 또는 감소
• 현대 분산형 시스템
• ASG, ELB로 구현

가용성

재난 상황 속에서 운영/데이터 손실 최소화

멀티 AZ, 중복 구현

능동적 가용성 : 멀티 AZ ASG 구현

수동적 가용성 : 멀티 AZ RDS

---

EC2 AUto Scaling

워크로드에 따라 인스턴스를 자동으로 증가 또는 감소시킴

오토스케일링 그룹, 시작 템플릿, 조정 정책 등 요소

내오류성 향상, 가용성 향상, 비용 절감

미디어, 엔터테인먼트 산업 등 가변적 수요에 대응

조정 정책 : 수동, 일정(예약), 온디맨드(동적)

 

AUto Scaling group

최대/최소 크기, 희망 용량

동적 조정

대상 지표의 목표값 지정 가능

알람 수준에 따라 조정

알람시 지정 크기 증가

로드 밸런서 load balancer

트래픽 로드를 다수의 인스턴스에 분산

앱에 DNS 등 단일 접속 지점 제공

트래픽 분산, 인스턴스 헬스체크

SSL(HTTPS) 기반 보안성 연결 제공

private, public 트래픽 별도 관리

멀티 AZ 기반 고가용성 실현

AWS ELB

ALB, NLB, GLB - 관리형 로드 밸런서

EC2, ASG, ECS, CloudWatch 앞에 연결

Rout53, WAF, Global Accelerator 등과 연계

헬스 체크 : 로드 밸런서가 인스턴스에 응답 요청

 

보안그룹

EC2 인스턴스 방화벽

서브넷의 NACL과 함께 네트워크 보안 주요 요소

인스턴스로 유입/유출되는 트래픽 통제

허용 규칙만 적용 가능

 

특징

기본 보안 그룹은 모든 아웃바운드 트래픽 허용

스테이트풀 (요청 응답은 규칙 무관, 전달 허용) - 내보낸걸 기억하는 속성 [반대:스테이트레스]

보안 그룹의 규칙은 언제든 추가 또는 삭제 가능

다수의 규칙 존재 시, 가장 허용적인 규칙 적용

---

PaaS와 Elastic Beanstalk

웹 앱의 개발 속도를 높일 수 있는 프리빌트-백엔드(출시 속도 향상 - 로그인, 고객 관리 기능 등 공통 백엔드 요소)

앱 개발자가 앱 서비스를 개발 및 제공하는 데 필요한 제반 요소 제공

Dev tools, OS, Middleware, DB ,App service infra +

서버리스 컨셉과 유사성 있음( 스케일링 방식은 차이)

Elastic Beanstalk

PaaS, 인프라 프로비저닝 없이 신속하게 웹 앱 배포 및 스케일링

앱을 위한 모바일 API 백엔드 구현, 자동 패치 및 업그레이드

레거시에서 중요한 비즈니스 앱 마이그레이선

개발 옵션 : Java, .NET, Node,js, Python +

 

Serverless

서버 배포 및 관리 필요성 없이 코드 실행, 데이터 관리, 앱 통합(코드만 실행하면 됨)

자동 크기 조정, 고가용성, 종량제 결제 모델

민첩성 향상, 비용 최적화(과잉 프로비저닝 감소)

Lamda, Fargate, EventBridge, SQS, S3, DynamoDB, Aurora 등

 

Lamda

이벤트 기반 서버리스 컴퓨팅 서비스

인프라 프로비저닝 없이 코드 실행(Faas)

고도의 확장성, 연속적 스케일링

 

컨테이너

하나의 컨테이너는 앱과 앱 실행에 필요한 시스템 라입러리, 시스템 설정 및 기타 종속성 요소를 모두 포함

호스팅 위치에 관계없이 동일한 방식으로 실행

컨테이너화된 각각의 환경은 하나의 앱만 실행(커널은 공유하지만) 시스템의 다른 요소와 상호작용하지 않도록 구획

 

ECS - Clastic Container Service

완전관리형 컨테이너 오케이스트레이션 서비스

CI/CD, 자동화 도구 연계하여 수천 개의 컨테이너를 시작 및 관리

비용 절감 : 자율 프로비저닝, ALB 통합 오토스케일링, 종량제 요금

EC2 또는 Fargate 등 컴퓨트 리소스 위에 컨테이너 프로비저닝

 

ECR : 컨테이너 저장, 관리, 배포 서비스

 

Fargate

컨테이너를 EC2 인스턴스 등 인프라 위에 프로비전 할 필요 없음

CPU / RAM 용량 기반으로 컨테이너 실행

 

EKS - Elastic Kubernetes Service

오픈소스 컨테이너 오케스트레이션 플랫폼인 쿠버네티스 기반

ECS와 유사함

쿠버네티스 컨트롤 플레인 및 노드 설치, 운영 관리 부담 감소

고가용성 : 멀티 AZ 기반 컨트롤 플레인 실행 및 크기 조정

 

 

 

 

참조사이트:

https://www.daleseo.com/aws-ec2-storage/

Amazon EC2의 스토리지 옵션

https://tezhost.com/cloud-computing/iaas-vs-saas-vs-paas/

IaaS Vs SaaS Vs PaaS : The Ultimate Guide  - TezHost