[AWS SAA-C03] 5장 Amazon EC2 - Basics

Budgets

강의 들어가면서 예산(budgets) 설정하는 방법에 대해서도 나와서 간단히 정리해본다. 

AWS 서비스 이것저것 모르고 사용하다보면 과금 이슈가 많이 생겨서 조심해야하는데, 예산 설정 해두면 방지할 수 있다. 

예산을 설정해두면 해당 예산이 거의 소진되었을 때 알람이 온다. 기본적으로는 루트 계정에서 설정 가능하고, 루트에서 권한 주면 사용자(관리자)도 예산 확인 가능하다. 

 

Amazon EC2란

• Elastic Conpute Cloud, InfraStructure as a Service
• AWS의 많은 서비스를 포함하고 있는데, 
  • virture machine을 빌려주고 (EC2)
  • 가상 드라이브에 데이터를 저장하고 (EBS)
  • 여러 머신에 부하를 분산하고 (ELB)
  • 서비스를 자동으로 스케일링한다. (ASG : Auto Scaling Group)

EC2를 알면 클라우드의 작동 방식을 알 수 있다. 

 

EC2 크기 조정 & 구성 옵션들

• OS : Linux, Windows, Mac OS
• CPU : 컴퓨터 성능, 코어 용량
• RAM 
• Storage space
  • 네트워크 연결 : EBS & EFS
  • 하드웨어 : EC2 Instance Store
• Network card : speed of the card, 퍼블릭 ip 주소
• Firewall : security group (보안그룹)
• Bootstrap script : EC2 User Data
  • Bootstrap: 처음에 머신 작동할 때만(부팅) 실행되는 명령어 
  • EC2 User data script로 부팅할 때 뭐 실행할지 정의할 수 있음.
  • 사용자가 정의할 스크립트 예시 
    
    • 업데이트
    • sw 설치
    • 인터넷에서 파일 다운로드
    • 등등... 부팅할 때 할 작업들 자동화시킬 수 있다. -> 당연히 스크립트 길수록 부팅 시간도 길어지는거임
  • EC2 User Data Script는 root user로 실행된다 -> 즉, sudo 로 command가 실행된다. 

 

Hands-On : Linux 기반 EC2 인스턴스 실행

• 인스턴스 보안 그룹 설정 -> SSH 트래픽/ HTTPS 트래픽 / HTTPS 트래픽 허용 여부 선택
• SSH 접근 위해서는 Key pair를 발급 받아야 한다. (pem. ppk 형식)
• storage 설정 (프리티어로는 EBS 30GB 까지 제공된다)
  • default : EC2 종료시 볼륨도 함께 삭제된다. (변경 가능)
• 설정 아래 쪽에 User Data Script 작성할 수 있다. 여기에 쉘 스크립트(.sh) 작성 가능함. 
• 인스턴스 중지(stop) 후 재시작 하면 public IP는 변경된다. (이거 때메 탄력적 IP 할당 받아야함)

 

EC2 Instance Types

• EC2 Instance는 여러가지 Use Case에 맞춰 특화되어 있다. (= 여러 타입의 Instance 있음)
  • General Purpose : 범용 인스턴스
    • 웹 서버, 코드 저장소 같은 다양한 작업에 적합하다.
    • compute, memory, networking 가 밸런스 잡혀 있음. (그래서 범용으로 잘 쓰는 듯)
    • 프리티어로 제공되는 t2.micro도 범용 인스턴스다. 
  • Compute Optimized : high performance processors (고성능 프로세서)가 요구되는 compute-intensive tasks(CPU 직얍적 작업)에 최적화 
    • Batch processing workload (배치 처리)
    • Media transcoding
    • 고성능 웹서버
    • 고성능 컴퓨팅 (High Performance Computing, HPC)
    • modeling & machine learning
    • game servers
    • -> 이름이 모두 C 로 시작한다. 
  • Memory Optimized : 메모리(RAM)에서 대규모 데이터셋을 처리하는 작업(메모리 집약적 작업)에 적합하다. 
    • 고성능이 요구되는 DB
    • 분산형 웹 캐시 저장소
    • BI에 특화된 인메모리 DB
    • 대규모 비정형 데이터를 실시간으로 처리하는 application
    • -> 이름이 대부분 R 로 시작한다. (RAM의 R)
  • Accelerated Computing
  • Storage Optimized : 로컬 스토리지에서 대규모 데이터셋에 빠르고 순차적으로 read,write 하는 작업(storege-intensive task)에 적합 
    • online transaction processing (OLTP) systems
    • Relational & NoSQL DB
    • 인메모리 DB 캐시 (ex. redis)
    • Data warehousing applications
    • 분산 파일 시스템
  • HPC Optimized
  • Instanse Features
  • Measuring Instance Performance
• Instance를 부르는 네이밍 컨벤션이 있다. 
  • ex) m5.2xlarge 라면?
    • m: instance class
    • 5 : instance의 세대(generation)
    • 2xlarge: instance의 크기 (-> memory, CPU)

Security Groups

이상한 사람들이 자꾸 공격하면 안되니까, 허용한 사람만 접근하도록 해서 EC2를 보호할 수 있다.

(예전 플젝 때 스크래핑 하다가 블락 당한 기억이... )

 

EC2의 보안을 담당하는 것이 Security Group이다. 방화벽 같은 역할을 한다고 생각하면 편하다. 

 

• EC2 Intance의 Inbound/Outbound traffic을 통제한다.
• 보안 그룹은 오직 허용 규칙 (allow rules)만 포함한다. (-> 어떤 거 허용했는지 확인 가능)
• 보안 그룹 규칙은 IP 주소, 다른 보안 그룹을 참조할 수 있다.
• Port에 접근하는 것을 통제한다. 

 

아래의 보안그룹 다이어그램을 살펴보자.

Security Groups

• 인바운드 트래픽
  • Your computer : 허용된 IP, Port 이기 때문에 접근 가능
  • Other computer : 허용되지 않았기 때문에 접근 불가 (타임아웃 발생)
• 아웃바운드 트래픽
  • default로 모든 IP, Port로 보낼 수 있음. 

 

보안그룹에 대해 추가적으로 더 알아보자. 

• 보안그룹은 많은 인스턴스에 적용이 가능하다. (즉, 인스턴스와 일대일 관계가 아니다.) 
  • +) 반대로 한 인스턴스에 여러 보안 그룹을 적용할 수도 있다. 
• 보안그룹은 region과 VPC combination으로 통제한다. (즉, 다른 리전을 쓰게 되면 보안 그룹, VPC를 새로 생성해야한다.)
• SSH access를 위해 별도의 보안 그룹을 두는 것이 좋다. (왜냐하면 SSH access는 복잡하기 때문에, 따로 빼서 관리하는게 낫기 때문)
• 만약 애플리케이션에 접속하는데 계속 타임아웃 나면, 거의 보안그룹 이슈일 것임.
  • connection refused 에러면 애플리케이션 에러일 것임.
• 인바운드 트래픽은 default로 다 block임
• 아웃바운드 트래픽은 default로 다 autorised임

 

보안 그룹이 다른 보안 그룹을 참조할 수도 있다고 했다. 어떻게 동작할지 다이어그램을 통해 알아보자. 

다른 보안그룹을 참조한 예시

다이어그램을 보면 Security Group 1이 그룹 1,2를 참조하고 있다(허용함)

허용된 보안 그룹을 가지고 있는(?) EC2에서 인바운드로 접근하면 접근 가능이지만, 

허용되지 않은 Security Group3을 가진 EC2는 인바운드로 접근할 수 없다. (타임아웃)

 

알아야하는 Port 번호들

• 22 = SSH (Secure Shell) - log into a Linux instance
• 21 = FTP (File Transfer Protocol) – upload files into a file share
• 22 = SFTP (Secure File Transfer Protocol) – upload files using SSH
• 80 = HTTP – access unsecured websites
• 443 = HTTPS – access secured websites
• 3389 = RDP (Remote Desktop Protocol) – log into a Windows instance

그리고 SSH를 많이 사용할텐데, OS마다 사용 못하는 경우도 있다고 한다. 

OS별 SSH 사용 가능 여부

Window 10버전 미만만 putty사용하고, 그냥 SSH 사용하면 될 것 같다.

 

EC2 Instance Connect

• 브라우저를 기반으로 EC2 Intance에 접속한다.
• 이전에는 SSH 연결하려면 key를 다운로드 받아야했지만, 이 연결방법으로는 key를 다운받을 필요가 없다. (키 관리할 필요 x) -> key를 알아서 관리함. 
• Amazon Linux2만 동작한다. (AMI 얘기하는듯? )
• 포트 22번은 항상 열어둬야 한다. 
  • 왜냐하면 EC2 Instance connect도 SSH를 기반으로 하기 때문이다. -> 즉, security group의 inbound roles에서 22번 포트(SSH)를 닫아두면 EC2 connect로 접근 못한다. 

 

+ ) 실습 하면서 같이 나온 내용

 

터미널 내에서 aws iam list-users 와 같은 명령어를 쓸 때, 해당 명령어를 쓸 권한이 있는지 확인하기 위해 access key값 같은 민감한 값을 터미널에 입력하라고 한다. (aws configure) 

하지만 터미널에 값을 직접 입력하면 위험하다. -> "IAM Roles"을 사용하는 것이 안전하다. -> ex) EC2가 가지고 있는 DemoRoleEC2 Role이 있다고 하자. 해당 Role에 IAMReadOnlyAccess(Policy)를 연결해준다. -> 이런 방식으로 EC2 인스턴스에 aws 자격 증명을 제공할 수 있다. 

 

EC2 Instances Purchasing Options

인스턴스에도 다양한 구매 옵션들이 있다. 이런 옵션들을 사용하면 인스턴스를 훨씬 저렴한 가격으로 이용할 수 있다. 

진작 알았으면 좋았을 것 같다. 

• On-Demand Instances : short workloads, 비용 예측 가능, 초단위 지불
  • 사용한 대로 지불하며, linux or windows는 초단위로 청구하고 다른 os는 1시간 단위로 청구
  • 가격 비싸고 선결제 안 받음
  • 긴 기간 사용 X
  • => 짧은 기간쓸 예정이며, 무중단 워크로드 필요한 경우 추천
• Reserved (1 & 3 years)
  • Reserved Instances : long workloads
    • 가격: 온디멘드에 비해 최대 72% 저렴함. 
    • 인스턴스 속성 지정 : 인스턴스 유형, region, OS, 테넌시(인스턴스가 다른 사용자와 하드웨어 공유 할지 말지) 등의 속성을 지정하여 예약 가능함.
    • 예약 기간: 1년 or 3년 (3년이 할인 혜택 더 크다.)
    • 지불 옵션 : 선결제, 부분 선결제, 선불 x (-> 다 가능하다)
    • 예약 인스턴스 범위 : Regional or Nonal(AZ) -> 특정 리전 내의 모든 AZ를 범위로 (regional) 혹은 특정 AZ만을 범위로 (Zonal)
    • 마켓 플레이스에서 예약 인스턴스를 구매, 판매 가능
    • => 안정적인 사용량을 보이는 애플리케이션(ex. DB) 에 추천 (긴 기간동안 예약하기 위해 사용량이 얼마나 될지 예측가능해야 예약할 수 있으니까 안정적 사용량)
  • Convertible Reserved Instances : long workloads, instance가 유연성 있어야 함. 
    • EC2 인스턴스 유형, 인스턴스 패밀리, OS, scope, tenency 등의 관련한 옵션을 다 변경할 수 있다.
    • 가격: 최대 66% 저렴 -> 유연성 있기에 할인율은 더 낮음. 
• Savings Plans (1 & 3 years) : long workload, 사용량 정해둠
  • 가격: 온디맨드 대비 최대 72% 저렴 (-> 예약 인스턴스랑 동일함)
  • 사용량 약정 : 1년 or 3년 동안의 특정 사용량(1시간 당 10달러) 를 정해둠. (이정도만 쓸거야 ~)
  • 초과 사용량: 약정 사용량을 초과하는 경우, 온디맨드 가격으로 청구
  • 제약 사항: 특정 인스턴스 패밀리와 AWS 리전에 고정된다. ( 예: us-east-1 리전의 M5 패밀리)
  • 유연성 : 인스턴스 크기(m5.xlarge, m5.2xlarge), OS(Linux, Windows), 테넌시(Host, Dedicated, Default) 는 변경 가능하다.
• Spot Instances – short workloads, cheap, 인스턴스 사라질 수 있음 (안전성 낮음)
  • 가격: 온디맨드 대비 최대 90% 저렴 -> 가장 저렴하다. (위험하니까 싸다)
  • 인스턴스 종료 위험 : 스팟 가격 > 사용자가 설정한 최대 가격일 때 인스턴스가 종료될 수 있다.
  • 적합한 사례 : 장애에 대한 회복력 있는 작업 (ex. 배치 작업, 데이터 분석, 이미지 처리, 분산 작업 등)
  • 부적합한 사례: 중단 시 큰 문제가 날 수 있는 작업 (ex. DB, 웹서버 등)
• Dedicated Hosts – 고객에게 물리적 서버 전체 할당하여 ec2 인스턴스 용량을 독점으로 사용하도록 함.
  • 전용 물리 서버 : 고객만을 위한 전용 물리 서버 제공
  • 제어: 고객이 하드웨어 구성을 제어할 수 있다. 
  • 적합한 사례 : compliance와 licenses가 있는 경우 -> 즉, 물리적 서버를 독점으로 사용하여 다른 고객과 리소스를 공유하지 않기(데이터 보안 준수)나 다른 소프트웨어 라이선스를 활용하기 위해 필요할 수 있다. 
    • ex) 규정 준수 혹은 컴플라이언스 요구 사항이 엄격한 기업: 금융 기관은 데이터를 전용 서버에 저장해야하는 컴플라이언스가 있을 수 있다. 이 때 Dedicated Hosts로 해당 요구사항을 충족할 수 있다.
    • ex) 복잡한 라이선스 모델을 가진 소프트웨어
  • 가격: 
    • On-demand : 활성화된 dedicated hosts에 대해 초당 요금 지불
    • Reserved : 1년 or 3년 (선불, 부분 선불, 선불 x) 
    • 가장 비싼 옵션이다. 
• Dedicated Instances – 다른 사람와 하드웨어 공유 안함.
  • 전용 하드 웨어: 고객의 인스턴스는 전용 하드웨어에서 실행된다.
  • 계정 내 공유 가능: 동일한 계정 내 다른 인스턴스와 하드웨어를 공유할 수 있다.
  • 인스턴스 배치 제어 불가 : 고객은 인스턴스 배치를 제어할 수 없다. 인스턴스를 중지/시작한 후 하드웨어를 이동할 수 있다. -> (차이점) Dedicated Hosts 만큼의 제어 권한이 없다. 
  • Pros 
    • 성능 향상, 보안 강화 : 하드웨어 공유하지 않기에 성능, 보안 강화
  • 가격: dedicated hosts 보다는 저렴하다.

Dedicated Hosts, Instances 정리표

• Capacity Reservations – 특정 기간동안 특정 AZ에 용량 예약함. 
  • 특정 AZ 용량 예약 : 원하는 기간 동안 특정 AZ에서 온디맨드 인스턴스 용량을 예약함. 
  • 항상 사용 가능 : 예약된 EC2 용량은 필요할 때마다 항상 접근 가능하다.
  • 시간 약정 없음 : 얼마나 예약할지 기간에 대한 제한이 없어서, 언제든지 생성/ 취소 가능
  • 할인 없음: 용량 예약하는 건 할인 없음 (-> 뭐 말이 예약이지... 용량 계속 확보해두는건 똑같으니까?)
    • +) 예약만 하고 인스턴스 실행 안하더라도 똑같이 요금은 부과된다.
  • 적합한 사례 : 단기간, 중단 없는 작업, 특정 AZ에서 실행되어야하는 작업

 

너무... 옵션이 너무 길다... 돈 아끼기 참 힘들다....

 

여튼 너무 길어서 알기 힘드니까 강의에서도 리조트에 비유해서 옵션을 다시 설명해줬다. 

 

쉽게 보는 EC2 options

마치 호텔을 예약하는 것처럼, AWS EC2 인스턴스를 사용하는 데에도 다양한 구매 옵션이 있고, 각 옵션은 장단점이 있으므로, 사용 목적과 예산에 따라 가장 적합한 옵션을 선택해야 한다.

1. 온디맨드 (On Demand):

• 비유: 언제든지 리조트에 와서 머물 수 있으며, 풀 프라이스를 지불합니다.
• 설명: 필요할 때마다 EC2 인스턴스를 사용하고, 사용한 시간만큼 요금을 지불합니다. 가장 유연하지만, 할인 혜택이 없습니다.
• 적합한 경우: 단기간 사용, 예측 불가능한 작업 부하, 유연성이 중요한 경우

2. 예약 (Reserved):

• 비유: 미리 계획을 세우고 장기간 머물 경우, 할인 혜택을 받을 수 있습니다.
• 설명: 특정 인스턴스 유형과 리전을 미리 예약하고, 장기간 사용할 경우 할인 혜택을 받습니다.
• 적합한 경우: 장기간 사용, 예측 가능한 작업 부하, 비용 절감이 중요한 경우

 

3. 세이빙 플랜 (Savings Plans):

• 비유: 특정 기간 동안 시간당 요금을 지불하고, 원하는 객실 유형 (킹, 스위트, 오션뷰 등)에 머물 수 있습니다.
• 설명: 특정 기간 동안 특정 사용량을 약정하고, 할인 혜택을 받습니다. 인스턴스 유형과 리전을 자유롭게 선택할 수 있습니다.
• 적합한 경우: 장기간 사용, 예측 가능한 작업 부하, 유연성과 비용 절감이 모두 중요한 경우

4. 스팟 인스턴스 (Spot Instances):

• 비유: 호텔에서 빈 방을 경매로 판매하고, 가장 높은 가격을 제시한 사람이 방을 차지합니다. 언제든지 쫓겨날 수 있습니다.
• 설명: AWS에서 빈 용량을 경매로 판매하며, 가장 높은 가격을 제시한 사람이 인스턴스를 사용합니다. 가격 변동으로 인해 인스턴스가 종료될 수 있습니다.
• 적합한 경우: 장애에 강인하고, 유연한 시작 및 종료 시간을 가진 작업 부하, 극단적인 비용 절감이 필요한 경우

5. 전용 호스트 (Dedicated Hosts):

• 비유: 리조트 건물 전체를 예약합니다.
• 설명: 고객에게 물리적 서버 전체를 할당하여 독점적으로 사용할 수 있도록 합니다. 컴플라이언스 및 라이선스 문제 해결에 유리합니다.
• 적합한 경우: 컴플라이언스 요구 사항이 엄격하거나, 기존 서버 바인딩 소프트웨어 라이선스를 활용해야 하는 경우

6. 용량 예약 (Capacity Reservations):

• 비유: 특정 기간 동안 방을 예약하지만, 실제로 머물지 않더라도 요금을 지불합니다.
• 설명: 특정 AZ에서 온디맨드 인스턴스 용량을 특정 기간 동안 예약합니다. 할인 혜택은 없지만, 항상 용량을 확보할 수 있습니다.
• 적합한 경우: 특정 AZ에서 실행되어야 하고, 중단 없이 지속적으로 실행되는 작업에 적합합니다.

요약하면 -> 

가장 유연하고 비용이 높음: 온디맨드
장기간 사용 시 할인 혜택: 예약
유연성과 비용 절감 모두 중요: 세이빙 플랜
극단적인 비용 절감, 장애 허용: 스팟 인스턴스
컴플라이언스 및 라이선스 문제 해결: 전용 호스트
특정 AZ 용량 확보, 안정성: 용량 예약

 

EC2 Spot Instance

위에 나온 옵션 중 스팟 인스턴스가 꽤 특이하다고 생각했는데, 강의에서 스팟 인스턴스에 대해 더 자세히 다뤘다. 

 

• 가격: 온디맨드 대비 최대 90% 저렴, 수요와 공급에 따라 시간 단위로 변동
• 최대 스팟 가격: 스팟 가격 > 사용자가 설정한 최대 가격인 경우, 인스턴스는 2분의 기간 후 stop or terminate 된다. (택 1)  
• Spot Block 전략 : 인스턴스 중단되는 것이 싫다면 특정 기간(1 ~ 6시간 한정) 동안 스팟인스턴스를 중단 없이 사용할 수 있도록 설정한다. -> 아주 드물게, 그럼에도 회수될 때 있다. 
• 적합한 사례 
  • 배치 작업 마냥 한 번에 처리하는 작업일 때
  • 장애에 유연할 때 : 작업 중단 허용되고 재시작 가능한 작업
  • 작업 시작, 종료 시간이 유연할 때
• 부적합 사례
  • 중요한 작업 : DB, 웹서버 마냥 가동 중단되면 큰 문제나는 작업
  • 시간에 민감한 작업: 작업 완료 시간 중요한 작업

Spot Instance Price

 

위의 표에서, 유저가 정한 max price가 검정 점선이라면, 검정 점선을 넘을 때의 경우에는 인스턴스가 종료된다.

그리고 제일 위 쪽에 있는 On-demand와 비교해보면 훨씬 저렴하다. 

( => 최대 가격을 안전하게 더 높게 잡더라도 온디맨드보단 훨씬 싸게 쓸듯,,, 근데 또 그러면 다들 spot을 하지 않을까? )

 

Spot Instance 작동 방식

 

EC2 스팟 인스턴스를 생성할 때에 최대 가격, 인스턴스 수, 유효기간, request type 등을 설정할 수 있다. 

이 때, request type은 두가지 종류가 있는데, 

• one-time : 일회성 요청 -> 한번 요청(ec2 생성) 보냈으면 해당 요청을 지운다. 
• persistent : 영구 요청 -> 여러 이슈로 인스턴스 중단되었으면 다시 요청(ec2 생성)보낸다.

persistent 로 생성한 스팟 인스턴스를 지우려면

1. 스팟 요청 취소 2. 스팟 인스턴스 종료 순서로 해야한다. 2번부터 하게되면 계속 요청 보내서 재생성 하게 된다. 

 

또, 요청을 취소하려면 요청 상태가 open, active, disabled 상태 여야 한다. 스팟 인스턴스 요청을 취소하는 것은 인스턴스를 종료하는 것이 아님. 

 

Spot Fleets

• Spot Fleets = 여러 개의 스팟 인스턴스 + On-demand 인스턴스(Optional)
• 목표 용량 및 가격 제약 조건 : 사용자는 목표 용량, 최대 가격 설정하여서 spot fleet이 조건에 맞는 인스턴스를 요청하도록 한다. 
  • 사용자는 인스턴스 타입(m5.large), OS, AZ 등의 launch poll을 설정할 수 있다. (-> 설정 많을 수록 조건에 맞는 spot fleets이 줄어들겠지)
  • multiple launch poll : 하나의 스팟 플릿에 여러 개의 런치 풀을 설정하여 스팟 플릿이 다양한 옵션에서 선택하도록 한다. 
• 용량 혹은 최대 비용 도달 시 종료: 스팟 플릿은 목표 용량, 최대 비용을 초과할 경우 인스턴스 요청을 중지한다.
• 스팟 인스턴스 할당 전략
  • lowestPrice : 가장 낮은 가격의 런치풀에서 인스턴스 요청 (비용 최적화, 단기작업 적합)
  • diversified : 모든 런치 풀에 인스턴스를 분산 (분산되기에 가용성 o, 장기작업 적합)
  • capacityOptimized : 인스턴스 수에 가장 적합한 용량을 제공하는 런치 풀 선택
  • priceCapacityOptimized (권장) : 가용 용량이 가장 높은 런치풀을 우선 선택, 그 중에서 가장 낮은 가격의 런치풀 선택 (대부분의 작업에서 가장 적합)
• 스팟 플릿은 자동으로 적은 가격에 스팟 인스턴스를 사용할 수 있도록 해준다. ( ???: 필요한 용량이랑 예산 알려줄테니까 알아서 해줘)
• 스팟 인스턴스와의 차이점
  • 간단한 스팟 인스턴스 요청 : 원하는 인스턴스 유형, AZ가 명확한 경우
  • 스팟 플릿 요청 : 조건 (낮은 가격 등)을 만족하는 모든 인스턴스 유형, AZ를 알려줘 !