EC2 소개

• 클라우드 컴퓨팅 : 컴퓨팅 빌려 쓰기
• EC2 : 컴퓨팅을 빌려 쓰는 서비스

EC2의 장점

• 온디맨드 모델에서는 가격이 초 단위로 결정
  • 필요한 만큼 쓸 수 있다.
• 서비스 요금을 미리 약정하거나 선입금이 필요 없음(약정을 한다면 더욱 싸게 이용 가능)
• 몇 분이면 전 세계에 인스턴스 수백여대 구축 가능
• 머신러닝, 웹서버, 게임서버, 이미지처리 등 다양한 용도에 최적화된 서버 구성 가능
• 다양한 과금 모델 사용 가능
• 오토스케일링, ELB, CloudWatch 등 다양한 서비스와 연동 가능
  • 서비스들 끼리 어떻게 연동되는지가 핵심

EC2의 구조

EC2 인스턴스란?

• EC2에서 컴퓨팅을 담당
  • 다양한 유형과 크기로 구성
  • 저장을 담당하는 EBS와 네트워크로 연결
• 저장 방법에 따라 두 가지로 분류
  • EBS 연동
  • 인스턴스 스토어
• 하나의 가용영역(AZ)에 존재

인스턴스 유형

인스턴스 유형(패밀리)

• 인스턴스의 역할에 따라 CPU, 메모리, 스토리지, 네트워크 등을 조합한 구성
• 각 인스턴스 유형 별로 사용 목적에 따라 최적화
  • ex) 메모리 위주, CPU위주, 그래픽카드 위주 등등
• 유형 별로 이름 존재
  • ex) t유형, m유형, inf유형 등
  • 같은 유형의 인스턴스들을 인스턴스 패밀리라 부름
• 타입 별 세대별로 숫자 부여
  • ex) m5= m인스턴스의 5번째 세대
• 아키텍쳐 및 프로세서/추가기술에 따라 접미사
  • ex) c7gn = c 인스턴스 중 AWS Graviton 프로세스 사용(g) + Network Optimized(n)

인스턴스 크기

• 같은 인스턴스 패밀리에서 다양한 크기가 준재
• 인스턴스의 cpu갯수, 메모리 크기, 성능 등으로 크기 결정
• 크기가 클 수록
  • 더 많은 메모리
  • 더 많은 CPU
  • 더 많은 네트워크 대역폭
  • EBS와의 통신 가능한 대역폭

Amazon EBS

EBS란?

• 가상 하드드라이브
• EC2 인스턴스가 종료 되어도 계속 유지 가능
  • 루트 볼륨으로 사용시 EC2가 종료되면 같이 삭제됨
  • 단 설정을 통해 EBS만 따로 존속 가능
• 용량을 범위에 따라 자유롭게 설정 가능
• 특수하게 하나의 EBS를 여러 EC2 장착 가능한 경우도 있음(EBS Multi Attatch)
• EC2 인스턴스와 같은 가용영역에 존재
• 가용영역 내에 분산 저장

EBS의 유형

• 범용(General Purpose) : SSD
• 프로비저닝 된 IOPS (Provisioned IOPS) : SSD
  • 적은 용량, 빠르고 비쌈
• 쓰루풋 최적화(Throughput Optimized HDD) : HDD
  • 대용량의 데이터 저장, 느림
• 콜드 HDD (SC) : HDD
  • 파일 저장소, 잘 쓰지않는 데이터, 쌈
• 마그네틱 (Standard) : HDD
  • 백업 저장소, 매우 쌈

Snapshot

• 스냅샷 : EBS의 특정 시점을 저장한 이미지
  • 이후 EBS로 다시 복구 가능
  • EBS의 백업 용도로 활용 가능
• 증분식 : 바뀐 부분 만 저장
  • 즉, 100gb 볼륨의 스냅샷을 5번 찍어도 500gb가 아닌 100gb+4번의 변경 부분만 저장
• S3에 저장
• Data Lifecycle Manager/ AWS Backup등으로 자동화 해서 생성 가능
• 기타 여러 기능
  • 암호화
  • 아카이브
  • 공유

AMI(Amazon Machine Image)

• EC2 인스턴스를 실행하기 위해 필요한 정보를 모은 템플릿
• 구성
  • 1개 이상의 EBS 스냅샷
  • 사용 권한
  • 블록 디바이스 맵핑(볼륨 정보)
• 필요에 따라 Private으로 가지고 있거다 Public 공개 가능

인스턴스 저장 유형에 따른 AMI의 생성 방법

• EBS : 스냅샷을 기반으로 루트 디바이스 생성
• 인스턴스 저장 : S3에 저장된 템플릿을 기반으로 생성
  

AWS 가격 정책

• 미리 내지 않고, 사용한 만큼 내고 (On-Demand)
• 많이 쓸수록 적게 내고
• 예약할수록 더 적게 낸다

EC2의 요금 구성

• 인스턴스 요금
• 데이터 전송
• Public IPv4 Ip
• 연동 서비스
  • ELB, CloudWatch, EBS 등

EC2 요금 모델

• On-Demand : 사용한 시간 만큼만 요금 지불
• Spot Instances : 남는 인스턴스를 저렴하게 사용
• Reserved Instances : 인스턴스 사용 기간을 약정
• Dedicated : 물리적인 전용 인스턴스 임대
  • Dedicated Instance/Dedicated Host
• Savings Plan : AWS의 컴퓨팅 사용량을 약정

보안 그룹

• EC2의 방화벽 역할을 하는 서비스
• Port 허용
  • 기본적으로 모든 포트는 비활성화
  • 선택적으로 트래픽이 지나갈 수 있는 Port와 Source를 설정 가능
  • Deny는 불가능
• 인스턴스 단위
  • 하나의 인스턴스에 하나 이상의 보안 그룹 설정 가능
  • 인스턴스에 여러 보안 그룹이 적용될 경우 모든 보안 그룹의 규칙을 적용 받음

EC2의 생명 주기

중지

• 중지 중에는 인스턴스 요금 미 청구
• 단, EBS요금, 다른 구성요소는 청구
• 중지 후 재시작시 퍼블릭 IP 변경

재부팅

• 퍼블릭 IP 변동 없음

최대 절전모드

• 메모리 내용을 보존해서 재시작시 중단지점에서 시작할 수 있는 정지모드

ENI(Elastic Network Interface)

• EC2의 가상의 랜카드
• IP주소와 Mac 주소를 보유
• 하나의 인스턴스에 여러개의 ENI를 연동 가능
  • 하나의 인스턴스가 한 개 이상의 아이피를 보유 가능
• 인스턴스 유형 및 사이즈에 따라 최대 보유 가능한 IP주소가 변동
• 내부적으로는 보안 그룹은 ENI에 부착
• 기본적으로 Private IP주소와 Private DNS 보유

Elastic IP

• EC2의 퍼블릭 IP를 고정해주는 서비스
  • 즉 인스턴스를 중지->재시작 해도 고정적인 IP를 확보 가능
• EC2이외에 다른 서비스에도 사용
• 내가 보유한 IP주소를 AWS에서 사용 가능
• 리전 단위
• 연결하지 않아도 보유하기만 해도 비용 발생

EC2 User Data

• EC2 인스턴스의 최초 실행 시 지정한 스크립트 실행 가능
  • 별도 설정을 통해서 재부팅 마다 실행하도록 설정 가능
• 두 가지 모드
  • Shell Script
  • cloud-init : 리눅스 이미지의 부트스트래핑을 위한 오픈소스 어플리케이션
• 주요 사용 사례
  • EC2 인스턴스 설정
  • 외부 패키지 다운로드
  • 설치 어플리케이션 실행
  • 기타 EC2 실행 시 필요한 동장
    

Amazon EC2 Instance Metadata

• EC2 인스턴스의 속성 및 정보 데이터
  • AMI ID, IPv4/IPv6주소, EBS 맵핑, 보안 그룹 연동상황, IAM 역할 연동 등
• 실행중인 EC2 인스턴스의 메타데이터 IMDS로 조회 가능
  • HTTP Endpoint 지원
  • IP주소 : 169.254.169.254, fd00:ec2::254
  • 두 가지 모드
    • IMDS v1 : Request/Response 기반
    • IMDS v2 : 세션 기반(default)
• 주요 사용 사례
  • 인스턴스 별 설정, IAM 임시 자격증명 조회 등
• EC2 실행 시 메타데이터 엑세스 가능 여부 설정 가능
  • 기본 활성화
  • 버전 선택 가능
• 무료

Instance Metadata Service V1

• 별도의 보안 인증이 필요 없는 Request/Response 기반
  • Link Local IP를 사용하기 때문에 해당 EC2 인스턴스에서만 요청 가능
• CloudWatch Metric을 활용해서 조회 횟수 기록 가능
• ex) 인스턴스 이름 가져오기 curl http://169.254.169.254/latest/meta-data/tags/instance/Name

Instance Metadata Service V2

• 보안 토큰을 발급받아 요청할 떄 마다 토큰을 사용해 인증하는 세션 방식
  • 토큰의 유효기간은 1초에서 최대 6시간
• IMDSv1보다 높은 보안 수준 제공
  • IAM 정책 등을 활용하여 EC2 인스턴스가 IMDS v2를 사용하도록 강제 가능
  • 활용 시 EC2 인스턴스 내부의 AWS CLI, SDK등이 IMDSv2를 지원하는 최신 버전임을 확인 필요

EC2에 권한 부여

IAM 자격 증명을 등록

• IAM사용자를 생성하고 IAM 자격증명을 발급받아 EC2에 등록
• AWS Configure를 통해 자격 증명을 파일로 등록(~/.aws/credentials)
• 관리가 어렵고 바꾸기 힘듦
  • ex) EC2 100대의 자격증명을 교체해야 한다면?

IAM 역할을 부여

• 권한이 부여된 IAM 역할을 만들고 EC2에 부여
• 관리가 쉽고 교체가 쉬움
• 내부적으로 지속적으로 자격증명을 변경
  • 뛰어난 보안성
    

EC2 Auto Scaling

정확한 수의 EC2 인스턴스를 보유하도록 보장

• 그룹의 최소 인스턴스 숫자 및 최대 인스턴스 숫자
  • 최소 숫자 이하로 내려가지 않도록 인스턴스 숫자를 유지
  • 최대 숫자 이상 늘어나지 않도록 인스턴스 숫자 유지

다양한 스케일링 정책 적용

• 다양한 스케일링 정책
  • ex)CPU의 부하에 따라 인스턴스 크기를 늘리기
  • ex)특정 시간에 인스턴스 개수 늘리고 다른 시간에 줄이기

시작 구성/ 시작 템플릿

• EC2의 유형, 크기
• AMI, 보안 그룹, Key, IAM 역할
• 유저 데이터
• 기타 설정

모니터링

• ex) CPU 점유율이 일정 %을 넘어 섰을때 추가로 실행
• ex) 2개 이상이 필요한 스택에서 EC2 하나가 죽었을 때

설정

• 최대/최소/원하는 인스턴스 숫자
• ELB와 연동 등

기타 설정 사항

• 종료 정책 : 인스턴스 숫자를 줄일 경우 어떤 순서로 인스턴스를 종료시킬지에 관한 정책
  • 기본:
    • 인스턴스가 2개 이상인 가용영역의 인스턴스에서
    • 가장 오래된 시작 템플릿
    • 모두 같은 시작 템플릿이라면 다음 과금 시간에 가장 가까운 인스턴스 종료
  • 커스텀:
    • 가장 예전 시작 템플릿부터
    • 가장 오래된 인스턴스부터
    • 가장 최근 인스턴스부터 등
• Lambda를 활용해서 커스텀 정책 적용 가능

Elastic Load Balancer

• 다수의 EC2에 트래픽을 분산 시켜주는 서비스
• 총 4가지 종류
  • Application Load Balancer
  • Network Load Balancer
  • Classic Load Balancer
  • Gateway Load Balancer
• Health Check
• Autoscaling과 연동 가능
• 지속적으로 IP 주소가 바뀌며 IP 고정 불가능 : 항상 도메인 기반으로 사용

Application Load Balancer

• 똑똑하다
• OSI Moder Layer 7
• 트래픽을 모니터링 하여 라우팅 가능
  • ex) image.sample.com > 이미지 서버로, web.sample.com > 웹 서버로 트래픽 분산

Network Load Balancer

• 빠르다
• OSI Model Layer 4
• TCP, UDP 기반 빠른 트래픽 분산
• Elastic IP 할당 가능

Classic Load Balancer

• 옛날거
• 요즘 잘 사용하지 않음

Gateway Load Balancer

• 먼저 트래픽을 체크함
• OSI Layer 3
• 가상 어플라이언스 배포/확장 관리를 위한 서비스

대상 그룹

• ELB가 라우팅 할 대상의 집합
• 구성
  • 대상 종류
    • Instance
    • IP
    • Lambda
    • ALB
  • 프로토콜(HTTP,HTTPS,gRPC,TCP 등)
  • 기타 설정
    - 트래픽 분산 알고리즘, 고정 세션 등
    

리스너

• ALB로 들어오는 요청을 처리하는 주체
  • 들어오는 트래픽의 프로토콜 + 포트 단위
• 규칙으로 ALB에서 어떤 요청을 받을지, 요청을 어떻게 어디로 처리할지 결정
• 규칙을 활용해 다양한 조건에 따라 트래픽 배분 가능
  • 활용 가능한 조건 : Header, QueryString, source IP, Method 등
• 들어온 트래픽 처리 방식 : forward, redirect, fixed-response, cognito 인증 등

ELB의 비용

• 기본적으로 시간당 프로비전 비용
• 추가적으로 트래픽/사용량 비용
• 프로비전 시 시간당 비용 청구 (서울리전 기준)
  • 기본 $0.0225/시간
  • $0.008/LCU-시간
• LCU : ALB가 트래픽을 처리하는 단위
  • 1LCU는
    • 25개의 새로운 컨넥션/초
    • 3000/분 연결 숫자 or 1500/분 TLS
    • 1GB/시간 의 EC2, 컨테이너, IP주소, 혹은 0.4GB/시간 의 Lambda 함수 트래픽
    • 1000/ 초 룰 평가(10개 무료)
  • 이 중 가장 높게 측정된 것 기준으로 계산

NLB의 비용

• 프로비전 시 시간당 비용 청구 (서울리전 기준)
  • $0.0225/시간
  • $0.006/NLCU
• NLCU : NLB가 트래픽을 처리하는 단위
  • 1NLCU
    • 800ㅅ TCP 연결, 400UDP/초
    • 100,000 TCP 초당 연결유지, 50,000 UDP
    • 1GB / 시간 EC2, 컨테이너, IP, ALB 대상 트래픽

Amazon CloudWatch 와 EC2

• AWS에서 제공하는 AWS 서비스 / 어플리케이션의 모니터링 서비스
• EC2 를 포함한 AWS의 다양한 서비스에 기본적인 모니터링을 지원
• EC2의 주요 지표
  • CPU 사용량
  • 디스크
  • 네트워크
  • CPU Credit 관련 지표
  • 상태 관련
• 이외에 커스텀 지표 활용 가능
• EC2의 경우 별도로 활성화 불필요 / 무료
• 기본 5분 단위 (상태 확인만 1분 단위)
• EC2 세부 모니터링
  • 모든 지표에 1분단위 모니터링
  • 메트릭 별로 비용 발생, 단 저장 비용은 없음
  • 별도로 활성화 필요

Amazon CloudWatch 와 Autoscale

• Autoscale 지표
  • 지표의 별도로 활성화 필요
• 주요 지표
  • 용량
  • 인스턴스 상태
  • 기타 관리중인 인스턴스 모두의 통합 지표 제공
• 이외에 내부적으로 Autoscaling의 알람, 타켓 추적 스케일링 정책등은 CloudWatch 기반

Amazon CloudWatch 와 ELB

• ELB 지표는 기본적으로 활성화
• 주요 지표
  • 요청/연결
  • Status Code별 Count(3xx,4xx,5xx)
  • IPv6 처리
  • 네트워크 지표 (처리된 네트워크 트래픽)

AutoScale Scaling 정책

• Autoscale에서 관리하고 있는 인스턴스의 숫자를 조절하는 방식
• 크게 네 가지 분류
  • 수동 스케일 : 수동으로 직접 인스턴스 숫자를 증감
  • 스케쥴기반 스케일 : 특정 시점에 인스턴스 숫자를 증감
    • 주로 예측 가능한 시점의 부하 처리 목적으로 활용
  • 동적 스케일 : 특정 기준을 두고 기준치에 따라 인스턴스 숫자를 증감
    • ex) CPU사용률 기반, 요청 숫자 기반, 판매량 기반 등
  • 예측기반 스케일 : 과거의 기록의 패턴을 기반으로 수요량을 예측해서 인스턴스 숫자를 증감

수동 스케일

• 수동으로 인스턴스 숫자를 조절
  • 주로 개발 환경 혹은 다른 정책을 적용하기 전 사전 테스트 용도로 활용
• 되도록이면 다른 스케일 정책을 비활성화 시킨 후 적용 추천

스케쥴기반 스케일

• 예측 가능한 시점의 변동사항에 대비해서 인스턴스 숫자를 조절하는 방식

• 적용 방식

  • 특정 시점을 정해서 해당시점 or Cron으로 표현하는 반복 시점에
  • 범위 지정
    • 지정한 범위보다 인스턴스가 작다면 Scale Out
    • 지정한 범위보다 인스턴스가 크다면 Scale In

  

Cron Expression

• 특정 시간의 주기를 표현하기 위한 표현식
• 1분 단위가 최소 단위
  

동적 스케일

• 지표에 반응해서 인스턴스 숫자를 조절하는 방식
  • 주로 CloudWatch의 지표 활용
  • 혹은 자신만의 기준으로 스케일링 정책 조절 가능
• 주로 Autoscale에서 지원하는 추적 조정 정책 활용
  • 내부적으로 CloudWatch Alarm을 생성해서 Alarm에 반응하여 자동으로 증감
  • 지표 증감에 따라 얼마나 민감하게 반응할 것인지 결정 가능
• 필요시 커스텀 로직을 활용해서 Autoscale의 증감을 수동으로 조절 가능
  

예측기반 스케일

• 사용 패턴의 히스토리를 기반으로 인스턴스 수요량을 예측하여 인스턴스 숫자를 조절하는 방식
  • 주로 반복되는 패턴이 명확한 경우, 혹은 인스턴스 준비가 오래 걸리는 경우 사용
  • ex) 매일 오후 2시에 레이드 이벤트가 열리는 게임 서비스의 서버
• CloudWatch 지표를 14일간 분석하여 패턴을 만들고 다음 48시간의 사용 패턴을 분석
• 수요량에 따라 증가만 가능
  • 즉, 인스턴스 숫자를 감소시키려면 동적 스케일링 정책 필요
• 주의사항
  • Autoscale Group에 다양한 인스턴스 종류가 섞여있을 경우 효율성이 매우 떨어짐
  • 다양한 스케일링 정책이 공존할 경우 효율성이 떨어짐
  • 충분한 데이터가 쌓일 때 까지 기다림 필요

Health Check

• 인스턴스의 상태를 체크하는 기능
• 상태 확인 소스
  • EC2 : 인스턴스가 실행중인지, 하드웨어 상태가 정상적인지 확인
  • ELB : 트래픽을 발생시켜서 해당 트래픽을 잘 수행하는지 확인
  • VPC Lattice : 생략
  • 커스텀 : 직접 커스텀 로직으로 상태를 확인
• 상태확인에 실패했을때 Unhealthy 상태로 변경 > Autoscale에서 직접 해당 인스턴스를 교체

인스턴스 Warm Up / Health Check Grace Period

• 인스턴스 Warm Up
  • 인스턴스에 대한 CloudWatch의 모니터링 지표가 수집 되기 전 준비 기간
  • 트래픽을 받기 전에 지표등이 반영되지 않도록 설정 가능
• Health Check Grace Period
  • 신규로 추가된 인스턴스가 Health Check을 수행 하기 전 준비를 위한 기간
    • 기본 300초
  • 인스턴스가 신규로 올라간 이후 준비가 오래 필요할 경우 등에 활용

Instance Scale-In Protection

• Autoscale 혹은 인스턴스 단위로 인스턴스의 종료를 막는 기능
• 디버그 목적 혹은 로직을 끝까지 수행할 수 있도록 보장하기 위해서 사용
• Protection이 있어도 종료되는 경우
  • Health Check Fail
  • Spot 인스턴스
  • 수동으로 삭제

인스턴스 Lifetime 관리

• 인스턴스가 최대로 실행되어 있는 기간(초 단위)을 설정 가능
  • 해당 기간 이후 자동으로 교체
• 최소 1일
• 설정을 취소하려면 새로운 값을 0으로 입력 > 모든 인스턴스에 적용
• Scale In Protection이 걸려있을 경우, 해당 기능 우선
  • 즉, 인스턴스가 종료되지 않을 수 있음
• 기본 교체 방법은 인스턴스가 종료된 후 신규 인스턴스 생성

인스턴스 유지 관리 정책

• 인스턴스의 숫자가 변동할 때 어떤 우선순위로 어떻게 변동할지를 정하는 정책

인스턴스 유지 관리 기본 정책

인스턴스 유지 관리 커스텀 정책

Autoscale 기능 임시 비활성화

• 임시로 Autoscale의 다양한 기능을 비활성화/활성화 가능
  • 주로 디버그 / 상황 대응의 복적으로 활용
• 주요 비활성화 가능한 기능
  • Launch : 인스턴스의 Scale Out이 필요할 때 신규 인스턴스를 시작을 비활성화
  • Terminate : 인스턴스의 Scale In이 필요할 때 인스턴스 중지를 비활성화
  • AddToLoadBalancer : ELB에 인스턴스 등록을 중지
  • AZRebalance : 가용영역간에 골고루 인스턴스가 분배되도록 인스턴스 조절 기능을 중지
  • HealthCheck : 인스턴스의 상태 체크를 비활성화
  • ReplaceUnhealthy : HealthCheck에 실패한 인스턴스의 교체 비활성화

Autoscale 관리 임시 해제

• 임시로 Autoscale으로 관리중인 인스턴스를 StandBy 상태로 전환 가능
• StandBy : ELB의 트래픽을 받지 않고 HealthCheck도 임시로 비활성화된 상태
• 업데이트, 디버그 등등 목적으로 활용 가능
  • 예 : 인스턴스를 StandBy로 두고 관련 소프트웨어 업데이트 후 복귀
• StandBy 설정 시 desired capacity 조절 가능
  • desired capacity 하나를 낮추면 Autoscale그룹에서 인스턴스 숫자 유지
  • desired capacity 변경 없이 진행한다면 Autoscale그룹에서 인스턴스를 추가
• AZRebalance 가 비활성화 되어있지 않다면, StandBy가 풀리면서 인스턴스 조정 가능

Autoscale Lifecycle Hooks

• Autoscaling의 각 단계에서 특정 로직을 수행할 수 있는 기능
  • 주로 미리 수행되어야 하는 작업/ CI/CD 파이프라인을 통한 배포 등을 수행
• 추후 Notification Target에 대해 배우고 나서 실습진행 예정
  

Elastic File System

• NFS 기반 공유 스토리지 서비스
  • 따로 용량을 지정할 필요 없이 사용한 만큼 용량이 증가 <-> EBS는 미리 크기를 지정해야 함
• 페타바이트 단위까지 확장 가능
• 몇 천개의 동시 접속 유지 가능
• 데이터는 여러 AZ에 나누어 분산 저장
• 쓰기 후 읽기 일관성
• Private Service : AWS 외부에서 접속 불가능
• 각 가용영역에 Mount Target을 두고 각각의 가용영역에서 해당 Mount Target으로 접근
• Linux Only
  

Amazon EFS 타입

• Regional : 리전 전체를 활용하여 고가용성과 내구성 확보
• One-Zone : AZ 하나만 활용하여 고가용성과 내구성은 떨어지지만 저렴한 가격

Amazon EFS 퍼포먼스 모드

• General Purpose : 가장 보편적인 모드
• Max IO : 매우 높은 IOPS가 필요한 경우

EFS Throughput 모드

• Elastic Throughput : EFS가 자동으로 Throughput을 조절 - 예측하기 어렵거나 적은 범위에서 변동이 있는 경우
• Bursting Throughput : 낮은 Throughput일 때 크레딧을 모아서 높은 Throughput일때 사용
• Provisioned Throughput : 미리 지정한 만큼의 Throughput을 미리 확보해두고 사용

T인스턴스

• T 인스턴스는 burstable performance instances
  • 다른 인스턴스 타입처럼 고정된 용량의 CPU 자원을 제공하지 않음
  • CPU 크레딧 제도
    • CPU 사용량이 기본 수준 이상이라면 크레딧을 차감
    • CPU 사용량이 기본 수준 미만이라면 크레딧을 제공
  • 베이스라인 : CPU사용량을 통해 크레딧의 소모와 증가가 같은 지점
• 즉 평소에는 baseline 밑으로 유지해 크레딧을 모으고 꼭 필요한 상황에 크레딧을 소모해 Burst
• 크레딧이 없다면 최악의 경우 CPU 사용량이 5% 미만으로 제한

T인스턴스 모드

• 스탠다드 모드
  • 베이스라인 이상으로 Burst가 발생할 경우 미리 저장된 크레딧을 소모해 CPU 사요
  • 크레딧이 없다면 베이스라인 이상으로 CPU 사용 불가
• 언리미티드 모드
  • 제한없이 필요한만큼 CPU 사용
  • 베이스라인 이상으로 Burst가 발생할 경우 미리 저장된 크레딧을 소모해 사용
  • 크레딧이 없을경우, 24시간 안으로 크레딧을 빌려 충당
  • 24시간 안에 베이스라인 미만으로 CPU를 유지해 추가된 크레딧으로 갚기 가능
  • 갚지 못한 크레딧은 비용을 지불해 충당
• T2는 스탠다드가 기본, T3는 언리미티드가 기본

Launch Credit

• T2 인스턴스의 경우 Launch Credit을 제공
  • 인스턴스가 처음 생성될 때 제공
  • 생성 직후에 Burst 로 진입할 경우를 대비
  • Standard 모드가 Default 이기 때문
• T3의 경우 Unlimited Mode가 기본이기 떄분에 Launch Credit이 부여되지 않음
  • 즉 T3를 Standard모드로 사용해서 생성할 경우, 바로 Burst 진입 불가
    

T2인스턴스가 크레딧이 없을 경우

• 인스턴스의 응답이 없음
• 어플리케이션이 자주 멈춤

해결책

• 인스턴스 사이즈 들리기
• 인스턴스 타입 바꾸기
• Unlimited 모드로 바꾸기
• 계획적으로 CPU 사용하기

인스턴스 타입 변경

• 클라우드 컴퓨팅의 장점을 최대한 이용하여 프로비전 이후에도 적절한 타입/사이즈로 변경 가능
• 두 가지 변경
  • 사이즈 변경 : 같은 인스턴스 패밀리에서 사용량에 따라 크기 조절
  • 패밀리 변경 : 워크로드의 성격에 따라 다른 인스턴스 패밀리로 변경
• 호환성 체크 필요
  • 가상화타입, EBS 볼륨 개수 등
• 인스턴스 정지 필요
  • Spot 인스턴스는 변경 불가능
  • HealthCheck 불가능 > Autoscale에 영향
• 참고사항
  • 인스턴스 아이디는 유지
  • Private IP는 유지하지만 Public IP는 변경(중지하고 시작하기 때문)
• 인스턴스 스토어와 EBS 사용 인스턴스에 따라 과정이 달라짐