EC2 - Elastic Compute Cloud
EC2란 AWS의 가상 컴퓨터 리소스이자 가장 기본적인 서버 리소스이다. 컴퓨터 하나 당 EC2 인스턴스라고 한다. 컴퓨터이니 OS가 필요하고, OS는 설정과 정보들을 담아둔 이미지인 AMI로 실행할 수 있다.
인스턴스의 상태는 여러가지가 있지만 종료와 중단은 특히 구분되어야 한다. 중단(Stop)은 인스턴스를 사용하진 않지만 삭제하지 않고, 종료(Terminate)는 인스턴스를 삭제하는 것이다.
디스크 역할을 하는 스토리지 볼륨으로는 네트워크 기반의 EBS(Elastic Block Storage)나 EFS(Elastic File System)를 연결해줄 수도 있고, 인스턴스 자체의 스토리지인 인스턴스 스토어를 사용할 수 있다. 네트워크 기반의 스토리지는 물리적으로는 서버와 떨어져 있지만 인스턴스 스토어는 인스턴스 자체의 디스크를 사용하는 것이기 때문에 IOPS가 굉장히 높다. 하지만 물리적으로 붙어있다는 것은 EC2 인스턴스가 종료되면 인스턴스 스토어도 같이 없어진다. 반면, 네트워크 기반의 스토리지는 EC2 인스턴스와 별개로 존재시킬 수 있다. 보통 EBS는 EC2 인스턴스의 생명 주기와 같이 설정되어 인스턴스 삭제 시 종료가 되는데, 이는 사실 EC2 인스턴스의 설정으로 Delete on termination가 기본으로 true인 것이다.
아무나 EC2 인스턴스에 접근할 수 없고, 이를 사용자가 설정해주어야 한다. 인스턴스에 보안 그룹을 부착해서 접근을 제어한다.
컴퓨터를 부팅할 때 기본적으로 실행시키는 스크립트를 정의할 수 있다. EC2 User Data에 스크립트를 작성하면 이를 부팅할 때 한 번만 실행한다. 원하는 소프트웨어나 파일을 최초 부팅 시 꼭 다운받을 필요가 있을 때 사용할만 하다.
보통 OS로 Linux나 Ubuntu를 설정하게 된다. 그러면 SSH로 접속을 할 수가 있는데, SSH 접속을 위해선 콘솔로 접속하거나 외부 접속 시에는 SSH 키를 사용해서 접속할 수 있다. 이를 위해 SSH Key Pair를 생성해서 이를 할당해줘야 한다. 키는 pem(OpenSSH)키나 ppk(PuTTY)가 있고, Windows 환경에서 접속 시 ppk를 받아서 PuTTY를 사용하거나 pem 키를 MobaXterm 등으로 OpenSSH로 접속해야한다. 키는 생성하고 한 번만 다운 받을 수 있을테니 신중하자.
EC2 인스턴스 네트워크로는 VPC를 설정한다. 어느 VPC의 어느 subnet에 있는지 설정해야한다. 그래서 EC2 인스턴스는 IP나 호스트를 가지고 있다. VPC의 사설 네트워크 영역인 Private IP가 기본적으로 존재하고, 인터넷에 접근시킬 수 있는 Public IP도 할당할 수 있다. Public IP를 할당하기 위해 VPC의 Public subnet에 존재해야 하며, VPC의 Public subnet에서 자동 할당을 설정할 수 있다.
컴퓨터마다 사양이 다르듯, EC2도 용도에 따라 사양을 정할 수 있다. 이러한 사양을 나타내는 것이 인스턴스 타입이다.
인스턴스 타입
인스턴스 타입은 인스턴스 패밀리 + 세대 + 사이즈로 구성되어 있다. 예를 들어, t3.small 인스턴스 타입은 t패밀리의 3세대 small 사이즈이다. 인스턴스 패밀리 타입은 아래와 같다.
범용인 General Purpose, 성능을 위한 Compute Optimized나 HPC(High Performance Computing), 인메모리 RAM 성능이 좋은 Memory Optimized, OLTP 등 디스크 I/O 성능과 스토리지 성능이 뛰어난 Storage Optimized 등이 있다. 머신러닝이나 게임, 스트리밍 등 성능이 중요하면 Compute Optimized 패밀리, 메모리 성능이 중요하다면 Memory Optimized(특히 r패밀리), 스토리지 성능이 중요하다면 Storage Optimized를 생각하면 좋다.
이러한 인스턴스 타입에 여러 세대와 사이즈가 존재한다. 보통 세대가 높아질 수록 더 많은 가상 CPU(vCPU)를 가지고, 사이즈가 높아질 수록 RAM이 높아진다. 자세한 건 AWS 공식 홈페이지를 한 번 쯤 보면 좋다.
Pricing Plan
기본적으로 AWS의 리소스 비용은 리소스를 사용하는만큼 지불한다. 하지만 경우에 따라서 적절한 Pricing Plan으로 인스턴스 비용을 절약할 수 있다.
On Demand
기본적으로는 온디맨드로 사용량 기반이다. 사용 상황이 자주 바뀌거나 얼마나 사용량이 불확실 할 때 선택하는 것이 좋다. 오랜 기간 AWS 서비스를 사용한다면 더 좋은 플랜이 있다. 원하는 시간대만 가용하고 싶다면 온디맨드가 적합하다.
Reserved
1년 이상 사용한다면 예약 인스턴스로 비용을 절감할 수 있다. 1년과 3년동안 인스턴스를 선지불로 예약할 수 있고, 길수록 할인이 더 많이 들어가서 최대 72% 할인이 적용된다. 심지어 예약 인스턴스를 사고 팔 수 있다.
1년 이상, 매일 매일 24시간 가용을 한다면 예약 플랜을 사용하는 것이 좋다. 하지만 인스턴스 타입은 미리 선택해야한다.
Saving Plan
Saving 플랜은 Reserved랑 같지만 패밀리 내에서 인스턴스 타입을 교체할 수 있다. 다양한 인스턴스 타입이 필요할 때 사용할 수 있으며, 예약된 인스턴스 사용량이 넘어가면 온디맨드 기반으로 계산된다. 최대 66%까지 할인된다.
기본적인 EC2 Instance Saving 플랜을 사용하면 교체할 수 있는 패밀리는 패밀리 종류에 한정된다. 예를 들어, t패밀리로 Saving 플랜을 구매했다면 같은 t패밀리로만 교체할 수 있다.
반면, Compute Saving 플랜을 사용하면 Compute 패밀리 종류 내의 모든 패밀리로 교체할 수 있다. 제품군을 더 자유롭게 바꾸려면 EC2 Instance Saving 플랜이 아닌 Compute Saving Plan으로 해야한다. 당연히 가격은 더 비싸지긴한다.
Spot
최대 90%까지 할인되는 플랜이다. 하지만 인스턴스가 갑자기 중단될 수 있다. 기본적으로 온디맨드나 예약을 사용하다가 추가적인 리소스를 사용하거나 개발환경 등 리소스 중단이 치명적이지 않을 때 적합하다. 혹은 배치, 데이터 분석, 이미지 프로세싱 등 아무때나 해도 상관없고 복구 가능하면서 상태 비저장인 경우 사용하는 것도 적합하다.
스팟 인스턴스는 스팟 요청으로 관리된다. one-time으로 설정된 스팟이라면 무작위로 종료되고 끝이지만, persistent로 설정되었다면 스팟이 종료되고 다음 스팟이 생성된다. 무작위로 종료되는 인터럽션이 발생된다면 인스턴스를 중단, 삭제, 혹은 hibernate를 할 지 설정할 수 있다.
스팟 요청으로 인한 스팟 인스턴스 생명 주기 관리 시, persistent를 취소하고 싶다면 먼저 request를 취소해야한다. 스팟 인스턴스를 종료하고 request를 취소한다면, 스팟 요청이 먼저 생성을 하고 취소를 하기 때문에 인스턴스가 남게된다.
스팟은 단순히 하나만 쓰지 않고, 온디맨드까지 여러개를 묶어서 사용할 수도 있다. 이를 Spot Fleets라고 하며, 용량과 비용을 지정해서 스팟 플릿이 적절히 관리해준다. 기본적인 스팟 인스턴스에 온디맨드를 추가해서 사용하게 된다. 용량이나 비용이 넘어가면 자동으로 스팟을 재실행하고, 비용 우선이나 용량 우선, 혹은 둘을 합친 price capacity optimized 등의 전략을 선택할 수 있다.
Dedicated
인스턴스, 혹은 물리적 서버 자체를 독점할 수도 있다. Dedicated Instance를 사용하면 다른 사람과는 공유가 불가능한 인스턴스를 생성할 수 있지만 물리적 서버는 공유가 될 수도 있고, 물리적 서버를 아예 할당받고 싶다면 Dedicated Host를 사용해서 리소스를 독점할 수 있다. Compliance나 Security가 중요해서 특정 라이센스 사용이나 소켓이나 물리적 코어 노출에 대한 제어가 중요하다면 적합하다. 가격은 온디맨드 + Region fee(시간당 2불)이다.
Capacity Reservation
비교적 최근에 나온 솔루션으로, 특정 AZ에 원하는 기간만큼 용량을 예약할 수 있다. 특정 AZ에 원하는 인스턴스 수를 예약해서 트래픽이 과다할 때 정의해놓은 인스턴스를 즉시 가용하며 가용성 보장을 목표할 때 유용하다.
Placement Group - 배치그룹
영어로 공부할 땐 Placement Group이지만 한국어로 시험 볼 땐 배치그룹이라고 나와서 조금 헤맸었다. 배치 그룹 내의 EC2 인스턴스 생성 시 어느 AZ에 위치시킬지를 정의할 수 있다. 인스턴스 생성 시 설정할 수 있다. 주로 여러 EC2 인스턴스끼리의 네트워크를 형성할 때 적합한 배치그룹을 선택하는 문제가 나온다.
Cluster - 클러스터 배치그룹
단일 AZ에다 생성한다. 단일 AZ인 만큼 인스턴스끼리의 통신은 저지연이고, 그렇기 때문에 성능이 좋다. 대신 안 좋은 가용성이 단점이다. 단일 AZ=낮은 가용성이다. AZ에 장애 발생 시 해당 AZ의 모든 리소스가 영향받기 때문이다.
Spread - 분산 배치그룹
다중 AZ에다 생성하고, 각 AZ 당 최대 7개의 인스턴스를 분산한다. 지연이 좀 있을 수 있지만, 다중 AZ를 활용한 만큼 고가용성, 안정성이 장점이다. AZ로 Outpost를 사용해 사용자가 가진 물리 리소스를 사용할 수도 있다.
Partition - 파티션 배치그룹
다중 AZ에다 여러 파티션을 만들어 인스턴스를 분할한다. 파티션을 랙(rack)이라고도 한다. 분산 배치는 AZ 당 최대 7개의 인스턴스를 배치하지만, 파티션 배치는 AZ 당 최대 7개의 파티션을 배치하고 해당 파티션에 많은 인스턴스를 넣을 수 있다.
파티션에 여러 인스턴스를 넣으니 AZ 당 여러 인스턴스가 존재할 수 있고, 한 AZ에는 여러 파티션이 들어가니 AZ 내의 파티션 내의 수많은 인스턴스끼리는 저지연이다. 하지만 그러한 AZ에 장애가 발생하면 어떨까? 해당 파티션들이 모두 불능이된다. 그래도 다른 AZ에 다른 파티션이 존재한다. 즉, 성능으로 따지면 클러스터 >> 파티션 >> 분산 순이고, 가용성은 분산 >> 파티션 >> 클러스터 순이다. 하지만 파티션 배치의 큰 장점이 있다면, 최대 100개까지의 인스턴스를 배치그룹이 다룰 수 있다. 즉, 대량의 인스턴스와 대량의 데이터를 다루는 빅데이터나 데이터 분산 처리 환경 등에 적합하다.
EC2 Enhanced Networking
EC2 인스턴스끼리의 네트워크 성능을 높이는 솔루션이다. 문제를 거의 본 적은 없다.
AMI - Amazon Machine Image
EC2 인스턴스를 생성하기 위해 OS 설정과 정보를 알아야한다. 그러한 정보의 초기 볼륨 템플릿을 담고 있고 하이퍼바이저가 실행할 수 있는 이미지가 AMI이다. 도커를 많이 사용해봤다면 도커 이미지라고 생각해도 좋을 것 같다.
AMI는 OS 뿐만 아니라 다른 초기 소프트웨어나 설정 등을 담을 수 있다. 마켓플레이스에서 필요한 AMI를 사용할 수도 있지만, 커스텀한 환경이 EC2 인스턴스 생성 시 즉각적으로 적용되길 원한다면 커스텀 AMI를 만들어 둘 수도 있다. 커스텀 AMI를 만드는 방법은 가용 중인 EC2 인스턴스에서 환경을 AMI로 빌드하면 된다. 이렇게 생긴 AMI를 사용해서 다른 EC2를 시작할 때 사용할 수 있다.
Region Level의 리소스이다. 만약 내가 ap-northeast-2의 EC2 인스턴스로부터 AMI를 빌드했는데, us-east-1에서 곧바로 이를 사용할 수 없다. 사용하기 위해선 원하는 Region으로 복사해야한다!
AMI에 관한 문제가 은근 나온다. AMI를 사용해서 쉽게 EC2 인스턴스를 만들어 초기화 대기 시간을 줄일 수 있는데, 최소 초기화 대기 시간을 위해선 CloudFormation이나 EBS 스냅샷를 사용하는 것이 적합하다.
초간단 요약
Amazon Machine Image AMI
- 커스텀한 게스트 OS 이미지 포함한 EC2 기초 설정 포함 이미지
- 도커 이미지 같음
- 특정 region에서 빌드 후 다른 region으로 카피 가능
- ✨카피 안 하면 못씀!!✨
- 마켓플레이스도 있음
- Process
- EC2 시작
- AMI 빌드 ⇒ EBS Snapshot도 생성
- AMI로 다른 EC2 시작 가능
- 기본 서버 리소스
- 게스트 OS 이미지 - AMI (OS 템플릿 이미지) 설정
- ✨인스턴스 타입✨ - 인스턴스 패밀리 + 세대 + 사이즈
- Computing Optimized - High Performance가 필요할 때 (ML, 스트리밍, 게임 등)
- Memory Optimized - large data sets ✨in memory✨ (웹 분산화 캐싱 등 ≠ 인메모리 캐시)
- Storage Optimized - High read and write on local 빈도가 높을 때 → (✨OLTP✨, In-memory Cache, Data warehousing, file 등)
- 네트워크 - VPC
- 스토리지 볼륨
- network attached - EBS & EFS
- ✨Instance Store✨ - 인스턴스 RAM
- ✨설정으로 Delete on termination으로 인스턴스 삭제 시 삭제 가능 (default: true)✨
- 보안 - 보안그룹
- 랜카드 - Public IP
- Bootstrap
- ✨EC2 User Data로 부팅 시 실행 script - 한 번만 실행✨
- ex) Install software, update, download common file
- 해당 인스턴스의 root user로 작동
- SSH Key Pair - pem (OpenSSH) / ppk (PuTTY)
Pricing Plan
- On Demand
- 이용 기반
- 사용 상황이 자주 바뀌거나 얼마나 사용할지 ✨불확실할 때✨
- 오래 할거면 추천 ㄴㄴ
- Reserved ✨1-3년✨ - 길수록 할인 더
- 비용 먼저 지불
- ✨72% Discount✨
- 1년 이상 & 24시간 등 지속적인 사용 시 적합
- 인스턴스 타입 미리 선택
- 사고팔기 가능
- Convertible - 인스턴스 타입 변경 가능 66% 할인
- Saving Plan ✨1-3년✨
- Reserved + 인스턴스 타입 다중 선택 ⇒ 가격만 정해놓을게
- ✨다양한 운영 서비스✨ (다양한 인스턴스 타입) 필요 시 적합
- 예약한거 넘어가면 on demand만큼
- 인스턴스 패밀리별 가격대 형성. Computing, Memory, Storage 등등.
- Spot
- 갑자기 중단될 수 있음
- ✨90% Discount✨
- 리소스 중단이 ✨치명적이지 않을 때✨ (개발환경 등)
- 무작위 중단 → 원하는 시간대에만 중단하고 싶으면? On Demand
- 그럼 어따씀? Batch, data analysis, image processing → 아무때나 해도 되는거 → 복구 가능한거. ✨상태 비저장✨
- Spot Request로 관리
- one-time or persistent ? one-time이면 종료되면 끝
- persistent면 AWS에서 새로 instance 시작해줌
- interruption 시 어떻게 할건지 - terminate / stop / hibernate
- cancel하고 싶으면? fail이나 closed가 아닐 때만 가능. relaunch를 피하고 싶으면 stop request를 먼저 cancel 후 인스턴스를 terminate
- Spot Fleets
- spot 인스턴스 + 온디맨드
- capacity와 price 제한 launch pool을 define하면 fleet이 고름
- target capacity를 넘거나 비용제한을 넘으면 relaunch
- 전략 - lowest price(비용, short) / diversified 모든 풀 전체 중 가용성(가용성, long) / capacity optimized - capacity에 최대한 맞게 가용 / price capacity optimized - 가용성, 비용 최적
- Dedicated
- ≠ Dedicated Host → 물리적 서버 예약
- 인스턴스 할당을 직접 - 물리적 자원 독점 → 인스턴스고 뭐고 알아서 관리
- 가지고 있는 SW 라이센싱 사용 원할 시
- Dedicated Instance - 다른 사람 공유 불가
- 물리적 서버에 올릴 인스턴스
- Host랑 다른 점은? Host는 네트워크 노드 독점. Instance는 그런 Host에 돌아가는 인스턴스. 같은 계정으로 다른 인스턴스 만들면 host 공유될 수도
- ✨Compliance, Security✨
- On Demand 만큼
- ✨Region fee ($2 / hr)✨
- Visibility of Sockets and physical cores - 민감!
- ≠ Dedicated Host → 물리적 서버 예약
- Capacity Reservation
- Capacity 예약 for specific AZ (원하는 기간 만큼)
- Capacity 예약 빼면 On Demand랑 같음
Placement Groups
- EC2 인스턴스가 어떻게 위치할건지? - 인스턴스 생성 시 설정
- Cluster
- ✨Single AZ✨에서 지연시간 낮은 클러스터
- 인스턴스끼리 네트워크 지연 낮음 → 성능!
- AZ 망하면 다 망함
- 빨라야하는 작업 + (복구 가능 작업) ⇒ 안정성보단 ✨High Performance✨
- Spread
- AZ 당 7개 할당
- 분산이라 안정적
- AZ당 7개라서 지연이 좀 있을 수도 있음
- ✨고가용성, 안정성 추구, 3개 중 가용성이 최고✨
- 레벨 선택 시 Outpost도 가능 → 물리적으로 가지고 있는 랙에다 이을건지!
- Partition
- 여러 AZ에 여러 파티션에 인스턴스 분할
- partition = rack → AZ 당 랙이 7개 ⇒ 파티션 망하면 그 랙에 있는 인스턴스만 망함
- 같은 리젼에 많은 AZ활용 가능 → 분산 & 인스턴스 100개까지 가능!
- ✨빅데이터, 분산 데이터 처리 환경 등등, 안정성 짱✨
EC2 Hibernate
- stop - EBS 살아있음
- terminate - EBS 죽음 → Delete on Termination?
- 근데 stop하고 부팅할 때마다 script 돌리고 OS 기다려야하나..
- Hibernate!
- RAM과 OS는 그대로 ⇒ root EBS에 작성
- process
- EC2 run
- EC2 stop start
- RAM이랑 OS는 EBS에 작성
- EC2 stopped
- EC2 restart ? RAM이랑 OS 캐싱
- Long running processing, RAM 상태 저장 하고 싶을 때
- 인스턴스 RAM이 150기가보다 작아야하고 EBS가 encrypted여야함
EC2 Enhanced Networking
- 더 고처리량, 더 저지연 =? High Performance
- Elastic Network Adapter
- Elastic Fabric Adapter - Improved ENA
'DevOps > AWS' 카테고리의 다른 글
| AWS SAA - Auto Scaling Group (0) | 2025.03.08 |
|---|---|
| AWS SAA - Elastic Load Balancer & Elastic Beanstalk (0) | 2024.11.03 |
| AWS Certified Solution Architect - Associate (AWS SAA) 시작 (2) | 2024.10.31 |
EC2 - Elastic Compute Cloud
EC2란 AWS의 가상 컴퓨터 리소스이자 가장 기본적인 서버 리소스이다. 컴퓨터 하나 당 EC2 인스턴스라고 한다. 컴퓨터이니 OS가 필요하고, OS는 설정과 정보들을 담아둔 이미지인 AMI로 실행할 수 있다.
인스턴스의 상태는 여러가지가 있지만 종료와 중단은 특히 구분되어야 한다. 중단(Stop)은 인스턴스를 사용하진 않지만 삭제하지 않고, 종료(Terminate)는 인스턴스를 삭제하는 것이다.
디스크 역할을 하는 스토리지 볼륨으로는 네트워크 기반의 EBS(Elastic Block Storage)나 EFS(Elastic File System)를 연결해줄 수도 있고, 인스턴스 자체의 스토리지인 인스턴스 스토어를 사용할 수 있다. 네트워크 기반의 스토리지는 물리적으로는 서버와 떨어져 있지만 인스턴스 스토어는 인스턴스 자체의 디스크를 사용하는 것이기 때문에 IOPS가 굉장히 높다. 하지만 물리적으로 붙어있다는 것은 EC2 인스턴스가 종료되면 인스턴스 스토어도 같이 없어진다. 반면, 네트워크 기반의 스토리지는 EC2 인스턴스와 별개로 존재시킬 수 있다. 보통 EBS는 EC2 인스턴스의 생명 주기와 같이 설정되어 인스턴스 삭제 시 종료가 되는데, 이는 사실 EC2 인스턴스의 설정으로 Delete on termination가 기본으로 true인 것이다.
아무나 EC2 인스턴스에 접근할 수 없고, 이를 사용자가 설정해주어야 한다. 인스턴스에 보안 그룹을 부착해서 접근을 제어한다.
컴퓨터를 부팅할 때 기본적으로 실행시키는 스크립트를 정의할 수 있다. EC2 User Data에 스크립트를 작성하면 이를 부팅할 때 한 번만 실행한다. 원하는 소프트웨어나 파일을 최초 부팅 시 꼭 다운받을 필요가 있을 때 사용할만 하다.
보통 OS로 Linux나 Ubuntu를 설정하게 된다. 그러면 SSH로 접속을 할 수가 있는데, SSH 접속을 위해선 콘솔로 접속하거나 외부 접속 시에는 SSH 키를 사용해서 접속할 수 있다. 이를 위해 SSH Key Pair를 생성해서 이를 할당해줘야 한다. 키는 pem(OpenSSH)키나 ppk(PuTTY)가 있고, Windows 환경에서 접속 시 ppk를 받아서 PuTTY를 사용하거나 pem 키를 MobaXterm 등으로 OpenSSH로 접속해야한다. 키는 생성하고 한 번만 다운 받을 수 있을테니 신중하자.
EC2 인스턴스 네트워크로는 VPC를 설정한다. 어느 VPC의 어느 subnet에 있는지 설정해야한다. 그래서 EC2 인스턴스는 IP나 호스트를 가지고 있다. VPC의 사설 네트워크 영역인 Private IP가 기본적으로 존재하고, 인터넷에 접근시킬 수 있는 Public IP도 할당할 수 있다. Public IP를 할당하기 위해 VPC의 Public subnet에 존재해야 하며, VPC의 Public subnet에서 자동 할당을 설정할 수 있다.
컴퓨터마다 사양이 다르듯, EC2도 용도에 따라 사양을 정할 수 있다. 이러한 사양을 나타내는 것이 인스턴스 타입이다.
인스턴스 타입
인스턴스 타입은 인스턴스 패밀리 + 세대 + 사이즈로 구성되어 있다. 예를 들어, t3.small 인스턴스 타입은 t패밀리의 3세대 small 사이즈이다. 인스턴스 패밀리 타입은 아래와 같다.
범용인 General Purpose, 성능을 위한 Compute Optimized나 HPC(High Performance Computing), 인메모리 RAM 성능이 좋은 Memory Optimized, OLTP 등 디스크 I/O 성능과 스토리지 성능이 뛰어난 Storage Optimized 등이 있다. 머신러닝이나 게임, 스트리밍 등 성능이 중요하면 Compute Optimized 패밀리, 메모리 성능이 중요하다면 Memory Optimized(특히 r패밀리), 스토리지 성능이 중요하다면 Storage Optimized를 생각하면 좋다.
이러한 인스턴스 타입에 여러 세대와 사이즈가 존재한다. 보통 세대가 높아질 수록 더 많은 가상 CPU(vCPU)를 가지고, 사이즈가 높아질 수록 RAM이 높아진다. 자세한 건 AWS 공식 홈페이지를 한 번 쯤 보면 좋다.
Pricing Plan
기본적으로 AWS의 리소스 비용은 리소스를 사용하는만큼 지불한다. 하지만 경우에 따라서 적절한 Pricing Plan으로 인스턴스 비용을 절약할 수 있다.
On Demand
기본적으로는 온디맨드로 사용량 기반이다. 사용 상황이 자주 바뀌거나 얼마나 사용량이 불확실 할 때 선택하는 것이 좋다. 오랜 기간 AWS 서비스를 사용한다면 더 좋은 플랜이 있다. 원하는 시간대만 가용하고 싶다면 온디맨드가 적합하다.
Reserved
1년 이상 사용한다면 예약 인스턴스로 비용을 절감할 수 있다. 1년과 3년동안 인스턴스를 선지불로 예약할 수 있고, 길수록 할인이 더 많이 들어가서 최대 72% 할인이 적용된다. 심지어 예약 인스턴스를 사고 팔 수 있다.
1년 이상, 매일 매일 24시간 가용을 한다면 예약 플랜을 사용하는 것이 좋다. 하지만 인스턴스 타입은 미리 선택해야한다.
Saving Plan
Saving 플랜은 Reserved랑 같지만 패밀리 내에서 인스턴스 타입을 교체할 수 있다. 다양한 인스턴스 타입이 필요할 때 사용할 수 있으며, 예약된 인스턴스 사용량이 넘어가면 온디맨드 기반으로 계산된다. 최대 66%까지 할인된다.
기본적인 EC2 Instance Saving 플랜을 사용하면 교체할 수 있는 패밀리는 패밀리 종류에 한정된다. 예를 들어, t패밀리로 Saving 플랜을 구매했다면 같은 t패밀리로만 교체할 수 있다.
반면, Compute Saving 플랜을 사용하면 Compute 패밀리 종류 내의 모든 패밀리로 교체할 수 있다. 제품군을 더 자유롭게 바꾸려면 EC2 Instance Saving 플랜이 아닌 Compute Saving Plan으로 해야한다. 당연히 가격은 더 비싸지긴한다.
Spot
최대 90%까지 할인되는 플랜이다. 하지만 인스턴스가 갑자기 중단될 수 있다. 기본적으로 온디맨드나 예약을 사용하다가 추가적인 리소스를 사용하거나 개발환경 등 리소스 중단이 치명적이지 않을 때 적합하다. 혹은 배치, 데이터 분석, 이미지 프로세싱 등 아무때나 해도 상관없고 복구 가능하면서 상태 비저장인 경우 사용하는 것도 적합하다.
스팟 인스턴스는 스팟 요청으로 관리된다. one-time으로 설정된 스팟이라면 무작위로 종료되고 끝이지만, persistent로 설정되었다면 스팟이 종료되고 다음 스팟이 생성된다. 무작위로 종료되는 인터럽션이 발생된다면 인스턴스를 중단, 삭제, 혹은 hibernate를 할 지 설정할 수 있다.
스팟 요청으로 인한 스팟 인스턴스 생명 주기 관리 시, persistent를 취소하고 싶다면 먼저 request를 취소해야한다. 스팟 인스턴스를 종료하고 request를 취소한다면, 스팟 요청이 먼저 생성을 하고 취소를 하기 때문에 인스턴스가 남게된다.
스팟은 단순히 하나만 쓰지 않고, 온디맨드까지 여러개를 묶어서 사용할 수도 있다. 이를 Spot Fleets라고 하며, 용량과 비용을 지정해서 스팟 플릿이 적절히 관리해준다. 기본적인 스팟 인스턴스에 온디맨드를 추가해서 사용하게 된다. 용량이나 비용이 넘어가면 자동으로 스팟을 재실행하고, 비용 우선이나 용량 우선, 혹은 둘을 합친 price capacity optimized 등의 전략을 선택할 수 있다.
Dedicated
인스턴스, 혹은 물리적 서버 자체를 독점할 수도 있다. Dedicated Instance를 사용하면 다른 사람과는 공유가 불가능한 인스턴스를 생성할 수 있지만 물리적 서버는 공유가 될 수도 있고, 물리적 서버를 아예 할당받고 싶다면 Dedicated Host를 사용해서 리소스를 독점할 수 있다. Compliance나 Security가 중요해서 특정 라이센스 사용이나 소켓이나 물리적 코어 노출에 대한 제어가 중요하다면 적합하다. 가격은 온디맨드 + Region fee(시간당 2불)이다.
Capacity Reservation
비교적 최근에 나온 솔루션으로, 특정 AZ에 원하는 기간만큼 용량을 예약할 수 있다. 특정 AZ에 원하는 인스턴스 수를 예약해서 트래픽이 과다할 때 정의해놓은 인스턴스를 즉시 가용하며 가용성 보장을 목표할 때 유용하다.
Placement Group - 배치그룹
영어로 공부할 땐 Placement Group이지만 한국어로 시험 볼 땐 배치그룹이라고 나와서 조금 헤맸었다. 배치 그룹 내의 EC2 인스턴스 생성 시 어느 AZ에 위치시킬지를 정의할 수 있다. 인스턴스 생성 시 설정할 수 있다. 주로 여러 EC2 인스턴스끼리의 네트워크를 형성할 때 적합한 배치그룹을 선택하는 문제가 나온다.
Cluster - 클러스터 배치그룹
단일 AZ에다 생성한다. 단일 AZ인 만큼 인스턴스끼리의 통신은 저지연이고, 그렇기 때문에 성능이 좋다. 대신 안 좋은 가용성이 단점이다. 단일 AZ=낮은 가용성이다. AZ에 장애 발생 시 해당 AZ의 모든 리소스가 영향받기 때문이다.
Spread - 분산 배치그룹
다중 AZ에다 생성하고, 각 AZ 당 최대 7개의 인스턴스를 분산한다. 지연이 좀 있을 수 있지만, 다중 AZ를 활용한 만큼 고가용성, 안정성이 장점이다. AZ로 Outpost를 사용해 사용자가 가진 물리 리소스를 사용할 수도 있다.
Partition - 파티션 배치그룹
다중 AZ에다 여러 파티션을 만들어 인스턴스를 분할한다. 파티션을 랙(rack)이라고도 한다. 분산 배치는 AZ 당 최대 7개의 인스턴스를 배치하지만, 파티션 배치는 AZ 당 최대 7개의 파티션을 배치하고 해당 파티션에 많은 인스턴스를 넣을 수 있다.
파티션에 여러 인스턴스를 넣으니 AZ 당 여러 인스턴스가 존재할 수 있고, 한 AZ에는 여러 파티션이 들어가니 AZ 내의 파티션 내의 수많은 인스턴스끼리는 저지연이다. 하지만 그러한 AZ에 장애가 발생하면 어떨까? 해당 파티션들이 모두 불능이된다. 그래도 다른 AZ에 다른 파티션이 존재한다. 즉, 성능으로 따지면 클러스터 >> 파티션 >> 분산 순이고, 가용성은 분산 >> 파티션 >> 클러스터 순이다. 하지만 파티션 배치의 큰 장점이 있다면, 최대 100개까지의 인스턴스를 배치그룹이 다룰 수 있다. 즉, 대량의 인스턴스와 대량의 데이터를 다루는 빅데이터나 데이터 분산 처리 환경 등에 적합하다.
EC2 Enhanced Networking
EC2 인스턴스끼리의 네트워크 성능을 높이는 솔루션이다. 문제를 거의 본 적은 없다.
AMI - Amazon Machine Image
EC2 인스턴스를 생성하기 위해 OS 설정과 정보를 알아야한다. 그러한 정보의 초기 볼륨 템플릿을 담고 있고 하이퍼바이저가 실행할 수 있는 이미지가 AMI이다. 도커를 많이 사용해봤다면 도커 이미지라고 생각해도 좋을 것 같다.
AMI는 OS 뿐만 아니라 다른 초기 소프트웨어나 설정 등을 담을 수 있다. 마켓플레이스에서 필요한 AMI를 사용할 수도 있지만, 커스텀한 환경이 EC2 인스턴스 생성 시 즉각적으로 적용되길 원한다면 커스텀 AMI를 만들어 둘 수도 있다. 커스텀 AMI를 만드는 방법은 가용 중인 EC2 인스턴스에서 환경을 AMI로 빌드하면 된다. 이렇게 생긴 AMI를 사용해서 다른 EC2를 시작할 때 사용할 수 있다.
Region Level의 리소스이다. 만약 내가 ap-northeast-2의 EC2 인스턴스로부터 AMI를 빌드했는데, us-east-1에서 곧바로 이를 사용할 수 없다. 사용하기 위해선 원하는 Region으로 복사해야한다!
AMI에 관한 문제가 은근 나온다. AMI를 사용해서 쉽게 EC2 인스턴스를 만들어 초기화 대기 시간을 줄일 수 있는데, 최소 초기화 대기 시간을 위해선 CloudFormation이나 EBS 스냅샷를 사용하는 것이 적합하다.
초간단 요약
Amazon Machine Image AMI
- 커스텀한 게스트 OS 이미지 포함한 EC2 기초 설정 포함 이미지
- 도커 이미지 같음
- 특정 region에서 빌드 후 다른 region으로 카피 가능
- ✨카피 안 하면 못씀!!✨
- 마켓플레이스도 있음
- Process
- EC2 시작
- AMI 빌드 ⇒ EBS Snapshot도 생성
- AMI로 다른 EC2 시작 가능
- 기본 서버 리소스
- 게스트 OS 이미지 - AMI (OS 템플릿 이미지) 설정
- ✨인스턴스 타입✨ - 인스턴스 패밀리 + 세대 + 사이즈
- Computing Optimized - High Performance가 필요할 때 (ML, 스트리밍, 게임 등)
- Memory Optimized - large data sets ✨in memory✨ (웹 분산화 캐싱 등 ≠ 인메모리 캐시)
- Storage Optimized - High read and write on local 빈도가 높을 때 → (✨OLTP✨, In-memory Cache, Data warehousing, file 등)
- 네트워크 - VPC
- 스토리지 볼륨
- network attached - EBS & EFS
- ✨Instance Store✨ - 인스턴스 RAM
- ✨설정으로 Delete on termination으로 인스턴스 삭제 시 삭제 가능 (default: true)✨
- 보안 - 보안그룹
- 랜카드 - Public IP
- Bootstrap
- ✨EC2 User Data로 부팅 시 실행 script - 한 번만 실행✨
- ex) Install software, update, download common file
- 해당 인스턴스의 root user로 작동
- SSH Key Pair - pem (OpenSSH) / ppk (PuTTY)
Pricing Plan
- On Demand
- 이용 기반
- 사용 상황이 자주 바뀌거나 얼마나 사용할지 ✨불확실할 때✨
- 오래 할거면 추천 ㄴㄴ
- Reserved ✨1-3년✨ - 길수록 할인 더
- 비용 먼저 지불
- ✨72% Discount✨
- 1년 이상 & 24시간 등 지속적인 사용 시 적합
- 인스턴스 타입 미리 선택
- 사고팔기 가능
- Convertible - 인스턴스 타입 변경 가능 66% 할인
- Saving Plan ✨1-3년✨
- Reserved + 인스턴스 타입 다중 선택 ⇒ 가격만 정해놓을게
- ✨다양한 운영 서비스✨ (다양한 인스턴스 타입) 필요 시 적합
- 예약한거 넘어가면 on demand만큼
- 인스턴스 패밀리별 가격대 형성. Computing, Memory, Storage 등등.
- Spot
- 갑자기 중단될 수 있음
- ✨90% Discount✨
- 리소스 중단이 ✨치명적이지 않을 때✨ (개발환경 등)
- 무작위 중단 → 원하는 시간대에만 중단하고 싶으면? On Demand
- 그럼 어따씀? Batch, data analysis, image processing → 아무때나 해도 되는거 → 복구 가능한거. ✨상태 비저장✨
- Spot Request로 관리
- one-time or persistent ? one-time이면 종료되면 끝
- persistent면 AWS에서 새로 instance 시작해줌
- interruption 시 어떻게 할건지 - terminate / stop / hibernate
- cancel하고 싶으면? fail이나 closed가 아닐 때만 가능. relaunch를 피하고 싶으면 stop request를 먼저 cancel 후 인스턴스를 terminate
- Spot Fleets
- spot 인스턴스 + 온디맨드
- capacity와 price 제한 launch pool을 define하면 fleet이 고름
- target capacity를 넘거나 비용제한을 넘으면 relaunch
- 전략 - lowest price(비용, short) / diversified 모든 풀 전체 중 가용성(가용성, long) / capacity optimized - capacity에 최대한 맞게 가용 / price capacity optimized - 가용성, 비용 최적
- Dedicated
- ≠ Dedicated Host → 물리적 서버 예약
- 인스턴스 할당을 직접 - 물리적 자원 독점 → 인스턴스고 뭐고 알아서 관리
- 가지고 있는 SW 라이센싱 사용 원할 시
- Dedicated Instance - 다른 사람 공유 불가
- 물리적 서버에 올릴 인스턴스
- Host랑 다른 점은? Host는 네트워크 노드 독점. Instance는 그런 Host에 돌아가는 인스턴스. 같은 계정으로 다른 인스턴스 만들면 host 공유될 수도
- ✨Compliance, Security✨
- On Demand 만큼
- ✨Region fee ($2 / hr)✨
- Visibility of Sockets and physical cores - 민감!
- ≠ Dedicated Host → 물리적 서버 예약
- Capacity Reservation
- Capacity 예약 for specific AZ (원하는 기간 만큼)
- Capacity 예약 빼면 On Demand랑 같음
Placement Groups
- EC2 인스턴스가 어떻게 위치할건지? - 인스턴스 생성 시 설정
- Cluster
- ✨Single AZ✨에서 지연시간 낮은 클러스터
- 인스턴스끼리 네트워크 지연 낮음 → 성능!
- AZ 망하면 다 망함
- 빨라야하는 작업 + (복구 가능 작업) ⇒ 안정성보단 ✨High Performance✨
- Spread
- AZ 당 7개 할당
- 분산이라 안정적
- AZ당 7개라서 지연이 좀 있을 수도 있음
- ✨고가용성, 안정성 추구, 3개 중 가용성이 최고✨
- 레벨 선택 시 Outpost도 가능 → 물리적으로 가지고 있는 랙에다 이을건지!
- Partition
- 여러 AZ에 여러 파티션에 인스턴스 분할
- partition = rack → AZ 당 랙이 7개 ⇒ 파티션 망하면 그 랙에 있는 인스턴스만 망함
- 같은 리젼에 많은 AZ활용 가능 → 분산 & 인스턴스 100개까지 가능!
- ✨빅데이터, 분산 데이터 처리 환경 등등, 안정성 짱✨
EC2 Hibernate
- stop - EBS 살아있음
- terminate - EBS 죽음 → Delete on Termination?
- 근데 stop하고 부팅할 때마다 script 돌리고 OS 기다려야하나..
- Hibernate!
- RAM과 OS는 그대로 ⇒ root EBS에 작성
- process
- EC2 run
- EC2 stop start
- RAM이랑 OS는 EBS에 작성
- EC2 stopped
- EC2 restart ? RAM이랑 OS 캐싱
- Long running processing, RAM 상태 저장 하고 싶을 때
- 인스턴스 RAM이 150기가보다 작아야하고 EBS가 encrypted여야함
EC2 Enhanced Networking
- 더 고처리량, 더 저지연 =? High Performance
- Elastic Network Adapter
- Elastic Fabric Adapter - Improved ENA
'DevOps > AWS' 카테고리의 다른 글
| AWS SAA - Auto Scaling Group (0) | 2025.03.08 |
|---|---|
| AWS SAA - Elastic Load Balancer & Elastic Beanstalk (0) | 2024.11.03 |
| AWS Certified Solution Architect - Associate (AWS SAA) 시작 (2) | 2024.10.31 |
